Sirraide wrote: > It’s not entirely clear to me which of the conditions I listed above > constitute an ill-formed program, and which are grounds for switching to > destructuring instead. GCC and the experimental fork also don’t seem to agree > with each other on this.
What I believe would have the best QOI is something like - if either member `begin()` or `end()` exist (irrespective of whether they’re accessible), it is an iterating expansion statement (albeit perhaps an ill-formed one); otherwise - if ADL for either `begin()` or `end()` finds a single best viable candidate (simply checking if they exist doesn’t suffice here; as stated above, doing ADL on e.g. anything in namespace `std` will find a number of `begin()`/`end()` overloads), it is an iterating expansion statement (albeit perhaps an ill-formed one); otherwise - it is a destructuring expansion statement. This in my opinion would have the least risk of potentially confusing what is probably supposed to be an iterating expansion statement for a destructuring one. To me, it stands to reason that if we can find *any* `begin()` or `end()` member, or a *best viable* ADL `begin()` or `end()`, then the user probably intended for this to be an iterating expansion statement. In particular: - If either `begin()` or `end()` is deleted, I would assume that user intent is ‘don’t iterate over this or expand it please’, i.e. it should be an ill-formed iterating expansion statement. - Similarly, if we can only find one of `begin()` or `end()`, it seems more reasonable to me to assume that the user forgot to provide the other one, rather than assuming that it’s supposed to be a destructuring expansion statement, and that the sole `begin()` or `end()` serves some entirely unrelated purpose. From what I recall in the proposal for this feature, ‘if you don’t get the `begin()`/`end()` protocol exactly right, you silently get destructuring instead’ is precisely something that the designers wanted to avoid. That said, I’m entirely unsure if any of that matches the intent of the standard here. https://github.com/llvm/llvm-project/pull/165195 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
