alex/gba
1
0
Fork 0
mirror of https://github.com/italicsjenga/gba.git synced 2025-01-23 16:06:34 +11:00
Code Issues Projects Releases Packages Wiki Activity

introduction improvements

Browse source
This commit is contained in:
Lokathor 2018-12-10 10:58:37 -07:00
parent 43efae8264
commit 6a3d022d6d
2 changed files with 25 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
book/src/00-introduction/00-index.md
View file

@ -10,7 +10,12 @@ of the pages listed in the Table Of Contents.
## Feedback ## Feedback
It's also often hard to tell when you've explained something properly to someone It's very often hard to tell when you've explained something properly. In the
who doesn't understand the concept yet. Please, if things don't make sense then same way that your brain will read over small misspellings and correct things
[file an issue](https://github.com/rust-console/gba/issues) about it so I know into the right word, if an explanation for something you already understand
where things need to improve. accidentally skips over some small detail then your brain can fill in the gaps
without you realizing it.
**Please**, if things don't make sense then [file an
issue](https://github.com/rust-console/gba/issues) about it so I know where
things need to improve.

22
book/src/00-introduction/05-newtype.md
View file

@ -111,12 +111,22 @@ macro_rules! newtype {
``` ```
That seems like enough for all of our examples, so we'll stop there. We could That seems like enough for all of our examples, so we'll stop there. We could
add more things, such as making the `From` impl optional (because what if you add more things:
shouldn't unwrap it for some weird reason?), allowing for more precise
visibility controls (on both the newtype overall and the inner field), and maybe * Making the `From` impl being optional. We'd have to make the newtype
even other things I can't think of right now. We won't really need those in our invocation be more complicated somehow, the user puts ", no-unwrap" after the
example code for this book, so it's probably nicer to just keep the macro inner type declaration or something, or something like that.
simpler and quit while we're ahead. * Allowing for more precise visibility controls on the wrapping type and on the
inner field. This would add a lot of line noise, so we'll just always have our
newtypes be `pub`.
* Allowing for generic newtypes, which might sound silly but that we'll actually
see an example of soon enough. To do this you might think that we can change
the `:ident` declarations to `:ty`, but then you can't use that captured type
when you declare the new wrapping type. The way you get around this is with a
proc-macro, which is a lot more powerful but which also requires that the
proc-macro be written in an entirely other crate. We don't need that much
power, so for our examples we'll go with the macro_rules version and just do
it by hand in the few cases where we need a generic newtype.
**As a reminder:** remember that macros have to appear _before_ they're invoked in **As a reminder:** remember that macros have to appear _before_ they're invoked in
your source, so the `newtype` macro will always have to be at the very top of your source, so the `newtype` macro will always have to be at the very top of