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.
As per [RFC 52](https://github.com/rust-lang/rfcs/blob/master/active/0052-ownership-variants.md), use `_mut` suffixes to mark mutable variants, and `into_iter` for moving iterators. Additional details and motivation in the RFC.
Note that the iterator *type* names are not changed by this RFC; those are awaiting a separate RFC for standardization.
Closes#13660Closes#16810
[breaking-change]
This patch does not make many functional changes, but does a lot of restructuring towards the goals of #5527. This is the biggest patch, basically, that should enable most of the other patches in a relatively straightforward way.
Major changes:
- Do not track impls through trans, instead recompute as needed.
- Isolate trait matching code into its own module, carefully structure to distinguish various phases (selection vs confirmation vs fulfillment)
- Consider where clauses in their more general form
- Integrate checking of builtin bounds into the trait matching process, rather than doing it separately in kind.rs (important for opt-in builtin bounds)
What is not included:
- Where clauses are still not generalized. This should be a straightforward follow-up patch.
- Caching. I did not include much caching. I have plans for various kinds of caching we can do. Should be straightforward. Preliminary perf measurements suggested that this branch keeps compilation times roughly what they are.
- Method resolution. The initial algorithm I proposed for #5527 does not work as well as I hoped. I have a revised plan which is much more similar to what we do today.
- Deref vs deref-mut. The initial fix I had worked great for autoderef, but not for explicit deref.
- Permitting blanket impls to overlap with specific impls. Initial plan to consider all nested obligations before considering an impl to match caused many compilation errors. We have a revised plan but it is not implemented here, should be a relatively straightforward extension.
The wording is correct if you consider that two of these lines were extracted from the original example. It still tripped me up while reading, so i just removed any reference to the linecount.
This closes#17260. The guide references the old install location for
the windows rust install before it was split into 64bit and 32bit
installers. This adds a link to each binary.
1000 tasks * 2MiB stack size -> 2GiB of virtual memory
On a 64-bit OS, a 32-bit executable has 4GiB available, but the kernel
gets half of the available address space so the limit is 2GiB on 32-bit.
Closes#17044
This isn't ready to merge yet.
The 'containers and iterators' guide is basically just a collection of stuff that should be in the module definitions. So I'm moving the guide to just an 'iterators' guide, and moved the info that was there into the right places.
So, is this a good path forward, and is all of the information still correct?
The Guide isn't 100% perfect, but it's basically complete. It's
certainly better than the tutorial is. Time to start pointing more
people its way.
I also just made it consistent to call all things 'guides' rather than
tutorials.
Fixes#9874. This is the big one.
And two bugs that just go away.
Fixes#14503.
Fixes#15009.
The Guide isn't 100% perfect, but it's basically complete. It's
certainly better than the tutorial is. Time to start pointing more
people its way.
I also just made it consistent to call all things 'guides' rather than
tutorials.
Fixes#9874. This is the big one.
And two bugs that just go away.
Fixes#14503.
Fixes#15009.
This allows code to access the fields of tuples and tuple structs behind the feature gate `tuple_indexing`:
```rust
#![feature(tuple_indexing)]
let x = (1i, 2i);
assert_eq!(x.1, 2);
struct Point(int, int);
let origin = Point(0, 0);
assert_eq!(origin.0, 0);
assert_eq!(origin.1, 0);
```
Implements [RFC 53](https://github.com/rust-lang/rfcs/blob/master/active/0053-tuple-accessors.md). Closes#16950.
This part can get _really_ confusing, and we want to make sure that
people succeed in the guide. I plan on making a module guide in the
future to replace the information here.
This allows code to access the fields of tuples and tuple structs:
let x = (1i, 2i);
assert_eq!(x.1, 2);
struct Point(int, int);
let origin = Point(0, 0);
assert_eq!(origin.0, 0);
assert_eq!(origin.1, 0);
instead of prefix `..`.
This breaks code that looked like:
match foo {
[ first, ..middle, last ] => { ... }
}
Change this code to:
match foo {
[ first, middle.., last ] => { ... }
}
RFC #55.
Closes#16967.
[breaking-change]
This breaks code that uses the `..xs` form anywhere but at the end of a
slice. For example:
match foo {
[ 1, ..xs, 2 ]
[ ..xs, 1, 2 ]
}
Add the `#![feature(advanced_slice_patterns)]` gate to reenable the
syntax.
RFC #54.
Closes#16951.
[breaking-change]
This unifies the `non_snake_case_functions` and `uppercase_variables` lints
into one lint, `non_snake_case`. It also now checks for non-snake-case modules.
This also extends the non-camel-case types lint to check type parameters, and
merges the `non_uppercase_pattern_statics` lint into the
`non_uppercase_statics` lint.
Because the `uppercase_variables` lint is now part of the `non_snake_case`
lint, all non-snake-case variables that start with lowercase characters (such
as `fooBar`) will now trigger the `non_snake_case` lint.
New code should be updated to use the new `non_snake_case` lint instead of the
previous `non_snake_case_functions` and `uppercase_variables` lints. All use of
the `non_uppercase_pattern_statics` should be replaced with the
`non_uppercase_statics` lint. Any code that previously contained non-snake-case
module or variable names should be updated to use snake case names or disable
the `non_snake_case` lint. Any code with non-camel-case type parameters should
be changed to use camel case or disable the `non_camel_case_types` lint.
[breaking-change]
This cleans up blatant lies in the concurrency guide, and modernizes it
a bit. There's a lot more to do, but until I get to it, let's make it a
little bit better.
This cleans up blatant lies in the concurrency guide, and modernizes it
a bit. There's a lot more to do, but until I get to it, let's make it a
little bit better.
We have to specify the module and the function name in the example where
the module shares a crate with the executable as well, so remove the
redundant (and potentially confusing) mention.
For review. Not sure about the link_attrs stuff. Will work on converting all the tests.
extern crate "foobar" as foo;
extern crate foobar as foo;
Implements remaining part of RFC #47.
Addresses issue #16461.
Removed link_attrs from rust.md, they don't appear to be supported by
the parser.
We have to specify the module and the function name in the example where
the module shares a crate with the executable as well, so remove the
redundant (and potentially confusing) mention.
Also:
* Remove unseeming repetition.
* By now, the reader has already heard that Rust is safe by default, so
reduce the overlong sentence, making it easier to read.
Implements remaining part of RFC #47.
Addresses issue #16461.
Removed link_attrs from rust.md, they don't appear to be supported by
the parser.
Changed all the tests to use the new extern crate syntax
Change pretty printer to use 'as' syntax
