Disable parsing of type ascription in beta and stable

[estebank]

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

[durka]

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 #![feature(type_ascription)]"?

Second thought: would this affect macros? When type ascription was implemented it changed the meaning of macros such as ($e:expr) => {}; ($n:ident : $t:ty) => {}. This sounds like it might end up changing that back, on stable/beta?

So this seems like maybe a good idea to improve error messages but would have to be done really carefully.

[nikomatsakis]

I'm kind of tempted to just rip out type ascription, maybe try again some other time.

[eddyb]

GitHub needs 😞/😭 reactions.

[nikomatsakis]

I confess I've never really wanted it though =) I'm happy to be persuaded to keep it...

[durka]

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> .

[estebank]

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.

[nikomatsakis]

I mean it went through the RFC process, seems weird to simply drop it without another one.

(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.)

[nikomatsakis]

@estebank

Due to its syntax, this feature can cause some confusing error messages.

Can you elaborate on these? I think that'd be useful information for the feature stabilization process in general.

[cramertj]

@nikomatsakis This is the one I see all the time:

error: type ascription is experimental (see issue #23416)
 --> src/main.rs:2:13
  |
2 |     let _ = Box:new();
  |             ^^^^^^^^^

[estebank]

@nikomatsakis a few other that I've seen recently:

#39126
#37509
#34255
#47360

[nikomatsakis]

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.