-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
:!
generic syntax
#676
:!
generic syntax
#676
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fine to me.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this. FWIW, I think this summary is really great. This was a complex issue with a lot of discussion. I think this does a great job of pulling together a good overview of the thinking that went into the decision.
The change LGTM, but we should get at least one more thumbs up here before landing.
Is this proposal intended to be an RFC? It's currently categorized as draft. |
Yes, it is an RFC. It appears there are two independent ways it can be marked as a draft? @jonmeow |
Kind of, but switching project columns is the only one that really works. Switching project columns should also take care of the rest. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM given zygoloid/chandlerc are okay, but I'll note I don't understand the indicated alternative.
proposals/p0676.md
Outdated
#### Square brackets | ||
|
||
Using `[`...`]` consistently for generics creates the opposite problem of the | ||
brackets being inconsistent with the deduced or explicit distinction. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm the only one confused by this, but aren't you using square brackets for the proposal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Square brackets are only used to indicate "deduced" in the proposal. Generics are indicated using :!
. A generic parameter can be in the deduced list or in the regular (...)
explicit parameter list. For now, the only example we have of non-generic deduced parameters is me: Self
, but eventually we will probably have more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But what was this alternative? Can you give an example of what was considered?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chandlerc Can you recall what was actually considered? I could potentially just delete this little bit if it doesn't match what you actually discussed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I think I found the example in the discussion notes, I'll add it to the doc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote down the example, but it may have fallen under "We never really broke out of the idea that [
...]
were for deduced parameters" and wasn't actually considered. Perhaps I should include something in the "alternatives not considered" about figuring out which parameters are deduced the same way C++ does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The example matches my memory -- this was exactly parallel to <>
s and didn't try to get to a consistent story. I think what you have here is right, and the "not considered" thing at the bottom already captures well the space we didn't spend time exploring.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM given the thumbs up and some time today for folks to look.
If there is a useful clarification for the open comment, can incorporate that or make a follow-up PR -- I'm pretty happy.
var to: Vector[i64] = CastAVector[i64](from); | ||
``` | ||
|
||
One concern is that use of square brackets will be in the same contexts as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zygoloid Could you remind me of your other concern about this option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other concern was that we might want to put generic / template parameters in the (
...)
list. Motivation for this can be found here: http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1045r1.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added.
This implements decision #565 to use
T:! Type
to declare generic parameters, andtemplate T:! Type
for template parameters.