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 should allow for delegation to default trait method implementation #68309

Open
jazzfool opened this issue Jan 17, 2020 · 4 comments
Labels
A-specialization Area: Trait impl specialization C-feature-request Category: A feature request, i.e: not implemented / a PR. F-associated_type_defaults `#![feature(associated_type_defaults)]` F-specialization `#![feature(specialization)]` T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@jazzfool
Copy link

Given the following trait:

trait Trait {
    fn test(&self) { println!("default implementation"); }
}

To provide a default specialization on Trait::test, test must be redefined;

impl<T> Trait for T {
    default fn test(&self) { println!("default implementation"); }
}

However this violates the DRY principle. The solution here would be to provide a way to delegate the implementation of test to the already existing default implementation found in the trait definition.

Proposed syntax to allow for this delegation:

impl<T> Trait for T {
    default fn test(&self);
}
@jazzfool
Copy link
Author

cc @Centril

@Centril Centril added C-feature-request Category: A feature request, i.e: not implemented / a PR. F-specialization `#![feature(specialization)]` T-lang Relevant to the language team, which will review and decide on the PR/issue. F-associated_type_defaults `#![feature(associated_type_defaults)]` labels Jan 17, 2020
@Centril
Copy link
Contributor

Centril commented Jan 17, 2020

I believe this is intentional fallout from #64564 (cc @jonas-schievink).

Having some sort of forwarding syntax to recover DRY seems reasonable and default fn test(&self); isn't a bad one.

@jonas-schievink
Copy link
Contributor

Yup, sounds reasonable to me. I noticed the amount of repetition when working on that PR too:

One annoyance with doing this is that it sometimes requires users to copy-paste a provided trait method into an impl just to mark it default (ie. there is no syntax to forward this impl method to the provided trait method).

@Centril
Copy link
Contributor

Centril commented Jan 17, 2020

Syntactic support for default fn test(&self); in an impl should already be there after #67131. To support it semantically we would need changes in lowering and beyond.

@jonas-schievink jonas-schievink added the A-specialization Area: Trait impl specialization label Jan 17, 2020
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-feature-request Category: A feature request, i.e: not implemented / a PR. F-associated_type_defaults `#![feature(associated_type_defaults)]` F-specialization `#![feature(specialization)]` T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants