Resolving conflicts between 'master' and 'ziriso'

ziriso authored
revision c2f6ec3e4b05a158a510f863cd59647288edf5cf
Contents
About.txt
readme.md
getting-started.md
installing-rust.md
hello-world.md
hello-cargo.md
learn-rust.md
guessing-game.md
dining-philosophers.md
rust-inside-other-languages.md
effective-rust.md
the-stack-and-the-heap.md
testing.md
conditional-compilation.md
iterators.md
concurrency.md
error-handling.md
ffi.md
borrow-and-asref.md
release-channels.md
syntax-and-semantics.md
variable-bindings.md
functions.md
primitive-types.md
comments.md
if.md
for-loops.md
while-loops.md
ownership.md
references-and-borrowing.md
lifetimes.md
mutability.md
structs.md
enums.md
match.md
patterns.md
method-syntax.md
vectors.md
strings.md
concordance.txt
concordance.md
concordance
# 9. 용어 색인 (Concordance)

* 이 페이지는 Rust 한글화 프로젝트에서 사용되는 용어들의 영문과 국문을 일대일로 표기해놓은 가이드입니다.
* 번역하시면서 새로운 용어가 나오면 추가해주세요. 좀 더 적절한 대체 용어가 있다면 구성원들의 의견을 모아 반영합니다.
* 알파벳 순으로 표기합니다.
* [정보통신용어사전](http://word.tta.or.kr/terms/terms.jsp), [텀즈](http://www.terms.co.kr/), [Joinc 컴퓨터 용어사전](http://www.joinc.co.kr/modules/moniwiki/wiki.php/man/12), [정보통신기술용어해석](http://www.ktword.co.kr/) 등을 참조하세요.

## A - G

* address - 주소
* allocate - 할당하다
* binding - 바인딩
* borrowing - 빌림
* Cargo - 카고
* compile - 컴파일
* dynamic language - 동적 언어
* exterior mutability - 외적 가변성
* Field-level mutability - 필드 단위 가변성
* function - 함수
* garbage collector - 가비지 콜렉터

## H - N

* heap - 힙
* immutable - 변경할 수 없는
* input - 입력
, 불변
* immutable - 불변
* input - 입력
* interior mutability - 내적 가변성

* iterator - 반복자
* lifetime - 수명
* lifetime elision - 수명의 생략
* LIFO - LIFO
* macro - 매크로
* mutable - 변경할 수 있는
* mutable - 가변
* mutability - 가변성


## O - Z

* output - 출력
* ownership - 소유권
* pointer - 포인터
* Rust - 러스트
* semantics - 구문
* signiture - 시그니처
* stack - 스택
* syntax - 의미
* testing- 테스팅
* variable - 변수
* vector - 벡터
* verification - 검증
* zero-cost abstractions - 무비용 추상화
mutability
# 5.11. 변성 (Mutability) - 0%

Mutability, the ability to change something, works a bit differently in Rust
than in other languages. The first aspect of mutability is its non-default
status:

```rust,ignore
let x = 5;
x = 6; // error!
```

We can introduce mutability with the `mut` keyword:

```rust
let mut x = 5;

x = 6; // no problem!
```

This is a mutable [variable binding][vb]. When a binding is mutable, it means
you’re allowed to change what the binding points to. So in the above example,
it’s not so much that the value at `x` is changing, but that the binding
changed from one `i32` to another.

[vb]: variable-bindings.html

If you want to change what the binding points to, you’ll need a [mutable reference][mr]:

```rust
let mut x = 5;
let y = &mut x;
```

[mr]: references-and-borrowing.html

`y` is an immutable binding to a mutable reference, which means that you can’t
bind `y` to something else (`y = &mut z`), but you can mutate the thing that’s
bound to `y`. (`*y = 5`) A subtle distinction.

Of course, if you need both:

```rust
let mut x = 5;
let mut y = &mut x;
```

Now `y` can be bound to another value, and the value it’s referencing can be
changed.

It’s important to note that `mut` is part of a [pattern][pattern], so you
can do things like this:

```rust
let (mut x, y) = (5, 6);

fn foo(mut x: i32) {
# }
```

[pattern]: patterns.html

# Interior vs. Exterior Mutability

However, when we say something is ‘immutable’ in Rust, that doesn’t mean that
it’s not able to be changed: We mean something has ‘exterior mutability’. Consider,
for example, [`Arc`][arc]:

```rust
use std::sync::Arc;

let x = Arc::new(5);
let y = x.clone();
```

[arc]: ../std/sync/struct.Arc.html

When we call `clone()`, the `Arc` needs to update the reference count. Yet
we’ve not used any `mut`s here, `x` is an immutable binding, and we didn’t take
`&mut 5` or anything. So what gives?

To understand this, we have to go back to the core of Rust’s guiding
philosophy, memory safety, and the mechanism by which Rust guarantees it, the
[ownership][ownership] system, and more specifically, [borrowing][borrowing]:

> You may have one or the other of these two kinds of borrows, but not both at
> the same time:
>
> * one or more references (`&T`) to a resource.
> * exactly one mutable reference (`&mut T`)

[ownership]: ownership.html
[borrowing]: borrowing.html#The-Rules

So, that’s the real definition of ‘immutability’: is this safe to have two
pointers to? In `Arc`’s case, yes: the mutation is entirely contained inside
the structure itself. It’s not user facing. For this reason, it hands out `&T`
with `clone()`. If it handed out `&mut T`s, though, that would be a problem.

Other types, like the ones in the [`std::cell`][stdcell] module, have the
opposite: interior mutability. For example:

```rust
use std::cell::RefCell;

let x = RefCell::new(42);

let y = x.borrow_mut();
```

[stdcell]: ../std/cell/index.html

RefCell hands out `&mut` references to what’s inside of it with the
`borrow_mut()` method. Isn’t that dangerous? What if we do:

```rust,ignore
use std::cell::RefCell;

let x = RefCell::new(42);

let y = x.borrow_mut();
let z = x.borrow_mut();
# (y, z);
```

This will in fact panic, at runtime. This is what `RefCell` does: it enforces
Rust’s borrowing rules at runtime, and `panic!`s if they’re violated. This
allows us to get around another aspect of Rust’s mutability rules. Let’s talk
about it first.

## Field-level mutability

Mutability is a property of either a borrow (`&mut`) or a binding (`let mut`).
This means that, for example, you cannot have a [`struct`][struct] with
some fields mutable and some immutable:
가변성 (Mutability) - 99%

Rust에서, 변화할 수 있음을 나타내는 '가변성(Mutability)'은 다른 언어와는 약간 다르게 동작합니다. 가변성의 가장 중요한 측면은, 이것이 기본 상태가 아니라는 것입니다:

```rust,ignore
let x = 5;
x = 6; // error!
```

(역자 주 : 다른 프로그래밍 언어와는 달리) 아래와 같이 `mut` 키워드를 붙여야만 가변성을 부여할 수 있습니다:

```rust
let mut x = 5;

x = 6; // no problem!
```

이것은 가변(mutable) [변수 바인딩(variable binding)][vb]입니다. 바인딩이 변경 가능하다는 것의 의미는, 바인딩이 어디를 가리키는지를 바꿀 수 있다는 얘기입니다. 따라서 위의 예제에서는, `x`에 있는 값이 변경된다기보다는, 바인딩이 어떤 `i32` 객체에서 다른 것으로 변화한다고 볼 수 있습니다.

[vb]: variable-bindings.html

만약 바인딩이 가리키는 곳의 내용을 바꾸기를 원한다면, [mutable reference][mr]를 사용해야 합니다:

```rust
let mut x = 5;
let y = &mut x;
```

[mr]: references-and-borrowing.html

`y`는 가변(mutable) 참조에 대한 불변(immutable) 바인딩이며, 이것은 (`y = &mut z`와 같이) `y`에 묶인 것을 또다른 무언가로 바꿔 묶을 수는 없지만, (`*y = 5`와 같이) `y`에 묶여있는 것 자체를 바꾸는 것은 가능합니다. 여기에는 아주 미묘한 차이가 있습니다.

물론, 양쪽이 다 필요하다면 다음과 같이 할 수 있습니다.

```rust
let mut x = 5;
let mut y = &mut x;
```

이제 `y`는 다른 값에 묶일 수 있고, 그것이 참조하는 값 자체도 바뀔 수 있습니다.

`mut`는 [패턴][pattern]의 한 부분이라는 것에 주목하시길 바라며, 따라서 다음과 같이 할 수 있습니다:

```rust
let (mut x, y) = (5, 6);

fn foo(mut x: i32) {
# }
```

[pattern]: patterns.html

# 내적(Interior) vs. 외적(Exterior) 가변성

그러나, 러스트에서 무언가가 '불변(immutable)'이라고 말할 때, 이것이 변화가 불가능하다는 말은 아닙니다: 이것이 의미하는 바는, 어떤 무언가는 '외적 가변성(exterior mutability)'을 가질 수 있다는 뜻입니다. [`Arc`][arc] 와 관련하여 다음 예제에 대해 생각해 봅시다:

```rust
use std::sync::Arc;

let x = Arc::new(5);
let y = x.clone();
```

[arc]: ../std/sync/struct.Arc.html

우리가 `clone()`을 호출할 때, `Arc`는 참조 카운트를 갱신합니다. 그러나 우리는 여기에 어떤 `mut`도 사용하지 않았기에, `x`는 불변(immutable) 바인딩이며, `&mut 5` 혹은 그 어떤 것도 취하지 않았습니다. 그럼 이것은 어떻게 된 일일까요?

이것을 이해하기 위해서는 러스트의 기본 철학의 핵심인 메모리 안전성과, 그것이 돌아가는 방식인 [소유권][ownership] 시스템, 그리고 더 정확하게는 [빌림(borrowing)][borrowing]에 대해 다시 돌아볼 필요가 있습니다:

> 어떤 리소스에 대해 다음 두 종류의 빌림 중 어느 쪽이든 가질 수 있지만, 두 종류의 빌림을 동시에 유지할 수는 없다:
>
> * 한 리소스로의 0개에서 N개까지의 참조(&T)
> * 한 리소스로의 정확히 1개의 가변 참조(&mut T)
>

[ownership]: ownership.html
[borrowing]: borrowing.html#The-Rules

이것이 바로 '불변성(immutability)'의 진짜 정의입니다: 그러면, 두개의 포인터를 동시에 가지는 것은 안전할까요? (원문 : is this safe to have two pointers to?) `Arc`의 경우에 대해서라면, 맞습니다. 변경은 완전히 구조체 그 안쪽에서만 일어납니다. 이것은 사용자가 직접 대면하지 않습니다. 이런 이유로, 이것은`clone()`을 통해 `&T`를 건네줍니다. 만약 이것이 `&mut T`을 건네준다면, 이것은 문제가 될 것입니다(역자 주 : 한 리소스에 대해 한 개의 불변 참조와 한 개의 가변 참조를 동시에 가지게 됩니다).

다른 타입들, 그러니까 [`std::cell`][stdcell] 모듈 안에 있는 것들은, 그 반대입니다. 여기서는 내적 가변성(interior mutability)을 갖습니다. 예를 들자면:

```rust
use std::cell::RefCell;

let x = RefCell::new(42);

let y = x.borrow_mut();
```

[stdcell]: ../std/cell/index.html

RefCell은 그 안쪽에 대한 `&mut` 참조를 `borrow_mut()` 메쏘드를 통해 건네줍니다. 위험하지 않을까요? 만약 우리가 아래와 같이 한다면:

```rust,ignore
use std::cell::RefCell;

let x = RefCell::new(42);

let y = x.borrow_mut();
let z = x.borrow_mut();
# (y, z);
```

이것은 실제로 실행시간에 패닉을 일으킬 것입니다. 이것이 `RefCell`이 그렇게 동작하는 이유입니다: 이것은 러스트의 빌림 규칙을 실행시간에 강제하며, 만약 어길 시에는 `panic!`을 불러옵니다. 이것은 러스트의 가변성 규칙의 또다른 면에 대해 생각해보게 합니다. 우선 이것에 대해 이야기해 봅시다.

## 필드 단위 가변성(Field-level mutability)

가변성은 빌림(`&mut`)과 바인딩(`let mut`)에 대한 특성입니다. 이것이 의미하는 바는, 예를 들자면, 어떤 [`struct`][struct]에 대해 어떤 필드(field)는 변경 가능(mutable)하고 어떤 것은 불변(immutable)하게 만들 수 없다는 것입니다.


```rust,ignore
struct Point {
x: i32,
mut y: i32, // nope
}
```

The mutability of a struct is in its binding구조체의 가변성은 그것의 바인딩에 의해 좌우됩니다:

```rust,ignore
struct Point {
x: i32,
y: i32,
}

let mut a = Point { x: 5, y: 6 };

a.x = 10;

let b = Point { x: 5, y: 6};

b.x = 10; // error: cannot assign to immutable field `b.x`
```

[struct]: structs.html

However, by using `Cell`, you can emulate field-level mutability그러나, `Cell`을 사용해서, 우리는 필드 단위 가변성을 흉내낼 수 있습니다:

```
use std::cell::Cell;

struct Point {
x: i32,
y: Cell,
}

let point = Point { x: 5, y: Cell::new(6) };

point.y.set(7);

println!("y: {:?}", point.y);
```

This will print `y: Cell { value: 7 }`. We’ve successfully updated `y`.이것은 `y: Cell { value: 7 }`을 출력합니다. 성공적으로 `y`를 갱신하였죠?