From 9b40614a64de1c247ef95b43cbe1f4e6d169c2dc Mon Sep 17 00:00:00 2001 From: Niko Matsakis Date: Mon, 16 Nov 2015 12:08:32 -0500 Subject: [PATCH] Accept RFC #1268. Add notes on motivation and unresolved questions. --- ...llow-overlapping-impls-on-marker-traits.md | 29 ++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) rename 0000-allow-overlapping-impls-on-marker-traits.md => text/1268-allow-overlapping-impls-on-marker-traits.md (73%) diff --git a/0000-allow-overlapping-impls-on-marker-traits.md b/text/1268-allow-overlapping-impls-on-marker-traits.md similarity index 73% rename from 0000-allow-overlapping-impls-on-marker-traits.md rename to text/1268-allow-overlapping-impls-on-marker-traits.md index 1dfcba35587..0df23acbb26 100644 --- a/0000-allow-overlapping-impls-on-marker-traits.md +++ b/text/1268-allow-overlapping-impls-on-marker-traits.md @@ -18,6 +18,14 @@ While specialization will certainly make all cases not covered today possible, removing the restriction entirely will improve the ergonomics in several edge cases. +Some examples include: + +- the coercible trait design presents at [RFC #91][91]; +- the `ExnSafe` trait proposed in [RFC #1236][1236]. + +[91]: https://github.com/rust-lang/rfcs/pull/91 +[1236]: https://github.com/rust-lang/rfcs/pull/1236 + # Detailed design For the purpose of this RFC, the definition of a marker trait is a trait with no @@ -110,4 +118,23 @@ specify the empty impl for any overlap that might occur. # Unresolved questions -None at this time. +How can we implement this design? Simply lifting the coherence +restrictions is easy enough, but we will encounter some challenges +when we come to test whether a given trait impl holds. For example, if +we have something like: + +```rust +impl MarkerTrait for T { } +impl MarkerTrait for T { } +``` + +means that a type `Foo: MarkerTrait` can hold *either* by `Foo: Send` +*or* by `Foo: Sync`. Today, we prefer to break down an obligation like +`Foo: MarkerTrait` into component obligations (e.g., `Foo: Send`). Due +to coherence, there is always one best way to do this (sort of --- +where clauses complicate matters). That is, except for complications +due to type inference, there is a best impl to choose. But under this +proposal, there would not be. Experimentation is needed (similar +concerns arise with the proposals around specialization, so it may be +that progress on that front will answer the questions raised here). +