Support an explicit annotation for marker traits

[scottmcm]

From the tracking issue for rust-lang/rfcs#1268:

It seems obvious that we should make a #[marker] annotation. ~ #29864 (comment)

This PR allows you to put #[marker] on a trait, at which point:

• The trait must not have any items All of the trait's items must have defaults
• Any impl of the trait must be empty (not override any items)
• But impls of the trait are allowed to overlap

r? @nikomatsakis

[scottmcm]

I think this is functional and sound, but it's missing the "this trait would be impossible to implement" error when defining a trait without default implementations for its items.

I'd appreciate advice on where that should go, as well as any other feedback on how I've been going about this.

[nikomatsakis]

@scottmcm this is confusing to me. I thought a marker trait had no items -- not "items with defaults".

[scottmcm]

@nikomatsakis See #29864 (comment) for some context. But yes, it's an extension beyond the RFC, so I'm fine not implementing that for now.

I do still need advice on where to put the "has no items" valuation check, though. (Once I know where I can figure out how to get the item list.)

[nikomatsakis]

@scottmcm I see. That seems like an ok extension, actually, but in that case I don't know what this is referring to...

I think this is functional and sound, but it's missing the "this trait would be impossible to implement" error when defining a trait without default implementations for its items.

...oh, I see, I thought you meant some fancy check designed to prove that the trait is imposible to implement. But actually you just mean that you want to report an error if you label a trait as #[marker] and it has items that lack defaults?

In that case, I think we should do that .. hmm .. either in WF or in coherence. Coherence seems like -- today -- it is focused on checking properties of impls so maybe wfcheck would be a better place.

Basically extending this function:

rust/src/librustc_typeck/check/wfcheck.rs

Lines 305 to 311 in 70a21e8

	fn check_trait<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, item: &hir::Item) {
	let trait_def_id = tcx.hir.local_def_id(item.id);
	for_item(tcx, item).with_fcx(|fcx, _| {
	check_where_clauses(tcx, fcx, item.span, trait_def_id, None);
	vec![]
	});
	}

We should probably do a quick lang-team FCP here too.

[nikomatsakis]

@rfcbot fcp merge

This PR modifies the special treatment of marker traits in two ways. First, you have to declare the traits explicitly, by writing #[marker], but secondly, it permits items in those traits -- so long as those items have defaults. However, once a trait is defined as #[marker], impls of the trait are then disallowed from containing any items, so you know that the defaults from the trait will be used.

Seems reasonable to me.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Centril
• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

Concerns:

• concrete-syntax resolved by Support an explicit annotation for marker traits #53693 (comment)
• needs-rfc resolved by Support an explicit annotation for marker traits #53693 (comment)
• vague resolved by Support an explicit annotation for marker traits #53693 (comment)

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[withoutboats]

@rfcbot concern vague

I'm 👍 on having a #[marker] annotation for marker traits with no items, and requiring that to get the overlapping allowance as a statement of your indefinite, permanent intent that this trait is a marker trait.

I'm not so convinced that redefining marker trait to include traits with default items and then adding additional checks that those are never overriden is a good idea. It comes at a nontrivial cost of complexity for users in terms of understanding the meaning and mechanics of both default methods and marker traits. The motivation doesn't seem that strong to me.

[Centril]

I very much agree that the incoherency should be opt-in rather than be implicit.

However; this was not discussed in the RFC (unless I somehow missed that but I did look at every comment...) and this could use some more elaborate and detailed justification.
For example, the changes wrt. provided definitions could use some more explaining per @withoutboats's concern. This is also, relatively speaking to the size of the original RFC, quite a large change.
Therefore I'd like to move this back to the drawing board, so:

@rfcbot concern needs-rfc

In addition; I am not so sure about the concrete syntax here.
For example, it seems to me that #[overlappable] (as suggested by @Vurich in #29864 (comment)) or #[incoherent] is more informative than #[marker] as to what effect it has. I think this holds particularly if associated items with defaults are permitted but can't be overridden as it isn't a marker trait anymore.

The choice of using an attribute rather than some keyword as a prefix to the trait (e.g. overlappable trait Foo { .. }) hasn't been sufficiently justified either in my opinion. The justification that has been given (#29864 (comment)) is merely that there is precedent to use an attribute. But precedent alone is not sufficient. In would like to see a discussion of this in an RFC. As such:

@rfcbot concern concrete-syntax

[Centril]

To elaborate a bit: I'm fine with landing this PR and using #[marker] as a temporary syntax; but not with resolving the final design at this stage.

[nrc]

I agree with @Centril and @withoutboats - this seems like a big change and marker traits with default methods adds considerably to the complexity of the feature, as well as making marker not really an appropriate name, IMO.

[nikomatsakis]

@bors r-

[scottmcm]

@nikomatsakis Ok, how about something like this:

If you're using overlapping_marker_traits, please migrate your code to marker_trait_attr. The former has the problem that it makes adding a method to an empty trait a potentially-breaking change, so the latter requires that the trait opt-in to supporting overlapping implementations.

But both features continue to work and are unstable, so it's surprising to me that we'd relnote them at all.

[nikomatsakis]

@bors r+

I'm not sure if we usually relnote unstable features. Seems like a nice thing to do.

[bors]

📌 Commit 3932249 has been approved by nikomatsakis

[bors]

⌛ Testing commit 3932249 with merge 2871872...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 2871872 to master...