아마도 a..b| 또는 a..b]

나는 이것이 단순한 오타(.. vs ...) 때문에 미래에 예측할 수 없는 새로운 종류의 오류에 대한 길을 열 것이라고 생각합니다. ....(4 기간)이면 더 좋습니다. 이렇게 하면 인적 요소에 오류가 발생하기 쉽습니다.

https://github.com/rust-lang/rfcs/pull/1592 및 https://github.com/rust-lang/rfcs/pull/1582를 결합하여 ..= 대신 구문. 누군가가 더 큰 튜플 앞에 있는 튜플을 확장하기 위해 (head..., tail) 보다 더 나은 구문을 생각할 수 없다면.

나는 배타적 범위를 사용하려고 할 때 내 코드에 _off-by-one- dot _ 오류가 있었기 때문에 이 문제를 발견했습니다.

👎 ... 구문. 하나씩 오류를 일으키는 잘못 입력하기 쉬운 구문을 갖는 것은 총알이 될 것이라고 생각합니다.

이 기능은 유용하므로 ..= 와 같이 다른 구문으로 사용할 수 있습니다.

이에 대한 구문은 공개 질문입니까? ... 이 이미 match 문에 있으므로 배가 항해했다고 가정했습니다.

개인적으로 ... 포함 범위를 선호하지만 이미 .. 독점 버전이 있으므로 문제의 가능성이 있습니다. #23635를 본 후에는 .. 더 이상 사용하지 않고 ... 만 허용하고 싶습니다.

저는 C와 같은 for 루프 for i in 0..foo.len() 에 완벽하게 맞는 경우 포괄적인 범위를 많이 사용하므로 그대로 두는 것이 좋습니다(Rust의 반복자는 "1차원"이고 종종 2D 배열 또는 비선형 반복과 함께 사용하기에는 너무 어색함).

포괄적인 범위에 대한 오버플로 문제는 어리석은 것처럼 보이지만 실제로는 Rust가 usize 이외의 다른 유형과 함께 사용하는 것이 짜증나기 때문에 실제로는 이 문제에 부딪힌 적이 없습니다. for i in 0..(len as usize) 범위를 생성할 때 캐스트하지 않았다면 어쨌든 루프 내에서 i as usize 6번을 사용해야 합니다.

이 구문은 여전히 ​​기능이 제한되어 있으므로 배가 항해하지 않았으면 합니다.

swift가 포함에 ... 를 사용하고 독점 범위에 ..< 를 사용한다는 점을 고려하면 포함에 ..= 를 사용하는 것이 꽤 합리적으로 보입니다.

유용한 통찰력이 없지만 포괄적인 범위에서 "실험적" 상태를 종료하고 싶습니다. Rust By Example을 진행하면서 다음과 같은 이점을 얻을 수 있는 스니펫을 찾았습니다.

fn fizzbuzz_to(n: u32) {
    for n in 1..n + 1 {
        fizzbuzz(n);
    }
}

위로 ? 😄

a ..= b 구문 및 일반화된 범위에 대한 RFC를 작성하고 싶습니다. 표준 라이브러리에서 이러한 범위가 표현되는 방식에 대해 논의 하기 위해

IMHO ..= 이상해 보입니다. 저는 ... 및 ..<에 대한 Swift의 접근 방식이 더 좋아 보입니다. 저는 두 개의 점보다 줄임표를 선호하기 때문입니다. 줄임표는 생략을 나타내며 범위의 시작과 끝 사이의 숫자를 생략합니다.

나는 여전히 ... 그리고 .. 충분히 좋았다고 생각합니다. 1개의 문자 차이가 있으므로 +/- 또는 x/y 또는 그 밖의 것보다 실수를 하기가 더 어렵습니다.

이전에 내가 이것을 잘못 이해했기 때문에(그래서 내 의견을 삭제했습니다):

Rust의 RFC 프로세스에 따라 이 제안은 RFC pull request 1192 에서 이미 검토, 논의 및 승인되었습니다. 이번 호에서는 이전에 결정된 사항의 ​​구현을 추적합니다. 토론에서는 사람들이 여기에서 제기하는 많은 요점을 다뤘습니다: 대체 구문(새 구문 없음 포함), Ruby의 유사한 연산자와의 대조 등.

기능이 달라야 한다고 강하게 느낀다면 동일한 RFC 프로세스를 거쳐야 한다고 생각합니다. 그래야 언어가 변경되기 때문입니다. 그러나 이 문제는 그럴 문제가 아닙니다.

@jimblandy 어쩌면 우리는 @nikomatsakis가 그 정중한 알림과 지침을 진정한 빅 프린트의 첫 번째 댓글로 편집하도록 해야 할 것입니다. 😇

@shepmaster _모든_ 추적 문제를 제출하는 데 사용되는 템플릿에 추가하는 것이 좋을 것입니다.

토론/가능한 FCP 지명

@rust-lang/lang 회의에서 이에 대해 논의했습니다. 이 기능에 대한 전반적인 불만이 있었습니다. 우리는 더 이상 사용하지 않기로 결정했지만 당분간 보류하기로 결정했습니다. ... 대한 두 가지 주요 반대 의견이 있습니다.

• .. 와 ... 사이의 혼동 용이성 ;
• @aturon 은 "완전히 가능한" 범위 구문을 갖는 것이 더 낫다고 생각했습니다. 이것은 btree 반복 등과 같은 API에서도 사용할 수 있습니다.

이를 위해 우리는 사람들이 하한 및 상한이 포괄적인지 배타적인지를 정확하게 지정할 수 있도록 하는 더 일반적인 구문을 가능하게 하는 RFC를 기꺼이 추진할 사람이 있는지 궁금했습니다. 나는 @aturon 이 그러한 RFC에서 누군가와 함께 일하게 되어

나는 잠시 멈췄다는 것을 알고 있지만 최근에 libstd에서 완전한 기능을 갖춘 범위를 표현하는 방법에 대한 토론 스레드( 위에 링크됨)를 열었지만 아무도 언급하지 않았습니다.(

위의 정보를 바탕으로 새로운 RFC를 기꺼이 도와드리겠습니다.

나는 최근에 libstd(위에 링크됨)에서 완전한 범위를 표현하는 방법에 대한 토론 스레드를 열었지만 아무도 언급하지 않았습니다.

그것은 어느 정도 그들의 유용성을 반영합니다.
임의의 포괄적-배타적 범위를 갖는 것은 좋은 생각처럼 들리지만 .. 와 훨씬 적은 수준으로 ... 를 제외한 모든 것은 절대 사용되지 않을 것이라고 확신합니다.

@durka

나는 잠시 멈췄다는 것을 알고 있지만 libstd(위 링크)에서 완전한 기능 범위를 표현하는 방법에 대한 토론 스레드를 열었지만 아무도 언급하지 않았습니다.(

이것은 대략 우리가 염두에 둔 접근 방식과 비슷합니다.

@petrochenkov

임의의 포괄적-배타적 범위를 갖는 것은 좋은 생각처럼 들리지만 ..를 제외한 모든 것이 .. 그리고 훨씬 적은 ... 정도는 절대 사용되지 않을 것이라고 확신합니다.

솔직히 말해서 동의하지만, 여전히 더 일반적인 구문을 추구할 가치가 있다고 생각합니다. 특히 ... 는 차선책이라고 생각하지만 ..= 또는 더 명시적인 것으로 이동하면 드물게 발생하더라도 좀 더 일반적인 것을 하는 것이 실제로 나쁠 것은 없을 것입니다. 사용 된. 즉, 체계적으로 하면 배우기가 훨씬 어려워 보이지 않고, .. 인지 ... "더 많은 수"를 의미하는지 혼동이 없을 것입니다. ".

이것은 대략 우리가 염두에 둔 접근 방식과 비슷합니다.

어느 것? 내 게시물에서 몇 가지 대안을 제안했습니다.

나는 종종 포괄적 인 범위를 반복하고 싶지 정말 입력 좋아 0...x 대신 0..(x + 1) . 나는 이것이 하나씩 오류를 일으킬 수 있다는 것을 이해하지만 어떤 대안이 있습니까?

Rust의 구문을 부작용 없이 자유롭게 변경할 수 있다고 가정하면 몇 가지 명백한 패턴만 보입니다.

있는 그대로 받아들이고

1..4 // 1, 2, 3
1...4 // 1, 2, 3, 4

이는 괜찮은 솔루션 IMHO이며 패턴 일치에도 사용됩니다.

수학에서 빌리다

[1, 4] // 1, 2, 3, 4
[1, 4[ // 1, 2, 3
]1, 4] // 2, 3, 4
]1, 4[ // 2, 3

이것은 가장 완전한 구문이지만 같은 양의 여는 중괄호 규칙을 깨고 시각적으로 구문 분석하기 더 어렵습니다.

파이썬에서 차용

1:1:=5 // 1, 2, 3, 4, 5
1:1:<5 // 1, 2, 3, 4

이는 알려진 패턴이며 계단 크기를 통합할 수도 있습니다. RFC 프로세스가 어떻게 작동하는지 모르지만 범위에 대해 이야기할 때 단계 크기도 고려해야 한다고 생각합니다.

단계 크기가 이 논의의 일부가 아닌 경우(또는 미래의 것) ..= 및 ..< 가 매우 합리적으로 보입니다!

업데이트: ..= 및 ..< 가 정말 좋은 솔루션이라고 생각합니다. 단계 크기를 어댑터로 유지하는 것이 훨씬 더 합리적입니다.

이 토론에 내림차순 범위가 포함되어야 합니까? 범위를 반전시키는 현재 솔루션은 매우 혼란스럽습니다(그러나 포괄적인 범위가 있는 경우에는 그렇지 않을 수 있음).

예를 들어 눈을 가늘게 뜨지 않고도 이것을 읽고 이해할 수 있습니까?

for i in (1..l.len()).rev() { ... }

편집: 그리고 GitHub의 글꼴을 사용하면 l 가 1 처럼 보이기 때문에 훨씬 더 혼란스럽습니다.

네거티브 스텝사이즈로 충분하다고 생각합니다.

Matlab 구문 a:b 및 a:step:b 있습니다.

2016년 11월 4일 00시 50분에 "Ott" [email protected]이 작성했습니다.

네거티브 스텝사이즈로 충분하다고 생각합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment -258344460,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAC3n3kwnGH6POQb4dGwCwJ8yOGqPSBQks5q6rmDgaJpZM4F4LbW
.

@durka 그렇다면 a 또는 b 가 없는 현재 .. 와 동등한 것은 무엇입니까? 그냥 : ?

내가 보지 못한 것이 RFC에 기록되어 있습니다. 필드에 대해 다른 이름이 고려되었습니까?

다른 유형이 있는 경우 의미가 다를 때 다른 필드 이름을 갖는 것이 유용할 수 있습니다. 예를 들어 "range.start"는 모든 유형에서 "하한 포함"입니다. 그러나 "range.end"는 때로는 포괄적이고 때로는 배타적입니다. "끝"과 (strawman) "마지막"의 구별은 그것을 더 명확하게 합니다.

(물론 Range를 위해 다른 유형을 포기한 경우에는 관련이 없습니다.>...)

포괄적인 범위는 여전히 std::collections::range::RangeArgument를 구현해야 한다고 생각합니다.

pub trait RangeArgument<T> {
    fn start(&self) -> Option<&T> { ... }
    fn end(&self) -> Option<&T> { ... }
}

그 다음에

impl RangeArgument<T> for RangeToInclusive<T> {
   fn end(&self) {
     Some(self.end+1)
   }
}

따라서 fn foo<T, R: RangeArgument<T>>(arg: R) 는 포함 범위 또는 반개방 범위를 사용할 수 있습니다.

@durka a:b 구문의 문제는 유형 ascription이 모호하다는 것입니다. b 변수 또는 b 유형을 요구하고 있습니까? 분명히 훌륭한 Rust 프로그래머로서 우리는 유형을 대문자로 표시하지만 컴파일러는 이를 유추할 수 없습니다.

.. 수학 정의가 있는 연산자( @duesee 주석 기반):

[1..4] // 1, 2, 3, 4
[1..4[ // 1, 2, 3
]1..4] // 2, 3, 4
]1..4[ // 2, 3

사용( @0tt 예제 기반):

fn fizzbuzz_to(n: u32) {
    for n in [1..n + 1] {
        fizzbuzz(n);
    }
}

이 경우 .. 힌트로 사용하지만 경계는 [ 및 ]

@adelarsq : Rust에서는 시작을 포함하지 않는 범위가 필요하지 않습니다. 그러나 대괄호 구문은 허용되는 경우에만 의미가 있습니다. 또한 대괄호 구문이 이미 사용되었습니다.

나는 ..= 가 포괄적인 범위를 위한 가장 합리적인 선택이라고 생각합니다.
... 가 아닌 .. 와 시각적으로 쉽게 구별할 수 있습니다. 입력의 기회 ... 의미하는 경우 .. 하거나 그 반대의 경우도 마찬가지과 몰래는보다 높은 ..= .
(시각적 인지 가능성과 버그 가능성 모두에서 C에서 if(a == b) 대신 if(a = b) 를 실수로 입력하는 것과 비슷합니다).
그리고 ..= 는 그 의미를 상징하기 때문에 외우기 쉽습니다( i ..= j 는 i .. j 범위를 의미하고 여기서 i = j ).

주요 불만은 ... 가 .. 와 너무 유사하다는 것입니다. 더 많은 문자를 포함하는 다른 제안이 있을 때 아무도 문자 수에 대해 불평하지 않고 대괄호 일치 및 특정 장소에서의 사용과 같은 것에 대해서만 불평한다는 것을 알았습니다.
그렇다면 포함 범위의 경우 .... 는 어떻습니까? 그것은 여전히 ​​범위처럼 보일 것입니다. 그리고 내가 말했듯이 아무도 추가 문자가 필요한 솔루션을 신경 쓰지 않는 것 같습니다. ..= 보다 다소 불안정한지 여부는 논쟁의 여지가 있습니다.
for i in 0....10 { println!("just a thought"); }

기본 동작이 포함된 경우 ..! 연산자가 사용됩니다(거의 부정으로).

.... 의 문제는 ... 실제로 존재하는 경우 약간의 혼란이 있을 수 있다는 것입니다.

나는 ... 좋아하지 않습니다. 왜냐하면 Ruby 와 정확히 반대이기 때문입니다.

지금까지 가장 좋은 옵션은 ..= 입니다.

@adelarsq는 .... 운영자는 대체 할 것이다 ... 당신이하려고하면 그래서, 연산자를 .. 하고 별도의 추가 . , 그것은 것입니다 컴파일을 시간 오류, .... 를 시도하고 점을 잊어버리면 그것도 오류가 됩니다.

패턴 일치에서 ... 는 포함 범위와 일치하는 데 사용되므로 포함 범위 표현에도 ... 를 사용하는 것이 좋습니다.
단계가 있는 범위의 경우 Haskell 구문을 선호합니다(예: 1,3..9 => [1,3,5,7]).

스텝/리버스 등의 범위의 경우 복잡한 리터럴 대신 좋은 구식 함수(일종의 Range 생성자)를 선호합니다.

쿼드 도트 .... 도 괜찮습니다( ..= 도 IMHO 괜찮음). 일관성을 위해 패턴 일치에서도 허용될 수 있습니다(결국 패턴에서 ... 가 더 이상 사용되지 않을 수 있음).

나에게 ..= 는 .... 없는 시각적 의미입니다.

방금 뭔가를 발견했습니다.

수학에서 ∀ i: 0 ≤ i < 10 쓰면 다음과 같이 번역됩니다.

for i in 0 ..< 10 { }

이것은 일관성이 있습니다.

그러나 ∀ i: 0 ≤ i ≤ 10 은 다음과 같이 번역됩니다.

for i in 0 ..= 10 { }

여기서 ≤은 =로 번역되어 일관성이 없습니다.

이것은 자전거 세차장일 수 있지만,

for x in 0 ..<= 10 { }

더 맞는 느낌. 이것은 내 C 배경 때문일 수 있습니다.

for (unsigned int i = 0; i <= 10; ++i) { }

" i 가 10 보다 작거나 같으면 무언가를 하십시오"로 해석됩니다. CI에서는 루프 조건에서 == 를 사용하지 않는 것을 선호합니다. 값을 뛰어 넘고 무한 루프로 끝날 가능성이 있기 때문입니다. 이것은 Rust에서는 일어날 수 없는 일이지만 for i in 1 ..= 10 를 C로 번역하면 정확히 그것을 암시할 수 있습니다.

더 나아가서,

for i in 0 <..<= 10 { }

자명할 것입니다.

편집: 여기에 = 만 사용하는 것이 어떻게 혼란스러울 수 있는지 보여주기 위한 나쁜 역 예제가 있습니다. 건설적인 것보다 더 혼란스러워서 삭제했습니다.

@duesee >=..> 는 어떻게 자명합니까? <=..> (<= 10 and > 0) 이어야 하지 않습니까?
IMO는 설명이 필요 없으며 운영자로서 너무 길고 비밀스럽습니다.
(연산자는 IMO 3자 이상이어야 합니다).
Btw, 우리는 이미 역반복 방향을 표현하는 방법을 가지고 있습니다: .rev()
포괄적인 범위와 .step_by() 대한 연산자만 필요합니다.
단계의 경우 구문은 a .. b | s 수 있습니다(포함 범위의 경우: a ..= b | s ).

@norru : for i in (1..l.len()).rev() { ... } 예제는 대부분의 경우 슬라이스( for x in arr[1..].rev() { ... } )를 사용하므로 매우 비현실적이지만 인덱스 스타일의 반복을 사용해야 하는 경우에도(기본적으로만 i 없는 배열 요소를 수정할 때 읽기가 전혀 어렵지 않습니다. (그러나 나는 일반적으로 인수가 리터럴 숫자가 아닐 때 .. 주위에 공백을 둡니다: (1 .. arr.len()).rev() )

Rust 연산자에서 물고기의 >=..> 더 많은 종!

그러나 나는 좋아한다 ..<= 많은 (편집 : 으음,를 제외하고 match 가 보이는 곳 <= 0 => :()

• 일반 .. 와 매우 다릅니다.
• ..= 의 += 의미가 없습니다.
• Swift의 ..< 와도 논리적으로 일치합니다. 두 언어가 수렴하는 것이 가능합니다!
• 가장 중요한 것은 상위 숫자보다 작 거나 같은 범위에서 숫자를 얻는다는 점입니다.

@pornel : >=..> more species of fish in Rust operators! 헤헤 :-)

@Boscop : 수학의 정의처럼 읽으면 자명합니다. 10 >= i > 2 . 나머지 답변: 전적으로 동의합니다. 두 번째 부분은 향후 확장을 위해 차단기를 도입하지 않기 위해 ..= 대 ..<= 를 재고하도록 동기를 부여하기 위한 것입니다. 그에 따라 답변을 수정하겠습니다.

.. 표기법에 대한 경고 또는 오류 플래그를 얻을 수도 있습니다.

.. 가 내 코드베이스의 어디에도 표시되는 것을 원하지 않습니다.

..= 에 또 한 표를 던지고 싶습니다.

..< 및 ..<= 의 단점은 이미 유효한 코드라는 것입니다(다른 값과 비교되는 오른쪽 열린 배타적 범위).

@thepowersgang

..< 및 ..<=의 단점은 이미 유효한 코드라는 것입니다(오른쪽으로 열린 배타적 범위가 다른 값과 비교됨).

사실이지만 이것이 실제로 문제가 될 가능성은 거의 없습니다.

나는 여기의 다른 제안보다 ... 를 매우 선호합니다. 하지만 대체 구문을 선택해야 한다면 ..= 가 될 것입니다.

@nikomatsakis

저는 ..< 및 ..<= 옵션이 언어 문법의 직관적인 모델을 획득하는 과정을 지나치게 복잡하게 만든다는 이유로 순전히 반대합니다.

좀 더 개인적인 메모에서, 나는 그것들이 적어도 터보피쉬만큼 추하고 우아하지 않다고 생각합니다.

나는 함께 가고 싶어요 .. 마우스 오른쪽 독점 및 ..= 포함에 대한 같은 시각적 우아함 사이의 최적의 균형, 직관적으로 이해하기 쉽게하고, 혼란스럽게 두 어렵게 만드는 문법 규칙.

... 정말 .. 구별되지 않습니까? 내가 왜 그렇게 좋아?

@tshepang

나는 ... 가 미학적으로 매력적이기 때문에 좋아하지만 if (x == 2) { 아닌 if (x = 2) { 를 쓰는 것과 유사하게 눈에 띄지 않는 버그를 일으킬 가능성이 있다고 우려하기 때문에 반대합니다. C/C++의 if (x == 2) { . (그리고 그것이 얼마나 위험한 것으로 판명되었는지는 잘 확립되어 있습니다.)

@ssokolow

Linting 또는 옵션 플래그로 더 잘 해결되는 IMO입니다. 단일 파일/프로젝트에서 표기법을 혼합하는 데 많이 사용되지 않습니다.

또한 다른 옵션보다 .... 를 선호합니다. 너비/간격을 두 배로 늘리면 특히 양쪽에 기호가 나란히 배치되어 음의 공간을 격리된 것보다 더 뚜렷하게 만들 수 있다는 점을 고려할 때 충분히 명확해야 합니다.

@ssokolow

시각적 우아함, 직관적으로 파악하기 쉬운 문법 규칙, 그리고 두 가지를 혼동하기 어렵게 만드는 것 사이의 최상의 균형을 위해 ..를 오른쪽 배타적으로, ..=를 포함합니다.

그것은 나를 위해 작동합니다. 주요 문제는 다른 경우(예: <..<= )에 대한 구문 도 원하는지 여부입니다. 개인적으로 .. 및 ..= 케이스의 99.5%를 커버한다고 생각합니다. 저는 주요 사용 사례가 drain 와 같은 API라고 생각하며 현재 거기 에서

cc @rust-lang/libs

우리는 다음을 사용하여 범위를 직접 구성하는 드문 경우를 남길 수 있습니다.
구조체 리터럴.

2017년 2월 22일 수요일 오후 4시 50분, Niko Matsakis [email protected]
썼다:

@ssokolow https://github.com/ssokolow

나는 .. 오른쪽 배타적 및 ..= 최고로 포괄적으로 갈 것입니다
시각적 우아함과 직관적으로 이해하기 쉬운 문법 규칙 사이의 균형
파악하여 두 가지를 혼동하기 어렵게 만듭니다.

그것은 나를 위해 작동합니다. 주요 난제는 우리가 또한할지 여부입니다
다른 경우의 구문(예: <..<=). 나는 개인적으로 .. 그리고 ..=
99.5%의 경우를 다룹니다. 주요 사용 사례는 드레인과 같은 API라고 생각합니다.
우리는 현재 거기에서 독특한 접근 방식을 채택했습니다
https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.range
.

참조 @rust-lang/libs https://github.com/orgs/rust-lang/teams/libs

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment-281815665 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAC3n-aKwYKFq4VI9RizL0GkzXXSjTPwks5rfK2ngaJpZM4F4LbW
.

..= 패턴에서도 사용할 수 있습니까? 기존 ... 구문은 어떻게 됩니까?

더 이상 사용되지 않을 수 있습니다. 그러나 그것의 존재는
최소한 속기로 사용합니다.

2017년 2월 22일 수요일 오후 6시 2분에 andrewtj [email protected]에서 다음과 같이 썼습니다.

I take it ..= 패턴으로도 사용 가능할까요? 무엇이 될 것인가
기존 ... 구문이 있습니까?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment-281834007 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAC3nw_DaOMNxuIKw6ZFfXJW95QyijY4ks5rfL6DgaJpZM4F4LbW
.

@durka @andrewtj 우리가 더 이상 사용하지 않을 것이라고 가정합니다.

..= 는 += 와 같은 의미로 연산자로 사용할 수 있습니다.
~ , 0~9 , 'A'~'Z' 조수 ~ 사용하는 것이 좋습니다.

..= 는 어떤 작업에 해당합니까? - 는 분명히 실행할 수 없습니다.
1-9 == -8 .

2017년 2월 22일 수요일 오후 8:04, Junfeng Liu 알림 @github.com
썼다:

..=는 +=와 같은 의미로 연산자로 사용할 수 있습니다.
~를 사용하는 것이 좋습니다(예: 0~9, 'A'~'Z').

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment-281856846 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAC3n7N2dM4DAzc_uc5JdHit4IJgyvYGks5rfNsPgaJpZM4F4LbW
.

@durka ..= 는 할당 연산자처럼 보이지만 사용 사례는 드물어야 합니다. ~ 은(는) 잠복하지 않는 조수입니다. ... 사용해도 괜찮습니다.

impl Fill for Range<String> {
   fn fill() -> String { ... }
}
impl FillAsign for RangeAssign<String> {
   fn fill(&mut self) { ... }
}
(String::new("abc") .. String::new("f")).fill()  // "abcdef"
(String::new("abc") ..= String::new("f")).fill()  //  ()

아 죄송합니다. 제 글꼴에서 동일하게 보입니다. ..=가 화합물인지 묻고 있었습니다.
+=와 같은 할당 연산자는 어떤 연산을 수행합니까(해당
+로)?

2017년 2월 22일 수요일 오후 8:29, Junfeng Liu 알림 @github.com
썼다:

@durka https://github.com/durka ..= 그냥 할당처럼 보입니다
연산자의 경우 사용 사례는 드물어야 합니다. ~는 조수가 아닌 조수입니다.

범위에 대한 impl 채우기{
fn 채우기() -> 문자열 { ... }
}
RangeAssign에 대한 impl FillAsign{
fn 채우기(&mut self) { ... }
}
(String::new("abc") .. String::new("f")).fill() // "abcdef"
(문자열::new("abc") ..= 문자열::new("f")).fill() // ()

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment-281861478 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAC3n39uqbADB1rNtBh3PBTRY2XBXOUNks5rfOD-gaJpZM4F4LbW
.

@durka @nikomatsakis 좋아, 글쎄, 나는 이것이 곧 해결되기를 바란다. 현재 상황은 어색하고 구문 변경도 마찬가지입니다.

@pornel 비난하는 ... 에서 match 그것이 좋은 해결책이되지 않도록, 호환성을 깰 것이다. 나는 여전히 ... 가장 적절한 것을 찾았습니다(그러나 이것은 Ruby의 정반대이지만 Rubyists는 유사한 문제에 대해 논의하지 않습니다).

@hyst329 하지만 ... 는 오류에 더 취약할 수 있습니다. . 를 누락하거나 추가하면 새로운 의미가 생기기 때문입니다.

비추천은 물건을 망가뜨리지 않습니다. 이전 구문은 기존 프로그램에 대해 영구적으로 지원되어야 하지만 사용자는 문서 및 rustfmt를 통해 새 구문으로 방향을 조정할 수 있습니다.

그러나 사용자는 문서 및 rustfmt를 통해 새로운 구문으로 방향을 조정할 수 있습니다.

나는 그것을 위해 Rustfmt를 사용하지 말 것을 강력히 권장합니다. "자동으로 변경 사항 적용" 모드에서 사용할 때 ... 의 총알 같은 품질을 악화시킬 수 있습니다. 오타를 훨씬 더 목적이 있어 보이는 것으로 자동으로 변환할 수 있기 때문입니다. (따라서 나중에 검사할 때 간과하기 쉽도록 합니다.)

자동 고칠 수 없는 "의미한 내용을 확인하고 .. 또는 ..= 사용하십시오"라는 의미의 컴파일러 경고는 인적 오류의 가능성.

나는 발총이 존재하지 않는 기존 ... 패턴의 맥락에서 이야기하고 있음을 유의하십시오. 현재 Rust는 패턴이 ... 만 허용하고 표현식이 .. 만 허용하는 임시 발총 없는 상황에 있으므로 둘 다 오타로부터 안전합니다.

물론 표현식의 ... 를 ..= 로 변환하는 것은 추천하지 않습니다. 당연히 오타가 영구적일 수 있기 때문입니다.

아. 나는 그것에 대해 잊고 있었다. 상기시켜주셔서 감사합니다.

@adelarsq 실제로 'a'..'z' 또는 128u8..255u8 와 같은 일반적인 오류는 경고로 cargo-clippy 쉽게 통합될 수 있습니다. 그리고 또한 .. 와 ... 의 너비는 분명히 다릅니다 (물론 고정 폭 글꼴을 사용할 때; 사용하지 않는 것은 일반적으로 Rust뿐만 아니라 일반적으로 소스 코드를 작성하는 데 나쁜 생각입니다) .

... 대신 … (유니코드 수평 타원) 구문을 만들 수 있습니다. 그렇게 하면 최소한 아무도 실수로 입력하지 않을 것입니다.

편집: 오 아무도 이 제안을 진지하게 다루지 않았습니다 :cry: 소음에 대해 죄송합니다.

모르겠습니다. 마지막으로 Google 문서도구가 자동으로 줄임표로 변환하는 것을 확인했습니다. 텍스트 편집 업계의 주요 플레이어.

또한, 모든 사람이 편리하게 작성 입력을위한 작성 키가 있습니다. . 그들이 원하는 않는 경우 …

Windows에서는 숫자 키패드와 함께 Alt + 0133 를 사용하여 줄임표를 입력할 수 있습니다! …

그리고 유사한 코드포인트 기반 메커니즘이 X11 기반 데스크탑의 다양한 스택 레이어에 존재하지만(나는 GTK+와 X11 입력 스택이 자체 독립 솔루션을 가지고 있음을 기억합니다) 코드포인트를 숫자로 기억하는 것은 큰 번거로움입니다.

Compose 는 직관적인 솔루션입니다.

내가 기억하는 유일한 Windows Alt 시퀀스는 어렸을 때 만든 모든 DOS 배치 파일 메뉴의 Alt + 219 입니다.

현재 구문은 이미 오래 전부터 존재합니다. 이미 안정화하고 이 끝없는 자전거 이동을 중지합시다.

현재 구문을 유지하는 것은 실제 단점이 많기 때문에 우리가 할 수 있는 최악의 일입니다. 이것은 단순한 자전거 이동이 아닙니다. 올바르게 수행되어야 합니다. 전체 스레드를 건너뛰고 ..= 구문은 지금까지 가장 많이 수용되었습니다...

이 시점에서 나는 그것이 죽은 말을 치는 것 같은 느낌이 들지만 그것에 대해 생각하면... .. 와 ... 는 말 그대로 가능한 한 가장 작은 문자의 사본입니다. 입력하거나 읽을 수 있고, 동일한 문자 그룹과 혼합되어 있으며, 두 가지 모두를 완전히 구별할 수 없는 경우 매우 일반적이고 종종 짜증나게 찾기 어려운 오류 클래스(일부 오류)를 생성할 가능성이 있습니다. 사람과 기계에게.

또는 말 그대로 세계의 다른 구문을 수행할 수 있습니다.

한편으로는 그 우려에 감사드립니다. 다른 한편으로는 현재 ... 패턴 일치 구문이 이미 포함되어 있어 Rust의 다른 곳에서 이미 사용된 구문과 완벽하게 일치합니다.

시각 문제가 있거나 4k 모니터와 10pt 글꼴을 사용하는 사람들이 그럴 수 있다는 것을 알고 있지만 개인적으로 차이점을 인식하는 데 문제가 없습니다.

하지만 합의가 ..= 에 있는 것 같으며 저도 괜찮은 것 같습니다.

FWIW, 나는 .. 의미할 때 실수로 ... 입력한 다음 잠시 동안 눈치채지 못했지만 잠시 후 내 프로그램이 이상하게 작동하는 이유가 궁금했습니다.
예, 더 눈에 띄는 차이가 있어야 하며 ..= 가 가장 합리적입니다.

@rust-lang/lang 토론을 위한 지명. 나는 우리가 ..= 채택하고 그것을 하루라고 불러야 한다고 생각합니다. 수정된 RFC가 필요합니까? 그냥 해? 여기에는 패턴에서 기존 ... 구문을 더 이상 사용하지 않는 것이 포함됩니까? (나는 그렇게 가정한다.)

나는 범위에 ... 를 사용하지 않는 것을 강력히 찬성합니다. 이 스레드 또는 RFC 스레드에서 이미 언급되었는지는 모르겠지만 ... 가 .. 와 비슷해 보이는 것 외에도 ... 을 사용할 수도 있습니다 ... 입니다.

..= 는 분명해 보이고 상대적으로 추함은 .. 보다 덜 일반적이기 때문에 정당화됩니다.

여기에는 패턴의 기존 ... 구문을 더 이상 사용하지 않는 것이 포함됩니까? (나는 그렇게 가정한다.)

좋은 생각인 것 같습니다. ... 에 대해 경고하고 가능한 경우 패턴에서 .. 및 ..= 를 모두 지원합니다.

나는 일반적으로 구문 업데이트를 위한 자동화된 도구 없이 많은 사람들에게 영향을 미칠 경고를 도입하는 것을 경계하지만 ... 에서 ..= 로 변경하는 것은 특히 간단한 변경입니다. 우리는 또한 그러한 도구를 사용할 때까지 더 이상 사용하지 않지만 경고로 만드는 것을 연기할 수 있습니다. 다른 사람들은 어떻게 생각합니까?

저는 ... 가 더 "일반적인" 구문이기 때문에 강력하게 찬성합니다. ..= 를 사용하는 언어는 모르지만 .. 및 ... 를 사용하는 언어는 많습니다.

..= 에 대한 감정이 강하면 시각적 문제를 피하고 다시 무료로 제공하기 위해 포괄적인 범위 구문을 사용하지 않고(대신 내가 보기에 충분히 간결해 보이는 (a..b).inclusive() 메서드를 선택함) 가변 제네릭의 경우 최대 ... 입니다.

편집 :에 대 한 하나 개의 좋은 인수 (a..b).inclusive() 우리가 아직해야한다는 것입니다 ... 에 match 불행히도로 교체하고 새로운 구문. :혼란스러운:

@steveklabnik 사과이 경우 이미 어딘가에 (매우 긴) 스레드 만 언급한다 : 다른 언어는 모두 무엇을 사용 .. 및 ... 각각 독점적이고 포괄적 인 범위에 대한을?

Rust는 다른 언어의 유용한 기능과 구문을 채택했지만 선택적으로 , 적절한 경우 거부하거나 적용한 역사가 있습니다.

@joshtriplett Ruby는 둘 다 사용하지만 반대의 의미를 갖습니다( .. 는 포함, ... 는 제외). 나는 그것이 Ruby에서 좋은 생각이었다고 생각하지 않으며, 우리가 둘 모두를 갖는 것이 잠재적으로 훨씬 더 혼란스러울 수 있지만 거꾸로 된 것 같습니다.

@joshtriplett 내가 가장 친숙한 것은 Ruby입니다. Perl에서 가져온 것이라고 생각했지만 확실하지 않습니다. 나는 ..= 보다 Ruby에서 거꾸로 된 의미론이 더 좋습니다.

솔직히 말해서, 나는 다른 어떤 것보다 안정적인 포괄적인 범위 구문을 선호하고 ..= 에 대한 나의 강렬한 혐오는 개인적인 것이며 합리적인 사람들은 동의하지 않을 수 있음을 인식합니다.

@steveklabnik Swift는 ..< . 제 생각에는 맞죠? ..= 와 비슷하지만 잘못된 경우에 최적화된다는 점에서 더 나쁜 것입니다. =)

Swift는 배타적인 경우 ..<를 사용하고 포괄적인 경우 ...를 사용합니다(해당 용어는
"반개방" 및 "닫힘").

나는 여전히 ..<(..를 속기로 사용) 및 ..=를 좋아합니다.

그러나 또 다른 미해결 질문(아마도 이 추적 문제의 범위에 속하지 않을 수 있음)은 닫힌 범위에 대한 구문을 "그냥" 채택할지, 아니면 첫 번째 지점이 열린 범위(예: Strawman >..> 및 >..=.

2017년 3월 16일 목요일 오후 2시 19분, Niko Matsakis [email protected]
썼다:

@steveklabnik https://github.com/steveklabnik Swift는 ..<를 사용한다고 생각합니다.
오른쪽? ..=와 비슷해 보이지만 더 나쁘다는 점에서 최적화됩니다.
(이모) 잘못된 경우입니다. =)

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment-287147321 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAC3n0Wop5fJh9HVo7pSqo0riHm96Gm4ks5rmX1BgaJpZM4F4LbW
.

전주곡에 inclusive 함수가 있어도 상관 없습니다.

for x in inclusive(1..10) {

}

나는 성냥과의 대칭성이 설득력 있는 주장이라고 느낀 적이 없습니다. 나는 우리가 독점적인 .. 패턴을 추가하기로 결정했다고 생각하지만 나는 그것들도 싫어합니다 - 이제 패턴의 값이 패턴과 일치하지 않습니다! 범위를 일치시키는 것은 범위를 반복하는 것과 근본적으로 다르며 대칭이어야 할 이유가 없습니다. 나는 그것이 여전히 옵션이라면 패턴에서 .. 를 허용하지 않는 것을 선호하지만 그렇지 않다고 생각합니까?

..= 및 ... 의 단점이 모두 중요하다고 생각합니다. ..= 는 상당히 이상하지만 ... 는 오류 가능성을 1만큼 높입니다.

그런 끝없는 버그 가능성보다 이상하게 보이는 연산자를 사용하는 것이 좋습니다(모든 언어는 다른 언어에는 없는 연산자를 도입합니다. 예를 들어 Swift의 ..< , F# 및 Scala의 모든 연산). 어쨌든 사람들은 Rust 책을 읽어야 할 것입니다.
많은 사람들이 Ruby에서 Rust로 오고 있다는 점을 고려하면 Ruby와 비교하여 이전 버전을 사용해서는 안 됩니다. ( ... 는 오프 가능성을 1 오류만큼 증가시킨다는 주장에 추가로.)
Swift에서는 ..< 를 수락하지만 Rust에서는 ..= 를 수락하지 않을 수 있습니까? ..= 는 그렇게 이상하지 않습니다.

패턴에서 범위 구문을 확장하는 것은 AFAIK와 마찬가지로 여전히 미해결 문제입니다.
한 가지 이유는 Enum::Variant(..) 가 이미
유효하고 Enum::Variant(RangeFull) 가 중단됨을 의미하도록 변경합니다.

2017년 3월 16일 목요일 오후 3시 77분에 Boscop [email protected]에서 다음과 같이 썼습니다.

이상하게 보이는 연산자를 사용하는 것이 좋습니다(모든 언어는
다른 사람들이 가지고 있지 않은 연산자(예: Swift의 ..<, F#의 모든 연산)
및 스칼라). 어쨌든 사람들은 Rust 책을 읽어야 할 것입니다.
Ruby에서 Rust로 오는 사람들이 많다는 점을 감안할 때,
Ruby와 비교하여 거꾸로되어서는 안됩니다. (논증에 덧붙여
그것은 ... off의 가능성을 1 오류만큼 증가시킵니다.)
어떻게 Swift에서 ..<를 받아들이고 Rust에서 ..=를 받아들이지 않을 수 있습니까?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment-287160485 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAC3nz9ZNR2utl7LPTVvQPQ_Ma8sDBGuks5rmYhmgaJpZM4F4LbW
.

그래서. slice.get(10...30) 같은 것을 입력하고 케이크도 먹고 싶어요.

다른 구문보다 inclusive(0..10) 를 선호한다고 확신했습니다.

• @nagisa 는 slice.get(10...30) 를 쓰고 싶어하지만, slice.get(10...30) 인지 slice.get(10..30) 인지 세심한 주의를 기울이고 싶지 않습니다 . 구문의 근접성이 진짜 문제라고 생각합니다.
• ..= 가 미학적이고 직관적이지 않다는 데 모두가 동의할 것이라고 생각합니다.
• (0..10).inclusive() 는 같은 구문이지만 덜 편리합니다. 기술적으로 inclusive prelude는 아마도 두 구문을 모두 지원할 것입니다.

나는 다음과 같이 보일 것이라고 생각한다.

trait IntoInclusive {
    type Inclusive;
    fn inclusive(self) -> Self::Inclusive;
}

fn inclusive<T: IntoInclusive>(range: T) -> T::IntoInclusive {
    range.inclusive()
}

나는 모두가 ..=가 미학적이고 직관적이지 않다는 데 동의한다고 생각합니다.

좀 지나친 일반화라고 생각합니다. ..= 는 inclusive() 와 같은 방법보다 더 미학적이고 직관적입니다.

(또한, 우리의 혐오 얼마나 많은 모르는 ..= 하지 않은 것을 문제 찾을 수) 잠재 의식 (또는 의식적인 노력이 될 수 ... .)

.inclusive() 너무 자주 발생 뭔가 너무 깁니다 (그 주에, 나는 또한에 대한 짧은 형태가 있어야한다고 생각 .enumerate() ).
그러나 .inclusive() 가 있더라도 함수는 두 개가 아니라 하나만 있어야 합니다.
또한 포함 범위 구문이 없으면 match 에서 사용할 수 없습니다.
하지만 Scala 와 같이 일반적인 방식으로 추출기를 지정하는 방법이 필요할 수 있습니다. 모든 유형이 일치에서 사용될 수 있으므로 해당 일치는 암시적으로 unapply 메서드를 호출합니다.

(또한 우리는 ..=에 대한 혐오감이 그렇지 않은 것에 대한 문제를 찾으려는 무의식적(또는 의식적인) 노력일 수 있는지 모릅니다....)

나에게서 아무도. 이것은 일종의 악의에 대한 비난입니다.

또한 포함 범위 구문이 없으면 일치에서 사용할 수 없습니다.

포함 범위 패턴은 이미 match 에서 지원됩니다. 사실 그것들은 오늘날 우리가 패턴으로 지원하는 유일한 종류의 범위입니다.

@withoutboats 예, 하지만 "포함 범위 구문이 없으면 매치에서 사용할 수 없습니다"라고 말했습니다. 지금은 구문이 있지만 Scala와 같은 추출기가 없으면 매치에서 사용할 수 없기 때문에 내 주장은 .inclusive() 에 반대했습니다. 이 문제의 요점은 포괄적 범위 구문이 일치에서만 작동하고 현재 구문 대신 구문이 무엇인지 결정하는 특별한 경우가 되어서는 안 된다는 것입니다.

포함: for i in 1..10! { }

Java/C/C++에서 15년 이상 일한 사람으로서 .. vs ... 는 매우 혼란스럽고 실수를 입력하는 것만으로도 버그를 일으킬 수 있습니다. 또한 Ruby와의 관계는 이것을 더욱 혼란스럽게 만듭니다. 이것이 ..= 또는 다른 대안이 더 나은 이유입니다.

내 '모자'를 링에 던지는 것:

for i in 1..10^

올바른 값이 _up_ 끝까지 간다는 것을 상징하는 모자/캐럿.

@leebenson 개인적으로

for i in 1..^10

@retep998 나는 보내기를

의 @ retep998 나는 같이 당신의 제안 ..^ 훨씬 더보다는 ..= ; 그것은 그 의미를 훨씬 더 연상시키는 것처럼 보이며, 증가된 할당 연산자의 이상한 변형(예 += 및 *= )처럼 보이는 것을 방지합니다. 즉, 어느 쪽이든 ... 보다 훨씬 낫습니다.

..^ 뒤처질 수 없습니다.

개인적인 수준에서는 매우 못생겼습니다(부분적으로는 .. 가 많은 글꼴에서 ^ 와 수직으로 분리되어 있기 때문입니다).

UI/UX 전문가로서, 나는 그것이 자신의 이익을 위해 너무 영리한 예라고 생각합니다.

나는 다른 언어에서 와서 볼 경우 ..^ , 모든 나는 알고있다 (나는 범위로 인식조차하지 않을 수 있습니다 5..^15 에 대한 몇 가지 이상한 부분 계승 축약 될 수 15! - 4! ) 인간은 컨텍스트에서 생각하고 캐릭터가 주류 프로그래밍 컨텍스트에서 갖는 유일한 연관성은 지수이기 때문입니다.

(만약 우리가 문맥에서 생각하지 않았다면, ... 는 산문 쓰기의 대화에서 "내용 생략"과 같은 의미와 유추하여 "콜백이 여기에 삽입됨" 또는 "이벤트 발생"과 같은 것을 의미할 수 있습니다. 가장 즉각적인 예를 보여줍니다. 화살과 유사하여 "끝까지 올라갑니다"라는 의미를 부여하는 것은 그것이 새로운 사람의 기대와 상호 작용하는 방식에 있어서 손의 속임수를 통해 마술을 하는 것과 같습니다.)

대조적으로, = 는 할당의 동작과 평등의 개념을 모두 언급한 선례가 있으며 ..= 대한 "이상한 지수 구문"과 같은 오해가 없습니다. 왜냐하면 " 할당 연산자에 의해 아직 처리되지 않은 "대입 + 평등"은 "오른쪽 숫자로 끝나는 일련의 숫자와 관련이 있는 것"입니다... 이는 범위 구문이 하는 일에 대한 모호하지만 적절한 정의입니다.

또한 ..^ 가 컨텍스트에서 사용되는 범위 구문이라는 것을 인식하더라도 ^ 가능성을 제외 중요한 상황에서, 2..^8 개방형 범위 두에서 시작하고 (제의 능력에 이전 단계를 고려하여, 즉. 스테핑 속기 2..Inf^8 는 2..+8 가 "2에서 무한대까지 8단계로 반복"의 약어입니다.)

사람들은 while 루프를 작성할 때 < (독점) 대 <= (포함)의 관점에서 생각하는 데 익숙하기 때문에 ..= 그 문제를 피할 수 있습니다. 및 C 스타일 for 루프.

@ssokolow 합법적 분석.

개인적으로 ..= 또는 ..^ 뒤에 갈 수 있습니다. 둘 중 하나의 기호는 나에게 의미가 있습니다. 즉, 각각 '최대 및 같음' 또는 단순히 '최대'입니다. 내 생각에는 둘 다 같은 의미입니다.

우리 모두는 다른 언어와 오염된 상징/편견의 역사를 가져오기 때문에 모든 사람을 만족시키는 무언가를 생각해 내기 어려울 것입니다. 처음에 ^ 기호를 추가했습니다. 예를 들어, 앞에 삽입하면 '계단'이나 지수를 나타내는 느낌이 있는 반면 접미사는 범위를 더럽히지 않고 어떻게든 더 순수한 느낌으로 남겼기 때문입니다. 하지만 그건 나뿐이야.

어쨌든 나는 어떤 형태의 속기 표기법과 오른쪽 값을 암시적으로 +1하는 함수 호출을 선호합니다. 나는 이것이 함수 호출처럼 느껴지는 것에 위임하기에는 너무 일반적인 구문이라는 이전 의견에 동의합니다. ... 신경쓰지 않겠지 = / == 버그일 것이고 누군가의 발을 쏘게 될 것입니다...

많은 사람들이 적극적으로 싫어하는 것 같습니다 ..= 아무도 부정적인 말을 하지 않았습니다
약 .... 그냥 조용히 무시했습니다 (몇 가지 엄지 손가락 제외) I
나는 그것을 다시 제기하고 사람들이 그것을 고려하고 줄 것이라고 생각했습니다.
반대하는 경우 사용하지 않는 이유.

소음이 더 많기 때문에 언급하기조차 싫지만 .:
(점 콜론) 포함? 점 3개지만 문자는 2개입니다.
모양이 ..

2017년 3월 18일 토요일 오전 11시 50분, Lee Benson 알림 @github.com
썼다:

@ssokolow https://github.com/ssokolow 합법 분석.

개인적으로 나는 ..= 또는 ..^ 중 하나를 뒤에서 얻을 수 있습니다. 둘 중 하나의 상징
나에게 의미가 있습니다. 즉 '최대 및 같음' 또는 단순히 '최대',
각기. 내 생각에는 둘 다 같은 의미입니다.

모두가 만족할 수 있는 제품을 찾기는 힘들겠지만,
왜냐하면 우리는 모두 다른 언어에서 역사를 가져오고 그것과 함께 더럽혀지기 때문입니다.
상징/편향. 처음에 숫자 뒤에 ^ 기호를 추가했습니다.
예를 들어, 이전에 삽입하는 것은 '단계'를 나타내는 느낌을 가졌기 때문에
또는 지수, 접미사는 범위를 오염시키지 않고 어떻게 든 더 순수하게 남겼습니다.
감정. 하지만 그건 나뿐이야.

어쨌든, 나는 어떤 형태의 속기 표기법을 선호합니다.
암시적으로 오른쪽 값을 +1하는 함수 호출입니다. 나는 이전에 동의한다
이것은 너무 일반적인 구문으로 다음과 같은 것에 위임하기에는
함수 호출처럼 느껴진다. 나는 상관하지 않을 것입니다 ...하지만 당연합니다.
아마도 = / == 새 옷에 버그가 있고 누군가를 쏘게 될 것입니다.
발...

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment-287566556 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AIhJ6jWgPwndKaQvVjULlV_OoC6WDO0Cks5rnCeLgaJpZM4F4LbW
.

오, 이것은 아직 자전거 탈취 단계에 있습니까? 😆

다시 읽어보니 @nikomatsakis 가 ..= 만들고 하루라고 부르는 데 동의하는 것 같습니다 . .. 대 ... 의 유사성은 너무 미묘하며 가변 제네릭(https://github.com/)에 모호성 없이 ... 토큰을 사용하는 것이 좋습니다. Rust-lang/rfcs/pull/1935), 여기서 둘 사이의 혼동을 줄여야 하는 매우 뚜렷한 목적을 수행합니다.

모든 반개방형 변형에 대해 보다 일반화된 구문에 대한 욕구가 여전히 존재하는지 확실하지 않지만 .. 및 ..= 이외의 언어 구문을 제공하려는 노력은 가치가 없다고 생각합니다. .

더 많은 소음 때문에 언급하기조차 싫지만 포괄적인 경우 .:(점 콜론)은 어떻습니까?

@ssokolow 가 UI/ 번 강조한 것

나는 개인적으로 세 번째 점이 있다는 것에 대해 _zero_ 반대하지만, 그것이 결국 일부 사람들을 걸려 넘어지게 할 것이라는 사실을 알고 있습니다. 그러나 설명하기가 너무 쉽기 때문에 영리한 해결 방법을 설계하기 위해 언어에 책임이 있어야 하는지 잘 모르겠습니다. '2개의 점은 제외됩니다. 점 3개 포함' 정말 _그_ 파악/디버그가 어렵습니까?

어떤 경우이든 - 누가 최종 결정을 내리고 이를 마무리 짓기 위한 다음 단계는 무엇입니까? 18개월 동안 세 번째 캐릭터에 대해 논의하는 것은 아마도 현 시점에서 _는_ 바이크쉐딩 입니다 😄

동의합니다. ^는 단계처럼 보입니다.
IMO 서로 불일치 op= 우리가 이제까지있을 것이라고 방법이 없기 때문에 운영자는 아무런 문제가 없습니다 a ..= b 의 의미에서 a = a .. b 부터 .. 있다가 연산자가 아니라 Range를 구성하기 위한 구문적 설탕(그리고 우리는 모든 연산이 op= 및 .. 형식을 자동으로 가져오는 일반적인 연산 오버로딩 체계가 없습니다).
나는 ..= 이 문서를 보지 않고 명확하다고 말하는 것이 아닙니다. 그러나 일단 사람들이 문서를 보면 암기하기 더 쉽고 어쨌든 문서를 봐야 할 것입니다.

@nikomatsakis 의 지명을 감안할 때 다음 주 lang-team 회의에서 이에 대해 논의하고 그 시점에서 전화를 걸 것 같습니다. 나는 이것이 전화를 걸고 바이크 셰딩을 끝내기 위해 랭 팀이 필요하다는 데 동의합니다.

나는 또한 ..^ 가 컨텍스트에서 사용되는 범위 구문이라는 것을 인식하더라도 처음에는 그것이 포괄적인지 배타적인지 직관적으로 알 수 없다는 것을 걱정합니다.

동의. 사실, 나는 이미 Perl 6에서 이 구문을 보았습니다. 여기서 제안의 반대는 배타적이라는 의미입니다.

@solson 그것에 대한 매우 강력한 주장입니다.

Perl은 ..가 포괄적인 의미를 갖는 완전히 일반적인 구문을 가지고 있는 것 같습니다(둘 다
측면) 및 양쪽의 ^는 해당 바인딩을 배타적으로 만듭니다.

2017년 3월 18일 토요일 오후 6시 51분, Josh Triplett [email protected]
썼다:

@solson https://github.com/solson 매우 설득력 있는 주장입니다.
반대합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment-287580739 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAC3n7Fnn1_t9BkYOhfS-7oCaGlVff2aks5rnF_5gaJpZM4F4LbW
.

죄송하지만 @rust-lang/lang 회의에서 이 문제를 논의했을 때 합의에 도달하지 못했습니다. @withoutboats 는 특히 일부 심각한 예약이 있어 스스로 방송할 수 있기를 바랍니다.

우리가 논의한 몇 가지 주요 사항:

• 표현식과 패턴에 포괄적인 범위 구문이 있는 경우 동일해야 합니다.
  
  
  
  • 즉, x ..= y 채택하면 기존 x...y 패턴 구문을 사용하지 않음을 의미합니다.
  
  
• 유혹적인 옵션은 "아무것도 하지 않고" (x..y).inclusive() 또는 이와 유사한 것을 쓰는 것입니다. 그러나 패턴에서는 작동하지 않습니다( x...y ). 이것은 다음과 같은 몇 가지 질문을 제기합니다.
  
  
  
  • 우리는 여전히 독점적인 범위 패턴을 원합니까? 예: match 3 { 1..3 => false, .. }
    
    
    
    
    
    • 그렇다면 동일한 잠재적 혼란이 있습니다!
    
    
    
  
  
  • @withoutboats 는 우리가 그런 패턴을 원하지 않을 수도 있다고 생각하는 것 같습니다. 나와 @joshtriplett 는 회의적 이었습니다. 우리 둘 다 그런 것들이 당신이 원하기 전까지는 아무 관련이 없어 보인다가 절대적으로 필요 하다고 느끼기 전까지는 그런 종류의 것이라는 의견을 갖고 있었던 것 같아요. =)
  
  
• 배타적 범위 패턴과 관련된 또 다른 문제는 (또한 불안정한) 슬라이스 패턴 과 제대로 상호 작용하지 않는다는 것입니다(자세한 내용은 https://github.com/rust-lang/rust/issues/23121 참조).

이번 토론을 통해 나온 한 가지는 상충 되는

• 배타적 범위 표현식 은 어떻게 해야 합니까?
• 기존 배타적 범위 패턴 을 더 이상 사용하지 않거나 변경해야 합니까?
• 포괄적인 범위 패턴 에 대해 어떻게 해야 합니까?
• 슬라이스 패턴 은 어떻게 해야 합니까?

이 글을 시작하기 전에 대화의 매 순간마다 우리 모두가 실제로 같은 개념에 대해 이야기하고 있다는 확신이 들지 않았다고 말하고 싶습니다. 예를 들어, Niko는 "배타적 범위 패턴은 당신이 원하기 전까지는 관련이 없어 보인다"고 말했지만, 나는 그 당시 Niko와 Josh가 포괄적인 범위 표현에 대해 이야기하고 있었다고 생각했습니다.

(그리고 나는 Niko의 게시물의 마지막 부분에서 현재 "배타적 범위 표현식"이라고 읽는 첫 번째 글머리 기호가 "포함 범위 표현식"이라고 말해야 한다고 생각합니다.)

TL;DR 내 의견

범위 표현식 정보:

• ... 또는 ..= 포함 범위 표현식에 대한 구문을 도입 해서는 안 됩니다.
• 전주곡에 배타적 범위 값을 취하고 포함 범위 값을 반환하는 함수를 추가해야 합니다. 따라서 inclusive(0..10) (이름은 자전거를 탈 수 있음)로 작성합니다.

범위 패턴 정보:

• 독점적인 범위 패턴을 도입하거나 어떤 방식으로든 생성해서는 안 됩니다.

다시 말해서, 우리가 해야 하는 유일한 물질적 변경은 libs 변경입니다: 서곡에 함수를 추가하십시오.

범위 표현식

내 주장의 기본은 포괄적 범위 값을 반복하는 것이 일반적이지 않은 요구 사항이라는 사실입니다. RFC가 18개월 전에 받아들여졌음에도 불구하고 우리는 여전히 이 기능을 안정화하지 못했다는 사실에서 이것이 입증되었다고 생각합니다. 구현 문제 때문이 아니라 우리가 교환에 만족하지 않기 때문입니다.

포괄적인 범위 표현식은 이를 생성하는 간단한 방법을 지원해야 할 만큼 충분히 자주 필요하지만 지금까지 논의한 구문의 단점을 극복할 만큼 자주는 아니라고 생각합니다.

특히 모든 구문 솔루션이 공유하는 단점은 어느 것도 실제로 자체 문서화되지 않는다는 것입니다. 0...10 또는 0..=10 가 포함 범위 표현식이라는 것은 비교적 명확하지 않습니다. 비교적 드물게 발생하기 때문에 처음 접하는 사용자에게는 걸림돌이 될 것입니다.

즉, 사용자가 "정상적인" .. 범위를 다루지 않는다는 사실을 알아차리기라도 합니다. 물론 이것은 ... 의 큰 문제이지만 ..= 가 문제를 완전히 제거 하지는 않습니다. 코드를 훑어볼 때 하나의 = 문자(또는 ^ 또는 : 또는 기타)를 놓치기 쉽습니다. 추가 . 만큼 쉽지는 않지만 충분히 눈에 띄는지 확신하지 못합니다.

나는 실제로 ... 와 ..= 사이에 "눈에 띄는 대 명확성" 트레이드 오프가 있다고 생각합니다. 나는 그것의 더 분명 어떻게 생각 ... 보다 (당신이 두 구문은 반대의 의미를 가지고 루비에서 오는 경우가 아니라면) 수단을 ..= ,하지만 확실히 덜 눈에 띄는.

그러나 inclusive(0..10) 와 같은 서곡 함수는 우리가 논의한 어떤 구문보다 더 명확하고 눈에 잘 띄는 것 같습니다. 예, 입력할 문자가 더 많지만 해당 속성의 단점은 사용 빈도와 관련이 있습니다.

또한 구문 분석 및 토큰화 문제를 피하고 (0..10).filter 등을 작성해야 하는 (매우 성가신) 범위 대 메서드 우선 순위 문제가 있는 사용자를 돕습니다.

범위 패턴

.. 추가하면 안 된다고 생각하는 주된 이유는 슬라이스 패턴 주변에 모호성이 발생하기 때문입니다. 이는 유용하다고 생각합니다. 나는 그것을 풀지 않아도 그 문제를 해결하고 싶다.

두 번째 이유는 그들이 꽤 나쁜 스타일이라고 생각하기 때문입니다(다른 사람들은 동의하지 않는다는 것을 압니다). 예를 들어:

if let 1..10 = x { .. }

10 가 포함된 패턴과 일치하지 않기 때문에 이것이 혼란스럽다고 생각합니다. Niko는 이것이 10 산출하지 않는 배타적 범위 표현식과 실제로 다르지 않다고 언급했지만, 저는 우리가 배타적 범위. Rust에 들어오면서 저는 반복 및 슬라이싱 범위가 배타적일 것이라고 예상했지만 패턴에 대해서는 그런 기대를 하지 않았습니다.

또한 표현식의 .. / ... 가 가지고 있는 "off-by-one" 문제가 있습니다.

Niko가 다음과 같은 글을 쓰고 싶다고 언급한 것으로 알고 있습니다.

match x {
    0..10 => { ... }
    10..20 => { ... }
}

그러나 나는 정말로 강력하게 다음을보고 싶습니다.

match x {
    0...9 => { ... }
    10...19 => { .. }
}

어쨌든, 나는 Niko가 때때로 이것이 "절대적으로 필요하다"고 생각한다는 의미에 놀랐습니다. 그래서 더 많은 반론을 듣고 싶습니다. 그것들은 constexpr이어야 하기 때문에 나에게 '절대적으로 필요한' 것보다 '있으면 좋은 것'에 훨씬 더 가깝습니다.

나는 포괄적인 범위 표현보다 독점적인 범위 패턴에 흔들리는 것이 확실히 더 쉽다고 느낍니다.

일관성 주장

Niko는 일관성 때문에 표현식과 패턴 모두에서 .. 및 ... 를 모두 갖는 것이 중요하다고 언급했습니다. 나는 기본적으로 이 주장에 전혀 동요하지 않습니다. 범위를 반복하고 범위를 일치시키는 것은 실제로 유사한 작업이 아니며 처리 방법에 차이가 있음을 이해합니다.

실제로 구현 연결조차 없습니다. 1..10 는 Range 값을 생성하는 반면 1...10 는 정수 값과 일치합니다. 대부분의 대칭 표현식/패턴 구문이 하는 방식으로 구조화/해체화 연결이 있는 것과 다릅니다.

유사성을 강조하는 "범위 패턴" 🤓보다 패턴을 "도메인 패턴"이라고 부르는 것이 기술적으로 더 정확해 보입니다.

@withoutboats

예를 들어, Niko는 "배타적 범위 패턴은 당신이 원하기 전까지는 관련이 없어 보인다"고 말했지만, 나는 그 당시 Niko와 Josh가 포괄적인 범위 표현에 대해 이야기하고 있었다고 생각했습니다.

제 입장에서는 다양한 경우에 필요한 배타적 범위와 포괄적 범위를 모두 찾았습니다(안정적인 Rust에서 작업하기 위해 두 경우 모두에 대해 배타적 범위를 사용했지만 상단에 +1 를 사용하여 이 문제를 해결해야 했습니다. 경계). 패턴과 표현 모두에 사용할 수 있도록 하고 싶습니다.

즉, 개인적으로 포함 범위에 대해 함수를 사용하는 데 반대하지 않습니다. 예외 는 포함 범위와 패턴 으로 작성하는 방법을 원한다는 점과 이 두 구문이 혼동될 정도로 유사해 보이지 않기를 바랍니다. .. 및 ... 처럼. 그리고 이러한 범위를 패턴으로 작성하는 구문이 주어지면 표현식에서 이러한 범위에 대해 다른 구문을 갖는 것이 이치에 맞는지 모르겠습니다.

특히 모든 구문 솔루션이 공유하는 단점은 어느 것도 실제로 자체 문서화되지 않는다는 것입니다. 0...10 또는 0..=10이 포함 범위 표현식이라는 것은 비교적 분명하지 않습니다. 비교적 드물게 발생하기 때문에 처음 접하는 사용자에게는 걸림돌이 될 것입니다.

나는 이것에 동의합니다. 이것은 덜 컴팩트한 구문에 대해 이의가 없을 정도로 충분히 드물게 나타납니다. 그러나 표현식과 패턴 모두에서 포괄적이고 배타적인 범위를 작성 하는 메커니즘을 갖고 싶습니다.

예를 들어 포괄적인 범위 패턴을 작성하는 데 매크로 또는 이와 유사한 것이 필요한 경우에는 상관하지 않습니다.

@joshtriplett 다음과 같이 말할 때 정말 명확하게 하고 싶은 부분입니다.

나는 다양한 시간에 필요한 배타적 범위와 포괄적 범위를 모두 발견했습니다(안정적인 Rust에서 작업하기 위해 두 경우 모두에 대해 배타적 범위를 사용했지만 상한선에서 +1로 이 문제를 해결해야 했습니다).

당신이 표현 에 대해 이야기하고 있는 것이 분명한 것 같지만 인용한 섹션은 패턴 에 관한 것이었습니다(다음 단락에서 패턴에 대해 이야기한다는 것을 알고 있지만, 나는 그 단락에서 다루지 않는 "필요성" 문제에 대해 묻고 있는 것입니다 😃) .

패턴의 현재 상태는 x...y 형식의 포함 범위 패턴만 지원한다는 것입니다. 독점 범위 패턴 이 없는 것이 정말 실망스러웠는지 여부에 대해 더 이야기할 수 있습니까?

@withoutboats

독점 범위 패턴이 없는 것이 정말 실망스러웠는지 여부에 대해 더 이야기할 수 있습니까?

같은 것

    match offset {
        0x0200 .. 0x0280 => { /* GICD_ISPENDR<n> */ }
        0x0280 .. 0x0300 => { /* GICD_ICPENDR<n> */ }
        0x0300 .. 0x0380 => { /* GICD_ISACTIVER<n> */ }
        0x0380 .. 0x0400 => { /* GICD_ICACTIVER<n> */ }
        0x0400 .. 0x0800 => { /* GICD_IPRIORITYR<n> */ }
    }

대

    match offset {
        0x0200 ... 0x027C => { /* GICD_ISPENDR<n> */ }
        0x0280 ... 0x02FC => { /* GICD_ICPENDR<n> */ }
        0x0300 ... 0x037C => { /* GICD_ISACTIVER<n> */ }
        0x0380 ... 0x03FC => { /* GICD_ICACTIVER<n> */ }
        0x0400 ... 0x07FC => { /* GICD_IPRIORITYR<n> */ }
    }

나는 그것이 특별히 실망스럽다고 말하지는 않겠지만, 첫 번째 것이 확실히 더 멋지게 보입니다.

@withoutboats 명확성을 기하기 위해 여러 번 배타적 범위 표현, 포괄적 범위 표현, 포괄적 범위 패턴을 원했습니다. 나는 배타적 범위 패턴을 갖는 것에 대해 깊이 관심을 가지고 있었던 시간을 바로 생각할 수는 없지만, 나는 또한 그것에 반대하지 않을 것입니다. 우리는 독점적 인 범위 패턴이없는 경우에도 포괄적 인 범위 패턴을 사용하는 경우, 나는 여전히 매우 혼란 것 ... 독점적 인 범위 표현식을 사용 .. .

@petrochenkov 나는 그것들이 C 아니라 F 로 끝나야 한다고 가정합니까?

16진수 범위 패턴(예: 0x8000...0x9FFF => /* body */ 에서 같은 경우를 겪었습니다. 0x8000..0xA000 가 약간 더 직관적인 속성을 가지고 있다는 것을 알았습니다. 생각할 필요 없이 즉시 범위의 크기가 0xA000 - 0x8000 = 0x2000 이고 다음 인접 범위가 0xA000 에서 시작한다는 것을 알 수 있습니다.

포괄적인 범위에서 이러한 사실을 확인하는 데 필요한 +1 처리하는 것은 제가 감당할 수 있는 작은 차이지만 일반적으로 배타적 범위(패턴 및 표현식 모두)가 제 작업에 더 적합합니다.

@petrochenkov 16진수에 대한 독점 범위를 선호하는 이유를 알 수 있습니다(아직 그렇지 않을 수도 있지만 이것은 매우 YMMV 거래처럼 느껴집니다).

그러나 슬라이스 구문의 모호성을 어떻게 처리할까요?

@joshtriplett

포함 범위 패턴이 ... 하고 배타적 범위 표현식이 .. 사용하는 경우 여전히 매우 혼란스러울 것입니다.

이것이 오늘날 Rust가 작동하는 방식이며 심각한 혼란의 원인이 아닌 것 같습니까?

@solson

나는 그것들이 C가 아니라 F로 끝날 예정이라고 가정합니다.

아니 :)
(이것들은 32비트이고 offset 는 4의 배수입니다.)

@withoutboats

16진수에 대해 독점적인 범위를 선호하는 이유를 알 수 있습니다.

나는 이것이 강력한 선호도가 아니라는 점에 유의해야 합니다. 나는 여전히 독점적인 패턴과 포괄적인 범위를 모두 삭제해도 괜찮을 것입니다(하지만 그 중 하나는 제외, 너무 우스꽝스러울 것입니다).

그러나 슬라이스 구문의 모호성을 어떻게 처리할까요?

용이하게! PATTERN.. => .. @ PATTERN

포괄적인 범위가 단순하기를 원하는 주된 이유는 변수에 중지 값을 전달하는 상황에 두 번 이상 부딪쳤고 정확히 한 변수 유형이 보유할 수 있는 최대값이므로 유일한 솔루션입니다. 컴파일 타임에 오버플로를 배제하는 방법은 다음과 같습니다.

1. 포함 범위 사용(가장 깨끗하지만 안정적이지 않음)
2. + 1 전에 업캐스팅(내가 이미 u64 에 있지 않고 우아하지 않다고 가정)
3. 값 중 작은 값과 범위에 대해 최대값 빼기 1을 취한 다음 적절한 경우 작업을 한 번 더 실행합니다.

고유한 목적이 없는 알고리즘에 + 1 를 추가하는 대신 포괄적 범위를 사용하는 습관을 구축하는 것은 나중에 cargo fuzz ... 및 + 1 보다 이름에 더 많은 문자가 포함된 "배타적에서 포함" 기능은 포함 범위가 습관적으로 사용해야 하는 것이 아니라 예외적인 것이라는 인상을 줍니다.

그것이 제가 반대하는 가장 큰 이유 중 하나입니다. 포괄적인 범위가 해킹이라는 인상을 전달하며, 배타적인 범위가 실패한 것으로 입증될 때 사용됩니다.

@ssokolow 하지만 그 사용 사례는 서곡 기능으로 편안하게 다룹니다. 포함된 범위를 만드는 것이 가능하지 않아야 한다는 입장을 취하는 사람은 아무도 없습니다.

나는 전주곡 기능에 대한 @withoutboats 아이디어를 좋아합니다. 포괄적인 범위가 더 일반적일 수 있는 다른 장소는 정수를 사용하지 않는 경우라고 생각합니다. 예를 들어 btree(또는 유사한 데이터 구조)에서 검색 범위를 지정하는 경우입니다.

@withoutboats 귀하가 응답하는 동안 내 게시물을 상당히 편집했지만 내가 추가한 요점은 포괄적인 범위를 구문적으로 2급 시민으로 만드는 것입니다(배타적 범위에 + 1 를 추가하는 것보다 구문이 더 깁니다. ), 그것들을 사용하는 것에 대한 미묘한 낙담과 "나중에 cargo fuzz 뵙겠습니다" 발총처럼 느껴집니다.

다른 것이 없다면, 그것은 학습성 사마귀입니다.

Rust는 무한한 정수 지원을 제공하는 Python 3.x가 아닙니다. Rust는 사용자에게 하드웨어 절충안을 숨기지 않으며 int 대신 u32 와 친구를 사용하는 것의 일부로 ..= 선호합니다. (특히 지금까지 cargo fuzz 의 "트로피 케이스"에서 오버플로/언더플로 오류가 가장 일반적이라는 점을 감안할 때)

편집: 이에 대한 이메일 알림에만 표시되는 비트는 무시하십시오. 방금 일어났고 아직 모든 실린더에서 발사하지 않습니다.

나는 inclusive(n..m) 를 낙담으로 보지 않습니다... n..(m + 1) 및 n..=m 보다 내 코드를 읽기 쉽게 만드는 매우 명확한 구조이기 때문에 작성하는 것을 선호합니다.

n..=m 는 inclusive(n..m) IMO보다 학습성 사마귀에 가깝습니다.

매치의 경우 특정 유형의 패턴보다는 숫자 범위를 완전히 커버하고자 하는 바람이 있다고 생각합니다.

아마도 "이전에서 계속" 구문이 있는 경우 문제를 해결할 수도 있습니다.

BTW, 첫 번째 패턴만 일치하므로 시작 번호를 생략할 수 있습니다.

    match offset {
        0 ... 0x01FF => {}
        0 ... 0x027C => { /* GICD_ISPENDR<n> */ }
        0 ... 0x02FC => { /* GICD_ICPENDR<n> */ }
        0 ... 0x037C => { /* GICD_ISACTIVER<n> */ }
        0 ... 0x03FC => { /* GICD_ICACTIVER<n> */ }
        0 ... 0x07FC => { /* GICD_IPRIORITYR<n> */ }
    }

나는 이것이 관점의 문제일 수 있다는 것을 인정하지만:

1. .. 및 ..= 를 볼 때 "허. 왜 그렇게 작은 차이에 대해 두 가지 구문이 있는지 궁금합니다."라고 생각합니다. " 1..pivot 및 pivot..end " 대 " x..=y 여기서 y 는 가능한 최대 값일 수 있습니다."

2. 가변 크기 측면에서 습관적으로 생각할 만큼 충분히 경험하기 전에 + 1 보다 inclusive() 사용했을 것입니다. + 1 초등학교 때부터 짧고 타이핑하기 쉬웠고, 경험이 부족한 필자는 덧셈이 오버플로를 일으키는 것이 걱정되지 않는 Python 및 JavaScript와 같은 언어로 작업하는 데 익숙합니다.

편집: ...그리고 우리가 초점을 맞춰야 한다고 생각하는 포인트 1의 개념적 구별입니다. (즉, "X에서 피벗으로"와 "X에서 끝까지"는 프로그래머의 마음에서 구별되어야 합니다.)

@포르넬
끔찍하다 😄
이 특정한 경우에 범위 시작은 코드를 읽는 사람에게 정말 정말 중요하며, 포괄적/배타적 범위 문제보다 훨씬 더 중요합니다.

@ssokolow +1 를 문제로 만드는 것은 문자 수가 아니라 오버플로 가능성을 처리해야 하는 것 같습니다. 또한 의도를 전달하지도 않으며 우선순위 괄호를 랭글링해야 합니다. 이 모든 것이 문자 수보다 훨씬 더 중요해 보입니다.

오버플로에 대해 모르는 사람은 포함 범위를 만들기 전에 +1 도달할 수 있지만 이는 구문에 의존하지 않는 것 같습니다. ..= 가 하나의 사물이고 inclusive() 가 포함된 범위를 구체적으로 원하는 이유를 배울 수 있는 교육 가능한 순간임을 발견하는 것입니다.

@petrochenkov

나는 여전히 독점적 인 패턴과 포함 범위 (그러나 너무 말도 안되는 것 중 하나) 모두 하락과 괜찮을 것입니다.

이에 대해 왜 그렇게 강하게 느끼는지 설명해 주시겠습니까? 배타적 패턴을 받아들이는 것은 사용자가 0...10 를 표현식으로 기대하게 할 수 있다는 단점이 있을 뿐이라고 생각하지만 그렇게 나쁘지 는 않습니다.

inclusive() 대한 내 문제 중 일부는 이것이 "그냥" 함수라는 점이며 사람들이 Rust 구문 색인으로 이동하여 "range" 또는 "iterator"를 검색한 다음 ROI가 충분하지 않다고 가정하는 것과 같은 일을 할까봐 걱정됩니다. "반복자 보기"를 위해.

("유용한 것을 찾을 기회가 없을 때 교과서를 읽고 싶지 않습니다... 범위를 반복하고 진행 상황으로 돌아가고 싶을 뿐입니다.")

@withoutboats 인클루 시브(a...b)가 있지만 경기에서 사용할 수 없다면 IMO의 가치가 없습니다.
내가 포함 범위를 사용할 때 대부분의 경우 일치 패턴에 있습니다!
그렇다면 왜 ... 제거하고 매치 내부와 외부에서 ..= 사용할 수 없습니까?

@Boscop 제안은 매치에서 ... 를 제거하는 것이 아니라 패턴을 안정적으로 유지하는 것입니다.

@ssokolow 는 .. 섹션의 메모로 꽤 쉽게 해결할 수 있는 것 같습니다.

@withoutboats 하지만 매치에서 ... 를 제거하고 대신 ..= 사용하여 일관성을 유지하는 것은 어떻습니까?
(매치 안팎에서 ..= 가 되도록)

부동 소수점의 숫자 범위 적용의 경우 배타적 도움이 됩니다. 예를 들어 다음 경계 중 하나는 완전히 포함되지만 다른 경계는 포함되지 않습니다.

match x {
    0.0...3.141592653589792 => 1,
    3.141592653589793...6.283185307179585 => 2,
    6.283185307179586...10.0 => 3,
    _ => 4,
}

그리고 겹침으로 작성하는 것은 오히려 기분이 나쁩니다(위의 "팔이 주문되기 때문에 -∞에서 모든 것을 시작하십시오"와 도덕적으로 유사합니다). 하루가 [00:00, 23:59:59]가 아니라 [00:00, 24:00)이기 때문에 ISO8601이 T24:00을 허용하는 방법과 같은 날짜/시간도 참조하십시오. 또는 문자열, 또는 합리성, 또는 ...

배타적이거나 포함만 선택할 수 있는 경우에는 매번 배타적 조치를 취하겠습니다.

(제외: 인덱싱을 위한 1 <= x <= N 패턴은 실제로 0 < x <= N 로 수행하는 것이 더 낫습니다. 또한 Dijkstra가 말한 것과 같은 이유로 배타적입니다. 0 기반 대신 1 기반 인덱싱으로 전환되었습니다.)

이 연산자는 https://github.com/rust-lang/rfcs/pull/1961에서 내가 제안한 클램프 기능에 매우 도움이 되었을 것입니다. 그러나 이것이 안정화되지 않았기 때문에 아마도 그 제안을 다음과 같이 수정해야 할 것입니다. 대신 두 개의 최소 및 최대 인수를 사용하십시오. InclusiveRange는 부동 소수점 값으로 작업할 때도 매우 유용하므로 다음과 같은 작업을 수행할 필요가 없습니다.

0.0..1.0+엡실론

그것이 맞는지 확실하지 않지만 지금은 부동 소수점 숫자의 포괄적인 범위를 선언하는 것이 매우 어렵습니다.

이를 수행하는 올바른 방법은 엡실론이 아닌 nextafter 를 사용하는 것입니다. 즉 x...y == x..nextafter(y) . ieee754 크레이트는 이러한 기능을 노출

이런, inclusive(a..b) 구문에 대해 언급했지만 사실이 아니라는 것을 깨달았습니다. 어쨌든, 나는 그것을 좋아하지만 우리가 더 나은 이름을 자전거로 탈 수 있기를 바랍니다.

@durka 이름이 분명해 보입니다. 이에 대한 우려 사항을 자세히 설명해 주시겠습니까?

그래서 포괄적 인 범위를 위해 우리가해야합니다 a ... b 에서 match 및 inclusive(a..b) 일치의 외부?
왜 우리는 일관성이 없고 어디에나 a ..= b 가질 수 없습니까?

ops::{RangeInclusive, RangeToInclusive} 이 공식적으로 안정화되는 것을 방해하는 것이 있습니까?

현재 가장 큰 장애물은 구문에 대한 논쟁인 것 같습니다. 비록 그 논쟁에 관계없이 최종 구문이 무엇인지에 관계없이 포괄적인 범위가 존재할 것이라고 확신합니다.

안정적인 라이브러리를 구현하기 위해 이러한 유형을 사용하는 것이 좋으며 이러한 라이브러리의 소비자는 특수 구문을 사용하려는 경우 기능 플래그를 활성화하기로 결정할 수 있습니다.

다른 날 RangeInclusive 에 대해 알게 된 한 가지는 범위를 허용하려고 하면 코드를 작성하는 데 어려움이 있다는 것입니다. 클램프 스레드는 .clamp(1...9) 허용에 대해 이야기했지만 코드는 다음과 같이 보입니다.

    fn clamp(self, r: RangeInclusive<Self>) -> Self where Self : Sized {
        match r {
            RangeInclusive::Empty { .. } =>
                panic!("Cannot clamp to an empty range"),
            RangeInclusive::NonEmpty { start, end } => {
                assert!(start <= end, "Cannot clamp to a degenerate range");
                if self < start { start }
                else if self > end { end }
                else { self }
            }
        }
    }

RangeInclusive::Empty 를 처리해야 하는 것은 목표가 멋진 구문으로 쌍을 받아들이는 것이기 때문에 불필요하다고 느낍니다. 열거형이 아니면 fn clamp(self, RangeInclusive { start, end }: RangeInclusive<Self>) 가 될 수 있고 훨씬 더 깨끗할 수 있습니다.

불행히도 나는 그것에 대해 무엇을 해야 하는지에 대한 좋은 답을 가지고 있지 않습니다. 왜냐하면 .into_iter() 를 포함하지만 배타적이지 않게 요구하는 것도 불행할 것이기 때문입니다...

무작위 아이디어: ... 패턴 구문이 포함 범위 유형과 실제로 관련이 없는지 확인하면 여기에서 제안된 ... 와 관련이 없는 구문을 사용하여 구문을 폐기하는 것을 고려할 수 있습니다.

포함 범위 패턴은 | 패턴과 더 밀접하게 관련되어 있으므로 |... 가 좋은 후보가 될 수 있습니다.

match {
    1 | 2 | 3 => ...
    1 |... 3  => ...
}

최종 결과는 포괄적이고 배타적인 범위 구문이 더 이상 패턴 일치와 1:1 관계가 없으므로 일치할 필요가 없다는 것입니다.

@scottmcm

불행히도 나는 그것에 대해 무엇을 해야 하는지에 대한 좋은 답을 가지고 있지 않습니다. 왜냐하면 .into_iter() 를 포함하지만 배타적이지 않게 요구하는 것도 불행할 것이기 때문입니다...

빈 범위에 대해 당황하고 쌍을 반환하는 range.nonempty() 와 같은 도우미를 추가할 수 있습니까?

또한 우리는 구현할 수 IntoIterator 에 대해 RangeInclusive 그리고 그것은 너무 멀리 이럴 해제하지 않을 것입니다.

RangeInclusive::Empty는 어떤 사용 사례를 제공합니까? 포함 범위에 빈 범위를 나타내는 기능이 필요한 이유는 무엇입니까? 어떻게 작성하시겠습니까? (이미 "5에서 4까지의 범위"와 같은 것을 작성할 수 있다는 점에 유의하십시오. 이 반복은 아마도 비어 있는 것으로 취급할 것입니다.)

@joshtriplett 주요 사례는 오버플로이지만 해당 문제를 해결하는 방법이 있습니다.

@joshtriplett start > end 실제로 0u8...255u8 라는 중요한 경우에서 빈 포함 범위를 나타내는 데 작동하지 않습니다. 당신이 도착하면 255u8...255u8 와 시도 .next() 를, 당신도 패닉을 얻거나 바꿈 것 0u8...255u8 비어 있지 않습니다. 따라서 대신 그 시점에서 Empty 변형으로 전환합니다.

@solson 아, 하나입니다.

(나는 당신이 모든 경우에 255u8 를 의미한다고 가정합니다.)

(나는 당신이 그 모든 경우에 255u8을 의미한다고 가정합니다.)

네, 고마워요. 수정됨.

@solson 그러나 이 경우 0과 255를 교환하여 수정할 수 있습니다.

@clarcharr 사실입니다. .next() 항상 Empty 범위의 생성을 특수 케이스해야 하므로 항상 비어 있는 것으로 처리되는 범위를 생성할 수 있습니다.

개인적으로 나는 그것이 빈 범위를 포함하지 않기 때문에 더 나은 방법을 좋아합니다.

그래서 이 스레드는 1년 반 동안 계속되었습니다. 방금 모든 내용을 다 읽었으며 신규 사용자를 위한 간략한 요약을 게시하고 우리가 결정을 내리는 데 도움이 되었으면 합니다.

오늘날 Rust Stable이 하는 일:

0..5 는 패턴 일치에 사용할 수 없는 반개방 범위 [0, 1, 2, 3, 4]를 나타냅니다.
0...5 는 패턴 일치에서만 사용할 수 있는 닫힌 범위 [0, 1, 2, 3, 4, 5]를 나타냅니다.

패턴 일치 외부에서 사용할 수 있는 추가 폐쇄 범위 구문에 대해 여러 형식이 제안되었습니다. 나는 각각의 장점과 단점을 다룰 것입니다.

0...5

장점: 기존 패턴 일치 구문과 일치하여 패턴 일치 구문에 변경 사항이 없다고 가정할 때 언어를 더 응집력 있게 만듭니다.

단점: 잘못 입력하고 하나의 오류로 인해 발생하기 쉽고, 다른 개념을 전달하기 위해 이 연산자를 사용하는 다른 언어로 인해 의도를 오해하기 쉽습니다.

0..=5

장점: 잘못 입력하기가 더 어렵고 의미적으로 더 명확합니다.

단점: 기존 패턴 일치 구문과 일치하지 않습니다. 사용자가 묻게 할 수 있습니다. 여기가 ... 여기지만 ..= 여기에 있는 이유는 무엇입니까?

0..^5

..= 와 매우 유사하지만 지수 연산자처럼 보인다는 추가 단점이 있습니다.

inclusive(0..5)

장점: 의미상 매우 명확합니다. 잘못 입력되지 않습니다.

단점: 좀 길다. 또한 패턴 일치 구문과 일치하지 않습니다.

0....5

장점: ... 의 오타 문제도 방지합니다.

단점: 의미 체계가 좋지 않고 패턴 일치 구문과 일치하지 않으며 패턴 일치 구문과 유사합니다.

[0..5] 수 없습니다. 대괄호는 이미 언어에서 구문론적 의미를 가지고 있습니다.

0..<=5 수 없습니다. 값을 범위와 비교하는 기존 구문과 충돌합니다.

"패턴 일치 구문과 일치하지 않음"이라는 단점이 있는 나열된 모든 옵션은 패턴 일치 구문을 변경하면 개선될 수 있지만 해당 경로에는 이전 버전과의 호환성 문제가 있습니다. 또는 ... 및 (여기서 구문 선택)을 패턴 일치 내에서 동등하게 만들 수도 있습니다. 그러면 하위 호환성이 깨지는 것을 방지할 수 있지만 패턴 일치 외부에서 ... 사용하는 것은 방지할 수 있습니다. 아마도 스타일 가이드를 업데이트하여 해당 경로를 따라갈 경우 패턴 일치에서 ... 를 사용하지 않도록 할 수도 있습니다.

또한 상한과 하한을 모두 포함하거나 배타적으로 만들 수 있는 보다 일반적인 목적의 범위 구문을 만드는 것에 대한 논의가 있었지만 반개방 및 폐쇄 범위가 포함될 가능성이 있으므로 해당 구문이 필요하지 않을 수도 있습니다. 사용 사례의 99.9999%.

나는 이 토론을 최대한 표현하려고 노력했습니다. 내가 요점을 적절하게 표현하지 못했다고 생각되면 알려주시면 업데이트하겠습니다.

@Xaerox 훌륭한 요약에 감사드립니다.

소스가 ... 패턴 일치에서 새 구문(예: ..= )으로 결정되면 자동으로 변환하는 도구(rustfmt 플러그인일 수 있음)가 있을 수 있습니다.
그렇게 하면 "예전 방식으로 작성된 모든 코드"에 의해 보류되지 않습니다.
그러나 프로젝트 작성자의 의도에 따라 호출해야 하며 모든 녹 매체에 알림/헤드라인이 있어야 모든 사람이 변경 사항을 알 수 있습니다.
그런 것들을 가지고 새로운 구문에 일치하는 패턴에서 ... 구문을 변경하는 것은 문제가 되지 않는다고 생각합니다.

구문 문제를 해결하기 위해 할 수 있는 한 가지는 @clarcharr이 제안한 대로 생각 합니다. 이것은 최소한 사람들을 차단 해제합니다.

inclusive 함수를 추가할 수도 있습니다( std::range 또는 전주곡에도 가능). 이것은 언젠가 일류 구문을 갖는 것을 배제하지는 않지만 지금 RangeInclusive를 구성하는 것이 훨씬 더 편리합니다.

그러나 이것들은 모두 libs 결정처럼 보이기 때문에 lang 팀이 이러한 항목을 안정화/추가하기로 결정할 관할권이 있는지 모르겠습니다.

나는 개인적으로 변환하는 것을 선호 RangeInclusive 이없는 무언가에 자체 Empty 변형을 후하게 IntoIter 변형있다. 수동으로 Empty { at } 없이 빈 범위를 구성하는 것이 본질적으로 불가능하다는 것을 고려하는 것이 더 합리적입니다.

또는 내가 언급한 한 가지 경우에서 MAX 와 MIN 를 교환하십시오. 이는 RangeInclusive 와 관련된 보다 일반적인 코드를 작성하는 것을 어렵게 만들지만 문제에 대한 합리적인 해결책처럼 보입니다.

무슨 일이 일어나든 저는 구문 문제와 상관없이 존재할 표준 라이브러리의 유형을 안정화하는 것을 매우 지지합니다. 이를 통해 라이브러리는 포괄적인 범위로 슬라이싱할 수 있는 안정적인 코드를 작성할 수 있으므로 구문이 안정화될 때 사람들은 이미 유형을 사용하는 코드를 구현했습니다. 이유 때문에 구문 및 유형이 다른 기능 플래그 아래에 있습니다.

@scottmcm 이 시점에서 아마도 별도의 스레드여야 한다는 데 동의합니다.

구문 토론을 계속 진행하기 위해 내가 선호하는 경로를 제공할 것입니다.

저는 ..= 구문을 가장 좋아하므로 이 구문 설탕을 패턴 일치에서 ... 와 동일하고 패턴 일치 외부에서 InclusiveRange로 추가해야 한다고 생각합니다. 그런 다음 언어를 일관되게 유지하기 위해 공지 및 자동화된 도구를 사용하여 패턴의 ..= 구문으로 사용자와 코드를 마이그레이션하려고 시도해야 합니다. ... 에서 충분한 사용자를 마이그레이션했다고 생각되면 컴파일러 경고를 사용하고 결국(지금부터 몇 년 후에도) 컴파일러 오류를 사용할 수 있습니다.

내 제안이 제공된 지 24일이 지났지만 아무런 코멘트도 제공되지 않았습니다. 그 계획을 계속 진행해야 합니까?

편집 : 모바일에서 나는 엄지 손가락을 보지 못했기 때문에 반대 의견이 있다는 것을 깨닫지 못했습니다.

@Xaerox 저는 그렇게 생각하지 않습니다. 나는 비하하는 것을 동의하지 않는 ... 찬성 ..= 이미이 스레드에 게시 한 이유에 대한 좋은 선택입니다. 같은 아이디어가 이미 제시되고 논의되었기 때문에 귀하의 구체적인 제안에 답변하지 않았습니다. 여기서 분명한 것은 우리가 합의를 이루지 못했다는 것뿐입니다. 많은 분들이 토론으로 인해 피로감을 느끼셨을 거라 생각합니다.

편집이 : 더 구체적를하기 위해, 내가 더 이상 사용하지 않으려는 ... 찬성 ..= 이유는

• 구문을 사용하지 않는 것은 이탈에 막대한 비용이 듭니다. 내가 단호하게 ..= 좋아하더라도 안정에서 포괄적인 범위 표현식을 얻는 것만으로는 사용 중단 주기의 가치가 있다고 생각하지 않습니다.
• ..= 마음에 들지 않습니다 . 명확하지 않고 불분명합니다. 하나의 오류로 인해 오류가 발생할 가능성이 적다는 장점이 있지만 사용자가 처음으로 보고 있는 내용을 알 수 있다는 의미는 아닙니다.
• 나는 유사한 구조화/해체화 작업을 하지 않기 때문에 패턴과 표현식 사이에 대칭이 필요하다는 전제에 동의하지 않습니다.

(이 댓글을 작성하는 동안 관점이 약간 바뀌었습니다. 다른 사람들이 내 생각 과정과 내가 내린 결론에 도달한 이유를 볼 수 있도록 모든 것을 그대로 두기로 결정했습니다.)

그러한 경험이 없기 때문에 사용 중단 비용에 대해 언급할 수 없습니다. 그러나 나는 여전히 ..= 합니다.

특정 시점에서 우리는 사용자에게 무언가를 배우도록 기꺼이 요청해야 한다고 생각합니다. 프로그래밍 전체는 배워야 할 부분이며, 일반적으로 전문화된 구문은 항상 의미론에 약간의 비용이 듭니다. 나는 사람들이 언뜻 보기에 구문을 인식할 것이라고 기대하지 않습니다. .. 도 이와 관련하여 나쁘지 않습니다.

그러나 특수 구문이 너무 많으면 언어가 Rust가 원하는 것보다 더 브레인퍽에 가깝게 보일 수 있습니다. 따라서 우리는 특별한 구문으로 변환하기로 선택한 경우가 실제로 가치가 있을 만큼 충분히 일반적이라는 점에 주의해야 합니다. 솔직히 말해서 지금 내가 이것을 타이핑한 지금 나는 이 케이스가 그만한 가치가 있는지 완전히 확신하지 못합니다. 포괄적인 범위의 필요성은 구문을 보증할 만큼 높지 않습니다.

그러나 불일치는 여전히 나를 괴롭힌다. 포괄적인 기능과 패턴 일치에 ... 가 있다는 것은 영어에서 회색과 회색이 모두 있는 것처럼 느껴집니다. 표준화할 기회가 있을 때 제 일부가 그렇게 해야 한다고 느낍니다. 그러나 그러한 변경을 수행하는 데에는 실제 물류 문제도 있습니다. 우리가 Rust 2.0을 디자인하게 된다면(미친 짓일지도 모릅니다. 저는 잘 모르겠습니다) 아마도 이것을 다시 살펴봐야 할 것입니다.

저는 현재 패턴 매칭 외부의 인스턴스에 inclusive 함수를 사용하고 패턴 매칭에 ... 를 사용하는 것을 지원합니다.

@withoutboats

1. 더 이상 사용하지 않는 경우 C++와 같은 모든(다소) 잘못된 결정의 조합으로 끝납니다. 이것은 상황이 가능한 한 일관성이 없기 때문에 초보자가 더 많이 배우도록 강요합니다.
   따라서 때로는 더 나은 솔루션을 제공하기 위해 더 이상 사용하지 않는 것이 좋습니다.

2. 그렇다고 해서 사용자가 처음 보는 것이 무엇을 보고 있는지 알 수 있다는 의미는 아닙니다.

이것은 모든 구문의 경우입니다. 우리(Rust를 아는)는 Rust 코드가 명백해 보이지만 다른 언어에서 Rust로 오는 사람은 누구나 구문을 자주 검색해야 하기 때문에 이러한 편견을 가지고 있습니다. ..= 또는 ... 또는 포함 범위에 대한 다른 구문을 사용하는 경우 변경되지 않습니다. 예를 들어 다른 언어는 배타적 범위에 대해 ... 를 사용하므로 어쨌든 검색해야 하기 때문입니다. .
명백한 기능만 소개하는 것이 우리의 목표가 되어서는 안 됩니다.
명백해 보이는 기능만 갖고 싶다면 Rust에 있는 기존 기능의 대부분을 가질 수 없습니다. 초보자 어쨌든 문서 봐야 무슨 일이 그것에 대해 너무 잘못? 박사님 좋습니다!

1. 
   초보자가 문서를 봐야 하는 시간을 최소화하는 데 관심이 있다면 구성과 포함 범위 일치 간의 대칭을 위해 노력해야 합니다! (및 기타 구성)

@withoutboats가 말했듯이 우리 중 많은 사람들이 이 토론에 지쳤습니다. 나는 잠시 동안 그것을 밖으로 앉혀 왔습니다. 즉, 나는 다시 읽고(요약 @Xaerox에 감사드립니다!) 여기에서 내 생각을 다시 방문하는 데 시간이 걸렸습니다.

IMO, 지금 가장 중요한 문제는 우리가 제공하는 구문의 불완전한 조합입니다 . 패턴의 경우 .. ... , 표현식의 경우 .. 입니다. 이 구문 쌍은 .. 가 패턴에서 작동하고 ... 가 표현식에서 작동할 것이라고 예상하도록 강력하게 유도합니다. 그러나 실제로는 그렇지 않습니다. 나는 이것이 장기적으로 지속 가능한 디자인이 아니라고 생각하고 정말로 수정하고 싶습니다.

또한 두 종류의 범위에 대한 구문을 제공했기 때문에 계속 제공하는 것이 가장 좋을 것이라고 생각합니다. 그러면 다음과 같은 몇 가지 옵션이 제공됩니다.

• 표현식에서 ... 를 안정화하고 패턴에 .. 를 추가합니다. 이것은 가장 고통스러운 변경 사항이지만, 개별 오류와 관련하여 잘 논의된 단점이 있습니다. 그러나 다른 언어에는 이러한 조합이 있으며 내가 아는 한 그러한 오류로 인해 심각한 고통을 겪지 않았습니다.

• 비추천 ... 패턴과 표현에 추가 ..= 모두하고, 추가 .. 패턴. 위의 단점을 해결하고 더 고통스럽고(지원 중단으로 인해) 미래에 다른 종류의 범위(예: 왼쪽 독점)에 대한 문을 엽니다.

이 시점에서 나는 주로 토론을 다시 하고 있으며 솔직히 말해서 이 시점에서 더 이상 할 말이 없다고 생각합니다. 나는 우리가 절충점을 드러냈고 평가를 수행하고 결정에 도달하기 위해 lang 팀이 필요하다고 생각합니다. 그러나 내 의견의 주요 요점은 여기에서 뭔가 변경해야 한다고 생각하는 이유(그리고 inclusive 추가하는 것만으로는 충분하지 않은 이유, IMO)에 대한 초기 요점입니다.

그러나 다른 언어에는 이러한 조합이 있으며 내가 아는 한 그러한 오류로 인해 심각한 고통을 겪지 않았습니다.

여기에서 선택 편향이 걱정됩니다. 문제가 경미한지 또는 우리의 주의를 거의 끌지 못하는지 여부를 판단할 신뢰할 수 있는 방법이 없습니다.

또한, ... 를 사용하는 것은 Rust의 디자인 철학과 새로운 모범 사례의 "상충 관계가 너무 심각하지 않은 한 발총을 피하십시오"라는 측면에 위배되는 것처럼 느껴집니다. (예: bool 사용하는 것보다 새로운 enum 유형을 생성하여 함수 매개변수를 혼합하는 것이 더 어렵습니다.)

예를 들어, C는 언어에 while let 가 없는 경우 if 문에 대입하는 것이 유용하다는 것을 증명했지만 == 을 의미할 때 = 를 입력하는 것으로 인식되었습니다. == 는 유일한 대안이 비특이하게 못생긴 상황이 존재하는 경우에도 Python과 같은 언어가 이를 거부하는 족쇄로 충분합니다.

다른 방향으로 가보면 실제로 일주일 전쯤 코딩에 지쳤을 때 Clippy가 이런 경우를 잡았습니다.

foo == bar;  // This should be `foo = bar;`

...여기서 걱정되는 "키를 너무 많이 눌렀다" 실수의 완벽한 예인 것 같습니다... 그리고 " == 는 효과가 없습니다"와 달리 .. 대 ... 대해 보푸라기 처리하는 좋은 방법이 없습니다.

@ssokolow ..= 도 괜찮습니다. 사용 중단이 그렇게 고통스러울 것이라고 생각하지 않으며 매우 쉬운 자동 수정입니다. 대부분 이 문제를 해결하고 싶습니다.

나는 아마 .. / ... (이미 야간에 구현됨) 안정화로 살 수 있습니다. 나는 존재하는 언어가 이것이 작동할 것이라고 제안하는 @aturon에 동의합니다.

내가 말했듯이, 나는 Rust-lang/rfcs#1980이 구문 논의 없이 통과할 때 libstd 유형을 안정화하고 싶습니다.

@aturon이 지적한 것과 함께 이 구문과 배타적 범위 구문 모두에 대한 추적 문제를 병합하는 것이 유용할 수 있습니까? 아마도 유형에 대해 별도의 추적 문제를 만들고 구문 전에 유형을 안정화하는 데 사용하십시오.

나는 lang 팀 토론을 위해 다시 지명하고 있습니다. 이 시점에서 상당히 새로운 아이디어나 절충안이 발생할 가능성은 거의 없다고 생각합니다. 우리는 제시된 트레이드오프에 대한 결정을 내려야 합니다.

2017년 5월 18일 오전 9:55:30 PDT, Aaron Turon [email protected] 은 다음과 같이 썼습니다.

나는 lang 팀 토론을 위해 다시 지명하고 있습니다. 나는 그것이 매우 가능성이 없다고 생각한다.
이 시점에서 상당히 새로운 아이디어나 절충안이 발생하게 될 것입니다.
가리키다. 우리는 지금까지의 트레이드오프에 대한 결정을 내려야 합니다.
배치.

다음 주 회의 때문에 회의에 나가려고 합니다. 경우 이것은 다음 주 회의에서 논의됩니다, 내가 아닌 다른 솔루션에 대한 내 지원을 음성 것이다 ... 여부, ..= , inclusive , 또는 기타.

우리가 거기에 있는 동안 rest/spread 구문에 대해 논의할 가치가 있습니다.
나는 단독 범위에 .. , 포괄적 범위에 ... , 휴식/확산에 .... 에 투표합니다.

take_range(..max); // exclusive range
take_range(...max); // inclusive range
take_multiple_args(....tuple); // spread
if let 0..10 = get_num() {} // exclusive range pattern
if let 0...9 = get_num() {} // inclusive range pattern
if let [first, ....rest] = get_slice() {} // rest pattern

저는 다음 두 가지 이유로 나머지 슬라이스에 대해 ... 에 투표합니다.

1. 사람들은 이미 가능성에 익숙 ... 커피 스크립트와 같은 언어에서 "휴식"을 의미한다 (커피 스크립트가 사용 rest... 가변 인자와 통화를 "표시가"에 대한 기능 서명에)와 영어 (올바른 유니 코드를 사용하여 코드 포인트 여부에 관계없이 마침표 4개가 아니라 생략 기호처럼 보이는 세 개의 마침표입니다. 사람들은 줄임표를 영어로 "더 많이 있지만 큰 소리로 말하는 것이 아닙니다"를 대략적으로 의미하는 줄임표를 제대로 이해하고 있습니다. 사용.)

2. 내가 Rust의 구문에 대해 뭔가를 놓치고 있지 않는 한, 범위에는 .. 및 ..= 를 사용하지만 나머지 슬라이스에는 ... 를 사용하면 모든 상황에서 ... 입력한다는 의미입니다 .. 를 의미하거나 그 반대의 경우 여전히 컴파일 타임 오류입니다.

   이를 위해 저는 두 가지 가정을 하고 있습니다.

   1. 나머지 구문만 사용하는 것은(시퀀스 압축 해제 컨텍스트 외부에서) 오타가 발생하기 쉬운 no-op으로 허용되지 않습니다. (예: for _ in ...rest 는 허용되는 경우 for _ in rest 와 동일하지만 오타가 거의 확실합니다.

   2. 할당할 패턴으로 개방형 범위를 사용하는 것은 유효하지 않습니다. (예: let [first, ..rest] = 는 유효하지 않습니다.)

@ssokolow 삼중 점은 이미 패턴의 범위를 의미하므로 나머지 구문으로 변경하는 주요 변경 사항이 될 것입니다.

@phaux 포인트. 어떤 이유에서인지 잊어버렸습니다.

"만약 우리가 Rust 2.0을 만든다면" 태그를 끊을 수도 있습니다.

삼중 점은 이미 패턴의 범위를 의미하므로 나머지 구문으로 변경하는 주요 변경 사항이 될 것입니다.

그러나 패턴의 ... 는 양쪽에 표현식이 있어야 한다고 생각합니다( a...b ). 반면 나머지 구문은 ... 를 접두사로 사용합니다. 아니요?

lang 팀은 오늘 회의에서 이 기능에 대해 다시 논의했고 대략 다음과 같은 매트릭스에 도달했습니다.

• 패턴에서 ... 를 지원하고 표현식에서 .. 하는 것은 지지할 수 없는 디자인입니다. 그것은 사용자가 구문이 작동하지 않을 것이라고 기대하게 만듭니다.

• ... 및 .. 를 두 위치에 모두 허용하면 도움이 되지만 개별 문제는 실제 문제입니다. 우리 중 누구도 잘못된 기간을 추적하는 데 시간을 보내는 사람들에 대한 보고를 받고 싶어하지 않습니다.

• ..= 및 .. 것은 미학적으로 덜 매력적이지만 위의 실제 적인 실제 문제를 피할 수 있습니다. 아주 부드러운 방식으로 롤아웃할 수도 있습니다. 먼저 ..= 를 대안 구문으로 도입하고(rustfmt 가 다시 작성할 수 있음), 관용적이 된 후에만 ... 사용하지 않습니다.

말할 수 없는 경우를 대비하여 팀은 ..= 및 .. 가 우리의 최선의 길이라고 생각합니다. 이 문제는 또한 새로운 주장이 제기될 가능성이 매우 낮다는 점에서 논의되었습니다. 그래서 우리는 뛰어들 준비가 되었습니다. 우리는 두 가지 모두에 대해 ..= 표기법을 구현하고자 하는 사람을 찾고 있습니다. 패턴과 표현, 그리고 이어서 우리는 FCP로 갈 것입니다!

이를 위해 우리는 구현을 추진할 누군가(또는 일부 사람들)를 찾고 있습니다. 아마도 이것은 더 작은 PR에서 수행될 수 있습니다.

• 시작하려면 ..= 를 ... 의 별칭으로 파서에 추가하고 기존 테스트를 변환해 보겠습니다.
  
  
  
  • ... 는 물론 계속 작동해야 하며 이것이 "자동" 사용 중단되기를 원하므로 (아직) 경고 등을 발행할 필요가 없습니다.
  
  
  • 따라서 ... 패턴에 대한 테스트를 유지해야 합니다.
  
  
  • 아마이 작업을 수행하는 방법을 생각하는 수정하는 것입니다 렉서를 추가하여 DotDotEquals 토큰 ( 여기에 기존 DotDotDot ) 다음 수정 파서을 받아 DotDotEquals 모든 곳에서 우리 이제 DotDotDot 수락( 예시 )
  
  
  • ripgrep DotDotDot 는 여기 당신의 친구입니다 ;)
  
  
• 표현식의 ... 는 결코 안정적이지 않으므로 ..= 하고 이전 지원을 종료할 수 있습니다.
  
  
  
  • 야생의 사람들에게 친절하기 위해 사용 중단 기간을 거칠 수 있지만 꼭 필요한지 잘 모르겠습니다(생각?)
  
  

참고로 구현할 때 extern fn foo(a: u32, ...) 구문 을 ..= 로 변경해서는 안 됩니다 😆

코드에 대한 멋진 첫 번째 단계처럼 보이기 때문에 받아보고 싶지만 앞으로 2주 동안 시간이 많지 않을 것이므로 누구든지 받아보고 싶다면 부담 없이 이용하세요!

나는 찬성 개인적으로 더 해요 ..^ 이상 ..= 로, a operator= b 일부 사업자, 이미 별칭입니다 a = a operator b . 반면에 ^ 는 XOR에 대해서만 훨씬 적게 사용되므로 혼동을 덜 일으킬 것입니다.

.. 은 이에 대한 왼쪽 및 오른쪽 피연산자의 유형과 다른 유형을 생성하므로 ..= 에 대한 문제가 되지 않습니다. 컨텍스트는 또한 연산자의 목적을 식별하는 데 도움이 됩니다. += 는 () 반환하므로 일반적으로 자체 줄에 자체 명령문으로 나타날 수 있습니다. 반면 ..= 는 InclusiveRange를 반환하므로 다른 명령어 내에서 표현식으로 나타납니다. 또한 위에서 언급했듯이 ..^ 는 범위보다 지수와 더 관련이 있는 것처럼 보입니다.

@Xaeroxe ^ 는 Rust에서 지수와 아무 관련이 없습니다(비록 다른 언어에서도 그렇게 사용됨). 반면 += , -= , *= 모두 Rust에 존재합니다. 실제로 ^= 존재합니다.

하지만 ..= 있으면 좋습니다.

#42134가 병합되었으므로 이제 라이브러리 구조체를 안정화하기 위해 이동할 수 있습니까? 앞서 말했듯이 구조체를 더 빨리 안정화하는 것이 도움이 되지만 안정화하기 전에 구문이 안정화될 때까지 기다려야 한다고 생각합니다.

@clarcharr 저는 우리가 ..= 구문뿐만 아니라 해당 구조를 안정화하기로 결정했다고 믿습니다. 그래서 실제로 그렇게 하려면 약간의 PR만 있으면 됩니다.

편집 : 웁스 내가 틀렸다. 컴파일러에서 구현 중이며 구문 안정화는 최종 주석 기간이 경과할 때까지 기다려야 합니다. 이 시점에서 구조를 안정화해야 한다고 생각하지만 그것도 제가 결정할 문제가 아닙니다.

나는 ... 가 합의를 이루는 것처럼 보였을 때 오래 전에 주제를 따라가는 것을 중단했습니다. ..= 는 언뜻 보기에 애교처럼 보이기 때문에 어색해 보입니다.

하지만 훨씬 더 중요한 것은 이 자전거 셰딩이 현재 패턴 구문을 변경할 만큼 중요하지 않다는 것입니다.

이 구문은 짜증나!
=는 +=, -=, *= 모델에서도 할당의 의미가 있지만 ..=는 무언가를 얻는 것입니다. 너무 혼란스럽고 추합니다.
배열 인덱스가 0에서 시작하는 것처럼 '...'는 좋고 아름답습니다. 사람들은 그것에 익숙해질 것입니다.

@zensai
..= 는 개념적으로 == 및 <= 와 같은 연산자에서 파생되며 이미 Rust에 존재하며 할당이 아닌 동등 비교를 나타냅니다.

(예: 1..=5 는 "Range over values 1 <= x <= 5 "의 약어이며 1..5 는 "Range over values 1 <= x < 5 "를 의미합니다.

편집: 또한 "익숙해지는" 문제가 아니라 피곤하거나 산만할 때 잘못 읽거나 잘못 입력하기가 더 어려운 문제입니다. 이와 같은 개별 오류는 발총으로 유명합니다.

이미 .. 의미할 때 실수로 ... 입력했습니다. 고맙게도 저는 항상 안정적인 Rust를 대상으로 하므로 컴파일러가 이를 포착했습니다. (단, 논픽션 글을 많이 쓰는 편이라 유사 생략 부호를 입력하고 싶다는 가정하에 근육경련인지 근육기억인지 기억이 나지 않습니다.)

@zengsai ... 너무 미묘하고 .. 와 너무 비슷해 보입니다.

언어가 다른 것을 의미하는 다른 수의 점을 갖는 것은 정말 비정상적일 것입니다.

미학적으로 어필하는 것보다 발 총을 제거하는 것이 더 중요합니다.

신규 사용자: 스레드가 매우 길기 때문에 TL;DR을 만들었습니다. 여기에서 읽을 수 있습니다: https://github.com/rust-lang/rust/issues/28237#issuecomment -296310123

" 이와 같은 개별 오류는 발총으로 유명합니다."라고 말하면서 오타 문제가 이 변경의 주요 원인으로 사용되어서는 안 된다고 말해야 합니다.

이 비교, ".." 및 "..." 대 "=" 및 "=="를 보십시오. 사용자의 오타 문제를 피하기 위해 "=="에 대한 다른 구문을 찾아야 한다는 의미입니까? "=" 및 "=="가 괜찮다면 왜 ".." 및 "..."는 할 수 없습니까?

나는 2년 이상 Rust-lang을 팔로우하고 있습니다. ant 그것은 내 개인 프로젝트의 많은 부분에서 사용되었습니다. 나는 그것을 좋아하지만 이 구문은 정말로 나를 불편하게 만듭니다. 미학적으로 매력적일 뿐만 아니라 코드의 쓰기 및 읽기 유창함에도 영향을 미칩니다.

@zengsai 그것은 주로 코드를 _작성_할 때가 아니라 코드를 검토하고 읽고 이해할 때라는 것을 이해했습니다. 찾고 있지 않다면 .. vs. ... 놓칠 수 있지만 ..= 확실히 더 눈에 띄고 이겼습니다. 이 문제가 없습니다.

미학적인 관점에서 내가 ..= 구문을 좋아하는지 확신할 수 없지만 .. 및 ... 대해 매우 비슷하게 읽고 있는 모든 사람이 어디에서 오는지 알 수 있습니다.

@zengsai = 대 == 에는 .. 대 ... 사용할 수 없는 솔루션이 있기 때문입니다.

물론, C에서 = 와 == 를 혼동할 수 있습니다... 그러나 이것은 인정된 발자취이며 Python 및 Rust와 같은 보다 현대적인 언어는 다음과 같이 해결했습니다.

1. 사용자가 입력하는 경우 오류의 if x = y 보다는 if x == y (이 녹과 파이썬이 만든 수정입니다)
2. 실수로 입력하면 x == y; 보다는 x = y; , 나는 아무런 영향을 미치지 않습니다 표현에 대한 경고를 받았습니다.

컴파일러가 .. 대 ... 혼동이 잘못된 것은 고사하고 비정상적 이라는 것을 인식할 방법도 없습니다.

@zengsai .. 및 ... 는 동일한 특성을 모두 구현하고 본질적으로 상호 교환 가능하게 사용할 수 있는 유형으로 평가됩니다(이는 의도된 것임 ). 하나의 오류로 인해 벗어나는 것은 매우 실제적인 문제입니다.

나는 또한 이 구문을 싫어한다는 것을 분명히 하고 싶습니다. 그래서 우리가 .. 및 표현식과 ... 를 사용하는 현재 상황이 @aturon 의 의견에 동의하지 않습니다. 패턴은 "유지할 수 없습니다." 사실 이 구문을 사용하는 것보다 연결을 끊는 것이 더 낫다고 생각합니다.

그러나 이 스레드에 대해 새로운 주장이 없으며 적극적으로 투자한 사용자의 대다수(및 나머지 언어 팀)가 이 변경 사항을 선호한다는 점에 대해 결코 합의를 보지 못할 것이 분명합니다. 그래서 문제를 해결할 수 있도록 옆에 서 있습니다.

내 경험상 위안이 된다면 대다수의 사용 사례에서 이 기능이 실제로 필요하지 않으므로 코드 전체에 나타나지 않을 것입니다.

사실, 나는 여전히 패턴에서 ... 를 비추천하는 것에 대해 정말로 불만이 있고, 기본적으로 이 문제를 해결할 수 있도록 이빨을 갈고 있습니다. 전체 lang 팀은 .. 및 ... 표현식이 모두 있는 것이 끔찍한 사마귀가 될 것이라는 데 동의하여 일부 사용자는 완전히 조용한 오타 문제를 디버깅하는 데 몇 시간을 소비하게 됩니다.

나머지 lang 팀은 표현과 패턴 사이에 단절이 있는 것이 용납될 수 없다고 강하게 느끼고 있으며 저는 동의하지 않지만 우리는 모두 주장을 펼쳤고 영원히 교착 상태에 있는 것이 건강하다고 생각하지 않습니다.

@ssokolow 죄송합니다. 아직 동의할 수 없습니다. 컴파일러는 이런 종류의 오타를 경고할 수 있지만 "x=6"이어야 하는 위치에 "x=5"를 입력하면 어떻게 될까요?

컴파일러는 오타를 피하기에 완벽한 것은 아니지만 프로그래머는 그렇습니다.

이 변경에 부작용이 없다면 전적으로 동의합니다. 그러나 이것은 언어의 미적 감각, 쓰기 및 읽기의 유창함을 잃게 하여 내 개인적인 의견으로는 가치가 없습니다.

오늘날의 녹은 이미 읽기 및 쓰기 문제에 직면해 있고, 더 흔하지 않고 직관적이지 않은 구문에 더 많은 학습 곡선이 있으므로 다른 Perl을 만들지 마십시오.

@withoutboats 우리는 그것을 사랑하기 때문에 논쟁합니다. 어쩌면 이 주장은 너무 늦었고 아무것도 바꿀 수 없었습니다. 그냥...

@zensai

분명히 타협해야 할 부분이 있지만, 우리는 그것들 사이의 최상의 균형점에 대해 결코 동의하지 않을 것이라는 인상을 받았습니다.

개인적인 취향에 관계없이 ..= 는 버그를 추적하는 데 낭비되는 매우 많은 시간을 피하기 위해 지불해야 하는 작은 비용이라고 생각합니다.

(제가 중점적으로 다루는 분야는 UI/UX 디자인이며 그들이 가르쳐주는 가장 큰 규칙 중 하나는 실수를 쉽게 저지를 수 있는 피해 및/또는 수정 시간에 반비례하도록 하는 것을 목표로 해야 한다는 것입니다. )

내 작은 의견으로는 5 vs. 6 가 .. vs ... 보다 훨씬 더 명확합니다.

@zengsai 이 대화를 위해 너무 많은 이메일을 받고 있습니다. 당신의 감정을 더 잘 표현하기 위해

@daiheitan 정상적인 통신입니다. 마음에 들지 않으면 이 이메일

Rust를 처음 보았을 때 .. 구문에 대해 정말 놀랐습니다. (1..10).sum() 는... 1에서 9까지의 정수의 합인가요? 이 구문을 새로 온 사람에게 제시하고 그 의미가 무엇인지 묻는다면 그는 1에서 10으로 갈 것으로 예상할 가능성이 매우 높습니다. 그리고 그는 그렇게 하는 것이 옳을 것입니다. 대칭 구문이 대칭을 표현할 것으로 예상하기 때문입니다. 범위. 왜 1은 포함되어야 하지만 10은 포함되지 않아야 합니까?

대칭 범위에 대해 다른 비대칭 형식 ..= 을 추가하면 시각적으로 더 일관성이 없습니다. 왼쪽이 포함되기 위해 = 가 필요하지 않은 이유를 물을 수 있습니다. 따라서 양쪽의 포함 범위에 대해 =..= 가 됩니다.

Swift 구문 ( 단독의 경우 ..< 및 포함의 경우 ... )과 같은 것이 이러한 문제를 방지하고 가독성을 향상시킵니다. 언어를 완전히 처음 접하더라도 쉽게 의미를 정확하게 추측할 수 있으므로 기억해야 할 것이 하나 줄어듭니다. 특히 Rust가 신규 사용자 친화성을 추구하는 것을 고려할 때 이와 같은 것이 선택되기를 기대했을 것입니다.

@rkarp 어느 정도까지는 기존 편견 때문일 것입니다.

예를 들어, Rust에는 많은 Python 영향이 있으며 Python은 같은 종류의 반개방 범위를 사용합니다. (즉, Python의 range(1, 5) 또는 myList[1:5] 둘 다 Rust의 1..5 와 같은 동작을 가짐)

파이썬에서 이에 대한 정당성은 오직 하나의 구문만 있고 반쯤 열린 구문을 사용하면 head, tail = myList[:pivot], mylist[pivot:] 와 같은 작업을 더 쉽게 수행할 수 있다는 점과 관련이 있습니다.

즉, Rust가 1.0을 통과했다는 점을 감안할 때 기존 코드를 깨뜨리지 않는 것에 대한 상당히 엄격한 규칙이 있습니다. .. 패턴 외부 독점 및 ... 독점 내부 패턴은 유효하게 유지되어야 합니다.

..= 는 .. (독점) 및 ..= (포함)를 모든 곳에서 허용하고 ... 를 .. 대한 더 이상 사용되지 않는 동의어로 취급할 수 있기 때문에 작동합니다. 패턴에서.

..= 를 토큰으로 사용하는 것은 매크로의 :tt 규칙에 영향을 미치기 때문에 기술적으로 호환되지 않는 변경 사항입니다. 아마도 문제가 되지는 않겠지만 조용한 변화일 수 있다는 점을 고려하여 누군가 그렇게 하지 않는지 확인하고 싶을 수 있습니다. (대안은 .. /* why not */ = 허용하는 것입니다. 이는 좋은 생각이 아닙니다.)

@ssokolow 엄밀히 a = 2 는 () 를 반환하는 표현식이고 if 는 bool 기대하므로 분명히 호환되지 않습니다.

규칙이 서서히 바뀌고 있습니다. 기술적으로 ..= 는 처음 2개 뒤에 공백이 없는 3개의 토큰입니다.

@eddyb : 나는 그것을 완전히 이해하지 못한다는 것을 인정합니다. :tt 구문 분석 방법에 영향을 주지 않고 새 토큰을 도입하는 방법이 있습니까?

이 코드는 현재 "규칙 2" 및 "규칙 4"를 보고합니다. 이 변경 사항을 올바르게 이해하면 "규칙 2" 및 "규칙 5"로 변경됩니다.

macro_rules! ex {
    ( . . )   => { "Rule 1: . ." };
    ( .. )    => { "Rule 2: .."};
    { . . = } => { "Rule 3: . . = " };
    { .. = }  => { "Rule 4: .. = " };
    { ..= }   => { "Rule 5: ..=" };
}

macro_rules! show {
    ( $($t:tt)* ) => { println!("{}", ex!($($t)*)) };
}

fn main() {
    show!(..);
    show!(..=);
}

아니요, 토큰이 정의되는 방식이 변경되었습니다. @jseyfried 는 결과를 더 잘 설명할 수 있습니다.

기술적으로 이것은 구문 분석 오류가 아니라 Rust의 유형 오류입니다. a = 2는 ()를 반환하는 표현식이며, bool이 필요한 경우 분명히 호환되지 않습니다.

@xfix 감사합니다. 지난번에 오타를 냈을 때 제대로 주의를 기울이지 않았고 여전히 표현 지향 언어로 생각하는 데 완전히 익숙하지 않습니다.

댓글 수정했습니다.

나는 ..= 구문이 마음에 들지 않으며 패턴에서 ... 를 사용하지 않는 것에 반대합니다. 오타 오류가 두려우면 ... 또는 ..= 대신 RangeInclusive { start, end } 구조체를 약어로 사용할 수 있습니다.

내가 방금 깨달은 잠재적인 모호성:

if let 5..=x { ... }

@clarcharr 그래도 컴파일되지 않는 것 같습니다.

rustc 1.17.0 (56124baa9 2017-04-24)
error: unexpected token: `=`
 --> <anon>:3:13
  |
3 |     if let 5..=x {
  |             ^^

error: aborting due to previous error

@clarcharr @kennytm
..= 를 하나의 연산자로 도입하면 오류는 다음과 같습니다.

error: expected one of `::` or `=`, found `{`
 --> <anon>:3:13
  |
3 |     if let 5..=x {
  |                  ^

error: aborting due to previous error

지금처럼 let x=10; if let 5..x {}

따라서 이 "모호성"은 컴파일되지 않으므로 if let 5..x {} 보다 더 모호하지 않습니다.

@Boscop 요점은 현재 5.. 를 Some(5) 와 같은 패턴으로 취급하면 if let 5.. = x 가 let Some(5) = x 와 유사하고 후자가 컴파일된다는 것입니다. 내 의견은 5.. 가 패턴이 아니므 로 ..= 도입에 대한 if let 호환성 위험이 없음을 보여줍니다.

이 기능을 도입하고 패턴에서 ..= 및 .. 를 모두 허용하면 if let 5..=x 는 항상 if let 5.. = x 이어야 하며 컴파일해야 합니다. if let (single expression) 는 의미가 없으므로 모호성이 없다고 생각합니다.

@kennytm 그래서 우리 둘 다 컴파일하지 않을 2가지 다른 모호성을 보여주었습니다. (그가 무엇을 의미했는지는 분명하지 않았습니다. 다소 모호했습니다.)

@daboross kennytm이 말했듯이 5.. 는 패턴이 아니며 지금도 컴파일되지 않습니다. 그리고 이것은 ..= 를 연산자로 추가해도 변경되지 않습니다. 모호함이 없습니다. 중요한 것은 이제 ..= 를 하나의 연산자로 구문 분석할 수 없지만 일단 하나의 연산자로 구문 분석할 수 있게 되면 모호성이 없다는 것입니다.

5.. 은 현재 유효한 패턴이 아니며 반쯤 닫힌 간격 패턴도 없습니다. 즉, 반 폐쇄 간격 패턴의 부족은 범위 표현식과 비교할 때 종종 불일치의 원인으로 간주되고 패턴에 대해서도 구현될 수 있습니다. 예를 들어 완전한 정수 일치를 위해 나중에 패턴에서 간격의 한쪽을 생략하는 기능을 추가할 수도 있습니다.

따라서 @clarcharr의 관찰이 현재 문법을 고려할 때 반드시 모호성을 지적하는 것은 아니지만, 패턴에 ..= 를 사용하라는 제안과 충돌할 수 있는 잠재적인 미래 확장을 고려할 때 확실히 모호합니다.

이를 염두에 두고 여기에 다른 기호를 사용하는 것이 좋습니다. ^ 는 현재 IIRC의 표현식 컨텍스트에서만 사용되기 때문에 상당히 괜찮은 것 같습니다.

(지금은 구조체를 안정화하고 구문은 나중에 안정화하는 방향으로 이동하는 것이 좋다고 생각하는 또 다른 이유입니다.)

@nagisa RangeFrom 패턴이 지원되기 전에 ..= 토큰이 추가되면 if let 에 대한 충돌은 없습니다. x <- y (위치) 대 x < -y (미만 + 음수)와 같이 .. 와 = 사이에 공백을 추가하여 명확하게 할 수 있습니다.

( ^ 는 배타적 -or 연산자이므로 포함 범위에 ..^ 를 사용하는 것이 아이러니하다고 생각합니다.)

내가 작성한 수천 개의 범위 중 상당수는 완전히 닫혀 있고 한두 개는 잘못된 방향으로 반쯤 열려 있지만 여전히 추가 구문이 필요하지 않습니다. 1..(n+1) 쓰기 어렵지 않습니다.

end = T::max_value()에서는 작동하지 않습니다.

2017년 5월 29일 16시 33분에 "Diggory Hardy" [email protected]이 다음과 같이 썼습니다.

내가 작성한 수천 개의 범위 중 상당수가 완전히 닫혀 있습니다.
어쩌면 한두 개라도 잘못된 방향으로 반쯤 열렸을 수도 있지만, 여전히
추가 구문의 필요성을 참조하십시오. 1..(n+1) 쓰기가 그렇게 어렵지 않습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment-304662258 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AApc0ipynL_qrZqUBldOJOX046RNY2H_ks5r-skwgaJpZM4F4LbW
.

나는 반 폐쇄 범위에 대한 방법을 ..=보다 선호합니다.

2017년 5월 29일 16시 35분에 "Simonas Kazlauskas" [email protected]가 썼습니다.

end = T::max_value()에서는 작동하지 않습니다.

2017년 5월 29일 16시 33분에 "Diggory Hardy" [email protected]이 다음과 같이 썼습니다.

내가 작성한 수천 개의 범위 중 상당수가 완전히
닫힌, 어쩌면 한두 개라도 잘못된 방향으로 반쯤 열렸을 수도 있지만, 여전히
추가 구문이 필요한지 확인하십시오. 1..(n+1) 어렵지 않습니다
쓰다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment-304662258 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AApc0ipynL_qrZqUBldOJOX046RNY2H_ks5r-skwgaJpZM4F4LbW
.

나는 그것에 대해 이견이 없다고 확신하기 때문에 이미 그것들을 구성하는 방법으로 특성과 유형을 안정화했으면 합니다. 구문에 대한 바이크쉐딩으로 인해 핵심 기능 자체의 안정화가 지연되지 않도록 하십시오.

end = T::max_value()에서는 작동하지 않습니다.

2^64 값 또는 2^8 값을 반복하시겠습니까? 예를 들어 u32 의 마지막 몇 개 값에 대해서만 반복하려는 경우 루프 내부에 하나를 추가하는 것이 더 쉬운 경우가 많습니다. 그리고 불분명한 이유로 2^B-1 로 반복하려는 경우 루프 끝에 항상 if i == END { break; } 를 붙일 수 있습니다.

표준 부호 없는 정수가 2^32 또는 2^64 값을 지원한다고 해서 표현 가능한 가장 높은 값이 자주 사용되는 것은 아닙니다. 그리고 u8 무언가를 하고 있다면 CPU가 카운터에 u32 를 사용하는 것이 더 쉽다는 것을 잊지 마십시오.

그러나 폐쇄 범위 생성기 구문이 필요하지 않다고 생각하더라도 변경에 대한 팀의 주장을 반박할 수 없습니다. 오 글쎄:/

이 네 가지가 모든 포괄성 옵션을 포괄하는 것은 어떻습니까?

1...10
1>..10
1..<10
1>.<10

나는 불평등 연산자가 유치원부터 모든 사람의 마음에 두드려져 왔다는 점을 감안할 때 추가 설명 없이 그들이 의미하는 바를 이해할 수 있어야 한다고 생각합니다. 하지만 이것이 다른 방식으로 고통이 될지는 모르겠습니다.

또는 부등식을 전환할 수 있습니다.

1...10
1<..10
1..>10
1<.>10

... 마지막 사람이 화난 카트맨처럼 보이지 않도록.

@vegai 그리고 확실히 제거되지 않을 기존 a..b 구문은 어떻습니까? 아니요, 새로운 구문 옵션을 제안하는 것이 어떤 문제도 해결될 것이라고 생각하지 않습니다.

흠, 두 가지 "잠재적 모호성"이 제기되었습니다.

• if let 5..= x -- 언급한 바와 같이 이것은 지금 은 실제로 모호하지 않지만 일종의 그럴 수 있습니다. 반면에 이러한 종류의 모호성은 자주 발생하며 토크나이저에서 해결합니다. 즉, 파서에서 ..= 를 토큰으로 간주하면 나중에 5.. 패턴을 추가하더라도 모호하지 않습니다. .. 와 = 사이에 공백을 쓰기만 하면 됩니다(예: let 5.. = x ).
• 거시적 규칙에 대한 모호성. 이것은 참으로 고통스럽고 불행한 일이며 우리가 "복합 토큰" 세트를 최종 사용자에게 노출하는 것을 피하는 "매크로 2.0"에 대해 다른 시스템으로 이동한 이유 중 하나입니다.
  
  
  
  • 결국, 우리는 필요한 경우 특별한 경우 코드를 통해 macro_rules! back-compat를 처리할 수 있습니다. 어쨌든 ... 를 사용하는 것 외에는 이런 종류의 문제를 피할 수는 없다고 생각합니다.
  
  

포함 범위를 안정화하기 전에 문제 #42401도 수정해야 합니다. 안정화 후에는 수정이 주요 변경 사항이 될 것이기 때문입니다.

@est31 좋은 점, 문제 헤드의 체크리스트에 추가했습니다.

확인된 str 슬라이싱 자체가 불안정하며 해당 문제를 수정해도 포함 범위가 전혀 차단되지 않습니다.

오, @nagisa 가 맞습니다. 범위 구문과 관련이 없습니다. 머리에서 다시 제거 할 수 있습니까? 내 실수. 버그는 get 구현에 있으므로 str_checked_slicing 기능으로 보호됩니다.

    impl SliceIndex<str> for ops::RangeToInclusive<usize> {
        type Output = str;
        #[inline]
        fn get(self, slice: &str) -> Option<&Self::Output> {
            if slice.is_char_boundary(self.end + 1) {
                Some(unsafe { self.get_unchecked(slice) })
            } else {
                None
            }
        }
    [...]

제거됨

또 다른 체크박스 업데이트: PR https://github.com/rust-lang/rust/pull/42134 적용 https://github.com/rust-lang/rfcs/pull/1980 비틀기

범프: 적어도 구조체를 1.20에서 안정화할 수 있는 방법은 무엇입니까?

포괄적인 범위 구문을 위해 C++에서 유명한 go-to 연산자 를 차용하는 것은 어떻습니까? 😛

@nikomatsakis 및 @rust-lang/libs(태그하는 방법을 모르겠습니다), 안정화에 대해 이야기할 수 있도록 구조체를 다른 추적 문제로 이동한 PR을 제출하면 기분이 어떻겠습니까? 거기? 새로운 구문이 구현/정착되기를 기다리는 동안 안정화를 더 빨리 진행할 수 있는 좋은 방법이라고 생각합니다.

cc @rust-lang/libs (팀의 사람들만 자신이나 다른 팀에 태그를 지정할 수 있음)

감사합니다, @eddyb!

@clarcharr 기반 https://github.com/rust-lang/rust/pull/42275#discussion_r119211211 , 나는 그것이 감사 할 것이라고 생각합니다.

구문 제안을 위한 기차에 너무 늦었나요?
현재는 누군가가 슬라이스에 값을 할당하려고 하는 것처럼 보입니다.

for i in a..b {} // [a..b) 
for i in a..+b {} //[a..b] 
for i in a-..b {} //(a..b) 
for i in a-..+b {} // (a..b]

이 구문을 사용하면 향후 범위에 대한 Add 구현을 추가할 수 없습니다. Add 구현이 무엇을 하는지 잘 모르겠기 때문에 그것이 문제인지는 잘 모르겠습니다.

후행 플러스에 동의합니다. 접두사로 변경되었습니다.

a.. , ..b 및 .. 는 Rust에서 유효한 구조이기 때문에 이것은 여전히 ​​수학 연산에서 모호성을 생성합니다 :/

a... / a..= / a..+ 는 유효하지 않겠죠? 끝점을 포함하는 무제한 범위를 갖는 것은 실제로 의미가 없기 때문입니다.

나는 Add 에 대해 너무 걱정하지 않을 것입니다. 범위와 관련하여 너무 일반적인 일이 아닌 것 같습니다. 원한다면 (x..+y) + z ?

편집: 신경쓰지 마세요, 방금 당신이 의미하는 바를 깨달았습니다. 모호한 a..+b 이겠죠? 지금 당장은 a.. + b 합니다.

@daboross 이것이 좋은 아이디어인지 나쁜 아이디어인지 말하는 것은 아니지만 이 구현(또는 약간의 변형)은 미래의 범위에 대해 원하는 것일 수 있습니다.

impl<T> Add<T> for RangeFrom<T> where T: Add<T> {
    type Output = RangeFrom<T>;
    fn add(self, rhs: T) -> RangeFrom<T> {
        (self.start + rhs)..
    }
}

이 특정 impl은 좋은 생각일 수도 있고 아닐 수도 있지만 가능한 미래의 사용 사례로 생각해내는 데 너무 오랜 시간이 걸리지 않았습니다. 기존 구문 결정으로 인해 이것 또는 이와 유사한 것이 추가될 가능성을 배제하는 것은 좋지 않다고 생각합니다.

내 또 다른 관심사는 ... 를 무시하는 요점은 오타를 인식하기 어려운 기회를 최소화하고 괄호가 추상 a..+b 의 두 가지 다른 의미 사이의 차이를 만들 수 있도록 하는 것입니다. 그 방향으로 돌아가게 될 것입니다.

또한 현재 .. 및 제안된 동안 "완전함을 위해 좋지 않은 것"을 넘어서 a-..b 및 a-..+b 대한 확실한 정당성을 아직 보지 못했습니다. ..= 둘 다 알려진 유효한 근거가 있습니다.

표현식 구문이 모호해지기 때문에 + 를 사용할 수 없습니다.

편집: 비록 <Range as Add<{integral}>>::Output = InclusiveRange 의 구현을 끝내기 때문에 라이브러리에서 완전히 포괄적인 범위를 구현하는 것이 가능할 것이라고 생각합니다.

..! 변형을 제안할 수 있습니다. .. 생산적인 운율을 가지고 있으며 마지막 점에 추가 강조를 두어 더 눈에 띄게 만듭니다.

물론 ! 연산자와 충돌하지만 솔직히 말해서 바인딩된 하위 표현식에 ! 를 넣어야 하는 상황을 상상할 수 없었습니다.

..! 는 직관성에 문제가 있습니다. 아직 구문에 익숙하지 않은 초보자는 ..! 를 "최대, 하지만..."을 의미하는 것으로 쉽게 오해할 수 있습니다.

또한 "...의 비트 보수까지 범위"에 대한 구문과 충돌합니다( + 를 사용하는 것과 유사한 상황에 놓이게 됨).

동의하다. 그러나 다른 한편으로 ..= 할당 연산자 중 하나로 잘못 해석될 수 있습니다.

이것이 할당 연산자라면 무엇에 할당하시겠습니까?

@snuk182 의 제안에 따라:

a...b // [a; b] shorthand for RangeIncusive
a..-b // [a; b) new Range shorthand 
a..b // [a; b) old Range shorthand exists for compatibility

다른 조합이 필요한지 궁금합니다. 어쨌든 나중에 추가할 수 있습니다.

a-..b // (a; b]
a-.-b // (a; b)  

마지막 옵션이 약간 이상해 보이지만. ^_^

단항 연산자(예: a..-b , a..!b , a..*b , a..&b 또는 a?..b )를 포함하는 구문 제안을 중단하십시오. 받아들였다.

..! 직관력에 문제가 있다. 아직 구문에 익숙하지 않은 초보자는 쉽게 오해할 수 있습니다..! "~까지, 그러나 ~까지"를 의미하기 위해

..= 는 직관성에 대해 동일한 문제가 있습니다. = 사람은 누구나 감동이나 비교를 기대합니다. ..= 볼 때마다 이 구문이 식별 문제를 완벽하게 해결한다는 것을 인정합니다. 이 등호가 여기서 무엇을 하는지 궁금하지 않을 수 없습니다.

매우 직관적이고 현재 구문과 일치하는 유일한 제안 구문은 ... 입니다. 그러나 배가 출항한 것 같습니다.

새로 온 사람들은 어쨌든 문서를 자주 봐야 할 것입니다. ... 를 사용해도 그들은 문서를 볼 것입니다. 이것은 피할 수 없습니다. 그러나 ..= 에는 멋진 니모닉( up to 및 equal to )이 있으므로 이 연산자에 대한 문서를 자주 볼 필요가 없습니다.

... 연산자가 그대로 유지되고 대신 .. 연산자를 ..⎵ , 즉 두 개의 점과 하나의 공백으로 변경하면 어떻게 될까요? ' 문자가 있는 이유는 이 웹페이지에 일반 공백이 표시되지 않기 때문입니다. 그것은 공백이 중요한 언어에서 한 곳일 것입니다. 같은 모든 코드 때문에 그것은 또한, 주요 변경 될 a..b 아니라 그런 운영자가 없음을 불평 것 .. , 그리고 조언는 점 이후에 적어도 하나 개의 공간을 추가 할 수 있습니다. 공간이 시각적으로 충분히 구별되도록 만든다고 생각합니다.

a.. b
a...b

@tommit 솔직히 좋은 생각이 아니라고 생각합니다.

연산자는 현재 공백에 대해 매우 유연합니다. 예를 들어 a..b 및 a .. b 는 동일합니다. 이는 a+b 및 a + b 와 같은 다른 연산자와 일관성을 유지하기 위한 것 같습니다. 물론 이들은 동일한 작업을 수행하며 사람들이 다른 구문 스타일을 사용할 수 있도록 합니다. 나에게 물어보면 좋은 일이야!

여기에 추가하기 위해 ..= 표기법은 <= 및 >= 표기법(_포함_으로 간주됨)과 일치합니다.

다른 가능성이 있는지 확인하는 것은 항상 좋지만 이것은 아마도 올바른 해결책이 아닐 것입니다.

동의하다. <= 및 >= <= 와 비교할 때 ..= 는 그럴듯하고 논리적으로 보입니다.

그건 그렇고, ... 의 팬이거나 ..= 모양이 마음에 들지 않는 경우 타협 솔루션은 ..= 대한 특수 합자가 있는 FiraCode 와 같은 프로그래밍 합자와 함께 일부 글꼴을 사용하는 것입니다 ..= , ... 매핑되거나 ⩷, ⩦ 또는 ≔와 같은 이상한 것까지 매핑될 수 있습니다.

범위를 사용하여 기존의 모든 녹 코드에 대한 주요 변경... 도착 시 사망,
죄송합니다. 누군가가 정말 심각한 하위 호환 제안을 가지고 있다면
제기된 우려 사항을 해결하고 논의되지 않았습니다.
이미, 들어 보겠습니다. 하지만 적어도 표준은 유지합시다, 응?
이 스레드는 자전거 창고로 가득 차 있고 팀은 이미 결정을 내렸습니다.
그것은 클리어 할 높은 바입니다.

어쨌든, 실제 구문에 대해 계속해서 많은 바이크 셰어가 있는 것 같습니다. 핵심 기능을 사용할 수 있도록 최소한 구조체, 특성 및 impls를 안정화하기 위해 #43086을 제출했습니다(수요가 있는 것 같습니다. 위의 @retep998 주석 참조).

방의 코끼리는 .. 가 대칭 모양이지만 비대칭 의미 때문에 실제로 여기에서 진짜 문제라는 것입니다. "옳은 일"은 아마도 그것을 비추천하는 것을 수반할 것이지만, 너무 많은 코드에서 이미 그것을 사용하고 있기 때문에 그렇게 할 의지는 없습니다.

완벽하게 일관된 ... (대칭 모양, 대칭 의미)를 사용하지 않는 것이 쉬운 방법이지만 ..= 에 또 다른 일관성 없는 연산자를 추가해야 합니다. 이전의 잘못된 디자인을 해결하기 위해 나쁜 디자인을 추가하는 것처럼 보입니다.

이 이중 불일치 때문에 이것에 또 다른 문제가 있습니다. 마지막 두 개의 포함 변형을 추가하는 좋은 방법이 없습니다(양쪽에 배타적이며 왼쪽에만 배타적). .. 및 ..= 모두 왼쪽에 이미 암시적 = 가 있으므로 이를 어떻게든 무효화해야 합니다. 아마도 < 합니다. 따라서 다음과 같이 보여야 합니다.

• <..= 대한 (a; b]
• <.. 대한 (a; b)

신규 이민자로서 이것이 무엇을 의미하는지 올바르게 추측하는 행운을 빕니다. 그래서 그들은 아마도 (정당하게) 결코 추가된 것으로 간주되지 않을 것입니다.

.. 가 확고하지 않거나 존재하지도 않는다면, 이 모든 것에 대한 일관된 디자인을 처음부터 시작하는 것이 그렇게 어렵지는 않을 것입니다. 예를 들면 다음과 같습니다.

• .. (또는 ... )에 대한 [a; b]
• ..< 대한 [a; b)
• <.. 대한 (a; b]
• <..< 대해 (a; b)

마지막 두 가지 변형이 어느 시점에서 유용할 수 있다는 느낌이 듭니다. 정말 빨리 그 경로를 차단해야 합니까? 어떤 경우에는, 유일한 이유는 선택 ..= 비하 이상 .. 훨씬 덜 예전의 코드를 깨는되지만 기껏해야 필요악, 축하 아무것도 할 것이다.

_편집: 더 명확하게 하기 위해 예제와 몇 가지 설명을 추가했습니다._

.. ... 또는 ..= 아니라 여기서 실제 문제라는 @rkarp의 의견에 동의합니다. 비대칭 의미는 다른 (인기) 언어는 사실에 대칭 의미를 할당 할 것을 고려하고 특히 나쁘다. 예를 들어 Kotlin, Ruby 및 Haskell은 모두 5가 3..5 범위에 있는 것으로 간주합니다. 수학 논문도 그것을 선호하는 것 같습니다. 여기서 최악의 상황은 초보자가 Rust에서 3..5의 동작을 추측할 기회가 없다는 것입니다. 4와 4만 범위 3..5(점에 대한 반복)의 구성원이라고 결정하거나 둘 다 3과 5도 그 안에 있습니다('우리가 볼 수 있는 모든 것'과 점의 외삽을 반복함).

그러나 이것을 변경하는 것이 어렵다는 점에는 동의하지 않습니다. @adelarsq 제안은 비교적 고통 없이 구현될 수 있다고 생각합니다. 참고로:

[1..4] // 1, 2, 3, 4
[1..4[ // 1, 2, 3
]1..4] // 2, 3, 4
]1..4[ // 2, 3

의 모든 발생 x..y (대괄호없이이)로 번역 될 수 [x..y[ 와 컴파일러 경고를 방출한다. 몇 가지 릴리스 후에 컴파일러는 단순히 "베어" 범위 표기법 컴파일을 거부할 수 있으며 새 표기법으로 자동 변환하는 도구를 제공할 수도 있습니다.

https://github.com/rust-lang/rust/issues/28237#issuecomment -274216603 이는 새로운 아이디어가 아니며 이미 언급한 이유로 사용할 수 없습니다.

나는 우리가 뒤늦게 알게 된 이점을 가지고 언어를 처음부터 디자인한다면 배타적 범위와 포괄적 범위의 구문을 함께 고려하기를 원할 것이라는 생각에 절대적으로 동의합니다. ..= 는 포괄적인 범위에 대한 이상적인 연산자가 아니라고 생각합니다. 그것은 단순히 현재 테이블에 있는 최선의 선택입니다. 그러나 현재의 배타적 범위 연산자를 더 이상 사용하지 않는 것은 지나치게 고통스럽고 기존의 Rust 사용자와 프로젝트에 불쾌감을 줄 것입니다.

작동 할 수 있는 다른 수많은 제안 ..@ 제안된 것을 본 적이 없으며 x..@y 가 연상되는 것 같습니다. 문제는 현재 제안보다 더 설득력 있는 것을 찾는 동시에 모호함을 유지하는 것입니다.

대칭에 대한 내가 가장 좋아하는 관점으로 2개월 전 @ssokolow 의 의견 을 강조하고 싶었습니다.

• ..4 에는 < 4 포함되어 있습니다.
• ..=4 에는 <= 4 포함되어 있습니다.

포함 범위만 필요하다고 생각합니다. 더 간단합니다.
항상 + 1 또는 -1을 추가하여 범위를 변경할 수 있습니다.
그리고 .. 이 더 낫습니다. .. 가 ... 보다 간단하기 때문입니다.

@AlexanderChen1989 이 스레드의 여러 게시물에서 이전에 말했듯이 .. 의 의미를 변경하면 기존 코드가 손상되기 때문에 불가능합니다.

게다가 실제로 그렇게 간단하지도 않습니다. 특히 +1 및 -1 는 정수 오버플로/언더플로를 유발할 수 있습니다.)

다음 은 nightly (포함 범위 구문에 대한 이전 후보를 통해)에서

• ...어떤 루프를 먼저 넣든 디버그 빌드에서 오버플로/언더플로 시 패닉이 발생합니다.
• ...릴리스 빌드에서 의도한 것과 완전히 반대로 동작합니다(즉, "0에서 0"은 256번 반복되고 "0에서 255"는 전혀 반복되지 않음)

#![feature(inclusive_range_syntax)]
fn main() {
    let max = 255u8;
    let user_provided = 0u8;

    for x in 0...user_provided-1 {
        println!("(0 to 0, exclusive via 'inclusive - 1'): {}", x);
    }

    for x in 0..max+1 {
        println!("(0 to 255, inclusive via 'exclusive + 1'): {}", x);
    }
}

언어 팀이 결정을 내린 이후로 8개의 Dead on arrival 구문 제안이 만들어졌습니다. 새로 오신 분들은 글을 읽어주세요. 우리가 약속한 결정을 내리는 데에는 아주 좋은 이유가 있습니다.

IMHO OP는 이 스레드에서 더 이상 구문 논의가 없어야 하며 배타적 범위 구문(예: (a, b) 및 (a, b] 범위)에 대한 제안은 다른 스레드로 이동해야 함을 지적하도록 업데이트되어야 합니다.

현재 계획을 안정화하기 위해 수행해야 하는 작업에 대해서만 이야기해야 합니다.

@clarcharr 나는 대부분 일방적인 결정을 내리고 그것을 OP에 추가했습니다. 좋은 생각입니다. 소음이 계속되면 스레드를 잠그는 데 투표하겠습니다.

안녕하세요, 저는 처음이고 이 작업을 시작하고 싶습니다. PR을 작성하여 ..= 를 패턴에서 ... 의 동의어로 추가하고 표현식에서 ... 를 더 이상 사용하지 않으며 구문이 다음으로 변경되었다는 오류를 표시하려고 합니다. ..= . 이 소리가 맞습니까?

@Badel2 멋지네요 . 실제로 시작했습니다. 곧 내 지점을 푸시하고 여기에 연결할 것입니다.

@durka 명확히 @Badel2 가 귀하의 지점에서 시작하도록 하시겠습니까? impl 기간 작업의 일부로 그들을 멘토링할 수 있습니까? 그들은 Gitter 채널에 있습니다.

나는 또한 실제 문제가 .. 이라는 데 동의합니다. (이것은 기존 코드를하지 깰 __not__ 것 한 번에 교체하지 않는, 그래서) 그래서, 더 유리한 솔루션을 비하하는 것입니다 .. 같은 찬성 ..< 사이 (가있을 것입니다 혼란을 a..<b 및 (a..)<b , .. 는 결국 존재하지 않게 됩니다.

@hyst329 이미

첫 번째 게시물은 굵은 글씨체로 "이 스레드에서 더 이상 구문 논의가 없어야 합니다."라고 말합니다.

그것은 제쳐두고, 당신이 설명하는 것은 기존 토론을 읽지 않은 다른 사람들에 의해 이미 여러 번 제안되었으며 실행 가능한 옵션이 아닌 이유에 대한 응답으로 여러 가지 이유가 있습니다.

이것이 건설적이지 못해서 죄송하지만 ..= 를 보고 그것이 무엇인지 기억하려고 할 때마다 += 또는 <<= 와 유사한 할당 연산자처럼 보입니다. 그렇지 않다는 것이 매우 혼란스럽게 느껴집니다. (예를 들어 " ..= 구문에 대한 초기 지원" https://this-week-in-rust.org/blog/2017/10/03/this-week-와 같이 컨텍스트에서 벗어났습니다. 녹슬지 않는-202/)

@SimonSapin 위에서보다 건설적인 방식으로 동일한 비판을 표현했으며 대신 ..^ 를 제안했습니다. https://github.com/rust-lang/rust/issues/28237#issuecomment -304325663

나를 위해, 대변 하나의 큰 포인트 ..= (가지고있는 신속하고 일관성 정렬입니다 ..< 독점 및 .. 포괄적 인 범위에 대한 참조). 이것은 ..= 선택에 문제가 없었습니다.

@SimonSapin 나는 그것에 완전히 만족하는 사람이 없다고 생각합니다. 문제는 불행히도 더 나은 대안이 없다는 수백 개의 의견이 있다는 것입니다.

아무것도 하지 않는 것보다 나를 설득하기 위해 달성한 이 패치 는 현재의 패턴 구문을 엉망으로 만드는 것보다 에지 케이스만 처리하는 것이 좋습니다.

.. 패턴의 사용 사례는 거의 없으며 항상 그것 없이도 처리할 수 있습니다.

... 는 실제로 필요한 표현식에서 RangeInclusive 또는 (Bound<T>, Bound<T>) 로 대체될 수 있습니다. 더 장황하지만 이해하기 쉽습니다.

@UtherII

...그리고 나는 컴파일러의 "You can't use inclusive range syntax on stable" 메시지에 의해 미묘한 버그로부터 내가 구원받았을 때 ... 가 유지될 수 없다고 확신했습니다.

여러 번 연속으로 빠르게 누를 때 실수로 . 너무 많이(또는 관련된 역학을 감안할 때 한 번 너무 적게) 누르는 것은 너무 쉽습니다.

" ..= 을 패턴에서 ... 동의어로 수락하고 표현식에서 ..= 를 수락하도록 변경"을 체크했습니다. 이미 #44709 이후의 경우이므로 dotdoteq_in_patterns 및 inclusive_range_syntax 기능. 남은 것은 문서화와 안정화뿐입니다.

안정화 요청

포함 범위를 1.26 (3월 30일 베타, 5월 11일 안정) 또는 그 이전으로 안정화하고 싶습니다. 안정화 PR이 #47813으로 제출되었습니다.

요약

다음 3가지 기능이 안정화됩니다.

• inclusive_range_syntax — 표현식의 a..=b 및 ..=b 구문:

  for i in 1..=10 {
      println!("{:?}", &a[..=i]);
  }
  

• dotdoteq_in_patterns — 패턴의 a..=b 구문:

  match c {
      b'0'..=b'9' => c - b'0',
      b'a'..=b'z' => c - b'a' + 10,
      b'A'..=b'Z' => c - b'A' + 10,
      _ => unreachable!(),
  }
  

  (참고: a...b 구문은 여전히 ​​경고 없이 허용됩니다.)

• inclusive_range — std::ops::{RangeInclusive, RangeInclusiveTo} 유형 및 해당 필드:

  let r = 1..=10;
  assert_eq!(r.start, 1);
  assert_eq!(r.end, 10);
  

선적 서류 비치

@alercah 가 여러 문서 PR을 제출했습니다. 감사합니다!

• 책: https://github.com/rust-lang/book/pull/1134
• 참조: https://github.com/rust-lang-nursery/reference/pull/215
• Rust-by-Example: https://github.com/rust-lang/rust-by-example/pull/1015

테스트

다음에서 테스트 케이스를 찾을 수 있습니다.

• run-pass/range_inclusive.rs —
  for-loop에서 a..=b , 반복자, 슬라이스 인덱스, ..= 연산자의 우선 순위 및 유형 검사 동작과 같은 기본 테스트.
• libcore/tests/iter.rs —
  반복자로서 a..=b 의 동작에 대한 추가 테스트; nth() , min() , max() 및 last() 전문화가 올바르게 작동하는지, 그리고 (5..=5).next() 호출한 후 범위가 1..=0 .
• liballoc/tests/str.rs , liballoc/tests/btree/map.rs 및 liballoc/tests/vec.rs —
  a..=b 가 다양한 컬렉션 유형에서 올바르게 작동하는지 확인합니다.
• parse-fail/range_inclusive.rs 및 ui/impossible_range.rs —
  a..= 및 ..= 와 같은 넌센스 구문을 식으로 컴파일할 수 없도록 합니다.
• parse-fail/range_inclusive_dotdotdot.rs —
  더 이상 사용되지 않는 표현식 구문 a...b 및 ...b 을 거부합니다.
• run-pass/inc-range-pat.rs —
  패턴에서 a..=b 및 a...b 이 모두 허용되고 동등함을 보장합니다.
• compile-fail/range_traits-1.rs 및 compile-fail/range_traits-6.rs —
  RangeInclusive 및 RangeInclusiveTo 는 다른 범위와 마찬가지로 PartialOrd 구현하지 않으며 RangeInclusive 는 Copy 구현하지 않습니다. 반복자이기 때문에 Copy를 구현하십시오).
• libcore/tests/ops.rs —
  수동으로 생성된 RangeInclusive 인스턴스의 반복이 작동하는지 확인합니다.

해결되지 않은 질문

• for-loop에서 a..=b 를 사용하면 next() 가 더 복잡하고 최적화 프로그램에 덜 친숙하기 때문에 a..(b+1) 보다 성능이 훨씬 낮습니다. 이것은 현재 #45222에서 추적되고 있습니다. 이것은 현재 for-loop 대신 iterator 메서드를 사용할 때 #48012에 의해 완화됩니다.

  아직 Rust-lang/rfcs#1980의 디자인에 커밋하고 싶지 않다면 RangeInclusive 필드를 불안정하게 유지해야 할 수도 있습니다 .

아직 Rust-lang/rfcs#1980의 디자인에 커밋하고 싶지 않다면 RangeInclusive 필드를 불안정하게 유지해야 할 수도 있습니다.

+1
일부 메서드 기반 인터페이스를 통하지 않고 직접 범위 필드를 노출할 필요가 있습니까?

@rfcbot fcp 병합

@kennytm 의 요약 에 따르면 포함 범위 구문( ..= )을 안정화 할 것을 제안합니다.

(즉, ..= 의 낮은 성능은 약간 우려스럽습니다. 그리고 ..= 당분간 Iterator 에 직접 구현하지 않는 것이 타당한지 궁금합니다. 이를 완화하기 위해.)

팀원 @nikomatsakis 가 이를 병합할 것을 제안했습니다. 다음 단계는 태그가 지정된 나머지 팀이 검토하는 것입니다.

• [x] @BurntSushi
• [x] @키문디
• [ ] @KodrAus
• [x] @alexcrichton
• [x] @아투론
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @sfackler
• [ ] @보트 없이

현재 나열된 우려 사항이 없습니다.

과반수의 검토자가 승인하고 반대하지 않으면 최종 의견 제출 기간이 시작됩니다. 이 프로세스의 어느 시점에서도 제기되지 않은 주요 문제를 발견하면 알려주세요!

태그가 지정된 팀 구성원이 나에게 줄 수 있는 명령에 대한 정보는 이 문서 를 참조하십시오.

이를 완화하기 위해 당분간 Iterator를 ..= 직접 구현하지 않는 것이 타당한지 궁금합니다.

이러한 안정적인 특성은 현재 Nightly에서 T 대해 RangeInclusive<T> 대해 구현됩니다. Iterator , FusedIterator , ExactSizeIterator , Debug , Clone , Eq , PartialEq , Hash , TrustedLen .

@SimonSapin 나는 이미 구조체를 안정화 했습니까? (즉, 관찰 가능합니까?) 그렇지 않다고 가정했습니다.

말했다, 나 또한 정말, 정말 생각 1..2 및 1..=2 여기 변경하기에 대해 주장하고, 대신에 우리가 완화를 추구하고 개선 만한다 제안 모두 같은 장소에서 사용할 수 있어야 최적화.

end == MAX 특수 케이스 범위가 아닌 이유는 무엇입니까? 이는 경계로 직접 이동하는 범위에 더 많은 코드가 있다는 점을 제외하고 배타적 범위와 동일한 코드를 갖는 가장 포괄적인 범위로 이어질 수 있습니다. end != Max 분기는 end 수정하지 않으므로 옵티마이저에서 쉽게 인라인할 수 있습니다.

@nikomatsakis 아니요, 구조체는 현재 불안정합니다. 그러나 @kennytm의 제안에는 안정화가 포함됩니다.

@SimonSapin

아니요, 구조체는 현재 불안정합니다. 그러나 @kennytm의 제안에는 안정화가 포함됩니다.

알 겠어요; 실제로 이것이 바로 지금 아니면 절대 Iterator impl을 제거해야 한다고 언급한 이유입니다. =)

@SimonSapin 구조체를 안정화하지 않고는 a..=b 표현식 구문을 안정화할 수 없다고 생각합니다. 그러나 우리는 필드를 불안정하게 둘 수 있습니다. 만약 우리가 그것을 바꿀 수 있다고 생각한다면.

맞습니다. 이러한 유형의 값을 구성하기 위한 구문을 안정화할 때 유형을 안정화해서는 안 된다고 말하는 것은 아닙니다.

범위 구문을 탈출하고 안정화를위한 Huzzah! :따다:

타임머신이 주어지면 Range 유형이 :Iterator 가 아니고 :IntoIterator 라고 주장합니다. 하지만 지금 은 Range와의 일관성 이 최선의 선택이라고 생각합니다. 이 경우를 Chain 와 함께 "음, 내부 반복이 때때로

해결되지 않은 또 다른 문제는 반복과 관련이 있습니다. 반복이 완료되면 RangeInclusive의 특정 표현을 커밋하고 싶습니까? 지금 은 1..=0 로 끝났지만 다른 옵션에 대해 논의했습니다 . 문서가 사람들이 문서에 의존하지 않도록 하는 데 충분한지 여부는 알 수 없지만 현재 문서는 사후 반복 범위를 상당히 쓸모없게 만들고 적어도 낙담합니다.

이 경우를 Chain과 함께 "음, 내부 반복이 때때로 더 빠른 것으로 밝혀졌습니다" 버킷에 넣을 수 있습니다.

독점 범위보다 성능이 떨어지지 않도록 수정해야 한다고 생각합니다. 그럴 근본적인 이유는 없습니다.

그럴 _근본적인_ 이유는 없습니다.

그것은 우리가 시행할 수 있는 불변성에 달려 있습니다. 상태의 추가 비트가 있는 이전 두 공식에서는 반복을 완료할 때 해당 비트가 실제로 설정되도록 강제하는 것이 없었습니다(사실 100..=0 와 같은 리터럴에 설정되지 _않습니다_). 종료 조건은 복합적이어야 합니다. 즉, LLVM이 더 이상 이를 해제할 의사가 없으므로 성능이 저하됩니다. 완전히 수정하는 것은 구조체를 더 크게 만들고 pub 필드가 없도록 하거나 RangeInclusive: !Iterator 를 만들거나 이러한 종류의 루프를 최적화하는 데 LLVM을 더 잘 만드는 것을 의미합니다.

그게 내가 쓰는 몇 가지 다른 방법으로 시도했다 RangeInclusive::next , 그리고 것 같습니다 내 과거 자기의 선택이에 일치하도록 Option<Ordering> 매우 슬픈하고있다 LLVM - 단지 대신이 비교 연산자를 넣어주고있다 훨씬 더 나은 조립. PR 수정 : https://github.com/rust-lang/rust/pull/48057

타임머신이 주어지면 Range 유형 중 어느 것도 :Iterator가 아니고 :IntoIterator일 뿐이라고 주장합니다. 하지만 지금은 Range와의 일관성이 최선의 선택이라고 생각합니다. 이 경우를 Chain과 함께 "음, 내부 반복이 때때로 더 빠른 것으로 밝혀졌습니다" 버킷에 넣을 수 있습니다.

나는 기본적으로 이것에 동의합니다.

:bell: 위 의 이제 최종 댓글 기간에 접어들었습니다 . :벨:

:bell: 위 의 이제 최종 댓글 기간에 접어들었습니다 . :벨:

@rfcbot fcp 취소

@withoutboats 및 @KodrAus 는 해당 상자를 선택하지 않았습니다.

@cramertj 제안이 취소되었습니다.

@rfcbot fcp 병합

https://internals.rust-lang.org/t/psa-tweaks-to-fcp-process/6775

팀원 @cramertj 가 이를 병합할 것을 제안했습니다. 다음 단계는 태그가 지정된 나머지 팀이 검토하는 것입니다.

• [x] @alexcrichton
• [x] @아투론
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @sfackler
• [ ] @보트 없이

현재 나열된 우려 사항이 없습니다.

과반수의 검토자가 승인하고 반대하지 않으면 최종 의견 제출 기간이 시작됩니다. 이 프로세스의 어느 시점에서도 제기되지 않은 주요 문제를 발견하면 알려주세요!

태그가 지정된 팀 구성원이 나에게 줄 수 있는 명령에 대한 정보는 이 문서 를 참조하십시오.

:bell: 위 의 이제 최종 댓글 기간에 접어들었습니다 . :벨:

@rfcbot fcp 관심사 범위 패턴에는 운영자 우선 순위 문제가 있습니다( https://github.com/rust-lang/rust/issues/48501).

( @petrochenkov 구문은 <strong i="6">@rfcbot</strong> concern KEYWORD 가 없는 fcp 입니다. 그러나 태그가 지정된 팀원만이 우려 사항을 등록할 수 있다고 생각합니다.)

이제 최종 의견 수렴 기간이 완료되었습니다.

#48501이 안정화를 차단하기에 충분하다면 #48500이 병합(및 안정화)될 때까지 기다려야 합니까? 더 빠른 길을 찾을 수 있기를 바랍니다. 이 기능은 출시된 지 너무 오래되어 현재 오류 메시지가 사람들에게 불안정한 구문을 가리키는 불안정한 상태에 있습니다.

@durka
이 안정화를 위해 https://github.com/rust-lang/rust/pull/48500 안정화를 기다릴 필요가 없다고 생각합니다
... 패턴이 여전히 존재하고 여전히 이전 우선순위를 유지하므로 패턴에 &BEGIN ... END 있는 경우(이것은 매우 드문 경우임) 항상 ..= 변경하지 않는 옵션이 있습니다. 한동안

#48500을 꽤 빨리 안정화시킬 수 있다고 생각합니다.

개인적으로 나는 "insta-stable"로 랜딩하는 것이 좋습니다.

inclusive range 는 #47813 pull 요청이 병합되어 안정화되었지만 1.25 릴리스에는 없습니다. 이유는 무엇입니까? 풀 리퀘스트가 3월 16일 에 병합되었지만

@mominul 기능은 마스터 브랜치에 병합된 후에만 사용할 수 있으므로 ..= 는 1.25가 아닌 1.26부터 사용할 수 있습니다.

그런 식으로 베타에서 테스트하고 안정적인 상태로 푸시되기 전에 야간에 테스트할 수 있습니다.

@kennytm 및 @clarcharr 입력에 감사드립니다! Rust 1.26 릴리스는 확실히 적어도 저에게는 지루하지 않습니다! :웃다:

이 토론에 참여하기에는 너무 늦었다는 것을 알고 있지만 .. 구문을 완전히 생략하고 대신 단어를 사용하는 것은 어떻습니까?

Scala에는 1 to 4 를 생성하는 [1, 2, 3, 4] , 1 until 4 를 생성하는 [1, 2, 3] 및 단계 크기를 나타내는 선택적 by 키워드가 있습니다. : 1 to 10 by 2 = [1, 3, 5, 7, 9] .

이렇게 하면 의도가 더 명확해지고 모든 사람이 걱정하는 것처럼 보이는 "오프-바이-원" 오류를 피할 수 있습니다.

물론 원래 구문이 계속 지원되지 않는 경우 기존 코드가 모두 중단됩니다.

Rust 범위의 to 및 until 를 키워드로 도입해야 하며 이는 훨씬 더 큰 변화가 될 것입니다.

Scala에서 잘 작동하지만 Rust의 디자인 선택은 크게 다릅니다.

@ElectricCoffee 그 느낌을

내장 언어 키워드는 함수 또는 변수 이름과 충돌할 수 있으므로 최소한으로 유지해야 한다고 생각합니다.

to 와 until 는 std 에서 사용되는 단어는 아니지만 (내가 아는 한) 다른 상자와 프로젝트.

@daboross 그건 사실 고려하지 않은 공정한 지적이지만 a .. b 는 a 및 b 관계없이 어떤 의미에서 a to b 의미합니다. b 실제로 있습니다.

그리고 예, @timvisee 는 아마도

@ElectricCoffee 하지만 to 가 ..= 하고 until 가 .. 를 의미한다면 a to b 아니라 a until b 를 써야 합니다 a to b a .. b a to b 대신 a .. b . 보시다시피, 연산자보다 이러한 단어를 사용하는 것이 "더" 직관적이지 않습니다. 그러나 .. 가 사용되는 모든 곳에서 until 를 쓰는 것이 더 장황할 것입니다. ..= (단어가 사용된 경우 .. 에 더 짧은 단어를 할당해야 함)

그리고 당신은 @Boscop 에 대해 절대적으로 옳습니다. 그러나 그것은 단어가 어떻게 수행될 수 있는지에 대한 예일 뿐입니다.

일부 언어에서는 to 독점 및 upto 포함도 본 것 같습니다.
그것은 모두 아이디어로 의미했습니다.

스칼라에서는 배타적 범위보다 포괄적 범위가 더 많이 사용되므로 더 짧은 단어가 주어집니다.

@timvisee One은 단순히 a.to(b) 및 a.until(b) 를 사용할 수 있으며 추가 키워드가 필요하지 않습니다(구문을 훨씬 더 어색하게 만들지 않습니다).

@hyst329 그건 생각도 못

이것이 현재(/new) 구문에 대한 적절한 완전한 대체가 될 것이라고는 믿지 않습니다. 그러나 그것은 좋은 추가 사항이 될 것입니다.

직관성에 대한 Boscop의 의견에 동의해야 합니다. "포함하는" 및 "제외한"과 같은 단어를 제외하고, 일상적인 영어는 기성품 지름길이 있을 만큼 충분히 포괄적인 범위와 배타적인 범위를 실제로 구분하지 않습니다.

"A to B"도 사용되는 맥락에서 사용되지 않는 한, "A to B"가 여기 캐나다 온타리오주 남부에서 일상적인 연설에서 포괄적인 범위를 의미하는지 배타적인 범위를 의미하는지 모호하며 "until"이 연관되어 있습니다. 시간이 너무 강력하여 이 느슨한 의미로 사용될 때 "until"이 연관되는 "event"가 "X를 볼 때까지"인지 "X를 처리 할 때까지"인지 여부가 불분명합니다.

@hyst329 메서드로 사용하면 범위가 숫자 유형으로 제한됩니다. 숫자 범위에 대한 구문과 다른 범위에 대한 구문을 사용하지 않는 것이 좋습니다.

범위 생성을 위한 서곡에 새로운 포괄적인 특성을 추가할 수 있다고 생각합니다. 하지만 이는 실제 to 및 until 메서드가 있는 항목에 대한 주요 변경 사항에 가깝습니다.

고백하자면 키워드 제안이 만우절 장난인 줄 알았다.
..= 구문이 안정화되었습니다.

2018년 4월 5일 목요일 오후 1시 53분에 David Ross [email protected]에서 다음과 같이 썼습니다.

@hyst329 https://github.com/hyst329 메소드로 사용하면 제한됩니다.
그러나 범위는 숫자 유형입니다. 하나의 구문을 사용하지 않는 것이 좋습니다.
숫자의 범위와 다른 것의 범위에 대한 또 다른 것입니다.

나는 우리가 다음을 만들기 위한 서곡에 새로운 포괄적인 특성을 추가할 수 있다고 생각합니다.
범위, 하지만 그것은 여전히
실제 to 및 until 메서드.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/28237#issuecomment-379021814 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAC3nwBj-b985q1Ez0OHDEHkG6DWV_5nks5tlloZgaJpZM4F4LbW
.

예, 우리는 이 문제에 대해 300개 이상의 댓글을 달았고 첫 번째 댓글 은 다음과 같습니다.

이 스레드에서 더 이상 구문 토론이 없어야 합니다 . 배타적 범위 구문에 대한 다른 제안은 사용자 포럼 또는 내부 포럼에서 기존의 모든 의견과 해당 근거를 읽은 후 이루어져야 합니다. 특히, 하위 호환성을 깨는 것은 시작이 아닙니다.

지금은 이 문제를 잠그겠습니다. 혹시라도 발을 밟고 있다면 죄송합니다!

이 문제에서 다루는 모든 것이 완료되었다고 믿습니다. 다른 문제가 있는 경우 문제의 원래 메시지에 있는 체크리스트를 다시 열고 업데이트하십시오.