Because I'm still 😷😷😷 , I figured some mindless tasks would be better than trying to finish the ownership guide.
The manual has long been waiting for some ❤️❤️❤️ , and so I gave it a quick once-over. I made small commits in case any of the changes are a bit weird, I mostly did a few things:
1. changed 'manual' to 'reference.' I feel like this name is better. If it's not, It's not a huge deal. it shouldn't be `rust.md` though.
2. word wrapped everything appropriately. Changes 1&2 are in the first commit, so that its' easier to see the changes in the later ones.
3. fixed other small style issues
4. removed references to things that are in the standard library, and not the language itself
There's still lots of gross in here, but I didn't want to pile on too too many changes.
/cc @brson @nikomatsakis
See: http://doc.rust-lang.org/std/from_str/trait.FromStr.html
```
let input_num = from_str::<Option<uint>>("5");
```
```
<anon>:2:21: 2:45 error: failed to find an implementation of trait std::from_str::FromStr for core::option::Option<uint>
<anon>:2 let input_num = from_str::<Option<uint>>("5");
^~~~~~~~~~~~~~~~~~~~~~~~
```
While reading the intro, I was confused as to why there were two variables named "numbers". Unless I'm mistaken and it's not necessary, let's get rid of it to make it clearer.
This breaks code like:
struct Foo {
...
}
pub fn make_foo() -> Foo {
...
}
Change this code to:
pub struct Foo { // note `pub`
...
}
pub fn make_foo() -> Foo {
...
}
The `visible_private_types` lint has been removed, since it is now an
error to attempt to expose a private type in a public API.
Closes#16463.
RFC #48.
[breaking-change]
r? @alexcrichton
This breaks code like:
struct Foo {
...
}
pub fn make_foo() -> Foo {
...
}
Change this code to:
pub struct Foo { // note `pub`
...
}
pub fn make_foo() -> Foo {
...
}
The `visible_private_types` lint has been removed, since it is now an
error to attempt to expose a private type in a public API. In its place
a `#[feature(visible_private_types)]` gate has been added.
Closes#16463.
RFC #48.
[breaking-change]
Closes#17185.
The stability lint will now check code generated by macro expansion. It will allow to detect :
- arguments passed to macros using deprecated (and others) items
- macro expansion generating code using deprecated items due to its arguments (hence the second commit, fixing such issue found in libcollections)
Checking is still done at expansion, but it will also detect a macro explicitly using a deprecated item in its definition.
- Don't attempt to autoderef `!`. The `Deref`/`DerefMut` trait lookup would generate a bunch of unhelpful error spew.
- Don't allow explicit deref of `!`, since later passes just ICE. This closes issue #17373
- Don't allow explicit index of `!`, since later passes just ICE. There does not seem to be an issue associated with this
This is just true of all of Rust, and doesn't make a lot of sense now.
Especially as we move towards finalizing things, I think it's time for
this to go.
This commit deprecates the String::shift_char() function in favor of the
addition of an insert()/remove() pair of functions. This aligns the API with Vec
in that characters can be inserted at arbitrary positions. Additionaly, there
is no `_char` suffix due to the rationaled laid out in the previous commit.
These functions are both introduced as unstable as their failure semantics,
while in line with slices/vectors, are uncertain about whether they should
remain the same.
