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

std::str::StrSlice needs documentation #9370

Closed
luisbg opened this issue Sep 20, 2013 · 2 comments
Closed

std::str::StrSlice needs documentation #9370

luisbg opened this issue Sep 20, 2013 · 2 comments

Comments

@luisbg
Copy link
Contributor

luisbg commented Sep 20, 2013

Reporting the issue here to assign it to myself and soon push a Pull Request against it.

@luisbg
Copy link
Contributor Author

luisbg commented Sep 21, 2013

This is a bug in the language.

There are two rules on implementing a trait. Either one of the rules must be met, always. Or both. Never none.

  1. The trait must be defined in your own crate
  2. The type you're implementing the trait for must be in your own crate

This is so that you can always combine any two crates and not get conflicting implementations (coherency).
libstd has a special position in that it defines all of the methods on the builtins, but it doesn't define the types

You can't just say "impl int", or "impl ~str", you need to have a "dummy" trait like StrSlice
So that you meet one of the rules, specifically rule 1

The thing to fix is to be able to add an attribute that says "pretend that this crate defines this builtin type so I can give it methods directly", a 3rd rule to the coherency rules that only applies ot builtins

@luisbg
Copy link
Contributor Author

luisbg commented Sep 21, 2013

So the issue reported is something completely different and out of scope. Closing this issue then.

@luisbg luisbg closed this as completed Sep 21, 2013
Jarcho pushed a commit to Jarcho/rust that referenced this issue Aug 29, 2022
Replace `contains_ty(..)` with `Ty::contains(..)`

This removes some code we don't need and the method syntax is
also more readable IMO.

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant