Your 'using' syntax does seem more scalable with regards to multiple entities and different types of entities, though it seems more like it's just focused towards normal declarations of variables, since I'm unsure how it would look when used with parameters, but even if there is a nice way to use it for parameters, it seems like it would just be reinventing normal template declaration syntax.

I wonder though if maybe the matter of different types of entities, i.e. types and variables, is maybe a separate issue from "named auto"? We can't deduce e.g. the extent of an array now with terse syntax, which maybe is a pain point, and it might be good to have a solution that would cover it as well, but I'm not sure I'm sold on these issues being so intimately linked that we need a solution that fixes both.

Also for the record, I envisioned my 'T{auto} var' syntax being combined with concepts like 'T{std::copyable auto} var'.
------- Original Message -------
On Tuesday, September 27th, 2022 at 2:40 PM, Edward Catmur <ecatmur_at_[hidden]> wrote:

> On Tue, 27 Sept 2022 at 19:52, Keenan Horrigan via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> Perhaps it could be spelled like
>>
>> T{auto} var = ...;
>>
>> Then 'auto' is still apparent, and it might seem more like it's declaring 'T' there? maybe? Definitely doesn't look like a template instantiation at least. I think it might also make it more clear what type is actually getting stored in 'T' since the 'T' is just taking the place of 'auto', it looks more like normal template deduction.
>>
>> I do think it would be really nice to have some sort of "named auto". I've held off on extensive use of auto parameters mainly because often when I deduce a parameter's type, I also want to name that type, e.g. for forwarding (but also for other things), and doing 'decltype(arg)' all over the place is very cluttered, and making a 'using' declaration sort of defeats the point of the terse 'auto' syntax, because why wouldn't I just make an explicit template parameter then? That problem gets amplified even more if I would need to 'remove_cvref' on it.
>
> I agree with this; decltype is ugly, you're never quite sure when you need to `remove_cvref` on it, and it doesn't allow you to pattern match or destructure types, other than the very basic cv/pointer/reference stuff.
>
> The interesting thing about this feature is that it would introduce multiple identifiers into block scope: at minimum, a type alias and a variable, but possibly multiple type aliases, constexpr variables (binding the extent of a std::array, for example) and even possibly introducing packs (making P1061 "Structured Bindings can introduce a Pack" relevant). Also in the same space would be P1985 "Universal Template Parameters", since the introduced type name might be dependent.
>
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1061r2.html
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1985r3.pdf
>
>> So I would very much like some sort of "named auto" in the language, and I am finding myself more fond of the 'T{auto} var' syntax as I write this out. I'm presently unsure if it would conflict with any other syntax, maybe brace-initialization? I wouldn't think so since it'd be in a type's position always but I'm not an expert in that stuff.
>
> I would be inclined to a syntax that makes it very clear that multiple entities of possibly different kinds are being introduced.
>
> Since this would be replacing a `using` on the following line, why not move that to the head?
>
> // before
> auto const& vec = getVec();
> using Vec = std::remove_cvref_t<decltype(vec)>;
> using T = typename Vec::value_type;
> static_assert(std::same_as<Vec, std::vector<T>>);
>
> // after
> using { typename T } std::vector<T> const& vec = getVec();
>
> More examples:
>
> using { class K, class V } std::pair<K const, V>& kv = *map.begin(); // or [k, v]?
> using { std::copyable T, auto I } std::array<T, I> arr = getArr();
> using { std::size_t... I } [[maybe_unused]] std::index_sequence<I...> seq = std::index_sequence_for<Args...>();
>
>> ------- Original Message -------
>> On Tuesday, September 27th, 2022 at 1:32 PM, Oleksandr Koval via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>>>> 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.
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]p.org
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals