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
smime.p7s
Description: S/MIME Cryptographic Signature