Date: Tue, 16 Feb 2021 01:31:19 +0100
On Tue, Feb 16, 2021, 01:18 Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:
> On Tue, 16 Feb 2021 at 02:11, Corentin <corentin.jabot_at_[hidden]> wrote:
>
> >> $ is not up for grabs for C++. This has been discussed in SG7 and
> >> elsewhere before, but for the purposes of this discussion,
> >> suffice it to say that there are existing tools that rely on $ not
> >> being C++, and those tools can do balanced-token parsing
> >> of C++ source code, without parsing C++, because they know that $ isn't
> C++..
> > I don't know if that's as clear cut.
> > Standard adoption is slow, if we decided that $ is the best solution, it
> would be a medium term inconvenience for a small number of users.
>
> We have no knowledge of what the length of that term is, or how our
> understanding of that term matches that of the users
> impacted, and we have no way to know whether it impacts a small number
> of users or a larger one. On such occasions,
> we have tended to be careful rather than rash.
>
> > Which i understand would be a tough pill to swallow but, i suspect the
> conversation will have to be had at some point. If not for reflection, for
> the next feature which needs some syntactic space.
>
> The conversation has been had, multiple times. I fail to see how the
> next feature wouldn't just repeat the discussion,
> and need to find a syntax that doesn't break existing tools, like
> everything else needs to.
>
The amount of available token sequences is getting thin, as demonstrated by
[: :]
I don't really have a horse in this race but if we assume in 10+ years
reflection will be common place (and i think that's a fair assumption), i
think there is some value is making sure we do not restrict the set of
syntaxes available to us over shorter terms concerns!
It's a trade off more than it is an impossibility!
>
wrote:
> On Tue, 16 Feb 2021 at 02:11, Corentin <corentin.jabot_at_[hidden]> wrote:
>
> >> $ is not up for grabs for C++. This has been discussed in SG7 and
> >> elsewhere before, but for the purposes of this discussion,
> >> suffice it to say that there are existing tools that rely on $ not
> >> being C++, and those tools can do balanced-token parsing
> >> of C++ source code, without parsing C++, because they know that $ isn't
> C++..
> > I don't know if that's as clear cut.
> > Standard adoption is slow, if we decided that $ is the best solution, it
> would be a medium term inconvenience for a small number of users.
>
> We have no knowledge of what the length of that term is, or how our
> understanding of that term matches that of the users
> impacted, and we have no way to know whether it impacts a small number
> of users or a larger one. On such occasions,
> we have tended to be careful rather than rash.
>
> > Which i understand would be a tough pill to swallow but, i suspect the
> conversation will have to be had at some point. If not for reflection, for
> the next feature which needs some syntactic space.
>
> The conversation has been had, multiple times. I fail to see how the
> next feature wouldn't just repeat the discussion,
> and need to find a syntax that doesn't break existing tools, like
> everything else needs to.
>
The amount of available token sequences is getting thin, as demonstrated by
[: :]
I don't really have a horse in this race but if we assume in 10+ years
reflection will be common place (and i think that's a fair assumption), i
think there is some value is making sure we do not restrict the set of
syntaxes available to us over shorter terms concerns!
It's a trade off more than it is an impossibility!
>
Received on 2021-02-15 18:31:34