From 61b837db933d734c0c74ba3b400a35907e48c3df Mon Sep 17 00:00:00 2001 From: nomicon-kr Date: Sat, 22 Jun 2024 07:04:11 +0900 Subject: [PATCH] Update safe-unsafe-meaning.md --- src/safe-unsafe-meaning.md | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/src/safe-unsafe-meaning.md b/src/safe-unsafe-meaning.md index ff58f0d..8f54fee 100644 --- a/src/safe-unsafe-meaning.md +++ b/src/safe-unsafe-meaning.md @@ -59,14 +59,11 @@ _함수들_ 과 _트레잇 정의들_ 에서 확인되지 않은 계약들의 그 차이는 범위의 차이입니다. `BTreeMap` 이 정수들과 슬라이스들에 의존할 때, 그건 매우 특정한 구현에 의존하는 것입니다. 이것은 이득을 생각할 때 넘겨 버릴 수 있는, 일정한 부담입니다. 이 경우에서는 비용이 없다고 할 수 있습니다; 만약 정수들과 슬라이스들이 오류가 있다면, *모두가* 오류가 있는 거니까요. 게다가 그것들은 `BTreeMap` 을 관리하는 사람들의 손에 관리되기 때문에, 그 구현들을 지켜보기 쉽죠. -반면에 `BTreeMap` 의 키 타입은 제네릭입니다. - -On the other hand, `BTreeMap`'s key type is generic. Trusting its `Ord` implementation -means trusting every `Ord` implementation in the past, present, and future. -Here the risk is high: someone somewhere is going to make a mistake and mess up -their `Ord` implementation, or even just straight up lie about providing a total -ordering because "it seems to work". When that happens, `BTreeMap` needs to be -prepared. +반면에 `BTreeMap` 의 키 타입은 제네릭입니다. 그 `Ord` 구현을 믿는 것은 과거, 현재, 미래의 모든 `Ord` 구현을 믿는 것과 같습니다. +여기서의 비용은 큽니다: 어디서 누군가는 실수를 해서 본인의 `Ord` 구현을 망치거나, 심지어는 "그냥 되는 것처럼 보여서" 완전한 순서를 가지는 것처럼 거짓말을 할 수도 있습니다. +그런 일이 벌어질 때 `BTreeMap` 은 대비해야 합니다. + + The same logic applies to trusting a closure that's passed to you to behave correctly.