[libcxx-commits] [libcxx] [libc++] Remove `optional::iterator` from experimental mode (PR #203782)

Louis Dionne via libcxx-commits libcxx-commits at lists.llvm.org
Fri Jun 26 08:52:29 PDT 2026


https://github.com/ldionne commented:

I synced up with @philnik777 about this patch today and he had some very interesting ideas. I understand better why he feels this isn't ready to be baked into the ABI yet, and I agree.

One of the things he's been thinking about is an iterator that actually encodes bounds information *at runtime*, but in a very efficient way. For example, `optional::iterator` could be implemented as a pointer and we store whether we're `begin()` or `end()` in a low bit of the pointer (which is free to use depending on the alignment of the pointee). Then, in `operator*`, we can either decide to `assert` that we're not `end()` (in which case this is an efficient and specialized bounded iterator for 0 or 1 things), or we `assume` it and then we basically just don't perform any bit twiddling and dereference the pointer directly.

That's one possible direction. And this also ties into `inplace_vector`, where we might want to use similar tricks (as long as we can shove `N` into the low bits of a pointer, we can use the same trick). We might also potentially want to artificially increase the alignment of the `inplace_vector` so that small types can get this kind of implementation.

So, given this still has some design space, I agree we're not ready yet to make this non experimental. In order not to stall this, I think we should implement the above idea and validate whether that's what we want to do for `optional::iterator`.

Note that this iterator could actually be a simple improvement to `__capacity_aware_iterator` when `N` fits in the low bits of the pointer. It's a bit like a specialized "capacity-aware bounded iterator".

https://github.com/llvm/llvm-project/pull/203782


More information about the libcxx-commits mailing list