> 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@lists.isocpp.org> wrote:
On Tue, Sep 27, 2022 at 10:03 AM Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Tue, Sep 27, 2022 at 8:46 AM Oleksandr Koval via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


--
Regards,
Oleksandr Koval.