[std-proposals] Make the many times redundant auto optional

[Raymund Hofmann]

The auto keyword is redundant many times.

A range for very likely begins:

"for (auto"

Function declarations, prototypes and especially lambdas with auto
parameters.

Most auto variable declarations.

Could the auto keyword be made optional? Are there cases when it would make
the language ambiguous?

Raymund Hofmann

[Jared Grubb]

If I understand what you're asking, this was proposed but was rejected:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm>

This StackOverflow post discusses it a bit:
https://stackoverflow.com/a/32706369 <https://stackoverflow.com/a/32706369>

Jared

Post by Raymund Hofmann
The auto keyword is redundant many times.
"for (auto"
Function declarations, prototypes and especially lambdas with auto parameters.
Most auto variable declarations.
Could the auto keyword be made optional? Are there cases when it would make the language ambiguous?
Raymund Hofmann
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC56Ubra3FcbrtzmNDw%40mail.gmail.com <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC56Ubra3FcbrtzmNDw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Raymund Hofmann]

The reason on SE it was rejected seems weak for me.

The default is decltype(x) and you could prepend a &, &&, const or whatever
could be validly followed by auto.

for(&e:...)
[](const&e,i){...
auto m(&f)->...
{
*a=&f;
...
}


Imagine a preprocessor inserting the imaginary auto and saving you from
redundancy.

Time this gets proposed again, esp. with ranges making its way into the
standard.

Auto might be remembered as the most redundant keyword.

Post by Jared Grubb
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm
https://stackoverflow.com/a/32706369
Jared
The auto keyword is redundant many times.
"for (auto"
Function declarations, prototypes and especially lambdas with auto parameters.
Most auto variable declarations.
Could the auto keyword be made optional? Are there cases when it would
make the language ambiguous?
Raymund Hofmann
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC56Ubra3FcbrtzmNDw%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC56Ubra3FcbrtzmNDw%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5A1317DB-205E-49B7-B641-8D1E923F0907%40gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5A1317DB-205E-49B7-B641-8D1E923F0907%40gmail.com?utm_medium=email&utm_source=footer>
.

[Ville Voutilainen]

Post by Raymund Hofmann
The reason on SE it was rejected seems weak for me.

That hardly matters when two thirds of the committee opposed the proposal.

Post by Raymund Hofmann
The default is decltype(x) and you could prepend a &, &&, const or whatever could be validly followed by auto.
for(&e:...)
[](const&e,i){...
auto m(&f)->...

The auto is not redundant in function declarations, because a function
parameter can be declared without a name.
Furthermore, with auto-type parameters, the auto keyword is the only
thing that tells you the function is
a template, and there's ample evidence that having such a syntactic
marker is something that large swaths
of the committee will insist having.

[Raymund Hofmann]

Post by Ville Voutilainen

Post by Raymund Hofmann
The reason on SE it was rejected seems weak for me.

That hardly matters when two thirds of the committee opposed the proposal.

Changes happen all the time.

Post by Ville Voutilainen

Post by Raymund Hofmann
The default is decltype(x) and you could prepend a &, &&, const or

whatever could be validly followed by auto.

Post by Raymund Hofmann
for(&e:...)
[](const&e,i){...
auto m(&f)->...

The auto is not redundant in function declarations, because a function
parameter can be declared without a name.

Then it is optional.

Furthermore, with auto-type parameters, the auto keyword is the only

Post by Ville Voutilainen
thing that tells you the function is
a template, and there's ample evidence that having such a syntactic
marker is something that large swaths
of the committee will insist having.

A missing type doesn't tell you it is a template? Ok, it conflicts with
type only parameters of function declarations, but not for lambdas and in
class defined functions where type and name are required.
And these are the places having terse syntax options benefits the most.

Post by Ville Voutilainen
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUao5SP_rA5Wx87e9XyfmC4j0Zv%3Dmf7rs24Z5KU5CzEa2Q%40mail.gmail.com
.

[Ville Voutilainen]

Post by Raymund Hofmann

Post by Ville Voutilainen

Post by Raymund Hofmann
The default is decltype(x) and you could prepend a &, &&, const or whatever could be validly followed by auto.
for(&e:...)
[](const&e,i){...
auto m(&f)->...

The auto is not redundant in function declarations, because a function
parameter can be declared without a name.

Then it is optional.

The name is, yes. The type is not.

Post by Raymund Hofmann

Post by Ville Voutilainen
Furthermore, with auto-type parameters, the auto keyword is the only
thing that tells you the function is
a template, and there's ample evidence that having such a syntactic
marker is something that large swaths
of the committee will insist having.

A missing type doesn't tell you it is a template?

Indeed it doesn't, because now you have to separately look up whether
the identifier is a type or not.

Post by Raymund Hofmann
Ok, it conflicts with type only parameters of function declarations, but not for lambdas and in class defined functions where type and name are required.

I don't know what "type and name are required" means there, because
the name is not required.
We did discuss the possibility of leaving out the type in lambdas in
2012, and rejected that idea.

[Raymund Hofmann]

Post by Raymund Hofmann

Post by Raymund Hofmann

Post by Ville Voutilainen

Post by Raymund Hofmann
The default is decltype(x) and you could prepend a &, &&, const or

whatever could be validly followed by auto.

Post by Raymund Hofmann

Post by Ville Voutilainen

Post by Raymund Hofmann
for(&e:...)
[](const&e,i){...
auto m(&f)->...

The auto is not redundant in function declarations, because a function
parameter can be declared without a name.

Then it is optional.

The name is, yes. The type is not.

In cases where the name and type is required, the auto is optional. And
these are the most beneficial cases like lambda arguments, in class defined
member functions and constructors.

Post by Raymund Hofmann

Post by Raymund Hofmann

Post by Ville Voutilainen
Furthermore, with auto-type parameters, the auto keyword is the only
thing that tells you the function is
a template, and there's ample evidence that having such a syntactic
marker is something that large swaths
of the committee will insist having.

A missing type doesn't tell you it is a template?

Indeed it doesn't, because now you have to separately look up whether
the identifier is a type or not.

If you know that the parameter list in question is one requiring type and
name it is clear. Either type & name or "optional auto" and name.
This affords you to check if it is a function declaration or definition in
the member function / constructor case, a rather simple context check.
For lambda's it is clear, it will only improve readability.

Anyway, editors/IDE's could do the "optional auto" by displaying the code
appropriately, so the language could carry it's redundancy without lowering
readability, but still some kind of standard (a TS?) how the IDE's do it
would be good, otherwise most people will shy away from using it.

This is where most improvements in DRY, productivity, readability,
browseability and such could happen in the future anyway.

[Ville Voutilainen]

Post by Raymund Hofmann

Post by Ville Voutilainen

Post by Raymund Hofmann

Post by Ville Voutilainen

Post by Raymund Hofmann
for(&e:...)
[](const&e,i){...
auto m(&f)->...

The auto is not redundant in function declarations, because a function
parameter can be declared without a name.

Then it is optional.

The name is, yes. The type is not.

In cases where the name and type is required, the auto is optional.

I wrote 'I don't know what "type and name are required" means there, because
the name is not required.' I still don't know what you're talking
about when you say "in cases where the name and type is required".
As far as I know, such cases do not exist.

Post by Raymund Hofmann
Anyway, editors/IDE's could do the "optional auto" by displaying the code appropriately

Such suggestions of tools showing the context haven't been convincing
before, so I doubt they would be convincing now.

[Raymund Hofmann]

On Thu, Nov 29, 2018 at 12:38 PM Ville Voutilainen <

Post by Ville Voutilainen

Post by Raymund Hofmann
In cases where the name and type is required, the auto is optional.

I wrote 'I don't know what "type and name are required" means there, because
the name is not required.' I still don't know what you're talking
about when you say "in cases where the name and type is required".
As far as I know, such cases do not exist.

I thought you could only declare function parameters with a optional name,
but not define them, but you can.

Still you could apply the rule if what can not be found as a type in a
parameter declaration becomes a "optional auto" name.
Not good style to have parameter names matching user-defined type names,
anyway.

If there are unexpected ambiguities (libraries, headers, metaprogramming,
large teams), you could have a optional warning that you got the backward
compatible default which is a type name.

And new code should give a specific error on that case as soon as what is
recognized as a default parameter type is used as a instance name in the
function body, it gives a unspecific error now, it is not valid code.

void f(user_t)
{
user_t.a=1; // <-error because user_t is a known type, did not define a
parameter
g(user_t); // <-error because user_t is a known type, did not define a
parameter
}

You still could do:

void f(user_t user_t)
{
user_t.a=1;
g(user_t);
}

You could question it somewhat for functions because of that, but less for
lambda's and the range for.

This then of course depends on a lot of context to know if it is a type or
parameter name, but in times post syntax highlighting with
code-editors/IDE's it becomes viable.
And not that we are not used to overwhelming context since heavy template
use..

Post by Ville Voutilainen
Such suggestions of tools showing the context haven't been convincing
before, so I doubt they would be convincing now.

Tooling is slowly moving there anyway.
Even in MSVC you now can automatically create a member function declaration
from it's definition and some more.

There are so many more tedious, error prone common tasks that you could
automate and check with tooling.

[Balog Pal]

2018. november 28., szerda 4:19:32 UTC+1 időpontban Ville Voutilainen a

Post by Ville Voutilainen

Post by Raymund Hofmann
The reason on SE it was rejected seems weak for me.

That hardly matters when two thirds of the committee opposed the proposal.

Can you reproduce the problem example? The minutes only mention one was
presented, and that some suggestions floating around -- then the poll went
as massively against.

It's really hard to tell whether the reason is weak or strong with the key
info missing.

[Gareth Lloyd]

Post by Raymund Hofmann
The reason on SE it was rejected seems weak for me.

for ( for-range-declaration : for-range-initializer ) statement

for-range-declaration:
attribute-specifier-seq opt decl-specifier-seq declarator
attribute-specifier-seq opt decl-specifier-seq ref-qualifier opt [
identifier-list ]

IMO it would be unreasonable to change the grammar here. Stuff like
attribute-specifier-seq are fine to make optional because they are easily
identified by the next characters ''[[" or "alignas(", those can not be
confused with decl-specifier-seq. decl-specifier-seq should not be optional
it takes more lookahead or backtracking to figure out if decl-specifier-seq
was provided or not. This is not just an issue for your compiler but any
IDE language support.

['Thomas Köppe' via ISO C++ Standard - Future Proposals]

An optional "auto" would allow the following interesting code:

*int x = 10;*

*for (x : {1, 2, 3}) {} *



Does this assign to the outer "x" or declare a new, inner "x" via implicit
"auto x : ..." that shadows the outer one?

I think shadowing concerns were also among the criticisms of N3853. You can
imagine similar situations, e.g.:

*int x = 10;*
*{*
* x = 20; // assignment or implicit "auto x = 20;"?*
*}*


Whatever answer you come up with, you should consider how you explain that
to users, how you teach it to beginners, and how it affects code review
(where you potentially only see a single line of diff without context).

[Raymund Hofmann]

How is shadowing different in your examples to if there would be a type or
auto?
As i said, treat it like if there would be a imaginary auto. Seems quite
simple to me.

And with type we may get warnings and without we could too.

BTW gcc gives no shadowing warnings by default in the 2 cases with type.
It is because most intend to shadow in these cases, i think.

[Raymund Hofmann]

And for variable declarations the optional auto is indeed questionable for
function sub-blocks, so it could only be for the top function block or
better not at all.

In class defined member functions and esp. lambda's would benefit from
optional auto in their parameter list.

Even constructors could use some kind of this to improve DRY when
initializing members.

struct a : b
{
int i;
const std::string s;
struct {double d, const char *c} aa;
a(i,s,aa,b,int n) {i+=n;}
}

It means when no type and the names match imply a member initializer list
":i(i), s(s), aa(aa),b(b)"

Post by Raymund Hofmann
How is shadowing different in your examples to if there would be a type or
auto?
As i said, treat it like if there would be a imaginary auto. Seems quite
simple to me.
And with type we may get warnings and without we could too.
BTW gcc gives no shadowing warnings by default in the 2 cases with type.
It is because most intend to shadow in these cases, i think.