On Sun, Oct 10, 2021 at 4:00 PM Jean-Baptiste Vallon Hoarau via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> 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,

You are citing a case where they have no choice *but* to use `::<`
even when it's not needed. Obviously Rust programmers are going to do
what the language requires because... that's what the language
*requires*.

We're talking about syntax where the use of it is 100% optional,
except where it is absolutely necessary. You're trying to say that C++
programmers are just going to wholesale switch to this syntax when
they don't have to. Citing an example where programmers do this
because they have no choice isn't a valid point of comparison.

> yet I have never seen anyone turning an explicit parameter into a deducible one because typing '::' is too much work.

I haven't seen anyone turn an explicit parameter into a deducible one
just because of `template` either. Most places I've seen people doing
this are places where providing explicit parameters is impossible
(constructors. See `variant` and the `in_place_index/type_t` syntax),
hugely inconvenient (passing template parameters to `operator()`), or
just reads better as a "value" parameter than a template parameter.
Indeed, the last case is one of the reasons for wanting parameters to
be able to be `constexpr`.

The point being that there are lots of good reasons to make template
function arguments deducible.

>> 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.

Then give me an example. Give me an example of a standard library
function where the `template` disambiguation syntax is the design
reason why a particular API is the way it is. And to make this clear,
when I say "the design reason", I mean there is basically no reason to
design it that way *other than* to avoid this syntax.