Rust itself also provides precedent for may in the form of #[must_use] in the sense that both may and must are modal verbs.
Do we think that impls_ is necessary or could we leave that inferred and shorten the name to #[may_overlap] perhaps? Here, the name in #[may_overlap] is 11 characters long and shorter than in #[overlappable] which is 12 characters long.
I have a very slight preference for including impl(s) because
this is a pretty small feature in the grand scheme of things and not likely to be written dozens of times in a row, so a long descriptive name wins by default
I feel like a user whoās brand new to all this trait system machinery would have a much easier time guessing what āimpls may overlapā means on a trait than what āoverlappableā means on a trait (thereās probably some plausible but wrong meaning you could invent for āoverlapping traitsā; just look at how many people thought āinherent trait implsā were a thing because of bare trait syntax)
I am thinking that that is exactly what this attribute represents. "I as the API author recognize the trivialness of this Trait and am making a commitment to keep it Trivial so you as a client are free to create 3rd party implementations of this trait".
I like this one a lot. If we're not comfortable with "trivial" or "simple", I like this one the best of anything suggested so far. Could possibly be shorted to just "may_overlap" as well.
The shorter #[may_overlap] sounds a little like it might be referring to memory overlapping somehow, which is of course nonsense for a trait, let alone an empty trait. This potential confusion is (small) cognitive load.
I think marker is a fine name, since we already call these marker traits.
I think if a trait has items that canāt be overridden, that trait is still a marker trait, because you canāt define any items in impls. I am also dubious that we would ever add this feature, since it adds complexity & irregularity and is semantically equivalent to just writing free functions.
Iām more interested in the possibility that there are other things we could do with marker traits (nothing in particular comes to mind), and I think limiting the name of this attribute to the particular behavioral change weāre introducing today would be shortsighted.
Yes, but, what about traits that aren't "Marker" traits (i.e. have some default, non-overridable methods) that this should work with as well? I think that was the OP's point that "Marker" is misleading because it will (potentially) need to be used with non-marker traits; hence, the commentary around "simple/trivial" traits and a hierarchy of "Trait Complexity Kinds".
This can be worked around by having an item-less marker trait + a pre-implemented extension trait (until that pattern gets more sugar such as you suggest).
Doesnāt overloading make multiple implementation of a marker trait incoherent again?
Sure, that's what folks generally do today, but some consider it a hack.
As far as I know, No it doesn't; because all items are restricted to have the default provided definition; of course you can say that this is not overloading at all in that case...
We're diverging from the topic, but of course that's not overloading: ad hoc overloading means the ability to redefine the item according the particular type.
My point is that I think every item of a trait should be ad hoc overloadable for consistency and simplicity and comprehensibility of our system, at the expense of letting you wrote non-overloadable functions with method or associated function syntax. I'm similarly against free functions with self arguments.
That is, I think it is not worth allowing full syntactic freedom to create exactly the API syntax you might want at the expense of providing language features such that the syntax loses its connection to particular semantics. In this case, I think it is beneficial to users to be able to work from an understanding associated items are type dispatched in an ad hoc overloadable way. (My concerns about macro methods are along the same line.)
While it is true that "we already call these marker traits", I pointed out here (and @Ixrec extended it to #[trivial] et al. here) that having the name #[marker] would result in some marker traits having the annotation #[marker] while some marker traits would not. It is then unclear what a marker trait is... is it a trait with zero items (the current common definition), or is it a trait which has a #[marker] annotation on it?
The main benefit of #[marker] is as you say if we would extend the meaning of the attribute to do more things; but you also said nothing comes to mind (whereas things come to mind wrt. extending the attribute to other sorts of traits even if you are currently opposed to such extensions...).
I think that @Ixrec also hit the nail on the head when they said:
and
It seems to me that a naming which somehow includes "overlap" takes less out of the complexity budget than other names.
I have use-cases for explicitly not wanting Unpin to be #[marker], or at least to make it so that a manual non-overrideable opt-out is possible. This is so that macros could generate types that are guaranteed to be !Unpin for safety reasons and cannot have Unpin implād by the author of the crate in which the macro is called.