-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Disable parsing of type ascription in beta and stable #48016
Comments
First thought: this sounds like it might lead to odd behavior on nightly. Generally, nightly behaves the same as stable/beta unless you turn on a feature flag (and if you do something that is gated it tells you which feature flag to use). If nightly parses type ascription but gates it (current behavior), while stable/beta don't parse it at all, that's a behavior difference with no feature flag. But if nightly-without-feature-flag doesn't parse the syntax, there's no way to discover the flag. Maybe you'd have to run the parser in both modes, and say "warning: this parses differently with Second thought: would this affect macros? When type ascription was implemented it changed the meaning of macros such as So this seems like maybe a good idea to improve error messages but would have to be done really carefully. |
I'm kind of tempted to just rip out type ascription, maybe try again some other time. |
GitHub needs 😞/😭 reactions. |
I confess I've never really wanted it though =) I'm happy to be persuaded to keep it... |
I mean it went through the RFC process, seems weird to simply drop it
without another one. But it was never fully implemented (i.e. to do
coercions) AFAIK.
…On Mon, Feb 5, 2018 at 12:56 PM, Niko Matsakis ***@***.***> wrote:
I confess I've never really *wanted* it though =) I'm happy to be
persuaded to keep it...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#48016 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAC3n5jqnFzBj4eaBvOcwGyfwqCs9wlfks5tR0C2gaJpZM4R5xV5>
.
|
It is not my intention to completely rip out the feature, but rather to acknowledge that the feature has introduced difficulty to learn the language an significantly bad in such a way that is not actionable for stable/beta users. If the syntax is ever to be stabilized, the learnability and diagnostic problems will need to be addressed, but as it stands now, I feel there are better places to focus on. As for @durka's comments, they are very valid points. |
(I didn't mean we would drop it without some sort of FCP. In part, I am interested in culling "minor" features that have niggling issues that don't seem worth resolving at the moment.) |
Can you elaborate on these? I think that'd be useful information for the feature stabilization process in general. |
@nikomatsakis This is the one I see all the time:
|
@nikomatsakis a few other that I've seen recently: |
Thanks! A middle ground, I suppose, would be to generate a better error, right? That might be a pain to do in this case though. |
The only reason I'm proposing this is due to the multiple places these errors pop up in that need to be handled. Then again, at some point it'll have to be dealt with. The reasoning behind this proposal is that in the meantime stable users instantly get better errors while we improve them in nightly (and added beta just to make sure we had an option to catch regressions that wouldn't come up in nightly due to having different behavior to stable). |
@estebank started a thread on internals.rust-lang.org asking for compiler error pet peeves, and I'd just like to mention that the issue being discussed here is one of mine, especially as I just ran into it again today and was scratching my head for a few minutes. As a minimal example for what I just ran into:
I get three errors, two of which mention type ascription. I just wanted to lend my support to cleaning up the compiler messages in this situation. |
cc @rust-lang/lang -- it's worth trying to get some consensus around type ascription. I think that some of us at least regard type ascription as a kind of "not worth it" feature, at least with its current syntax, that introduces a variety of complications for relatively little gain. |
@nikomatsakis I'd be +1 for removing it if it helps us give better error messages. If the feature ever stabilizes, it certainly won't be soon, so IMO it's not worth additional effort to keep dragging it along. |
I'm strongly in favour of keeping and stabilising type ascription (although there is the open question about coercions, which has blocked stabilisation). I'm still in favour of landing this PR - seems like it is a win to not tell users about something they can't use. Reasons I like type ascription:
To head off discussion on the syntax, using a colon is pretty much perfect for type ascription since we use it for type declarations (and it is used for type ascription in other languages). I actually get sad in the opposite direction: when we use colons for anything other than indicating type (or bounds), e.g., I regard using colons for field initialisation as one of our larger syntactic blunders and I'm sad we couldn't change that pre-1.0. |
A post about a case where "the way to go is to replace casts with coercions", which might be another case for ascription: #46906 (comment) Given that I want to kill |
Heh, I just hit this error and it confused me for a good 5 minutes (I had |
In general, I am still vaguely against the current type ascription syntax. I agree that
Nonetheless I agree with @nrc's motivations, though I am less negative about turbofish than he is (and I sort of would prefr that if we hate it so much that we solve it more directly, though maybe there's no hope). I wonder about repurposing
with the semantics of it being always an rvalue, thus side-stepping the coercion soundness problems. So Maybe it's confusing that |
(also, given that fn cast<T>(x: T) -> T { x } it seems sort of silly to bake it in the language. Though I do wonder if we could replace type ascripton with putting that function into the prelude.) |
That function has other uses as well. |
And there's rust-lang/rfcs#2306 to add it as I do like that a name related to type ascription gives it more of an obvious purpose, since my first reaction to seeing |
That doesn't actually solve the problem though unless we allow every cast
as an implicit coercion, and I don't think that's desirable...
…On Fri, Mar 9, 2018 at 3:28 PM, scottmcm ***@***.***> wrote:
And there's rust-lang/rfcs#2306
<rust-lang/rfcs#2306> to add it as
convert::identity
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48016 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAC3n99tMpHpsqIWdgmLY22AKBbtzIndks5tcuXqgaJpZM4R5xV5>
.
|
@durka I'm hoping we get to the world where anything that's not a coercion is accessible through a method or function with clearer semantics. For example, |
I believe that #59150 covers a lot of ground of what disabling was meant to accomplish, although there are still cases where errors are not great, namely the following three:
|
Expand suggestions for type ascription parse errors Fix rust-lang#51222. CC rust-lang#48016, rust-lang#47666, rust-lang#54516, rust-lang#34255.
Expand suggestions for type ascription parse errors Fix rust-lang#51222. CC rust-lang#48016, rust-lang#47666, rust-lang#54516, rust-lang#34255.
Expand suggestions for type ascription parse errors Fix rust-lang#51222. CC rust-lang#48016, rust-lang#47666, rust-lang#54516, rust-lang#34255.
Now with #62791 the only two cases left are the last two in the previous comment. Those are tracked in #47666 and #34255 respectively. For the macro one a fix will require carrying state around from the |
…enkov Handle more cases of typos misinterpreted as type ascription Fix rust-lang#60933, rust-lang#54516. CC rust-lang#47666, rust-lang#34255, rust-lang#48016.
…enkov Handle more cases of typos misinterpreted as type ascription Fix rust-lang#60933, rust-lang#54516. CC rust-lang#47666, rust-lang#34255, rust-lang#48016.
Type ascription is a nightly only feature. Due to its syntax, this feature can cause some confusing error messages. Some of these have been handled by checking against typos (like when meaning
;
), but given that the feature is only available in nightly, I think we should gate the feature at the parser level as well, so that error messages do not even mention type ascription. The big draw backs of doing this is that once the feature gets stabilized it won't have good diagnostics as it would otherwise have (because they'd only be shown in nightly, so we'd have fewer bug reports about it) and if somebody tries to use a nightly only crate that uses type ascriptions, the compiler would complain about syntax errors, instead of the feature being nightly only.Having said that, there might be a middle point, where the feature is still being probed for diagnostic purposes, but never actually parsed on its entirety. At the same time, as pointed above, it probably would be worth to instead improve the diagnostics involving type ascription. If that is the decision, this issue can be closed.
cc @rust-lang/compiler
The text was updated successfully, but these errors were encountered: