As a new user, I spent a while confused when flycheck told me the code sample I'd typed in was invalid. I ended up figuring out some of what comes after the code sample more painfully by myself because there was no indication that it was broken in the text beforehand. This one line change makes it clear that the code following it is an experiment that may not work rather than something to assume just works.
This removes some leftover line-numbering cruft from elided error examples and brings some minor clarifications.
I’m not super happy about the ‘we cannot have two mutable pointers that point to the same memory’ wording (to the best of my understanding we can’t even have one mutable and one immutable), but other attempts to word this were derailing the flow a bit too much.
* Moves multi-collection files into their own directory, and splits them into seperate files
* Changes exports so that each collection has its own module
* Adds underscores to public modules and filenames to match standard naming conventions
(that is, treemap::{TreeMap, TreeSet} => tree_map::TreeMap, tree_set::TreeSet)
* Renames PriorityQueue to BinaryHeap
* Renames SmallIntMap to VecMap
* Miscellanious fallout fixes
[breaking-change]
I think it helps to show that the variables introduced in match blocks are indeed independent from the matched variable `x` (especially when `x` is still reachable inside those blocks and might be useful), so this renames them accordingly. Maybe some linter (or language-level warning?) will eventually warn about shadowing `x` in such cases. ;)
I’m not super happy about the matching-on-range example, as it’s too contrived (`e` and `x` are exactly the same here), but I couldn’t come up with something both simple and non-redundant.
This in-progress PR implements https://github.com/rust-lang/rust/issues/17489.
I made the code changes in this commit, next is to go through alllllllll the documentation and fix various things.
- Rename column headings as appropriate, `# Panics` for panic conditions and `# Errors` for `Result`s.
- clean up usage of words like 'fail' in error messages
Anything else to add to the list, @aturon ? I think I should leave the actual functions with names like `slice_or_fail` alone, since you'll get to those in your conventions work?
I'm submitting just the code bits now so that we can see it separately, and I also don't want to have to keep re-building rust over and over again if I don't have to 😉
Listing all the bits so I can remember as I go:
- [x] compiler-rt
- [x] compiletest
- [x] doc
- [x] driver
- [x] etc
- [x] grammar
- [x] jemalloc
- [x] liballoc
- [x] libarena
- [x] libbacktrace
- [x] libcollections
- [x] libcore
- [x] libcoretest
- [x] libdebug
- [x] libflate
- [x] libfmt_macros
- [x] libfourcc
- [x] libgetopts
- [x] libglob
- [x] libgraphviz
- [x] libgreen
- [x] libhexfloat
- [x] liblibc
- [x] liblog
- [x] libnative
- [x] libnum
- [x] librand
- [x] librbml
- [x] libregex
- [x] libregex_macros
- [x] librlibc
- [x] librustc
- [x] librustc_back
- [x] librustc_llvm
- [x] librustdoc
- [x] librustrt
- [x] libsemver
- [x] libserialize
- [x] libstd
- [x] libsync
- [x] libsyntax
- [x] libterm
- [x] libtest
- [x] libtime
- [x] libunicode
- [x] liburl
- [x] libuuid
- [x] llvm
- [x] rt
- [x] test
This includes updating the language items and marking what needs to
change after a snapshot.
If you do not use the standard library, the language items you need to
implement have changed. For example:
```rust
#[lang = "fail_fmt"] fn fail_fmt() -> ! { loop {} }
```
is now
```rust
#[lang = "panic_fmt"] fn panic_fmt() -> ! { loop {} }
```
Related, lesser-implemented language items `fail` and
`fail_bounds_check` have become `panic` and `panic_bounds_check`, as
well. These are implemented by `libcore`, so it is unlikely (though
possible!) that these two renamings will affect you.
[breaking-change]
Fix test suite
https://github.com/rust-lang/rfcs/pull/221
The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.
Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.
We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.
To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:
grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'
You can of course also do this by hand.
[breaking-change]
Some minor wording fixes to the Closures chapter; my brain tripped a few times when reading it, so I tried to come up with something a bit smoother. I’m not a native speaker, so please do review this critically.
Explain that Rust has different pointer types because there is a
tradeoff between flexibility and efficiency. Motivate boxes as
fixed-size containers of variable-sized objects. Clarify that Box and Rc
are pointer types that you deref with * just like references. Stick to
explaining the semantics and avoid implementation details. Scope isn't
the most accurate framework to think about deallocation (since you
return boxes and otherwise move values out of scopes); it's more "when
the value is done being used," i.e., lifetime. Provide a connection
between Rust's pointer types by locating them on a flexibiltiy /
performance scale. Explain the compiler can't statically analyze
lifetimes with multiple owners; hence the need for (runtime) reference
counting.
This should be clearer, and fits in better with the `TTNonterminal` variant.
Renames:
- `TTTok` -> `TTToken`
- `TTDelim` -> `TTDelimited`
- `TTSeq` -> `TTSequence`
Explain the primary disadvantage of garbage collection is runtime
overhead and unpredictable pauses. Elucidate where the name "race
condition" comes from. Emphasize that Rust can guarantee your code is
free of race conditions and other memory errors, with no runtime
overhead.
cc @steveklabnik
This patch contains a fix for:
- single quote around string slice
- string: String is confusing for newbies and it's more readble if the
argument name is different that the argument type name
Explain the primary disadvantage of garbage collection is runtime
overhead and unpredictable pauses. Elucidate where the name "race
condition" comes from. Emphasize that Rust can guarantee your code is
free of race conditions and other memory errors, with no runtime
overhead.
This is an almost-done draft of a guide on crates and modules. This is a hard guide to get right, I had to remove a chunk of the Guide because it was confusing.
I've also pushed up https://github.com/steveklabnik/phrases which has matching code. Whenever we finish this guide, I think it'd be good to have a sample crate like this in the rust-lang org for people to compare against. The hardest part of a guide like this is that it depends on multiple files being correct, and being able to point to a repository would be very helpful.
Things yet to do:
1. external crates via cargo
2. documentation
I'm super open to still revising this if it's still confusing. There's been a lot of Reddit discussion about the module system, and I tried to incorporate those posts and the comments into this.
Use a match expression directly in the println statement, instead of creating a second variable. It seems weird that the current guide.md complains about creating an extra variable, when the same feature could be demonstrated without creating the extra variable.
The array is the fundamental concept; vectors are growable arrays, and
slices are views into either. Show common array ops up front: length
and iteration. Mention arrays are immutable by default. Highlight
definite initialization and bounds-checking as safety features. Show
that you only need a type suffix on one element of initializers.
Explain that vectors are a value-add library type over arrays, not a
fundamental type; show they have the same "interface." Motivate slices
as efficient views into arrays; explain you can slice vectors, Strings,
&str because they're backed by arrays.
All deprecation warnings have been converted to errors. This includes
the warning for multiple cfgs on one item. We'll leave that as an error
for some period of time to ensure that all uses are updated before the
behavior changes from "or" to "and".
All deprecation warnings have been converted to errors. This includes
the warning for multiple cfgs on one item. We'll leave that as an error
for some period of time to ensure that all uses are updated before the
behavior changes from "or" to "and".
The old version switched in between examples from the value `5i` to `"Hello"` and back.
Additionally, the code generated by `rustc print.rs --pretty=expanded` is not as verbose anymore.
Currently, the Guide says tuples "are only equivalent if the arity, types, and values are all identical", before presenting an example that uses `==` to compare two tuples whose arity and contained types match. This is misleading, because it implies that `==` can dynamically check whether two tuples have the same arity and contained types, whereas trying to do this would lead to a compiler error.
I tried to avoid destroying the flow of this section, but I'm not sure if I've been successful.
Because my '30 minute intro' was originally a blog post, the tone was a bit too light. It also was written a long time ago, and deserves a bit of a refresher for modern Rust. now that my work on the Guide is wrapping up, I want to give it a quick re-write as well.
This is not yet done, but I'm submitting it for feedback so far. I'd really like some comments on the ownership part in particular, which gets lower level than before, but is not strictly 100% accurate. Trying to strike a balance.
In general, I'm not sure I go into enough detail for those without systems experience, but am afraid of too much detail for those that do.
Rendered view: https://github.com/steveklabnik/rust/blob/intro_redux/src/doc/intro.md
/cc @wycats @nikomatsakis @brson etc
The old version switched in between examples from the value `5i` to `"Hello"`
and back. Additionally, the code generated by `rustc print.rs
--pretty=expanded` is not as verbose anymore.
Hi,
These are a few small edits to the Guide that I made while reading online. Really well done and approachable.
I have a few questions below, but I don't know if this is the proper place to ask them, so feel free to ignore the below.
1. Trailing commas seem to be a convention in Rust and are used quite a bit throughout the Guide, but are never explicitly mentioned. Maybe adding a short mention about them when they first appear in the Structs section might be helpful to those who are unfamiliar with or don't use them in other languages.
2. In the Iterators section, there is a block of code like this:
```rust
let mut range = range(0i, 10i);
loop {
match range.next() {
Some(x) => {
println!("{}", x);
} // no comma needed?
None => { break }
}
}
```
My inclination would be to put a comma where the comment is to separate the two arms to get this to compile, but it runs fine either way. Is there a convention on commas for scenarios like this where each arm is enclosed in `{}`?
All the best,
O-I
Oddly (to me), this code runs fine without the comma separating the `Some` and `None` arms of the `match` construct. It seems like Rust doesn't require you to separate arms with commas if all the expressions are enclosed in braces.
Mention that using `pub` is called exporting.
Remove that `use` is called re-exporting, because `pub use` should be
called re-exporting. The guide currently doesn't cover `pub use`.
It's a rather useful syntax, and non-obvious.
A friend of mine is learning Rust and was trying to find a way to easily do such an initialization — he couldn't find it in the guide and was pretty surprised when I showed him. Looks like something that should be mentioned.
r? @steveklabnik
The sentence "The new iterator `filter()` produces returns only the elements that that closure returned `true` for:" can be structured as:
"The new iterator `filter()` produces only the elements that that closure returned `true` for:"
or as:
"The new iterator `filter()` returns only the elements that that closure returned `true` for:"
however, not both.
I went with "produces", since it then talks about returning true and having "return" so close together doesn't sound nice.
r @steveklabnik ?
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");
^~~~~~~~~~~~~~~~~~~~~~~~
```
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.
The implementation essentially desugars during type collection and AST
type conversion time into the parameter scheme we have now. Only fully
qualified names--e.g. `<T as Foo>::Bar`--are supported.
