Explain the --bin flag in terms of the difference
between shipping binary and library code
I'm not sure if my explanation is even quite correct, but as a newbie coming from Ruby, this is my best guess. (In Rubyland, libraries always ship with the source code because there's no other form you can ship. :) )
In the discussion of returning closures, it seems like the example code got simplified, but only the later copies got fixed. The final working code has `factory` returning `|x| x + num`, but the earlier code has `|x| vec.push(x)`.
The first form seemed to have more distracting characteristics, and the code wasn't right anyway, so I changed them to all use the second form, and updated the error messages.
r? @steveklabnik
Doc patch for #26120. Extra words here, because "value" is repeated.
I haven't read about whether/how it should go to stable (sorry), but I think it would help newcomers.
Thanks,
The text claimed 'any borrow must last for a _smaller_ scope than the
owner', however the accurate way of describing the comparison is
inclusive (i.e., 'less than or equal to' vs. 'less than').
The text claimed 'any borrow must last for a _smaller_ scope than the
owner', however the accurate way of describing the comparison is
inclusive (i.e., 'less than or equal to' vs. 'less than').
For a user following the path of reading Chapter 5: Syntax & Symantics
prior to Chapter 4: Learn Rust, this will be the first time they have
encountered executable tests inside documentation comments.
The test will fail because the `add_one` function is not defined in
the context of the doctest. This might not be the optimal place to
introduce and explain the `/// #` notation but I think it is important
that this snippet pass as a test when `rustdoc --test` is run against
it.
The doc indicates that you can replace 'before' with 'after' showing the use of try!. The two examples should be equivalent, but they are not.
In the File::create we were inducing a panic before in case of error, not propagating. It is important for newbies (like myself) to understand that try! propagates failures, while unwrap can induce a panic.
The other alternative is to make the 'before' File::create also manually handle Err like the other calls. Either way it would be consistent.
As mentioned in #25893 the copy trait is not very well explained for beginners. There is no clear mention that all primitive types implement the copy trait and there are not a lot of examples.
With this change I try to make it more visible and understandable for new users.
I myself have struggled with this, see [my question on stackoverflow](http://stackoverflow.com/questions/30540419/why-are-booleans-copyable-even-though-the-documentation-doesnt-indicate-that). And I want to make it more transparent for others.
I filed issue #25893 but I thought that I could give it a shot myself to relieve some of the work from the devs :)
If it is not well written or there are some changes to be made before it can be merged, let me know.
Cheers,
Mathieu
For a user following the path of reading Chapter 5: Syntax & Symantics
prior to Chapter 4: Learn Rust, this will be the first time they have
encountered executable tests inside documentation comments.
The test will fail because the `add_one` function is not defined in
the context of the doctest. This might not be the optimal place to
introduce and explain the `/// #` notation but I think it is important
that this snippet pass as a test when `rustdoc --test` is run against
it if it is going to be shown.
The sensible default used here for the version number in the
auto-generated Cargo.toml is 0.1.0, not 0.0.1 (at least as of cargo
0.2.0-nightly efb482d).
The statement is not completely exact, because it is valid to have
both 0 non-mutable references and 1 mutable reference. Instead, use
the same wording as in mutability.md.
Hi
I added a little section in the for loops about the `enumerate()` function.
I think it's useful for beginners to know this function and how you can use it.
I used the title loopcounter, but it's probably not the best word to describe it. So let me know if there is a better word :)
The statement is not completely exact, because it is valid to have
both 0 non-mutable references and 1 mutable reference. Instead, use
the same wording as in mutability.md.
My main sources of information are [RFC401](https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md), the rust IRC channel, and a bunch of experiments to figure out what `rustc` currently supports.
Note that the RFC calls for some coercion behaviour that is not implemented yet (see #18469).
The documentation in this PR mostly covers current behaviour of rust and doesn't document the future behaviour. I haven't written about receiver expression coercion.
I would be happy to rewrite/adapt the PR according to feedback.
r? @steveklabnik
This was always a weird feature, and isn't being used in the compiler.
Static assertions should be done better than this.
This implements RFC #1096.
Fixes#13951Fixes#23008Fixes#6676
This is behind a feature gate, but that's still a
[breaking-change]
The doc indicates that you can replace 'before' with 'after' showing the use of try!. The two examples should be equivalent, but they are not.
In the File::create we were inducing a panic before in case of error, not propagating. It is important for newbies (like myself) to understand that try! propagates failures, while unwrap can induce a panic.
The other alternative is to make the 'before' File::create also manually handle Err like the other calls. Either way it would be consistent.
As mentioned in #25893 the copy trait is not very well explained for beginners. There is no clear mention that all primitive types implement the copy trait and there are not a lot of examples.
With this change I try to make it more visible and understandable for new users.
I myself have struggled with this, see [my question on stackoverflow](http://stackoverflow.com/questions/30540419/why-are-booleans-copyable-even-though-the-documentation-doesnt-indicate-that). And I want to make it more transparent for others.
I filed issue #25893 but I thought that I could give it a shot myself to relieve some of the work from the devs :)
If it is not well written or there are some changes to be made before it can be merged, let me know.
Cheers,
Mathieu
