When I read the book, the following sentence of the reference documentation helped me greatly to understand slices:
"Slices are a view into a block of memory represented as a pointer and a length."
In this commit, I tried to integrate the gist of that into the slice section inside of "primitive-types.md".
len needs to be prefixed by self for this to work. That is something which trips me up all the time. It's reassuring to see that happening to seasoned Rust programmers.
I'm working my way through TRPL beginning at "Syntax and Semantics" as was recommended in a previous version.
I'm expecting the chapter to incrementally build up my knowledge of the language section by section, assuming no prior Rust experience. So it was a bit of a speed-bump to encounter references and the vector type in a code example long before they had been defined and explained.
Another commit in this PR tries to make consistent what is a "chapter" of TRPL versus a "section." Just a nit-pick, but not thinking about that stuff keeps my focus on the important material.
My background: Python programmer since ~2000, with moderate exposure to C, C++, assembly, operating systems, and system architecture in university several years ago.
For your kind consideration, feel welcome to use or drop or rework any part of this.
In a straight-through read of "Syntax and Semantics," the concept of a
"reference" is used here before it is explained. Mention that and link to
the section explaining references.
In a straight-through read of "Syntax and Semantics," the first time we
meet a generic, and the first time we meet a vector, is when a Vec<T> shows
up in this example. I'm not sure that I could argue that the whole section
should appear later in the book than the ones on vectors and generics, so
instead just give the reader a brief introduction to both and a promise to
follow up later.
heap::deallocate expects a *mut u8, but here a *mut T is given as the type of the argument. This would not compile. The final code is correct, however.
Rust differs in that behavior from C: In C, the newline escapes are resolved
before anything else, and in Rust this depends on whether the backslash is
escaped itself.
A difference can be observed in the following two programs:
```c
int main()
{
printf("\\
n\n");
return 0;
}
```
```rust
fn main() {
println!("\\
n");
}
```
The first program prints two newlines, the second one prints a backslash, a
newline, the latin character n and a final newline.
I noticed the alignment was off in the error handling part of the book. This was caused because two tabs had crept into the file. I have changed these for spaces.
Rust differs in that behavior from C: In C, the newline escapes are resolved
before anything else, and in Rust this depends on whether the backslash is
escaped itself.
A difference can be observed in the following two programs:
```c
#include <stdio.h>
int main()
{
printf("\\
n\n");
return 0;
}
```
```rust
fn main() {
println!("\\
n");
}
```
The first program prints two newlines, the second one prints a backslash, a
newline, the latin character n and a final newline.
Some history:
While getting Rust to 1.0, it was a struggle to keep the book in a
working state. I had always wanted a certain kind of TOC, but couldn't
quite get it there.
At the 11th hour, I wrote up "Rust inside other langauges" and "Dining
Philosophers" in an attempt to get the book in the direction I wanted to
go. They were fine, but not my best work. I wanted to further expand
this section, but it's just never going to end up happening. We're doing
the second draft of the book now, and these sections are basically gone
already.
Here's the issues with these two sections, and removing them just fixes
it all:
// Philosophers
There was always controversy over which ones were chosen, and why. This
is kind of a perpetual bikeshed, but it comes up every once in a while.
The implementation was originally supposed to show off channels, but
never did, due to time constraints. Months later, I still haven't
re-written it to use them.
People get different results and assume that means they're wrong, rather
than the non-determinism inherent in concurrency. Platform differences
aggrivate this, as does the exact amount of sleeping and printing.
// Rust Inside Other Languages
This section is wonderful, and shows off a strength of Rust. However,
it's not clear what qualifies a language to be in this section. And I'm
not sure how tracking a ton of other languages is gonna work, into the
future; we can't test _anything_ in this section, so it's prone to
bitrot.
By removing this section, and making the Guessing Game an initial
tutorial, we will move this version of the book closer to the future
version, and just eliminate all of these questions.
In addition, this also solves the 'split-brained'-ness of having two
paths, which has endlessly confused people in the past.
I'm sad to see these sections go, but I think it's for the best.
Fixes#30471Fixes#30163Fixes#30162Fixes#25488Fixes#30345Fixes#29590Fixes#28713Fixes#28915
And probably others. This lengthy list alone is enough to show that
these should have been removed.
RIP.
fs::File was being referenced without either calling via std::fs::File or by using File after having used fs::File. Also Path was being referenced without first having used std::path::Path.
Rewrite of a paragraph in in the `match` section.
The colon `:` should be used only when the sentence preceeding it is a
complete sentence. If this is not the case, then a `;` should be used;
this denotes that the following fragment is a part of the previous
fragment.
I got a new bike; it has two wheels. (Similar to I got a new bike, it has two wheels)
The ice cream truck has great flavours; blueberry, blackberry, berryberry.
Writing a complete sentence:
- with a list under it
- You can join two sentences with it: Much like this.
r? @steveklabnik
Some history:
While getting Rust to 1.0, it was a struggle to keep the book in a
working state. I had always wanted a certain kind of TOC, but couldn't
quite get it there.
At the 11th hour, I wrote up "Rust inside other langauges" and "Dining
Philosophers" in an attempt to get the book in the direction I wanted to
go. They were fine, but not my best work. I wanted to further expand
this section, but it's just never going to end up happening. We're doing
the second draft of the book now, and these sections are basically gone
already.
Here's the issues with these two sections, and removing them just fixes
it all:
// Philosophers
There was always controversy over which ones were chosen, and why. This
is kind of a perpetual bikeshed, but it comes up every once in a while.
The implementation was originally supposed to show off channels, but
never did, due to time constraints. Months later, I still haven't
re-written it to use them.
People get different results and assume that means they're wrong, rather
than the non-determinism inherent in concurrency. Platform differences
aggrivate this, as does the exact amount of sleeping and printing.
// Rust Inside Other Languages
This section is wonderful, and shows off a strength of Rust. However,
it's not clear what qualifies a language to be in this section. And I'm
not sure how tracking a ton of other languages is gonna work, into the
future; we can't test _anything_ in this section, so it's prone to
bitrot.
By removing this section, and making the Guessing Game an initial
tutorial, we will move this version of the book closer to the future
version, and just eliminate all of these questions.
In addition, this also solves the 'split-brained'-ness of having two
paths, which has endlessly confused people in the past.
I'm sad to see these sections go, but I think it's for the best.
Fixes#30471Fixes#30163Fixes#30162Fixes#25488Fixes#30345Fixes#28713Fixes#28915
And probably others. This lengthy list alone is enough to show that
these should have been removed.
RIP.
Didn't build/test the change, but if that one-character fix isn't correct, I'll eat my hat. :-) Found this reading the book over the last week or two since Mozlando -- much enjoying the book so far.
book: Some operator fixes for the syntax index
- Correct the names of the comparison traits (PartialOrd)
- Mention only the traits that overload the operator (PartialOrd,
PartialEq), not operator-unrelated traits (Ord, Eq).
- Add `!=` operator.
- Correct the names of the comparison traits (PartialOrd)
- Mention only the traits that overload the operator (PartialOrd,
PartialEq), not operator-unrelated traits (Ord, Eq).
- Add `!=` operator.
The website will [shortly](https://github.com/rust-lang/rust-www/pull/241) provide the main documentation landing page as well as the [FAQ](https://github.com/rust-lang/rust-www/issues/202). All of the content here will be there.
This strips out everything and makes the index *just* an index into the in-tree content. My only real qualm with this is that this will become the content on doc.rust-lang.org (a sweet URL), while the main documentation page will be www.rust-lang.org/documentation.html.
r? @steveklabnik
correcting use of ':' in sentences.
The colon `:` should be used only when the sentence preceeding it is a
complete sentence. If this is not the case, then a `;` should be used;
this denotes that the following fragment is a part of the previous
fragment.
This PR is a rebase of the original PR by @eddyb https://github.com/rust-lang/rust/pull/21836 with some unrebasable parts manually reapplied, feature gate added + type equality restriction added as described below.
This implementation is partial because the type equality restriction is applied to all type ascription expressions and not only those in lvalue contexts. Thus, all difficulties with detection of these contexts and translation of coercions having effect in runtime are avoided.
So, you can't write things with coercions like `let slice = &[1, 2, 3]: &[u8];`. It obviously makes type ascription less useful than it should be, but it's still much more useful than not having type ascription at all.
In particular, things like `let v = something.iter().collect(): Vec<_>;` and `let u = t.into(): U;` work as expected and I'm pretty happy with these improvements alone.
Part of https://github.com/rust-lang/rust/issues/23416
The previous example had no chance of compiling in either form, due to the restrictive follow set for `ty`. This one has the desired behavior: http://is.gd/kYdw4g (well, I don't exactly desire this behavior at all, but it's true at least :p )
