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.
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
The last two sections of the guide, and a small conclusion. I suck at conclusions.
I also realized I never covered strings, so I'm going to put that section up before we're actually 'done.'
declared with the same name in the same scope.
This breaks several common patterns. First are unused imports:
use foo::bar;
use baz::bar;
Change this code to the following:
use baz::bar;
Second, this patch breaks globs that import names that are shadowed by
subsequent imports. For example:
use foo::*; // including `bar`
use baz::bar;
Change this code to remove the glob:
use foo::{boo, quux};
use baz::bar;
Or qualify all uses of `bar`:
use foo::{boo, quux};
use baz;
... baz::bar ...
Finally, this patch breaks code that, at top level, explicitly imports
`std` and doesn't disable the prelude.
extern crate std;
Because the prelude imports `std` implicitly, there is no need to
explicitly import it; just remove such directives.
The old behavior can be opted into via the `import_shadowing` feature
gate. Use of this feature gate is discouraged.
This implements RFC #116.
Closes#16464.
[breaking-change]
This fixes#16451.
While moving things around, I also removed a bunch of unnecessary whitespace, however I can put it back in if that's undesired.
Thanks.
* `rust.md`: changes for consistency
* `guide-ffi.md`: wrapped inline code
NOTE: This is a duplicate of #16375. I completely messed up that fork, so I made a new fork.
rust.md: Explicitly point out how special `'static` is.
Drive-by: fix description of `&content` to point out that `&'f type` is (as of today) only for type expressions.
People reading the tutorial may not be familiar with the convention of naming lists, vectors and the like as xs, ys, etc. Without some explanation of the reasoning behind it, it might come off as just throwaway non-descriptive names. Languages like Haskell gets flak from using short, non-descriptive names, while in reality, there are clear conventions and reasons for using certain terse variable names.
This is just a proposed explanation of this convention, as I've interpreted it - I assumed that the convention came from a language like Haskell, so I tailored it according to that. So beware that I might have misjudged how it is used in the Rust language, or at least how it is used in the Rust tutorial.
People reading the tutorial may not be familiar with the convention of naming lists, vectors and the like as xs, ys, etc. Without some explanation of the reasoning behind it, it might come off as just throwaway non-descriptive names. Languages like Haskell gets flak from using short, non-descriptive names, while in reality, there are clear conventions and reasons for using certain terse variable names.
I assumed that the convention came from a language like Haskell, so I
tailored the explanation according to that.
I _think_ this is the right place to introduce strings. It's a bit hard to talk about without understanding pointers and ownership, but you need to have some idea of what's going on...
I wasn't 100% sure of what level of detail I wanted to go into things here. For example, 1:1 vs M:N tasks seems like a better distinction to leave to the Guide.
This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).
All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.
Closes#16281
[breaking-change]
This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).
All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.
Closes#16281
[breaking-change]
