C++ Logo


Advanced search

Re: [std-proposals] Proposal for a new language feature: auto?

From: Barry Revzin <barry.revzin_at_[hidden]>
Date: Sat, 16 Apr 2022 14:19:56 -0500
On Sat, Apr 16, 2022 at 8:13 AM Jonathan Sweemer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello,
> I have been following std-proposals for a little while and would like to
> share my first idea with everyone. It's not fully formalized yet but I
> would be grateful for some initial feedback on it.
> What I would like to propose is a new syntax for deducing either a value
> type or a const reference type depending on whether the type being deduced
> is both a) trivially copyable and b) two words in size or fewer.
> I think that auto? would be an intuitive syntax for this, as it suggests
> that the type may or may not be deduced as a reference type. Essentially
> auto? is the same as auto when the two conditions above are met, and then
> same as const auto& when not.
> Here's what auto? would look like in different scenarios:
> // local variable declaration
> auto? t = vector.front();
> // range-based for loop
> for (auto? i : vector) {}
> // lambda argument
> auto lambda = [](auto? x){};
> Has this sort of language feature been suggested before? If so, can
> someone point me to the paper for it?

This is one very narrow use-case from a broader language feature, which is:
the ability to write a deduction guide for a name which doesn't point you
to a class template of the same name. For instance:

template <class T> auto_cref(T&&) -> T;

auto_cref a = 42; // a is an int
auto_cref b = a; // b is int&

More generally, this could be used to do the kind of "operator auto" thing
that people have wanted in the past. Can also implement auto this way:

template <class T> auto(T) -> T;

Can... not quite... implement decltype(auto), since you'd have to be able
to differentiate prvalues from xvalues and deduction can't do that. This
wouldn't help you in the parameter case though, since we don't support
class template argument deduction there.

Adding a language feature for *very specifically* the use-case you're
describing doesn't seem worth it though.


Received on 2022-04-16 19:20:10