-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Tracking issue for RFC 2113: dyn Trait
Syntax for Trait Objects: Take 2
#44662
Comments
A lot of the interesting question marks here arise around backwards compatibility. Here are some observations:
It turns out that we already have support for "paths that must be trait objects" in the AST, which is almost exactly what we need. This is the We can use this same AST variant to support So probably the initial work items are something like this:
At this point, we should be able to use
After this point, we need to start thinking about the transition. Hopefully by then more of the epoch machinery is in place. |
This can be a parser-only change - " Additionally, |
@petrochenkov ah, nice, I forgot about that! I will update the mentoring instructions accordingly (or feel free to do so yourself...). |
I'm interested in tackling this :) |
@petrochenkov I updated the mentoring instructions. I left one "TODO" in there that maybe you can fill-in. -- @tomhoule great! let me or @petrochenkov know if anything is unclear from the mentoring instructions. If you're not getting any response, I will warn you that I at least have a hard time keeping up with notifications, so a ping on gitter may be faster. =) (Also, others in that room can likely help.) |
Also, we really should resolve the precedence of impl trait, which is directly relevant here. Not sure what's the best way to force that question. cc @rust-lang/lang |
I think I made my peace with the existing rules, i.e. bounds being parsed greedily after |
I still find it hard to square that into an actual grammar. In particular, something like this parses: fn foo<F>(f: F)
where F: Fn() -> Foo + Send
{ } parses as It's times like these that I wish we had made more progress on a formal grammar! I think there are some projects that have done so, though, so we could maybe get some sense for how awful it is. (Now, perhaps it was ill-advised to make the grammar work the way it does with |
@tomhoule just checking in -- any progress? Any questions I can help with? (BTW, with respect to the open question about the precedence of |
Since it's my first attempt at working on the compiler I'm taking off slowly, I haven't got much further than setting things up and making sure I completely understand the RFC. I expect I'll have more time this week to start actually writing code and come back to you with questions. Thanks for the clarification on precedence :) |
@tomhoule are you still working on this? |
Yes, I've made some progress and currently working on the parsing part and starting to write tests. I'll work on it more over the week-end and make sure to open a PR or report back here if it doesn't look doable by monday at the latest :) |
@gaurikholkar It doesn't look like I'll be able to finish this today, and I won't have free time before next week-end so you or someone else should feel free to take the issue. Sorry for delaying this feature :/ |
Implemented in #45175 |
Implement `dyn Trait` syntax (RFC 2113) cc #44662 r? @nikomatsakis
The box for the lint at the top of this thread is checked, but I can't seem to get the |
@cramertj adding |
The lint is opt in basically |
Has anyone pointed out how this seems somewhat flipped? Shouldn't it be EDIT: OTOH, this is only because of the use of verbs like |
We need to make sure that we handle I have a suggestion for the Rust 2018 side of this, that's maybe a bit late: @rust-lang/lang What do you think? |
I like the explicitness of |
With respect to @eddyb's comment:
|
@eddyb I don't think Maybe start an IRLO thread or RFC issue to discuss it? I'm not convinced here is the best place. |
As long as |
Note, that |
@petrochenkov Huh, I have assumed that it spanned all bounds, oops! |
I've marked this as due for RC2; I think we need to make Optionally, if it turns out to not be used anywhere (pending crater run), we can also make |
Me and @eddyb discussed this briefly on Discord. While there is a single root crate that uses this, https://crates.io/crates/goblin -- we have done 2018-only keywords for 3 other words (async, try, await), so it makes sense to do this for So... @rfcbot poll lang Can we make |
Team member @Centril has asked teams: T-lang, for consensus on:
|
AIUI the language team made a decision on this specific point months ago: https://paper.dropbox.com/doc/Keyword-policy--AM1CL55t0gF_Zoh7VeYN~HXSAg-SmIMziXBzoQOEQmRgjJPm Maybe the circumstances have changed? Back then we didn't have the implementation clarity on keyword edition hygiene we do now. Worth explicitly mentioning what has changed since then. |
@Manishearth see discussion about While we wouldn't, strictly speaking, need to make On sourcegraph I found one crate making actual use of |
IIRC the way contextual keywords are implemented makes this not necessarily
easy to do, at least this was the case in March. So I'm not sure if "short
on time" is valid here. In March one of the concerns was implementation
complexity and it's not clear to me that has changed.
The breakage is very likely small, yeah, but is it something we can easily
implement?
…On Sat, Sep 15, 2018, 10:32 PM Mazdak Farrokhzad ***@***.***> wrote:
@Manishearth <https://github.com/Manishearth> see discussion about dyn<'a>
above.
While we wouldn't, strictly speaking, need to make dyn a real keyword to
enable where dyn<'a> Fn(&'a T) -> &'a U, it is much simpler to make it a
real keyword in 2018 to handle that. (also because we are short on time...).
On sourcegraph I found one actual use of dyn as an identifier, so the
breakage is extremely small (much smaller than try and friends...). If we
wish to revert this after Rust 2018, we can do that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#44662 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABivSHNAxi5YUqAm0ceq_SLJ6shn7Rgeks5ubTKsgaJpZM4PaRse>
.
|
What exactly, making |
@varkor is looking into this :) |
We discussed this on this weeks lang team meeting and the general consensus seemed to be that given that we now have a good mechanism to make this a real keyword, we should do so given the added motivation. |
…nkov Make `dyn` a keyword in the 2018 edition Proposed in rust-lang#44662 (comment).
…nkov Make `dyn` a keyword in the 2018 edition Proposed in rust-lang#44662 (comment).
I went through the boxes and looks like it's fully done now. |
This is a tracking issue for the RFC "
dyn Trait
Syntax for Trait Objects: Take 2 " (rust-lang/rfcs#2113).Implementation plan:
dyn Foo
but we parsedyn ::Foo
asdyn::Foo
dyn
as an identifierdyn
only as adyn Trait
, and hencedyn ::Foo
Trait
todyn Trait
; if the pathTrait
is absolute (::Trait
), then we suggestdyn (::Trait)
#[warn(rust_2018_idioms)]
(Tracking issue for warning for rust_2018_idioms by default #54910)dyn Trait
in error messages (usedyn
syntax in error messages #49277)Steps to stabilize:
dyn
Trait (RFC 2113) reference#279) (see instructions on forge)The text was updated successfully, but these errors were encountered: