Merge changes from hanbum into master

sarojaba authored
revision 3bf7da59d2a91334e0e0b073c03aa306e1864965
closures
# 5.23. 클로저 (Closures) - 10%

가끔 내부 함수와 _자유 변수_(_free variable_)(내부 함수 안에서 정의되지 않은 변수)를 둘러싼 함수가 유용할 때가 있습니다. 자유 변수는 내부 함수와 인접한 영역(scope)에서 갖고 오고, 이 함수를 사용할 때 '닫힙니다(결정됩니다)'. 그렇기 때문에 이런 함수를 '클로저(closure)'라 부릅니다. 러스트는 이것을 정말 잘 지원하고 있습니다.
실제로 살펴보도록 하죠.

## 문법

다음과 같은 클로저가 있습니다:

```rust
let plus_one = |x: i32| x + 1;

assert_eq!(2, plus_one(1));
```

우리는 `plus_one`에 바인딩을 만들어, 클로저에 그것을 할당했습니다. 클로저의 인수(arguments)는 파이프(`|`) 사이에, 몸체(body)에는 표현식을 씁니다. `x + 1` 이 해당됩니다.
`{ }`가 표현식(expression)이라는 것을 기억하시나요? 이걸로 여러 줄로 된 클로저 또한 만들 수 있습니다.

```rust
let plus_two = |x| {
let mut result: i32 = x;

result += 1;
result += 1;

result
};

assert_eq!(4, plus_two(2));
```

클로저가 `fn`으로 정의되는 일반 함수와 약간 다르다는 것을 눈치채셨을 겁니다. 첫번째로 클로저가 받는 인수나 반환값의 타입을 명시해줄 필요가 없다는 것입니다.
물론 명시해 줄 수 있습니다:

```rust
let plus_one = |x: i32| -> i32 { x + 1 };

assert_eq!(2, plus_one(1));
```

그렇지만 그렇게 할 필요가 없습니다. 왜 그럴까요? 기본적으로, 사람이 보다 편하기 위해서입니다. 일반 함수가 문서나 타입 추론에 도움이 되게 하기 위해 타입들을 모두 명시하는 반면에, 클로저는 익명함수로써 error-at-a-distance 종류의 문제를 일으키지 않기 때문에 좀처럼 그렇게 하지 않습니다.

두번째는 문법이 비슷하지만, 조금은 다르다는 것입니다. 간단한 비교를 해보죠.

```rust
fn plus_one_v1 (x: i32 ) -> i32 { x + 1 }
let plus_one_v2 = |x: i32 | -> i32 { x + 1 };
let plus_one_v3 = |x: i32 | x + 1 ;
```

조금 다르긴 하지만 그래도 비슷합니다.

## 클로저와 그 환경(environment)

클로저의 환경은 그것을 둘러싼 영역의 변수는 물론 바인딩까지도 포함합니다.
다음을 보면:

```rust
let num = 5;
let plus_num = |x: i32| x + num;

assert_eq!(10, plus_num(5));
```

`plus_num` 이라는 클로저는, 본인이 속한 영역에서 `let` 을 통해 바인딩되어 있는 `num`을 참조합니다. 정확히 말하면, 그 바인딩을 빌리게 됩니다. 만약 우리가 바인딩 된 이것을 가지고 뭔가 하게 되면 충돌이 발생하고, 이런 에러가 납니다:


```rust,ignore
let mut num = 5;
let plus_num = |x: i32| x + num;

let y = &mut num;
```

이런 에러 메시지도 같이요:

```text
error: cannot borrow `num` as mutable because it is also borrowed as immutable
let y = &mut num;
^~~
note: previous borrow of `num` occurs here due to use in closure; the immutable
borrow prevents subsequent moves or mutable borrows of `num` until the borrow
ends
let plus_num = |x| x + num;
^~~~~~~~~~~
note: previous borrow ends here
fn main() {
let mut num = 5;
let plus_num = |x| x + num;

let y = &mut num;
}
^
```

장황하긴 하지만 유용한 에러 메시지에서 볼 수 있듯이, 우리는 `num`을 변화 가능한 형태로 빌릴 수 없는데, 이유는 클로저가 이미 `num`을 빌리는 중이기 때문입니다. 그렇기 때문에 클로저의 영역 바깥에서나 `num`을 빌릴 수 있습니다:

```rust
let mut num = 5;
{
let plus_num = |x: i32| x + num;

} // plus_num goes out of scope, borrow of num ends

let y = &mut num;
```

그러나 클로저가 소유권을 달라고 하면 Rust는 소유권을 가져가고 대신 환경을 옮겨(move)버립니다. 다음 코드는 동작하지 않습니다:

```rust,ignore
let nums = vec![1, 2, 3];

let takes_nums = || nums;

println!("{:?}", nums);
```

에러메시지는 이렇습니다:

```text
note: `nums` moved into closure environment here because it has type
`[closure(()) -> collections::vec::Vec]`, which is non-copyable
let takes_nums = || nums;
^~~~~~~
```

`Vec`는 자신 내부 요소들에 대해 소유권을 갖기 때문에, 클로저에서 이를 참조하려면 `nums`의 소유권을 얻을 필요가 있습니다. 말하자면 `nums`를 함수에서 사용하려면 `nums`의 소유권도 같이 전달하는 것과 같죠.


## `move` 클로저

`move` 키워드로 클로저가 자신의 환경의 소유권을 가져가도록 할 수 있습니다:

```rust
let num = 5;

let owns_num = move |x: i32| x + num;
```

이 경우는 `move` 키워드가 있는데도 변수는 그냥 일반적인 이동을 따릅니다. 이 경우 `5`가 `Copy`되고, `owns_num`는 복사된 `num`의 소유권을 가져갑니다. 차이점이 뭘까요?

```rust
let mut num = 5;

{
let mut add_num = |x: i32| num += x;

add_num(5);
}

assert_eq!(10, num);
```

이번에는 클로저가 변경가능한 `num`의 리퍼런스를 가져가기 때문에 `add_num`를 호출하면, `num` 값이 변경될 겁니다. 환경이 변하기 때문에 `add_num` 을 `mut`로 선언해야 합니다.

`move` 클로저로 바꾸면 이렇게 달라집니다:

```rust
let mut num = 5;

{
let mut add_num = move |x: i32| num += x;

add_num(5);
}

assert_eq!(5, num);
```

이렇게 하면 그냥 `5`가 나옵니다. 변경가능한 `num`을 빌려오는 대신에 그냥 `num`을 복사한 값의 소유권을 갖고 온 거죠.

이렇게도 생각해 볼까요. `move` 클로저는 클로저에게 자기만의 스택 공간을 줍니다. `move` 가 없으면 클로저는 생성될 때의 스택에 묶이겠죠. 말하자면 `move` 클로저는 컨테이너라고 할 수 있습니다. 즉 예를 들어서, 일반적으로 함수 내에서 `move` 클로저가 아닌 클로저를 반환하는 것은 불가능합니다.

클로저를 취하고 반환하는 법을 더 자세히 다루기 전에, 클로저를 구현하는 방식에 대해서 더 다뤄 봅시다. 시스템 언어인 러스트는 코드로 통제할 수 있는 부분이 엄청나게 많고, 이는 클로저도 마찬가지입니다.

## Closure implementation
클로저 구현

러스트에서 클로저를 구현하는 방식은 다른 언어와는 약간 다르다. 그들은 traits를 위한 효과적 문법 설탕이다. 이에 대해 더 알고 싶다면 traits chapter를 살펴보거나 그 전에 trait-object 챕터를 읽어보도록 해라.

Rust’s implementation of closures is a bit different than other languages. They
are effectively syntax sugar for traits. You’ll want to make sure to have read
the [traits chapter][traits] before this one, as well as the chapter on [trait
objects][trait-objects].

[traits]: traits.html
[trait-objects]: trait-objects.html

다 읽었나? 좋아.
Got all that? Good.

클로저를 이해하는 방식의 키는 조금 낯설 수도 있다. `foo()`와 같은 방식으로 `()`를 사용하여 함수를 호출하게 되는데, 이는 오버로드 가능한 연산자이다. 이런 방식은 다른 모든 것에도 동일하게 적용된다.( 역주: `()`라는 오퍼레이션이 오버로드 되어 함수 호출자가 되는 것과 동일 방식) 러스트에서는 trait 시스템을 연산자 오버로드에 사용한다. 함수를 호출하는 것도 다른지 않다. 우리는 이를 위해 세 개의 traits를 사용한다.
The key to understanding how closures work under the hood is something a bit
strange: Using `()` to call a function, like `foo()`, is an overloadable
operator. From this, everything else clicks into place. In Rust, we use the
trait system to overload operators. Calling functions is no different. We have
three separate traits to overload with:

```rust
# mod foo {
pub trait Fn : FnMut {
extern "rust-call" fn call(&self, args: Args) -> Self::Output;
}

pub trait FnMut : FnOnce {
extern "rust-call" fn call_mut(&mut self, args: Args) -> Self::Output;
}

pub trait FnOnce {
type Output;

extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
}
# }
```

몇 가지 차이점들이 눈에 띄지만, 가장 중요한 것은 `self`:`Fn`이 `&self`를 취하고, `FnMut`이 `&mut self`를 취하며 `FnOnce`는 `self`를 취한다는 점이다. 이 세 가지 형태의 `self`는 모두 함수 호출 문법으로 사용된다. 하지만 우리는 이것을 하나보다는 세개의 traits으로 나누어 구현했다. 이것이 우리가 사용할 수 있는 클로저에 많은 권한을 부여한다.
You’ll notice a few differences between these traits, but a big one is `self`:
`Fn` takes `&self`, `FnMut` takes `&mut self`, and `FnOnce` takes `self`. This
covers all three kinds of `self` via the usual method call syntax. But we’ve
split them up into three traits, rather than having a single one. This gives us
a large amount of control over what kind of closures we can take.

클로저 문법인 `|| {}`이 이 세개의 traits를 위한 요소이다. 러스트는 환경을 위한 구조체를 만들고, 적절한 trait을 `impl` 하여, 사용하게 된다.
The `|| {}` syntax for closures is sugar for these three traits. Rust will
generate a struct for the environment, `impl` the appropriate trait, and then
use it.


## Taking closures as arguments
클로저의 인자 값 취하기

이제 우리는 클로저가 traits임을 알게 됐으니, 이를 통해 클로저로 인자 값을 받거나 리턴하는 방법도 알게 됐다. 그냥 다른 trait처럼 사용하면 된다!

Now that we know that closures are traits, we already know how to accept and
return closures: just like any other trait!

이것은 또한 우리가 static 혹은 dynamic 한 방식을 취할 수 있음을 뜻한다. 첫 째로, 호출할 수 있는 함수를 만들어 호출하고 리턴하는 함수를 만들어보자. 이렇게 :
This also means that we can choose static vs dynamic dispatch as well. First,
let’s write a function which takes something callable, calls it, and returns
the result:

```rust
fn call_with_one(some_closure: F) -> i32
where F : Fn(i32) -> i32 {

some_closure(1)
}

let answer = call_with_one(|x| x + 2);

assert_eq!(3, answer);
```
우리는 클로저 `|x| x + 2`를 `call_with_one`으로 전달한다. 이것은 보다시피: 클로저를 호출하며, `1`을 인자로 주는 것이다.
We pass our closure, `|x| x + 2`, to `call_with_one`. It just does what it
suggests: it calls the closure, giving it `1` as an argument.

`call_with_one`이란 서명을 좀더 깊게 살펴보자.
Let’s examine the signature of `call_with_one` in more depth:

```rust
fn call_with_one(some_closure: F) -> i32
# where F : Fn(i32) -> i32 {
# some_closure(1) }
```

우리는 하나의 인자를 취하고, 타입은 `F`다. 또한 우리는 `i32`를 반환한다. 이 부분은 그닥 중요하진 않고 다음으로 넘어가자:
We take one parameter, and it has the type `F`. We also return a `i32`. This part
isn’t interesting. The next part is:

```rust
# fn call_with_one(some_closure: F) -> i32
where F : Fn(i32) -> i32 {
# some_closure(1) }
```

`Fn`이 trait이기 때문에, 이를 통해 우리의 제네릭의 범위를 정할 수 있다. 이번 예에서, 우리의 클로저는 `i32`를 인자로 취하고 `i32`를 반환하기에 제네릭의 범위를 `Fn(i32) -> i32`로 사용한다.
Because `Fn` is a trait, we can bound our generic with it. In this case, our closure
takes a `i32` as an argument and returns an `i32`, and so the generic bound we use
is `Fn(i32) -> i32`.

여기에는 또 하나의 키 포인트가 있다: 우리가 trait과 함께 제네릭의 범위를 정하기에, 이것은 다형성을 갖게 되므로, 우리는 static dispatch 를 클로저에서 사용할 수 있다. 이건 훌륭하다! 많은 언어들이, 클로저는 본질적으로 heap 할당을 받고, dynamic dispatch 가 되게 된다. 러스트에서는 클로저 환경을 stack에 할당할 수 있고, static한 방식으로 dispatch 호출을 할 수 있다. 이는 많은 iterator와 그들의 adapter들에서 클로저를 인자로 받는 방식으로 많이 사용된다.
There’s one other key point here: because we’re bounding a generic with a
trait, this will get monomorphized, and therefore, we’ll be doing static
dispatch into the closure. That’s pretty neat. In many languages, closures are
inherently heap allocated, and will always involve dynamic dispatch. In Rust,
we can stack allocate our closure environment, and statically dispatch the
call. This happens quite often with iterators and their adapters, which often
take closures as arguments.

당연하게 우리가 dynamic dispatch를 하는 것도 가능하다. trait object를 이렇게 다루면 된다:
Of course, if we want dynamic dispatch, we can get that too. A trait object
handles this case, as usual:

```rust
fn call_with_one(some_closure: &Fn(i32) -> i32) -> i32 {
some_closure(1)
}

let answer = call_with_one(&|x| x + 2);

assert_eq!(3, answer);
```

이번에 우리는 trait object를 `&Fn`으로 취한다. 그리고 우리의 클로저를 `call_with_one`의 인자로 전할 때 `&||`로 참조하여 보낸다.
Now we take a trait object, a `&Fn`. And we have to make a reference
to our closure when we pass it to `call_with_one`, so we use `&||`.


## Function pointers and closures
함수 포인터와 클로저

함수 포인터는 환경없는 클로저의 형태이다. 그렇기에, 우리는 함수 포인터를 클로저를 인자로 기대하는 어떤 함수에도 전달할 수 있고 동작할 것이다:

A function pointer is kind of like a closure that has no environment. As such,
you can pass a function pointer to any function expecting a closure argument,
and it will work:

```rust
fn call_with_one(some_closure: &Fn(i32) -> i32) -> i32 {
some_closure(1)
}

fn add_one(i: i32) -> i32 {
i + 1
}

let f = add_one;

let answer = call_with_one(&f);

assert_eq!(2, answer);
```

이번 예제에서, 우리는 `f`라는 중간 매개가 필요하다고 제약하진 않고, 함수 이름을 사용해도 문제 없다 :
In this example, we don’t strictly need the intermediate variable `f`,
the name of the function works just fine too:

```ignore
let answer = call_with_one(&add_one);
```

## Returning closures
클로저를 반환하기

다양한 상황에서 함수 스타일의 코드에서 클로저를 반환하는 매우 일반적이다. 만약 당신이 클로저를 반한하고자 한다면, 에러를 볼 수 있을 것이다. 처음에는, 낯설게 느껴지겠지만 이해할 수 있을 것이다. 클로저를 함수에서 반환하는 방법을 알아보자:

It’s very common for functional-style code to return closures in various
situations. If you try to return a closure, you may run into an error. At
first, it may seem strange, but we’ll figure it out. Here’s how you’d probably
try to return a closure from a function:

```rust,ignore
fn factory() -> (Fn(i32) -> i32) {
let num = 5;

|x| x + num
}

let f = factory();

let answer = f(1);
assert_eq!(6, answer);
```

위의 코드는 다음과 같은 긴 에러를 보여준다:
This gives us these long, related errors:

```text
error: the trait `core::marker::Sized` is not implemented for the type
`core::ops::Fn(i32) -> i32` [E0277]
fn factory() -> (Fn(i32) -> i32) {
^~~~~~~~~~~~~~~~
note: `core::ops::Fn(i32) -> i32` does not have a constant size known at compile-time
fn factory() -> (Fn(i32) -> i32) {
^~~~~~~~~~~~~~~~
error: the trait `core::marker::Sized` is not implemented for the type `core::ops::Fn(i32) -> i32` [E0277]
let f = factory();
^
note: `core::ops::Fn(i32) -> i32` does not have a constant size known at compile-time

let f = factory();
^
```

함수에서 뭔가를 반환하는 경우, 러스트는 타입의 사이즈를 알아야 할 필요가 있다. 하지만 `Fn`이 trait이 된 이후, 이는 많은 다양한 형태의 크기의 사이즈를 갖을 수 있게 됐다: 많은 다양한 형태가 `Fn`으로 구현될 수 있다. 간단한 방법은 사이즈로 뭔가 전해주기 위해, 참조를 취하는 것이고, 참조의 사이즈는 알고 있다. 그래서 다음과 같이 작성해보자:
In order to return something from a function, Rust needs to know what
size the return type is. But since `Fn` is a trait, it could be various
things of various sizes: many different types can implement `Fn`. An easy
way to give something a size is to take a reference to it, as references
have a known size. So we’d write this:

```rust,ignore
fn factory() -> &(Fn(i32) -> i32) {
let num = 5;

|x| x + num
}

let f = factory();

let answer = f(1);
assert_eq!(6, answer);
```

하지만 또 다른 에러가 보이게 된다:
But we get another error:

```text
error: missing lifetime specifier [E0106]
fn factory() -> &(Fn(i32) -> i32) {
^~~~~~~~~~~~~~~~~
```

맞아! 우리가 참조를 취했기에 이에 대한 시한을 설정할 필요가 있다. 하지만 우리 `factory()` 함수는 아무 인자도 없기에 생략하면 발로 차이게 되는 것이다. 어떤 시한을 우리가 선택할 수 있을까? `'static`:
Right. Because we have a reference, we need to give it a lifetime. But
our `factory()` function takes no arguments, so elision doesn’t kick in
here. What lifetime can we choose? `'static`:

```rust,ignore
fn factory() -> &'static (Fn(i32) -> i32) {
let num = 5;

|x| x + num
}

let f = factory();

let answer = f(1);
assert_eq!(6, answer);
```

하지만 또 다른 에러가 난다:
But we get another error:

```text
error: mismatched types:
expected `&'static core::ops::Fn(i32) -> i32`,
found `[closure :7:9: 7:20]`
(expected &-ptr,
found closure) [E0308]
|x| x + num
^~~~~~~~~~~

```
이번 에러는 우리에게 `&'static Fn(i32) -> i32` 가 아니라 `[closure :7:9: 7:20]`를 다루고 있다고 알려준다. 잠깐, 뭐라?
This error is letting us know that we don’t have a `&'static Fn(i32) -> i32`,
we have a `[closure :7:9: 7:20]`. Wait, what?

이유는 각 클로저가 그들 고유의 `struct`환경을 갖고 `Fn`을 함께 구현된 코드를 생산하기 때문에, 이 타입들은 익명이 된다. 이들은 고유하게 해당 클로저를 위해서만 존재한다. 그래서 러스트는 `closure `라고 보여주고, 이는 자동으로 생성된 이름이다.
Because each closure generates its own environment `struct` and implementation
of `Fn` and friends, these types are anonymous. They exist just solely for
this closure. So Rust shows them as `closure `, rather than some
autogenerated name.

그렇다고 하더라도 왜 클로저는 `&'static Fn`이 아닐까? 글쎄, 우리가 이전에 토의했 듯, 클로저는 그들의 환경을 대여한다. 그리고 이번 케이스에서 우리의 환경은 stack 할당된 `num` 변수에 바인딩 되어 있는 `5`를 기반하고 있다. 그래서 시한은 stack frame에 달려있다. (역주:stack이 해제되면 자동으로 소멸) 그래서 우리가 해당 클로저를 반환하게 되면, 함수 호출이 끝나고, stack frame이 소멸되고, 우리의 클로저 환경은 쓰레기 메모리에 위치하게 될 것이다!
But why doesn’t our closure implement `&'static Fn`? Well, as we discussed before,
closures borrow their environment. And in this case, our environment is based
on a stack-allocated `5`, the `num` variable binding. So the borrow has a lifetime
of the stack frame. So if we returned this closure, the function call would be
over, the stack frame would go away, and our closure is capturing an environment
of garbage memory!

그래서 어떻게 해야 할까? 이는 거의 될 것 같다:
So what to do? This _almost_ works:

```rust,ignore
fn factory() -> Box i32> {
let num = 5;

Box::new(|x| x + num)
}
# fn main() {
let f = factory();

let answer = f(1);
assert_eq!(6, answer);
# }
```

우리는 trait object를 `Box` 포장한 `Fn`을 통해 사용한다. 여기에 마지막 문제가 있다:
We use a trait object, by `Box`ing up the `Fn`. There’s just one last problem:

```text
error: closure may outlive the current function, but it borrows `num`,
which is owned by the current function [E0373]
Box::new(|x| x + num)
^~~~~~~~~~~
```

우리는 아직 기원 stack frame의 참조를 하고 있다. 마지막 수정을 해보자:
We still have a reference to the parent stack frame. With one last fix, we can
make this work:

```rust
fn factory() -> Box i32> {
let num = 5;

Box::new(move |x| x + num)
}
# fn main() {
let f = factory();

let answer = f(1);
assert_eq!(6, answer);
# }
```

내부 클로저를 `move Fn`으로 만듬으로, 우리는 새로운 stack frame을 클로저에게 주어줬다. `Box`포장을 통해, 우리는 사이즈를 알 수 있게 해줬고, 이는 stack frame에서 빠져나오게 한다.

By making the inner closure a `move Fn`, we create a new stack frame for our
closure. By `Box`ing it up, we’ve given it a known size, and allowing it to
escape our stack frame.
crates-and-modules
# 5.25. 크레이트들과(Crate) 모듈들(Module) - 0%

프로젝트가 방대해지기 시작하면서, 좋은 소프트웨어 엔지니어들은 그를 작은 조각으로 나누는데 신경쓰기 시작했고, 이게 협업하기에 적합하다. 또한 어떤 기능들을 private하게 할 것인지, public하게 할 것인지처럼 잘 정의된 interface 도 중요하다. 이러한 종류의 것들을 용이하게 할 수 있도록, 러스트는 모듈 시스템을 지원한다.
When a project starts getting large, it’s considered good software
engineering practice to split it up into a bunch of smaller pieces, and then
fit them together. It’s also important to have a well-defined interface, so
that some of your functionality is private, and some is public. To facilitate
these kinds of things, Rust has a module system.

# Basic terminology: Crates and Modules
기본 용어 : Crate들과 Module들

러스트는 모듈 시스템과 관련해 `crate`와 `module`이라는 독특한 두 용어를 사용한다. crate는 '라이브러리' 혹은 '패키지' 와 같은 의미를 갖는 언어이다. "Cargo"가 러스트의 패키지 매니저 도구의 이름으로 정해졌기에: 당신은 당신이 만든 crate들을 카고를 통해 다른 사람들에게 보낼 수 있다. Crate들은 프로젝트에 따라 실행가능 형태 혹은 라이브러리가 될 수 있다.

Rust has two distinct terms that relate to the module system: ‘crate’ and
‘module’. A crate is synonymous with a ‘library’ or ‘package’ in other
languages. Hence “Cargo” as the name of Rust’s package management tool: you
ship your crates to others with Cargo. Crates can produce an executable or a
library, depending on the project.

모든 crate들은 각자가 소유한 코드를 포함하는 암시적인 *root module*이다. 당신은 root module 이하에 sub-module들을 Tree처럼 정의할 수 있다. module은 당신의 코드들을 crate로 나눌 수 있도록 한다.
Each crate has an implicit *root module* that contains the code for that crate.
You can then define a tree of sub-modules under that root module. Modules allow
you to partition your code within the crate itself.

As an example, let’s make a *phrases* crate, which will give us various phrases
in different languages. To keep things simple, we’ll stick to ‘greetings’ and
‘farewells’ as two kinds of phrases, and use English and Japanese (日本語) as
two languages for those phrases to be in. We’ll use this module layout:

```text
+-----------+
+---| greetings |
| +-----------+
+---------+ |
+---| english |---+
| +---------+ | +-----------+
| +---| farewells |
+---------+ | +-----------+
| phrases |---+
+---------+ | +-----------+
| +---| greetings |
| +----------+ | +-----------+
+---| japanese |--+
+----------+ |
| +-----------+
+---| farewells |
+-----------+
```

In this example, `phrases` is the name of our crate. All of the rest are
modules. You can see that they form a tree, branching out from the crate
*root*, which is the root of the tree: `phrases` itself.

Now that we have a plan, let’s define these modules in code. To start,
generate a new crate with Cargo:

```bash
$ cargo new phrases
$ cd phrases
```

If you remember, this generates a simple project for us:

```bash
$ tree .
.
├── Cargo.toml
└── src
└── lib.rs

1 directory, 2 files
```

`src/lib.rs` is our crate root, corresponding to the `phrases` in our diagram
above.

# Defining Modules

To define each of our modules, we use the `mod` keyword. Let’s make our
`src/lib.rs` look like this:

```rust
mod english {
mod greetings {
}

mod farewells {
}
}

mod japanese {
mod greetings {
}

mod farewells {
}
}
```

After the `mod` keyword, you give the name of the module. Module names follow
the conventions for other Rust identifiers: `lower_snake_case`. The contents of
each module are within curly braces (`{}`).

Within a given `mod`, you can declare sub-`mod`s. We can refer to sub-modules
with double-colon (`::`) notation: our four nested modules are
`english::greetings`, `english::farewells`, `japanese::greetings`, and
`japanese::farewells`. Because these sub-modules are namespaced under their
parent module, the names don’t conflict: `english::greetings` and
`japanese::greetings` are distinct, even though their names are both
`greetings`.

Because this crate does not have a `main()` function, and is called `lib.rs`,
Cargo will build this crate as a library:

```bash
$ cargo build
Compiling phrases v0.0.1 (file:///home/you/projects/phrases)
$ ls target/debug
build deps examples libphrases-a7448e02a0468eaa.rlib native
```

`libphrases-hash.rlib` is the compiled crate. Before we see how to use this
crate from another crate, let’s break it up into multiple files.

# Multiple file crates

If each crate were just one file, these files would get very large. It’s often
easier to split up crates into multiple files, and Rust supports this in two
ways.

Instead of declaring a module like this:

```rust,ignore
mod english {
// contents of our module go here
}
```

We can instead declare our module like this:

```rust,ignore
mod english;
```

If we do that, Rust will expect to find either a `english.rs` file, or a
`english/mod.rs` file with the contents of our module.

Note that in these files, you don’t need to re-declare the module: that’s
already been done with the initial `mod` declaration.

Using these two techniques, we can break up our crate into two directories and
seven files:

```bash
$ tree .
.
├── Cargo.lock
├── Cargo.toml
├── src
│ ├── english
│ │ ├── farewells.rs
│ │ ├── greetings.rs
│ │ └── mod.rs
│ ├── japanese
│ │ ├── farewells.rs
│ │ ├── greetings.rs
│ │ └── mod.rs
│ └── lib.rs
└── target
└── debug
├── build
├── deps
├── examples
├── libphrases-a7448e02a0468eaa.rlib
└── native
```

`src/lib.rs` is our crate root, and looks like this:

```rust,ignore
mod english;
mod japanese;
```

These two declarations tell Rust to look for either `src/english.rs` and
`src/japanese.rs`, or `src/english/mod.rs` and `src/japanese/mod.rs`, depending
on our preference. In this case, because our modules have sub-modules, we’ve
chosen the second. Both `src/english/mod.rs` and `src/japanese/mod.rs` look
like this:

```rust,ignore
mod greetings;
mod farewells;
```

Again, these declarations tell Rust to look for either
`src/english/greetings.rs` and `src/japanese/greetings.rs` or
`src/english/farewells/mod.rs` and `src/japanese/farewells/mod.rs`. Because
these sub-modules don’t have their own sub-modules, we’ve chosen to make them
`src/english/greetings.rs` and `src/japanese/farewells.rs`. Whew!

The contents of `src/english/greetings.rs` and `src/japanese/farewells.rs` are
both empty at the moment. Let’s add some functions.

Put this in `src/english/greetings.rs`:

```rust
fn hello() -> String {
"Hello!".to_string()
}
```

Put this in `src/english/farewells.rs`:

```rust
fn goodbye() -> String {
"Goodbye.".to_string()
}
```

Put this in `src/japanese/greetings.rs`:

```rust
fn hello() -> String {
"こんにちは".to_string()
}
```

Of course, you can copy and paste this from this web page, or just type
something else. It’s not important that you actually put ‘konnichiwa’ to learn
about the module system.

Put this in `src/japanese/farewells.rs`:

```rust
fn goodbye() -> String {
"さようなら".to_string()
}
```

