Skip to content
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 De-RFC 3307: Remove type ascription #101728

Open
2 of 7 tasks
Manishearth opened this issue Sep 12, 2022 · 7 comments
Open
2 of 7 tasks

Tracking Issue for De-RFC 3307: Remove type ascription #101728

Manishearth opened this issue Sep 12, 2022 · 7 comments
Assignees
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-type_ascription `#![feature(type_ascription)]` S-tracking-remove-implementation Status: The feature needs to be removed from the Rust toolchain before this issue can be closed T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@Manishearth
Copy link
Member

Manishearth commented Sep 12, 2022

This supersedes #23416

This is a tracking issue for the RFC "3307" (rust-lang/rfcs#3307).

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

  • Implement the RFC:
    • Remove type ascription from the parser and diagnostics
    • @rust-lang/compiler: Do y'all have a preference as to how far the removal should go? Unparseable AST nodes could be left in the code, for example (perhaps only instantiable by internal macro)
  • Adjust documentation: Remove it from the unstable book
  • (No stabilization PR necessary)
  • Remove the feature gate.

Unresolved Questions

  • Should this be completely removed by the compiler, or left behind in a way that cannot be directly accessed through Rust syntax (or requires using a wrapper macro)?
  • [ ]

Implementation history

@Manishearth Manishearth added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Sep 12, 2022
@Manishearth Manishearth added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Sep 12, 2022
@SoniEx2

This comment was marked as off-topic.

jplatte added a commit to jplatte/caniuse.rs that referenced this issue Sep 29, 2022
@Noratrieb
Copy link
Member

@rustbot claim

I'll remove all the parsing and diagnostic logic/hacks but leave the AST nodes and everything after it behind for now.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 2, 2022
Add `type_ascribe!` macro as placeholder syntax for type ascription

This makes it still possible to test the internal semantics of type ascription even once the `:`-syntax is removed from the parser. The macro now gets used in a bunch of UI tests that test the semantics and not syntax of type ascription.

I might have forgotten a few tests but this should hopefully be most of them. The remaining ones will certainly be found once type ascription is removed from the parser altogether.

Part of rust-lang#101728
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 12, 2022
delete mentions of type ascription from lint descriptions

Tracking Issue: rust-lang#101728
@Noratrieb Noratrieb added the F-type_ascription `#![feature(type_ascription)]` label Dec 16, 2022
@RalfJung
Copy link
Member

Would it make sense to possibly replace type ascription by an unstable macro in the standard library?

macro_rules! type_ascribe {
    ($e:expr, $t:ty) => {{
        let val: $t = $e;
        val
    }};
}

I noticed #104614 added a magic macro that preserves the old semantics, but maybe we can implement this entirely in userland?

@bjorn3
Copy link
Member

bjorn3 commented Jan 10, 2023

That macro shortens the lifetime of temporaries created in the expression.

@Skgland
Copy link
Contributor

Skgland commented Jan 12, 2023

Would a function eliviate this problems with temporaries?
Or am I missing more temporary stuff?

pub fn type_ascribe<T>(value: T) -> T { value }

#[allow(unused_macros)]
macro_rules! type_ascribe {
    ($e:expr, $t:ty) => {{
        let val: $t = $e;
        val
    }};
}

pub fn main() {
    // macro dosn't work because of temporaries
    // println!("{}", type_ascribe!(String::from("hello world").split_once(' '), _).unwrap().0)
    
    //  identity function with turbo fish works
    println!("{}", type_ascribe::<_>(String::from("hello world").split_once(' ')).unwrap().0)
}

playground

@RalfJung
Copy link
Member

RalfJung commented Jan 12, 2023

That can be wrapped in a macro, of course:

pub fn type_ascribe<T>(value: T) -> T { value }

#[allow(unused_macros)]
macro_rules! type_ascribe {
    ($e:expr, $t:ty) => {type_ascribe::<$t>($e)};
}

pub fn test(x: usize) {
    println!("{}", type_ascribe!(String::from("hello world").split_once(' '), _).unwrap().0);
    let v = type_ascribe!([[0, 1, 2, 3], [4, 5, 6, 7]][x], [u32; 4]);
}

@Noratrieb
Copy link
Member

This has taken a lot more time than I thought since lots of diagnostics were relying on it in subtle ways and require restructuring. I don't have enough time to work on this and also the other things I'm working on so I'm dropping my assignment here, feel free to take it. There's a WIP PR #106826 which may or may not be useful.
@estebank maybe you're interested in working on it, given all the pains you've had with type ascription :D
@rustbot release-assignment

@chenyukang chenyukang self-assigned this Mar 8, 2023
bors added a commit to rust-lang-ci/rust that referenced this issue May 2, 2023
…tion, r=estebank

Remove type ascription from parser and diagnostics

Mostly based on rust-lang#106826

Part of rust-lang#101728

r? `@estebank`
flip1995 pushed a commit to flip1995/rust that referenced this issue May 5, 2023
…tion, r=estebank

Remove type ascription from parser and diagnostics

Mostly based on rust-lang#106826

Part of rust-lang#101728

r? `@estebank`
calebcartwright pushed a commit to calebcartwright/rust that referenced this issue Jun 20, 2023
…tion, r=estebank

Remove type ascription from parser and diagnostics

Mostly based on rust-lang#106826

Part of rust-lang#101728

r? `@estebank`
@fmease fmease added the S-tracking-remove-implementation Status: The feature needs to be removed from the Rust toolchain before this issue can be closed label Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-type_ascription `#![feature(type_ascription)]` S-tracking-remove-implementation Status: The feature needs to be removed from the Rust toolchain before this issue can be closed T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants