Lifetime 은 왜 존재하나

Borrowing 트랙은 약속으로 끝났어: 컴파일러가 각 참조가 얼마나 오래 유효한지 추적하고, 그 추적을 lifetime 이라 부른다고. 이 트랙은 Rust 에서 제일 무서워 보이는 문법의 안개를 걷어 — 그리고 그게 대부분 안 보인다는 걸 보여줘.

lifetime 은 지속시간이 아니야

먼저 틀린 직관을 죽이자: lifetime 은 '값이 몇 밀리초 사는가' 가 아니야. 참조가 유효한 컴파일 타임 코드 영역 이야. 컴파일러는 이 영역들을 추론해서 어떤 참조도 drop 된 데이터를 가리키지 않게 보장해. 뭘 재는 게 아니라, 스코프 간 관계를 서술하는 거야.

대부분의 lifetime 은 추론돼

여기 안도감이 있어: 거의 대부분 lifetime 표기를 0 개 써. 너 이미 `'a` 하나 안 보이게 참조 받는 함수들을 썼잖아. 표기는 컴파일러가 혼자선 관계를 정말 못 알아낼 때만 나타나.

lifetime 은 지속시간이 아니라 관계를 서술해. 'a 같은 표기는 뭐가 얼마나 오래 사는지 안 바꿔 — 어떤 참조가 어떤 것만큼 오래 유효해야 하는지를 서술해. 컴파일러가 못 추론한 사실을 주는 거야, 그뿐이야.

언제 표기해야 하나

전형적 경우: 함수가 참조 둘을 받아 하나를 반환해. 출력은 어느 입력에서 빌려? 컴파일러가 항상 알진 못해서, 말해달라고 해. 그 시나리오 하나가 lifetime 문법 대부분이 나오는 곳이야 — 다음 두 레슨의 초점이고.

Code

쓸 필요 없던 lifetime·rust

// lifetime 표기 불필요 — 컴파일러가 추론:
fn first_line(text: &str) -> &str {
    text.lines().next().unwrap_or("")
}

fn main() {
    let doc = String::from("first line\nsecond line");
    let line = first_line(&doc);
    println!("{line}");
    // 컴파일러가 이미 `line` 이 `doc` 보다 오래 못 산다고 증명함.
    // 너는 'a 를 안 썼어 — elision 이 처리함.
}

Exercise

&str 하나를 받아 그것의 &str 슬라이스를 반환하는 함수를 써봐 (예: 첫 글자 이후 전부). lifetime 표기가 0 개 필요한 걸 봐. 그다음 왜인지 말해봐: 입력 참조가 하나뿐일 때 출력은 명백히 뭐에서 빌려?

Hint

입력 lifetime 이 하나면 모호함이 없어 — 출력은 그 하나에서만 빌릴 수 있으니 컴파일러가 추론해. 모호함 (그리고 표기) 은 입력 참조가 여럿일 때만 생겨.

Lifetime 은 왜 존재하나

lifetime 은 지속시간이 아니야

대부분의 lifetime 은 추론돼

언제 표기해야 하나

Code

External links

Exercise

Progress

댓글 0