> does need some significant real-world motivation
Well, it's just syntactic sugar, not sure it needs strong motivation beyond
that it makes some things simpler/shorter. I agree that it's not something
I need often but sometimes it's useful.

> needs some "review of literature" on prior proposals in the area
I tried to google "c++ named auto" before posting and found nothing. I
would never call it "in-place syntax" so chances to find Herb's proposal
were extremely low.

It's just an idea, I looked for some feedback and I got it here, thank you
all for your opinions :)

On Tue, Sep 27, 2022 at 6:07 PM Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Tue, Sep 27, 2022 at 10:03 AM Jason McKesson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Tue, Sep 27, 2022 at 8:46 AM Oleksandr Koval via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>> >
>> > Hi, C++20 introduced angle brackets for lambdas to simplify access to
>> argument
>> > types.
>>
>> That's not why it was done. It was done so that you could do things like
>> this:
>
> []<typename T>(vector<T> const& x) {}
>> [...]
>> Overall, what you're proposing is a convenience feature, but it's not
>> really all that necessary most of the time. Users already have the
>> tools to assign a name for an auto-deduced variable's type if they
>> need one. It may take a bit more text to do so [...]
>
>
> Well, technically, users already had the tools to create a callable object
> with an operator()(vector<T> const&) const, if they needed one. ;) I think
> there's no problem with convenience features *per se*. However,
> Oleksandr's proposal:
> (1) does need some significant real-world motivation [which I don't think
> will be forthcoming], and
> (2) needs some "review of literature" on prior proposals in the area.
> Specifically, this syntax seems extremely similar to Herb Sutter's
> "in-place syntax" proposed (but rejected) for C++20 Concepts:
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0745r1.pdf
> IIUC, Herb's "in-place syntax" proposal handled all of these situations:
> template<class> concept True = true; // irrelevant naming bikeshed
> True{T} auto v = GetValue();
> const True{T} auto& v = GetRef();
> void f(True{T} auto v); // same as `template<True T> void f(T v);`
> but did not handle this:
> void f(std::vector<True{T}> v); // could maybe be the same as
> `template<True T> void f(std::vector<T> v);`
> because there's no template-sigil in that last case: no `template` keyword
> and also no `auto` keyword.
>
> There's also the question of whether `auto<T>` looks enough like an
> introduction of the new name `T`. To me, it looks more like you're saying
> "instantiate *something-figure-out-what* with template argument T":
> vector<T>, list<T>, auto<T>. I think Herb's proposal was rejected partly
> (but probably not completely) because `Number{N}` didn't look much like an
> introduction of N (although it didn't look much like anything else
> *either*). At the time of Herb's proposal, the C++2a working draft did
> not yet include the "introducer" syntax `template<Number N> void f(N)`
> either, primarily (IIUC) because people didn't think it was unambiguous
> enough.
>
> my $.02,
> Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
Regards,
Oleksandr Koval.