about summary refs log tree commit diff
path: root/src
diff options
context:
space:
mode:
authorManish Goregaokar <manishsmail@gmail.com>2015-09-05 16:16:01 +0530
committerManish Goregaokar <manishsmail@gmail.com>2015-09-05 16:16:01 +0530
commit3610c731f3b0182f79bf002cb30eb994b9ddfed9 (patch)
tree8a52e065637b37bc2bcf0404ce387a0b4866b1fc /src
parent6b36e921f4198f5afc1656db2d153f4f74a1fabe (diff)
parentf44fbf08f95e86e0eabdb492e8d003ccfcefa258 (diff)
downloadrust-3610c731f3b0182f79bf002cb30eb994b9ddfed9.tar.gz
rust-3610c731f3b0182f79bf002cb30eb994b9ddfed9.zip
Rollup merge of #28225 - jackwilsonv:patch-3, r=steveklabnik
r? @steveklabnik
Diffstat (limited to 'src')
-rw-r--r--src/doc/trpl/method-syntax.md16
1 files changed, 8 insertions, 8 deletions
diff --git a/src/doc/trpl/method-syntax.md b/src/doc/trpl/method-syntax.md
index 1afa622db7d..a2bdd66b0c2 100644
--- a/src/doc/trpl/method-syntax.md
+++ b/src/doc/trpl/method-syntax.md
@@ -7,7 +7,7 @@ can be awkward. Consider this code:
 baz(bar(foo));
 ```
 
-We would read this left-to right, and so we see ‘baz bar foo’. But this isn’t the
+We would read this left-to-right, and so we see ‘baz bar foo’. But this isn’t the
 order that the functions would get called in, that’s inside-out: ‘foo bar baz’.
 Wouldn’t it be nice if we could do this instead?
 
@@ -45,17 +45,17 @@ This will print `12.566371`.
 
 
 
-We’ve made a struct that represents a circle. We then write an `impl` block,
+We’ve made a `struct` that represents a circle. We then write an `impl` block,
 and inside it, define a method, `area`.
 
-Methods take a  special first parameter, of which there are three variants:
+Methods take a special first parameter, of which there are three variants:
 `self`, `&self`, and `&mut self`. You can think of this first parameter as
 being the `foo` in `foo.bar()`. The three variants correspond to the three
 kinds of things `foo` could be: `self` if it’s just a value on the stack,
 `&self` if it’s a reference, and `&mut self` if it’s a mutable reference.
 Because we took the `&self` parameter to `area`, we can use it just like any
 other parameter. Because we know it’s a `Circle`, we can access the `radius`
-just like we would with any other struct. 
+just like we would with any other `struct`. 
 
 We should default to using `&self`, as you should prefer borrowing over taking
 ownership, as well as taking immutable references over mutable ones. Here’s an
@@ -120,12 +120,12 @@ Check the return type:
 ```rust
 # struct Circle;
 # impl Circle {
-fn grow(&self) -> Circle {
+fn grow(&self, increment: f64) -> Circle {
 # Circle } }
 ```
 
 We just say we’re returning a `Circle`. With this method, we can grow a new
-circle to any arbitrary size.
+`Circle` to any arbitrary size.
 
 # Associated functions
 
@@ -161,7 +161,7 @@ methods’.
 
 # Builder Pattern
 
-Let’s say that we want our users to be able to create Circles, but we will
+Let’s say that we want our users to be able to create `Circle`s, but we will
 allow them to only set the properties they care about. Otherwise, the `x`
 and `y` attributes will be `0.0`, and the `radius` will be `1.0`. Rust doesn’t
 have method overloading, named arguments, or variable arguments. We employ
@@ -224,7 +224,7 @@ fn main() {
 }
 ```
 
-What we’ve done here is make another struct, `CircleBuilder`. We’ve defined our
+What we’ve done here is make another `struct`, `CircleBuilder`. We’ve defined our
 builder methods on it. We’ve also defined our `area()` method on `Circle`. We
 also made one more method on `CircleBuilder`: `finalize()`. This method creates
 our final `Circle` from the builder. Now, we’ve used the type system to enforce