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]
The reference manual said that code is interpreted as UTF-8 text and a implementation will normalize it to NFKC. However, rustc doesn't do any normalization now.
We may want to do any normalization for symbols, but normalizing whole text seems harmful because doing so loses some sort of information even if we choose a non-K variant of normalization.
I'd suggest removing "normalized to Unicode normalization form NFKC" phrase for the present so that the manual represents the current state properly. When we address the problem (with a RFC?), then the manual should be updated.
Closes#12388.
Reference: https://github.com/rust-lang/rust/issues/2253
The reference manual said that code is interpreted as UTF-8 text and a
implementation will normalize it to NFKC. However, rustc doesn't do
any normalization now.
We may want to do any normalization for symbols, but normalizing whole
text seems harmful because doing so loses some sort of information even
if we choose a non-K variant of normalization.
I'd suggest removing "normalized to Unicode normalization form NFKC"
phrase for the present so that the manual represents the current state
properly. When we address the problem (with a RFC?), then the manual
should be updated.
Closes#12388.
Reference: https://github.com/rust-lang/rust/issues/2253
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
This is the next section of the guide, and it's on pointers. It's not done yet, as I need to write the section on ownership and borrowing, but I figured I'd share the rest now, to get feedback on the rest of it while I take some time to get that right.
The start of a testing guide. This PR relies on the crates and modules one because I shuffled some stuff around, so sorry about that.
I got stuck with how to import this name with cargo. @wycats and @alexcrichton , any ideas?
