Arthur :

> The proposed change merely takes code that people already avoid (because
> it is ugly) and introduces a special-case ad-hoc hack to make it *still
> ugly but 7 characters shorter*.
>

 I don't think that's fair to describe this as a hack. Most languages are
written with simple top down, context-free parsing in mind, this would
bring C++ a bit closer to that. At the very least it is not more of a hack
than the present day syntax, while being much more palatable.

But our changes should find ways to improve *the code people already write*,
> like
> template<enable_if_t<X,int>=0> // syntax error because ">=" is a token
>

Do you have an example of a more pressing syntax problem outside of SFINAE?
Because obviously the people who have to use enable_if will not be able to
benefit from any syntax improvement, since they are stuck with an outdated
compiler already.

Personally, I waste time turning members functions templates into
friends/or turn explicit into deducible parameters everyday. I've never, as
far as I remember, stumbled on the issue you mentioned.

Which nobody will use, because in order to use it you have to know that the
> problem exists, and once you know the problem exists, the problem is
> already solved. The problems we should focus on solving are the problems
> that people tend to run into *without* understanding them.
>

I don't find this convincing. What's "a problem you run into without
understanding it"? The problem is not solved for all the programmers who
know about it : the syntax is still bad and they have to waste time working
around it. What's more practical? Having to use "::" in context dependent
code or going out of your way to avoid members functions templates
altogether?

Lastly, isn't `x.get<0>()` already fixed by
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html "Declarations
> and where to find them"?
>

I wouldn't expect that, the syntax of member functions templates is
undecidable without context.

Le ven. 8 oct. 2021 à 23:08, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> a
écrit :

> In other words, the proposal is more-or-less that C++ should introduce a
> new token, ::< , which is treated by the parser as "The same token as < but
> it's invariably an angle bracket, not a less-than sign." Phrased that way,
> the proposal is *simple*, but that doesn't make it *good*.
>
> I would like to see some kind of cleanup around angle-brackets, but this
> particular small fix doesn't provide enough benefit to justify its cost.
> The cost of changing the parser is honestly not very big (we did it for
> operator<=>). But our changes should find ways to improve *the code
> people already write*, like
> template<enable_if_t<X,int>=0> // syntax error because ">=" is a token
> The proposed change merely takes code that people already avoid (because
> it is ugly) and introduces a special-case ad-hoc hack to make it *still
> ugly but 7 characters shorter*. Which nobody will use, because in order
> to use it you have to know that the problem exists, and once you know the
> problem exists, the problem is already solved. The problems we should focus
> on solving are the problems that people tend to run into *without*
> understanding them.
>
> I don't like "Down with typename!" either, but at least it was focused on
> making the compiler accept *the code that people already write*. This
> proposal just makes up a *new* syntax that people won't want to write
> (even if they knew they could, which they won't).
>
> Lastly, isn't `x.get<0>()` already fixed by
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html
> "Declarations and where to find them"?
> I'm even more confident that it fixes
> using f = T::type<0>;
> because that is a typeid-only context, where the `<` cannot possibly
> denote a less-than sign.
>
> my $.02,
> –Arthur
>
>
> On Fri, Oct 8, 2021 at 4:21 PM Jean-Baptiste Vallon Hoarau via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> Hi,
>>
>> "x.template get<0>()" becomes "x.get::<0>()".
>>
>> (That's addressed in the first email, but perhaps the formatting makes
>> that unclear)
>>
>> Le ven. 8 oct. 2021 à 22:15, Barry Revzin <barry.revzin_at_[hidden]> a
>> écrit :
>>
>>>
>>>
>>> On Fri, Oct 8, 2021 at 2:11 PM Jean-Baptiste Vallon Hoarau via
>>> Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>>> The current disambiguator for template members of context dependent
>>>> ID is excessively verbose, to the point where members functions
>>>> template needing explicit parameters are largely avoided. This is a
>>>> problem.
>>>>
>>>> I think that the Rust "turbofish" syntax provides an elegant
>>>> alternative, which consists of having the token "::" preceding the template
>>>> parameters list.
>>>> That is the code
>>>>
>>>> ```
>>>> x.template get<0>();
>>>> using f = T::template type<0>;
>>>> ```
>>>>
>>>> becomes :
>>>>
>>>> ```
>>>> x.get::<0>();
>>>> using f = T::type::<0>;
>>>> // ^^
>>>> ```
>>>>
>>>> I hope that you'll agree that this syntax is more ergonomic. It's also
>>>> not unpleasant from a semantic point of view, as "::" is used to query a
>>>> child entity, and template instantiation are childs entities of the primary
>>>> template.
>>>>
>>>> It would also not be difficult to allow the turbofish in front of every
>>>> templates parameter list, for consistency. E;g. :
>>>>
>>>> ```
>>>> template <int N> struct type{};
>>>> type::<0> x; // not needed, but ok
>>>> ```
>>>>
>>>> Would this create any conflicts with the current C++ grammar ?
>>>>
>>>
>>> What would you do for member function calls? For instance, today's
>>> "x.template get<0>()" becomes... ?
>>>
>>> Barry
>>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>