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

RFC: Generalized Type Ascription #2522

Open
wants to merge 45 commits into
base: master
from

Conversation

Projects
None yet
@Centril
Contributor

Centril commented Aug 10, 2018

🖼️ Rendered

📝 Summary

This RFC supersedes and subsumes RFC 803.
We finalize a general notion of type ascription uniformly in patterns, expressions, let bindings, and fn definitions. You may now for example write:

// requires #![feature(block_ascription)]:
// These bits are proposed experimentally.
do_stuff(try : Option<u8> { .. });

do_stuff(async : u8 { .. });

do_stuff(unsafe : u8 { .. });

do_stuff(loop : u8 { .. });

// requires #![feature(type_ascription)]:
let x = (0..10).collect() : Vec<_>;

let alpha: u8 = expr;
    ^^^^^^^^^

let [x: u8, y, z] = stuff();
    ^^^^^^^^^^^^^

if let Some(beta: u8) = expr { .. }
            ^^^^^^^^

for x: i8 in 0..100 { .. }
    ^^^^^

// requires #![feature(limited_fn_inference)]:
fn foo(Wrapping(alpha: usize)) {}
       ^^^^^^^^^^^^^^^^^^^^^^

Here, the underlined bits are patterns. Note however that this RFC does not introduce global type inference.

Finally, when a user writes Foo { $field: $pat : $type }, and when $pat and $type are syntactically α-equivalent, the compiler emits a warn-by-default lint suggesting: Foo { $field: ($pat : $type) }.

💖 Thanks

To @nrc, @kennytm, @varkor for reviewing the draft version.
To @scottmcm in particular for reviewing and being my rubber duck wrt. type inference.

Centril added some commits Aug 6, 2018

@ExpHP

This comment has been minimized.

Show comment
Hide comment
@ExpHP

ExpHP Aug 22, 2018

Aside: I'm beginning to feel that any RFC written by @Centril needs its own table of contents. =P

ExpHP commented Aug 22, 2018

Aside: I'm beginning to feel that any RFC written by @Centril needs its own table of contents. =P

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Aug 23, 2018

Contributor

We probably also need a table of contents of all the @Centril RFCs :)

Contributor

mark-i-m commented Aug 23, 2018

We probably also need a table of contents of all the @Centril RFCs :)

@scottmcm

This comment has been minimized.

Show comment
Hide comment
@scottmcm

scottmcm Aug 23, 2018

Member

This has received a number of positive comments, so with the latest updates to only accept the more-uncertain block syntaxes experimentally, I think this is ready for wider team review.

@rfcbot fcp merge

Member

scottmcm commented Aug 23, 2018

This has received a number of positive comments, so with the latest updates to only accept the more-uncertain block syntaxes experimentally, I think this is ready for wider team review.

@rfcbot fcp merge

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Aug 23, 2018

Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged teams:

Concerns:

Once a majority of reviewers approve (and none object), 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.

rfcbot commented Aug 23, 2018

Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged teams:

Concerns:

Once a majority of reviewers approve (and none object), 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.

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Aug 23, 2018

Member

So, I'm 👍 on type ascription, 👎 on block ascription with the proposed syntax, and 👎 😟 on patterns in function signatures. Will post individual followup comments.

Member

joshtriplett commented Aug 23, 2018

So, I'm 👍 on type ascription, 👎 on block ascription with the proposed syntax, and 👎 😟 on patterns in function signatures. Will post individual followup comments.

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Aug 23, 2018

Member

@rfcbot concern block-type-ascription

For block ascription, it previously sounded like the proposal was to exclude those from the RFC and merge the rest, but the current proposal being FCPed seems to accept them "experimentally". All RFC changes are "accepted experimentally" until evaluated for stabilization, so that doesn't seem like a major difference. Could we please drop those entirely and stabilize the rest?

Member

joshtriplett commented Aug 23, 2018

@rfcbot concern block-type-ascription

For block ascription, it previously sounded like the proposal was to exclude those from the RFC and merge the rest, but the current proposal being FCPed seems to accept them "experimentally". All RFC changes are "accepted experimentally" until evaluated for stabilization, so that doesn't seem like a major difference. Could we please drop those entirely and stabilize the rest?

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Aug 23, 2018

Member

@rfcbot concern patterns-in-function-signatures

Python 2 used to have these, and Python 3 explicitly removed them. See https://www.python.org/dev/peps/pep-3113/ ; many of the arguments there apply just as well to Rust.

I don't feel like this adds significantly to expressiveness, and it complicates function syntax. It would also complicate macros parsing and processing function definitions, among other things.

Member

joshtriplett commented Aug 23, 2018

@rfcbot concern patterns-in-function-signatures

Python 2 used to have these, and Python 3 explicitly removed them. See https://www.python.org/dev/peps/pep-3113/ ; many of the arguments there apply just as well to Rust.

I don't feel like this adds significantly to expressiveness, and it complicates function syntax. It would also complicate macros parsing and processing function definitions, among other things.

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Aug 23, 2018

Contributor

We already have patterns in function signatures, though, don't we? This is just making patterns more expressive everywhere and removing the need to declare a type afterwards.

Contributor

mark-i-m commented Aug 23, 2018

We already have patterns in function signatures, though, don't we? This is just making patterns more expressive everywhere and removing the need to declare a type afterwards.

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Aug 23, 2018

