>
> You're going to have to put forth some pretty compelling evidence to
> convince people that "everyone puts extra work to avoid needing"
> `template`. Remember: most template functions deduce their parameters
> *naturally* (ie: without having to write them to do so). So the number
> of functions in question is pretty small.
>

Informally : I do, every API I have ever used largely avoids and workaround
member functions templates with explicit parameters, every C++ programmer I
know avoids them and knows how to workaround them. This is embarrassing to
C++ as a language and only someone who's been programming too much in C++
for too long (like me, and I suspect, everyone in this thread) would think
this is a comfortable state of affairs.

And no, nobody's going to use `::<` unless they *have to*.


The burden of proof is on you. In Rust, "::" must precede *every* explicit
parameters list, yet I have never seen anyone turning an explicit parameter
into a deducible one because typing '::' is too much work.

It requires no more "cognitive load" than `::<`, since people are only
> going to use that where they have to.
>

".template" is harder to read, harder to write, can be used only for
context-dependent symbols. It's a lot less ergonomic for any useful
definition of "ergonomic".

Let me finish that sentence more directly: "which other types can
> participate in *without* having to modify the definition of those
> types". Also see `begin/end`, `size`, `data`, `swap`, and so forth.
>

If what you're saying is "the current syntax had no incidence on the design
of the standard library", this is simply not true.
If you're saying "everything a member function can do can be done by a free
function", then again, no, for the aforementioned reasons.

Le dim. 10 oct. 2021 à 01:21, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> a écrit :

> On Sat, Oct 9, 2021 at 1:20 PM Jean-Baptiste Vallon Hoarau via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > Jason :
> >>
> >> I believe his point is that, even though it's "simpler" than
> >> `template`, you still have to do *something* that you wouldn't
> >> ordinarily have to do. That is, you still have to know that you need
> >> disambiguation syntax. As such, your proposal doesn't fix the C++
> >> parser to take the expected code. It merely provides a different
> >> spelling of the disambiguated code.
> >
> >
> > If I could magically make the C++ grammar context-free, I would. However
> it's too late for that, the grammar is undecidable and having to use a
> disambiguator is the price to pay in some cases. The question is what kind
> of disambiguator do we want : one so bad that everyone puts extra work to
> avoid needing it, or one that's reasonably usable and can be used
> coherently in non ambiguous code.
>
> You're going to have to put forth some pretty compelling evidence to
> convince people that "everyone puts extra work to avoid needing"
> `template`. Remember: most template functions deduce their parameters
> *naturally* (ie: without having to write them to do so). So the number
> of functions in question is pretty small.
>
> And no, nobody's going to use `::<` unless they *have to*.
>
> >> The problem you're talking about is one that the compiler basically
> >> tells you how to fix. "It looks like you tried to write a template
> >> specialization, but you need to put 'template' there." You encountered
> >> a problem and understand what you need to do to solve it.
> >
> >
> > I think there's a misunderstanding about the nature of the problem. The
> problem is not that people try to write this kind of code and it fails :
> this happens once. The problem is that people now have to go out of their
> way to workaround something so basic, which happens everyday. How many
> times do programmers accidentally step on the "most vexing parse"? Perhaps,
> once or twice before they know what's going on. The fix is easy : use "{}"
> or "=" to declare and initialize variables. You can use that and forget
> about it because the solution is unobtrusive. You can't forget about having
> to type ".template" everywhere or turns everything into a deducible
> parameters : it's both ugly and requires cognitive load, that you could
> have used to do more interesting things than fixing the C++ grammar.
>
> It requires no more "cognitive load" than `::<`, since people are only
> going to use that where they have to.
>
> >> If having to write 9 extra characters
> >> is enough to make you fundamentally rewrite code, I don't see how
> >> having to write 2 characters would make you stop.
> >
> > Isn't 2 a lot less than 9? I have no trouble seeing how not
> interspersing my code with a 9 letter word when most of my identifiers are
> less than that, and replacing that with a 2 characters punctuator would
> improve readability.
> >
> >> C++ didn't make
> >> `std::get` a free function because making it a template member of
> >> `tuple` would make it too ugly to call. We did it because it creates a
> >> uniform interface for extracting members which other types (like
> >> `pair`) can participate in.
> >
> > How would this have been impossible with a member function?
>
> Let me finish that sentence more directly: "which other types can
> participate in *without* having to modify the definition of those
> types". Also see `begin/end`, `size`, `data`, `swap`, and so forth.
>
> Extensible uniform APIs are best built from free functions in C++, not
> member functions. Or at least, not *only* member functions.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>