Skip to content
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

[Specialization] Alternatve Minimal implementation: only allow whole-impl specialization, haskell style #125295

Open
lolbinarycat opened this issue May 19, 2024 · 5 comments
Labels
A-specialization Area: Trait impl specialization C-discussion Category: Discussion or questions that doesn't represent real issues. F-specialization `#![feature(specialization)]`

Comments

@lolbinarycat
Copy link

Many of the difficulties #31844 has encountered come from dealing with things that happen when some but not all of a trait's items are overridden. I would argue that this is overkill for the common usecase of making blanket impls not conflict with more specific impls. this would also address the most common reason for people asking for negative type constraints.

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label May 19, 2024
@workingjubilee
Copy link
Contributor

Rust does not have Haskell's type system, it has a much more complicated one (unless you mean "Haskell with approximately 100 compiler features enabled", in which case it has a much simpler one), so, while I'm not sure if this is the best venue for such a proposal, in whatever venue you do take it to, you're going to want to actually explain what you mean.

@workingjubilee workingjubilee added the C-discussion Category: Discussion or questions that doesn't represent real issues. label May 20, 2024
@lolbinarycat
Copy link
Author

in my proposal there would be two types of impl blocks: regular impl and default impl. it is legal for a default impl block to conflict with a regular impl block. for types with two matching implementations of a trait, the regular impl gets priority over the default impl. it is not legal for two impls of the same priority to overlap.

@SkiFire13
Copy link
Contributor

Many of the difficulties #31844 has encountered come from dealing with things that happen when some but not all of a trait's items are overridden.

AFAIK the main soundness problem is with specialized implementation applying depending on some lifetimes. How are you proposing to solve that?

@lolbinarycat
Copy link
Author

could you give an example of code that would be potentially unsound under this proposal?

@SkiFire13
Copy link
Contributor

See #40582 for an example. This old blogpost has a nice explanation of what's the fundamental problem with specialization, along with a bunch of other tricky examples.

@jieyouxu jieyouxu added A-specialization Area: Trait impl specialization F-specialization `#![feature(specialization)]` and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-specialization Area: Trait impl specialization C-discussion Category: Discussion or questions that doesn't represent real issues. F-specialization `#![feature(specialization)]`
Projects
None yet
Development

No branches or pull requests

5 participants