Member

@mark-i-m I'm not sure we should be further encouraging that, though. And removing the top-level type signature on a parameter complicates the introspection of function arguments.

Member

joshtriplett commented Aug 23, 2018

@mark-i-m I'm not sure we should be further encouraging that, though. And removing the top-level type signature on a parameter complicates the introspection of function arguments.

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Aug 23, 2018

Contributor

And removing the top-level type signature on a parameter complicates the introspection of function arguments.

Could you elaborate? Is your concern about the compiler implementation or macros or something else?

Contributor

mark-i-m commented Aug 23, 2018

And removing the top-level type signature on a parameter complicates the introspection of function arguments.

Could you elaborate? Is your concern about the compiler implementation or macros or something else?

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Aug 23, 2018

Member

@mark-i-m Macros and similar syntax parsing. Right now you can safely assume that all parameters in function signatures have a top-level type.

Member

joshtriplett commented Aug 23, 2018

@mark-i-m Macros and similar syntax parsing. Right now you can safely assume that all parameters in function signatures have a top-level type.

@scottmcm

This comment has been minimized.

Show comment
Hide comment
@scottmcm

scottmcm Aug 24, 2018

Member

Whether function parameters should require top-level type ascription is a good discussion.

I don't think the existence of patterns in function definitions is worth debating here, though. They exist; they're used. If one wishes to make a pep-3113-like case, that should be a separate RFC.

nitpick: the complaint is with function definitions, not with function signatures. Just like today, the patterns are there in the definition, but not the signature: fn foo(mut x: i32) takes a pattern, but there's no mut in the signature; it's just fn(i32). This RFC wouldn't change that.

Member

scottmcm commented Aug 24, 2018

Whether function parameters should require top-level type ascription is a good discussion.

I don't think the existence of patterns in function definitions is worth debating here, though. They exist; they're used. If one wishes to make a pep-3113-like case, that should be a separate RFC.

nitpick: the complaint is with function definitions, not with function signatures. Just like today, the patterns are there in the definition, but not the signature: fn foo(mut x: i32) takes a pattern, but there's no mut in the signature; it's just fn(i32). This RFC wouldn't change that.

@mark-i-m

This comment has been minimized.

Show comment
Hide comment
@mark-i-m

mark-i-m Aug 24, 2018

Contributor

Perhaps a compromise would be to require top level type ascription in method definitions until we have more experience. In other words, function arguments would become patterns entirely, as in this RFC, but we would artificially require ascription on the outside of the pattern for each param.

We could then loosen this requirement later when macros et al are figured out.

Contributor

mark-i-m commented Aug 24, 2018

Perhaps a compromise would be to require top level type ascription in method definitions until we have more experience. In other words, function arguments would become patterns entirely, as in this RFC, but we would artificially require ascription on the outside of the pattern for each param.

We could then loosen this requirement later when macros et al are figured out.

@MajorBreakfast

This comment has been minimized.

Show comment
Hide comment
@MajorBreakfast

MajorBreakfast Aug 24, 2018

Contributor

The RFC proposes the feature gates type_ascription, block_ascription and limited_fn_inference. I'm for merging the RFC with all three feature gates because this will allow experiments in real code. Some parts of the RFC are more controversial, but that doesn't mean that they are a bad idea. IMO all of these features deserve to be implemented. After playing with these features, it will be possible to make informed decisions about which ones should be stabilized.

Contributor

MajorBreakfast commented Aug 24, 2018

The RFC proposes the feature gates type_ascription, block_ascription and limited_fn_inference. I'm for merging the RFC with all three feature gates because this will allow experiments in real code. Some parts of the RFC are more controversial, but that doesn't mean that they are a bad idea. IMO all of these features deserve to be implemented. After playing with these features, it will be possible to make informed decisions about which ones should be stabilized.

bors added a commit to rust-lang/rust that referenced this pull request Aug 25, 2018

Auto merge of #53272 - mark-i-m:anon_param_error_now, r=nikomatsakis
Warn on anon params in 2015 edition

cc #41686 rust-lang/rfcs#2522
cc  @Centril @nikomatsakis

TODO:
- [x] Make sure the tests pass.
- [x] Make sure there is rustfix-able suggestion. Current plan is to just suggest `_ : Foo`
- [x] Add a rustfix ui test.

EDIT: It seems I already did the last two in #48309

bors added a commit to rust-lang/rust that referenced this pull request Aug 25, 2018

Auto merge of #53612 - mark-i-m:anon_param_disallowed_2018, r=petroch…
…enkov

Remove anonymous trait params from 2018 and beyond

cc @Centril @nikomatsakis
cc #41686 rust-lang/rfcs#2522 #53272

This PR removes support for anonymous trait parameters syntactically in rust 2018 and onward.

TODO:
- [x] Add tests

bors added a commit to rust-lang/rust that referenced this pull request Aug 28, 2018

Auto merge of #53272 - mark-i-m:anon_param_error_now, r=nikomatsakis
Warn on anon params in 2015 edition

cc #41686 rust-lang/rfcs#2522
cc  @Centril @nikomatsakis

TODO:
- [x] Make sure the tests pass.
- [x] Make sure there is rustfix-able suggestion. Current plan is to just suggest `_ : Foo`
- [x] Add a rustfix ui test.

EDIT: It seems I already did the last two in #48309
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment