De-RFC: Remove type ascription by Manishearth · Pull Request #3307 · rust-lang/r...
source link: https://github.com/rust-lang/rfcs/pull/3307
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Conversation
From the community that brought you the Pre-RFC and the e-RFC, we now introduce: the de-RFC!
Type ascription (RFC #803, tracking issue) has been a merged RFC for seven years, with no clear path to stabilization. Since then, syntactic norms in Rust have shifted significantly and it's becoming increasingly unlikely that this RFC if posted would have landed today. During this time the nightly support for this feature has impacted the quality of parser diagnostics; creating a large black hole of potential mistakes that lead to a suggestion around ascription (a feature most cannot use) when there could have been a more targeted and accurate diagnostic.
This RFC intends to advocate for the feature being removed entirely (or at least moving the implementation to a less prime area of the syntactic space) with a fresh RFC being necessary to add it again (which this RFC encourages the community to do!)
(While I've taken some ... liberties with the RFC template here; it is not a joke; it's a serious attempt to give us a clean slate when it comes to this feature.)
added the T-lang Relevant to the language subteam, which will review and decide on the RFC. label
Contributor
jhpratt commented 11 days ago
ELI5 reference-level obfuscation? |
added the I-lang-nominated Indicates that an issue has been nominated for prioritizing at the next lang team meeting. label
Member
joshtriplett commented 11 days ago
LGTM; nominating for lang team consideration in our next meeting. |
steffahn commented 11 days ago •
That feels like a fun parsing exercise in case we’d want to make this support things like
(TBH, Sorry, this comment is mostly off-topic presumably, but I didn’t know a good other place to post it. |
Since this is a removal of a feature proposed by an existing RFC, as a joke all of the section names are reversed from what they are in the RFC Template. One of the template sections is "Reference level explanation", so this De-RFC has a "Reference level obfuscation". The content of that section is a screenshot of a summary of the diff that would result from removing type ascription from the reference; 276,000 lines deleted from the reference. That feels high to me, so I believe the screenshot is a joke as well, simply indicating "this will allow us to delete a lot of things from the reference." |
CAD97 left a comment •
I'm a +1 on eventually fully removing ascription syntax from the compiler.
As a member of wg-grammar, but speaking for myself, there's as I recall nothing formally blocking about : Type
syntax, but it fails the "syntactic redundancy" and clarity rules that provide for strong parser recovery, because while type ascription is not in and of itself ambiguous, it is highly "typo-ambiguous".
HOWEVER, there is a wrinkle that will make removing ascription more difficult: the syntax is accidentally syntax-stable. rust-lang/rust#99935 just recently managed to enable warnings for the use of type ascription. Actual removal will need to go through a few cycles of upgrading the warning for type ascription to deny-by-default and future-compat-report.
- `.is::<Type>` |
||
- `.<Type>` |
||
- `.::<Type>` |
||
- `.become::<Type>` (already reserved! credit @mystor) |
This comment has been minimized.
Given that as
is already a keyword, .as(Type)
and .as<Type>
are available syntactic space (arguments about operators looking like function calls notwithstanding).
Member
Author
Manishearth commented 11 days ago
@lambda the screenshot was supposed to be for the compiler, as a joke about the number of diagnostics hacks we can remove guide/reference level don't quite make sense for this RFC so I had fun with it |
Contributor
jhpratt commented 11 days ago
I figured it had something to do with the diff if this was removed, but it's also obviously not an actual diff count. No issue keeping a joke in, just wasn't certain if it was to be taken seriously for whatever reason. |
CAD97 commented 10 days ago •
I'm not super familiar with the future compat lint mechanism, but I did just recently implement syntax warnings for type ascription (among other unstable syntax). As such, I made a potential patch for pulling type ascription into its own warning: rust-lang/[email protected]:deny-type-ascription This is made extra interesting by the fact this is being done in rustc_session::parse before we have access to the normal rustc_middle lint infrastructure. This should prove that the migration lint is feasible, though. |
Member
joshtriplett commented 10 days ago
I would propose that this thread should avoid speculations on what the syntax should be if this is added back. @Manishearth, you might consider adding an explicit note in that section disclaiming the speculation as non-normative for the RFC; that's already normally the case but I think this de-RFC might be more than usually prone to such bikeshedding. |
Member
Author
Manishearth commented 10 days ago
@joshtriplett done. |
Contributor
clarfonthey commented 10 days ago
Back when it was first proposed, I really loved type ascriptions and tried to use them despite the weird errors. Back then, type inference also wasn't nearly as good as it is now, and such a feature was more useful. Nowadays I find very few uses that can't be done via turbofish and aren't unreasonable to do via separate bindings, since something that is sufficiently complex to need those ascriptions is probably sufficiently complex to factor into a separate binding anyway. I think that we shouldn't really be looking for alternative syntax for generic type ascription and instead really take a hard look at what problems it's trying to solve, and what problems are left in a state where they're vest solved by type ascription. This also means keeping in mind that |
Process question: for a De-RFC, would it make sense to also include a link at the top of the original RFC? Or would it just be discoverable from that RFC by visiting its tracking issue? |
Member
Author
Manishearth commented 9 days ago
Probably the latter: we typically do not edit RFCs after the fact. But I wouldn't be opposed. |
Member
joshtriplett commented 9 days ago
@Manishearth We have edited some RFCs to indicate that they were withdrawn or similar. We should do the same here. |
Member
joshtriplett commented 9 days ago
We discussed this in today's @rust-lang/lang meeting. Several of us want type ascription in some form, but not in this form, and there seemed to be general consensus that we should remove this syntax and require a new RFC. @rfcbot merge |
rfcbot commented 9 days ago •
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it.
labels
Given that Rust sacrificed "colon introduces a type" to keep struct initializers and struct definitions the same, I think that That said, I can't refute that this has been around for a long time and hasn't been making progress, so
I think putting a note at the top of the other RFC makes sense. We did that in https://rust-lang.github.io/rfcs/2203-const-repeat-expr.html, as an example. We generally don't edit the body, but adding a kind of "historical note" is reasonable.
I'd love to see ascription on bindings in patterns. Here's an old Zulip thread about it, if anyone gets inspired: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/type.20ascription.20*in.20patterns*/near/213985025 Of course, that does hit the "colon used for a value" mistake again, since a |
Member
Author
Manishearth commented 9 days ago
Yeah, though " |
added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised.
and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period.
labels
rfcbot commented 8 days ago
This is now entering its final comment period, as per the review above. |
Contributor
estebank commented 7 days ago
Interestingly enough,
|
Member
scottmcm commented 7 days ago
Well, we can have it on bindings too, it's just stuck with being And that at least works nicely on tuple-structs, as |
Member
mark-i-m commented 6 days ago
To clarify, this does not remove type ascription in already-stable places, right? For example:
|
Contributor
jhpratt commented 6 days ago
Yes, this only removes type ascription on expressions. |
May also be worth noting that there was previously a postponed RFC talked about some related things (could be a future reference). |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
No one assigned
None yet
No milestone
Successfully merging this pull request may close these issues.
None yet
Recommend
-
9
Collaborator rust-log-analyzer commented
-
12
Collaborator camsteffen ...
-
9
Copy link Member Manishearth commen...
-
8
Copy link Member Manishearth...
-
9
New issue Detect bare blocks with type ascription that were meant to be a struct literal #88598
-
5
New issue Handle intra-doc links in doc_markdown #7772
-
5
Copy link Collaborator
-
14
Member
-
8
Remove streaming replication implementation #411 Merged ...
-
5
Remove now deprecated target x86_64-sun-solaris. #118091
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK