Uh oh!
There was an error while loading. Please reload this page.
Feature gate defaulted type parameters appearing outside of types - #30724
Conversation
There was a problem hiding this comment.
ah cool, good to CSE this messaging in one place.
pnkfelix
commented
Jan 5, 2016
bors
commented
Jan 5, 2016
🙀 |
pnkfelix
commented
Jan 5, 2016
(graar i hate githubs presentation of the commit series) |
pnkfelix
commented
Jan 5, 2016
nikomatsakis
commented
Jan 6, 2016
@bors r=pnkfelix |
bors
commented
Jan 6, 2016
📌 Commit 6dd3f61 has been approved by |
bors
commented
Jan 7, 2016
…eters, r=pnkfelix It was recently realized that we accept defaulted type parameters everywhere, without feature gate, even though the only place that we really *intended* to accept them were on types. This PR adds a lint warning unless the "type-parameter-defaults" feature is enabled. This should eventually become a hard error. This is a [breaking-change] in that new feature gates are required (or simply removing the defaults, which is probably a better choice as they have little effect at this time). Results of a [crater run][crater] suggest that approximately 5-15 crates are affected. I didn't do the measurement quite right so that run cannot distinguish "true" regressions from "non-root" regressions, but even the upper bound of 15 affected crates seems relatively minimal. [crater]: https://gist.github.com/nikomatsakis/760c6a67698bd24253bf cc @rust-lang/lang r? @pnkfelix
bors
commented
Jan 7, 2016
pnkfelix
commented
Jan 12, 2016
(I suspect we should not actually take any special effort to backport this to beta. But I'll leave the nominated tag to ensure that the team discusses it.) |
bluss
commented
Jan 13, 2016
@nikomatsakis I object to removing defaults in Something like the following is working fine for me today. It also allows backwards compatible addition of type parameters just like for structs. traitIndexRange<T=usize>{fnstart(&self) -> Option<T>}fnindex<R:IndexRange>(r:R){ ...} |
petrochenkov
commented
Jan 13, 2016
@bluss |
bluss
commented
Jan 13, 2016
@petrochenkov Ok, that's great. Some of the messages need updating for that. |
m4rw3r
commented
Jan 13, 2016
Some functional programming with generics would benefit from having the default type parameters, provided that Since it is not yet enabled by default I will follow the recommendation and remove these defaults from Chomp. |
bluss
commented
Jan 13, 2016
type parameter defaults seem to be going rather than coming to rust, what it looks like now, @m4rw3r |
…nt, r=brson
There is now more structure to the report, so that you can specify e.g. an RFC/PR/issue number and other explanatory details.
Example message:
```
type-parameter-invalid-lint.rs:14:8: 14:9 error: defaults for type parameters are only allowed on type definitions, like `struct` or `enum`
type-parameter-invalid-lint.rs:14 fn avg<T=i32>(_: T) {}
^
type-parameter-invalid-lint.rs:14:8: 14:9 warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
type-parameter-invalid-lint.rs:14:8: 14:9 note: for more information, see PR 30742 <rust-lang#30724>
type-parameter-invalid-lint.rs:11:9: 11:28 note: lint level defined here
type-parameter-invalid-lint.rs:11 #![deny(future_incompatible)]
^~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
```
r? @brson
I would really like feedback also on the specific messages!
Fixesrust-lang#30746bluss
commented
Jan 18, 2016
This should link to the tracking issue for default type parameter fallback: #27336 (now it does) |
Introduced in PR rust-lang#30724, needs to mention that type parameter defaults are legal in trait and type definitions too.
Fix type parameter default error to mention type and trait definitions Introduced in PR #30724, needs to mention that type parameter defaults are legal in trait and type definitions too.
Fix type parameter default error to mention type and trait definitions Introduced in PR rust-lang#30724, needs to mention that type parameter defaults are legal in trait and type definitions too.
Fix type parameter default error to mention type and trait definitions Introduced in PR rust-lang#30724, needs to mention that type parameter defaults are legal in trait and type definitions too.
ClosesPistonDevelopers#996 - Removed draw_state dependency - Fixed [PR 30742](rust-lang/rust#30724) (default generic parameters will become a hard error)
Allow the [un]signed functions to return integers smaller than [iu]64 and also use the standard `byteorder` definitions of endianness rather than implementing our own enum type. Unfortunately, Rust functions are no longer allowed to have default type arguments (see PR 30724, rust-lang/rust#30724), so we still have to specify the endianness explicitly every time we use one of these functions. The may require wrapping inside a type...
It was recently realized that we accept defaulted type parameters everywhere, without feature gate, even though the only place that we really intended to accept them were on types. This PR adds a lint warning unless the "type-parameter-defaults" feature is enabled. This should eventually become a hard error.
This is a [breaking-change] in that new feature gates are required (or simply removing the defaults, which is probably a better choice as they have little effect at this time). Results of a crater run suggest that approximately 5-15 crates are affected. I didn't do the measurement quite right so that run cannot distinguish "true" regressions from "non-root" regressions, but even the upper bound of 15 affected crates seems relatively minimal.
cc @rust-lang/lang
r? @pnkfelix