Unused Pattern Bindings (Unused Function Parameters) #2022
Conversation
matthew-russo
force-pushed
the
proposal-optional-argument-na
branch
from
49fd1ad to
5e2b309
Compare
matthew-russo
changed the title
matthew-russo
force-pushed
the
proposal-optional-argument-na
branch
4 times, most recently
from
eb518d5 to
966746a
Compare
|
I framed this around patterns more generally based on the discussion in #476. If this should only talk about function parameters, let me know and I'll adjust the wording |
There was a problem hiding this comment.
Thank you! This proposal looks pretty good to me. There are just a couple aspects I see which I think it may be helpful to provide info on (or specifically mark as open questions not resolved here, so that people don't accidentally read this as resolving them).
matthew-russo
force-pushed
the
proposal-optional-argument-na
branch
from
966746a to
8737e61
Compare
|
Sorry for the delay in updating this. I've pushed some small changes that cover the areas you suggested -- they're very high level, let me know if I need to go in to more detail on context or the why behind them and I can spend a bit more time with it. |
jonmeow
added
proposal
|
I see this had been missing proposal labels -- I've added those to help make sure it's getting reviewed as such (leads have been busy but I think there'll be increased availability now) |
matthew-russo
force-pushed
the
proposal-optional-argument-na
branch
from
8737e61 to
479c79f
Compare
|
Looks good to me, noting outstanding comments. Just a tip regarding force-pushes though -- those can break GitHub's comment associations, and it makes it harder to determine what's changed since the last review (with regular pushes, GitHub can show a delta). We're going to squash-and-merge PRs anyways, so if you use regular pushes the end result will actually be the same and it can make it easier to review. :) |
Whoops sorry about that -- will adjust going forward |
| The inclusion of two syntaxes allows authors to decide when they will favor | ||
| conciseness or explicitness over the other. | ||
|
|
||
| ## Alternatives considered |
There was a problem hiding this comment.
Good call, suggested more specific wording below.
Co-authored-by: Geoff Romer <gromer@google.com>
… for semantic meaning is disadvantageous
Includes the advice from #2022 (comment) Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
There was a problem hiding this comment.
Approving on behalf of carbon leads. Thank you!
One concern during leads discussion was how often unused is used as an identifier in C++ code. We investigated and found that most uses would actually be either _ or unused foo: ... in Carbon, and there were few enough remaining cases that we were OK with taking unused as a keyword.
zygoloid
added
proposal accepted
This proposal specifies how unused pattern bindings are written in the Carbon programming language. This is a more general problem statement of "how do users specify unused function parameters" as function parameter declarations are a more specific form of pattern
Related issue #1996