-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 RFC 213: Default Type Parameter Fallback #27336
Comments
What is the status of this? |
This doesn't seem to be working properly. #![crate_type = "lib"]
#![feature(default_type_parameter_fallback)]
trait A<T = Self> {
fn a(t: &T) -> Self;
}
trait B<T = Self> {
fn b(&self) -> T;
}
impl<U, T = U> B<T> for U
where T: A<U>
{
fn b(&self) -> T {
T::a(self)
}
}
struct X(u8);
impl A for X {
fn a(x: &X) -> X {
X(x.0)
}
}
fn f(x: &X) {
x.b(); // ok
}
fn g(x: &X) {
let x = x.b();
x.0; // error: the type of this value must be known in this context
} |
@mahkoh there is a necessary patch that hasn't gotten rebased since I stopped my summer internship. I've been unfortunately busy with real life stuff, looks like @nikomatsakis has plans for landing a slightly different version according to a recent post of his on the corresponding documentation issue for this feature. |
@nikomatsakis I know the lang team didn't see any future in this feature, will you put that on record in the issue 😄? One example where this feature seems to be the only way out is the following concrete example of API evolution in libstd.
|
@bluss I HAVE been dubious of this feature, but I'm been slowly reconsidering. @aturon is supposed to be doing some exploration of this whole space and writing up some detailed thoughts. I actually started rebasing @jroesch's dead branch to implement the desired semantics and making some progress there too, but I've been distracted. One advantage of finishing up the impl is that it would let us experiment with extensions like the one you describe to see how backwards compatible they truly are -- one problem with fallback is that it is not ACTUALLY backwards compatible, because of the possibility of competing incompatible fallbacks. |
That said I still have my doubts :) |
Another example where this could be useful -- basically the same example as petgraph -- is adding allocators to collections in some smooth way. |
What are the drawbacks to turning this on? It seems to mainly make things compile that otherwise cannot infer enough type information. |
I have a pretty good use for this too. It's basically what @bluss mentioned, adding new types to an |
Is the only issue with this the interaction with numeric fallback? I like default type parameters a lot. I often use them when I parameterize a type which has only one production instantiation, for mocking and to enforce bondaries. Its inconsistent and for me unpleasant that defaults don't work for the type parameters of functions. |
It would be nice if a default value could be used so old code would mostly just work, but defaults are not used while determining types so adding a default does nothing here. It would also be nice if we could calculate the number of interfaces needed at compile time, but I'll leave that as an exercise for later. rust-lang/rust#95486 rust-lang/rust#99727 rust-lang/rust#27336
It would be nice if a default value could be used so old code would mostly just work, but defaults are not used while determining types so adding a default does nothing here. It would also be nice if we could calculate the number of interfaces needed at compile time, but I'll leave that as an exercise for later. rust-lang/rust#95486 rust-lang/rust#99727 rust-lang/rust#27336
It would be nice if a default value could be used so old code would mostly just work, but defaults are not used while determining types so adding a default does nothing here. It would also be nice if we could calculate the number of interfaces needed at compile time, but I'll leave that as an exercise for later. rust-lang/rust#95486 rust-lang/rust#99727 rust-lang/rust#27336
Types in part of a (path) expression, like
Where as in type ascription location, you can't elide non-defaulted parameters, but if you elide defaulted parameters they take on the default value. (Then the inferred type parameter in the expression can be resolved from the ascription.) So these are all the same and compile:
And then we have
Summary
|
#![feature(default_type_parameter_fallback)]
pub fn empty_vec<A=u32>() -> Vec<A> {
Vec::new()
}
pub fn use_empty_vec() {
empty_vec();
} #![feature(default_type_parameter_fallback)]
use core::marker::PhantomData;
pub struct WithTypeDefault<T = ()> {
field: PhantomData<T>
}
impl <T> WithTypeDefault<T> {
pub fn to_t(&self) -> T {
loop {}
}
}
pub fn use_to_t() {
let with_type_default = WithTypeDefault {field: PhantomData {} };
let to_t = with_type_default.to_t();
} |
This comment was marked as outdated.
This comment was marked as outdated.
Someone with access, or @Gankra or @jroesch, could you update the very first comment (issue description) to reflect the following, so as to save readers' time, please.
Unfortunately, that internals thread was auto-closed, and the last comment (from September 2015) says that "the lang subteam" has had a "consensus". So, it doesn't explain the problem mentioned in the "EDIT" in 2019. As is, the "EDIT" paragraph easily confuses readers to search for the problem in that internals thread. Please split into two paragraphs, or add some wording to make the separation clear.
Curious: Was the problem found during implementation only when there is a conflict between the user-supplied default type and an inferred type? Because I have a huge piece of work (for |
There's still a feature gate, |
I think we should completely remove the feature gate. It's currently only partially implemented and requires some significant design work before we re-add it afaict. |
+1
…On Mon, Jul 15, 2024, at 4:17 AM, lcnr wrote:
I think we should completely remove the feature gate. It's currently only partially implemented and requires some significant design work before we re-add it afaict.
—
Reply to this email directly, view it on GitHub <#27336 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABF4ZWVJ62BRCX2DZI6AP3ZMOAP7AVCNFSM6AAAAABKZA5FOKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRXHEZTMMBQG4>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Sadly that's not really possible currently, |
I will reopen the issue then -- as long as the feature gate exists, the tracking issue it points to should remain open. |
…t, r=compiler-errors turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps` `@rust-lang/types` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error. However, turns out that outright removing it right now would lead to [tons of crater regressions](rust-lang#127655 (comment)), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this. Fixes rust-lang#27336 by removing the feature gate (so there's no way to silence the lint even on nightly) CC rust-lang#36887
…t, r=compiler-errors turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps` ``@rust-lang/types`` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error. However, turns out that outright removing it right now would lead to [tons of crater regressions](rust-lang#127655 (comment)), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this. Fixes rust-lang#27336 by removing the feature gate (so there's no way to silence the lint even on nightly) CC rust-lang#36887
…t, r=compiler-errors turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps` ```@rust-lang/types``` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error. However, turns out that outright removing it right now would lead to [tons of crater regressions](rust-lang#127655 (comment)), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this. Fixes rust-lang#27336 by removing the feature gate (so there's no way to silence the lint even on nightly) CC rust-lang#36887
…t, r=compiler-errors turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps` ````@rust-lang/types```` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error. However, turns out that outright removing it right now would lead to [tons of crater regressions](rust-lang#127655 (comment)), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this. Fixes rust-lang#27336 by removing the feature gate (so there's no way to silence the lint even on nightly) CC rust-lang#36887
Rollup merge of rust-lang#127655 - RalfJung:invalid_type_param_default, r=compiler-errors turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps` `````@rust-lang/types````` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error. However, turns out that outright removing it right now would lead to [tons of crater regressions](rust-lang#127655 (comment)), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this. Fixes rust-lang#27336 by removing the feature gate (so there's no way to silence the lint even on nightly) CC rust-lang#36887
2024-07-15: This feature (
default_type_parameter_fallback
) is slated for removal, but that is currently blocked on too many crater regressions.EDIT: this issue has been stalled on disagreements about how to handle a nasty problem found during implementation. See the internals thread where this was detailed and discussed.
This is a tracking issue for RFC 213.
The initial implementation of this feature has landed.
cc @nikomatsakis
The text was updated successfully, but these errors were encountered: