On Wed, 10 Sept 2025 at 10:01, Tomasz Kaminski <tkami...@redhat.com> wrote: > > > > On Wed, Sep 10, 2025 at 10:54 AM Jonathan Wakely <jwak...@redhat.com> wrote: >> >> On Wed, 10 Sept 2025 at 09:52, Jonathan Wakely <jwak...@redhat.com> wrote: >> > >> > On Thu, 4 Sept 2025 at 14:39, Tomasz Kaminski <tkami...@redhat.com> wrote: >> > >> + if constexpr (is_same_v<_Out, _Iter_for_t<_CharT>>) >> > > >> > > This would be better if we use _Drop_iter here. This is result of me >> > > doing some other tests. >> > >> > Yes, I agree it should be _Drop_iter<_CharT>. That way if we ever >> > change the _Iter_for<C>::type to be _Iter_sink<C> this won't break, or >> > if we change it to some different type then we will have to explicitly >> > consider how to handle that type here (it's safe to ignore _Drop_iter, >> > but might not be for some other type). >> > >> > Alternatively, we could just remove _Iter_for and define >> > _Iter_for_t<C> as type_identity_t<_Drop_iter<C>>, or just >> > _Drop_iter<C> directly? >> > >> >> Actually, not "alternatively". We still need to change the is_same_v >> check above. >> >> But we could additionally remove _Iter_for. > > Using _Iter_for allowed me to not define the _Drop_iter_t in fmt/formatfwd.h, > but I could put a forward declaration here. My concern here was that changing > the iterator later, will change how __formattable_impl is mangled in the name, > as default argument is. Using _Iter_for allows us to change the iterator, > without > changing the mangling for __formattable_impl, and using _Drop_iter direclty > would affect it.
Yes, that seems more futureproof.
