그 RFC에는 4가지 고유한 기능이 있지만 여전히 모든 기능에 대해 하나의 추적 문제만 있습니다. 우리는이 같은 서로 다른 기능을 밀어하지시겠습니까?

@retep998 RFC 토론 전반에 걸쳐 설명했듯이 이러한 기능은 글로벌 설계 고려 사항을 통해 연결됩니다. 예를 들어, 크레이트 이름을 변경하기 위한 외부 메커니즘을 제공하는 것은 부분적으로 extern crate 의 궁극적인 사용 중단에 의해 동기가 부여됩니다. 우리는 할 수 있고 의지 게이트 다양한 측면 개별적으로 (그리고 가능성이 다른 구문을 시도하는 일부 중복 게이트를해야합니다)하지만, 전체적인 디자인 및 안정화에 대한 논의, 그것을 염두에 글로벌 일관성을 유지하는 것이 중요합니다.

크레이트의 이름을 바꾸는 외부 메커니즘을 갖는 것은 이미 몇 년 동안 원하고 필요했던 것입니다(https://github.com/rust-lang/cargo/issues/1311). extern crate 죽이기를 지원하는 폰에

우리는 과거에 밀접하게 관련된 기능에 대해 별도의 RFC를 갖는 데 문제가 없었지만( repr(align(N)) 및 repr(packed(N)) 대한 RFC가 떠오름), 지금은 foo/mod.rs 에서 foo.rs 는 extern:: 및 crate:: 와 매우 밀접하게 관련되어 있으므로 동일한 RFC에 있어야 하고 동일한 추적 문제를 사용해야 합니까?

해결되지 않은 구문의 상대적으로 미묘한 측면이기 때문에 이 요점이 계속 유지되도록 하십시오. crate 를 가시성 수정자 및 경로 접두사로 사용하면 crate ::absolute::path 와 crate::relative::path . 컨텍스트 키워드를 사용하면 동일한 모호성이 발생하며 가시성 수정자로 실제로 의미가 있는 다른 예약된 키워드는 없습니다.

따라서 (적어도) crate 가시성 수정자를 생략하고 기존 pub(crate) 고수하는 실험을 하고 싶습니다.

foo.rs / foo/mod.rs 포인트를 별도의 추적 문제로 분할하는 것은 마음에 들지 않습니다. 경로 및 가시성 수정자 변경 사항과 실제로 독립적으로 보이기 때문입니다.

외부 상자 이름 변경에 관해서 는 ... 이미 별도의 문제가 있습니까? 나는 그것의 벌금이 하나의 일부가되는뿐만 아니라 생각 있도록 경로 변경을 위해 매우 중요하다.

몇 주 전에 가시성 수정자(경로 접두어 아님)로 crate 를 선택하는 것과 관련하여 많은 토론이 있었음에도 불구하고 이 키워드 선택이 RFC, 이제 분명히 잊혀졌습니다. 나 자신과 내가 언급한 몇몇 다른 사람들은 이 선택이 형용사/수식어가 아니며 모호할 수도 있기 때문에 이 선택이 혼란스럽다고 생각합니다. crate 는 크레이트의 공개 API의 일부를 의미합니까? 아니! 그것은 상자에 local 또는 internal 또는 pub 를 의미합니다(따라서 내가 후자의 키워드를 선호하는 이유). 따라서 즉각적인 변경을 요구하는 것은 아니지만, 안정화 시 잊혀지지 않도록 최소한 이 추적 문제에서 해결되지 않은 문제로 인정합니다.

이 모듈 재설계가 지금까지 진행되었다는 것은 훌륭하지만 동시에 'impl period'를 만드는 데 실수하지 않고 대다수의 Rust 사용자와 상의하지 않고 결정을 내리는 것이 중요합니다. 그리고 불행히도 Github RFC 토론에 참여하는 사람들이 전체 사용자 기반을 대표하지 않는다고 생각합니다. 정보/코멘트/의견이 넘쳐서 낙담할 수 있기 때문입니다. 따라서 어떻게 든 처리해야합니다.

구현이 어떻게 끝났는지 명확하지 않습니다 ...

@rpjohnst @retep998 저는 foo.rs + foo/ 에 대해 논의하고 이 RFC에 대한 몇 가지 개선 사항을 제안하기 위해 새 RFC 를 열었습니다.

편집: 가시성 수정자로 crate 에 대해 논의하기 위해 다른 RFC를 여는 것이 좋습니다. 개인적으로 나는 반대의 것을 보고 싶습니다. pub(extern) 가 추가되고 외부적으로 게시된 모든 기호에 필요합니다. 이렇게 하면 다음 에포크에서 pub 가 pub(crate) 와 동일하게 됩니다.

@rpjohnst

crate ::absolute::path와 crate::relative::path 사이에 모호한 구문 분석을 도입합니다.

어쨌든 crate ::relative::path 잘못된 코드가 아닌가요? 파싱 ​​중에 거부할 수 없나요?

@est31 아니요, 구문 분석 중에 이름 확인을 수행해야 하는 것은 확실히 우리가 원하는 것이 아닙니다. a * b 는 곱셈이나 선언이고, a b(c, d); 는 변수 선언이나 함수 프로토타입과 비슷한 모호성이 있는 C 및 C++ 구문 분석의 가장 성가신 부분 중 하나입니다.

이름이 같은 종속성과 최상위 모듈을 허용하기 시작하면 구문 분석과 이름 확인을 뒤섞어도 저장되지 않습니다. crate :: some :: item 는 crate -visible item 가 될 수 있습니다. some 또는 전용 item 최상위 모듈 some .

관점에서 이것을 유지하기 위해, 우리는 단지 임의로 모호성 하나의 방법 또는 기타를 해결하고 (아마도 다른 경우 쓰기 괄호를 요구할 수 crate 희귀 한 것 같다 -visibility 절대 경로 케이스),하지만 여전히입니다 pub(crate) 고수한다면 필요하지 않은 발총은 이미 구문상의 모호성을 해결했습니다.

crate를 가시성 수정자 및 경로 접두사로 사용하면 crate ::absolute::path 와 crate::relative::path 사이에 구문 분석이 모호해집니다.

튜플 구조체 필드와 "인라인" 절대 경로에 대한 가시성이 모두 드물다는 점을 감안할 때 이것은 작은 문제입니다.
경로는 현재 항상 탐욕스럽게 구문 분석되므로 crate :: x :: y 가 crate::x::y 를 의미하는 것이 합리적입니다.
반대의 의미를 원할 경우 pub(crate) ::x::y 또는 crate (::x::y) 사용할 수 있습니다.

@rpjohnst @petrochenkov pub ::relative::path 가 유효한 코드인 코드 예제를 공유해 주시겠습니까? 나는 두 가지 경우 중 하나가 유효하지 않다고 생각하기 때문에 전체 모호성을 이해하지 못합니다.

편집: 이것이 관련 될 수 있는 유일한 장소는 가시성 한정자 + 경로에 대해 일치할 때 매크로 내부입니다. 그러나 그것은 IMO가 수용할 수 있는 매우 작은 파손입니다.

@est31 잘못된 생각을 가지고 있는 것 같습니다. 상대 경로가 아니라 문제가 되지 않습니다. 이름이 무엇을 가리키는지 알기 전에 AST를 구축하는 것입니다. 전체 샘플은 다음과 같습니다.

struct S(crate :: x :: y);

아직 그 이름을 조회할 수 없다는 점을 감안할 때 해당 문자열을 AST로 어떻게 변환합니까? 두 가지 가능한 대답이 있습니다. 하나는 현재 크레이트의 x 모듈에 정의된 y 유형의 개인 필드가 있습니다. 다른 하나에는 x 종속성의 최상위 수준에서 정의된 y 다른 유형의 crate -visible 필드가 있습니다. 매크로가 필요하지 않습니다.

@rpjohnst 명확히 해주셔서 감사합니다. 참으로 모호합니다.

@rpjohnst

간단한 솔루션은 크레이트 가시성 수정자로 명확하게 구문 분석하도록 정의하는 것입니다. 주어진 유형의 private 멤버가 있는 튜플 구조체로 구문 분석하려면 다음과 같이 하십시오.

    struct S(:: crate :: x :: y);

(루트 '네임스페이스'를 나타내기 위해 :: 접두사에 유의하십시오)

이는 하위 모듈에서 다른 루트 네임스페이스를 참조해야 하는 방식과 일치합니다(예: ::std::x::y ).

crate -as-a-visibility로 명확하게 하는 것은 다소 놀라운 일이라고 생각합니다. 그러나 이 해결 방법을 약간 "정규화"하고 crate:: 가 항상 선행 :: 와 함께 사용되도록 강제하는 것이 좋습니다(물론 use 제외). 당신이 지적했듯이 이것은 ::std::x::y 와 같은 경로로 대칭성을 증가시키고 진정한 상대 경로( self:: / super:: / something_in_scope:: 대해 접두사가 없는 형태를 남깁니다

우리는 이것을해야합니까? 허용 crate::x::y 비에서 use 경로가 있습니다 crate 종류의 마법의은, 시행하면서 ::crate::x::y 우리 '의존성과 같은 수준에 스코프이다 어쨌든 암시하려고합니다.

@rpjohnst

crate:: 가 항상 선행 :: 와 함께 사용되도록 강제합니다(물론 사용 제외).

이것은 적어도 처음에는 합리적일 수 있습니다(나중에 이것을 완화하는 것을 방해하는 것은 없습니다).

저는 use extern::bar::foo 또는 use crate::bar::foo 구문을 좋아하지 않습니다. 매우 시끄러운 것 같습니다. 나는 이것을 위해 약간의 설탕을 선호합니다. 나는 이것을 위해 extern bar::foo 를 제안합니다.

묵시적 규칙을 하나 더 추가하는 것은 어떻습니까? extern crate를 루트 네임스페이스로 자동으로 가져오고 더 일치하는 경로 표현을 만듭니다.

예

1. 우리의 프로젝트 구조는 다음과 같습니다.

src
|--lib.rs
|--foo.rs
|--푸
|----|--bar.rs

1. 다음과 같이 Cargo.toml에서 종속성을 구성합니다.
   [dependencies] serde = "3.0.0"

2. mod bar 를 mod foo 에 추가하고 mod foo 를 lib.rs에 추가하고,

3. lib.rs에서 finlib 함수를 정의하고 foo.rs에서 finfoo 함수를 정의하고 bar.rs에서 finbar 함수를 정의합니다.

extern 크레이트의 스코프를 크레이트의 최상위 모듈로 만들면 어디에서나 이와 같은 코드를 작성할 수 있습니다.

완전한/적격 경로

::serde::Deserialize
::serde::x::y
::finlib                            // not ::crate::finlib
::foo::finfoo                   // not ::crate::foo::finfoo
::foo::bar::finbar           // not ::crate::foo::bar::finbar

상대 경로는 다음과 같이 작성하십시오.

serde::Deserialize      // no need to write `use serde`
serde::x::y                   // no need to write `use serde`
finlib                          
foo::finfoo                  
bar::finbar       

우리는 먼저 현재 모드 범위에서 serdefinlibfoo를 찾습니다. 저녁 모드에서 조회를 찾지 못하면 루트 네임스페이스까지 찾습니다. 이름 충돌이 있는 경우 대신 전체 경로를 씁니다.

또한 foo.rs에서 self::bar::finbar 를 사용하여 이름 조회를 피할 수 있습니다.

이에 대해 논의한 이전 스레드를 찾을 수 없지만 컴파일러는 그런 식으로 작동했고 이름 확인에 큰 문제를 일으켰습니다. IIRC @pcwalton 또는 @arielb1 이 더 많이 알고 있을 것입니다.

이 모호성에 대한 가장 쉬운 해결책은 crate-local 가시성 수정자에 대해 다른 키워드를 사용하는 것입니다(예: pub(crate) 대체). 예를 들어, 이전 RFC 토론에서 여러 번 제안된 local 입니다. 그러면 struct S(local :: x :: y) 는 struct S(crate :: x :: y) 다릅니다.

이는 <visibility> <absolute path> 와 <relative path starting with the new keyword> 사이에 또 ​​다른 모호성을 소개합니다. 왜냐하면 새 키워드는 문맥적이어야 하기 때문입니다.

@rpjohnst 아 젠장.. 근데 그게 시대가 해결하도록 설계된 문제가 아닌가? 예: 현재 에포크에서는 pub(crate) 만 사용하고 다음 에포크에서는 보다 '인체 공학적'인 새로운 비문맥 키워드를 도입합니다.

@neon64 네, 하지만 RFC는 새로운 시대가 필요하지 않다고 주장합니다. 그 주장은 성립하지 않는 것 같다.

현재로서는 crate 가시성 또는 crate:: 경로를 사용하는 코드가 없으므로 새 코드만 영향을 받습니다. 해상도를 선택하고 고수하는 한 호환성 문제는 없습니다.

나에게 일어난 한 가지, 사과와 함께 토론 중 하나에서 이전에 제기된 적이 있다면(지난 몇 번에서 본 기억이 없습니다):

최신 제안에서 crate:: 는 "in this crate"를 참조하고 self:: 는 "in this module"을 참조합니다. 이것은 수보다 약간 일관성이 잠재적으로 덜 명확하다 : 한 가지에 대해 self "이", 그것은 본질적으로 명백하지를 말한다 "이 무엇을", 그리고 반대로,이 사실에서 self:: 는 " 이 모듈"을 의미하며 crate:: 가 " 다른 상자"를 의미할 수 있다고 추론할 수 있습니다. 이는 실제로 스레드에서 언급된 혼동입니다.

한 가지 가능한 솔루션은 단계적으로하는 것입니다 self:: 찬성 mod:: . 그러면 crate:: 가 "가장 가까운 엔클로징 상자에서"를 의미하고 mod:: 가 "가장 가까운 엔클로징 모듈에서"를 의미하며 명확하고 일관됩니다. 우리는 또한 잠재적으로 해결할 수있는 문제를 그것이 내에서 항목을 참조 할 수 없습니다 경우 fn 도입하여 전혀 자격을 갖춘 방식으로 범위 fn:: 접두사, 가장 가까운 바깥 쪽의 "에 놀라지 평균 fn ". (더 나아가 trait:: 또는 impl:: 와 같은 것이 있는지 여부에 대해 생각하지 않았습니다.)

@glaebhoerl 흥미로운 제안입니다. 개인적으로 절대 경로에 대한 새로운 구문을 도입하고

경로에 대해 다음 문법이 있다고 상상해보십시오.

Path = AbsolutePath | RelativePath
AbsolutePath = 
    | `@` ID? 
    | `@` ID? `::` RelativePath
    | `self` :: RelativePath
    | `super` :: RelativePath
RelativePath = ID (`::` ID)*

이 문법에서는 @crate 로 시작하여 다른 크레이트의 항목을 참조할 수 있습니다. 예를 들면 다음과 같습니다.

use <strong i="13">@std</strong>::collections::HashMap;

예를 들어 @ 만 사용하여 로컬 크레이트를 참조할 수 있습니다.

use @::something::in::my::crate;

(그리고 use self::something 는 좋든 나쁘든 오늘날과 동일하게 유지됩니다.)

이것에 대한 좋은 점은 절대 경로가 상대 경로와 완전히 구별된다는 것입니다. 즉, 이제 use 에서 코드로 경로를 복사하여 붙여넣을 수 있고 작동하는 바람직한 속성이 있습니다.

fn foo() {
    <strong i="24">@std</strong>::cmp::min(a, b) // OK
}

이것은 오늘날 사실이 아니므로 때때로 나를 혼란스럽게 합니다.

또한 crate 주변의 구문 분석 모호성을 제거하여 pub Foo(crate @::MyType) 또는 무엇이든 할 수 있으며 잘 작동합니다.

(일반적으로 상대 경로와 절대 경로가 동일한 :: 로 시작하는 것이 여러 번 고통의 원인이 된 것이 사실입니다.)

내가 모르는 한 가지는 @foo 가 최고인지 여부입니다. 내가 생각 하고 [] .

• [std]::collections 및 [crate]::collections // []::collections 너무 이상해 보입니다.

나는 정말로 우리가 단지 길을 위해 어떤 새로운 인장을 도입해야 한다고 생각하지 않습니다. 강제 선도적 인 :: 에서 ::crate::foo 주소 @glaebhoerl에 충분하다의 의견과 해석의 모호성을 제거합니다. 또한 crate:: 에 대한 의도된 멘탈 모델에 더 밀접하게 맞습니다. 이는 self:: 와 같은 경로 접두어가 아니라 현재 상자의 이름을 대신하는 것입니다.

(일반적으로 상대 경로와 절대 경로가 동일한 :: 로 시작하는 것이 여러 번 고통의 원인이 된 것이 사실입니다.)

이게 무슨 말인지 잘 모르겠습니다. :: 시작하는 상대 경로가 없다고 생각합니까?

@nikomatsakis @glaebhoerl 귀하의 제안이 마음에 드는지 여부에 관계없이 (실제로 둘 다 함께 살 수 있습니다), RFC를 고수할 수 있습니까? 그것은 많은 방법으로 앞뒤로 논의되었으며 다시 토론을 시작하는 것이 누군가에게 도움이 될 것이라고 생각하지 않습니다. 총 82명의 사람들이 최신 RFC의 스레드에 대해 논평했으며(이전에도 꽤 많은 논의가 있었습니다) 많은 사람들이 이에 대해 매우 강하게 느끼고 있습니다. 이 시점에서 변경 사항을 검토할 기회를 주지 않고 제안서의 마지막 변경 사항을 몰래 넣는 것은 부당하다고 생각합니다.
특히 #44721 @nikomatsakis가 "구현에 대해서만 이야기합시다"라는 인수로 기능에 대한 토론을 종료 했기 때문에 약간 혼란스럽습니다.

@ 표기법과 [] 표기법이 둘 다 제안되었지만(저는 둘 다의 지지자입니다) 결국 사용자의 부정적인 반응으로 인해 적어도 그것이 제 느낌이었습니다. .

선행 :: 가 선행 식별자에서 시작하고 내부 :: 가 있는 경로와 혼동될 수 있는 경우가 전혀 없더라도 시각적으로 매우 뚜렷하지 않습니다.

또한 덜 암시적입니다. @ 가 더 나은 니모닉입니다. 선행 :: 하면 선행 / 루트를 의미하는 파일 이름 경로와 같은지(Unix 시스템을 사용하는 경우) 표준 약어인지, 선행 표시가 없는지 궁금해야 합니다. 그것은 "상대적이기 때문에 이름을 생략했습니다"를 의미합니다. 잠시 생각해보면 전자가 더 타당하다는 것을 알 수 있지만 요점은 잠시 생각이 필요하다는 것입니다. @ (또는 일부)는 컴파일러와 코더 모두에서 즉시 구별할 수 있으므로 현재 진행 중인 상황을 더 쉽게 즉시 파악할 수 있습니다.

선행 @ 가 선행 :: 보다 구별 하기 쉬운 방법은 무엇입니까? :: 는 이미 Rust와 C++ 모두에서 확립된 메커니즘입니다!

@rpjohnst - 나는 당신이 대답하는 바로 그 문장에서 어떻게 말했습니다! @ 는 시각적으로 구별됩니다. 확장하려면: 그것은 당신에게 튀어나옵니다. 토큰 스트림의 멘탈 모델에서 리더와 내부 위치가 혼동될 위험이 없습니다.

@ 는 의미가 전혀 없는 완전히 새로운 토큰이며 파악하는 데 "잠시 생각"보다 훨씬 더 오래 걸립니다. 내부 :: 대해 선행 :: 를 혼동하는 것은 처음에는 문제가 되지 않습니다. 누군가 선행 :: 이라는 아이디어를 기각하기 위해 "잠시 생각"을 해야 할 이유가 없습니다

@rpjohnst - :: 의미하는 바에 대한 충분한 교육을 받은 경우 귀하의 진술은 사실입니다(C++ 또는 Rust 경험에 의해 제공됨). 나는 학습 가능성과 본질적인 차이에 대해 이야기하고 있었습니다. "다른 맥락에서 사용되는 동일한 기호"는 "고유한 기호"만큼 구별할 수 없습니다.

나는 허용 가능한 대안이 있는 이와 같은 사용 사례에서 @ 를 고유한 기호로 태울 가치가 없다는 주장을 받아들일 수 있습니다.

@Ichoran : Rust 문법에 특정 의미( @ )에 대한 새 토큰을 추가하는 것은 가볍게 받아들일 단계가 아니라고 생각합니다. 그리고 @nikomatsakis 를 사용하여 그렇게 하는 데 너무 가깝다는 약간의 의심이 @ 토큰이 많은 장소에 게재 될 수 있습니다). 또한 Rust 코드의 복잡성에 대한 인식에 어떤 영향이 있는지 궁금합니다. 예를 들어 C++에 익숙하지 않은 초보자에게는 Rust가 매우 바로크적이고 위협적인 표기법을 가진 언어라고 믿습니다(그러나 이에 대한 연구는 없습니다). 올해의 전략적 목표 중 하나는 학습 가능성을 최적화하고 Rust의 접근 가능성을 최적화하는 것입니다. 그래서 우리는 @ 좋아할 때 이것을 고려해야 할 것입니다. 왜냐하면 직관은 그것이 코드에서 눈에 띄기 때문입니다( @rpjohnst는 이것이 정당한 질문이라고 생각합니다). 이 말의 의미가 충분히 명확합니까?

(나는 Rust 문법에 대한 논의를 자세히 따를 시간이 없기 때문에 내가 주장한 모든 것을 자유롭게 수정하거나 명확히 하십시오.)

@est31

귀하의 제안이 마음에 드는지 여부에 관계없이(실제로 둘 다 살 수 있습니다), RFC를 고수할 수 있습니까?

기본적으로 동의합니다. 지금 당장은 큰 토론에 참여하고 싶지 않습니다. 결국 임프 기간입니다! -- 하지만 저는 @ 아이디어를 배경에서 끓어오르게 하고 싶었습니다. 부분적으로는 제가 건망증이 있는 경향이 있기 때문에 기록하는 것이 나중에 기억하는 데 도움이 됩니다.

제 느낌은 이 시점에서 해야 할 옳은 일은 다음과 같습니다.

• 작성된 대로 대략적으로 RFC를 구현합니다.
  
  
  
  • 예를 들어, 구문 분석의 모호성을 해결하기 위해 절대 경로에 대해 @rpjohnst 의 제안 ::crate 을 채택하고 싶을 수 있습니다. 이는 매우 작은 델타처럼 보이고 실제로는 전반적으로 일관성을 증가시키기 때문입니다.
  
  
• 사용 경험을 얻으십시오.
• 그 동안 떠오른 대안을 염두에 두고 설계를 재검토하고 최종 안정화 결정을 내립니다.

이것은 내가 명확하게 밝히지 않은 것 같지만 내 의견을 쓰려는 의도였습니다. 아마도 개인 파일에 보관하는 것이 더 나았을 것입니다. :여자_어깨를 으쓱:

편집: 또한 @ 및 [] 가 더 일찍 제기되었다는 것을 알고 있습니다. 그러나 @::foo 표기법이 현재와 관련하여 이전에 언급되었는지 여부는 기억나지 않습니다. 나무 상자. 그래서 나는 그 아이디어의 저자를 주장하려는 것이 아닙니다.

OTOH, 내가 언급한 아이디어는 이전에 제기되지 않았으며 RFC의 확장이라기 보다는 RFC를 수정한 것이 아닙니다. 또한 "절대 경로에 대한 최종 구문입니다. 다양한 옵션을 실제로 시도할 수 있는 컨텍스트에서 더 많은 자전거 이동을 수행해야 합니다." 문제 본문에 미해결 질문 으로 명시되어 있습니다 . 일반적으로 승인된 RFC에 대해 다시 소송을 제기하는 것을 피해야 한다는 데 동의하지만, 이 상황이 예를 들어 포괄적 범위에서 있었던 상황과 비교할 수 없다고 생각합니다.

이 토론 스레드도 참조하십시오.

https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678

Great Modules Adventure의 다른 에피소드에 오신 것을 환영합니다! 우리가 마지막으로 만났을 때 우리의 용감한 모험가들은 마침내 RFC #2126을 수락하고 전설의 땅에 왔습니다. 그곳에서 그들은 잠시 휴식을 취하고 임프 기간을 시작할 준비를 했습니다. 그 기간 동안 많은 작업이 이루어졌고 실제로 모듈 시스템의 개요가 구현되었습니다. 그러나 여전히 해결해야 할 몇 가지 사소한 질문이 있었습니다. 그리고 그것은 우리를 이 토론 스레드로 인도합니다.

덜 화려한 언어로: impl 기간 동안 "경로 및 가시성을 명확하게 하고 간소화" RFC(많은 관련 RFC와 함께)를 구현하는 데 많은 진전이 있었습니다. 사실, 우리는 거의 너무 많은 진전을 이루었습니다. 우리는 몇 가지 다른 변형을 구현했으며 우리가 진정으로 원하는 것에 대해 논의를 시작하고 싶습니다.

나는 이 훌륭한 작업을 언젠가 안정화할 수 있기를 원합니다 =) 그리고 그것은 우리가 변종 중 하나를 선택해야 할 것입니다...그러므로 스레드가 필요합니다.

개인적으로 저는 @nikomatsakis가 언급한 @ 구문의 팬입니다. 간결하고 합리적으로 자명합니다. 우리는 그래서 더, 여기에 새로운 구문의 도입 일종의 가지고 같은 예약 된 이름이 아닌 특수 문자거야 crate (우)를.

특히 https://github.com/rust-lang/cargo/issues/1311 이 이제 해결된 경우 두 번째 외부 포인터를 다룰 수 있는 위치에 있는 것 같습니다(사실 이미 닫혀 있어야 함). 약간의 멘토링과 @ 대 crate 구문에 대한 결정으로 이 문제를 해결할 수 있습니다. 생각?

구현되지 않은 두 개의 린트에 대한 추적 문제를 추가했습니다.

약간의 호환성 문제가 있는 것 같습니다. extern crate 가 암시적이면 해당 작업을 수행하는 데 중요한 변경 사항이 있습니다. extern crate 는 크레이트를 강제로 연결합니다. Cargo.toml에 추가 크레이트를 지정하지만 깔끔하게 함께 연결되지 않는 lib.rs는 지정하지 않으면 오류가 발생할 수 있습니다(예:panic=unwind 크레이트와 패닉=abort 또는 동일한 기호를 내보내는 크레이트). 이것이 문제가 없는 파손으로 결정되었습니까?

우리에게 작은 호환성 문제가 있다는 생각이 듭니다. extern crate를 암시적으로 만들려면 해당 작업을 수행하는 것과 관련된 주요 변경 사항이 있습니다. extern crate는 크레이트를 연결해야 합니다. Cargo.toml에 추가 크레이트를 지정하지만 깔끔하게 함께 연결되지 않는 lib.rs는 지정하지 않으면 오류가 발생할 수 있습니다(예:panic=unwind 크레이트와 패닉=abort 또는 동일한 기호를 내보내는 크레이트). 이것이 문제가 없는 파손으로 결정되었습니까?

지금까지 내가 본 유일한 해결책은 해당 크레이트에서 무언가를 가져올 때만 크레이트를 암시적으로 연결하는 것이지만 여전히 몇 가지 문제가 있습니다. 특정 네이티브 라이브러리에 링크하거나 네이티브 라이브러리의 일부 종속성을 해결하기 위해 #[no_mangle] 심볼을 내보내는 것과 같이 단순히 임포트할 녹 기호를 내보내는 것 외에 크레이트가 기능을 노출할 수 있는 방법이 많이 있습니다. extern crate 가 제거되면 이러한 상자를 강제로 연결하는 유일한 방법은 필요에 따라 가져오기 위해 위약 녹 기호를 내보내도록 하는 것입니다. extern crate 를 고수하는 대신 그러한 해결 방법을 사용하도록 강요하는 것이 더 나은 생각이라고 누가 생각했는지 모르겠습니다.

예, 우리는 Firefox에서 이 패턴을 명시적으로 사용합니다 -- 링크되어야 하는 크레이트에 대한 extern crate 문을 포함하는 최상위 gkrust 크레이트가 있습니다(이들은 Firefox가 호출하는 Rust로 작성된 extern C 함수를 노출합니다)

이것을 강제하기 위해 사람들이 lib.rs에서 use cratename; 를 요구하는 것과 함께 여전히 작동하도록 만들 수 있습니다.

이 목적을 위해 #![link_crates(stylo,webrender)] 속성을 갖는 것은 어떻습니까? extern crate 와 달리 이름 트리에 크레이트를 추가하지 않습니다. 새 이름을 지정하면 독자에게 연결용 상자만 포함하고 해당 명령문은 제거해서는 안 되지만 extern crate 는 제거해야 함을 분명히 나타냅니다.

그러면 반대의 문제가 해결됩니까?

아, 2015 에포크의 사람들은 에포크를 전환하지 않고도 코드를 업그레이드할 수 있습니다.

그러나 이것은 _모든 사람이_ link_crates 키를 사용해야 한다는 것을 의미합니다. 그것은 이상적이지 않습니다.

이 목적을 위해 #![link_crates(stylo,webrender)] 속성을 갖는 것은 어떻습니까? extern 크레이트와 달리 이름 트리에 크레이트를 추가하지 않습니다.

링크 전용 크레이트, Rust 기호가 있는 크레이트 또는 둘 다로 사용할 수 있는 크레이트는 어떻습니까?

@whitequark 해당 크레이트의 심볼을 사용하면 이미 지금처럼 무료로 연결을 얻을 수 있습니다. 속성은 사용 사이트에 있으므로 사용자는 크레이트 사용 방법을 결정합니다.

@Manishearth

그러나 이것은 모든 사람이 link_crates 키를 사용해야 한다는 것을 의미합니다. 그것은 이상적이지 않습니다.

아니오. 제 제안을 충분히 표현하지 못했습니다. use cratename::item; 가 link_crates 와 같은 효과를 갖는 부분을 그대로 유지하고 싶습니다. link_crates 기능은 상자의 항목이 필요하지 않지만 연결이 필요한 경우 에만 사용해야

나는 단지 그 목적을 위해 코드에 use cratename; 를 갖는 것이 좋다고 생각하지 않습니다. 왜냐하면 그것이 lints와 (가장 중요한) 코드 리더/라이터를 혼란스럽게 할 것이고 따라서 합법적인 전용 기능이 있어야 한다고 생각하기 때문입니다. (그러나 드물게) 사용 사례.

@est31 link_crates 구문에 대한 Bikeshedding을 속성으로 사용하는 대신 extern crate foo; 와 같은 작업을 수행하지 않겠습니까?

@retep998
좋은 생각! :웃다:
https://github.com/rust-lang/rfcs/pull/2166 은 연결 전용 크레이트의 범위/모듈에 크레이트 이름을 가져오는 것을 방지하기 위해 extern crate foo as _; 도 도입했습니다.

@est31 link_crates 구문에 대해 Bikeshedding을 속성으로 사용하는 대신 extern crate foo;와 같은 작업을 수행하는 것이 어떻습니까?

요점은 장기적으로 extern crate 구문을 제거하는 것입니다.

@alexreg 요점은 일반적인 경우에 필요하지 않게 만드는 것입니다. 그렇다고 해서 완전히 근절되어야 한다는 의미는 아닙니다. 아마도 Rust 항목을 사용하지 않고 연결해야 하는 상자의 경우에는 여전히 좋은 솔루션일 것입니다. (어쨌든 컴파일러가 이전 시대를 지원하는 한 계속 유지됩니다.)

@SimonSapin 그러나 앞으로 나아가면 특별한 경우가 될 것이므로 아마도 특별한 구문을 사용하는 것이 의미가 없으며 속성(위에서 제안한 대로)이 더 의미가 있을 것입니다.

나는 여전히 use foo 또는 use foo as _ 로 충분해야 한다고 생각합니다.

@Manishearth에 동의합니다.

extern crate; 에 대한 내 견해 요약:

장점:

• extern crate 는 라이브러리 상단에서 사용된 상자의 포괄적인 목록을 제공합니다. 이 Cargo.toml이지만,이 예제가 있다면 그것은 당신에게 수입에 상자의 목록을 제공으로 이것은 매우 유용하기 때문에 지금은 정상 상자와 함께이는 관련이 없습니다. 예제가 개발 종속성의 하위 집합을 가져오기만 하면 어떻게 될까요? 이것은 새로운 크레이트의 API를 알아내려고 할 때 높은 이점이 있습니다. 일명 학습성 이점입니다. 반면에 extern crate 는 크레이트의 아무 곳에나 나타날 수 있으므로 목록이 완전할 필요는 없지만 예를 들어 이것은 덜 관련성이 있다고 언급할 수 있습니다. 우리는 원할 경우 항상 크레이트 루트에서만 작동하도록 extern 크레이트를 변경할 수 있습니다.

단점:

• extern crate 는 크레이트를 추가할 때 입력해야 할 항목이 더 많기 때문에 약간의 성가심입니다. 이것이 많은 사람들이 extern crate 에 반대하는 이유라고 생각하지만 저에게는 동기를 부여하는 이유가 아닙니다.
• extern crate 를 거래의 일부로 봅니다. 우리는 extern crate 포기하지만 자체 상자에서 가져오기와 외부 상자에서 가져오기를 구분할 수 있습니다. 이것은 훨씬 더 유용한 기능이며 코드 예제/테스트에서 IMO의 학습 가능성 단점을 능가합니다. 이것이 내가 extern crate 제거에 동의하는 동기를 부여하는 이유입니다.

extern crate는 라이브러리 상단에서 사용된 상자의 포괄적인 목록을 제공합니다. 이제 일반 상자에서는 Cargo.toml만큼 관련성이 없지만 예제가 있는 경우 가져올 상자 목록을 제공하므로 매우 유용합니다.

이것이 여기서 논의와 어떻게 관련이 있는지 모르겠습니다. 이것은 이미 병합된 RFC에 대한 포인트입니다.

@Manishearth 여기에서 @retep998 에게 extern crate를 보관할 것을 제안한 사람에게 더 많이 회신했습니다. 그리고 아니요. 이미 병합된 RFC에 반대한다고 해서 해당 포인트가 불법적이거나 관련이 없는 것은 아닙니다. 결정의 장점과 단점을 반성하고 알아야 합니다. 예를 들어 lib.rs 에서 extern crate를 제거할 수 있지만 인체 공학 및 학습 용이성 이점을 위해 hello_world.rs 로 유지합니다(저자가 아닌 라이브러리 사용자를 위해).

논의되고 있는 것(당신이 답장하는 Peter의 코멘트에서)이 링크 전용 크레이트이기 때문에 그것은 부적절합니다. "모든 외부 상자를 맨 위에 나열"하는 틈새 사용 사례는 미미한 이점입니다. 특히 링크 전용 크레이트가 아닌 _not_ 종속성이 있는 경우(이것은 Firefox에서는 사실이 아니었지만 지금은 그렇습니다).

귀하의 요점이 암시적 extern crate를 테스트에 적용하지 않는 것(특히 링크 전용 크레이트에 대한 것이 아님)에 대한 보다 일반적인 것이라면 흥미로운 요점이지만 실제로는 동의하지 않습니다. 코드의 절반에서만 사용하면 혼란스럽습니다.

그래서 내가 틀리지 않았다면 여기에 남은 유일한 구현 지점은 #48719입니다. 지금 그것을 해결하는 사람이 있습니까? 그렇지 않다면 가볼 수 있을 것 같은데...

예, #50260에서 무언가를 시도하고 있습니다.

2018년 4월 28일 토요일 오전 9시 15분 Alexander Regueiro [email protected]
썼다:

그래서 내가 틀리지 않았다면 여기에 남은 유일한 구현 포인트는

48719 https://github.com/rust-lang/rust/issues/48719 . 누구인가

그것을 지금 해결? 그렇지 않다면 가볼 수 있을 것 같은데...

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

48722가 완료되었습니다. @Manishearth OP를 업데이트할 수

@mark-im @Manishearth https://github.com/rust-lang/cargo/issues/1311 도 완성 되었으니 그 점을 체크박스로 바꿔서 좋을 것 같습니다. 그래도 궁금합니다. Cargo를 사용하지 않을 때의 접근 방식은 어떻게 되나요? (제정신이 있는 사람이 화물을 피한다는 것은 아닙니다...)

@alexreg Cargo가 Rustc에게 크레이트의 이름을 바꾸도록 지시하는 데 사용하는 메커니즘은 Cargo를 사용하지 않는 사람들도 동일하게 액세스할 수 있습니다: --extern name_rustc_sees=path_to_dep.rlib .

https://github.com/rust-lang/rust/pull/47992 가 실제로 도착하면 전체 구현 단계가 곧 완료될 것 같습니다. 내가 뭔가를 놓치고 있습니까? 할 일이 남아 있는 경우 이 작업을 진행하는 데 도움이 되어 기쁩니다.

네, 진행 중입니다. 나는 내가 일찍 할 가능성이있는 그것을 마무리해야합니다.
다음주.

2018년 5월 3일 목요일 오후 7:51 Alexander Regueiro 알림 @github.com
썼다:

곧 전체 구현 단계를 완료할 것 같습니다.

사실 47992 https://github.com/rust-lang/rust/pull/47992 땅입니다. 이다

누락된 것이 있습니까? 문제가 있는 경우 이 작업을 진행하는 데 도움을 드리겠습니다.
할 일이 남아 있습니다.

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

@Manishearth 좋은 물건.

@aturon with https://github.com/rust-lang/rust/pull/50260 착륙했습니다. 모든 것이 구현되었습니까?

RFC 이후 에 제안된 계획에 대한 링크를 얻은 사람이 있습니까? 실제로 구현된 것과 더 유사한 것은 무엇입니까? (여기서 --extern 상자의 수입이 서곡에 추가되는 등)

그것을 찾았습니다: https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/205

이것은 매우 중요한 변경 사항이므로 RFC를 업데이트해야 합니까?

RFC는 일반적으로 업데이트되지 않습니다. 그들은 최종 사양이 아닙니다. 그들은
합의 구축 도구.

2018년 6월 18일 월요일 오후 9시 43분, 누구? 나?! [email protected] 은 다음과 같이 썼습니다.

이것은 매우 중요한 변경 사항이므로 RFC를 업데이트해야 합니까?

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/44660#issuecomment-398247665 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AABsij-Iwwb7vf4qBrsq9KFFqhuIbkVBks5t-Fc3gaJpZM4PaPWi
.

@mark-im 그 담론 포스트는 RFC의 정신 안에 있습니다. RFC 요약을 해당 게시물과 비교하면 약간의 세부 사항을 제외하고는 대부분 동일합니다. 팀이 완전히 다른 변경을 하기로 결정한 RFC가 있었지만 이것은 그 중 하나가 아닙니다.

다 맞는 말이지만 이 모든 것이 한 곳에 있으면 좋을 것입니다. 나는 그 물류 문제를 이해하지만 ...

🔔 🔔 2018년 초

@aturon 마지막 업데이트와 모듈 작업 그룹의 마지막 회의 결과 https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/205 , 구체적으로 " 두 가지 변형이 있는 단일 핵심 제안으로 좁혀졌습니다." 내가 아는 한 그것은 여전히 ​​사실이었습니다. 나는 nightly가 기능 플래그를 통해 둘 다에 대한 실험을 지원하기 위해 둘 다 구현했다는 인상을 받았습니다.

에디션은 두 가지 변형 중 하나를 선택하고 기능 플래그 없이 지원하도록 선택하고 에디션 가이드에 문서화한 것 같습니다. 어디에서 논의되었습니까? 내가 말할 수 있는 한, 모듈 작업 그룹이나 lang 팀이 거기에 관여하지 않았기 때문입니다.

2018년 미리 보기에서 작성된 새로운 제안은 https://internals.rust-lang.org/t/relative-paths-in-rust-2018/7883 을 참조 use 문과 코드에서 경로의 직접 사용 모두에서 동일한 이름 확인을 사용합니다.

안녕하세요, ::some::path 대 crate::some::path 에 대한 내 2센트 - 저는 후자를 선호합니다. 주로 일반 영어로 읽기 쉽고 왼쪽에 매달린 구두점을 남기지 않기 때문입니다.

여기에서 보시고 피드백을 남겨주세요!

이것이 당신이 의미하는 바였기를 바랍니다. 모든 pub(crate) 가 crate 로 변경된 선물 상자에 대한 큰 변경 사항을 검토한 후 수입 및 가시성 모두에서 crate 를 사용하는 것이 더 확실합니다. 수정자는 부자연스럽고 혼란스럽게 느껴집니다.

crate enum Either<T, U> {
    A(T),
    B(U),
}

두 가지를 함께 사용할 때 특히 혼란스럽습니다.

crate use crate::foo;

내가 린트 문제에서 우리 모두가 전환하도록 하려고 하는 것을 언급했듯이, 그것은 나를 매우 슬프게 할 것이고, 아마도 나는 반대를 수행하기 위해 구현된 제3자 린트가 내가 유지 관리하는 라이브러리에서 사용되기를 원할 것입니다: 사람들을 멈추는 것 pub(crate) 를 crate 합니다.

(참고: 일관성에 좋은 것처럼 보이는 변경 사항의 다른 부분에 대해서는 언급하지 않고 pub(crate) 에서 일반 crate 로의 변경 사항 만 언급합니다.)

@seanmonstar 다음 에디션 미리보기에서 모듈 시스템에 대한 추가 변경 사항이 제안됨에 따라 crate::foo 가 더 희귀해질 것으로 기대하고 있으며 crate use crate:: 는 특히 드문 경우처럼 보입니다.

초기 2018 미리 보기의 모듈 시스템을 사용하면 상자에 대한 더 깊은 참조를 위해 crate:: 를 작성해야 합니다. 제안 된 모듈 시스템으로 만 필요할 것 crate:: 당신의 상자에서 참조 최대에 (예를 들어, foo.rs에서 lib.rs, 또는 foo.rs에 foo는에서 / bar.rs),하지만를 아닌 상자에서 아래 참조에 대한 (예를 들어, lib.rs에서 foo.rs, 또는 foo.rs에서 foo는 / bar.rs에). 그리고 일반적으로 재수출( pub use 또는 crate use )을 통해 상위 모듈의 더 깊은 모듈에서 무언가를 다시 내보낼 것으로 예상합니다.

따라서 일반적으로 crate use crate::foo; 를 보고 놀랐습니다.

그러나 내가 작업하고 있는 프로젝트에는 정확히 이 시나리오가 있습니다. 여러 "일반" 헬퍼를 포함하는 모듈이 있고 기본 특성 + 결합자를 정의하는 또 다른 모듈이 있습니다. 이 모듈은 몇 가지 일반 헬퍼를 사용하기 때문에 나무 상자:

현재:

// in filter/mod.rs
pub(crate) use ::generic::{Combine, Func};

// in filters/foo.rs
use ::filter::{Filter, Func};

린트가 이것을 다음과 같이 변경하기를 원할 것입니다.

// in filter/mod.rs
crate use crate::generic::{Combine, Func};

그래서 저는 아무도 만나지 않을 가설을 세우려고 하지 않았습니다. 진짜야

@seanmonstar에 전적으로 동의합니다. 우리가 해야 하는 경우가 아니면 이 키워드를 오버로드하지 말자.

예, _보통_ 재수출하는 것이 옳습니다. 그러나 Sean이 설명하는 것처럼 재수출되는 _측면도 마찬가지입니다. 그것은 파일이 꽤 멋지게 분할되어 있기 때문에 서보 미디어 크레이트에 대해서도 수행하는 것을 고려하고 있지만 이는 모든 노드 구현에서 많은 공통 가져오기를 의미합니다.

모듈에서 사용되는 것을 계속 선언하고 아마도 크레이트 속성으로 명시적으로 사용해야 할 수 있습니까? 소스 파일을 보고 그 안에 있는 범위를 알 수 있는 것을 선호합니다. 소스 파일의 시작 부분에 몇 줄의 루트 수준 가져오기가 있으면 범위 내에서 모든 외부 종속성을 암시적으로 포함하는 것보다 실제로 내부에서 일어나는 일에 대한 컨텍스트를 제공하고 리팩토링할 때 크게 도움이 됩니다.

내 상자 중 하나에서 변환을 시도한 후 이에 대해 이야기하는 것을 본 다른 사람들처럼 언급하고 싶었습니다. pub(crate) 대신 가시성 수정자로 crate 를 사용하는 것이 확실하지 않습니다. 개선. 여기서 내 추론은 상자 이름이 꽤 널리 사용되며 항목 앞에 붙이면 약간 지저분해지기 때문입니다(Java의 public static void main() 와 같은 일부 언어에서 사용하는 키워드 수프를 생각나게 합니다. 적어도 Rust는 끝에 반환 유형이 있습니다). pub(crate) 는 pub 를 최소한 유지하여 crate 가 이 컨텍스트에서 가시성을 처리한다는 것을 더 분명하게 만듭니다.

다음은 가시성 수정자와 경로 모두에서 crate 키워드를 결합한 또 다른 인스턴스입니다. 이는 crate use crate... 인스턴스보다 훨씬 더 가능성이 높아 보입니다.

현재의:

pub(crate) struct Bar {
    pub(crate) foo: ::Foo,
}

pub(crate) struct Baz(pub(crate) ::Foo);

이 추적 문제의 변경 사항:

crate struct Bar {
    crate foo: crate::Foo,
}

crate struct Baz(crate crate::Foo);

저는 개인적으로 새로운 것이 현재 방식보다 더 혼란스럽다고 생각합니다.

pub(crate) 를 crate 로 변환하기 위해 RFC를 처음 읽었을 때 나는 그것이 당연하다고 생각했습니다. pub(crate) 는 이 영역에서 관련된 Rust 구문의 나머지 부분에 비해 매우 이상해 보입니다.

하지만...

후 약간의 피스톤 게임을 변환 녹 2018 그것에게 먼저 손을보고, 나는 s와 다른 의견 '@seanmonstar에 공감 해요 인정해야한다는 갖는 베어 crate 사방에 뿌려인지 부조화했다. 시간이 지나면 자연스럽게 익숙해질지 모르겠습니다.

다른 사람들이 말했듯이 키워드가 두 컨텍스트에서 매우 다른 것을 의미하는 것처럼 느껴집니다 .

use crate::menu::{Sound, Volume};

crate mod color;

...

/// A type for storing text and an associated color it should
/// be drawn as.
crate struct ColoredText {
    crate color: types::Color,
    crate text: &'static str,
}

이 제안의 나머지 부분(모듈 시스템 업데이트)이 정말 마음에 든다는 점을 분명히 하고 싶습니다.

나는 pub(crate) 가 약간 무겁고 이상하게 보이지만, 또한 crate 가 약간 어울리지 않는 느낌이 든다는 점에 공감합니다.

여기서 crate 를 재사용하는 대신 다른 키워드를 고려할 수 있습니까?

@neon64 제안된 internal 합리적으로 들리지만 다른 것도 있을 수 있습니다. Rust 2018에서 키워드를 추가할 수 있기 때문에 이제 이것을 고려할 기회가 있습니다.

internal 가 pub(crate) 보다 무거워 보입니다. 더 짧지 않고 새로운 키워드입니다.

int 어떻습니까? :피

내부( ins ), 내부( int ), 보호( pro ), 로컬( loc ), 비밀( sec ), 내부( inn ) crate 키워드에 대한 대안이 많이 있습니다.

int 가 C/C++ 개발자에게 혼란을 줄까요? (정수 키워드)

프로그래머로서 pub을 볼 때 공개로 취급합니다. 다른 가시성 수준을 도입하려면 일관성을 유지하기 위해 형용사가 필요합니다. 내가 기억하는 한 pub은 처음에 publish를 의미했으며 두 경우 모두 pub(crate)가 더 자연스럽게 느껴집니다. Crate는 그에 대한 이상한 키워드입니다.
pub(crate)를 그대로 두거나 형용사에서 약어를 추가하는 것이 낫다고 생각합니다.

또한 네이밍의 어려움은 펍이 줄임말이라는 점에서 비롯된 것이라고 생각하는데, 공적이라면 사설이나 내부라고 부르고 잊어버려도 문제 없을 거라고 생각합니다.

개인적으로 나는 pub(crate) 문제를 보지 못합니다. 구문은 첫눈에 명확하고 모호하지 않으며 실제 Rust와 일치합니다. 5번의 추가 키 입력이 문제가 될 정도로 자주 입력할 필요는 없다고 생각합니다.

@UtherII

pub(crate) 대한 짧은 이름이 필요한 이유는 현재 pub 의 많은 (아마도 대부분 ) 사용이 대체될 것이기 때문입니다.

Rust 2018에서 효과적인 비공개 항목에 pub 를 사용하면(비공개 모듈에 나타나기 때문에) 경고가 됩니다. 대신 이러한 항목에 대해 pub(crate) 를 사용해야 합니다. 이 규칙은 코드의 가독성을 향상시킵니다. pub 로 표시된 경우에만 항목을 다른 상자에서 볼 수 있지만 현재는 다른 상자에서 볼 수 있는지 여부가 한 눈에 명확하지 않을 수 있습니다.

죄송합니다. 이 스레드에 응답하지 않고 실수로 이에 대한 새 문제를 만들었습니다. 죄송합니다. 저는 github에 익숙하지 않고 여기에서 응답한다고 생각했지만 실제로 새로운 문제를 일으키고 있었던 것에 로그인하도록 하는 버튼을 클릭하기만 하면 됩니다. 여기에 새호에 쓴 내용을 붙여넣고 제 새호를 삭제할 수 있습니다. 죄송합니다.

에디션 매뉴얼에서 사람들이 여기에 피드백을 남길 것을 제안하는 것을 보고 그렇게 하기로 결정했습니다.

저는 crate:: 또는 :: 크레이트 루트에서 요소에 액세스하는 데 전혀 신경 쓰지 않습니다. ::는 이미 구문이지만, 가능하다면 crate::와 :: 둘 다 사용해야 한다고 생각합니다. 내가 보기에는 경로와 관련하여 제안된 새로운 크레이트 시스템이 본질적으로 이전 구문과 동일하지만 유일한 차이점은 더 이상 extern 키워드를 사용할 필요가 없고 명시적으로 사용할 필요가 없는 것보다 액세스가 더 쉽다는 것입니다. 하위 모듈에서는 본질적으로 모든 곳에서 암시적으로 가져옵니다.

유일한 다른 추가 사항은 ::가 아닌 crate::로 크레이트 루트를 시작한다는 것입니다. 저는 ::로 시작하는 것을 선호합니다. 이것이 제가 원래 배운 방식과 일치하기 때문입니다. 그러나 모듈 시스템을 아직 배우지 않은 사람들이 crate::로 시작하는 것이 더 직관적임을 알 수 있습니다. 두 구문 형식을 모두 허용하지 않는 이유는 무엇입니까? 둘 다 가질 수 없는 이유가 있습니까? 둘 다 지원될 수 있다면 둘 다 지원하는 것을 철저히 지지합니다. 하나만 지원할 수 있다면 나는 익숙해진 대로 :: 쪽으로 더 기울어지지만 초보자에게는 crate::로 배우는 것이 더 쉬울 수 있습니다. 그래서 아마도 내 동기는 이기적인 것입니다.

그래서 본질적으로 나는 궁극적으로 별로 신경쓰지 않지만 개인적으로 ::를 선호하지만 둘 다 지원하는 것이 이상적이라고 생각합니다. 하지만 하나를 선택해야 하고 사람들이 crate:: 로 시작하는 것이 초보자에게 더 우수하다고 생각한다면 저는 그렇게 하지 않습니다. 이에 이의를 제기하지 않습니다.

#[path] 는 Rust 2018에서 중첩 모듈과 어떻게 작동할까요? (https://github.com/rust-lang/rust/issues/35016#issuecomment-409185342)

IIUC, 현재 src/lib.rs 및 src/bar.rs 두 개의 파일이 주어지면 다음으로 대체할 수 있는 X 가 없습니다.

mod foo {
    #[path = "X/bar.rs"]
    mod bar;
}

bar.rs 대한 경로는 항상 src/foo/X/bar.rs 이고 foo 디렉토리가 존재하지 않기 때문에 유효하지 않기 때문에 bar.rs 모듈이 발견됩니다.

pub(crate) 교체를 위한 좋은 이름을 공유하고 있고 핵심 팀에서 여전히 피드백을 구하고 있으므로 제 경험을 공유하고 제안을 드리고자 합니다.

내가 쓴 한 상자에서 pub(crate) 입력하는 것이 짜증나는 것을 발견했습니다. 그래서 그냥 pub 로 줄여서 상자 밖에서 볼 필요가 없는 많은 기호를 실수로 내보냈습니다. 죄송합니다. 😛 (제 경우에는 크레이트가 내부에 있고 공개되지 않았기 때문에 문제가 되지 않습니다. 하지만 여전히! 정확성보다 편리합니다.) 네, 크레이트 수준의 가시성을 전달하기 위해 두 개의 키워드를 매시업하는 것보다 더 나은 것이 필요하다고 강력히 믿습니다. .

그러나 나는 crate 가 이에 대한 올바른 키워드라고 생각하지 않으며(이 주제에 대한 다른 사람들의 피드백은 위 참조), 관점에서 문제에 접근함으로써 다른 제안된 키워드가 요점을 놓치는 것 같은 느낌이 듭니다. 크레이트 루트의; 문제는 모듈의 관점, 즉 키워드를 포함하는 특정 코드 행에 있습니다. 즉, 코드는 "상자 위치"를 제공하려고 하지 않고 정의된 모듈에서 참조를 내보내려고 합니다.

그런 의미에서 저는 export 라는 키워드를 좋아합니다( extern 와 혼동될 수 있지만 extern crate 가 죽었기 때문에 무의미한 것 아닐까요?) export struct Foo; 보기에 매우 읽기 쉽고 일부 다른 언어(ish)와도 일치합니다. 이 RFC 또는 다른 곳에서 키워드로 export 대한 언급을 찾을 수 없습니다. 그래서 그런 것도 있습니다.

완전성을 위해 @seanmonstar , @johnthagen 등이 제기한 사용 사례를 다룹니다.

export use crate::generic::{Combine, Func};

// Or even better using relative paths
export use ::generic::{Combine, Func};

export struct Bar {
    export foo: crate::Foo,
}

export struct Baz(export crate::Foo);

use crate::menu::{Sound, Volume};

export mod color;

// ...

/// A type for storing text and an associated color it should
/// be drawn as.
export struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

그렇긴 하지만, 나는 불로 pub(crate) 를 죽이는 것에 찬성합니다. 나는 심지어 crate , FWIW를 선호합니다.

@parasyte export 내가 본 문제는 "이 상자 는 ____을(를) pub 용도)과 혼동될 수 있다는 것입니다. 다른 관점.

대부분의 사람들이 pub(crate) 가 이상적이지 않다는 데 동의하는 것 같으며, 현재 다른 컨텍스트에서 사용되는 명사 키워드 crate 가 대체품으로 거슬릴 수 있다는 우려를 제기한 사람들이 많습니다. Rust 2018이 이를 확정하기 전에 다른 (잠재적으로 새로운) 키워드를 완전히 고려했는지 확인하는 것은 시간을 매우 잘 활용하는 것처럼 보입니다.

이것이 아직 토론의 여지가 있다면 "공식적인" 피드백을 듣지 못했습니까?

제안의 @parasyte의 라인을 따라 좀 더 단어를 도입의 관심에서 (나는 것을 @johnthagen에 동의 export 많은 것 같아 pub 에 비해 pub(crate) ) :

shared use ::generic::{Combine, Func};
shared struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

global use ::generic::{Combine, Func};
global struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

우리 는 Java의 발자취를 따라 protected 와 같은 것을 사용할 수도 있지만 이것이 이해하기가 특히 쉬운지 잘 모르겠습니다. local (crate-local의 의미에서)도 있지만 global 는 실제로 혼동될 가능성이 더 낮습니다(예: local 는 _file_-local일 수 있음).

사람들은 pub(cr) 또는 cr 어떻게 생각할까요?

crate 것은 그냥 넘어가기에는 너무 좋은 것 같습니다. 이미 키워드이며 extern crate 에서 이전 사용이 중단됩니다. 다른 용도는 이미 pub(crate) 가시성과 관련되어 있습니다.

상자를 형용사로 사용하여 조금 곁눈질하면 그렇게 당황스럽게 들리지 않습니다. '집'과 같은 단어는 형용사로 잘 사용할 수 있습니다. IANA영어교수.

상자에 보이는 항목을 다시 내보내는 것은 큰 문제가 되지 않는다고 생각합니다. 개인적으로 난 단지 적 의미를 정의하는 모듈의 직접 부모의 항목을 재수출했다 (아마) 사용하려면 self 대신 crate 코드 조직의 (seanmonstar의 경우에도 불구하고 ). 예.

    mod detail {
        crate struct Foo;
    }

    crate use self::detail::Foo;

유형에 절대 경로와 결합 된 가시성으로 상자를 사용 (다시 seanmonstar의 예를 사용하는) 모습이 더 문제가 않습니다 : crate struct Foo(crate crate::Bar); 에 반대 pub(crate) struct Foo(pub(crate) ::Foo); . 내 유일한 희망은 이 구조가 대중적이지 않아 전환으로 인해 이 상자 수프가 생성되지 않는다는 것입니다. 사용자는 명시적 가져오기를 통해 이를 방지할 수 있습니다.

use crate::Bar;

crate struct Foo(crate Bar);

share 또는 이와 유사한 제안이 마음에 듭니다. give , provide , deliver , offer , serve , post , forward .. 형용사 여야 하는 경우 shared , givable , providable 등의 접미사로 모두 변환할 수 있습니다.

잠시 JavaScript를 선택하기 위해 ES6에는 언어에 내장된 패키지 대 모듈의 개념조차 없습니다. 모듈만 있습니다. ES6의 export 키워드는 항상 모듈에서 참조를 내보냅니다. 그런 다음 사용하려는 경우 경로로 참조하는 import 에 대한 다른 모듈에 달려 있습니다.

이것은 각각 pub 및 use 와 크게 다르지 않습니다. export 키워드를 사용할 때 혼란이 생길 ​​수 있습니다. pub(crate) 는 실제로 일종의 틈새 시장입니다. 이것이 내가 과거에 pub 를 사용하기로 선택한 이유입니다. ;(

crate 가시성 수정자 문제가 #53120으로 추출되었습니다. 거기에서 더 많은 토론과 결정이 계속되어야 합니다.

mod.rs 변경 사항의 문제가 #53125로 추출되었습니다. 거기에서 더 많은 토론과 결정이 계속되어야 합니다.

extern crate 지원 중단 문제와 use crate_name::foo 및 crate_name::foo Just Work™가 https://github.com/rust-lang/rust/ 로 추출되었습니다.

모듈 경로 시스템 선택 문제는 https://github.com/rust-lang/rust/issues/53130 에서 추출되었습니다

이 문제의 모든 비트를 별도의 문제로 추출했습니다. 이로써 이 글을 마칩니다.

@Centril : https://doc.rust-lang.org/unstable-book/print.html#extern_prelude 링크는 여기로. 이것은 어디에서 논의되고 있습니까? 이 정보가 실제로 누락된 경우 OP에 추가할 수 있습니까?

@sanmai-NL "extern prelude"가 무엇인지 기억을 새로 고칠 수 있습니까?

use some_crate::foo::bar; 를 수행할 수 있는 기능인 경우 https://github.com/rust-lang/rust/issues/53128 이어야 합니다

그 중 일부는 https://github.com/rust-lang/rust/issues/54230 에서 논의되고

@sanmai-NL 나는 이 문제가 주로 진단용이라고 생각합니다.

extern_prelude 인 crate_name::foo::bar 외측 use (가져 오기) 경로.

@센트릴

"extern prelude"가 무엇인지에 대한 내 기억을 새로 고칠 수 있습니까?

일반적으로 "서곡"은 현재 전체 크레이트의 범위에 있고 특정 모듈에 첨부되지 않은 모든 이름에 사용됩니다. (실제로 그런 경우가 많다.)

@petrochenkov 그렇다면 이와 관련하여 "extern" 서곡은 무엇입니까?

@alexreg
--extern 로 전달된 크레이트는 특정 모듈에 연결되지 않고 전체 크레이트의 범위에 있습니다.

이러한 정보의 덩어리가 아무리 변덕스럽더라도 공식 문서 소스에 기록된다면 좋을 것입니다. 특히 Unstable 책에서와 같이 개념에 대한 외부 언급이 있는 경우. 하지만 이러한 개념을 구현하는 유지 관리자가 그렇게 해야 한다고 말하는 것은 아닙니다.

@petrochenkov 감사합니다. 이해가 됩니다.

이 문제의 모든 비트를 별도의 문제로 추출했습니다. 이로써 이 글을 마칩니다.

@Centril 현재 베타 버전의 문제 추적은 여기를 참조하세요. 사람들이 댓글을 속일 필요가 없도록 원래 댓글을 최신 정보로 업데이트하시겠습니까?