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

Allow trait-less impls on primitive types when in the corresponding libcore module for each type #6065

Closed
bstrie opened this issue Apr 25, 2013 · 4 comments
Labels
A-type-system Area: Type system

Comments

@bstrie
Copy link
Contributor

bstrie commented Apr 25, 2013

I filed #6045 before I realized that you have to make useless traits to implement methods on primitives. However, we already use lang items to identify core::char as the "canonical" char module, yes? Is it possible then to allow impls directly upon char from within core::char, since we know that it won't have anonymous impls anywhere else? This is what I'd like to be able to do:

impl char {
    fn anything() { ... }
}

without having to make a useless trait first:

trait UselessCharTrait {
    fn anything();
}

impl UselessCharTrait for char {
    fn anything() { ... }
}

This is somewhat more pertinent now that #3048 is WONTFIX.

@emberian
Copy link
Member

emberian commented Jul 7, 2013

Still relevant. I thought a potential solution was to move the builtin types to std::unstable, and do like struct char(std::unstable::builtin_char), but @thestinger pointed out newtypes were still buggy. He came up with the idea of #[lang="char"] struct char {priv c: u32}

@thestinger
Copy link
Contributor

This would be incredibly nice to have, in order to clear out a bunch of useless one use traits.

@eddyb
Copy link
Member

eddyb commented Dec 29, 2013

I would rather have the compiler provide the type, but it could be "owned" by the crate which defines it.

#[lang="char"] struct char;
// `char` is now a type defined in the same crate,
// but behaves just like the current built-in type.
impl char {...}

@rust-highfive
Copy link
Collaborator

This issue has been moved to the RFCs repo: rust-lang/rfcs#286

flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 24, 2020
…-macro, r=Manishearth

Forbid redundant_pattern_matching triggering in macros

fixes rust-lang#6065

changelog: forbid redundant_pattern_matching triggering in macros
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

5 participants