Unstable type parameters on stable types

This is related to #1 but not identical. When adding a defaulted type parameter to a stable type, for example changing:

struct Vec<T> {…}

To:

struct Vec<T, A: Alloc = Global> {…}

We would like to experiment with this change on Rust Nightly before it affects users one the Stable channel. That is, we would like to keep the type parameter unstable. Ideally, even the existence of this type parameter should not affect the stable channel at all.

As far as I understand this is not possible today. Ways forward include:

Extend the stability mechanism in the language to support unstable type parameters. This itself would likely take significant time to design and implement.
Accept that the existence of the new type parameter is instantly stable as soon as it lands, and hope that the trait that constraints this parameter being unstable is enough to avoid locking is into some API detail that we might want to change later. In this case Compat of adding parameters to stable types #1 needs to be resolved before adding the parameter.
Avoid adding type parameters at all to stable types. Define new types instead. This would mean that e.g. &mut NewVec<T, Global> could not be passed where &mut Vec<T> is expected.

I tested this for Box<T, A> just right now, and it doesn't actually work:

use std::alloc::System;
  
fn main() {
    let x = Box::<(), System>::default();
}

Just compiles without an error.

So either this needs to be fixed first, or we have to limit the changes to only expose unstable methods, which would make it less useful.

Oh damn, I think I tested it with Box::<(), Global> and forgot that Global itself isn't stable either... I'm sorry for the confusion...

A fourth option would be another Alloc trait, which is unstable and will only be implemented for unstable types. This will then be replaced as soon as either 1. becomes possible or when allocator_api becomes stable. With this we could also test other options for the alloc trait without breaking the current allocator api every time.

Taking a step back, the only stable type that implements Alloc is System. There is nothing that says that System should implement Alloc. The only thing currently documented is that it implements GlobalAlloc. And Global is what implements Alloc, and, practically speaking, it wraps System. So it doesn't seem to actually be useful for System to implement Alloc.

So how about we remove the Alloc impl for System?

`Global` uses the `#[global_allocator]` and `System` the system allocator but this doesn't matter here. Removing `Alloc` for `System` is maybe the most simple option. The implementation cannot be used on stable anyway.

…

On May 3, 2019, 12:41, at 12:41, Mike Hommey ***@***.***> wrote: Taking a step back, the only stable type that implements `Alloc` is `System`. There is nothing that says that `System` should implement `Alloc`. The only thing currently documented is that it implements `GlobalAlloc`. And `Global` is what implements `Alloc`, and, practically speaking, it wraps `System`. So it doesn't seem to actually be useful for `System` to implement `Alloc`. So how about we remove the `Alloc` impl for `System`? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #2 (comment)

I think unstable params on stable types is good thing to have in general: I think a lot of Rust code ought be more polymorphic (in ways we haven't even thought of yet!) and this is the best way to unblock experimentation on that front.

Now I don't want to hold up Box<T, A> much longer, either, so how hard would this be?

@SimonSapin

Now I don't want to hold up Box<T, A> much longer, either, so how hard would this be?

With glandium/rust@4395ce1 this issue should be solved. @SimonSapin?

I think unstable params on stable types is good thing to have in general

Absolutely! Probably an issue should be filed in rust repo, if there isn't one yet.

@TimDiekmann

@TimDiekmann I assume you mean that this commit “solves” this issue on the premise that since there is a bound on the type parameter with an unstable trait that has no impl with stable types, then users on Stable cannot write Box<T, Foo> for any Foo.

Does this satisfy the criteria that the parameter addition has no observable effect for users on Stable? I’m not sure. For example, what about Box<T, _>? (With a literal underscore.)

Oh, the literal underscore is a good point. But, as far as I can see, this case should be safe. There will definitely a second parameter but a user on Stable cannot make any assumptions about it, as he cannot implement the trait. (Even typing Box<T, System> would be relatively safe, but Alloc should be removed from System anyway. If a nightly user really needs this, he may implement it in a newtype struct). With Box<T, _> it would even be possible to change the second parameter bound or default without breaking anything.

Just to be clear, you’re arguing that the visible effects of this type parameter on Stable are benign enough that we should accept them as insta-stable. This is not the same as there being no such effect. The former would require some @rust-lang/libs buy-in before landing at all.

Yeah I want something that's seamless enough that teams / WGs don't need to synchronize, so this and other parameter experiments can take place entirely in parallel.

Remove the impl Alloc for System

@varkor

@varkor #[may_dangle] does not show up either.

HirId { owner: DefIndex(6), local_id: 5 }
annotate_generic
NOT staged_api annotate(id = HirId { owner: DefIndex(6), local_id: 5 }, attrs = [])
UNMARKED: DefId(15:4 ~ stability_attribute_generic[8787]::Foo[0]::T[0])
UNMARKED: DefId(15:4 ~ stability_attribute_generic[8787]::Foo[0]::T[0])
UNMARKED: DefId(15:4 ~ stability_attribute_generic[8787]::Foo[0]::T[0])
UNMARKED: DefId(15:4 ~ stability_attribute_generic[8787]::Foo[0]::T[0])

Another aspect to consider is how adding a defaulted type parameter affects inference: rust-lang/rust#50822 (comment)

This issue is now exactly one year old.

Extend the stability mechanism in the language to support unstable type parameters.

This pretty much failed. I don't think we should focus on this anymore.

I'd say we do two things in parallel to push this further:

a crater-run on an MVP with an allocator aware Box to solve Compat of adding parameters to stable types #1
implement another Box (maybe in alloc::alloc::boxed) gated behind a feature flag and test around with this box. The new box should be compatible with the old box, so at a later point it could replace it.

I'm pretty sure new issues will occure as soon as we push the box upstream.

I'm still interested in rust-lang/rust#65083, but I would need guidance on blocking type inference.

That's nice! However the crater run is needed anyway and using a new type could be a temporary solution to get things done.

…

On May 4, 2020, 04:37, at 04:37, Avi Dessauer ***@***.***> wrote: I'm still interested in rust-lang/rust#65083, but I would need guidance on blocking type inference. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #2 (comment)

If we can't get unstable type parameters then we will just have to introduce the allocator parameter as insta-stable, like a trait impl.

rust-lang/rust#58457 would have removed AllocRef for System. This is also an option to prevent users from specifying an allocator. However this does not prevent writing

let boxed: Box<T, _> = Box::new(...)

But this is fine to me.

I think rust-lang/rust#72314 is ready to merge now, which adds support for unstable type parameters. That is, type parameters with defaults can be marked unstable, which means an explicit type argument will only be permitted if the corresponding feature flag is enabled. However, as a note of warning to API implementers: a non-default type can still be inferred for an unstable type parameter. (This appears to be necessary to prevent code breaking when a type parameter is stabilised.) That means that you must be careful not to allow the type parameter to be inferred outside of library code, e.g. by having custom constructors for the non-default type parameter, at least until the type parameter is stabilised. I think that this is the most reasonable design, but let me know if you have any concerns. It may be helpful for those interested to take a look at the tests on rust-lang/rust#72314 to check it matches their intuition. If there are no concerns, I'll approve it in a few days.

@Avi-D-coder

That seems like a reasonable trade-off between reviewer responsibility and compiler detectability to me. Nice work @Avi-D-coder and @varkor!

you must be careful not to allow the type parameter to be inferred outside of library code, e.g. by having custom constructors for the non-default type parameter

I don’t understand this part, could you say more?

I don’t understand this part, could you say more?

If I understand correctly, this means, that a stable API must not make any assumption about the unstable type parameter. For example we must not stabilize Vec::new_in before stabilizing the type parameter. If we'd do this, we may pass an allocator without a feature gate and alter the defaulted type parameter.

@TimDiekmann

Now that I think about it, it seems harder to accidentally allow this than I thought. The sort of example I had in mind was the following.

// Library code.
pub struct SomeType<#[unstable(feature = "test_feature")] T = ()>(T);

// User code.
SomeType(0u8) // Works, even though a non-default is not specified, because the default is inferred.

There could be a similar problem if existing methods are extended to support different type parameters, but that's not going to happen, in which case @TimDiekmann's comment is the main point to keep in mind: if you stabilise any method that allows the default to be changed (even implicitly, e.g. taking a type that can be inferred as non-default), you've effectively stabilised the type parameter itself (even if the user can't mention it explicitly). I think due to the way the APIs are designed, this won't be a problem in practice, though.

Auto merge of rust-lang#77118 - exrook:stability-generic-parameters-2…

@Avi-D-coder

It's now possible to add stability annotations on generic parameters as seen in rust-lang/rust#77187. Many thanks for @Avi-D-coder to make this possible. Also thank you for @varkor for reviewing the changes and @exrook to catch this up, so it's merged now!

Navigation Menu

Repository navigation

Unstable type parameters on stable types #2

18 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unstable type parameters on stable types #2

Description

Activity

TimDiekmann commented on May 3, 2019

glandium commented on May 3, 2019

TimDiekmann commented on May 3, 2019

TimDiekmann commented on May 3, 2019

glandium commented on May 3, 2019

TimDiekmann commented on May 3, 2019

Ericson2314 commented on May 3, 2019

TimDiekmann commented on May 3, 2019

SimonSapin commented on May 3, 2019

TimDiekmann commented on May 3, 2019

SimonSapin commented on May 3, 2019

Ericson2314 commented on May 3, 2019

18 remaining items

Avi-D-coder commented on Nov 12, 2019

SimonSapin commented on Nov 12, 2019

TimDiekmann commented on May 4, 2020

Avi-D-coder commented on May 4, 2020

TimDiekmann commented on May 4, 2020

Amanieu commented on May 4, 2020

TimDiekmann commented on May 4, 2020

varkor commented on Jul 20, 2020

Wodann commented on Jul 22, 2020

SimonSapin commented on Jul 22, 2020

TimDiekmann commented on Jul 22, 2020

varkor commented on Jul 22, 2020

TimDiekmann commented on Sep 27, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions