On Wed, Feb 11, 2026 at 02:56:36AM +0200, Ville Voutilainen wrote:
> This was discussed some moments ago on the Core reflector, and it was
> pointed out that it's quite
> intentional in the proposed resolution of CWG 3123 that there's no
> overload resolution used for
> determining whether iteration is the chosen approach instead of
> destructuring, just a viability check.
> As far as I understand the code, finish_call_expr indeed does overload
> resolution.
>
> This additional testcase was provided: https://godbolt.org/z/o39hEs876
>
> In it, overload resolution fails due to an ambiguity, for iteration,
> and then destructuring is used instead. But the intent
> of the proposed resolution is that the semantics are (more) similar to
> what range-for uses, so the intent
> is that for iteration, only the presence of viable overloads is
> checked, and then iteration is committed to,
> and then the testcase should be rejected because the actual attempt to
> expand with iteration fails due to the aforementioned
> ambiguity.
>
> None of that affects this patch as such, but I think it's worth
> pointing out where this should eventually be going.
Ah, you're right.
Jason, do we have any call.cc API that just tells us if there were
any viable candidates, either stopping just there (after splice_viable?)
or going on until end but propagating the result from splice_viable
back in some way? In the latter case if it is error_mark_node but
any_viable was set (for both calls) we could commit to esk_iterating
and just repeat the lookup with tf_warning_or_error.
Jakub
