And if we consider changing syntax, why not go the D route?
We can start with `type!<12, other>` or we can go full D and allow
`type!(12, other)` and `type!other` too.
with `!()` we fix another problem too with macros that break on `<,>`.

At least basic version (only `!<>`) will be probably more readable than `::<`:
```
T::temp!<T2>::temp!<T3>::x
T::temp::<T2>::temp::<T3>::x
```
as the second version looks more "split" than the first one.

niedz., 10 paź 2021 o 22:01 Jean-Baptiste Vallon Hoarau via
Std-Proposals <std-proposals_at_[hidden]> napisał(a):
>>
>> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals