On Tue, Aug 18, 2026 at 2:14 AM Connor Song <perdixky_at_[hidden]> wrote:

> > Your paper suffers from long Latinate sentences and (in some places) the
> bolding and sycophancy characteristic of ChatGPT output.
>
> You got me :), I do use GPT for the paper's generation, as my English
> capability is not sufficient [...]
>

+1 to what David Brown said, btw. Your emails are perfectly comprehensible.
Just write your paper in the same way. :)


> So, your paper does not fix the one thing I think would be worth fixing.
>
> There are two differences between `ranges::for_each` and `for`; my paper
> only addresses the "presence" vs. "valid" distinction, because I was a
> little afraid of making the paper too large given my experience. Actually,
> my opinion is more aggressive than what's in this paper: I'd like to
> totally relax the checking on the `for` expression, making it check whether
> `begin` and `end` are *valid separately*, so that `for` may be aligned with
> `ranges::for_each`. (I'm not sure about that, though — it may need a
> thorough investigation. If that sounds good to you, I'll dive into that.)
>

Well, I think I'd disagree with that direction too: I think it's good that
the core-language `for` requires a "matching pair" of `begin` and `end`. It
doesn't really make sense to get `begin` from one place and `end` from
another. So I would much rather "fix Ranges" (the later, worse, arrival) to
match the core language, than worsen the core language in order to match
Ranges.

However, I admit that the core language isn't perfect today. Consider (
Godbolt <https://godbolt.org/z/Eb94M5obr>):

namespace N {
    struct A {};
    int *begin(A);
    int *end(A); // selected
} // namespace N

struct B : N::A {};
int *begin(B); // selected

int main() {
    B b;
    for (int elt : b) {}
}

Here the core-language `for` matches up `::begin(B)` with `N::end(A)`. IMO,
in an ideal world, that wouldn't happen: those two functions clearly aren't
"intended" for use together!
But that example could be presented as evidence that the core language
already doesn't *truly* care about things matching up correctly. "It
permits nonsense like that, so why not loosen it up and permit
*additional* kinds
of nonsense, for the sake of matching all the kinds of nonsense that Ranges
permits?" is a plausible argument, IMHO.

I believe you're right that loosening the core language's rules to match
Ranges' would be a valid approach to LWG4389. I think it'd be fixing the
problem *in the wrong way*, but I agree it would be fixing the problem.

HTH,
Arthur

>