Date: Tue, 16 Feb 2021 02:18:10 +0200
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.
>> $ 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.
Received on 2021-02-15 18:18:24