Make it possible to gate features on epochs

[Manishearth]

Features like NLL and dyn trait should automatically turn on in epoch 2018.

(see #48790)

[SimonSapin]

dyn Trait requires a new keyword, but why is NLL related to epochs/editions at all? (In the cargo/rustc flag sense, not the "marketing" sense. (I still think it’s bad to conflate these two things.))

[steveklabnik]

I believe this is “stuff we want to ship before the edition” not “stuff that is only in the new edition and not in the old one”

…

On Mar 14, 2018, at 10:44 AM, Simon Sapin ***@***.***> wrote: dyn Trait requires a new keyword, but why is NLL related to epochs/editions at all? (In the cargo/rustc flag sense, not the "marketing" sense. (I still think it’s bad to conflate these two things.)) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Manishearth]

dyn trait and NLL will both be available pre-epoch as well. However we want people to be able to experience the 2018 epoch now on stable via -Zepoch. So it will turn on features early -- by the time the epoch release rolls around most of these should be stable anyway. Perhaps not all.

[SimonSapin]

should […] Perhaps

Tying the epoch flag to feature flags that we only speculate will be stabilized around the same time as the epoch doesn’t seem like a good idea to me. Regardless of how this prediction turns out, opting into breaking changes like new keywords and trying unstable features in Nightly should be separate concerns.

[Manishearth]

You can try unstable features in Nightly now if you wish.

And yeah, a #![feature(2018_edition_features)] thing may be nice.

This doesn't tie anything, if we decide to not stabilize a feature we can drop it out of this group. -Zepoch is currently unstable, as will -Zedition be, as will --edition when it comes to that.

-Zepoch is a way for us to test stuff, and a way to get an early taste which will be a more accurate representation of the epoch as we get closer.

It also lets us work on epoch-related things in an easier way.

[Manishearth]

Also, when I say "perhaps not all", I'm talking about features stabilizing pre-epoch-release; some features may stabilize that release.

(And some may stabilize as "only in 2018 epoch" though I don't think we have anything like that for this epoch. There are planned features like self: *const Self which will probably be 2018-epoch-only)

[nox]

There are planned features like self: *const Self which will probably be 2018-epoch-only.

That seems very bad to me. I keep reading "backwards compatibility isn't an issue with editions", but if you edition-gate features as trivial (in terms or being mere additions to the language) as arbitrary method receives, that means anyone who wants to use this feature needs to actually port their code to Rust 2018, potentially with massive module import changes and whatnot.

I don't understand why new features which don't actually need to break backwards-compatibility should have an edition-gate.

[Manishearth]

That feature isn't compatible with the 2015 epoch (so far at least), which is why it may be gated.

Either gate it or don't get it at all in any epoch.

(And *const Self receivers seems like a rare enough usecase that I don't see it particularly bad that people won't be able to use it on the old epoch. Completely arbitrary method receivers, perhaps, but this is just *const Self I'm talking about)

potentially with massive module import changes and whatnot.

There's none of this.

This epoch currently has only two breakages:

• foo.is_null() will not work if foo is *const T/*mut T and T is not a completely-known type (a type variable)
• some things are now keywords

There is a lint that will appear in the new epoch eventually that asks you to migrate your imports to what will be idiomatic in the new world, but that won't become deny any time in the 2018 epoch (and I doubt it will become deny the next epoch but that's too far away to tell)

[nox]

but this is just *const Self I'm talking about

Ok, thanks for the clarification.

[Manishearth]

The issue is that while currently foo.bar() will work if foo is Foo<T> only if T is not a type variable, this isn't true for *const T, you can call .is_null() on *const T where T is completely unknown, because the compiler knows how to calculate is_null() anyway and just does it.

This means that adding a fn is_null(self: *const Self) to any one type will make foo.is_null() ambiguous.

(New ambiguities are not normally breaking changes because they are introduced by imported traits and fixed by UFCS, but this is more action-at-a-distance)

See #46906

If we do add arbitrary self types, implementing and calling such methods on raw pointers (and things that deref to them) may be epoch-gated since the 2015 epoch is more flexible about raw pointers.

[Manishearth]

#49016