On Thu, Apr 15, 2021 at 6:50 AM Jens Gustedt via Liaison
<liaison_at_[hidden]> wrote:
>
> Ville,
>
> on Thu, 15 Apr 2021 13:22:05 +0300 you (Ville Voutilainen
> <ville.voutilainen_at_[hidden]>) wrote:
>
> > On Thu, 15 Apr 2021 at 13:06, Jens Gustedt <jens.gustedt_at_[hidden]>
> > wrote:
> > >
> > > Ville,
> > > your answer shows a sufficient amount of bad faith, I find.
> >
> > I have the exact same thoughts about your dismissal of concerns about
> > deployment and editing
> > of source code as "culture wars".
>
> I am not dismissing them, I just said that we had them often
> enough. And that I wanted to hear about the other part.
>
>
> > But fine. If you wish to shut your eyes
>
> Why would you say that?
>
> Just because I *also* at one point want to collect the other
> information?
>
> > about anything besides the implementation and specification aspects
> > of this, go ahead. You need to describe how these new punctuators
> > fit into operator precedence,
>
> no, these operators are not new, they would just be different
> spellings
>
> (and I described how I see that this fits into the C specification in
> several papers, you could have a look at
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2644.pdf, for example)
>
> > and add them as alternative spellings of some existing semantic
> > descriptions. Overall, I think there's not much specification
> > difficulty, at least not for things that are just alternate
> > spellings.
>
> That's the kind of information that I was after, thank you.
>
> > I don't know whether you envision adding new operators,
>
> no

Then these aren't "just different spellings" as far as I can tell. For
example, this is valid C++ code that uses a different spelling:

struct S {
  int operator and(int i); // [lex.digraph]
  int operator <::>(int i) const; // [lex.digraph]
};

Why are these hypothetical punctuators different?

~Aaron

> > which is then a completely different ballgame, because in order to
> > evaluate the difficulty of that, we'd need to know what the intended
> > semantics are.
>
> sure
>
> > Based on how you deal with comments related to this idea,
>
> Have you other examples for that, or is this just about this
> conversation here, and my reaction to your reaction?
>
> > especially when they're not exactly the comments you wished to have,
> > I recommend against wasting committee time on this. Discussing
> > those matters is inevitable, and trying to cover just a subset of
> > the problems in this problem space while ignoring the others isn't
> > going to get us anywhere.
>
> I think it would effectively be a waste of time to discuss these
> things if in the end they were difficult to implement (in the standard
> or in compilers). Your statement above (and my experience implementing
> this) seems to indicate that this isn't the case. But I'd also like to
> hear from others, that perhaps have insight in implementations that
> feature non-Unicode characters sets, for example.
>
> So then, and if others agree about this assertion, we could have the
> discussion about cultural differences, cultural dominance, personal
> preferences, language imposed coding style, free speech ...
>
> Thanks
> Jens
>
> --
> :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
> :: ::::::::::::::: office Strasbourg : +33 368854536 ::
> :: :::::::::::::::::::::: gsm France : +33 651400183 ::
> :: ::::::::::::::: gsm international : +49 15737185122 ::
> :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/04/0438.php