-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for specialization (RFC 1210) #31844
Comments
Some additional open questions:
|
I am not sure that specialization changes the orphan rules:
Worse than that, the "future compatibility" orphan rules keep cross-crate specialization under pretty heavy control. Without them, default-impls leaving their methods open becomes much worse. I never liked explicit negative reasoning. I think the total negative reasoning specialization provides is a nice compromise. |
Should this impl be allowed with specialization as implemented? Or am I missing something? |
Same with this one, would have expected it to compile: http://is.gd/RyFIEl |
Looks like there's some quirks in determining overlap when associated types are involved. This compiles: http://is.gd/JBPzIX, while this effectively identical code doesn't: http://is.gd/0ksLPX |
Here's a piece of code I expected to compile with specialization: #![feature(specialization)]
use std::str::FromStr;
struct Error;
trait Simple<'a> {
fn do_something(s: &'a str) -> Result<Self, Error>;
}
impl<'a> Simple<'a> for &'a str {
fn do_something(s: &'a str) -> Result<Self, Error> {
Ok(s)
}
}
impl<'a, T: FromStr> Simple<'a> for T {
fn do_something(s: &'a str) -> Result<Self, Error> {
T::from_str(s).map_err(|_| Error)
}
}
fn main() {
// Do nothing. Just type check.
} Compilation fails with the compiler citing implementation conflicts. Note that |
Experimented with the new impl specialization features of Rust. They work! But they're not quite there yet. Specifically, I was able to specialize on `Responder`, but when trying to remove the macro in `FromParam`, it didn't work. See rust-lang/rust#31844.
I had time to look at the first two examples. Here are my notes. Example 1First case, you have:
The problem is that these impls overlap but neither is more specific than the other:
This is the kind of situation that lattice impls would allow -- you'd have to write a third impl for the overlapping case, and say what it should do. Alternatively, negative trait impls might give you a way to rule out overlap or otherwise tweak which matches are possible. Example 2You have:
These overlap because you can have
But neither impl is more specific:
|
The problem is that the compiler is conservatively assuming that This is a conservative choice, and is something we might want to relax over time. You can get the background here: |
Thank you for clarifying those two cases. It makes complete sense now On Tue, Mar 22, 2016, 6:34 PM Aaron Turon notifications@github.com wrote:
|
Isn't this exactly what specialization is trying to address? With specialization, I would expect that even if an implementation of |
@SergioBenitez you need to put On Tue, Mar 22, 2016, 6:54 PM Sergio Benitez notifications@github.com
|
I think "default" trait items being automatically considered |
Note from #32999 (comment): if we do go with the lattice rule (or allow negative constraints), the "use an intermediate trait" trick to prevent further specialization of something will no longer work. |
Why won't it work? The trick limits the specialization to a private trait. You can't specialize the private trait if you can't access it. |
@arielb1 Ah. Good point. In my case, the trait isn't private. |
I don't think the "externals can't specialize because orphan forward-compatibility + coherence rulea" reasoning is particularly interesting or useful. Especially when we don't commit to our specific coherence rules. |
Is there a way to access an overridden |
Allowing projection of default associated types during type-checking will allow enforcing type inequality at compile-time: https://gist.github.com/7c081574958d22f89d434a97b626b1e4 #![feature(specialization)]
pub trait NotSame {}
pub struct True;
pub struct False;
pub trait Sameness {
type Same;
}
mod internal {
pub trait PrivSameness {
type Same;
}
}
use internal::PrivSameness;
impl<A, B> Sameness for (A, B) {
type Same = <Self as PrivSameness>::Same;
}
impl<A, B> PrivSameness for (A, B) {
default type Same = False;
}
impl<A> PrivSameness for (A, A) {
type Same = True;
}
impl<A, B> NotSame for (A, B) where (A, B): Sameness<Same=False> {}
fn not_same<A, B>() where (A, B): NotSame {}
fn main() {
// would compile
not_same::<i32, f32>();
// would not compile
// not_same::<i32, i32>();
} edited per @burdges' comment |
Just fyi @rphmeier one should probably avoid is.gd because it does not resolve for Tor users due to using CloudFlare. GitHub works fine with full URLs. And play.rust-lang.org works fine over Tor. |
@burdges FWIW play.rust-lang.org itself uses is.gd for its "Shorten" button. It can probably be changed, though: https://github.com/rust-lang/rust-playpen/blob/9777ef59b/static/web.js#L333 |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
The The compiler warns:
So, for now use |
This comment was marked as off-topic.
This comment was marked as off-topic.
Tracking issues have a tendency to become unmanageable. Please open a dedicated new issue and label it with
F-specialization
|
Ugh, Github's noise combined with Github's infuriating collapsing comment behavior has hidden Oli's most recent comment. Reposting:
|
I've added that to the top comment for visibility. |
This is a tracking issue for specialization (rust-lang/rfcs#1210).
Major implementation steps:
default impl
(supportdefault impl
for specialization #37653)default
members? 🛠️ specialization permits empty impls when parent has no default items #48444Unresolved questions from the RFC:
default type
? Never during typeck? Or when monomorphic?default
(i.e. specializable)?default impl
(where all items aredefault
) orpartial impl
(wheredefault
is opt-in); see supportdefault impl
for specialization #37653 (comment) for some relevant examples of wheredefault impl
is limiting.Note that the
specialization
feature as implemented currently is unsound, which means that it can cause Undefined Behavior withoutunsafe
code.min_specialization
avoids most of the pitfalls.Tracking issues have a tendency to become unmanageable. Please open a dedicated new issue and label it with F-specialization for absolutely any topics you want to discuss or have questions about. See rust-lang/compiler-team#739 for details and discussions on this prospective policy.
The text was updated successfully, but these errors were encountered: