Valen, Rust의 빌림 검사보다 유연한 메모리 안전성 공개
Valen's Memory Safety: A New Kind of Borrow Checking
Valen이 그룹 빌림(Group Borrowing)을 도입해 기존 빌림 검사기의 제약을 완화했다. 컴파일러가 참조가 가리키는 경로를 기억해 use-after-free만 정밀하게 차단하므로, 하나의 객체를 가리키는 여러 읽기-쓰기 참조를 허용한다. Rust의 shared-xor-mutable 규칙을 'no use-after-free'로 완화한 셈이다. Carbon, Ante 등 여러 언어가 이미 이 접근을 채택했으며, Valen은 Rust 코드와의 상호운용까지 지원한다.
그룹 빌림은 실제로 이 갈등을 해결한다. 'shared-xor-mutable'을 'no use-after-free'로 완화함으로써.
HN 토론
65- kvark
내게는 "그룹" 빌림보다는 "경로" 빌림처럼 들리지만, 아이디어는 훌륭하다! 꽤나 눈이 트이는구나!
사소한 점 하나는, 하위 빌림에 왜 "in" 키워드가 있어야 하는지 잘 모르겠다. "entity in world.entities[]" 대신 "entity &world.entities[?]"로 보는 게 더 일관되지 않을까? 그러면 일관되게 빌림 "&" 기호를 얻게 되고, 어떤 인덱스(범위)가 영향을 받는지에 대한 계약을 열 수 있을 텐데.
- zamalek
> 빌림 검사에는 "공유-xor-가변" 제약이 있다: 객체에 대한 참조를 가지고 있으면, 다른 누구도 그 객체를 변경할 수 없다.
이 글은 이것을 문제인 것처럼 만든다. 그렇지 않다. 이 제약은 동시성 코드에서 특정 부류의 버그에 대해 생각하지 않아도 되게 해준다; 바로 여기서 "두려움 없는 동시성"이 나온다. R^w는 수명에 관한 것이 아니다 - 정신적으로는(실제로는 확실치 않지만) use-after-free에 전혀 영향을 주지 않고 Rust에서 제거할 수 있다.
물론, 이는 완전히 유효한 많은 프로그램을 작성할 수 없다는 뜻이고, 그래서 더 나은 해결책이 있기를 바라지만, 제거하는 것은 해결책이 아니다.
그것에 대해 생각해야 하고(그리고 잠재적으로 버그를 도입할 수 있다) 싶다면, 그것은 완벽히 괜찮다. r^w를 요구하지 않는 유연성은 극히 유용하다. 나는 단지 이 잘못된 귀속을 바로잡고 있는 것뿐이다.
- SleepyMyroslav
이것은 코드가 시스템의 모든 경로에 대한 정적 지식을 가진 코드 주도 시스템에 멋져 보인다. 렌더링 유형이 코드 주도인 렌더링 같은 것에는 확실히 더 나을 수 있다. 예를 들어 당신의 월드에는 스카이박스 같은 것이 있을 수 있다. 하지만 게임 개발의 '월드'와 '엔티티'를 가정한 예시들은 완전히 오해를 부른다. 왜냐하면 모두가 데이터 주도 월드로 넘어갔다고 생각하기 때문이다. 코드 예시의 엔티티 'advance'를 '엔티티 블루프린트 실행'으로 생각해라.
- melodyogonna
Mojo의 origin은 이러한 의미론의 많은 부분을 표현할 수 있다. Nick의 제안에서 많은 것을 배웠다고 생각한다, 직접 구현되지는 않았더라도. 다음은 두 참조가 같은 리스트를 업데이트할 수 있는 첫 번째 스니펫을 표현하는 방법의 예시다: https://godbolt.org/z/78bhzWjYM
- verdagon
또한, 이 글을 쓰면서 몇 가지가 떠올랐다:
* `entities in world.entities[]` 대신 함수 매개변수 구문 `entities: &world.entities[]`를 사용할 _수도_ 있다.
* "그룹"은 이 아이디어를 이해하는 데 그다지 중심적이지 않으므로, Group Borrowing보다 Path Borrowing이 더 나은 이름일 수 있다.
의견 환영합니다 =)