Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support an explicit annotation for marker traits #53693
From the tracking issue for rust-lang/rfcs#1268:
This PR allows you to put
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.
referenced this pull request
Aug 26, 2018
@scottmcm I see. That seems like an ok extension, actually, but in that case I don't know what this is referring to...
...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
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:
We should probably do a quick lang-team FCP here too.
@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
Seems reasonable to me.
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:
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.
@rfcbot concern vague
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.
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.
@rfcbot concern needs-rfc
In addition; I am not so sure about the concrete syntax here.
The choice of using an attribute rather than some keyword as a prefix to the trait (e.g.
@rfcbot concern concrete-syntax
Ok, I'll just do the "opt into the RFC behaviour using an attribute" part of the change, making having anything in a