Remove variances from traits and deprecate PhantomFn/MarkerTrait

[nikomatsakis]

There are still some remnants we could remove from the compiler (e.g. references to "subtraitrefs"; traits still have variance entries in the variance table), but this removes all user-visible bits I believe.

r? @pnkfelix

Fixes #22806 (since such traits would no longer exist)

[pnkfelix]

anyway I'm still going to approve the PR

(update: there was once a note on a commit above about the deprecation strategy and whether we would be restricted from "undeprecating" these traits in the future. But I eventually realized that there is a fundamental difference between an item marked both #[unstable] #[deprecated] (where I think we can freely toggle the deprecation) and an item marked #[deprecated] with no unstable (which implies this was once #[stable] and thus can never adopt a different semantics nor transition back to #[unstable]).

[pnkfelix]

@bors r+ d580d1b

[nikomatsakis]

@bors r=pnkfelix e24f968

[nikomatsakis]

Update: @alexcrichton encountered some errors combining this PR with the ty_relate code introduced by #23895.

[nikomatsakis]

I have to look more deeply, but perhaps that suggests variance on traits is more useful than originally anticipated -- particularly around lifetime parameters.

[alexcrichton]

@bors: r- (due to bad interaction with #23895)

[bors]

☔ The latest upstream changes (presumably #23955) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

OK, I rebased and fixed the bad interaction.

[nikomatsakis]

Feeling a wee bit undecided about whether to take this patch, though I still lean in favor.

[nikomatsakis]

@bors r=pnkfelix c2dba85

[nikomatsakis]

Decided to go through with this.

[nikomatsakis]

Basic explanation of reasoning:

1. Still no concrete example.
2. Current system is somewhat uneven -- you can get variance, but you really have to understand the rules. On the other hand, the price of MarkerTrait + PhantomFn is imposed on all users, and most people don't really grok what is necessary.
3. In particular, Fn traits are invariant, which is not good, since this is the poster child for variance.
4. Always possible, if awkward, to workaround:
   • either with HRTB or,
   • by introducing a wrapper (i.e., if you need a Foo<'a> trait where 'a can be made shorter, then you can make a FooAdapter<'a,'b> where 'a:'b type that implements Foo<'b> given a Foo<'a>.

This adds up to: better to address trait variance more comprehensively in future and make Fn and friends opt-in.

[bors]

⌛ Testing commit c2dba85 with merge a167956...

[bors]

💔 Test failed - auto-linux-64-nopt-t

[alexcrichton]

@bors: retry

On Thu, Apr 2, 2015 at 3:31 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-linux-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-linux-64-nopt-t/builds/4301

—
Reply to this email directly or view it on GitHub
#23938 (comment).

[nikomatsakis]

@bors p=1

giving high priority because this is a backwards compat thing

[bors]

⌛ Testing commit c2dba85 with merge c14eb7c...

[bors]

💔 Test failed - auto-mac-64-nopt-t

[pnkfelix]

@bors retry

[pnkfelix]

@bors force

[bors]

⌛ Testing commit c2dba85 with merge 2615106...

[pnkfelix]

(I forced the retry in the hopes that the build products from the previous attempt would still be usable, but perhaps I was incorrect about that, since I think normally bors writes some notes here when it has discovered it can reuse build products from a previous attempt.)

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt