Rust: 기본 인수 및 키워드 인수

이에 대한 계획은 없었지만 아직 아무도 반대의 목소리를 내지 않았습니다. 저는 이 문제에 대해 오랫동안 생각해 왔으며 기본적으로 기본 인수에 대한 요청으로 요약됩니다. 나는 그것이 다음과 같이 보일 것이라고 생각합니다.

fn foo(bar: int, qux=2: int, ham=0: uint) { ... }

그러면 foo(1) , foo(1, 3) , foo(1, ham=4) , foo(6, 7, 8) 등으로 호출될 수 있습니다.

편집: 아래에서 huonw가 제안한 구문을 참조하세요. 현재 선언 구문에서 훨씬 더 좋고 균일해 보입니다.

Triage 2013-08-05: 진전이 없음(내가 알고 있음), 여전히 깔끔하지만; 아마도 선언 구문은 다음과 같을 수 있습니다.

fn foo(bar: int, qux: int = 4, ham: Option<int> = None) { ... }

여기서 RHS는 상수 expr입니다(즉, static 선언에서 유효한 것).

IMO 이것들은 정말 유용합니다. 지정되지 않은 후행 인수에 대해서만 기본값으로 폴백할 수 있는 _default arguments_의 C++ 시스템도 훌륭할 것입니다... 오버로딩만큼 복잡하지 않으면서 대체 명명된 함수 변형의 수를 줄입니다. 구조체 및 열거형 변형에서도 선언할 수 있다면 좋을 것입니다.
명명된 키워드 매개변수를 호출하는 방법/경우에 대한 합의가 있기 전에 필요한 동작의 이 간단한 하위 집합을 구현할 수 있습니다. 그러면 내부가 준비될까요?

이전에 지정된 인수 및 일반 유형 매개변수(예: 0을 조회하는 기능::또는 slice(&self, start:uint , end:uint=self.len ()) /* "foobarbaz".slice(6) == "baz" .. 또는 create_window(parent,x,y, width :uint=parent.width ()/4, height:uint= (width_161)/100) /_ 기본값은 황금 비율 모양의 창이며 크기를 전혀 지정하지 않으면 1/4 화면 너비입니다.. */ .. .. 아니면 코드 부풀림에 대한 레시피처럼 들릴까요?

C++ 스타일 기본값은 하스켈과 같은 부분 기능 응용 프로그램을 배제하지만 들어갈 가능성이 없다고 들었습니까?

기본 인수에 대한 또 다른 아이디어가 있습니다. 인수를 완전히 생략하는 대신 기본값이 있는 인수를 _ 로 호출할 수 있습니다.

따라서 @huonw 의 멋진 예는 다음과 같습니다.

fn foo(bar: int, qux: int = 4, ham: Option<int> = None) { ... }

... 이것을 foo(1, 2, None) , foo(1, _, Some(1)) , foo(1, _, _) 등으로 호출할 수 있습니다.

그러나 이 아이디어는 여전히 엄밀한 위치에 있다는 점을 감안할 때 키워드 인수를 채택하는 데 아무런 이점을 제공하지 않습니다.

제목을 "기본 인수 및 키워드 인수"로 변경합니다.

구현되지 않았지만 ast 및 파서에 추가하려고 시도했습니다. https://github.com/dobkeratops/rust/compare/default_args , 이것이 올바른 방법입니까? (옵션 @expr .. expr이 무엇인지에 대한 제약 조건이 필요합니까? )
이 기능을 실험하기 위해 물에 발가락을 담그고 있습니다.
번역할 수 있는 C++ API의 하위 집합을 늘리기 위해 이것을 열망하고 있으며, C++에서 확실히 그리워하는 부분이며 명명된 키워드 기능은 C++에서 수행하는 것 이상으로 굉장할 것입니다.
두 번째로 제안된 선언 구문을 사용하는 것이 간단하고 논리적으로 보였습니다.

@dobkeratops 는 좋아 보입니다( type Default = Option<@expr> 는 아마도 불필요하지만).

상의 제약 expr 갈 rustc::middle::check_const ; 각 인수를 확인하는 check_fn 와 같은 함수를 추가해야 합니다. (또한 기본 args가 끝에만 표시되는지 확인해야 하며 유형 검사기 rustc::middle::typeck 및 trans 에도 무언가가 있어야 할 것 같습니다. )

Ok 필드의 이름이 필요하지 않은 주석이 되도록 지정되었습니다.
어디를 봐야 하는지 알려주셔서 감사합니다. 나는 rustc::middle::typeck::.. mod.rs (check_fn something )에서 찾고 있었습니다.

'지속적 통합'이라는 이름으로 사소한 기초 작업을 홍보로 제출하는 것이 가치가 있습니까? 만약 내가 이것에 대해 알면 코드베이스를 더 잘 아는 사람이 다른 부분을 훨씬 더 빨리 할 수 ​​있을 것입니다.
나는 항상 변화하는 변화에 대해 편집증적입니다.

당신이 확실히 _반대_ 결정한다면 그것의 유일한 파괴적입니까?

누군가는 이런 종류의 것이 -Z 옵션(..Session::debug_opts…

컴파일러가 아직 사용하지 않는 것을 구문 분석하는 것에 반대할 수 있다는 것을 알 수 있습니다. 경고에서 오류로 변경할 수 있습니다...

@dobkeratops 아직 공식 개발자가 이에 대해 언급하지 않았으므로 PR이 받아들여질 가능성은 거의 없습니다. 여기에서 1) 기본 인수를 원하는지 여부, 2) 그렇다면, 구문은 어떠해야 하는지, 3) 키워드 인수를 원하는지 여부(기본 인수에 대해 선택한 의미 체계가 이를 배제할 수 있기 때문에 ).

좋아, 나는 그들이 아무 것도 차단하지 않기 때문에 오랫동안 아직 우선 순위가 매우 낮을 것이라고 생각한다.
그것은 낮은 매달린 과일, 그리고 C++ 사람들을 위한 또 다른 친숙함일 수 있다고 생각했습니다.
나는 매크로가 때때로 비슷한 일을 할 수 있다고 생각합니다.

명명된 인수가 중요하지 않다는 것을 알 수 있지만 IMO 선택적 인수는 중요합니다. 어떤 곳에서는 주어진 arg가 필요하지 않을 때 더 쉬운 인터페이스를 제공하기 위해 비슷한 서명과 비슷한 이름을 가진 몇 가지 메서드를 본 것 같아요. 기능이 없다는 이유만으로 그런 레거시 기능을 사용하게 된다면 정말 짜증날 것입니다.

여기에 미묘한 부분이 많이 있습니다. 기본 인수는 모두 오버로딩의 암시적 형태이므로 (내 추측으로는) 특성 분석 알고리즘 및/또는 유형 추론과 통합될 가능성이 높습니다. 그다지 어렵지 않을 수도 있지만 신중하게 설계할 가치가 있으며 현재로서는 이를 위한 시간 예산이 있는지 확신할 수 없습니다. _언어_ 기능으로서 나는 그것이 이전 버전과 호환된다고 상상합니다. API 기능으로 API 설계에 일부 정보를 제공하므로 BC 위험을 나타냅니다.

@Seldaek 기본 인수를 원하면 stdlib 이전 버전과의 호환성을 커밋하기 전에 이를 구현하는 것이 중요하다는 데 동의합니다. 그러나 나는 약간 다른 이름과 서명을 가진 함수 접근 방식에 찬성하여 기본 인수를 철학적으로 거부하는 적어도 하나의 언어(Go)를 알고 있습니다.

그러나 Rust와 달리 Go에는 기본 인수의 부재를 덜 고통스럽게 만드는 몇 가지 기능이 있습니다. 하나는 가변 함수가 있습니다.[1] 둘째, 구조체를 생성할 때 필드를 생략할 수 있습니다. 즉, 구성 구조체를 함수에 쉽게 전달할 수 있습니다(생략된 필드는 사용자가 할 수 있는 것이 아니라 컴파일러 지정(?) 기본값으로 설정되는 것으로 나타납니다. 사용자 정의).[2]

전자의 경우 매크로 해커를 사용하여 동일한 결과를 얻을 수 있습니다(비록 구현 비용이 많이 들지만). 실제로 fmt!() 대한 향후 교체는 다음을 수행합니다.

ifmt!("{foo} {1} {bar} {0}", 0, 1, foo=2, bar=3)

이것은 오늘날 작동하는 코드입니다.

후자의 경우 우리가 가진 가장 좋은 유사점은 다음과 같이 기능적 구조체 업데이트를 사용하는 것입니다.

struct Foo { x: int, y: int, z: int }

impl Foo {
    fn default() -> Foo {
        Foo{x: 0, y: 0, z: 0}
    }
}

fn bar(f: Foo) {
    printf!(f);
}

fn main() {
    bar(Foo{y: 5, ..Foo::default()});
}

나는 이 방법이 과거에 기본 인수 부족에 대한 해결 방법으로 무심코 제안된 것을 보았지만 실제로는 꽤 보기 흉합니다( bar(Foo{y: 5, ..Foo::default()}) 와 bar(y=5) 또는 bar(_, 5, _) ), 물론 모든 인수를 전달하려는 _do_ 경우에도 모든 호출자가 구조체를 생성하도록 강제합니다.

다시 말하지만, 저는 Python과 Javascript에서 온 사람으로서 기본 인수를 분명히 환영합니다. 그러나 API를 명시적으로 만드는 Go의 철학에 어느 정도 공감합니다(API 자체의 기능 수를 (잠재적으로 크게) 부풀리는 대가로).

[1] https://groups.google.com/d/msg/golang-nuts/NWMReL1HueQ/X9mdYduCOB8J

[2] http://stackoverflow.com/questions/2032149/optional-parameters

또한 클로저와 상호 작용하고 함수에 대한 일급 참조를 사용한다는 점을 지적해야 합니다.

@bstrie Go 개요에 감사드립니다. 오버로딩은 혼란스러운 API를 생성하기 때문에 아마도 나쁜 생각일 수 있다는 점에 동의합니다. 마찬가지로 원하는 거의 모든 인수에서 콜백을 받을 수 있는 jQuery의 "과부하된" 메서드는 구현하기가 매우 이상하고 고통스럽습니다.

그리고 어떤 경우에는 기본 인수를 채우는 래퍼 함수가 그렇게 나쁘지 않다는 데 동의합니다. 그러나 문제는 일부 혼란스러운 경우를 방지하는 반면 다른 경우에는 많은 상용구를 도입한다는 것입니다. 한 가지 예는 *::to_str_radix(num, radix) 입니다. 선택적 인수가 있는 경우 *::to_str(num, radix = 10) 로 접을 수 있습니다. 어떤 경우에는 함수 변형의 폭발로 인해 직관적이지 않고 기억하기가 더 어려워집니다. 분명히 내 2 센트.

나는 그것들을 연기하기에 좋은 타이밍을 볼 수 있습니다.
그러나 철학적으로 기본값을 _정말__ 생략합니까, 아니면 구현 시간과 예산 절충안을 정당화하는 것뿐입니까? 누군가가 long_function_names_with_lots_of_trailing_qualifiers를 한 단계 더 나아가는 것이라고 생각했다면 놀랐을 것입니다. :) 하지만 그들이 "간단한 도구를 활용할 수 있게 해주지만 아직 강력한 IDE를 개발하지 못했습니다.."라고 말하면 또 다른 문제입니다.

나는 확실히 C++의 오버로딩과 기본값을 모두 그리워합니다. 그러나 Rusts의 다른 편리함과 C++ 대안의 약속(오랫동안 1개의 주요 언어에 매달린 후..)

실험을 위해 '파서 해킹'으로 수행하려고 생각했습니다... 매크로 수준에서 작업합니까? 인수가 누락 된 호출 사이트에서 기본 expr을 인라인 하시겠습니까?
나는 그것이 받아들일 수 있는 디자인일 것 같지 않다는 것을 알고 있습니다 - 그러나 그것은 녹스의 기능과 함께 작동하는 기본 인수를 갖는 것이 _불가능_하지 않다고 믿게 만듭니다.

내가 여전히 정말로 익숙해지고 있는 한 가지는 방법이 이론상 녹에서 훨씬 더 유용하다는 것입니다.
C++로 돌아가서 나는 헤더/종속성 문제 때문에 그것들을 두려워합니다(이것이 내가 여기 있는 주된 이유입니다). 그래서 저는 종종 본능적으로 함수를 먼저 찾습니다.
아마도 Rust를 더 잘 사용하면 기본값을 덜 그리워 할 것입니다.

아이디어가 사라지지 않도록: bar(Foo{y: 5, ..Foo::default()}) 의 수다스러운 측면은 제가 보기에 ..Foo::default() 부분인 것 같습니다.

구조체 생성에서 필드를 생략하는 것을 더 쉽게 만들고 기본값으로 떨어뜨리면 이 접근 방식이 더 입맛에 맞을 것입니다.

예를 들어 어떤 적절한 특성( Zero 또는 Default )을 구현하는 구조에 대해서만 정의된 새 형식은 다음과 같습니다.

Foo{y: 5, *) 여기서 * 는 이전 ..Foo::default() 합니다.

그런 다음 예제는 "단지" bar(Foo{y: 5, *}) 입니다. 다른 사람들은 Foo 도 거기에 없는 것을 선호할 수도 있지만 이것은 나에게 꽤 깨끗해 보입니다.

열거형은 또한 C++ 프로그래머가 사용하는 것과 다르게 선택적 매개변수 그룹을 편리하게 전달하는 다른 방법과 주석 및 값을 호출로 산재하는 방법을 제공한다고 가정합니다.
설정 매개 변수가 많은 것을 만드는 것과 같은 경우에 잘 맞는 것 같습니다.

@pnkfelix 해당 예제의 Foo 구조체는 아마도 훨씬 더 자체 설명적인 이름을 가질 것이며 제안한 설탕을 사용하더라도 실제로는 다음과 같이 보일 것입니다.

html::start_server(html::ServerOpts{port: 10088, *});

조금 더 멋져 보입니다. 새 구문을 보증하기에 충분한지 또는 기본 인수의 모든 사용 사례를 충족하기에 충분한지 여전히 확실하지 않습니다.

사실, 내 자신의 예를 사용하려면 HTML 서버와 같은 많은 옵션을 사용하여 무언가를 초기화할 때 미리 server_opts 구조체를 설정한 다음 start_server(server_opts) 호출하는 것만큼 행복할 것입니다 ..html::ServerOpts::default 한 줄을 추가해도 상관 없습니다.

기본 인수가 가장 유용한 위치를 다시 생각해야 할 수도 있습니다. 제게는 많은 잠재적인 논쟁이 있는 곳이 아닙니다. 이것은 상당히 드물고 구성 구조체를 초기화하는 몇 줄이면 충분합니다. 오히려 1) 작업이 상당히 일반적이고 2) 작업에 거의 항상 불필요하지만 완전성을 위해 필요한 하나 또는 두 개의 인수가 작업에 있을 때 기본 인수를 가장 그리워합니다. 예를 들어:

let foo = Some('a');
foo.unwrap();  // same as today
foo.unwrap('z');  // imagine that this replaced unwrap_or_default

int::from_str("4");  // same as today
int::from_str("4", 16);  // imagine that this replaced from_str_radix

그러나 이제 이러한 항목을 입력하고 나면 실제로는 별도의 메서드가 명시적으로 표시되는 것을 선호합니다. :) 어쩌면 나는 결국 내가 무엇을 원하는지 정말로 모를 수도 있습니다!

@dobkeratops , C++에 대한 경험에서 기본 인수로 활성화되는 멋진 C++ API의 몇 가지 예를 제공할 수 있습니까?

https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-08-13의 댓글은 개발자가 이것을 먼 미래의 기능으로 보고 있음을 나타내는 것 같습니다. 지명.

OCaml은 오버로딩 없이 선택적/기본 인수를 수행한다고 생각합니다. 기본값이 없는 T 유형의 선택적 인수는 암시적으로 T 옵션으로 변환되며 함수는 값이 제공되었는지 확인해야 합니다. 또한 인수가 생략된 경우 컴파일러가 알 수 있도록 선택적 인수의 선언 및 사용에 대한 제한이 있습니다. 모든 선택적 인수에는 레이블이 있어야 합니다(선택 사항이 되려면 키워드 인수여야 함). 이것은 OCaml의 유형 시스템을 복잡하게 만들지만(레이블은 함수 유형의 일부가 됨) 이것은 Hindley-Milner 유형 시스템의 나머지 부분과 상호 운용해야 하는 결과라고 생각합니다.

C++에서 오면 기본 인수 값이 정말 그리울 것입니다. 나는 종종 많은 수의 매개변수가 있는 함수를 사용하는데, 드물게 사용하거나 테스트 사례를 제외하고 대부분은 거의 항상 기본값을 사용합니다. 기본값 대신 순전히 조합 함수 이름 파생물을 추가하면 정말 긴 이름이 엉망이 됩니다.

기본 인수 및/또는 키워드 인수가 매우 유용할 것이라는 데 동의합니다. 오버로딩과 관련하여 수행해야 하는 작업을 설명하고 구문에 대해 논의해야 하는 1.0 이전 제안을 위해 작업해야 한다고 생각합니다.

더 많은 사람들이 찬성하는 댓글을 보니 반갑습니다 :) 내가 원했던 또 다른 이유는 원활하게 번역될 수 있는 C++ API의 양을 늘리는 것이었습니다. C++ 라이브러리를 사용하는 것은 우리가 C++에 집착하는 큰 이유 중 하나입니다.

커뮤니티가 핵심 개발자에게 비용을 들이지 않고 _구현할 수 있다면 우리가 이것을 얻을 수 있는 유일한 방법이 아닐까 생각합니다.
나는 그들이 해야 할 훨씬 더 중요한 일이 있다는 데 동의하고 열거형은 C++ 조건화된 두뇌에 즉시 명백하지 않은 가능성으로 손실된 다형성을 복구합니다.

이것이 내가 그것을 AST 데이터 구조로 파싱하는 기초를 제출하고 싶었던 이유입니다. 다른 누군가가 그것을 선택하고 해결책을 얻으려고 할 준비가 되어 있을 것입니다. 초기 피드백으로 인해 PR을 하지 못하게 되었습니다.

C++에서 나는 스칼라와 파이썬이 이것에 대해 부러워하는 것을 봅니다. 그 우아함을 가진 네이티브 non-GC 언어는 훌륭할 것입니다.
.. 한 곳에서 더 많은 기능, 무슨 일이 일어나고 있는지 파악하기 위해 덜 탐색하고, 더 적은 중첩 깊이, 소스 코드의 더 적은 노이즈. 단순히 타이핑을 줄이는 것이 아닙니다.
어쩌면 더 자체 문서화되어 있다고 주장할 수도 있습니다. 함수 서명은 사용 방법에 대해 더 많이 알려줍니다.

어려운 부분은 유형 검사기이며, 파서 해킹으로 수행된 경우 미묘한 버그 가능성과 혼란스러운 오류를 방지합니다.

당신이 이런 것들을 쓸 수 있다고 상상해보십시오.

fn substr(a:&str, start:int, end:int=a.len())->~str

오류 검사 없이 그런 종류의 것을 AST에 해킹하면 많은 일이 잘못될 수 있다고 확신합니다. 하지만 예상한 대로 수정할 수 있다고 상상해 보세요. :)

그냥 버그입니다. 장점에 대해 토론할 수 있지만 릴리스를 차단하지는 않습니다.

나는 @tautologico 가 그의 코멘트에서 설명한 행동을 좋아합니다.

Rust에 적용하면 다음과 같이 번역될 것입니다.

fn ga(bu: int, zo: Option<int>, meu: Option<int>) {
  let zo = zo.get_or_default(42);
  let meu = meu.get_or_default(99);
  ...
}

그리고 이것들은 모두 유효한 호출일 것입니다:

ga(10, 20, 30); // 20 and 30 are automagically
                // converted to Some(20) and Some(30)
ga(10, 20);         // ga(10, 20, 99) 
ga(10);             // ga(10, 42, 99)
ga(10, None, None); // ga(10, 42, 99)
ga(10, 20, None);   // ga(10, 20, 99)
ga(10, None, 30);   // ga(10, 42, 30)

규칙은 후행 Option<T> 매개변수를 생략할 수 있다는 것입니다. 여기서 Option 유형이 재사용되지만 이로 인해 문제가 발생하면 더 구체적인 OptParam 유형이 생성될 수 있습니다.

이 제안을 통해 호출자는 위치와 관계없이 제공하려는 매개변수와 기본값으로 유지하려는 매개변수를 정확하게 선택할 수 있습니다. 그리고 파라미터 목록에 기본값이 나오지 않는 것도 좋은 일이라고 생각합니다. 이렇게 하면 기본값이 상수 표현식에 국한되지 않고 객체의 상태에 따라 달라지거나 다른 매개변수에 따라 달라질 수 있습니다.

GUI 대화 상자를 표시하는 함수의 실제 예:

fn showDialog(message: ~str,
              parent: Option<Widget>,
              title: Option<~str>,
              type: Option<DialogType>,
              icon: Option<Icon>) { ... }

// Display an info box in the middle of the screen.
// Set the title to "information", translated in the current locale
// Set the icon to an "info" icon
showDialog(~"hello, world!");

// Display a warning box in the middle of the screen.
// Set the title to "warning", translated in the current locale
// Set the icon to a "warning" icon
showDialog(~"sick, sad world!", None, None, WarningDialog);

// Display a warning box in the middle of the screen.
// Set the title to "warning", translated in the current locale
// Set the icon to a custom icon
showDialog(~"sick, sad world!", None, None, WarningDialog, bugIcon);

이 예에서:

• parent 의 기본값은 None (상위 없음).
• type 의 기본값은 InfoDialog
• icon 의 기본값은 type 의 값에 따라 다릅니다.
• title 의 기본값은 type 의 값과 현재 로케일에 따라 다릅니다.

이제 Option 를 새로운 기본 유형으로 추가하는 것도 제안합니다. 그것은 평범한 오래된 enum 이므로 지금은 완전히 라이브러리 기능입니다.

IMO 기본 인수가 키워드 인수로 10억 배 더 낫다고 덧붙이고 싶습니다. 나는 기본 args가 마음에 들지 않지만 키워드 args는 없습니다.

하나는 다른 하나의 디딤돌이며 기본값은 그 자체로 여전히 유용합니다. 몇 가지 추가 플래그가 있습니다. 기본값만 원하면 생략할 수 있습니다.
둘 다 있으면 잘 결합된다는 데 동의했습니다.
문제는 실제로 구현하는 것입니다. :)
typechecker/type inferer에 다시 장착하는 방법 또는 슬롯에 넣는 방법.

위치 인수의 기본값은 암호 코드를 생성합니다. 왜 키워드 인수에 대한 기본값만 가지고 있지 않습니까? (이것이 구현된 경우).

IMO ... "둘 중 하나"가 아닙니다.
둘 다 유용합니다. 하나는 구현하기가 더 간단하고 구문에서 선택할 수 있는 항목이 적습니다.
그래서 우리가 그것을 디딤돌로 삼거나 먼저 구현하려고 하는 것이 합리적입니다...

기본값으로 설정된 값을 생략하는 것이 어떻게 일반 함수 호출보다 더 비밀스럽습니까? C++ 프로그래머는 이미 thsi에 대한 매개변수 정렬에 익숙합니다. 일반적으로 끝에 적절한 기본값이 있는 일종의 제어 플래그 단어.. 중요한 정보만 나열하여 명확히 하는 것(..,BLAH_DEFAULT)을 작성하는 대신 값을 생략합니다. Rust가 필요한 사람들은 이미 C++를 다루었으므로 그것에 익숙해져 있을 것입니다.

나는 오늘 일찍 위의 내 제안 (구조체를 이미 키워드 인수에 대한 구성 요소를 제공하는 것으로 보기 때문에 기본 인수에 가까운 것을 제공하기 위해 기존 struct-extension 구문을 활용하려고 시도함)이 한 가지 중요한 문제를 무시했다는 것을 깨달았습니다. 내가 제안한 구문 _every_ 인수에 대한 기본값을 제공할 수 있다고 가정했습니다(그런 다음 모두 단일 struct 매개변수로 들어 올려짐).

이것은 물론 일반적으로 사실이 아닙니다. 하나는 필수 인수와 선택 인수가 있는 경우가 많습니다.

함수 선언 구문을 더 이상 사용하지 않고 이미 있는 기능을 활용하는 방법을 찾고 싶습니다. 주로 함수/클로저/메소드를 작성할 수 있는 다양한 방법 덕분에 함수 선언이 _이미 털이 많기 때문입니다.

현재 브레인 스토밍은 구조체 항목 정의에서 필드에 대한 기본 표현식을 추가하여 기존 구조체 구문을 활용할 수 있는지 여부에 중점을 둡니다. 그러면 삭제할 수 있는 일부 필드와 필수 필드를 가질 수 있습니다. 다음과 같은 것:

struct Foo { x: int = 0, y:int = 0, z:int = 0 }

fn bar(f: Foo) {
    printf!(f);
}

struct Baz { x: int, y: int, z:int = 0 }

fn quux(g: Baz} {
    printf!(g);
}

fn main() {
    bar(Foo{y: 5});
    quux(Baz{y: 5}); // ~ERROR: required field, `x`
}

@pnkfelix 나는 그 제안이 마음에

fn bar({ x: int = 0, y:int = 0, z:int = 0 }) {
    printf!(f);
}

fn quux({ x: int, y: int, z:int = 0 }) {
    printf!(g);
}

fn main() {
    bar({ y: 5 });
    quux({ y: 5 }); // ~ERROR: required field, `x`
}

@visionmedia @bstrie 구조체 이름을 없애는 것에 대해 정말로 걱정할 필요가 있습니까? 리바인딩 사용 선언 은 호출 사이트에서 추가 문자의 최소 수를 3(이름 + 왼쪽 및 오른쪽 대괄호의 경우)으로 줄여 긴 이름 문제를 해결하지 않습니까?

즉, bstrie가 나에게 제시한 ServerOpts 예:

fn main() {
  use O = html::StartServerOptions;
  ...
  html::start_server(O{port: 10088});
}

@pnkfelix 좋아요

struct Foo {
   x: int = 10,
   y: float = 1.0
}

구문이지만 합리적인 필수 인수(불행히도 이름이 지정되지 않음)를 얻는 데 필요하지 않다고 생각합니다. 필수 인수를 별도로 전달하면 됩니다.

struct FooOptions { ... }
static default: FooOptions = FooOptions { ... };
fn foo(compulsory: int, required: uint, necessary: float, optionals: FooOptions) { ... }

FWIW, 나는 또한 기본 값 아이디어가 있는 구조체를 좋아합니다. 나는 그것이 바로 가기라고 생각합니다.

struct Test {
    m: int,
    y: int
}

static DEFAULT: Test = Test{m: 10, y: 15};

Test{y: 5, ..DEFAULT}

나는 정의 내부의 구조체 기본값도 좋아합니다.

해당 구문으로 구문 분석을 수행했지만 실제로는 사용하지 않았습니다. 여전히 typechecker 소스 등을 둘러보는 방법을 모릅니다...

아마도 이미 기본 메커니즘이 있다는 사실로 인해 구현하기가 좀 더 쉬워질 수 있습니다.

답장. 익명 구조체는 원래 그것들이 있었다고 생각하지만 '이상한 상호 작용 때문에'제거해야 했습니까?
나는 두 가지 메커니즘을 모두 사용하는 것을 선호합니다. 아마도 매개변수 구조체는 _keyword_ 인수의 필요성을 완화할 수 있지만 C++에서와 같은 후행 기본값은 여전히 ​​편리할 것입니다.

참고로 -
http://www.parashift.com/c++-faq-lite/named-parameter-idiom.html
lol - 흥미롭지 만 진정한 키워드 인수는 이와 같은 보일러 플레이트 무거운 해킹의 필요성을 피할 것입니다.

답장. 익명 구조체는 원래 그것들이 있었다고 생각하지만 '이상한 상호 작용 때문에'제거해야 했습니까?

원래 모든 구조체 유형은 구조적이었습니다. 특성과의 어색한 상호 작용으로 인해 제거되었습니다(명목 구조체 유형으로 대체됨).

나는 구조체 정의 아이디어의 기본값을 좋아합니다. 이것은 이해하기 쉽고 적어도 구조체를 구성할 때 모든 필드를 열거해야 하는 것을 피할 수 있습니다. 이것은 "옵션" 유형 구조체에 대한 문제입니다. 새로운 "선택적" 필드가 추가될 때 모든 호출 사이트가 다음으로 수정되어야 한다는 것을 의미하기 때문입니다. 0/None/etc로 초기화합니다.

Perl(기본값은 임시 패턴임), Python 2( foo() takes at least 2 arguments (2 given) 얻을 수 있음), Python 3(기본값 없이 명명된 전용 인수를 가질 수 있음)에서 나온 저는 겸손하게 제안합니다. 구조체를 함수에 대한 최종 인수로 선언하는 것을 허용하지만 호출자가 구조체 필드를 _inline_하게 하기 위한 _십대_ 비트의 설탕.

예

impl int {
    struct FromStrOptions {
        radix: uint = 10
    }
    fn from_str(s: str, opts: FromStrOptions) -> int {
        // ...
    }
}

int::from_str("4", radix: 10);

장점:

• 함수 정의에 대한 새로운 구문은 없으며 실제로 호출자가 호출하는 방법을 전혀 신경쓸 필요가 없습니다. 이것은 do 하여 블록을 전달하는 방식과 유사합니다. 이는 순전히 호출자의 관심사입니다. (마지막 인수가 구조체이지만 kwargs에 사용하지 않으려는 경우 옵트인/아웃하는 방법이 필요합니까? 아무도 신경 쓰지 않을까요? 아무도 do 신경 쓰지 않는다고 생각합니다.
• 바이너리 레이아웃과 C 호출 의미 등은 여전히 ​​꽤 잘 정의되어 있습니다.
• 유형 또는 arity에 의한 오버로딩은 언젠가는 구현하기가 더 이상 어렵지 않습니다. 단, 최종 인수의 유형이 유형 오버로딩에 기여할 수 없다는 점을 제외하면 말입니다. 가변 인수가 발생하더라도 이를 방해해서는 안 됩니다.
• 동일한 기본값 세트를 여러 기능에서 재사용할 수 있습니다.
• **kwargs 와 같은 무료: 그냥 구조체를 만들고 위치 인수로 전달하면 됩니다.
• 필수 키워드 인수는 자연스럽게 여기에 해당합니다. 구조체에 기본값을 지정하지 않으면 이름으로 _something_을 전달해야 합니다.
• 이름으로 위치 인수를 전달할 때 이상한 혼란이 없습니다. 당신은 그것을 할 수 없습니다.

단점:

• 약간 마법. 그러나 5 전달하고 함수의 argspec에서 유형을 유추하는 것 이상은 아니라고 생각합니다.
• 기존 do 관용구와 상호 작용하는 방법이 명확하지 않습니다. 마지막 인수 _write_ 해야 한다고 말하는 것이 충분히 쉬울 수 있습니다. 즉, do 와 함께 사용될 때만 마지막 인수로 작동합니다.

FWIW int::from_str("4", radix: 10) 는 이전에 제안된 : 를 유형 지정 연산자로 사용하는 것과 충돌합니다.

저주, ASCII에 의해 저지됨.

int::from_str("4", radix☃ 10)

나는 키워드 args에 대해 = 사용에 투표하고, 하위 표현식 내 할당에 대한 C의 아이디어를 허용하지 않습니다. (어쨌든 대부분의 불변의 아이디어에는 적합하지 않을 수 있음) .. 스칼라가 이것을 가지고 있다고 생각합니다. C와 같은 구문에 맞는 가능한 예는 무엇입니까?

이 중 하나를 구현하는 방법에 대해 브레인스토밍할 수 있는 곳이 있습니까? 인수 수를 기반으로 하는 함수 오버로드처럼 변수 argumentmnt 스타일이 내부적으로 구현될 수 있는지 궁금합니다(거의 args 수가 함수 이름에 접미사로 붙은 것처럼 .. )

우리 는 어젯밤 주간

함수 선언/호출 형식을 더 복잡하게 만드는 것은 좋지 않으며 이전 의견 에서 제안한 대로 구조체 선언을 확장하여 필드 기본값(const 표현식과 연결됨)을 허용하는 것이 합리적인 방법이라는 데 모두가 동의했다고 생각합니다. 여기에서 원하는 것의 대부분.

팀은 또한 어떤 방식으로든 이 문제를 해결하는 것이 1.0 릴리스의 우선 순위가 아니라고 결정했습니다. 프로젝트 리더 @brson 은 1.0 이후(예: 1.1 릴리스의 경우)를 위해 이 작업에 대한 프로토타이핑을 남겨둘 것을 제안했습니다.

이것은 모든 기여자에게 강력한 힌트입니다. 원하는 모든 것을 해킹하십시오. 그러나 1.0 릴리스가 나올 때까지 이 버그에 대한 pull 요청이나 r+를 제출하지 마십시오.

손을 들어, Rust는 놀라운 언어입니다. 너무 많은 일을 제대로 해서 웃기지도 않습니다. 하지만 이 기능을 1.0 이후로 연기하는 것은 실수라고 생각합니다.

자세히 설명하겠습니다.

기본 함수 인수는 좋은 API 디자인을 위해 _critical_입니다. 그것들이 없으면 더 간단한 API가 복잡해집니다. std 라이브러리의 예:

• 선택적으로 구분 기호를 사용하는 concat 대신 concat 및 connect .
• split_iter 및 splitn_iter 이상 단지 split_iter 옵션으로 count . rsplit_iter 및 rsplitn_iter 입니다.

다른 사람.

기본 인수로 제거할 수 있는 이러한 모든 추가 기능 이름을 갖는 것은 인지 부하를 불필요하게 증가시킵니다. 사용자는 이제 하나가 아닌 두 개(또는 그 이상)의 이름을 알아야 합니다.

기본 인수가 1.0 이후로 연기되면 이전 버전과의 호환성 때문에 std 라이브러리의 이러한 함수를 제거할 수 없습니다. 이것은 기본 인수가 미래에 추가되고 함수의 "바닐라" 버전이 이제 다른 변형의 작업을 수행할 수 있더라도 이전 변형이 계속 유지되고 누군가가 확실히 사용할 것이기 때문에 개발자는 이에 대해 알아야 함을 의미합니다. 실수로라도.

따라서 추가적인 인지 부하가 ​​_영원히_ 남게 됩니다.

[NB 매개변수 유형 기반 함수 오버로딩에 대해 동일한 주장을 할 수 있지만(현재 특성 기반 해결 방법은 너무 번거롭고 std 라이브러리 함수에서 이를 사용하지 않습니다), 이 문제는 그 논의를 위한 장소가 아닙니다.]

Rust 개발자 여러분, Rust를 작업하고 멋지게 만들어 주셔서 감사합니다!

저는 핵심 팀에서 이 문제에 대해 잠시 시간을 할애하는 사람과 소통하고자 하는 극도의 낙담을 강조하기 위해 "먼 미래" 이정표를 추가하고 있습니다. 지금 Rust에 기여하고 싶다면 마일스톤 1(잘 정의됨)에 있는 41개의 공개 버그 중 하나를 해결하세요.

https://github.com/mozilla/rust/issues?milestone=12&state=open

또는 마일스톤 2(이전 버전과의 호환성)에 있는 104개의 열린 버그 중 하나:

https://github.com/mozilla/rust/issues?milestone=13&state=open

또는 마일스톤 3에 있는 68개의 열린 버그 중 하나(우리가 한 시점에서 동의한 기능은 Rust 1.0을 릴리스하는 데 중요합니다):

https://github.com/mozilla/rust/issues?milestone=14&state=open

또는 버그 중 하나에 대해 설명을 요청하거나 진행 방법을 제안하기 위해 댓글을 달 수도 있습니다. 선택할 수 있는 버그는 213개입니다. 이 시점에서 그 중 하나를 진행하는 것이 이 문제보다 Rust에게 훨씬 더 가치가 있을 것입니다. 그리고 이 버그 중 하나를 닫을 수 있는 사람은 누구에게나 최고의 감사를 표할 것입니다.

핵심 팀이 해야 할 일이 훨씬 더 많다는 것을 알 수 있지만 '극도의 낙담을 전달'하는 것은 부끄러운 일인 것 같습니다.
Vallorics 의견에 +1. 이름을 짓는 것은 어렵습니다. 문서를 파헤치고 더 많은 이름을 배우는 것은 지겹습니다..; 기본 args/overloading을 사용하면 더 쉽게 할 수 있습니다. 키워드 args를 사용하면 이에 대해 C++를 뛰어넘는 기회를 가질 수 있습니다. (나는 github이 투표를 했으면 좋았을 텐데, 여기서 조금 더 욕을 하는 대신 +1을 눌렀을 수도 있습니다.)

@Valloric 나는 전적으로 동의하며(이전에 말했듯이)

이것이 좋은 언어 기능이 될 것이라는 합의는 없습니다. 명명된/기본 매개변수에 대한 모든 세부 사항이 포함된 구체적인 제안도 없습니다. 1.0에서는 발생하지 않을 것입니다. 왜냐하면 매우 불필요한 구문 설탕을 꿈꾸기 전에 수정하거나 제거할 기존의 핵심 언어 기능 세트가 있기 때문입니다.

'dreaming up'은 뭔가 기발한 것처럼 들리지만 이러한 기능은 다른 언어에서 입증되었습니다. 단순히 구문 설탕이 아니라 탐색해야 하는 코드의 양을 줄이고 배워야 하는 기호의 수를 줄입니다.

1.0에서는 발생하지 않을 것입니다. 왜냐하면 매우 불필요한 구문 설탕을 꿈꾸기 전에 수정하거나 제거할 기존의 핵심 언어 기능 세트가 있기 때문입니다.

수정/구현해야 하는 다른 언어 기능이 더 중요하지 않다는 말은 아닙니다. 그들은 아마 그럴 것이다. 그러나 어느 쪽도 아닙니다. 내가 말하고 싶은 것은 이 기능이 없으면 std 라이브러리 _forever_의 API 품질에 영향을 미치기 때문에 1.0에서 (다른 기능과 함께) 이 기능을 강력하게 고려해야 한다는 것입니다.

이것은 아마도 논쟁의 여지가 있는 의견일 수 있지만 IMO 프로그래밍 언어는 핵심 기능보다 제공하는 API에 의해 더 많이 살고 죽습니다. Python의 "배터리 포함" 표준 라이브러리는 전체 언어를 판매했습니다. CPAN은 Perl을 유지합니다. .Net은 C# 코드 작성을 훌륭하게 만들고 LINQ는 얇게 썬 빵 이후로 최고입니다. C++의 가장 큰 단점 중 하나는 우수하고 표준화된 API가 없다는 것입니다. 등.

API는 언어의 성공에 매우 중요하므로 _good_ API 생성을 가능하게 하는 기능이 "비필수적인 구문 설탕"으로 폐기되어서는 안 됩니다.

@dobkeratops : _dreaming up_ 이라는 말을 해서 아직 완전한 제안이 된 것이 아니라서 의사결정 단계가 아니라는 점을 강조하고 싶습니다.

이 토론은 비생산적입니다. 다른 사람의 시간을 더 이상 소모하지 않도록 문제를 종료하겠습니다. 누군가가 지금부터 1년 후 또는 그 이후에 이 책을 다시 열거나(또는 새 문제를 시작하기를 원하면) 괜찮을 것입니다.

누군가가 거의 모든 세부 사항(문법, 의미론)이 포함된 제안을 제안하면 메일링 리스트에 게시하는 것이 좋습니다. 이를 수행하는 특정 방법이 _올바른 방법_이라는 합의에 도달했다면 문제를 열고 once 기능과 같은 플래그 뒤에 실험적 기능으로 구현하는 것이 합리적입니다.

나는 두 번째 @thestinger -- 누군가(또는 소수의 사람들)가 완전한 제안을 가지고 있거나 토론을 위한 몇 가지 명확하게 철자가 있는 공백이 있는 제안을 가지고 있다면 그 사람이 그것을 실행하는 것이 적절할 것입니다. 메일링 리스트로. 우리가 그 제안을 구현한다는 약속은 아니지만 아이디어를 공식화하고 다른 언어 기능과 상호 작용하는 방법을 설명하는 작업을 수행하면 제안의 가치가 크게 증가할 것입니다.

@stinger @catamorphism 열린 마음을 유지해 주셔서 감사합니다! 시간이 나면 제안서를 작성하여 rust-dev에 보내겠습니다.

이 기능에 대해 토론하고 이에 대한 명확한 사양을 작성하기 위해 패드를 만들었습니다. https://pad.riseup.net/p/hvbg6dQQnEe7

다시 열겠습니다. 우선 순위가 아닙니다. 이미 수행해야 할 작업이 너무 많습니다. 하지만 사람들이 원하는 기능이며 완전히 배제된 것은 아닙니다. 나는 그 주제에 관한 어떤 대화도 끊고 싶지 않습니다.

@brson 감사합니다!

나는 etherpad에 대한 링크와 함께 원래 문제를 편집했습니다.

안녕.
패드 생성 이후로 많은 디자인 제안, 질문, 문제 등으로 완성되었습니다...
그래서 토론 패드를 "요약"하기 위해 두 번째 패드를 만들었습니다. 이 패드는 기능 요청을 정확하게 설명하는 데 사용됩니다.
패드 URL: https://pad.riseup.net/p/Ca5PBeDjUGxW

@KokaKiwi 이제 패드가 다 비었습니다. 내용은 어디로 갔나요?

@cmr , 나는 추측한다:

경고: 이 패드는 편집 없이 30일이 지나면 삭제됩니다. 이 일이 발생한 후에는 패드를 복구할 수 있는 방법이 없으므로 주의하십시오!

:찡긋:

실제로 Mozilla Etherpad 인스턴스에서 만든 패드를 검색하고 있지만(이 경우를 방지하기 위해) 내 기록에서 찾을 수 없고 여기에 링크를 게시하는 것을 잊었습니다.(

@cmr @huonw @KokaKiwi , 여기 내 브라우저 기록에 있는 두 개의 링크가 있습니다.

https://etherpad.mozilla.org/CQEDa85jLX
https://etherpad.mozilla.org/78FA1bozLd

@dram 내가
새로운 링크로 문제를 수정해야 할 수도 있습니다.

(수정됨.)

언어에 더 많은 시간을 투자하기 전에 주의 깊게 관찰하고 있는 것 중 하나라는 것 외에는 추가할 의미가 없습니다. 이 기능이 있는 언어(Objective-C 및 Python)에서 나온 명명된 매개변수는 다른 사람들의 코드를 더 읽기 쉽게 만드는 방식 때문에 생산성을 간접적으로 크게 향상시킬 수 있다고 생각합니다.

구체적인 제안은 새로운 RFC 프로세스를 통해 이루어져야 합니다: https://github.com/rust-lang/rfcs

유용한 토론 영역이 되기에는 너무 많은 상충되는 아이디어와 다양한 대화 스레드가 있습니다.