auto keyword for vars #851
Conversation
github-actions
bot
added
the
proposal rfc
There was a problem hiding this comment.
Sorry that this proposal got largely missed and not promptly reviewed.
I generally like the direction here. I've left one comment, but its pretty minor. I do want to check that the @carbon-language/carbon-leads don't want to see anything else here before moving forward or don't have any concerns.
| Disadvantages: | ||
|
|
||
| - Type inference becomes the _lack_ of a type, rather than the presence of | ||
| something different. | ||
| - C++'s syntax legacy may have needed `auto` in order to provide type | ||
| inference, where Carbon does not. |
There was a problem hiding this comment.
I think it'd be good to also capture that this creates the potential for ambiguity with expression patterns as well. There are possible ways of addressing that ambiguity (some of which you get into in the background section), but I feel like its still an important consideration in the tradeoff here. @zygoloid might even be able to suggest something here.
There was a problem hiding this comment.
Added a bullet for that, linking the background.
There was a problem hiding this comment.
Mid-air collision between your update and my suggestion. Here's what I'd written up (which looks similar enough to your new bullet):
| Disadvantages: | |
| - Type inference becomes the _lack_ of a type, rather than the presence of | |
| something different. | |
| - C++'s syntax legacy may have needed `auto` in order to provide type | |
| inference, where Carbon does not. | |
| Disadvantages: | |
| - Type inference becomes the _lack_ of a type, rather than the presence of | |
| something different. | |
| - C++'s syntax legacy may have needed `auto` in order to provide type | |
| inference, where Carbon does not. | |
| - Removes syntactic distinction between binding of a new name and reference | |
| to an existing name. Reintroducing this distinction would likely require | |
| additional syntax, such as Swift's nested `let`. |
There was a problem hiding this comment.
Noting here -- replaced mine with @zygoloid's
| Disadvantages: | ||
|
|
||
| - Type inference becomes the _lack_ of a type, rather than the presence of | ||
| something different. | ||
| - C++'s syntax legacy may have needed `auto` in order to provide type | ||
| inference, where Carbon does not. |
There was a problem hiding this comment.
Mid-air collision between your update and my suggestion. Here's what I'd written up (which looks similar enough to your new bullet):
| Disadvantages: | |
| - Type inference becomes the _lack_ of a type, rather than the presence of | |
| something different. | |
| - C++'s syntax legacy may have needed `auto` in order to provide type | |
| inference, where Carbon does not. | |
| Disadvantages: | |
| - Type inference becomes the _lack_ of a type, rather than the presence of | |
| something different. | |
| - C++'s syntax legacy may have needed `auto` in order to provide type | |
| inference, where Carbon does not. | |
| - Removes syntactic distinction between binding of a new name and reference | |
| to an existing name. Reintroducing this distinction would likely require | |
| additional syntax, such as Swift's nested `let`. |
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
github-actions
bot
added
proposal accepted
Allow `var <identifier>: auto = <expression>;` syntax. Co-authored-by: Richard Smith <richard@metafoo.co.uk> Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Allow
var <identifier>: auto = <expression>;syntax.