Rust: (모듈) 가시성 수정자로 '크레이트'에 대한 추적 문제

가시성 수정자로 crate 에 대한 의견:

모호성 구문 분석

• https://github.com/rust-lang/rust/issues/44660#issuecomment -330105779
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330265493
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330268244
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330271416
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330274593
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330283059
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330537697
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330598910
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330699801
• https://github.com/rust-lang/rust/issues/44660#issuecomment -331609126
• https://github.com/rust-lang/rust/issues/44660#issuecomment -331612061
• https://github.com/rust-lang/rust/issues/44660#issuecomment -331680750
• https://github.com/rust-lang/rust/issues/44660#issuecomment -331683175
• https://github.com/rust-lang/rust/issues/44660#issuecomment -331687462

부자연스러운 / 혼란스러운 / 개선되지 않음

• https://github.com/rust-lang/rust/issues/44660#issuecomment -330142301
• https://github.com/rust-lang/rust/issues/44660#issuecomment -406013863
  
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406026647
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406035818
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406069472
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406070896
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406271075
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406355868
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -408676804 (+ 무거운 손)
  
  
• https://github.com/rust-lang/rust/issues/44660#issuecomment -408690552
• https://github.com/rust-lang/rust/issues/44660#issuecomment -408696147
• https://github.com/rust-lang/rust/issues/44660#issuecomment -408707824
  
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -408769188
  
  
• https://github.com/rust-lang/rust/issues/44660#issuecomment -409790996 (+ 자전거 보관소)
• https://github.com/rust-lang/rust/issues/44660#issuecomment -409900466

좋은 아이디어

• https://github.com/rust-lang/rust/issues/44660#issuecomment -409959482

대신 pub(extern)

• https://github.com/rust-lang/rust/issues/44660#issuecomment -330262645

자전거 보관소

• https://github.com/rust-lang/rust/issues/44660#issuecomment -408679152
• https://github.com/rust-lang/rust/issues/44660#issuecomment -408681646
• https://github.com/rust-lang/rust/issues/44660#issuecomment -408682187
• https://github.com/rust-lang/rust/issues/44660#issuecomment -409910136
• https://github.com/rust-lang/rust/issues/44660#issuecomment -409942899
• https://github.com/rust-lang/rust/issues/44660#issuecomment -409972551

초기 미리보기

• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/15?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/35?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/37?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/50?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/51?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/52?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/53?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/54?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/55?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/56?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/57?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/58?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/60?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/62?u=centril

전용 스레드

• https://internals.rust-lang.org/t/visibility-modifiers-pub-super-vs-super/7838

개인적으로, 나는 가시성 수정자로서 crate 에 매우 찬성하며 여기에 @stepancheg 의 의견을 공유합니다. 나는 우리가 더 작고 더 엄격한 가시성을 장려해야 한다고 생각하며 crate 가 바로 그 일을 합니다.

저는 개인적으로 pub(crate) 을 쓰는 것이 좋습니다. 의도는 매우 명시적입니다.
@johnthagen 이 제공한 예제는 보기에 정말 고통스럽습니다( 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,
}

crate mod color; 는 특히 혼란스러워 보입니다. 여기서 무슨 일이 일어나고 있는지 생각해봐야 합니다.

이러한 예 중 일부는 매우 C- static -esque- 직관적으로 관련되어 있지만 실제로는 놀라울 정도로 뚜렷합니다.

@johnthagen 으로 인한 예제는 나에게 잘 읽히지 않습니다. 사실, 그것은 자연스럽게 읽히고 나는 대칭을 아주 좋아합니다. 어떻게 보면 아름답습니다.

가독성이 다음과 같은 경우:

crate struct ColoredText {
    crate color: types::Color,
    crate text: &'static str,
}

문제가 된다; 그런 다음 Rust의 구문을 이해하는 IDE/에디터는 다른 색상으로 다른 위치에 있는 crate 토큰을 강조 표시할 수 있습니다. 그것은 내가 생각하는 차이점을 잘 정리해야합니다.

가시성 수정자로 crate 는 확실히 이상합니다. 이것은 녹과 관련이 없는 것에 대해 매우 녹 관련 키워드를 사용합니다. Kotlin 및 C#은 이를 위해 internal 를 사용합니다.

개인적으로 crate-visible pub 를 재사용하고 pub* 또는 pub! 와 같이 세상에서 볼 수 있는 더 비명을 지르는 구문을 사용하고 싶습니다.

이전에 제기되었지만 내가 보는 근본 문제는 다음과 같습니다.

1. crate 는 명사 입니다. pub(crate) 가 길고 이상해 보입니다. 그래서 나는 그것을 무언가 로 바꾸는 것을 전적으로 지지합니다. 그러나 그것과 관련된 공개 형용사가 있기 때문에 문법적으로 더 잘 전달되었습니다.
2. crate 는 이제 "this-crate" 가져오기의 앵커로 사용됩니다. 즉, "이것이 정의된 곳마다 이 상자에서 가시적으로 내보내집니다"와 다른 의미입니다.

// Here `crate` means the root of this crate.
use crate::menu::{Sound, Volume};

// Here, `crate` means: export crate::game::color
// The `crate` is referring to `color`, not the root.
crate mod color;

...

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

Kotlin/C#에서 @matklad 의 internal 를 사용하는 예와 비교합니다.

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

internal mod color;

...

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

internal 가 올바른 키워드라고 말하는 것은 아니지만(Rust는 매우 짧은 약어를 좋아하고 int 는 불행히도 C/C++/Java 혼동으로 가득 차 있음), 개인적으로 두 번째 예가 즉시 더 읽기 쉽습니다.

나는 또한 crate 가시성 키워드가 다른 언어에서 Rust로 오는 사람들에게 혼란을 줄 것이라고 생각합니다. Rust에 관련된 많은 사람들이 이 스레드에 대해 논평을 할 정도로 혼란스럽다면, Rust를 처음 접하는 사람들에게도 문제가 될 것이라고 상상해야 합니다.

pub(crate) 의 약간 더 긴 구문은 상자 외부에 도달할 수 없는 pub 항목이 있다는 경고/오류가 되지 않는다면 그렇게 큰 문제가 아닐 수 있습니다. 나는 개인적으로 pub(crate) struct Foo { ... } 가 있다면 컴파일러가 impl Foo 에 있는 모든 pub fn $ 에 분명히 도달할 수 없다는 것을 깨닫고 그것에 대해 신경 쓰지 않기를 바랍니다.

pub struct Foo 에서 pub(crate) struct Foo 로 유형을 표시하면 현재 Rust 2015에서 바쁜 작업으로 보입니다. 그러면 컴파일러가 다른 pub fn s는 문제가 실제가 아닐 때 갑자기 pub(crate) 유형을 사용하여 존재합니다. 다른 유형도 pub(crate) 이기 때문입니다.

나는 또한 pub 를 crate-public으로 용도 변경하고 export 또는 세계적으로 볼 수 있는 수출용으로 사용하는 @matklad 의 아이디어를 찾습니다. 그러나 그것이 에디션에 비해 너무 큰 차이가 날 수 있습니까?

pub 를 crate-public으로 용도 변경하고 world-public에 대한 새로운 가시성을 추가하는 것은 현재 버전 이전 의 제안이었습니다. 기존 의미에 대한 이러한 변경은 에디션이라고 해도 너무 과감한 것으로 간주되어 pub 가 현재의 의미를 유지하고 있습니다.

덜 논의되고 고려된 것은 보풀을 통해서만 pub 의 용도를 변경하는 것이었습니다. 아마도 우리는 Lint를 "warn on pub $ that is not accessable the crate"에서 "warn on pub that the crate 밖에서"로 전환하고 순수한 선택적인 pub(extern) 를 추가할 수 있습니다. export 키워드. 즉, 의미 체계를 변경하지 않고 보푸라기 침묵 구문을 추가하기만 하면 됩니다.

나는 이것이 상자 공개 항목보다 세계 공개 항목이 더 적다는 가정에 기초하여 덜 방해가 될 것이라고 생각합니다. 또한 가시성의 실제 동작으로 모든 사람을 대면하는 대신 "현재 모듈에서 내보내기"로 pub 의 직관적인(미묘하게 부정확하지만) 의미를 유지합니다.

Rust는 매우 짧은 약어를 좋아하고 int 는 불행히도 C/C++/Java 혼란으로 가득 차 있습니다.

FWIW는 두 문자만 저장하지만 internal 를 축약하려는 경우 "올바른" 약어는 extern al과 유사하게 intern 것입니다. 그것이 일반적으로 이해되고 다른 의미를 가진 명사이기도 하다는 것은 불행한 일입니다. 오 글쎄.

@glaebhoerl intern 은(는) 고려해야 할 좋은 옵션입니다! ❤️

extern 와의 대칭은 정말 좋으며 IMO는 intern 의 명사 형태와의 잠재적인 혼동을 크게 줄입니다.

짧고( crate 보다 1자 더 많음) use crate:: 와 충돌하지 않습니다.

업데이트된 예는 다음과 같습니다.

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

intern mod color;

...

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

전에도 언급했지만 명사를 형용사로 사용하는 것이 어떤 문제인지 잘 모르겠습니다.

요약하자면, 형용사로 사용할 수 있는 명사가 많이 있습니다. 집 고양이, 컴퓨터 마우스, 컴퓨터 책상 등... _형용사로 사용되는 영어 명사_에 대한 Google 검색은 모든 명사가 형용사로 작동하는 것은 아니지만 본질적으로 잘못된 것이 없음을 나타내는 것 같습니다.

해 보자:

_crate mod hello;_ hello라는 이름의 크레이트 모듈은 괜찮습니다.
_crate fn world() {}_ world라는 크레이트 함수는 괜찮습니다.
_crate struct Foo;_ Foo라는 이름의 크레이트 구조체는 괜찮습니다.
_crate enum Bar {}_ Bar라는 이름의 크레이트 열거형은 괜찮습니다.
_crate trait Baz {}_ Baz라는 상자 특성은 괜찮습니다.

_crate use self::local::Foo;_ Ack, 이것은 작동하지 않습니다. 크레이트 사용? Foo라는 이름의 상자 사용 가능 아이템으로 읽을 수 있습니다. 그것은 패턴을 깨뜨립니다.

또한 struct 멤버 앞에서 사용하고 경로의 루트로 crate와 함께 사용하면 어색할 수 있습니다.

상자가 완벽하지는 않지만 '명사'가 결정적인 요소라고 확신하지 못합니다.

문제는 매우 드물다는 것입니다. 명사를 유형 수정자로 사용하는 프로그래밍 언어는 없습니다.

@센트릴

문제가 된다; 그런 다음 Rust의 구문을 이해하는 IDE/에디터는 다른 색상으로 다른 위치에 있는 크레이트 토큰을 강조 표시할 수 있습니다. 그것은 내가 생각하는 차이점을 잘 정리해야합니다.

개인적으로 다른 편집기의 기능은 훌륭하다고 생각하지만 충분히 고급 편집기를 가정하고 언어를 설계해야 한다고 생각하지 않습니다. 나는 C#이 이런 식으로 설계되었다고 느꼈고 그것이 그 언어에 대한 나의 좌절의 주요 요인이었습니다.

@epage 저는 crate 를 강조 표시와 상관없이 가시성 수정자로 사용하는 것이 좋다고 생각합니다. 나는 강조 표시가 추가적인 완화라고 제안하는 것뿐입니다. 특히, $# crate field $#$와 다르게 crate:: 를 강조 표시하는 것은 편집자가 매우 간단해야 합니다. 전자는 항상 확인하기 쉬운 crate + :: $이기 때문입니다. crate ::foo::bar 를 제외한 모든 경우에 해당합니다(그러나 이것은 상당히 드뭅니다..).

IDE 담당자로서, 그러한 강조 표시는 매우 적은 양의 정보에 대해 상당한 양의 노이즈를 추가하여 부정적인 결과를 초래할 것이라고 생각합니다. IMO(이것은 매우 개인적이지만 강력한 IDE를 사용하고 구현하여 정보를 얻음) 강조 표시는 의미론적 비-로컬 정보를 전달할 때 가장 잘 작동합니다(이 사용법은 mut 로 선언된 변수를 참조합니까) 및 강조 표시 코드의 로컬 "보일러플레이트" 측면(모든 키워드의 스타일이 정확히 동일해야 함).

dom (예: 국내)가 잠재적인 후보인 것 같습니다.

세 글자(정렬하기 좋고 기억하기 쉬움)가 있고 명사가 아니며 'Document Object Model' 외에는 특별한 모호성이 붙은 것 같지 않습니다.

pub struct MyStruct {
    dom num: i32,
    pub msg: String,
}

아무도 이것에 대해 생각이 있습니까?

내가 언급한 것을 보았지만 요약에서 찾을 수 없는 한 가지 각도(btw를 해주셔서 감사합니다!)는 바로 가기가 기존 pub() 구문에 맞는 방법입니다.

pub 및 <something> (예: crate )에 특별한 의미가 있는 경우 pub(<something>) 의 가시성과 확장성을 감소시킵니다. 우리가 어떤 솔루션을 사용하든, 다른 솔루션이 아니라 기존 기계를 지원하거나 대체해야 한다고 생각합니다.

예를 들어 crate 또는 교체를 사용하는 경우:

• 범위 제한(예: crate(<something>) )을 적용하려면 crate 를 확장해야 합니까?
• pub pub() 를 더 이상 사용하지 않아야 합니까?

이것을 고려하고 목표에 대한 이해(내부 API에서 공개 API를 명확히 함)를 고려하여 @vitiral 의 pub(extern) 아이디어를 다시 만들었습니다.

• 기존 기계에 적합
• imo는 pub 를 특별한 경우가 아니라 pub(<something>) 의 지름길로 만들어 기존 기계를 개선합니다.
• 공개 API가 비공개 API보다 훨씬 작은 경우 구문에 가중치를 부여한 것입니다.
• 그러나 public 가 공개 API에 있을 수 있음을 의미하는 다른 언어에서 오는 사람들을 혼동시킬 수 있습니다.

RE 캡슐화에 대한 영향

기존 pub 시스템의 장점 중 하나는 캡슐화입니다. 쉬운 경로는 API를 한 단계 위로만 노출하는 것입니다. 이렇게 하면 크레이트의 일부에는 공개하지만 전체 생성에는 비공개로 설정하는 것이 더 쉬워집니다.

pub(super) pub(crate) 대한 바로 가기가 있으면 사람들이 더 많이 사용하도록 유도하여 사람들이 API를 캡슐화하지 않도록 권장합니다.

나는 이것이 작은 상자의 문화 때문에 문제가 되지 않는다고 생각합니다.

그러나 이것을 고려할 때 pub(extern) 에 대한 위의 의견에 대한 또 다른 반복을 제공합니다.

• pub 는 pub(super) 의 바로 가기여야 합니다.
• pub(extern) 는 공개 API에 필요합니다.

나는 이전에 사람들이 다른 언어에서 전환하는 것에 대한 우려를 제기했습니다. 이것은 그들과 더 잘 어울립니다.

• 다양한 언어에서 public 가 작동하는 방식과 더 밀접하게 일치합니다.
• 일부 언어는 공개 API에 대해 고유한 메커니즘을 사용하는 경향이 있으므로 이에 대해 설명할 수 있습니다.

imo 이것은 모든 세계 중 최고입니다. 그러니 찢고 왜 안되는지 이해하도록 도와주세요 :)

나는 여전히 pub(foo) 구문을 싫어합니다. 과장되게 말하면 함수 호출인지 여러 키워드의 매시업인지 판단할 수 없는 것처럼 보입니다. 우리는 let(mut) 또는 for(in) 를 사용하지 않습니다. 그래서 이것은 무엇과 관련이 있습니까?

@parasyte pub<foo> 승리합니다! 결국, 그것은 _시각성의 유형_이 아닙니까?

pub<crate> 또는 pub(crate) 정말 기분이 좋습니다.

캠프를 변경한 사람의 몇 가지 생각:

처음에 나는 crate 에 매우 반대했고 "이것이 멋진 pub 를 망치고 있다"고 생각했습니다.

그런 다음 내 프로젝트 중 일부에서 나란히 시도하고 가라앉게 했습니다.

솔직히 며칠 만에 pub(X) 를 더 이상 볼 수 없었습니다.

처음에는 (시각적) 모호함이 있을 수 있다는 두려움이 있었습니다. 하지만 제게는 반대 현상이 발생했습니다. 이제 crate 가 표시되면 "상자 물건"이라는 것을 알 수 있습니다. 그것이 모듈을 가져오든 가시성을 선언하든 상관없습니다. 압도적 다수의 경우에 정확히 무엇은 문맥에서 매우 명확합니다(영어의 모호성 같은 것).

어떤 경우에는 여전히 "더 어려운" (시각적) 모호성이 남아 있을 수 있다는 것을 알 수 있습니다. 시각적 토큰화/노력 대 덜 모호해진 소스 코드 라인" ).

그 각도에서 crate - intern (또는 다른 비대칭)도 한 걸음 물러나는 것처럼 느껴질 것입니다.

이렇게 말했지만 모호성을 구문 분석하는 것에 대해 잘 모릅니다. 하나를 선택해야 한다면 " crate ::foo::bar 그냥 작동"에 대한 좋은 이야기보다 " crate 가 상자 물건을 의미합니다"에 대한 좋은 이야기가 훨씬 낫습니다.

내 두 센트는 다음과 같습니다.

• 나는 crate mod , crate struct , crate fn , ... 광범위하게 사용했으며 매우 유용하다는 것을 알았습니다.
• 자주 사용하기 때문에 너무 길지 않은 한 ( crate , pub(crate) , ...) 이름이 어떻게 지정되는지는 그다지 중요하지 않습니다.

나에게 달려 있다면 vis 를 키워드로 사용하고 가시성 유형을 수정자로 사용합니다(예: vis(pub) , vis(crate) 등). 나에게 감각.

이미 pub 를 "가시성 지정자"로 사용하고 있다는 점을 감안할 때 저는 실제로 crate 를 좋아합니다. pub(crate) 는 이 모듈에 대한 공개로, 크레이트에 대해 비공개로 읽습니다. 여기에서 공개와 비공개를 동시에 사용하는 것이 이상하다는 것을 알았습니다.

새로운 키워드와 문맥 키워드 등을 도입하는 것은 가치가 없다고 생각합니다. 가시성이 두 개 있다는 것을 가르치는 것은 pub 및 crate 수정하고, 하나는 공개를 의미하고 다른 하나는 크레이트에 대한 비공개를 의미한다고 가르치는 것은 나에게 일종의 의미가 있지만 아마도 나는 익숙해졌습니다. 지난 2주 동안 이미 crate 입니다.

이미 사용된 키워드(예: crate )가 의미를 통합한다고 제안하는 사람들에게는 단어 자체보다 문맥이 더 중요하다고 주장합니다. 두뇌는 컨텍스트로 모든 것을 구문 분석합니다(컴파일러가 이를 구문 분석하는 방법은 다른 문제입니다): 이것은 for x in y 및 impl X for Y for 의 의미론적 의미를 통합하지 않는 이유를 설명합니다. .

마찬가지로 crate 를 가시성 한정자로 도입하면 해당 의미가 멤버 또는 함수 한정자의 컨텍스트에서 추가 컨텍스트와 함께 제공될 때 분명하기 때문에 혼동을 일으키지 않을 것입니다. 예를 들어, crate fn my_func(); 는 "이것은 상자입니다"로 읽히지 않고 "이것은 상자에서 볼 수 있는 기능입니다"로 읽습니다.

즉, 그것이 명사라는 사실은 일관성이 없습니다. 이 문제를 해결하기 위해 새로운 가시성 한정자 키워드를 만들고 싶습니다.

사실, 확실히 사용자를 혼란스럽게 할 것이 있다면 직관적으로 함수 호출처럼 보이고 언어의 다른 곳에서 동등한 구문이 없는 pub(crate) 구문입니다. 나에게 그것은 추악한 해킹처럼 느껴진다.

pub(crate) 의 대체품으로 crate 를 사용하는 것에 대한 우려를 제기한 사람으로서 그리고 @aturon 의 최신 게시물 을 읽은 후:

가시성 수정자로 크레이트 지원(여기 138에서 추적. 지금까지 피드백을 감안할 때 이 기능은 Rust 2018에서 안정화되지 않을 것 입니다.

저는 개인적으로 pub(crate) 를 무언가 로 바꾸는 것에 전적으로 찬성한다는 점을 분명히 하고 싶습니다(대부분이 그렇다고 생각 합니다).

선호하는 순서대로, 특히 Rust가 처음이거나 익숙하지 않은 사람들에게 가장 이해하기 쉬울 것 같습니다.

1. intern (또는 다른 유사한 새 키워드)
2. crate
3. pub(crate)

핵심 팀이 intern 또는 이와 유사한 것이 궁극적으로 결코 받아들여지지 않을 것 같다면 pub(crate) 에 비해 크게 개선되었다고 생각하기 때문에 crate 뒤처질 것입니다. @Centril 과 다른 사람들이 분명히 밝힌 이유.

따라서 훨씬 더 경험이 풍부한 핵심 팀이 이것이 최선의 길이라고 생각한다면 나는 이것을 방해하지 않을 것입니다. 피드백을 제공할 수 있다는 것은 고려할 만한 아이디어를 표현하는 것입니다. 👍 녹!

@ralfbiedert

처음에는 (시각적) 모호함이 있을 수 있다는 두려움이 있었습니다. 하지만 제게는 정반대의 일이 일어났습니다. 지금 상자를 보면 그것이 "상자 물건"이라는 것을 압니다. 그것이 모듈을 가져오든 가시성을 선언하든 상관없습니다. 압도적 다수의 경우에 정확히 무엇은 문맥에서 매우 명확합니다(영어의 모호성 같은 것).

@zesterer

이미 사용된 키워드(예: crate)가 의미를 통합한다고 제안하는 사람들에게는 단어 자체보다 문맥이 더 중요하다고 주장합니다. 두뇌는 컨텍스트로 모든 것을 구문 분석합니다(컴파일러가 이를 구문 분석하는 방법은 다른 문제입니다). 이것은 for in for x in y와 impl X for Y의 의미론적 의미를 병합하지 않는 이유를 설명합니다.

개인적으로 두 분을 부르려는 것이 아니라 사용 후 변화에 찬성하는 사람들의 모범이 되십시오.

보기에는 이상해 보이지만 가장 큰 걱정은 녹슬지 않는 사람들입니다.

• 이것이 녹을 평가할 때 누군가의 의견에 어떤 영향을 미칠 수 있습니까? 한 가지 구문상의 문제는 그들을 설득하기에 충분하지 않아야 하지만 평생과 다른 "이상한" 것으로 쌓으면 사람들을 낙담시킬 수 있습니다 .
• 이것이 Rust를 배우는 사람들에게 어떤 영향을 미치나요?
• 이것은 Rust를 모르지만 수정해야 하는 사람들에게 어떤 영향을 줍니까?

이러한 우려가 얼마나 많은 영향을 미치는지 더 잘 알기 위해 이에 대한 사용성 연구를 할 수 있다면 좋겠습니다.

@epage , 매우 동의합니다. Rust의 사용자 대면 부분은 UX 테스트를 받아야 합니다. 그런데 이게 지금 일어나고 있는 일이라고 생각하고, 결과를 논의하는 중입니다.

이에 덧붙여 우리 회사의 일화적 관찰은 다음과 같습니다.

저는 다른 3명과 함께 일하는 우리 부서의 "Rust 옹호자"입니다. 모두 C#에 대한 탄탄한 배경 지식을 가지고 있지만 Rust에는 비교적 새롭습니다. 다른 날에는 " crate -stuff"와 함께 연구 프로젝트를 Rust 2018로 마이그레이션했습니다.

코드를 살펴보았을 때 대화는 대략 다음과 같았습니다.

"그래서 여기에 내가 만든 몇 가지 다른 변경 사항, 새로운 가져오기 시스템, 수정자가 있습니다."

"그게 무슨 일이야?" ( use crate::object 및 crate x: object 를 가리킴)

"이 상자에서 가져오세요." 및 "가시성 수정자."

"아, 알았어. 또 달라진 게 있어?"

토론 끝.

확실히, 우리는 새로운 기능과 특정 패턴을 채택해야 하는지 여부에 대해 조금 더 이야기를 나눴습니다. 그러나 이 두 항목의 "가르치는 측면"은 몇 단어로 요약되어 그 이후로 (내가 아는 한) 언급되지 않았습니다.

다음에 이야기할 때 다른 소식이 들리면 이 의견을 업데이트하겠습니다.

@ralfbiedert 공유해주셔서 감사합니다!

@epage , 매우 동의합니다. Rust의 사용자 대면 부분은 UX 테스트를 받아야 합니다. 그런데 이게 지금 일어나고 있는 일이라고 생각하고, 결과를 논의하는 중입니다.

저는 이러한 UX 일화를 특히 학습 가능성 측면에서 중요하게 생각하지만 이 문제의 프로세스를 UX 테스트로 규정할 수 없다고 생각합니다. 내 의견은 더 깊은 이해를 얻고 편견을 제거하는 데 도움이 될 수 있는 보다 공식적인 프로세스를 언급하는 것입니다.

다음은 Rust가 다소 생소한 사람의 몇 가지 생각입니다. 먼저, 이 언어에서 정말 제정신이고 좋은 느낌을 주는 것은 "기본적으로는 변경할 수 없고 기본적으로는 비공개" ​​접근 방식이라고 말하고 싶습니다.

이제 pub 는 간단하고 현대 언어에서 기대하기 때문에 좋습니다. Rust의 맥락에서 이것을 배우지 않고 대신 다른 키워드를 도처에 뿌려야 하는 것은 약간 서툴다고 생각합니다. 의미상 "이것은 상자에 나타나는 버튼입니다", 상자는 모듈: 가시성 "한 수준 위로"를 의미하는 것이 옳다고 느껴집니다.

그래서 나에게 pub 대신 crate 또는 그와 같은 성격의 다른 키워드를 사용하면 가렵게 느껴집니다. 공개가 기본값이 아닌 경우 크레이트에서 내보내는 것이 훨씬 더 특별해야 합니다. . 즉, 크레이트의 API는 특별한 방식으로 표시되어야 합니다.

그래서 저는 @epage 에 전적으로 동의합니다. pub 는 그대로 유지되어야 하고 pub(extern) 가 도입되어야 합니다. 괄호로 묶인 키워드는 실제로 털이 많은 느낌이 들므로 전용 키워드를 사용할 가치가 있습니다. crate 키워드는 그런 의미에서 작동합니다. "내보낸 크레이트 멤버"라는 의미를 볼 수 있습니다. 또는 export 실제로는 모르겠습니다. 어쩌면 내 요점은 모두 자전거 보관소이며 이것은 모두 "키워드가 올바르지 않습니다"에 해당합니다. 그러나 pub 는 너무 일반적이어서 특별하게 느껴지지 않으므로 정말로 특별한 것을 나타내지 않아야 합니다(crate-exported API).

이번 주말에 RustConf에서 코드 샘플에 pub(crate) 를 많이 사용한 강연을 봤는데 정말 평범한 crate 를 원하게 되었습니다. 나는 여전히 원래 계획에 매우 프로입니다.

@steveklabnik

저는 이번 주말에 RustConf에서 코드 샘플에 많은 pub(crate)를 사용한 강연을 보았는데, 정말이지 평범한 오래된 크레이트를 원하게 되었습니다. 나는 여전히 원래 계획에 매우 프로입니다.

이 주석의 컨텍스트는 대부분 RustConf에서 가져온 것입니까, 아니면 이 스레드를 고려하고 이에 대한 불일치를 전제로 합니까? 이전에 pub(crate) 가 아니라 pub 변경을 유발하는 요구 사항에 대한 대안 솔루션을 제공했으며 이것이 사람들의 요구를 충족시킬 수 있기를 바랍니다.

보다

• 내 걱정
• 또 하나의 우려와 제안된 솔루션

@superseed

그래서 저는 @epage 에 전적으로 동의합니다. pub는 그대로 유지되어야 하고 일종의 pub(extern)이 도입되어야 합니다. 괄호로 묶인 키워드는 실제로 털이 많은 느낌이 들므로 전용 키워드를 사용할 가치가 있습니다. crate 키워드는 그런 의미에서 작동합니다. "내보낸 크레이트 멤버"라는 의미를 볼 수 있습니다. 아니면 실제로 수출하는지는 모르겠습니다. 어쩌면 내 요점은 모두 자전거 보관소이며 이것은 모두 "키워드가 올바르지 않습니다"에 해당합니다. 그러나 pub은 너무 일반적이어서 특별하게 느껴지지 않으므로 정말로 특별한 것을 나타내지 않아야 합니다(crate-exported API).

RE "괄호로 묶인 키워드는 정말 털이 많은 느낌이 들지만"

개인적으로 나는 그것들에 대해 알았을 때 그것들이 깔끔하다고 생각했지만(all-or-nothing friend 보다 훨씬 낫습니다), 더 큰 관심사는 병렬 구문을 만들지 않고 우리가 가진 것을 수용하거나 찾을 수 있다는 것입니다. 대체 솔루션.

반면에...

RE 또는 export 실제로,

export 를 추가하는 것이 $ crate 와 달리 이전 의견과 모순된다고 생각하지 않습니다. 이 컨텍스트에서 export 는 가시성과 다르게 취급될 수 있습니다. export 는 pub(crate) 를 의미합니다. 나는 이것이 가르치는 데 큰 문제가되지 않을 것이라고 생각합니다.

나는 내 원래 아이디어의 확장에 대해 어느 쪽이든 갈 수 있습니다.

@superseed

pub […] 가시성 "한 단계 위로".
crate 키워드는 그런 의미에서 작동합니다. "내보낸 크레이트 멤버"라는 의미를 볼 수 있습니다.

이 두 키워드의 의미에 대한 귀하의 이해는 여기에서 제안된 것과 정반대일 수 있습니다. pub 는 모든 사람에게 공개를 의미하고 crate 는 동일한 상자에서 액세스할 수 있음을 의미합니다.

@epage

pub(crate) 의 경우 정말 깔끔한 기능 을 제공하고 실제로 잘 읽히지만 내 눈에는 너무 많은 함수 호출처럼 보입니다. 즉, 구문 강조 표시가 없으면 아마 정말 혼란스러울 것이고 강조 표시는 언어의 의미를 이해하는 데 필요하지 않아야 합니다.

@SimonSapin

실제로, 그리고 나는 그것이 이해되어야 하는 방식이라는 것을 알고 있지만 crate -- 명사이기 때문에 -- 크레이트(?) 또는 크레이트의 속성을 선언하는 것처럼 느껴집니다. 선언하고 자격 이 없음 을 강조합니다.

그리고 public / pub 는 어디에서나 볼 수 있는 한정어이며 "이것은 상자 밖으로 내보낸 것"을 의미해야 하는 것처럼 느껴지지 않습니다. struct 회원 가시성을 검증하는 데 사용하는 경우와 같이 "이것은 내가 속한 컨텍스트 외부에서 볼 수 있습니다"라는 의미를 가지고 있습니다. t 그 경우 의미가 변하고 있다고 생각하십시오).

그리고 public/pub는 유비쿼터스 수식어이며 "이것은 상자 밖으로 내보낸 것"을 의미해야 하는 것처럼 느껴지지 않습니다. "이것은 내가 있는 컨텍스트 외부에서 볼 수 있습니다"라는 의미를 가지고 있습니다. 이는 구조체 멤버 가시성을 한정하는 데 사용하는 경우와 같습니다(그리고 내가 틀렸지만 의미 체계가 이 경우 변경).

pub 는 항상 "이것은 상자 밖으로 내보내집니다"를 의미합니다. 이것은 변경 사항이 아니라 이미 있는 그대로입니다. 많은 사람들이 그렇지 않다고 가정한다는 사실이 왜 pub(crate) 가시성 수준이 전혀 추진되지 않는지입니다.

펍은 항상 "이것은 상자에서 내보냅니다"를 의미했습니다.

이 이해가 전체 그림이 아니기 때문에 혼란을 일으킬 수도 있다고 생각합니다. pub 는 "이 모듈 외부의 누가 이 항목/필드/메소드에 액세스하는지 상관하지 않습니다"를 의미합니다. 크레이트에서 내보내려면 항목 경로에도 동일한 pub 수정자가 있어야 합니다.

이 세부 사항은 많은 언어에서 매우 일반적입니다. 이것이 내가 unreachable_pub 보푸라기에 관심이 없는 이유이기도 합니다. 이것이 이 문제를 너무 많이 밀어붙이는 부분이기 때문입니다. 최상위 레벨에서 절대 내보내지 않는 유형이 있는 경우 pub 메소드라고 표시하는 것이 귀찮은 일입니다.

@rpjohnst 그것이 항상 의미하는 바입니까? 요소를 내보낸 상자의 상단에서 "visible from super "의 사슬이 아니었고 리프 요소 자체를 pub 로 규정하지 않았습니까?

아니요, 그것이 전체 이야기가 아니며 @seanmonstar 의 설명이 나머지를 암시합니다. 가장 큰 예외는 재수출입니다. 부모 모듈이 비공개인 항목을 pub use 할 수 있습니다. 더 이상한 예는 이것 과 같으며, 상위 모듈이 비공개인 경우에도 공개 인터페이스에서 pub 항목을 사용할 수 있습니다.

그리고 다른 방향으로 가면 $ pub use pub(crate) pub 더 낮은 가시성은 같은 방식으로 우회할 수 없습니다 . pub use 자체가 상자 밖에서는 보이지 않습니다.

따라서 항목 자체의 가시성은 super 에 대한 가시성에 대한 직접적인 것이 아니라 가시성 의 "상한"에 관한 것입니다.

오오 그렇군요 설명 감사합니다! 훨씬 더 순진한 모델을 염두에 두었습니다. "펍의 현재 의미"에 대한 이전 의견과 관련하여 더 합리적입니다.

우리는 오늘 @rust-lang/lang 회의에서 간략하게 논의했습니다.

• 우리 중 많은 사람들이 이에 대해 긍정적으로 생각하지만 키워드 선택과 crate::foo::bar 경로와 결합할 때 혼란을 야기할 수 있는지 여부에 대해 여전히 의구심 이 있습니다.
• 그러나 struct Foo ( crate :: foo :: Bar ) 를 해결하는 방법을 결정해야 한다는 점을 지적할 가치가 있습니다. (crate::foo::Bar) 유형의 개인 필드인지 아니면 crate 필드인지 ::foo::Bar 유형 ?
  
  
  
  • 솔직히 오늘날 우리가 무엇을 분석하는지 잘 모르겠습니다.
  
  

답변: 우리는 그것을 경로( 놀이터 )로 구문 분석합니다.

이것은 ::foo::bar 경로가 점점 더 드물어 질 것이라고 생각하기 때문에 아마도 나에게는 괜찮을 것 같습니다.

우리 중 많은 사람들이 이에 대해 긍정적으로 생각하지만 키워드 선택과 crate::foo::bar 경로와 결합할 때 혼란을 일으킬 수 있는지 여부에 대해 여전히 의문점이 있습니다.

@nikomatsakis 우리가 따라잡을 회의 메모나 요약이 있습니까? 이 스레드 내에서 내 관심사[0] 중 하나 이상에 대해 논의한 적도 없고 반대 제안에 대한 많은 논의도 본 적이 없습니다. 아마도 [0]과 다른 것들 중 일부는 다양한 내부 스레드에서 논의되었지만 파고들어야 할 것이 많습니다.

[0] pub(...) 를 제거하거나 수용해야 한다는 느낌으로 pub(...) 를 모호한 상태로 밀어넣는 병렬 가시성 구문 생성

@epage

@nikomatsakis 우리가 따라잡을 회의 메모나 요약이 있습니까?

죄송합니다. 우리는 그것에 대해 아주 오랫동안(최대 몇 분) 논의하지 않았으며 이에 대한 회의록도 작성하지 않았습니다.

@eddyb 는 my 를 더 짧고 인체공학적인 가시성 수정자로 간략하게 언급했습니다.

mine 라고 했던 것 같은데 my 는 더 짧고 사랑스럽습니다!
(참고로 저는 회의에서 반 농담이었습니다)

편집 : my 가 crate-local이면 pub 를 our 로 바꿀 수 있습니까? 예:

our struct Foo(my FooImpl);

(참고로 저는 회의에서 반 농담이었습니다)
my 가 crate-local이면 pub 를 our 로 바꿀 수 있습니까?

Perl: 농담을 현실로 만듭니다.
https://perldoc.perl.org/functions/my.html
https://perldoc.perl.org/functions/our.html

my 는 훌륭하고(이전에도 등장한 적이 있습니다), 문제는 local , internal 또는 무엇과 관련하여 무엇 보다 명확하지 않다는 것입니다(또는 그 경우, 누구의 ), 이것이 전체 문제입니다.

우리가 처한 어색한 상황은 "완전히 공개된", "완전히 비공개적인" 및 "중간에 있는"(즉, 크레이트 수준)의 세 가지 개인 정보 보호 수준을 원한다는 것입니다. 그리고 이전 버전과의 호환성 제약으로 인해 이 중 첫 번째는 반드시 pub 이고 두 번째는 묵시적 기본값이며 세 번째는 새로운 것을 제시해야 합니다. 그리고 영어에는 "완전히 글로벌하지도 않고, 완전히 지역적이지도 않지만, 그 사이 어딘가에"를 정확하게 나타내는 단어가 많지 않습니다.

그리고 crate 키워드는 실제 범위가 무엇 인지 정확히 이름에 나와 있기 때문에 이를 만족시키는 키워드입니다. 바로 크레이트입니다. 그러나 ("나는 그것을 알고 있었다!"를 나누기 전에) 이것의 대가는 그것이 가시성 수정자라는 것이 더 이상 분명하지 않다는 것 입니다. "Pub"은 "public"의 줄임말로 직감할 수 있습니다. 그러나 다른 언어에는 (그 이름을 가진) "상자"의 개념이 없습니다. crate struct 의 의미 를 이해하려면 먼저 이것에 대해 배워야 합니다. ¹ '언어이상예산'에서 추가 철수를 요구하며, 아직까지 잔고가 긍정적인지에 대해서는 의견이 엇갈릴 수 있다.

한편 pub(crate) 는 두 가지 문제를 모두 해결합니다. 가시성 수정자이며 범위가 무엇인지 알려줍니다. 그러나 그 대가로 길고 어색합니다.

이것이 기본적으로 곤경의 형태입니다.

¹ (위의 누군가가 " crate 가 무엇을 의미하는지 물었고 나는 그것이 가시성 수정자라고 말했고 그것이 끝이었습니다"라는 상호 작용을 설명했습니다. 문제가 있고 아마도 더 일반적인 상황은 다음과 같습니다. 당신 옆에 Rustacean이 앉아 있지는 않습니다.)

FWIW, 상자 로컬 항목의 경우 our 또는 my 로 완전히 괜찮습니다.
our 는 세 글자로 된 키워드이며 pub ~및 Perl~과 잘 어울립니다.
너무 비공식적으로 들리는 것이 문제입니까(영어 원어민에게?)?

사람들은 intern 에 대해 어떻게 생각합니까? crate 보다 한 문자 더 길지만, 그 외에는 Rust를 처음 접하는 사람들에게 crate 보다 직관적이고 $ extern 키워드와 좋은 대칭을 이룹니다.

IMO our 및 my 는 local 및 internal $와 동일한 약점을 가지고 있습니다. 범위가 명확하지 않습니다. local 는 범위가 로컬 변수와 근본적으로 다르기 때문에 상당히 혼란스럽습니다. internal 가 약간 불특정합니다. 무엇에 대한 내부? 모듈? 유형? 상자? 그것이 사용되는 언어에서 온 사람들에게는 분명할 수 있지만 다른 사람들에게는 반드시 그런 것은 아닙니다. our 및 my 는 훨씬 더 모호합니다. 대조적으로 crate 는 범위에 대해 매우 명확합니다.

pub(extern) 에 대해 실제로 질문이 있습니다. pub 앞에 extern "C" fn foo() {} 가 있다는 것이 말이 됩니까? 그렇지 않은 경우 "C"가 아닌 일반 Rust 함수에도 extern fn foo() {} 를 재사용할 수 있기 때문입니다. FFI에 대해 extern 구문을 특별하게 유지하지 않고 이를 통합할 수 있다고 생각했습니다. 즉, extern 는 이제 pub(extern) , pub 는 현재와 동일하게 유지되지만 항목이 지원하는 경우 선택적 ABI 문자열을 허용하고 pub 에 대한 보푸라기를 허용합니다. pub(extern) 또는 extern 없이 내보내고 있습니다.

extern fn foo() {
    println!("Just called a Rust function from Rust!");
}

#[no_mangle]
extern "C" fn foo_from_c() {
    println!("Just called a Rust function from C!");
}

내가 읽은 스레드에서 언급된 것을 본 적이 없으므로 이전에 논의된 적이 있다면 사과드립니다!

앞에 펍 없이 extern "C" fn foo() {} 가 있다는 것이 말이 됩니까?

예- 예를 들어 foo 를 함수 포인터로만 사용하고 싶을 때가 있습니다. 그리고 사실 $ "C" 는 기본적으로 C ABI를 사용하기 때문에 extern extern fn foo() {} 구문을 재사용할 수 없으며, 이것은 적어도 일부에서는 관용적인 것으로 간주됩니다.

여기 오래전에 제안된 내용이 있습니다. 이제 새 모듈 시스템의 일부 측면이 결정화되었으므로 다시 한 번 기회를 줄 수 있습니까?

// Public to the world.
pub struct Foo;

// Private to the crate.
priv struct Foo;

// Basically not visible at all (only inside the module).
struct Foo;

다음을 생각하면 이것이 의미가 있다고 생각합니다.

• "public"을 "전 세계에 공개"로
• "private" as "private to the crate"
• "기본적으로 전혀 보이지 않음"으로 "가시성 수정자 없음"

어떤 사람들은 priv 가 가장 제한적인 것이 아닌 것에 대해 무릎을 꿇는 반응을 보였습니다. 그러나 저는 그것에 대해 두 가지 요점을 말하고 싶습니다.

1. Rust에서 모듈은 네임스페이스 아래에 있는 것을 구성하는 데 사용되는 반면 크레이트는 인터페이스를 정의하는 데 사용됩니다. 따라서 크레이트가 "API 단위"인 경우 가시성 수정자가 주로 크레이트에 대해 이야기하는 것이 합리적입니다.

2. Java가 "클래스에 대한 비공개"를 의미하는 private 와 "패키지 내부에서 볼 수 있음"을 의미하는 가시성 수정자가 없는 실수를 저질렀다고 생각합니다. 나에게는 수정자가 없는 것(즉, 기본값)이 가장 제한적이라는 것이 더 합리적입니다.

@stjepang 나는 대부분의 다른 상황에서 "비공개"가 수정되지 않은 상태보다 더 제한적인 의미를 가질 것이라고 주장합니다. 일반적으로 private-default-public 스펙트럼은 protected-available-advertised와 유사합니다.

프라이빗 클럽은 클럽보다 더 독점적입니다.
사적인 행위는 일반적인 관점에서 숨기기 위해 어느 정도 노력을 기울였음을 의미합니다.
사적인 생각은 진화가 우리에게 텔레파시를 부여하는 데 실패했다는 점을 감안할 때 중복된 개념이어야 하지만 대부분의 사람들은 그것을 공유하지 않으려는 생각을 의미하는 것으로 인식합니다.

경험이 없는 언어 학습자로서, 나는 추가 키워드가 여러 문맥 의존적 의미를 갖는 단일 키워드보다 인지적 부담이 덜하다고 제안합니다. Costello, L 및 Abbot, B "누가 먼저 가는가", 1938년 참조.

my 및 our 에는 우리가 원하지 않는 함축이 있을 것이라고 생각합니다. 키워드로 예약하는 어려움은 제쳐두고요. 그들은 재미있는 농담을 하지만 우리가 그 길을 가야 한다고 생각하지 않습니다.

솔직히 사람들이 crate 가시성이 무엇을 의미하는지 알게 될 것 같습니다. 더 큰 문제는 읽기 어렵거나 구문 분석하기 모호해지는 코드에서 비롯됩니다.

crate struct S(crate crate::Foo);

crate struct S(crate ::Foo);

나는 개인적으로 그것들을 쇼스토퍼로 보지 않지만 여기에서는 분명히 정당한 우려입니다.

스칼라 언어에는 pub(path) 와 유사한 private[path] 가 있으며 거의 ​​동일하게 작동합니다. "이 항목은 비공개이며 $path 내의 사람들만 볼 수 있도록 허용합니다"라고 약간 다르게 읽습니다. 하지만 스칼라에서 무언가를 비공개로 만들려면 주석이 필요합니다. 기본값은 공개이기 때문입니다. Rust에서는 그렇지 않습니다.

friend s 의 C++ 개념도 pub(path) 와 유사한 선례로 생각됩니다.

궁극적으로 문제는 다음과 같습니다.

1. crate 키워드는 상대 경로 가져오기와 가시성 수정자 모두에 사용됩니다.
2. crate 키워드는 pub(...) 와 같은 통합 가시성 수정자 구문을 방지합니다.
3. 일부는 pub(crate) 구문을 싫어합니다(너무 길면 함수 호출처럼 보입니다).

5분 동안 정말 깊이 고민한 끝에 다음과 같은 결론이 나왔습니다... :P

가시성 수정자를 위한 특수 구문

_( @ 를 예로 사용)_

<strong i="18">@pub</strong> use crate::Foo;

<strong i="19">@crate</strong> struct Bar;

나는 개인적으로 그것이 꽤 추하다고 생각하고 @crate 또는 pub(crate) 를 입력하고 싶지 않습니다.

고유 가시성 수정자 키워드

pub 및 extern 가 이미 있으므로 crate 키워드가 아주 잘 맞는다고 생각합니다(일반적인 public , protected , private 키워드).

crate struct Foo;

crate fn path() -> PathBuf { ... }

그러나 내가 말했듯이, 그것은 crate import 접두사와 잘 작동하지 않으며 우리가 이것을 거꾸로 가지고 있는 것처럼 느끼기 시작했습니다. 실제 문제는 예를 들어 구문 강조 표시가 없는 경로 명확성 변경에 있다고 생각합니다.

use crate::utils;

crate 는 특별한 의미가 없는 것 같습니다.

선언적 매크로 구문에서 큰 영감을 받아 가시성 수정자를 위한 일종의 통합 구문을 찾는 대신 다음을 사용하고 싶습니다.

use std::io;
use std::path::Path;

use log::info;

use $crate::utils;

crate fn hello() -> io::Result<()> {
    utils::rm_rf(Path::new("/"))?;
    info!("Goodbye, World!");
}

( self , super 및 crate 경로 가져오기용 특수 앵커에는 접두사가 필요합니다(예: $crate ). 변수처럼 보입니다)

복잡한 예:

crate struct Foo(crate crate::Bar);

됩니다:

crate struct Foo(crate $crate::Bar);

중복 추적 문제가 있는 것 같습니다: https://github.com/rust-lang/rust/issues/45388.
이것에 찬성하여 닫습니다.

Rustc 구현이 이 기능을 dogfood하는 이유가 있습니까? crate fn pub(crate) fn 로 변경될 수 있으며 불안정한 기능 AFAICT에 대한 의존을 중단할 수 있습니다.

우리가 그렇게 할 이유가 없습니다. Clippy와 Rustc는 모두 불안정한 기능을 항상 사용하며 구현에서 버그를 잡는 것과 사용 방법에 대한 느낌을 얻을 수 있다는 점에서 더 광범위하게 테스트할 수 있기 때문에 사용해야 합니다.

이 경우 Clippy 및 Rustc에서 가시성 수정자로 crate 를 사용하면 pub(crate) 보다 읽기 좋고 이 추적 문제에서 언급된 대부분의 문제는 -실제 문제. 내 생각에 https://github.com/rust-lang/rust/issues/53120#issuecomment -413466129, https://github.com/rust-lang/rust/issues/53120#issuecomment -414392549, https://github.com/rust-lang/rust/issues/53120#issuecomment -414392549 crate 가 외부에서도 잘 작동한다고 제안합니다.

실제로 잘 작동 하기 때문에 언어 팀의 많은 사람들이 그것에 대해 긍정적 으로 생각하고 RFC 승인 되었기 때문에 struct Foo ( crate :: foo :: Bar ) 를 구문 분석하는 방법을 고려한 후 가시성 수정자로 crate 안정화를 고려해야 한다고 생각합니다. struct Foo ( crate :: foo :: Bar ) ( 현재 경로로, 아마도 맞을 것입니다 ).

FWIW, 나는 화물-n64 에서 이 기능을 사용하고 있으며 매우 좋았습니다!

나는 crate 을 사용하고 있는데, 그 이유는 그것이 짧고 pub(crate) 와 같은 괄호가 없기 때문입니다.
그래도 읽는 방식은 여전히 ​​마음에 들지 않습니다.
또한 3글자가 없기 때문에 pub <-> crate 와 함께 서식이 변경됩니다.
나는 여전히 아이러니하게도 our 를 좋아한다.

@petrochenkov 당신이 쓴 것에 대한 나의 이해는 당신이 pub(crate) 보다 $ crate 를 선호하지만 crate 보다 더 나은 것을 원한다는 것입니다. 정확한 평가인가요?

FWIW, 나는 여전히 intern 가 좋은 선택이라고 생각합니다.

• 괄호 없음
• pub(crate) 보다 짧음( crate 보다 한 문자 길지만)
• crate (경로와 같은 다른 용도로 사용됨, 예: crate::foo::bar )보다 읽기(IMO)가 더 좋습니다.
  
  
  
  • https://github.com/rust-lang/rust/issues/53120#issuecomment -411025646
  
  
• 기존 extern 와 대칭이 좋습니다.
• 다른 언어에서도 비슷한 것을 사용하기 때문에 익숙합니다( internal ). 코틀린, C# 등

즉, 나는 또한 pub(crate) 로 대체되어야 한다는 데 동의 합니다 .

그럼 해결되었습니다-- 세 글자가 좋고 "인턴"이 좋으므로... int . ;)

crate ::T (공백 포함) 케이스에 대한 보풀을 주시겠습니까?

@Centril 우리 중 몇 명이 #rocket 에 대해 논의하고 있었습니다. 최근 의견에 따르면 가까운 장래에 FCP가 제안될 가능성이 있습니까?

@jhpratt 글 을 쓰고 결국 제안하려고 했는데 다른 일로 바빴어요. 조만간 시간내서 찾아봐야겠습니다.

그래서, 나는 단지 문제를 탐색하고 매크로에 대한 것을 찾고 있었고 이것을 발견했습니다.

이미 오랫동안 pub(crate) 를 안정적으로 보유하고 있으니 이 문제를 닫아야 하지 않을까요?

흥미롭게도 이것은 최근 lang-team 회의 에서 방금 제기되었으며, 여기에서 우리가 되살리고 싶은 가능한 문제로 논의했습니다.

개인적으로 말하자면, 필드에 crate fn 및 crate foo: T 를 쓸 수 있다는 것이 확실히 그립습니다. pub(crate) 와 구문상의 큰 차이는 없지만 특히 공개 필드가 많은 구조체에서 코드를 훨씬 더 읽기 쉽게 만듭니다. 또한 합리적이고 유용하고 단순화된 "프라이버시 모델"에 기여한다는 것을 알았습니다.

• 구조체, 필드는 모듈 에 대해 로컬입니다(매우 좁은 추론).
• 또는 현재 크레이트 내의 어딘가에서 사용됩니다( crate , ripgrep해야 함)
• 또는 전 세계에 공개됩니다( pub ).

제 생각에는 이 키워드와 https://github.com/rust-lang/rust/issues/48054 에 구상된 변경 사항 사이에 교차점이 있으며 함께 채택하고 싶습니다. 나는 세부 사항을 잊어 버렸지만 위의 모델을 실행하려고 할 때 얻을 수있는 오류가 있었던 것으로 기억합니다.

이에 대한 첫 번째 단계는 누군가가 역사를 문서화하고 제기된 모든 우려 사항을 강조 표시했는지 확인하는 글을 작성하는 것입니다.

내가 기억하는 한 가지 구체적인 문제는 다음의 구문적 모호성입니다.

struct Foo(crate ::x)

오늘날, 이것은 허용되고 crate ::x 는 crate::x 경로로 구문 분석되지만 그럴듯하게 사용자는 $ ::x 를 경로로 사용하여 가시성 수정자 역할을 하도록 crate 를 의미했습니다. .

나는 crate 수식어를 다시 도입하고 위의 경우의 구문 분석을 오늘날과 같이 유지하는 경향이 있습니다. Rust 2018 이후로 ::foo 경로는 대부분 더 이상 사용되지 않습니다. 여전히 존재하며 매크로와 같은 특정 컨텍스트에서 유용할 수 있지만 대부분의 용어는 이제 crate_name::b 처럼 보이는 절대 경로를 권장합니다. crate_name 는 키워드 crate 이거나 다른 상자의 이름일 수 있습니다. 따라서 crate::x (공백 무시)가 실제로 경로 로 사용되었기 때문에 현재 구문 분석이 정확할 가능성이 높습니다.

잠재적인 사용자 혼란을 해결하려면 공백에 민감한 린트가 합리적으로 좋은 생각이라고 생각합니다. 즉, struct Foo(crate ::x) 는 경고하지만 struct Foo(crate::x) 는 경고하지 않지만 둘 다 허용되고 동등합니다.

개인적으로 저는 통합 구문과 단순한 lookahead(1) 파서를 더 선호합니다. 또한, 크레이트는 크레이트이고, 거기에 crates.io 가 있으며, 그 모든 것은 가시성과 _직접_ 관련이 없습니다 — pub(_) 컨텍스트에서만.

하지만 내가 뭘 알아? 또 다른 관점일 뿐입니다. 여러분은 의심할 여지 없이 더 많은 경험과 더 가치 있는 의견을 가지고 있습니다.

@nikomatsakis 이 사용 사례에 대해 intern 에 대한 생각이 있는지 궁금합니다(또는 이 시점에서 범위를 벗어나는 새 키워드를 예약하고 있습니까?).

몇 년이 지난 후에도 내 느낌은 여전히 ​​같습니다. 가독성을 위해 최적화합니다 . 코드를 작성 하는 것보다 읽는 것이 훨씬 더 많다는 것을 알게 되었습니다. 그래서 제 생각에는 pub(scope) , pub , pub(crate) , pub(super) , pub(in proto::h1) 를 읽는 것이 더 명확합니다. .

그러나 나는 우리가 이러한 의견과 대화하는 데 실제로 새로운 것을 추가하고 있다고 생각하지 않습니다. 결정은 새로운 것에 근거해야 합니까? 또는 달리 말하면, 이 구문을 채택하기로 한 결정이 몇 년 전에 아니요 또는 연기되었을 때 예가 되어야 한다고 결정하는 방법은 무엇입니까?

또한 합리적이고 유용하고 단순화된 "프라이버시 모델"에 기여한다는 것을 알았습니다.

• 구조체, 필드는 모듈 에 대해 로컬입니다(매우 좁은 추론).
• 또는 현재 크레이트 내의 어딘가에서 사용됩니다( crate , ripgrep해야 함)
• 또는 전 세계에 공개됩니다( pub ).

나는 이 단순화의 이점과 표현력을 상실할 가치가 있는 방법을 이해하지 못합니다. 가치 있는 일을 위해 나는 종종 아이템을 부모 모듈에 공개하지만(형제 모듈이 사용할 수 있도록) 전체 크레이트가 아닌 항목을 공개합니다. 조부모 모듈에 공개는 덜하지만 여전히 가끔 있습니다.

pub(super) 의 사용을 중단하는 것은 상당한 손실이 될 것이라고 생각합니다.

이와는 별도로 crate 명사 를 독립적으로 존재할 수 있는 항목을 수식하는 한정자로 사용하는 것에 대해 흥분하지 않습니다. 비교를 위해: pub(lic), unsafe, const(ant)는 형용사입니다. 항목 정의에서 이미 키워드로 사용된 명사는 한정자가 아니라 해당 항목의 특성을 나타냅니다: 기능, 특성, 모듈, …

상자는 이미 우리가 다루는 개념이지만 이 제안에서 crate 로 시작하는 항목 정의는 새 상자를 정의하지 않습니다.

약간의 새로운 정보:

Rust-analyzer는 pub(crate) 추가에 대한 완성 기능과 지원을 제공합니다. 이는 (주관적으로) 세 번의 키 입력으로 입력하는 것을 훨씬 덜 성가시게 만듭니다.

여기에 새로운 정보가 거의 추가되지 않는다는 데 동의합니다. 우리가 제안을 옹호하고 싶다면, 좋은 다음 단계는 돌아가서 해결되지 않은 문제를 요약하고 이를 lang 팀이 시도하고 최종 결정에 도달하기 전에 가져오는 것이라고 생각합니다. 나는 확실히 이 제안을 수락하거나 거부하는 것을 선호할 것입니다.

이 문제 전체를 빠르게 살펴 보니 @nikomatsakis 의 최근 댓글 이 모든 것을 잘 요약하고 있다고 생각합니다. intern 와 같은 것을 여전히 지원하는 소수의 사람들을 제외하고는 crate 가 가장 논리적인 것 같습니다( RFC 2126 에서 허용됨). 유일하게 해결되지 않은 문제는 fn foo(crate ::bar) 구문 분석 방법입니다.

기본적으로 경고하는 공백에 민감한 보푸라기가 시작하기에 가장 논리적인 위치인 것 같습니다. crate ::bar 는 현재 경로로 구문 분석되며 Rust 2015와 2018 모두에서 그대로 유지되어야 합니다. 그러나 에디션의 주요 변경 후보가 될 것이라고 생각합니다.

crate ::bar 사례는 실제로는 전혀 중요하지 않으며 이미 나머지 언어와 일관되게 동작합니다. 그것은 지속적으로 토론의 빨간 청어였습니다, 제발 관심을 집중하지 마십시오.

나는 확실히 이 제안을 수락하거나 거부하는 것을 선호할 것입니다.

나는 거부에 투표할 것이라고 생각합니다.
나는 Rustc에서 pub(crate) crate 를 지속적으로 사용해 왔으며 더 짧음에도 불구하고 여전히 대부분의 경우, 특히 필드 또는 수입품에서 어울리지 않고 crate 중에서 선택합니다. pub(crate) 는 두 가지 악 중 어느 것이 더 작은지 확실하지 않은 상태에서 둘 중 하나를 선택하는 것처럼 느껴집니다.

응. 더 중요한 것은 @SimonSapin 이 crate bar 가 실제로 새 크레이트를 정의하는 것처럼 보이지만 실제로는 새 크레이트를 정의하지 않는다고 언급한 것입니다.

@petrochenkov 보푸라기가 말이 되지 않는다고 생각하십니까? 개인적으로 이 토론을 보지 않고 crate ::bar 를 보았다면 pub(crate) ::bar 처럼 작동할 것으로 예상합니다. 경로에 공백을 허용하는 것은 _전혀_ 혼란스럽다고 생각합니다.

@jhpratt 파서가 토큰으로 작동하는 방식의 특성으로 인해 경로 세그먼트 사이의 공백을 거부하기 어려울 것입니다. 또한 quote!, syn 및 기타 여러 도구와 같은 엄청난 양의 도구를 깨뜨릴 것입니다.

나는 이것을 닫는 것도 지지할 것이라고 생각한다. 나는 간결함을 얻는 것이 가독성에 대한 잠재적인 손실의 가치가 있다고 생각하지 않는 이 구성의 의미에 대해 표현된 혼란을 충분히 보았습니다.

이것은 "더 큰"(그러나 닫힌) 추적 문제 #44660에 더 잘 맞을 수 있지만 가시성 수정자와 직접 관련이 있으며 #44660의 다른 하위 문제에는 맞지 않습니다.

어떤 시점에서 누군가 pub(in path) pub(crate) 및 pub(super) 를 포함하여 이제 pub(path) 가 합법적일 수 있다고 제안한 것을 기억합니다. 이는 pub(...) 의 멋진 단순화인 것 같습니다. crate 와 다른 방향이지만 우리도 고려할 수 있습니다.

편집 : 실제로 이것이 작동하는지 확실하지 않습니다 ... struct S(pub(path) Type) 는 struct S(pub (Type,)) 와 같은 것으로 (LL-esque 구문 분석에) 모호합니다.

그래서 나는 지난 몇 달 동안 이 생각을 해왔다. "닫기" 위치에 다다랐다고 생각합니다. 제 입장을 요약하면 다음과 같습니다.

• "3가지 수준의 가시성"(모듈, 상자, 세계)이라는 아이디어는 비교적 간단하고 매력적이지만 일반적인 실제 사례를 놓치고 있습니다. pub(super) , 특히 두 개 이상의 수준(예: pub(crate::foo) )이 필요한 경우는 드물지만 실제로는 매우 일반적이라는 것을 알았습니다. 예를 들어, 종종 하위 모듈이 있는 모듈을 원하는데 이러한 세부 사항에 대해 상자 가시성을 사용하면 의도한 개인 정보 보호 수준을 전달하는 데 실패합니다.
• "상자의 일부에 국한되거나 전 세계에 공개되는" 모델도 개념적으로 간단하고 우아하며 이러한 모든 사용 사례를 다룹니다.
• pub(crate) fn 는 crate fn 보다 훨씬 덜 간결하지만 그렇게 나쁘지는 않습니다. pub(crate) 가 pub(crate::foo) $ 로 확장되는 것이 귀엽습니다. 이는 제가 가끔 받는 다른 사용 사례(예: 크레이트 내의 "큰" 모듈)를 포함하지만 너무 장황합니다. 그 큰 모듈이 어쨌든 하위 상자에 포함되는 것이 더 나을 가능성이 큽니다...
• "혼합된 수준의 개인 정보 보호"와 관련된 가장 큰 인체 공학적 장애물은 (예:) pub(x) fn 에 나타나는 모든 유형이 적절한 개인 정보 보호를 보장하도록 하려는 보푸라기와 오류에서 비롯된 것 같습니다. 우리는 그 규칙을 수정했고 더 이상 그런 성가신 일을 겪지 않은 것 같습니다. 그리고 그러한 성가신 일이 더 많이 발생하면 우리도 해결할 수 있다고 생각합니다.
  
  
  
  • 예를 들어, 필드에 pub 를 작성하여 "구조체 자체만큼 공개"를 의미하는 것이 가능하며, 제 생각에는 잘 작동한다고 생각합니다.
  
  

그리고 물론 지금 crate fn 을 추가하지 않는다고 해서 나중에 추가할 수 없다는 의미는 아닙니다. 특히, 다른 크레이트 내에서 "가벼운 인라인 크레이트"를 수행할 수 있는 방법이 있다면 "프라이버시 수준 3단계" 모델이 더 잘 작동할 것이라고 생각합니다. 즉, 크레이트 내에 하위 모듈을 갖는 대신 암시하는 모든 것이 포함된 전용 크레이트 를 선언할 수 있다면(가장 특히, 아마도 다른 것들에 대한 DAG와 같은 관계일 것입니다). 경량 인라인 크레이트가 실제로 작동하는지 확실하지 않지만 pub(super) 와 같은 많은 사용 사례를 덮고 대체할 수 있습니다. 그것을 탐구한다면 crate fn 에 대한 토론을 다시 시작하는 것이 좋습니다. 훨씬 더 유용하고 일반화될 수 있기 때문입니다.

요컨대, 컴파일러에서 crate 가시성 수준을 제거하고 기능 게이트를 제거하는 것을 찬성합니다.

이 기능이 언제 안정화될 수 있는지 확인하고 싶었고 제거할 계획이 있다는 사실에 놀랍고 실망스럽습니다. 나는 그것이 추가된 지 얼마 되지 않아 그것을 일상적으로 사용하고 있으며 위에서 논의한 문제에 대해 거의 신경 쓰지 않습니다. 예를 들어 crate ::path 와 유사한 것은 아직 작성하지 않았으며 ::path 구문을 만진 적이 없기 때문에 아마 절대 작성하지 않을 것입니다.

물론 개선의 여지가 있습니다. 키워드를 선택하는 것이 더 좋을 수 있습니다. pub(super) 는 여전히 불편하고 도우미 메서드에 대해 크레이트 수준 가시성을 사용할 때 사방에서 데드 코드 경고를 받는 것은 성가신 일입니다. 하지만 사용자로서 더 나은 솔루션을 찾을 때까지 이 기능을 그대로 두는 것이 좋습니다(기능 제한). pub(crate) 구문은 눈에 거슬리고 큰 모듈을 더 작고 촘촘한 모듈로 나누는 것을 약간 권장합니다.

"혼합된 수준의 개인 정보 보호"와 관련된 가장 큰 인체 공학적 장애물은 (예를 들어) pub(x) fn에 나타나는 모든 유형이 적절한 개인 정보 보호를 유지하도록 하려는 보푸라기와 오류에서 비롯된 것이라고 생각합니다.

이것은 "unreachable pub" 린트( mod private { pub fn f() {} } )도 활성화하지 않는다는 것을 의미합니까?

헉, 여러가지 Rustc 코드를 읽고 crate 가 사용되는 것을 보면서 곰곰이 생각해 보았는데, 그런 경우들이 모두 pub(crate) ... 해볼 만한 가치가 있을 것 같습니다. diff가 나를 어떻게 느끼는지 확인하기 위해 실험적으로 전환합니다. 우리가 야간에서 마구간으로 그것을 옮겼을 때 분필에 대해 슬펐던 기억이 납니다. 하지만 지금은 그것에 익숙해져서 그렇게 많이 귀찮게 하지는 않았습니다.

@matklad 나는 그렇지 않기를 바랍니다. 보푸라기도 꽤 중요하다고 생각합니다. 솔직히 말해서, 나는 왜 내가 예전에 겪었던 것과 같은 종류의 오류와 성가심에 직면하지 않았는지 완전히 확신하지 못합니다. 최근에 Rust 코드를 충분히 작성하지 않았을 수도 있습니다! 내가 원했던 것보다 더 많은 것을 pub 만드는 것 외에는 컴파일러를 만족시킬 수 없는 것처럼 보이는 짜증나는 주기가 있었다는 것을 확실히 기억합니다.

pub(crate) 를 유지하고 별칭 pubc 을 추가하는 것은 어떻습니까? 이것은 매우 유사하게 읽고 현재 코드를 손상시키지 않으며 괄호를 입력할 필요가 없습니다(좀 더 빨라짐).
이것은 또한 부모에서 가시성을 위해 pubs 를 허용합니다.

요컨대 저는 컴파일러에서 crate 가시성 수준을 제거하고 기능 게이트를 제거하는 것을 찬성합니다.

코드를 읽을 때 pub(crate) 가 눈에 거슬리고 시끄럽습니다. 대신 crate 가시성 수정자가 있으면 정말 좋을 것입니다.

그리고 물론 지금 crate fn 을 추가하지 않는다고 해서 나중에 추가할 수 없다는 의미는 아닙니다. 특히, 다른 크레이트 내에서 "가벼운 인라인 크레이트"를 수행할 수 있는 방법이 있다면 "프라이버시 수준 3단계" 모델이 더 잘 작동할 것이라고 생각합니다. 즉, 크레이트 내에 하위 모듈이 있는 대신 암시하는 모든 것을 포함하는 private _crate_를 선언할 수 있다면(가장 주목할만한 것은 아마도 다른 것들에 대한 DAG와 같은 관계일 것입니다). 경량 인라인 크레이트가 실제로 작동하는지 확실하지 않지만 pub(super) 와 같은 많은 사용 사례를 덮고 대체할 수 있습니다. 그것을 탐구한다면 crate fn 에 대한 토론을 다시 여는 것을 고려할 것입니다 crate fn 훨씬 더 유용하고 일반화될 수 있기 때문입니다.

나는 당신이 언급한 이 "경량" 상자를 확실히 원합니다! 약간 무거운 작업 공간으로 즉시 이동하는 것보다 훨씬 낫습니다.