Hi,

Thank you for the feedback and for CC'ing the people involved in the
earlier discussions.

I haven't yet been in contact with them directly. In fact, one of my main
reasons for posting the draft to this list was to get feedback from people
who have more experience with this area and to make sure I haven't missed
important prior discussions.

Regarding LWG4389, my proposal takes a third direction. The alternatives
there essentially treat the current range-for behavior as the baseline and
try to make the Ranges side consistent with it. My proposal instead
questions whether the current range-for member lock-in rule is itself too
strong.

In particular, I propose using candidate viability as the boundary: merely
having declarations named begin and end should not suppress an otherwise
valid ADL customization if those member operations cannot actually
participate in the calls. At the same time, if viable member candidates do
exist, the member interpretation is still selected, so ambiguities and
similar errors remain diagnostics rather than silently falling back to ADL.

I think this preserves non-intrusive customization better while still
retaining the useful diagnostic behavior once there is stronger evidence
that the member customization was intended.

You're right that the paper should compare this direction with the two
alternatives in LWG4389 more explicitly. I'll add that discussion.

Thanks again,
Connor

Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
于2026年8月10日周一 14:52写道：

> Hi Connor,
>
> just a quick feedback.
>
>
>
> Have you been in contact with some of the community reporting and
> discussing this? I put those on CC.
>
>
>
> Arthur described the issue on his Blog (referenced in LWG4389). He
> normally also frequents this list.
>
>
>
> Jiang An (frederick-vs-ja or F.v.S./de34 on this list) submitted LWG4389.
> Another possible source for feedback.
>
> Also look in libc++ bug #119161, Hewill Kang and Jonathan Wakely discussed
> there with him.
>
> All 3 frequent this list.
>
>
>
> LWG4389 gives 2 solution alternatives including wording. Have you used one
> of them or used a third alternative one? Perhaps compare and give a reason
> for your direction.
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* 宋志博 via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mo 10.08.2026 07:55
> *Betreff:* [std-proposals] Fwd: [Draft Proposal] Further relaxing the
> range-for loop customization point finding rules
> *Anlage:* PXXXXR0.pdf
> *An:* std-proposals_at_[hidden];
> *CC:* 宋志博 <perdixky_at_[hidden]>;
> Hi all,
>
> I'd like to ask for feedback on a draft proposal:
>
> *Further relaxing the range-for loop customization point finding rules*
>
> The proposal revisits the rule used by range-based for to choose between
> member begin/end and ADL customization.
>
> Currently, if class-scope lookup finds declarations named both begin and
> end, range-based for commits to the member interpretation, even when the
> corresponding member calls cannot actually participate. This can prevent an
> otherwise valid non-intrusive ADL customization from being used, and also
> contributes to the discrepancy described by LWG 4389.
>
> The draft proposes committing to the member interpretation only when both
> member operations are applicable.
>
> I've attached the current draft for review.
>
> I would particularly appreciate feedback on:
>
> -
>
> whether the motivating problem is sufficiently compelling;
> -
>
> whether candidate viability is the right boundary for member lock-in;
> -
>
> compatibility or implementation concerns I may have overlooked;
> -
>
> relevant prior work or edge cases that should be discussed.
>
> This is my first WG21 proposal, so comments on the presentation and scope
> are also very welcome.
>
> Thanks,
> Connor Song
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>