(This is ‘Sayōnara’, if you’re curious.)

Now that we have some functionality in our crate, let’s try to use it from
another crate.

# Importing External Crates

We have a library crate. Let’s make an executable crate that imports and uses
our library.

Make a `src/main.rs` and put this in it (it won’t quite compile yet):

```rust,ignore
extern crate phrases;

fn main() {
println!("Hello in English: {}", phrases::english::greetings::hello());
println!("Goodbye in English: {}", phrases::english::farewells::goodbye());

println!("Hello in Japanese: {}", phrases::japanese::greetings::hello());
println!("Goodbye in Japanese: {}", phrases::japanese::farewells::goodbye());
}
```

The `extern crate` declaration tells Rust that we need to compile and link to
the `phrases` crate. We can then use `phrases`’ modules in this one. As we
mentioned earlier, you can use double colons to refer to sub-modules and the
functions inside of them.

(Note: when importing a crate that has dashes in its name "like-this", which is not a valid Rust identifier, it will be converted by changing the dashes to underscores, so you would write `extern crate like_this;`.)

Also, Cargo assumes that `src/main.rs` is the crate root of a binary crate,
rather than a library crate. Our package now has two crates: `src/lib.rs` and
`src/main.rs`. This pattern is quite common for executable crates: most
functionality is in a library crate, and the executable crate uses that
library. This way, other programs can also use the library crate, and it’s also
a nice separation of concerns.

This doesn’t quite work yet, though. We get four errors that look similar to
this:

```bash
$ cargo build
Compiling phrases v0.0.1 (file:///home/you/projects/phrases)
src/main.rs:4:38: 4:72 error: function `hello` is private
src/main.rs:4 println!("Hello in English: {}", phrases::english::greetings::hello());
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: in expansion of format_args!
:2:25: 2:58 note: expansion site
:1:1: 2:62 note: in expansion of print!
:3:1: 3:54 note: expansion site
:1:1: 3:58 note: in expansion of println!
phrases/src/main.rs:4:5: 4:76 note: expansion site
```

By default, everything is private in Rust. Let’s talk about this in some more
depth.

# Exporting a Public Interface

Rust allows you to precisely control which aspects of your interface are
public, and so private is the default. To make things public, you use the `pub`
keyword. Let’s focus on the `english` module first, so let’s reduce our `src/main.rs`
to just this:

```rust,ignore
extern crate phrases;

fn main() {
println!("Hello in English: {}", phrases::english::greetings::hello());
println!("Goodbye in English: {}", phrases::english::farewells::goodbye());
}
```

In our `src/lib.rs`, let’s add `pub` to the `english` module declaration:

```rust,ignore
pub mod english;
mod japanese;
```

And in our `src/english/mod.rs`, let’s make both `pub`:

```rust,ignore
pub mod greetings;
pub mod farewells;
```

In our `src/english/greetings.rs`, let’s add `pub` to our `fn` declaration:

```rust,ignore
pub fn hello() -> String {
"Hello!".to_string()
}
```

And also in `src/english/farewells.rs`:

```rust,ignore
pub fn goodbye() -> String {
"Goodbye.".to_string()
}
```

Now, our crate compiles, albeit with warnings about not using the `japanese`
functions:

```bash
$ cargo run
Compiling phrases v0.0.1 (file:///home/you/projects/phrases)
src/japanese/greetings.rs:1:1: 3:2 warning: function is never used: `hello`, #[warn(dead_code)] on by default
src/japanese/greetings.rs:1 fn hello() -> String {
src/japanese/greetings.rs:2 "こんにちは".to_string()
src/japanese/greetings.rs:3 }
src/japanese/farewells.rs:1:1: 3:2 warning: function is never used: `goodbye`, #[warn(dead_code)] on by default
src/japanese/farewells.rs:1 fn goodbye() -> String {
src/japanese/farewells.rs:2 "さようなら".to_string()
src/japanese/farewells.rs:3 }
Running `target/debug/phrases`
Hello in English: Hello!
Goodbye in English: Goodbye.
```

`pub` also applies to `struct`s and their member fields. In keeping with Rust’s
tendency toward safety, simply making a `struct` public won't automatically
make its members public: you must mark the fields individually with `pub`.

Now that our functions are public, we can use them. Great! However, typing out
`phrases::english::greetings::hello()` is very long and repetitive. Rust has
another keyword for importing names into the current scope, so that you can
refer to them with shorter names. Let’s talk about `use`.

# Importing Modules with `use`

Rust has a `use` keyword, which allows us to import names into our local scope.
Let’s change our `src/main.rs` to look like this:

```rust,ignore
extern crate phrases;

use phrases::english::greetings;
use phrases::english::farewells;

fn main() {
println!("Hello in English: {}", greetings::hello());
println!("Goodbye in English: {}", farewells::goodbye());
}
```

The two `use` lines import each module into the local scope, so we can refer to
the functions by a much shorter name. By convention, when importing functions, it’s
considered best practice to import the module, rather than the function directly. In
other words, you _can_ do this:

```rust,ignore
extern crate phrases;

use phrases::english::greetings::hello;
use phrases::english::farewells::goodbye;

fn main() {
println!("Hello in English: {}", hello());
println!("Goodbye in English: {}", goodbye());
}
```

But it is not idiomatic. This is significantly more likely to introduce a
naming conflict. In our short program, it’s not a big deal, but as it grows, it
becomes a problem. If we have conflicting names, Rust will give a compilation
error. For example, if we made the `japanese` functions public, and tried to do
this:

```rust,ignore
extern crate phrases;

use phrases::english::greetings::hello;
use phrases::japanese::greetings::hello;

fn main() {
println!("Hello in English: {}", hello());
println!("Hello in Japanese: {}", hello());
}
```

Rust will give us a compile-time error:

```text
Compiling phrases v0.0.1 (file:///home/you/projects/phrases)
src/main.rs:4:5: 4:40 error: a value named `hello` has already been imported in this module [E0252]
src/main.rs:4 use phrases::japanese::greetings::hello;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
Could not compile `phrases`.
```

If we’re importing multiple names from the same module, we don’t have to type it out
twice. Instead of this:

```rust,ignore
use phrases::english::greetings;
use phrases::english::farewells;
```

We can use this shortcut:

```rust,ignore
use phrases::english::{greetings, farewells};
```

## Re-exporting with `pub use`

You don’t just use `use` to shorten identifiers. You can also use it inside of your crate
to re-export a function inside another module. This allows you to present an external
interface that may not directly map to your internal code organization.

Let’s look at an example. Modify your `src/main.rs` to read like this:

```rust,ignore
extern crate phrases;

use phrases::english::{greetings,farewells};
use phrases::japanese;

fn main() {
println!("Hello in English: {}", greetings::hello());
println!("Goodbye in English: {}", farewells::goodbye());

println!("Hello in Japanese: {}", japanese::hello());
println!("Goodbye in Japanese: {}", japanese::goodbye());
}
```

Then, modify your `src/lib.rs` to make the `japanese` mod public:

```rust,ignore
pub mod english;
pub mod japanese;
```

Next, make the two functions public, first in `src/japanese/greetings.rs`:

```rust,ignore
pub fn hello() -> String {
"こんにちは".to_string()
}
```

And then in `src/japanese/farewells.rs`:

```rust,ignore
pub fn goodbye() -> String {
"さようなら".to_string()
}
```

Finally, modify your `src/japanese/mod.rs` to read like this:

```rust,ignore
pub use self::greetings::hello;
pub use self::farewells::goodbye;

mod greetings;
mod farewells;
```

The `pub use` declaration brings the function into scope at this part of our
module hierarchy. Because we’ve `pub use`d this inside of our `japanese`
module, we now have a `phrases::japanese::hello()` function and a
`phrases::japanese::goodbye()` function, even though the code for them lives in
`phrases::japanese::greetings::hello()` and
`phrases::japanese::farewells::goodbye()`. Our internal organization doesn’t
define our external interface.

Here we have a `pub use` for each function we want to bring into the
`japanese` scope. We could alternatively use the wildcard syntax to include
everything from `greetings` into the current scope: `pub use self::greetings::*`.

What about the `self`? Well, by default, `use` declarations are absolute paths,
starting from your crate root. `self` makes that path relative to your current
place in the hierarchy instead. There’s one more special form of `use`: you can
`use super::` to reach one level up the tree from your current location. Some
people like to think of `self` as `.` and `super` as `..`, from many shells’
display for the current directory and the parent directory.

Outside of `use`, paths are relative: `foo::bar()` refers to a function inside
of `foo` relative to where we are. If that’s prefixed with `::`, as in
`::foo::bar()`, it refers to a different `foo`, an absolute path from your
crate root.

This will build and run:

```bash
$ cargo run
Compiling phrases v0.0.1 (file:///home/you/projects/phrases)
Running `target/debug/phrases`
Hello in English: Hello!
Goodbye in English: Goodbye.
Hello in Japanese: こんにちは
Goodbye in Japanese: さようなら
```

## Complex imports

Rust offers several advanced options that can add compactness and
convenience to your `extern crate` and `use` statements. Here is an example:

```rust,ignore
extern crate phrases as sayings;

use sayings::japanese::greetings as ja_greetings;
use sayings::japanese::farewells::*;
use sayings::english::{self, greetings as en_greetings, farewells as en_farewells};

fn main() {
println!("Hello in English; {}", en_greetings::hello());
println!("And in Japanese: {}", ja_greetings::hello());
println!("Goodbye in English: {}", english::farewells::goodbye());
println!("Again: {}", en_farewells::goodbye());
println!("And in Japanese: {}", goodbye());
}
```

What's going on here?

First, both `extern crate` and `use` allow renaming the thing that is being
imported. So the crate is still called "phrases", but here we will refer
to it as "sayings". Similarly, the first `use` statement pulls in the
`japanese::farewells` module from the crate, but makes it available as
`jp_farewells` as opposed to simply `farewells`. This can help to avoid
ambiguity when importing similarly-named items from different places.

The second `use` statement uses a star glob to bring in _all_ symbols from the
`sayings::japanese::farewells` module. As you can see we can later refer to
the Japanese `goodbye` function with no module qualifiers. This kind of glob
should be used sparingly.

The third `use` statement bears more explanation. It's using "brace expansion"
globbing to compress three `use` statements into one (this sort of syntax
may be familiar if you've written Linux shell scripts before). The
uncompressed form of this statement would be:
```rust,ignore
use sayings::english;
use sayings::english::greetings as en_greetings;
use sayings::english::farewells as en_farewells;
```
As you can see, the curly brackets compress `use` statements for several items
under the same path, and in this context `self` just refers back to that path.
Note: The curly brackets cannot be nested or mixed with star globbing.
trait-objects
# 5.22. 트레잇 객체 (Trait Objects) - 75%

다형성과 관련된 코드가 실행될 때, 어떤 버전의 코드가 실행될지 결정하는 메카니즘이 필요합니다.
이것을 'dispatch' 라고 하며, 두 가지의 주요 형태가 있습니다: 정적 dispatch 와 동적 dispatch.
rust 는 정적 dispatch 를 선호하는데, 'trait objects' 라는 메커니즘을 통해서 동적 dispatch 역시 지원합니다.

## 배경

이 장에서 트레잇과 몇 개의 구현체가 필요합니다.
`Foo` 라는 간단한 코드를 만들어 봅시다. `String` 을 리턴하는 하나의 메소드를 갖고 있습니다.

```rust
trait Foo {
fn method(&self) -> String;
}
```

`u8`과 `String` 에 대해 이 트레잇을 구현 할 것입니다.

```rust
# trait Foo { fn method(&self) -> String; }
impl Foo for u8 {
fn method(&self) -> String { format!("u8: {}", *self) }
}

impl Foo for String {
fn method(&self) -> String { format!("string: {}", *self) }
}
```

## 정적 dispatch

정적 dispatch 를 수행하기 위해, 이 트레잇과 트레잇 바운드를 사용할 수 있습니다:

```rust
# trait Foo { fn method(&self) -> String; }
# impl Foo for u8 { fn method(&self) -> String { format!("u8: {}", *self) } }
# impl Foo for String { fn method(&self) -> String { format!("string: {}", *self) } }
fn do_something(x: T) {
x.method();
}

fn main() {
let x = 5u8;
let y = "Hello".to_string();

do_something(x);
do_something(y);
}
```

여기서 rust 는 정적 dispatch 를 수행하기 위해 단형화(monomorphization)를 사용합니다.
이 말은 rust 는 `u8` 과 `String` 을 위한 특별한 버전의 `do_something()`을 만들고, 이 메소드에 대한 호출부들을 이 구체화된 함수들에 대한 호출로 바꾼다는 것을 의미 합니다. 다르게 말하면, rust 는 이렇게 생성 합니다:

```rust
# trait Foo { fn method(&self) -> String; }
# impl Foo for u8 { fn method(&self) -> String { format!("u8: {}", *self) } }
# impl Foo for String { fn method(&self) -> String { format!("string: {}", *self) } }
fn do_something_u8(x: u8) {
x.method();
}

fn do_something_string(x: String) {
x.method();
}

fn main() {
let x = 5u8;
let y = "Hello".to_string();

do_something_u8(x);
do_something_string(y);
}
```

이것은 아주 큰 장점을 지니는데: 함수 호출하는 부분을 컴파일 타임에 알 수 있기 때문에, 정적 dispatch 는 함수 호출을 인라인 할 수 있으며, 인라인은 좋은 최적화의 핵심 입니다. 정적 dispatch 는 빠르지만 단점이 있습니다: 바이너리에 각 타입 별로 같은 함수의 복사본들이 있기 때문에 코드가 커집니다. (code bloat)

뿐만 아니라, 컴파일러는 완벽하지 않기 때문에 "최적화" 코드가 더 느려질 수 도 있습니다.
예를 들면, 너무 과하게 함수가 인라인되면 명령어 캐시를 넘칠 수 있습니다. (캐시가 우리 주변의 모든 것을 지배합니다)
이것이 `#[inline]`과 `#[inline(always)]` 이 신중하게 사용되어야 하는 이유이고, 동적 dispatch 가 가끔 더 효율적인 이유 입니다.

그러나, 일반적인 경우 정적 dispatch 를 사용하는 것이 더 효율적이고, 항상 정적으로 dispatch 되는 wrapper 함수가 동적 dispatch 를 수행하도록 할 수 있습니다. 반대로는 되지 않으며, 정적 호출이 더 유연하다는 것을 의미 합니다.
표준 라이브러리는 이런 이유로 가능하면 정적으로 dispatch 하도록 하고 있습니다.

## 동적 dispatch

Rust 는 ‘트레잇 객채(trait objects)’ 라는 기능을 통해 동적 dispatch 를 제공 합니다.
트레잇 객체는 `&Foo` 혹은 `Box` 와 같이 주어진 트레잇을 구현한 *어떤* 타입의 값을 저장하는 평범한 값들이며, 정확한 타입은 런타입에 결정 될 수 있습니다.

트레잇 객체는 트레잇을 구현한 구체적인 타입에 대한 포인터를 *캐스팅* 하거나 (예. `&x as &Foo`) *강제(coercing)* 해서 (예. `&Foo` 가 파라미터로 정의된 함수에 대해 인자로 `&x` 를 사용) 얻을 수 있습니다.

이러한 트레잇 객체에 대한 강제(coercion)나 캐스팅은 `&mut Foo` 나 `Box` 에 대한 포인터인 `&mut T`, `Box` 에 대해서도 모두 그 순간에 동작합니다. 강제와 캐스팅은 동일합니다.

이 작업은 특정 포인터의 타입에 대한 컴파일러의 지식을 ‘지우는’ 것 처럼 보입니다. 이런 이유로 트레잇 객체는 가끔 ‘타입 지우개(type erasure)’ 로 불립니다.

위 예제로 돌아가면, 트레잇 객체들을 동일한 트래잇으로 캐스팅 함으로써 동적 dispatch 를 수행할 수 있습니다:

```rust
# trait Foo { fn method(&self) -> String; }
# impl Foo for u8 { fn method(&self) -> String { format!("u8: {}", *self) } }
# impl Foo for String { fn method(&self) -> String { format!("string: {}", *self) } }

fn do_something(x: &Foo) {
x.method();
}

fn main() {
let x = 5u8;
do_something(&x as &Foo);
}
```

혹은 강제하기:

```rust
# trait Foo { fn method(&self) -> String; }
# impl Foo for u8 { fn method(&self) -> String { format!("u8: {}", *self) } }
# impl Foo for String { fn method(&self) -> String { format!("string: {}", *self) } }

fn do_something(x: &Foo) {
x.method();
}

fn main() {
let x = "Hello".to_string();
do_something(&x);
}
```

트레잇 객체를 받는 함수는 `Foo` 를 구현한 각각의 타입들에 대해서 구체화 하지 않습니다: 항상 그렇지는 않지만 하나의 복사본이 생성되고 적은 코드 블로트가 발생합니다. 그러나 더 느린 가상함수 호출 비용이 발생하게 되고, 효과적으로 인라이닝(inlining) 하고 관련된 최적화가 발생하는 것을 방해합니다.

### 왜 포인터인가요?

rust 는 많은 관리되는 언어(managed language)와 다르게 기본적으로 포인터를 사용해서 객체를 할당하지 않기 때문에 타입은 다른 크기를 갖을 수 있습니다.
함수의 인자로 값을 넘기는 경우, 그리고 스택(stack)에서 값을 이동하거나 저장하기 위해 힙(heap)에 할당(그리고 해제)하는 것들과 같은 일을 하는데 있어서, 컴파일 타임에 값의 크기를 아는 것은 중요 합니다.

`Foo` 와 같은 경우, 최소한 `String` (24 바이트) 혹은 `u8` (1 바이트) 크기인 값을 필요로 할 것이며, `Foo`를 구현하는 종속적인 크레이트에서의 어떤 타입이던지 역시 최소 몇 바이트가 되어야 할 것입니다.

값을 포인터를 통해 할당한다는 것은 트레잇 객체를 넘기는 경우에 한해서는 값의 크기는 유의미하지 않다는 것이며, 단지 포인터 자체의 크기만 의미 있다는 것입니다.

### 표현(Representation)

트레잇 객체를 사용한 트리잇의 메소드들은 전통적으로 (컴파일러에 의해 생성되고 관리되는) 'vtable' 이라고 하는 함수 포인터들의 특별한 기록들을 통해서 호출할 수 있습니다.

트레잇 객체는 단순하기도 하고 복잡하기도 합니다: 그것들의 핵심 표현이나 모양(layout)은 아주 간단합니다만, 이상한 에러 메세지들도 있고 확인해봐야 할 놀라운 동작들도 있습니다.

트레잇 객체의 런타임 표현을 간단하게 살펴보도록 합시다. `std::raw` 모듈은 복잡한 빌트인 타입들과 같은 모양을 갖는 구조체들을 갖고 있습니다. [including trait objects][stdraw]:

```rust
# mod foo {
pub struct TraitObject {
pub data: *mut (),
pub vtable: *mut (),
}
# }
```

[stdraw]: ../std/raw/struct.TraitObject.html

즉, `&Foo` 과 같은 트리잇 객체는 'data' 포인터와 'vtable' 포인터로 구성됩니다.

data 포인터는 트리엣 객체가 저장하고 있는 (어떤 알려지지 않은 타입 `T`의) 데이터를 가르키고 있으며, vtable 포인터는 `T` 에 대한 `Foo` 의 구현에 대응되는 vtable(가상 메소드 테이블)을 가르 킵니다.

vtable 은 본질적으로는 구현된 각 메소드들에 대한 구체적인 기계 코드 조각을 가르키는 함수 포인터들을 갖고 있는 구조체 입니다. `trait_object.method()` 와 같은 메소드 호출은 vtable 에서 정확한 포인터를 가져와서 동적으로 호출 할 것입니다. 예를 들면:

```rust,ignore
struct FooVtable {
destructor: fn(*mut ()),
size: usize,
align: usize,
method: fn(*const ()) -> String,
}

// u8:

fn call_method_on_u8(x: *const ()) -> String {
// 컴파일러는 이 함수가 u8 을 가르키는 `x` 에 대해서만 호출되도록
// 보장합니다.
let byte: &u8 = unsafe { &*(x as *const u8) };

byte.method()
}

static Foo_for_u8_vtable: FooVtable = FooVtable {
destructor: /* compiler magic */,
size: 1,
align: 1,

// cast to a function pointer
method: call_method_on_u8 as fn(*const ()) -> String,
};


// String:

fn call_method_on_String(x: *const ()) -> String {
// 컴파일러는 이 함수가 String 을 가르키는 `x` 에 대해서만 호출되도록
// 보장합니다.
let string: &String = unsafe { &*(x as *const String) };

string.method()
}

static Foo_for_String_vtable: FooVtable = FooVtable {
destructor: /* compiler magic */,
// values for a 64-bit computer, halve them for 32-bit ones
size: 24,
align: 8,

method: call_method_on_String as fn(*const ()) -> String,
};
```
각 vtable 의 `destructor` 필드는 vtable 의 타입에 대한 리소스들을 정리 하는데 사용되는 함수를 가르킵니다, `u8` 은 사소하지만, `String` 인 경우는 메모리를 해제 할 것입니다. 이것은 `Box` 와 같이 트레잇 객체를 소유하는 경우, `Box` 에 대한 할당과 스코프를 벗어났을 때 내부 타입을 정리 하기 위해 필요합니다. `size` 와 `align` 필드들은 지워진 타입에 대한 크기와 정렬(alignment) 요구사항들을 저장합니다; 이것들은 기본적으로 소멸자(destructor)에 포함되기 때문에 지금은 사용되지 않지만, 트레잇 객체는 계속해서 더 유연하게 만들어 지기 때문에 나중에는 사용될 것 입니다.

`Foo` 를 구현한 몇 개의 값들이 있다고 가정할 때, `Foo` 트레잇 객체의 구조에 대한 명시적인 형태나 사용은 약간 아래와 비슷할 것입니다. (타입 불일치는 무시: 어쨌든 모두 포인터):

```rust,ignore
let a: String = "foo".to_string();
let x: u8 = 1;

// let b: &Foo = &a;
let b = TraitObject {
// store the data
data: &a,
// store the methods
vtable: &Foo_for_String_vtable
};

// let y: &Foo = x;
let y = TraitObject {
// store the data
data: &x,
// store the methods
vtable: &Foo_for_u8_vtable
};

// b.method();
(b.vtable.method)(b.data);

// y.method();
(y.vtable.method)(y.data);
```

## Object Safety
Object 보호

모든 트레잇이 트레잇 객체를 만들어낼 수 있는 것은 아니다. 예를 들어, vector들은 `Clone`을 구현하고 있지만, 트레잇 객체를 만들고자 한다면:

Not every trait can be used to make a trait object. For example, vectors implement
`Clone`, but if we try to make a trait object:

```ignore
let v = vec![1, 2, 3];
let o = &v as &Clone;
```

우리는 에러를 받게 된다:
We get an error:

```text
error: cannot convert to a trait object because trait `core::clone::Clone` is not object-safe [E0038]
let o = &v as &Clone;
^~
note: the trait cannot require that `Self : Sized`
let o = &v as &Clone;
^~
```

해당 에러는 `Clone`이 '객체-안전'하지 않다고 말한다. 오직 객체-안전한 트레잇만이 트레잇 객체를 만들 수 있다. 다음의 사항들을 만족할 때 트레잇이 객체-앉전 하다고 할 수 있다:
The error says that `Clone` is not ‘object-safe’. Only traits that are
object-safe can be made into trait objects. A trait is object-safe if both of
these are true:

* `Self: Sized`가 필요치 않은 트레잇
* 소유한 모든 메소드가 객체-안전해야 함.
* the trait does not require that `Self: Sized`
* all of its methods are object-safe

그렇다면 어떻게 객체-안전한 메소드를 만들까? 모든 메소드가 `Self: Sized`를 반드시 요구하던가 다음의 내용들을 만족해야 한다.:
So what makes a method object-safe? Each method must require that `Self: Sized`
or all of the following:

* 어떤 타입 인자도 가져서는 안된다.
* `Self`를 사용해서는 안된다.
* must not have any type parameters
* must not use `Self`

휘유~! 살펴본 바와 같이, 이들 룰에 대한 것의 대부분은 `Self`에 대한 내용이다.
"특별한 경우를 제외하고, 트레잇의 메소드에서 `Self`를 사용하는 것은 객체-안전하지 않다." - 좋은 직관.
Whew! As we can see, almost all of these rules talk about `Self`. A good intuition
is “except in special circumstances, if your trait’s method uses `Self`, it is not
object-safe.”
ufcs
# 5.24. 전역 함수 사용법 (Universal Function Call Syntax) - 0%

종종, 함수들은 동일한 이름을 갖게 된다. 다음 코드를 살펴보자:
Sometimes, functions can have the same names. Consider this code:

```rust
trait Foo {
fn f(&self);
}

trait Bar {
fn f(&self);
}

struct Baz;

impl Foo for Baz {
fn f(&self) { println!("Baz’s impl of Foo"); }
}

impl Bar for Baz {
fn f(&self) { println!("Baz’s impl of Bar"); }
}

let b = Baz;
```

우리가 `b.f()`를 호출하고자 하면, 다음의 에러를 얻게 된다:
If we were to try to call `b.f()`, we’d get an error:

```text
error: multiple applicable methods in scope [E0034]
b.f();
^~~
note: candidate #1 is defined in an impl of the trait `main::Foo` for the type
`main::Baz`
fn f(&self) { println!("Baz’s impl of Foo"); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: candidate #2 is defined in an impl of the trait `main::Bar` for the type
`main::Baz`
fn f(&self) { println!("Baz’s impl of Bar"); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

```

우리가 필요한 메소드가 어떤 것인지 분명히 할 필요가 있다. 이런 기능을 '우주적(전역) 함수 호출 문법', 이라고 부르고, 다음과 같이 사용한다:
We need a way to disambiguate which method we need. This feature is called
‘universal function call syntax’, and it looks like this:

```rust
# trait Foo {
# fn f(&self);
# }
# trait Bar {
# fn f(&self);
# }
# struct Baz;
# impl Foo for Baz {
# fn f(&self) { println!("Baz’s impl of Foo"); }
# }
# impl Bar for Baz {
# fn f(&self) { println!("Baz’s impl of Bar"); }
# }
# let b = Baz;
Foo::f(&b);
Bar::f(&b);
```

나눠서 살펴보자.
Let’s break it down.

```rust,ignore
Foo::
Bar::
```

호출문의 절반은 두 트레잇들이다: `Foo`와 `Bar`. 이들의 끝 부분이 실제로 어떤 일을 할지를 결정한다: 러스트는 사용된 트레잇 이름에서 호출하게 된다.
These halves of the invocation are the types of the two traits: `Foo` and
`Bar`. This is what ends up actually doing the disambiguation between the two:
Rust calls the one from the trait name you use.

```rust,ignore
f(&b)
```

우리가 메소드를 `b.f()`같이 [method syntax][methodsyntax]를 사용하여 호출하게 되면, 러스트는 `f()`가 `&self`를 취할 경우 자동으로 `b`를 대여한다. 이번 경우에는, 러스트는 하지 않을 것이고, 그렇기에 우리는 `&b`를 명시적으로 전달할 필요가 있다.
When we call a method like `b.f()` using [method syntax][methodsyntax], Rust
will automatically borrow `b` if `f()` takes `&self`. In this case, Rust will
not, and so we need to pass an explicit `&b`.

[methodsyntax]: method-syntax.html

# Angle-bracket Form
꺾쇄 괄호 형태( <> )

이번에 얘기하고자 하는 UFCS(Universal Function Call Syntax : 전역 함수 호출 문법)이다:

The form of UFCS we just talked about:

```rust,ignore
Trait::method(args);
```

이는 줄여쓴 것이다. 어떤 상황에는 확장된 형식을 사용해야 할 필요가 있다.
Is a short-hand. There’s an expanded form of this that’s needed in some
situations:

```rust,ignore
::method(args);
```

`<>::` 문법은 타입의 힌트를 제공한다. `<>`안에 타입이 들어가게 된다. 이번 경우에 타입은 `Type as Trait`이고, `Trait`의 `method` 를 호출하는 버전을 보여주고자 한다. `as Trait` 부분은 부가적인 것으로 타입이 모호하지 않다면 빼도 된다. 꺾쇄 괄호 외엔 줄여쓴 형태와 같다.
The `<>::` syntax is a means of providing a type hint. The type goes inside
the `<>`s. In this case, the type is `Type as Trait`, indicating that we want
`Trait`’s version of `method` to be called here. The `as Trait` part is
optional if it’s not ambiguous. Same with the angle brackets, hence the
shorter form.

여기 긴 형태의 예제가 있다.
Here’s an example of using the longer form.

```rust
trait Foo {
fn clone(&self);
}

#[derive(Clone)]
struct Bar;

impl Foo for Bar {
fn clone(&self) {
println!("Making a clone of Bar");

::clone(self);
}
}
```

이는 `Foo` 대신 `Clone` 트레잇의 `clone()`을 호출할 것이다.
This will call the `Clone` trait’s `clone()` method, rather than `Foo`’s.