Hi Jonathan,

Thank you for picking up (the pieces of) my patch.

On 15/09/2024 17:00, Jonathan Wakely wrote:
Oops, that seems wrong, it seems the correct definition in terms
of indirect_value_t should be

   remove_cvref_t<indirect_value_t<projected<I, Proj>>>

as mentioned in P2248R8/5.9.1.
That predates the note in p2609r3, because P2248R8 refers to P2609R0.
In P2609R3 indirect_value_t became the exposition-only
indirect-value-t which is our __detail::indirect_value_t.

I think the working draft should be changed as those two papers
suggest, but I'm not sure if there's any advantage to us making that
change proactively.

I agree; I'm not sure if is there any advantage at doing this change (it's not that there's a massive duplication; plus, if it's not broken, don't touch it?). I'm also not sure whether such a change to the Standard could be considered editorial or if LWG would like to have a look and approve the final result. P2248R8 contains a note to this end, but it wasn't acted upon:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2248r8.html#iterators


Regards,

--
Giuseppe D'Angelo

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to