Rust: 변경 가능한 지역 주민만을 위한 var 키워드

고백해야 합니다. 처음에는 가변 변수와 가변 필드에 같은 키워드를 사용해야 한다고 생각했지만 var 는 꽤 잘 읽힙니다( let mut 좋아하지는 않지만).

가변 변수를 선언하는 것이 불변 변수보다 조금 더 번거로운 기능이라고 생각합니다. 프로그래머가 "일관성"을 유지하기 위해 또는 "var"가 더 강력하기 때문에 "var"만 사용하는 것을 볼 수 있습니다(나중에 변경하기로 결정한 경우 변경할 필요가 없음). 그러면 전반적으로 덜 읽기 쉬운 코드가 됩니다.

Rust가 심각한 속박 및 규율 언어가 되어야 한다고 제안하는 것은 아니지만 올바른 방향으로 부드럽게 넛지를 하는 것이 도덕적으로 정당하다고 생각합니다. 더 쉽게 엉망이 되는 구조").

한편으로는 이 형식에서 시각적 모호성을 제거하기 때문에 이것을 좋아합니다.

let mut x = 4,
    y = 8;  // is y mutable or not?

그러나 나는 실반의 편에 서려는 경향이 있습니다. 가변 객체를 선언하는 것이 꼭 _못생긴_일 필요는 없지만, 단 한 번의 키 입력만으로 불변 객체보다 생성하기가 조금 덜 편리하다면 의미가 있다고 생각합니다. 활성화 키워드도 고유해야 하며 (IMO) var 는 기본적으로 불변성을 자랑하는 언어에서 특히 가변성을 전달하기 위해 일반 변수 선언 키워드로 너무 널리 사용됩니다. 그리고 var 가 우리의 let 불쌍한 C# 프로그래머를 생각해 보십시오!

위의 코드 조각을 처리하기 위해 let mut 를 단일 키워드로 바꾸는 아이디어가 여전히 마음에 들지만 mut 자체로 충분할 때 새 키워드를 도입할 이유가 있습니까? #1273의 원래 제안?

@pcwalton 은 mut 사용하는 것의 문제를 지적했습니다. 레코드 리터럴 및 블록 표현식에 모호성이 있어 해결하기 위해 임의의 미리보기가 필요합니다.

{ mut x: int ...

리터럴을 기록하거나 지역 변수를 사용하여 차단하시겠습니까?

var 가 Rust에서 변수를 선언하는 방법이고 let 를 전혀 사용하지 않는다는 것을 배우는 많은 프로그래머를 볼 수 있었습니다. 결국 var 는 JavaScript와 같은 언어에서 지역 변수를 선언하는 방법입니다. 나는 이것이 이 제안의 좋은 점이라고 생각하는 경향이 있습니다.

어제 누군가가 지금 let 와 var 길이가 같아 정렬에 좋을 것이라고 지적하는 것을 우연히 들었습니다.

나는 다소 무관심하지만 더 짧기 때문에 var 선호합니다. 가변성을 성가시게 만드는 것은 내가 보기에 바람직한 목표가 아닙니다. (사실, 나는 프로그래밍 언어의 역할이 짜증나는 일을 해서는 안 된다고 생각하는 경향이 있습니다. 똑같은 것이 아닌 _명확한_ 일뿐입니다.)

let 와 var 함께 사용하는 것이 여전히 조심스럽긴 하지만(Javascript와 같지만 100% 다름) 변수를 감지하는 린트 패스가 있으면 문제가 훨씬 덜할 것입니다. 변경 가능한 것으로 선언되었지만 실제로는 변경되지 않았습니다.

가변성을 유형의 일부로 만들 계획이 있습니다. 그것이 지역 주민들에게 영향을 미치고 이것이 관련이 없게 만드는가?

어때요:

val x = ... // immutable (val-ue)
var y = ... // mutable (var-iable)

스칼라에서처럼.

@brson 이 옳다고 생각 mut 를 유형으로 이동하면 이 문제가 사라집니다. 즉, let x = mut 10; 를 얻습니다.

지금은 이 문제를 닫습니다. 내가 틀렸다고 생각하면 다시 열어!

나는 이것에 대해 확신하지 못한다. 나는 mut을 유형으로 옮기는 아이디어를 좋아하지만 그것이 "완료된 거래"인지는 모릅니다. 어쨌든, 나는 let x = mut 5 쓸 수 있다고 생각한 적이 없었습니다. 저는 항상 오늘처럼 let mut x = 5 쓸 것이라고 가정했습니다. 변수 유형의 "가변성"은 할당된 값이 아니라 선언된 방식에서 비롯됩니다.

그렇지 않으면 [mut int] 유형의 배열 x 이 있고 let y = x[0] 하면 y 가 변경 가능하다는 것을 의미하는 것 같습니다. 또는 뭔가? 바람직하지 않은 것 같습니다.

@Dretch 스칼라 선례는 좋지만 충분히 구별되지 않기 때문에 val/var를 좋아하지 않습니다.

기본적으로 var 를 사용하는 방법을 배우는 사람들에 대한 @eholk 의 우려를 공유합니다. 지금 작동하는 방식은 모든 것을 불변으로 선언하는 경향이 있습니다. 그런 다음 컴파일러는 변경 가능해야 함을 상기시킨 다음 mut 합니다. 이것은 var/let 분할을 사용하는 경향이 덜한 좋은 행동입니다. var 및 let 것은 똑같이 어렵지만 let mut 입력할 수도 없습니다. let let mut 를 입력하지 않고 let .

그러나 나는 선호하는 것이 없으며 세 글자 키워드로 시작하는 명령문의 기능을 완전히 구성할 수 있다는 점에 감사합니다.

@nikomatsakis 특히, 단일 할당에 대한 규칙은 유형이 아니라 선언의 가변성에서 비롯되어야 한다는 것이 나에게 이해가 됩니다. 미묘하게 할당 규칙을 기반으로 변경하는 것은 나에게 재미있는 냄새가납니다.

나는 프로그래머가 원하는 경우 가변 바인딩을 사용하는 것에 대해 불이익 을 안된다는 @pcwalton의 의견에 동의합니다. var 불필요하게 사용하는 사람들에 대한 우려에 관해서는 var 바인딩이 단일 할당된 경우 불평하는 선택적 경고를 추가할 수 있습니다. 그러나 또한 Rustc와 표준 라이브러리에서 좋은 스타일의 선례를 세울 수 있다고 생각합니다.

데이브

프로그래머가 모든 변수를 변경 가능하다고 선언하면 정말 끔찍합니까? var 가 변수를 선언하는 방식이라고 생각하는 Rust 프로그래머 세트와 대부분의 시간에 let 를 사용하는 것을 이해하는 다른 세트가 있다면 세상의 끝이 아닌 것 같습니다 var 필요할 때 var . 최초의 Rust 프로그래머로서, 우리는 let 와 var 올바르게 사용하도록 선례를 정할 수 있습니다.

IMHO의 좋은 구문 디자인은 당신이 하고 싶은 "모든 것"을 편리하게 만드는 것이 아니라 언어의 의미와 디자인 목표의 "원활한 경로"로 사람들을 부드럽게 밀어 넣는 것입니다.

예를 들어, Rust의 기본 원칙 중 하나는 효율적이어야 하기 때문에 연결 목록에 대한 특별한 구문 지원을 추가하지 않을 것입니다. 같은 이유로 스레드 간에 변경 가능한 데이터를 공유하는 것은 너무 편리하지 않아야 하고(안전한 동시성이 또 다른 원칙이기 때문에), 임의의 int를 포인터로 캐스팅하는 것도 매우 편리해서는 안 됩니다(메모리 안전이 큰 원칙이기 때문에).

이러한 일을 하는 것이 불가능해야 한다는 것은 말할 것도 없고, 단지 비례적으로 불편할 뿐이므로 Rust를 작성하는 관용적 방법인 구문에서 명확하게 알 수 있습니다.

변경 가능한 (로컬) 변수는 이들 중 어느 것만큼 나쁘지 않지만, 만약 Rust가 정확성과 유지 관리를 위해 변경 불가능한 데이터를 선호한다면(제가 개인적으로 동의하는 것입니다), 구문은 이상적으로 그 방향으로 부드럽게 움직여야 합니다. 하나의 추가 문자나 추가 수식 기호 또는 "let"이 "let mut" 또는 "let!"보다 덜 복잡하다는 것을 분명히 하기에 충분할 것입니다. 또는 무엇이든, 따라서 실제로 변수를 변경할 필요가 없을 때 시도해야 하는 기본 기본값이어야 합니다.

@ssylvan 오, 나는 그 점을 이해합니다. 그것은 단지 정도의 문제이고 절충안의 균형입니다. 우리는 이미 데이터 구조의 불변성을 장려하고 있으며 IMO 불변 로컬은 불변 필드보다 홍보하는 것이 덜 중요합니다. (특히 IINM 이후로, 우리는 힙 클로저에서 변경 가능한 로컬이 이스케이프하는 것을 허용하지 않습니다.) 그리고 열 수를 변경하지 않고 let 와 var 사이를 리팩토링하는 기능의 손실은 이점보다 큽니다. 불변의 지역 주민을 홍보합니다. 수치화하기 어려우니 제 느낌일 뿐입니다.

데이브

이 경우 "let mut foo = bar"와 반대로 "let foo = mut bar" 또는 "let foo := bar"가 첫 번째 토큰을 정렬합니다. 아마도 변수 이름은 가변 길이일 것이므로 문의 나머지 부분에서 추가 수정자를 피하는 것은 그다지 중요하지 않습니다.

오, 저는 := 아이디어에 다소 동의합니다.

데이브

다시 생각해보면, 파스칼은 영구적으로 멋지지 않습니다. 나는 그것을 다시 가져. :)

데이브

또한 let foo := bar 는 다음과 같은 것을 방지합니다.

let mut foo;
foo = bar;

같은 패턴을 작성하는 다른 방법이 항상 있는 것처럼 보이지만 이 패턴이 때때로 유용하다는 것을 알았습니다.

@eholk 나는 그것이 그것을 방지한다고 생각하지 않습니다. 그러나 나는 여전히 거의 모든 주류 언어의 프로그래머들에게 그것이 너무 이상하게 보일 것이라고 생각합니다.

데이브

:= 와 관련하여 Go는 이를 사용하여 유형 추론 할당을 나타냅니다(아직 주류 언어는 아니지만). 그러나 한 눈에 두 형식을 구별하는 데 어려움이 있음을 알 수 있습니다.

let foo = "hello";
let foo := "hell";

현재 구문에 대한 brson의 주장(즉, 가변 선언이 먼저 불변 선언을 필요로 함)은 설득력이 있습니다. 프로그래밍 언어가 독단적이라면, 그것에 대해 바보가 아닌 한 완전히 좋습니다. :)

= 대 := . 대부분 val , var 및 그 변형에 반대합니다. 변경 가능성을 제어한다는 것은 _명백한_ 것이 아닙니다. 내 말은, 나는 우리가 그들 중 하나를 채택하면 혐오감을 그만두지 않을 것이지만, "니모닉을 설명할 필요가 있다"는 것은 나쁜 징조라고 생각합니다. 나는 더 괜찮다:

• 유형이 지시하도록 합니다.
• mut 단독으로 로컬 선언자로 작동하도록 하고 파서가 레코드 구문 대 로컬 선언에 대한 커밋을 지연하도록 요구합니다. 여전히 LL(1)은 추가 중간 문법 상태를 추가하고 추가 역추적은 없습니다(앞으로 두 가지 방법 모두 유효함).
• let mut .

"우연한" 변경 가능한 로컬을 피하는 주된 이유는 환경 캡처를 도입하여 차용과 같은 다양한 분석에 대한 위험뿐만 아니라 원거리 행동의 형태로 변하기 때문입니다.

(모든 let은 처음에는 변경 가능했지만 환경 캡처도 없었고 바인딩만 했습니다. 이제 바인딩이 없고 env 캡처만 있습니다. Tomayto, tomahto.)

나는 mutables가 지금 암시적으로 캡처될 수 없다고 믿습니다.

@graydon 은 두 가지 원래 동기가

• fn@ 에서 변경 가능한 변수의 암시적 "복사본" 캡처
• 어떤 데이터가 변경 가능하고 어떤 데이터가 변경되지 않는지 이해

후자는 더 이상 관련이 없다는 것이 밝혀졌습니다. 변경 가능/불변 변수의 사용은 실제로 너무 조잡했기 때문에 차용은 변수를 "일시적으로" 차용한다는 아이디어를 가지고 있습니다. 포인터가 있는 동안 변수가 수정되지 않는 한 가변 변수는 불변 ptr로 차용될 수 있습니다. 범위.

변경 가능/불변 로컬이라는 개념을 제거하고 이전 규칙으로 돌아갈 수 있습니다. 모든 것이 변경 가능합니다. 그런 다음 클로저에 암시적으로 복사된 변수가 클로저가 생성된 후 수정될 때 경고를 발행할 수 있습니다.

세 번째 동기가 있습니다. 변경할 수 없는 변수가 더 쉽게 추론할 수 있습니다. 모든 것이 변경 가능한 경우 전체 함수를 검색하여 변수가 수명 동안 어떤 값을 가질 수 있는지 확인해야 합니다. 모든 변수는 잠재적으로 복잡한 데이터 흐름(특히 루프, 분기, 변경 가능한 함수 매개변수 등)을 가지고 있으며 모든 명령문을 주의 깊게 분석하지 않고는 무슨 일이 일어나고 있는지 확인하기 어렵습니다. 함수에 변경 가능한 변수가 하나 또는 두 개만 있는 경우 헴과 관련된 코드를 읽을 때 더 주의할 수 있도록 일종의 "플래그" 역할을 합니다.

@Dretch 또한 "val" 및 "var" 키워드가 있는 Scala 스타일을 좋아합니다.

나는 현재 구문이 어떻게 mutables가 아픈 엄지손가락처럼 튀어나오게 만드는지를 좋아합니다. 코드를 더 쉽게 스캔할 수 있습니다. val 및 var 는 그런 면에서 시각적으로 너무 유사해 보입니다. 변경 가능한 항목이 절대적으로 _반드시_ 튀어나와야 한다는 말은 아니지만 키워드를 시각적으로 뚜렷하게 유지하는 것은 사용성의 중요한 측면입니다.

변경 가능한 필드가 녹에서 제거될 것임을 이해합니다. 그러면 let mut 대신 mut 사용할 수 있다는 의미입니까? 레코드/블록 내 변수 모호성이 사라지기 때문입니까?

또한 변경 가능한 필드가 남아 있어도 모호성을 제거하는 구조적 레코드가 진행 중이라고 생각합니다.

@Dretch 변경 가능한 필드가 사라지고 있고 구조적 레코드가 이미 사라진 것이 사실입니다.

동결/해동의 경우 mut 가 자체적으로 선언 키워드(Dretch가 제안한 대로)가 되는 것이 _가능성이 있음을 지적하고 싶습니다. . 오늘 비교:

let foo = 1;  // immutable
/* 10,000 lines of code here */
let mut foo = foo;  // we're making foo mutable, totally understandable
/* 10,000 lines of code here */
let foo = foo;  // potential wtf

제안:

let foo = 1;  // immutable
/* 10,000 lines of code here */
mut foo = foo;  // a mutable foo, no problems here
/* 10,000 lines of code here */
let foo = foo;  // slightly less of a potential for wtf, since we officially have two declaration forms

나는 또한 녹주의 할 것 같은 느낌이 있지만 우리는 여전히 기록 할 것 때문에 덜 일관 "피 시험 메모리의 부재는 불변성을 의미한다" let foo = 1; 오히려보다는 다만 foo = 1; (후자의 형태는 분명히 선언에 바람직하지 않음).

Kotlin 은 val 및 var 합니다.

나는 우리가 이 변경을 할 것이라고 생각하지 않지만, 잘 정의된 이정표 1을 지명하여 해결할 수 있도록 하겠습니다.

mut을 패턴 바인딩으로 이동하는 것과 호환되지 않기 때문에 이 작업을 수행하지 않는 것이 합의입니다. 폐쇄.