Date: Tue, 16 Feb 2021 02:00:20 +0100
On Tue, Feb 16, 2021, 01:47 Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:
> On Tue, 16 Feb 2021 at 02:31, 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!
>
> It would be unwise to make C++ a language that plays less well with
> its surrounding environment. Some of those
> tools support C++ as just one language out of many, and the
> plausibility of such tools just dropping C++ as
> a supported language isn't clear-cut to be a short-term concern. But,
> again, we are rehashing a discussion
> that has been had before, and there's no new information in it.
>
I would point out that java, c#, rust, php, perl, JavaScript, Swift, go, D
and others use dollar signs, either as part of the grammar or in
identifier. And dollar signs can appear in strings, so a tool that would
use a single codepoint to do replacements is likely to be brittle and i
would love to see evidence of such tool existing to such extent that
claiming $ in C++ would be problematic.
Just one!
Should we close design avenues because we cannot with certainty disprove
their existence?
>
wrote:
> On Tue, 16 Feb 2021 at 02:31, 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!
>
> It would be unwise to make C++ a language that plays less well with
> its surrounding environment. Some of those
> tools support C++ as just one language out of many, and the
> plausibility of such tools just dropping C++ as
> a supported language isn't clear-cut to be a short-term concern. But,
> again, we are rehashing a discussion
> that has been had before, and there's no new information in it.
>
I would point out that java, c#, rust, php, perl, JavaScript, Swift, go, D
and others use dollar signs, either as part of the grammar or in
identifier. And dollar signs can appear in strings, so a tool that would
use a single codepoint to do replacements is likely to be brittle and i
would love to see evidence of such tool existing to such extent that
claiming $ in C++ would be problematic.
Just one!
Should we close design avenues because we cannot with certainty disprove
their existence?
>
Received on 2021-02-15 19:00:36