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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>