Open
Description
This is the tracking issue for RFC 19.
Checklist
Here is a check-list of code to write and tricky scenarios to be sure we handle:
- forbid conditional negative impls as described hereconditional negative impls not properly enforced Bounds seem to be ignored in negative impls #23072
impl !Pod for ..
should not be legal Negative blanket OIBIT impl treated as positive #28475fix feature-gate forimpl Foo for ..
impl Trait for .. {} does not require a feature gate #23225defaulted traits ought to be have more restrictive coherence rules defaulted traits ought to be have more restrictive coherence rules #22978defaulted traits should have no methods ICE: "resolved vtable bad vtable" withimpl Trait for .. {}
#23080 / Check that traits with default impls have no methods #23117Add parser support forimpl Foo for ..
PortSend/Sync
to use new infrastructure internallyAddunsafe impl Send for ..
/unsafe impl Sync for ..
Object types should never match against a defaulted trait (though the object type itself may add a candidate for traits that appear in the object type)When a defaulted trait matches, it should impose any supertrait bounds on the matched type as nested obligationsBe wary of type inference -- if we haven't resolved a type yet, we have to be ambiguousSystematic testing forconstituent_types
Coherence interaction: a defaulted trait can only be implemented for structs/enumsCoherence interaction: a trait can only be defaulted in the crate where it is definedCoherence interaction: a trait can only be defaulted onceCoherence interaction: an auto-trait can be redundantly implemented for an object that has it - It is possible to redundantly implement an auto trait for a trait-object type #56934Defaulted impls cannot be genericFix the interaction with PhantomData. OIBIT should treat PhantomData as if there were an instance of T reachable rather than breaking it down like it would a different struct. OIBIT: forPhantomData<T>
checkT
rather than the struct itself #23091Allow negative implementations for traits that have a default implementation (besides Send/Sync).ICE "wrong number of generic parameters" with abused auto trait #104808 lifetimes on auto traits are buggyCoherence rules: isimpl AutoTrait for dyn Trait
legal? Tracking Issue for auto traits (auto_traits) -- formerly called opt-in built-in traits (optin_builtin_traits) #13231 (comment)Interaction with dyn safety. Autotrait bounds on dyn-safe trait methods #107082Do[u8]
negative impls affectstr
. Tracking Issue for auto traits (auto_traits) -- formerly called opt-in built-in traits (optin_builtin_traits) #13231 (comment)
Metadata
Metadata
Assignees
Labels
Area: Trait systemArea: Type systemBlocker: Approved by a merged RFC but not yet implemented.Blocker: Approved by a merged RFC and implemented but not stabilized.Blocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFC`#![feature(auto_traits)]`Medium priorityStatus: The feature will stay unstable indefinitely.Relevant to the language teamRelevant to the types team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
[-]opt-in built-in trait bounds RFC tracker[/-][+]opt-in built-in bounds traits RFC tracker[/+]pnkfelix commentedon Apr 3, 2014
Marking 1.0, P-backcompat-lang.
nikomatsakis commentedon Apr 15, 2014
cc me
flaper87 commentedon Apr 22, 2014
I'm actively working on this. Unfortunately, I've moved quite slowly because of other bugs I had to fix. I hope to be able to submit a PR this week.
303 remaining items
madsmtm commentedon Sep 27, 2023
In my case too, you'd only need to opt out of
AutoreleaseSafe
when you're doing stuff with Objective-C (or perhaps Swift, but they're close enough) autorelease pools.I'll add that if a library wanted to make sure to opt out of all auto traits (e.g. if it implemented some sort of dynamic type), even for generic structs, they could do:
Of course this is yet another SemVer footgun to be aware of, but fortunately we have tools for that now.
GoldsteinE commentedon Sep 27, 2023
Oops, I mixed up “opting out” and “opting in” in my original message. Either way, the point stands: I don’t see a reason to opt out of arbitrary auto traits unless you’re doing something that can affect this particular system. Author of the auto trait guarantees that it’s safe to impl it if all the fields impl it.
steffahn commentedon Dec 11, 2023
For
Ungil
, I’ve found the issuePython::allow_threads
is unsound in the presence ofscoped-tls
. PyO3/pyo3#3640which is that an auto-trait is unable to restrict access to certain types even if those types always feature a non-
'static
lifetime as provided by to a higher-kindedfor<'a> FnOnce(SomeType<'a>)
-style callback.I’m relatively certain that the
AutoreleaseSafe
example suffers from the same issue.Of course one approach would be to declare
scoped-tls
unsound on the (arguably quite thin) grounds that the standard library only sets precedent that'static
data is allowed to be shared via thread-local storage. Assuming we don’t declarescoped-tls
unsound, an auto traits feature seems entirely unable to be a solution for sound API in either of the API cases forAutoreleaseSafe
norUngil
.GoldsteinE commentedon Dec 11, 2023
Oh, that’s really sad. If
scoped-tls
is valid (and I don’t see a reason for it not to be), thenauto trait Ungil
can only make pyo3 less-obviously-unsound instead of sound. IMHO that’s still a valid reason for it to be an auto trait, but it’s really unfortunate that it doesn’t just make it clean and sound.madsmtm commentedon Dec 11, 2023
Hmm, I don't think that's a problem for
objc2
'sAutoreleaseSafe
, since the only type it's used on isAutoreleasePool<'pool>
, whose only purpose is to carry a lifetime (it's a ZST that doesn't actually carry any data), which it seems likescoped-tls-hkt
manages to properly bind to the execution of the closure.So even though we can access the pool, we can't actually do anything bad with it, since it's only the lifetime that we care about, and that is still correctly bounded. See the following example for details.
If you manage to produce a similar example that does compile, then I'd love to know!
steffahn commentedon Dec 11, 2023
@madsmtm Here we go:
Python::allow_threads
is unsound in the presence ofscoped-tls
. PyO3/pyo3#3640impl Send + Sync
and overridecount
for theCStr::bytes
iterator #127444Auto merge of rust-lang#13231 - Jarcho:no_tree_walk_in_const, r=Alexe…
Zenithsiz commentedon May 6, 2025
Is it possible to make an auto trait not depend on the fields of a type?
I'd like to be able to have an auto trait
auto trait Everything {}
, and a typestruct Wrapper<T>(T)
such that an auto-trait is always implemented forWrapper
regardless ofT: Everything
(unless there's an explicitimpl !Everything for Wrapper<...> {}
).Further motivation
I have a normal trait with a default implementation depending on an auto trait:
I then have 2 types,
Normal
which just wants the default impl andSpecial
which wants to do a special implementation:The issues happen downstream, where a consumer of
Normal
cannot callset
on a genericT
, only onT: WantsAutoSet
:(See the playground)
This can be fixed by just using
impl<T> WantsAutoSet for Normal<T> {}
, (or by havingNormal
not have a type parameter), but I have a lot of theseNormal
-like types and I don't want to need to make this impl for each one, since at that point I'd just make it a normal trait instead of an auto trait.Also these
Normal
-like types do need ownership ofT
for theSet
impl, I can't just usePhantomData
to wave it away somehow.(Also note that this is somewhat like specialization, but I can't just use actual specialization because the
Special
impl ofSet
has different bounds that are incompatible (i.e. not a subset), and I'd also like to "disable" the default implementation because it'd inefficient forSpecial
, which wouldn't work with specialization.)