이것은 오픈 소스 릴리스 이전부터 시작하여 과거에 여러 번 논의되었습니다. 과거의 합의는 sum 유형이 인터페이스 유형에 별로 추가되지 않는다는 것이었습니다. 모든 것을 분류하면 결국 컴파일러가 유형 전환의 모든 경우를 채웠는지 확인하는 인터페이스 유형을 얻게 됩니다. 그것은 새로운 언어 변경에 대한 상당히 작은 이점입니다.

이 제안을 계속 추진하려면 다음을 포함하여 보다 완전한 제안 문서를 작성해야 합니다. 구문이란 무엇입니까? 정확히 어떻게 작동합니까? (당신은 그것들이 "값 유형"이라고 말하지만 인터페이스 유형은 또한 값 유형입니다). 장단점은 무엇입니까?

https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/d03t6ji/?st=ixp2gf04&sh=7d6920db 에서 알아야 할 과거 토론을 참조

나는 이것이 Go1의 유형 시스템의 너무 중요한 변경이라고 생각하며 긴급하게 필요하지 않습니다.
나는 이것을 Go 2의 더 큰 맥락에서 다시 살펴볼 것을 제안합니다.

이 제안을 만들어 주셔서 감사합니다. 저는 이 아이디어를 가지고 1년 정도 고민해 왔습니다.
다음은 내가 구체적인 제안을 가지고 있는 한입니다. 제 생각에는
"선택 유형"은 실제로 "합 유형"보다 더 나은 이름일 수 있지만 YMMV입니다.

Go의 합계 유형

합계 유형은 "|"가 결합된 둘 이상의 유형으로 표시됩니다.
운영자.

type: type1 | type2 ...

결과 유형의 값은 지정된 유형 중 하나만 보유할 수 있습니다. NS
유형은 인터페이스 유형으로 처리됩니다. 동적 유형은
할당된 값입니다.

특별한 경우로 "nil"은 값을 사용할 수 있는지 여부를 나타내는 데 사용할 수 있습니다.
0이 된다.

예를 들어:

type maybeInt nil | int

합계 유형의 메소드 세트는 메소드 세트의 교집합을 보유합니다.
동일한 모든 방법을 제외한 모든 구성 요소 유형
이름이지만 서명이 다릅니다.

다른 인터페이스 유형과 마찬가지로 sum 유형은 동적
유형 변환. 유형 스위치에서 스위치의 첫 번째 암은
저장된 유형과 일치하는 항목이 선택됩니다.

합계 유형의 0 값은 첫 번째 유형의 0 값입니다.
합계.

합계 유형에 값을 할당할 때 값이 더 많이 들어갈 수 있는 경우
가능한 유형 중 하나 이상인 경우 첫 번째 유형이 선택됩니다.

예를 들어:

var x int|float64 = 13

동적 유형이 int인 값이 생성되지만

var x int|float64 = 3.13

동적 유형이 float64인 값이 생성됩니다.

구현

순진한 구현은 합계 유형을 인터페이스로 정확하게 구현할 수 있습니다.
가치. 보다 정교한 접근 방식은 표현을 사용할 수 있습니다.
가능한 값 집합에 적합합니다.

예를 들어 포인터가 없는 구체적인 유형으로만 구성된 합계 유형
추가 값을 사용하여 포인터가 아닌 유형으로 구현할 수 있습니다.
실제 유형을 기억하십시오.

sum-of-struct-types의 경우 여분의 패딩을 사용할 수도 있습니다.
그 목적을 위해 구조체에 공통된 바이트.

@rogpeppe 유형 어설션 및 유형 스위치와 어떻게 상호 작용합니까? 합계의 멤버가 아닌 유형(또는 유형에 대한 어설션)에 case 가 있는 것은 컴파일 타임 오류일 수 있습니다. 그러한 유형에 대해 포괄적이지 않은 스위치를 사용하는 것도 오류가 될까요?

유형 스위치의 경우

type T int | interface{}

그리고 당신은 :

switch t := t.(type) {
  case int:
    // ...

t가 int를 포함하는{} 인터페이스를 포함하고 있는데, 첫 번째 경우와 일치하나요? 첫 번째 경우가 case interface{} 이면 어떻게 됩니까?

또는 합계 유형에 구체적인 유형만 포함될 수 있습니까?

type T interface{} | nil 어떻습니까? 당신이 쓰는 경우

var t T = nil

t의 유형은 무엇입니까? 아니면 그 공사가 금지되어 있습니까? 비슷한 질문이 type T []int | nil 대해 발생하므로 인터페이스에 관한 것만이 아닙니다.

예, 컴파일 타임 오류가 발생하는 것이 합리적이라고 생각합니다.
일치하지 않는 경우가 있습니다. 있는지 확실하지 않다.
이러한 유형에 대해 포괄적이지 않은 스위치를 허용하는 것이 좋습니다.
다른 곳에서는 철저함을 요구하지 않습니다. 한 가지
그래도 좋습니다. 전환이 철저하다면 기본값을 요구할 수 없습니다.
종결 진술로 만들기 위해.

즉, 다음과 같은 경우 컴파일러에 오류가 발생할 수 있습니다.

func addOne(x int|float64) int|float64 {
    switch x := x.(type) {
    case int:
        return x + 1
    case float64:
         return x + 1
    }
}

그리고 합계 유형을 변경하여 추가 케이스를 추가합니다.

유형 스위치의 경우

유형 T 정수 | 상호 작용{}

그리고 당신은 :

스위치 t := t.(유형) {
케이스 정수:
// ...
t가 int를 포함하는{} 인터페이스를 포함하고 있는데, 첫 번째 경우와 일치하나요? 첫 번째 케이스가 케이스 인터페이스{}라면?

t는 int를 포함하는{} 인터페이스를 포함할 수 없습니다. t는 인터페이스입니다
다른 인터페이스 유형과 마찬가지로 유형을 지정할 수 있다는 점만 제외하면
구성되어 있는 열거된 유형 집합을 포함합니다.
인터페이스가{} int를 포함하는 인터페이스를 포함할 수 없는 것처럼{}

합계 유형은 인터페이스 유형과 일치할 수 있지만 여전히 구체적인
동적 값을 입력합니다. 예를 들어 다음과 같이 하는 것이 좋습니다.

type R io.Reader | io.ReadCloser

T형 인터페이스는 어떻습니까{} | 무? 당신이 쓰는 경우

var t T = 없음

t의 유형은 무엇입니까? 아니면 그 공사가 금지되어 있습니까? 유형 T []int | nil, 그래서 그것은 단지 인터페이스에 관한 것이 아닙니다.

위의 제안에 따르면 첫 번째 항목을 얻습니다.
값을 할당할 수 있는 합계에서
nil 인터페이스를 얻을 수 있습니다.

사실 인터페이스{} | nil은 기술적으로 중복됩니다. 왜냐하면 모든 인터페이스가{}
0 일 수 있습니다.

[]int | nil, nil []int는 nil 인터페이스와 동일하지 않으므로
콘크리트 값 ([]int|nil)(nil) 될 것이다 []int(nil) 하지 형식화되지 않은 nil .

[]int | nil 사례가 흥미롭습니다. 유형 선언의 nil 가 항상 "nil 인터페이스 값"을 의미할 것으로 예상합니다. 이 경우

type T []int | nil
var x T = nil

x 는 nil []int 가 아니라 nil 인터페이스임을 의미합니다.

해당 값은 동일한 유형으로 인코딩된 nil []int 와 구별됩니다.

var y T = []int(nil)  // y != x

합계가 모든 값 유형인 경우에도 항상 nil이 필요하지 않습니까? 그렇지 않으면 var x int64 | float64 는 어떻게 될까요? 다른 규칙에서 외삽하는 내 첫 번째 생각은 첫 번째 유형의 0 값이지만 var x interface{} | int 어떻습니까? @bcmills가 지적한 것처럼 고유한 합계가 nil이어야 합니다.

너무 미묘한 것 같습니다.

Exhaustive 유형 스위치가 좋을 것입니다. 원하는 동작이 아닐 때 항상 빈 default: 할 수 있습니다.

제안서는 "합계 유형에 값을 할당할 때 값이 더 많은
가능한 유형 중 하나보다 더 많은 경우 첫 번째 유형이 선택됩니다."

따라서:

type T []int | nil
var x T = nil

x는 nil이 []int에 할당 가능하고 []int가 유형의 첫 번째 요소이기 때문에 구체적인 유형 []int를 갖습니다. 다른 []int(nil) 값과 같습니다.

합계가 모든 값 유형인 경우에도 항상 nil이 필요하지 않습니까? 그렇지 않으면 var x int64 | float64?

제안은 "합계 유형의 0 값은 첫 번째 유형의 0 값입니다.
합계."이므로 답은 int64(0)입니다.

다른 규칙에서 외삽하는 내 첫 번째 생각은 첫 번째 유형의 0 값이겠지만 var x interface{} | 인트? @bcmills가 지적한 것처럼 고유한 합계가 nil이어야 합니다.

아니요, 이 경우 일반적인 인터페이스 nil 값일 뿐입니다. 해당 유형(인터페이스{} | nil)은 중복됩니다. 아마도 한 요소가 다른 요소의 상위 집합인 합계 유형을 지정하도록 컴파일러를 만드는 것이 좋을 것입니다. 현재 그러한 유형을 정의할 요점을 볼 수 없기 때문입니다.

합계 유형의 0 값은 합계에서 첫 번째 유형의 0 값입니다.

흥미로운 제안이지만 합계 유형은 현재 보유하고 있는 값의 유형을 어딘가에 기록해야 하기 때문에 합계 유형의 0 값이 전체 바이트 0이 아니므로 다음과 다를 수 있습니다. Go의 다른 모든 유형. 또는 유형 정보가 없으면 값이 나열된 첫 번째 유형의 0 값이지만 그렇지 않은 경우 nil 를 표현하는 방법을 모르겠다는 예외를 추가할 수 있습니다. 나열된 첫 번째 유형.

따라서 (stuff) | nil 는 (stuff)의 아무 것도 nil이 될 수 없고 nil | (stuff) 는 물건의 어떤 것이 nil이 될 수 있는지 여부에 따라 다른 것을 의미할 때만 의미가 있습니까? nil은 어떤 가치를 더합니까?

@ianlancetaylor 나는 많은 기능적 언어가 C에서와 같이 본질적으로 (닫힌) 합계 유형을 구현한다고 믿습니다.

struct {
    int which;
    union {
         A a;
         B b;
         C c;
    } summands;
}

which 가 Union의 필드를 순서대로 인덱싱하면 0 = a, 1 = b, 2 = c, 0 값 정의는 모든 바이트가 0이 되도록 작동합니다. 그리고 인터페이스와 달리 다른 곳에 유형을 저장해야 합니다. 또한 유형 정보를 저장할 때마다 일종의 nil 태그에 대한 특별한 처리가 필요합니다.

그렇게 하면 특별한 인터페이스 대신 Union의 값 유형이 만들어지는데, 이것도 흥미롭습니다.

유형을 기록하는 필드에 첫 번째 유형을 나타내는 0 값이 있는 경우 모두 0 값이 작동하도록 하는 방법이 있습니까? 이것을 표현하는 한 가지 가능한 방법은 다음과 같다고 가정합니다.

type A = B|C
struct A {
  choice byte // value 0 or 1
  value ?// (thing big enough to store B | C)
}

[편집하다]

@jimmyfrasche 가 저를

nil로 추가할 수 없는 것이 있습니까?

type S int | string | struct{}
var None struct{}

?

그것은 많은 혼란을 피하는 것처럼 보입니다 (적어도 내가 가지고있는)

또는 더 나은

type (
     None struct{}
     S int | string | None
)

그런 식으로 switch on None 하고 None{} 할당할 수 있습니다.

@jimmyfrasche struct{} 는 nil 같지 않습니다. 사소한 세부 사항이지만 합계에 대한 유형 전환을 불필요하게(?) 다른 유형의 유형 전환과 분기하게 만들 것입니다.

@bcmills 달리 주장하려는 의도는 아니었습니다. 합계의 모든 유형에서 nil의 의미와 겹치지 않고 가치 부족을 구별하는 것과 같은 목적으로 사용할 수 있다는 의미였습니다.

@rogpepp 이것은 무엇을 인쇄합니까?

// r is an io.Reader interface value holding a type that also implements io.Closer
var v io.ReadCloser | io.Reader = r
switch v.(type) {
case io.ReadCloser: fmt.Println("ReadCloser")
case io.Reader: fmt.Println("Reader")
}

나는 "리더"라고 가정 할 것입니다.

@jimmyfrasche 저는 ReadCloser 라고 가정합니다. 다른 인터페이스의 유형 스위치에서 얻을 수 있는 것과 동일합니다.

(또한 명시적 태그가 유형 전환에서 조회 오버헤드를 약간 절약할 수 있다고 가정하지만 인터페이스 유형만 포함하는 합계는 일반 인터페이스보다 더 많은 공간을 사용하지 않을 것으로 예상합니다.)

@bcmills 흥미로운 할당입니다. 고려하십시오: https://play.golang.org/p/PzmWCYex6R

@ianlancetaylor 좋은 지적입니다. 감사합니다. 내 "순진한 구현" 제안 자체가 너무 순진하다는 것을 암시하지만 돌아다니기가 어렵다고 생각 하지 않습니다. 합계 유형은 인터페이스 유형으로 취급되지만 실제로 유형 및 해당 메소드 세트에 대한 직접 포인터를 포함할 필요는 없습니다. 대신 적절한 경우 유형을 암시하는 정수 태그를 포함할 수 있습니다. 해당 태그는 유형 자체가 nil인 경우에도 0이 아닐 수 있습니다.

주어진:

 var x int | nil = nil

x의 런타임 값이 모두 0일 필요는 없습니다. x의 유형을 전환하거나 변환할 때
다른 인터페이스 유형으로 태그를 지정하는 경우 다음을 포함하는 작은 테이블을 통해 태그를 간접 지정할 수 있습니다.
실제 유형 포인터.

또 다른 가능성은 첫 번째 요소인 경우에만 nil 유형을 허용하는 것이지만,
다음과 같은 구성을 배제합니다.

var t nil | int
var u float64 | t

@jimmyfrasche 다른 인터페이스의 유형 스위치에서 얻는 것과 동일한 ReadCloser를 가정합니다.

예.

@bcmills 흥미로운 할당입니다. 고려하십시오: https://play.golang.org/p/PzmWCYex6R

나는 이것을 이해하지 못한다. "이 [...]가 ReadCloser를 인쇄하기 위해 유형 스위치에 유효해야 하는 이유"
모든 인터페이스 유형과 마찬가지로 합계 유형은 그 안에 있는 것의 구체적인 값만 저장합니다.

합계에 여러 인터페이스 유형이 있는 경우 런타임 표현은 인터페이스 값일 뿐입니다. 기본 값이 선언된 가능성 중 하나 이상을 구현해야 한다는 것을 알고 있기 때문입니다.

즉, I1과 I2가 모두 인터페이스 유형인 유형(I1 | I2)에 무언가를 할당할 때 입력한 값이 당시에 I1 또는 I2를 구현하는 것으로 알려졌는지 여부를 나중에 알 수 없습니다.

io.ReadCloser | io.Reader 스위치를 입력하거나 io.Reader에서 io.ReadCloser가 아니라고 주장할 때 합계 유형에 대한 할당이 인터페이스를 unboxes 및 reboxes하지 않는 한 확신할 수 없습니다.

io.Reader가 있는 경우 다른 방향으로 이동합니다. | io.ReadCloser 엄격하게 오른쪽에서 왼쪽으로 진행하기 때문에 io.ReadCloser를 허용하지 않거나 구현이 합계의 모든 인터페이스에서 "가장 일치하는" 인터페이스를 검색해야 하지만 잘 정의할 수 없습니다.

@rogpeppe 제안에서 구현의 최적화 가능성과 0 값의 미묘함을 무시하고 수동으로 제작된 인터페이스 유형(관련 메소드의 교차 포함)보다 합계 유형을 사용하는 주요 이점은 유형 검사기가 오류를 지적할 수 있다는 것입니다. 런타임이 아닌 컴파일 시간에. 두 번째 이점은 유형의 값이 더 구별되어 프로그램의 가독성/이해에 도움이 될 수 있다는 것입니다. 다른 큰 이점이 있습니까?

(나는 어떤 식으로든 제안을 줄이려고 하는 것이 아니라 직관을 바로 잡으려고 할 뿐입니다. 특히 추가 구문 및 의미 복잡성이 "합리적으로 작은" 경우 - 그것이 의미하는 바가 무엇이든 - 컴파일러를 사용하는 것의 이점을 확실히 볼 수 있습니다. 오류를 일찍 잡아냅니다.)

@griesemer 네, 맞습니다.

특히 채널이나 네트워크를 통해 메시지를 전달할 때 가능한 가능성을 정확히 표현하는 유형을 가질 수 있는 것이 가독성과 정확성에 도움이 된다고 생각합니다. 현재는 인터페이스 유형에 unexported 메소드를 포함하여 이를 시도하는 것이 일반적이지만 이것은 a) 임베딩으로 우회할 수 있고 b) unexported 메소드가 숨겨져 있기 때문에 가능한 유형을 모두 보기 어렵습니다.

@jimmyfrasche

io.ReadCloser | io.Reader 스위치를 입력하거나 io.Reader에서 io.ReadCloser가 아니라고 주장할 때 합계 유형에 대한 할당이 인터페이스를 unboxes 및 reboxes하지 않는 한 확신할 수 없습니다.

그런 유형이 있으면 항상 io.Reader(또는 nil, 모든 io.Reader도 nil일 수 있기 때문에)임을 알 수 있습니다. 두 가지 대안은 배타적이지 않습니다. 제안된 합계 유형은 "배타적 또는"가 아닌 "포함 또는"입니다.

io.Reader가 있는 경우 다른 방향으로 이동합니다. | io.ReadCloser 엄격하게 오른쪽에서 왼쪽으로 진행하기 때문에 io.ReadCloser를 허용하지 않거나 구현이 합계의 모든 인터페이스에서 "가장 일치하는" 인터페이스를 검색해야 하지만 잘 정의할 수 없습니다.

"다른 길로 가는 것"이 ​​해당 유형에 할당하는 것을 의미하는 경우 제안서는 다음과 같이 말합니다.

"합계 유형에 값을 할당할 때 값이 더 많은
가능한 유형 중 하나보다 더 많은 경우 첫 번째 유형이 선택됩니다."

이 경우 io.ReadCloser는 io.Reader와 io.ReadCloser 모두에 들어갈 수 있으므로 io.Reader를 선택하지만 실제로는 나중에 알 수 있는 방법이 없습니다. io.Reader 유형과 io.Reader 유형 사이에는 감지할 수 있는 차이가 없습니다. | io.ReadCloser는 io.Reader가 io.Reader를 구현하는 모든 인터페이스 유형도 보유할 수 있기 때문입니다. 그렇기 때문에 컴파일러가 이와 같은 유형을 거부하도록 하는 것이 좋은 생각이라고 생각합니다. 예를 들어, 인터페이스{}가 이미 모든 유형을 포함할 수 있으므로 인터페이스{}와 관련된 모든 합계 유형을 거부할 수 있으므로 추가 자격은 정보를 추가하지 않습니다.

@rogpepp 당신의 제안에 대해 제가 좋아하는 부분이 많이 있습니다. 왼쪽에서 오른쪽으로 할당 의미와 0 값은 가장 왼쪽 유형 규칙의 0 값이 매우 명확하고 간단합니다. 아주 가다.

내가 걱정하는 것은 인터페이스에 이미 boxed된 값을 sum 형식 변수에 할당하는 것입니다.

잠시 동안 이전 예제를 사용하여 RC가 io.ReadCloser에 할당할 수 있는 구조체라고 가정해 보겠습니다.

이렇게 하면

var v io.ReadCloser | io.Reader = RC{}

결과는 분명하고 분명합니다.

그러나 이렇게 하면

var r io.Reader = RC{}
var v io.ReadCloser | io.Reader = r

할 수 있는 유일한 합리적인 일은 v store r을 io.Reader로 사용하는 것입니다. io.ReadCloser. 다음과 같은 것이 필요합니다.

switch v := v.(type) {
case io.ReadCloser: useReadCloser(v)
case io.Reader:
  if rc, ok := v.(io.ReadCloser); ok {
    useReadCloser(rc)
  } else {
    useReader(v)
  }
}

이제 io.ReadCloser <: io.Reader라는 의미가 있습니다. 제안한 대로 이를 허용하지 않을 수 있지만 문제가 더 근본적이며 Go†에 대한 모든 합계 유형 제안에 적용될 수 있다고 생각합니다.

A(), B(), C() 메서드가 각각 있는 세 개의 인터페이스 A, B, C가 있고 세 가지 메서드가 모두 있는 ABC 구조체가 있다고 가정해 보겠습니다. A, B, C는 분리되어 있으므로 A | 나 | C와 그 순열은 모두 유효한 유형입니다. 그러나 여전히 다음과 같은 경우가 있습니다.

var c C = ABC{}
var v A | B | C = c

이를 재정렬하는 방법이 많이 있지만 인터페이스가 포함될 때 v가 무엇인지에 대한 의미 있는 보장을 얻지 못합니다. 합계를 언박싱한 후 순서가 중요한 경우 인터페이스를 언박싱해야 합니다.

아마도 어떤 summands도 인터페이스가 될 수 없다는 제한이 있어야 합니까?

내가 생각할 수 있는 유일한 다른 해결책은 인터페이스를 합계 유형 변수에 할당하는 것을 허용하지 않는 것입니다. 그러나 그것은 그 자체로 더 심각한 방식으로 보입니다.

† 모호성을 없애기 위해 합계의 유형에 대한 유형 생성자를 포함하지 않습니다(Haskell에서 Maybe 유형의 값을 생성하기 위해 Just v라고 말해야 하는 경우와 같이). 하지만 저는 이에 대해 전혀 찬성하지 않습니다.

@jimmyfrasche 주문된 언박싱의 사용 사례가 실제로 중요합니까? 그것은 나에게 명확하지, 그리고 것이 중요 사건에 대한 명시적인 상자 구조체로 해결할 쉽게 :

type ReadCloser struct {  io.ReadCloser }
type Reader struct { io.Reader }

var v ReadCloser | Reader = Reader{r}

@bcmills 결과가 명확하지 않고 많으며 인터페이스가 포함될 때 합계 유형으로 원하는 모든 보장이 증발한다는 것을 의미합니다. 온갖 미묘한 버그와 오해를 불러일으키는 것을 볼 수 있습니다.

당신이 제공하는 명시적인 상자 구조 예제는 합계 유형에서 인터페이스를 허용하지 않아도 합계 유형의 능력을 전혀 제한하지 않는다는 것을 보여줍니다. 각주에서 언급한 명확성을 위해 유형 생성자를 효과적으로 생성하고 있습니다. 분명히 약간 성가시고 추가 단계이지만 간단하고 언어 구성이 가능한 한 직교하도록 하는 Go의 철학과 매우 일치합니다.

총액형으로 원하는 모든 보장

그것은 당신이 기대하는 보장에 달려 있습니다. 나는 당신이 합계 유형을 기대하고 있다고 생각합니다.
엄격하게 태그가 지정된 값이므로 A|B|C 유형이 주어지면 static이 무엇인지 정확히 알 수 있습니다.
할당한 유형입니다. 나는 그것을 콘크리트의 단일 값에 대한 유형 제한으로 본다.
유형 - 제한은 값이 A, B 및 C 중 적어도 하나와 유형 호환된다는 것입니다.
결국 값이 있는 인터페이스일 뿐입니다.

즉, 할당 호환이 가능하기 때문에 합계 유형에 값을 할당할 수 있는 경우
sum 유형의 멤버 중 하나가 있는 경우 해당 멤버 중 어느 멤버가
"chosen" - 값 자체를 기록합니다. io.Reader를 할당할 때와 동일
인터페이스{}에 대해 정적 io.Reader 유형을 잃고 값 자체만 갖게 됩니다.
io.Reader와 호환되지만 발생하는 다른 인터페이스 유형과도 호환됩니다.
구현.

귀하의 예에서 :

var c C = ABC{}
var v A | B | C = c

A, B 및 C 중 하나에 대한 v의 유형 어설션은 성공합니다. 그것은 나에게 합리적으로 보인다.

@rogpepp 그 의미론은 내가 상상했던 것보다 더 의미가 있습니다. 나는 여전히 인터페이스와 합계가 잘 섞이는지 확신하지 못하지만 더 이상 그렇지 않다고 확신하지 않습니다. 진전!

type U I | *T 있고 I 는 인터페이스 유형이고 *T 는 I 를 구현하는 유형입니다.

주어진

var i I = new(T)
var u U = i

u 의 동적 유형은 *T 이고,

var u U = new(T)

해당 *T 에 유형 어설션이 있는 I 로 액세스할 수 있습니다. 그 맞습니까?

이는 유효한 인터페이스 값에서 합계로의 할당이 합계에서 첫 번째 일치 유형을 검색해야 함을 의미합니다.

또한 var v uint8 | int32 | int64 = i 와 같은 것과는 다소 다를 수 있습니다. i 가 int64 경우에도 세 가지 유형 i 중 어느 것이든 항상 사용한다고 생각합니다. int64 uint8 들어갈 수 있는

진전!

야!

유형 어설션을 사용하여 해당 *T에 I로 액세스할 수 있습니다. 그 맞습니까?

예.

이는 유효한 인터페이스 값에서 합계로의 할당이 합계에서 첫 번째 일치 유형을 검색해야 함을 의미합니다.

예, 제안에서 말했듯이 (물론 컴파일러는 어느 것을 선택해야 하는지 정적으로 알고 있으므로 런타임에 검색하지 않습니다.)

또한 var v uint8 | int32 | int64 = i는 i가 uint8에 들어갈 수 있는 int64인 경우에도 세 가지 유형 i 중 어느 것이든 항상 사용할 것이라고 상상합니다.

예, 왜냐하면 i가 상수가 아니면 해당 대안 중 하나에만 할당할 수 있기 때문입니다.

예, 왜냐하면 i가 상수가 아니면 해당 대안 중 하나에만 할당할 수 있기 때문입니다.

명명되지 않은 유형을 명명된 유형에 할당할 수 있는 규칙 때문에 사실이 아닙니다. 그래도 큰 차이는 없는 것 같아요. 규칙은 동일하게 유지됩니다.

따라서 내 마지막 게시물의 I | *T 유형은 I 유형과 사실상 동일하고 io.ReadCloser | io.Reader 는 사실상 io.Reader 와 동일한 유형입니까?

좋아요. 두 유형 모두 한 유형이 다른 유형에 의해 구현되는 인터페이스인 경우 컴파일러가 합계 유형을 거부한다는 내가 제안한 규칙에 의해 다루어질 것입니다. 동일하거나 유사한 규칙은 int|int 와 같은 중복 유형이 있는 합계 유형을 다룰 수 있습니다.

한 가지 생각: int|byte 이 byte|int 와 같지 않다는 것이 직관적이지 않을 수 있지만 실제로는 괜찮을 것입니다.

이는 유효한 인터페이스 값에서 합계로의 할당이 합계에서 첫 번째 일치 유형을 검색해야 함을 의미합니다.

예, 제안에서 말했듯이 (물론 컴파일러는 어느 것을 선택해야 하는지 정적으로 알고 있으므로 런타임에 검색하지 않습니다.)

나는 이것을 따르지 않는다. 내가 읽는 방식(의도한 내용과 다를 수 있음)은 I와 T-구현-I의 결합 U를 처리하는 데 최소한 두 가지 방법이 있습니다.

1a) U u = t 할당 시 태그는 T로 설정됩니다. 태그가 T이기 때문에 나중에 선택하면 T가 됩니다.
1b) U u = i 할당 시(i는 실제로 T임) 태그가 I로 설정됩니다. 나중에 선택하면 태그가 I이기 때문에 T가 표시 되지만 두 번째 검사(T가 I 및 T를 구현하기 때문에 수행됨) U)의 구성원입니다. T를 발견합니다.

2a) 1a처럼
2b) U u = i 할당 시(i는 실제로 T임) 생성된 코드는 값(i)을 확인하여 T가 I를 구현하고 T도 U의 구성원이기 때문에 실제로 T인지 확인합니다. 즉, 태그가 T로 설정됩니다. 나중에 선택하면 직접 T가 됩니다.

T, V, W가 모두 I 및 U = *T | *V | *W | I 구현하는 경우 U u = i 할당에는 3가지 유형 테스트가 필요합니다.

인터페이스와 포인터는 공용체 유형의 원래 사용 사례가 아니었습니다. 그렇죠?

"멋진" 구현이 약간의 비트 뱅잉을 수행하는 특정 종류의 해커를 상상할 수 있습니다. 예를 들어 모든 참조 대상이 4바이트로 정렬되는 4개 이하의 포인터 유형의 조합이 있는 경우 태그를 하위 2에 저장합니다. 값의 비트. 이것은 차례로 Union 구성원의 주소를 가져오는 것이 좋지 않음을 의미합니다(어쨌든 해당 주소는 태그를 조정하지 않고 "이전" 유형을 복원하는 데 사용할 수 있기 때문에 그렇지 않습니다).

또는 50비트 주소 공간이 있고 NaN에 대해 약간의 자유를 갖고자 하는 경우 정수, 포인터 및 두 배를 모두 64비트 합집합으로 만들 수 있으며 약간의 비트 조정 비용이 발생할 수 있습니다.

두 하위 제안은 모두 총체적이며, 둘 다 소수의(?) 광신적인 지지자가 있을 것이라고 확신합니다.

이것은 차례로 노조원의 주소를 취하는 것이 좋지 않다는 것을 의미합니다.

옳은. 하지만 어쨌든 형식 주장의 결과가 오늘날 처리될 수 있다고 생각하지 않습니다. 그렇죠?

U u = i(i는 실제로 T임)의 할당에서 태그는 I로 설정됩니다.

이것이 핵심이라고 생각합니다 . 태그 I이 없습니다.

잠시 런타임 표현을 무시하고 합계 유형을 인터페이스로 고려하십시오. 모든 인터페이스와 마찬가지로 동적 유형(저장된 유형)이 있습니다. 당신이 참조하는 "태그"는 정확히 그 동적 유형입니다.

제안의 마지막 단락에서 암시하려고 했던 것처럼 런타임 유형에 대한 포인터를 사용하는 것보다 더 효율적인 방법으로 유형 태그를 저장하는 방법이 있을 수 있지만 결국에는 항상 동적 생성될 때 "선택된" 대안이 아닌 합계 유형 값의 유형입니다.

인터페이스와 포인터는 공용체 유형의 원래 사용 사례가 아니었습니다. 그렇죠?

그렇지는 않았지만 제 생각에는 다른 언어 기능과 관련하여 모든 제안이 가능한 한 직교해야 합니다.

@dr2chase 지금까지 내가 이해한 것은 sum 유형이 정의에 인터페이스 유형을 포함하는 경우 런타임에 구현이 인터페이스(메서드 세트의 교차 포함)와 동일하지만 허용 가능한 유형에 대한 컴파일 시간 불변성은 여전히 시행.

sum 유형이 구체적인 유형만 포함하고 C 스타일의 판별 합집합처럼 구현된 경우에도 sum 유형의 값을 처리할 수 없습니다. 주소. 그러나 합계 입력 값 자체의 주소를 사용할 수 있습니다.

합계 유형이 이런 식으로 동작하는 것이 바람직합니까? 우리는 선택된/어설션된 유형이 값이 공용체에 할당될 때 프로그래머가 말하거나 암시한 것과 동일하다고 쉽게 선언할 수 있습니다. 그렇지 않으면 우리는 int8 대 int16 대 int32 등과 관련하여 흥미로운 장소로 이끌릴 수 있습니다. 또는 예를 들어 int8 | uint8 .

합계 유형이 이런 식으로 동작하는 것이 바람직합니까?

그것은 판단의 문제입니다. 우리는 이미 정적 및 동적 유형의 값인 인터페이스 개념을 가지고 있기 때문에 그렇게 생각합니다. 제안된 합계 유형은 경우에 따라 인터페이스 유형을 지정하는 보다 정확한 방법을 제공합니다. 또한 sum 유형이 다른 유형에 제한 없이 작동할 수 있음을 의미합니다. 그렇게 하지 않으면 인터페이스 유형을 제외해야 하므로 기능이 완전히 직교하지 않습니다.

그렇지 않으면 int8 대 int16 대 int32 등과 관련하여 흥미로운 장소로 인도될 수 있습니다. 또는, 예를 들어 int8 | uint8.

여기에서 당신의 관심사는 무엇입니까?

함수 유형을 맵의 키 유형으로 사용할 수 없습니다. 나는 그것이 동등하다고 말하는 것이 아니라 다른 유형의 유형을 제한하는 유형에 대한 선례가 있다는 것입니다. 아직 판매되지 않은 인터페이스를 허용하도록 열려 있습니다.

다른 방법으로는 할 수 없는 인터페이스를 포함하는 합계 유형으로 어떤 종류의 프로그램을 작성할 수 있습니까?

대안.

공용체 유형은 0개 이상의 유형을 나열하는 유형입니다.

union {
  T0
  T1
  //...
  Tn
}

Union에 나열된 모든 유형(T0, T1, ..., Tn)은 서로 달라야 하며 인터페이스 유형이 될 수 없습니다.

메소드는 일반적인 규칙에 따라 정의된(명명된) 공용체 유형에 선언될 수 있습니다. 나열된 유형에서 승격된 메소드가 없습니다.

공용체 유형에 대한 임베딩이 없습니다. 하나의 공용체 유형을 다른 유형에 나열하는 것은 다른 유효한 유형을 나열하는 것과 같습니다. 그러나 type S struct { S } 가 유효하지 않은 것과 같은 이유로 공용체는 자체 유형을 재귀적으로 나열할 수 없습니다.

공용체는 구조체에 포함될 수 있습니다.

공용체 유형의 값은 나열된 유형 중 하나로 제한되는 동적 유형과 동적 유형의 값(저장된 값이라고 함)입니다. 나열된 유형 중 정확히 하나가 항상 동적 유형입니다.

빈 합집합의 0 값은 고유합니다. 비어 있지 않은 공용체의 0 값은 공용체에 나열된 첫 번째 유형의 0 값입니다.

U 유니온 유형에 대한 값은 0 값에 대해 U{} 를 사용하여 생성할 수 있습니다. U 에 하나 이상의 유형이 있고 v 가 나열된 유형 중 하나의 값인 경우 T , U{v} 는 v 저장하는 공용체 값을 생성합니다. T . v 가 U 나열되지 않은 유형이고 나열된 유형 중 둘 이상에 할당될 수 있는 경우 명확성을 위해 명시적 변환이 필요합니다.

조합의 값이 입력 U 다른 조합 형태로 변환 할 수 V 과 V(U{}) 의 타입 세트 IFF U 의 서브 세트 V 의 유형 집합입니다. 즉, 순서를 무시한다 U 등 모두 같은 유형이 있어야합니다 V 수행을하고, U 하지에있는 유형 가질 수 없습니다 V 있지만 V 에는 U 없는 유형이 있을 수 있습니다.

공용체 유형 간의 할당 가능성은 공용체 유형 중 최대 하나가 정의(이름 지정)되어 있는 한 변환 가능성으로 정의됩니다.

통합 유형 U 의 나열된 유형 중 하나인 T 값은 통합 유형 U 의 변수에 할당될 수 있습니다. 그러면 동적 유형이 T 되고 값이 저장됩니다. 할당 호환 값은 위와 같이 작동합니다.

나열된 모든 유형이 등호 연산자를 지원하는 경우:

• 같음 연산자는 동일한 공용체 유형의 두 값에 사용할 수 있습니다. 통합 유형의 두 값은 동적 유형이 다른 경우 결코 같지 않습니다.
• 해당 공용체의 값은 나열된 유형의 값과 비교할 수 있습니다. 공용체의 동적 유형이 다른 피연산자의 유형이 아닌 경우 저장된 값에 관계없이 == 는 false이고 != 는 true입니다. 할당 호환 값은 위와 같이 작동합니다.
• 유니온을 맵 키로 사용할 수 있습니다.

공용체 유형의 값에는 다른 연산자가 지원되지 않습니다.

주장된 유형이 동적 유형인 경우 나열된 유형 중 하나에 대한 통합 유형에 대한 유형 주장이 유지됩니다.

인터페이스 유형의 공용체 유형에 대한 유형 어설션은 동적 유형이 해당 인터페이스를 구현하는 경우 유지됩니다. (특히 나열된 모든 유형이 이 인터페이스를 구현하는 경우 어설션이 항상 유지됨).

유형 스위치는 나열된 모든 유형을 포함하여 완전하거나 기본 대소문자를 포함해야 합니다.

유형 어설션 및 유형 스위치는 저장된 값의 복사본을 반환합니다.

패키지 리플렉트는 반영된 공용체 값의 동적 유형 및 저장 값을 가져오는 방법과 반사된 공용체 유형의 나열된 유형을 가져오는 방법이 필요합니다.

노트:

union{...} 구문은 이 스레드의 합계 유형 제안과 ​​구별하기 위해, 주로 Go 문법에서 nice 속성을 유지하기 위해 부분적으로 선택되었으며, 부수적으로 이것이 구별된 공용체임을 강조하기 위해 선택되었습니다. 결과적으로 이것은 union{} 및 union{ int } 와 같은 다소 이상한 공용체를 허용합니다. 첫 번째는 많은 의미에서 struct{} (정의에 따라 다른 유형)와 동일하므로 다른 빈 유형을 추가하는 것 외에는 언어에 추가하지 않습니다. 두 번째가 더 유용할 수 있습니다. 예를 들어, type Id union { int } 는 통합 버전이 idValue.int 를 지정하지 않고도 직접 할당을 허용하여 내장 유형처럼 보이게 한다는 점을 제외하면 type Id struct { int } 와 매우 유사합니다.

할당 호환 유형을 처리할 때 필요한 명확화 변환은 약간 가혹하지만 다운스트림 코드가 준비되지 않은 모호성을 도입하도록 공용체가 업데이트되면 오류를 포착합니다.

임베딩이 없는 것은 공용체에 메소드를 허용하고 유형 스위치에서 철저한 일치를 요구하는 결과입니다.

나열된 유형의 메소드의 유효한 교집합을 취하는 대신 공용체 자체에 메소드를 허용하면 실수로 원치 않는 메소드를 얻는 것을 방지할 수 있습니다. 저장된 값을 공통 인터페이스에 어설션하는 형식은 승격이 필요할 때 간단하고 명시적인 래퍼 메서드를 허용합니다. 예를 들어, 통합 유형 U 나열된 모든 유형이 fmt.Stringer 구현합니다.

func (u U) String() string {
  return u.(fmt.Stringer).String()
}

연결된 reddit 스레드에서 rsc는 다음과 같이 말했습니다.

sum { X;의 0 값은 이상할 것입니다. Y }는 sum { Y; NS }. 총액이 일반적으로 작동하는 방식이 아닙니다.

이것은 실제로 어떤 제안에도 적용되기 때문에 이것에 대해 생각해 왔습니다.

버그가 아니라 기능입니다.

고려하다

type (
  Undefined = struct{}
  UndefinedOrInt union { Undefined; int }
)

대

type (
  Illegal = struct{}
  IntOrIllegal union { int; Illegal }
)

UndefinedOrInt 는 기본적으로 아직 정의되지 않았으나 정의되면 int 값이 됩니다. 이것은 *int 와 유사합니다. 이것은 합계 유형(1 + int)이 Go에서 지금 표현되어야 하는 방식이고 0 값도 유사합니다.

반면에 IntOrIllegal 는 기본적으로 int 0이라고 말하지만 어느 시점에서 불법으로 표시될 수 있습니다. 이것은 여전히 *int 유사하지만 0 값은 기본값을 new(int) 하는 것과 같이 의도를 더 잘 표현합니다.

구조체의 bool 필드를 음수로 표현하여 기본값으로 원하는 값이 0이 되도록 하는 것과 같습니다.

합계의 0 값은 모두 그 자체로 유용하고 의미가 있으며 프로그래머는 상황에 가장 적합한 것을 선택할 수 있습니다.

합계가 요일 열거형(각 요일 정의된 struct{} )인 경우 먼저 나열되는 날짜가 주의 첫 번째 요일이며 iota 스타일 열거형의 경우에도 동일합니다.

또한 합계 유형 또는 0 값의 개념이 있는 판별/태그 결합이 있는 언어를 알지 못합니다. C가 가장 가깝지만 0 값은 초기화되지 않은 메모리입니다. Java의 기본값은 null이지만 모든 것이 참조이기 때문입니다. 내가 아는 다른 모든 언어에는 summands에 대한 필수 유형 생성자가 있으므로 실제로 0 값의 개념이 없습니다. 그런 언어가 있습니까? 그것은 무엇을합니까?

"합"과 "합집합"의 수학적 개념과의 차이점이 문제라면 우리는 항상 그것들을 다른 것으로 부를 수 있습니다(예: "변형").

이름: Union은 C/C++ 순수주의자를 혼동합니다. Variant는 주로 COBRA 및 COM 프로그래머에게 친숙하며, 여기서 기능적 언어는 구별된 결합을 선호하는 것으로 보입니다. 세트는 동사와 명사입니다. 나는 _pic_ 키워드를 좋아한다. 림보는 _pick_를 사용했습니다. 짧고 유한한 유형 집합에서 선택하려는 유형의 의도를 설명합니다.

이름/구문은 크게 관련이 없습니다. 고르시면 됩니다.

이 스레드의 제안 중 하나는 집합 이론 정의에 맞습니다.

0 값에 대해 특별한 첫 번째 유형은 유형 이론적인 합이 통근하기 때문에 관련이 없으므로 순서는 관련이 없습니다(A + B = B + A). 내 제안은 그 속성을 유지하지만 제품 유형도 이론상 통근하고 대부분의 언어(Go 포함)에서 실제로 다른 것으로 간주되므로 아마도 필수는 아닙니다.

@jimmyfrasche

저는 개인적으로 인터페이스를 '선택' 멤버로 허용하지 않는 것이 매우 큰 단점이라고 생각합니다. 첫째, '선택' 유형의 훌륭한 사용 사례 중 하나를 완전히 무효화합니다. 오류가 구성원 중 하나가 되는 것입니다. 또는 사용자가 미리 StringReader를 사용하도록 하지 않으려면 io.Reader 또는 문자열이 있는 선택 유형을 처리하려고 합니다. 그러나 대체로 인터페이스는 또 다른 유형이며 '선택' 멤버에 대한 유형 제한이 없어야 한다고 생각합니다. 이 경우 선택 유형에 2개의 인터페이스 멤버가 있고 하나는 다른 하나에 의해 완전히 둘러싸여 있는 경우 이전에 언급한 대로 컴파일 시간 오류여야 합니다.

귀하의 반대 제안에서 내가 좋아하는 것은 선택 유형에서 메서드를 정의할 수 있다는 사실입니다. 어떤 메서드가 모든 구성원에 속할 수 있는 경우가 많지 않을 것이라고 생각하기 때문에(어쨌든 이에 대한 인터페이스가 있음) 멤버 메서드의 단면을 제공해야 한다고 생각하지 않습니다. 그리고 철저한 스위치 + 기본 케이스는 아주 좋은 생각입니다.

@rogpeppe @jimmyfrasche 당신의 제안에서 볼 수 없는 것이 우리가 이것을 해야 하는 이유입니다. 새로운 종류의 유형을 추가하는 데는 분명한 단점이 있습니다. 바둑에 기대는 모든 사람이 배워야 하는 새로운 개념입니다. 보상 이점은 무엇입니까? 특히, 새로운 유형의 유형은 인터페이스 유형에서 얻을 수 없는 무엇을 제공합니까?

@ianlancetaylor Robert는 여기에 잘 요약되어 있습니다: https://github.com/golang/go/issues/19412#issuecomment -288608089

@ianlancetaylor
하루가 끝나면 코드를 더 쉽게 읽을 수 있으며 이것이 Go의 주요 지시문입니다. json.Token을 고려해 보세요. 현재 인터페이스로 정의되어 있지만{} 문서에서는 실제로 특정 유형의 유형 중 하나만 될 수 있다고 명시하고 있습니다. 반면에 다음과 같이 쓰여지면

type Token Delim | bool | float64 | Number | string | nil

사용자는 모든 가능성을 즉시 볼 수 있으며 도구는 자동으로 완전한 스위치를 생성할 수 있습니다. 게다가, 컴파일러는 당신이 거기에 예상치 못한 유형을 집어넣는 것을 방지할 것입니다.

하루가 끝나면 코드를 더 쉽게 읽을 수 있으며 이것이 Go의 주요 지시문입니다.

더 많은 기능은 코드를 이해하기 위해 더 많이 알아야 한다는 것을 의미합니다. 언어에 대한 평균 수준의 지식을 가진 사람의 경우 가독성은 반드시 [새로 추가된] 기능의 수에 반비례합니다.

@cznic

더 많은 기능은 코드를 이해하기 위해 더 많이 알아야 한다는 것을 의미합니다.

항상은 아닙니다. "언어에 대해 더 많이 아는 것"을 "코드에서 잘못되거나 일관되지 않게 문서화된 불변량에 대해 더 많이 아는 것"으로 대체할 수 있다면, 그것은 여전히 ​​순익이 될 수 있습니다. (즉, 글로벌 지식이 로컬 지식의 필요성을 대체할 수 있습니다.)

더 나은 컴파일 시간 유형 검사가 실제로 유일한 이점이라면 vet가 검사한 주석을 도입하여 언어를 변경하지 않고도 매우 유사한 이점을 얻을 수 있습니다. 같은 것

//vet:types Delim | bool | float64 | Number | string | nil
type Token interface{}

현재 우리는 어떤 종류의 수의사 의견도 가지고 있지 않으므로 이것이 완전히 진지한 제안은 아닙니다. 그러나 저는 기본 아이디어에 대해 진지합니다. 우리가 얻는 유일한 이점이 정적 분석 도구로 완전히 할 수 있는 것이라면 적절한 언어에 복잡한 새 개념을 추가할 가치가 있습니까?

cmd/vet에 의해 수행된 테스트의 대부분, 아마도 모두는 별도의 정적 분석 도구가 아닌 컴파일러에 의해 검사될 수 있다는 의미에서 언어에 추가될 수 있습니다. 그러나 여러 가지 이유로 수의사를 컴파일러에서 분리하는 것이 유용하다는 것을 알았습니다. 이 개념이 수의사 쪽이 아니라 언어 쪽인 이유는 무엇입니까?

@ianlancetaylor 다시 확인 댓글: https://github.com/BurntSushi/go-sumtype

@ianlancetaylor 변경이 정당한지 여부에 대해서는 적극적으로 무시하거나 뒤로

더 나은 컴파일 시간 유형 검사가 실제로 유일한 이점이라면 vet가 검사한 주석을 도입하여 언어를 변경하지 않고도 매우 유사한 이점을 얻을 수 있습니다.

이것은 새로운 것을 배워야 한다는 비판에 여전히 취약합니다. 코드를 디버그/이해/사용하기 위한 마술 수의사 의견에 대해 배워야 한다면 Go 언어 예산에 할당하든 기술적으로 Go 언어가 아닌 예산에 할당하든 상관없이 정신과세입니다. 어쨌든 매직 댓글은 언어를 배웠다고 생각했을 때 배워야 한다는 것을 몰랐기 때문에 비용이 더 많이 듭니다.

@cznic
나는 동의하지 않는다. 현재의 가정으로는 채널이 무엇인지 또는 기능이 무엇인지 이해하게 될 것이라고 확신할 수 없습니다. 그러나 이러한 것들은 언어에 존재합니다. 그리고 새로운 기능이 자동으로 언어를 어렵게 만든다는 의미는 아닙니다. 이 경우, 블랙박스 인터페이스 유형을 사용하는 것과는 반대로 독자에게 유형이 무엇인지 즉각적으로 명확하게 해주기 때문에 실제로 이해하기가 더 쉬울 것이라고 주장합니다.{}

@ianlancetaylor
개인적으로 이 기능은 코드를 읽기 쉽고 추론하기 쉽게 만드는 것과 더 관련이 있다고 생각합니다. 컴파일 시간 안전성은 매우 좋은 기능이지만 주요 기능은 아닙니다. 유형 서명을 즉시 더 명확하게 만들 뿐만 아니라 후속 사용법도 이해하기 쉽고 작성하기도 더 쉽습니다. 사람들은 예상하지 못한 유형을 받으면 더 이상 패닉에 의존할 필요가 없습니다. 이는 표준 라이브러리에서도 현재 동작이므로 미지의 것에 방해받지 않고 사용법에 대해 더 쉽게 생각할 수 있습니다. . 그리고 이를 위해 주석 및 기타 도구(자사 제품일지라도)에 의존하는 것은 좋은 생각이 아니라고 생각합니다. 더 깔끔한 구문이 그러한 주석보다 읽기 쉽기 때문입니다. 그리고 댓글은 구조가 없고 엉망이 되기 쉽습니다.

@ianlancetaylor

이 개념이 수의사 쪽이 아니라 언어 쪽인 이유는 무엇입니까?

동일한 질문을 튜링 완전 코어 외부의 모든 기능에 적용할 수 있으며 틀림없이 Go가 "튜링 타핏"이 되는 것을 원하지 않습니다. 반면에, 우리는 일반적인 "확장"구문으로 떨어져 실제 언어의 중요한 부분 집합을 쑤셔 한 언어의 예를 가지고 않습니다. (예: Rust, C++ 및 GNU C의 "속성")

핵심 언어 대신 확장 또는 속성에 기능을 넣는 주된 이유는 새 기능을 인식하지 못하는 도구와의 호환성을 포함하여 구문 호환성을 유지하기 위해서입니다. ("도구와의 호환성"이 실제로 실제로 작동하는지 여부는 기능이 실제로 수행하는 작업에 크게 의존합니다.)

Go의 맥락에서 vet 에 기능을 넣는 주된 이유는 언어 자체에 적용할 경우 Go 1 호환성을 유지하지 않는 변경을 구현하기 위한 것 같습니다. 나는 그것을 여기에서 문제로 보지 않는다.

vet 에 기능을 넣지 않는 한 가지 이유는 컴파일 중에 전파해야 하는 경우입니다. 예를 들어 다음과 같이 작성합니다.

switch x := somepkg.SomeFunc().(type) {
…
}

패키지 경계를 넘어 합계에 없는 유형에 대해 적절한 경고를 받을 수 있습니까? vet 가 그렇게 깊은 이행적 분석을 할 수 있다는 것은 분명하지 않습니다. 그래서 아마도 그것이 핵심 언어로 가야 하는 이유일 것입니다.

@dr2chase 일반적으로 당신이 옳습니다만, 이 특정한 예에 대해서는 당신이 맞습니까? 코드는 매직 코멘트가 무엇을 의미하는지 몰라도 완전히 이해할 수 있습니다. 마법의 주석은 코드가 하는 일을 변경하지 않습니다. 수의사의 오류 메시지는 명확해야 합니다.

@bcmills

이 개념이 수의사 쪽이 아니라 언어 쪽인 이유는 무엇입니까?

튜링 완전 코어 외부의 모든 기능에 동일한 질문을 적용할 수 있습니다....

동의하지 않습니다. 논의 중인 기능이 컴파일된 코드에 영향을 미치는 경우 이에 대한 자동 인수가 있습니다. 이 경우 기능은 분명히 컴파일된 코드에 영향을 미치지 않습니다.

(예, 수의사는 가져온 패키지의 소스를 구문 분석할 수 있습니다.)

나는 수의사에 대한 나의 주장이 결정적이라고 주장하려는 것이 아닙니다. 그러나 모든 언어 변경은 부정적인 위치에서 시작됩니다. 간단한 언어는 매우 바람직하며 이와 같은 중요한 새 기능은 필연적으로 언어를 더 복잡하게 만듭니다. 언어 변경에 찬성하는 강력한 주장이 필요합니다. 그리고 내 관점에서 그러한 강력한 주장은 아직 나타나지 않았습니다. 결국, 우리는 이 문제에 대해 오랫동안 생각했고 FAQ(https://golang.org/doc/faq#variant_types)입니다.

@ianlancetaylor

이 경우 기능은 분명히 컴파일된 코드에 영향을 미치지 않습니다.

특정 세부 사항에 달려 있다고 생각합니까? 위에서 언급한 @jimmyfrasche (https://github.com/golang/go/issues/19412#issuecomment-289319916)가 확실히 하는 "합의 0값은 첫 번째 유형의 0값" 동작입니다.

@urandom 인터페이스와 공용체 유형이 명시적 유형 생성자 없이 혼합되지 않는 이유에 대한 긴 설명을 작성하고 있었지만 그렇게 할 수 있는 합리적인 방법이 있다는 것을 깨달았습니다.

내 반대 제안에 대한 빠르고 더러운 반대 제안. (명시적으로 언급되지 않은 것은 이전 제안과 동일합니다.) 한 제안이 다른 제안보다 더 나은지 확신할 수 없지만 이 제안은 인터페이스를 허용하고 더 명확합니다.

Union에는 이후 "태그 이름"이라고 하는 명시적인 "필드 이름"이 있습니다.

union { //or whatever
  None, invalid struct{} //None is zero value
  Good, Bad int
  Err error //okay because it's explicitly named
}

아직 임베딩이 없습니다. 태그 이름이 없는 유형을 갖는 것은 항상 오류입니다.

Union 값에는 동적 유형이 아닌 동적 태그가 있습니다.

리터럴 값 생성: U{v} 는 완전히 모호하지 않은 경우에만 유효하고, 그렇지 않으면 U{Tag: v} 여야 합니다.

변환 가능성 및 할당 호환성은 태그 이름도 고려합니다.

노동조합에 배정하는 것은 마술이 아닙니다. 항상 호환되는 공용체 값을 할당하는 것을 의미합니다. 저장된 값을 설정하려면 원하는 태그 이름을 명시적으로 사용해야 합니다. v.Good = 1 는 동적 태그를 Good으로 설정하고 저장된 값을 1로 설정합니다.

저장된 값에 액세스하는 것은 유형 어설션이 아닌 태그 어설션을 사용합니다.

g := v.[Tag] //may panic
g, ok := v.[Tag] //no panic but could return zero-value, false

v.Tag는 모호하기 때문에 rhs에 대한 오류입니다.

태그 스위치는 switch v.[type] 작성된 유형 스위치와 비슷하지만 대소문자가 공용체의 태그라는 점을 제외하고는 다릅니다.

유형 어설션은 동적 태그 유형과 관련하여 유지됩니다. 유형 스위치도 유사하게 작동합니다.

어떤 조합 유형의 값, b가 주어지면 동적 태그가 동일하고 저장된 값이 동일하면 a == b입니다.

저장된 값이 특정 값인지 확인하려면 태그 어설션이 필요합니다.

태그 이름을 내보내지 않은 경우 유니온을 정의하는 패키지에서만 태그 이름을 설정하고 액세스할 수 있습니다. 이것은 내보낸 태그와 내보내지 않은 태그가 혼합된 공용체의 태그 전환이 기본 케이스 없이 정의 패키지 외부에서 절대 완전할 수 없음을 의미합니다. 모든 태그가 내보내지지 않으면 블랙박스입니다.

리플렉션은 태그 이름도 처리해야 합니다.

e: 중첩된 공용체에 대한 설명. 주어진

type U union {
  A union {
    A1 T1
    A2 T2
  }
  B union {
    B1 T3
    B2 T4
  }
}
var u U

u의 값은 동적 태그 A이고 저장된 값은 동적 태그 A1과의 익명 합집합이며 저장된 값은 T1의 0 값입니다.

u.B.B2 = returnsSomeT3()

하나의 메모리 위치에 모두 저장되어 있으므로 중첩된 공용체 중 하나에서 다른 하나로 이동하더라도 u를 0 값에서 전환하는 데 필요한 전부입니다. 하지만

v := u.[A].[A2]

두 개의 공용체 값에 대한 태그 어설션과 여러 줄로 분할하지 않고는 2개의 값을 갖는 버전의 태그 어설션을 사용할 수 없기 때문에 패닉에 빠질 기회가 두 번 있습니다. 이 경우 중첩 태그 스위치가 더 깔끔합니다.

edit2: 유형 주장에 대한 설명.

주어진

type U union {
  Exported, unexported int
}
var u U

u.(int) 와 같은 형식 주장은 전적으로 합리적입니다. 정의 패키지 내에서는 항상 유지됩니다. 그러나 u 가 정의 패키지 외부에 있으면 동적 태그가 unexported 때 구현 세부 정보 누출을 방지하기 위해 u.(int) 패닉이 발생합니다. 인터페이스 유형에 대한 주장과 유사합니다.

@ianlancetaylor 다음은 이 기능이 어떻게 도움이 되는지에 대한 몇 가지 예입니다.

1. 일부 패키지(예 go/ast )의 핵심에는 하나 이상의 큰 금액 유형이 있습니다. 이러한 유형을 이해하지 않고는 이러한 패키지를 탐색하기가 어렵습니다. 더 혼란스럽게도 sum 유형은 메서드가 있는 인터페이스(예: go/ast.Node )로 표시되고 다른 경우에는 빈 인터페이스(예: go/ast.Object.Decl )로 표시됩니다.

2. protobuf oneof 기능을 Go로 컴파일하면 oneof 필드에 대한 할당이 유형이 안전한지 확인하는 것이 유일한 목적인 내보내기되지 않은 인터페이스 유형이 생성됩니다. 차례로 oneof의 각 분기에 대한 유형을 생성해야 합니다. 최종 제품에 대한 유형 리터럴은 읽고 쓰기가 어렵습니다.

   &sppb.Mutation{
              Operation: &sppb.Mutation_Delete_{
                  Delete: &sppb.Mutation_Delete{
                      Table:  m.table,
                      KeySet: keySetProto,
                  },
              },
   }
   

   일부(전부는 아니지만) 중 하나는 합계 유형으로 표현될 수 있습니다.

3. 때때로 "아마도" 유형이 정확히 필요한 것입니다. 예를 들어 많은 Google API 리소스 업데이트 작업에서는 리소스 필드의 하위 집합을 변경할 수 있습니다. Go에서 이것을 표현하는 자연스러운 방법 중 하나는 각 필드에 대해 "아마도" 유형이 있는 리소스 구조체의 변형을 사용하는 것입니다. 예를 들어 Google Cloud Storage ObjectAttrs 리소스는 다음과 같습니다.

   type ObjectAttrs struct {
      ContentType string
      ...
   }
   

   부분 업데이트를 지원하기 위해 패키지는 다음을 정의합니다.

   type ObjectAttrsToUpdate struct {
      ContentType optional.String
      ...
   }
   

   여기서 optional.String 는 다음과 같습니다( godoc ).

   // String is either a string or nil.
   type String interface{}
   

   이것은 설명하기 어렵고 유형이 안전하지 않지만 실제로는 편리합니다. 왜냐하면 ObjectAttrsToUpdate 리터럴은 존재를 인코딩하는 동안 ObjectAttrs 리터럴과 똑같이 보이기 때문입니다. 나는 우리가 쓸 수 있었으면 좋겠다.

   type ObjectAttrsToUpdate struct {
      ContentType string | nil
      ...
   }
   

4. 많은 함수는 xor 의미 체계와 함께 (T, error) 를 반환합니다(T는 의미가 있습니다. 오류가 nil인 경우). 반환 유형을 T | error 로 작성하면 의미를 명확히 하고 안전성을 높이며 더 많은 구성 기회를 제공할 수 있습니다. (호환성 이유로) 함수의 반환 값을 변경할 수 없거나 변경하고 싶지 않더라도 sum 유형은 채널에 쓰는 것과 같이 해당 값을 전달하는 데 여전히 유용합니다.

go vet 주석은 이러한 경우에 많은 도움이 될 것이지만 익명 유형이 의미가 있는 경우에는 그렇지 않습니다. 합계 유형이 있다면 많이 볼 수 있을 것입니다.

chan *Response | error

이 유형은 여러 번 쓸 수 있을 만큼 짧습니다.

@ianlancetaylor 이것은 아마도 좋은 시작은 아니지만 Go1에서 이미 할 수 있는 공용체로 할 수 있는 모든 것이 있습니다. 왜냐하면 저는 이러한 주장을 인정하고 요약하는 것이 공정하다고 생각했기 때문입니다.

(아래 구문/의미에 대한 태그와 함께 내 최신 제안을 사용합니다. 또한 방출된 코드가 기본적으로 스레드에서 훨씬 이전에 게시한 C 코드와 같다고 가정합니다.)

합계 유형은 iota, 포인터 및 인터페이스와 겹칩니다.

이오타

이 두 가지 유형은 대략 동일합니다.

type Stoplight union {
  Green, Yellow, Red struct {}
}

func (s Stoplight) String() string {
  switch s.[type] {
  case Green: return "green" //etc
  }
}

그리고

type Stoplight int

const (
  Green Stoplight = iota
  Yellow
  Red
)

func (s Stoplight) String() string {
  switch s {
  case Green: return "green" //etc
  }
}

컴파일러는 둘 다에 대해 정확히 동일한 코드를 내보냅니다.

Union 버전에서는 int가 숨겨진 구현 세부 정보로 바뀝니다. iota 버전을 사용하면 노란색/빨간색이 무엇인지 묻거나 Stoplight 값을 -42로 설정할 수 있지만 통합 버전에서는 그렇지 않습니다. 이는 모두 최적화 중에 고려할 수 있는 컴파일러 오류 및 불변량입니다. 마찬가지로 노란색 표시등을 설명하지 못하는 (값) 스위치를 작성할 수 있지만 태그 스위치를 사용하면 이를 명시적으로 나타내기 위해 기본 케이스가 필요합니다.

물론, 공용체 유형으로는 할 수 없는 일을 iota로 할 수 있습니다.

포인터

이 두 가지 유형은 거의 동일합니다.

type MaybeInt64 union {
  None struct{}
  Int64 int64
}

그리고

type MaybeInt64 *int64

포인터 버전은 더 컴팩트합니다. 통합 버전은 동적 태그를 저장하기 위해 추가 비트(이는 단어 크기일 수 있음)가 필요하므로 값의 크기는 https://golang.org/pkg/database/sql/ 과 같을 수

Union 버전은 의도를 보다 명확하게 문서화합니다.

물론 유니온 유형으로는 할 수 없는 포인터로 할 수 있는 일이 있습니다.

인터페이스

이 두 가지 유형은 거의 동일합니다.

type AB union {
  A A
  B B
}

그리고

type AB interface {
  secret()
}
func (A) secret() {}
func (B) secret() {}

통합 버전은 임베딩으로 우회할 수 없습니다. A와 B는 공통의 메소드가 필요하지 않습니다. 실제로 기본 유형일 수도 있고 @urandom 게시된 json.Token 예제와 같이 완전히 분리된 메소드 세트를 가질 수도 있습니다.

AB 공용체 대 AB 인터페이스에 무엇을 넣을 수 있는지 보는 것은 정말 쉽습니다. 정의는 문서입니다(무엇이 무엇인지 알아내기 위해 go/ast 소스를 여러 번 읽어야 했습니다).

AB 공용체는 절대 nil이 될 수 없으며 구성 요소의 교차점 외부에 메서드를 제공할 수 있습니다(이는 구조체에 인터페이스를 포함하여 시뮬레이션할 수 있지만 구성은 더 섬세하고 오류가 발생하기 쉽습니다).

물론, 공용체 유형으로는 할 수 없는 인터페이스로 할 수 있는 일이 있습니다.

요약

어쩌면 그 겹침이 너무 겹칠 수도 있습니다.

각각의 경우 유니온 버전의 주요 이점은 실제로 더 엄격한 컴파일 시간 검사입니다. 할 수 있는 것보다 할 수 없는 것이 더 중요합니다. 더 강력한 불변으로 변환하는 컴파일러의 경우 코드를 최적화하는 데 사용할 수 있습니다. 다른 것으로 번역하는 프로그래머의 경우 컴파일러가 걱정하도록 할 수 있습니다. 컴파일러는 당신이 틀렸는지 알려줄 것입니다. 인터페이스 버전에는 최소한 중요한 문서 이점이 있습니다.

iota 및 포인터 예제의 투박한 버전은 "내보내지 않은 메서드와의 인터페이스" 전략을 사용하여 구성할 수 있습니다. 그러나 그 문제에 대해 map[string]interface{} 및 func 유형 및 메서드 값이 있는 (비어 있지 않은) 인터페이스로 구조체를 시뮬레이션할 수 있습니다. 더 어렵고 덜 안전하기 때문에 아무도 하지 않을 것입니다.

이러한 모든 기능은 언어에 무언가를 추가하지만 해당 기능이 없으면 해결될 수 있습니다(고통스럽게 그리고 항의 중에).

그래서 저는 바가 Go에서 근사화될 수 없는 프로그램을 보여주기 위한 것이 아니라, 결합 없이 Go에서 훨씬 더 쉽고 깔끔하게 작성된 프로그램을 보여주기 위한 것이라고 가정합니다. 그래서 보여줘야 할 것은 그것뿐이다.

@jimmyfrasche

통합 유형에 이름이 지정된 필드가 있어야 할 이유가 없습니다. 이름은 동일한 유형의 서로 다른 필드를 구별하려는 경우에만 유용합니다. 그러나 공용체에는 동일한 유형의 여러 필드가 있어서는 안 됩니다. 이는 의미가 없기 때문입니다. 따라서 이름을 갖는 것은 중복되며 혼란과 더 많은 타이핑으로 이어집니다.

본질적으로 유니온 유형은 다음과 같아야 합니다.

union {
    struct{}
    int
    err
}

유형 자체는 구조체에 포함된 유형이 식별자로 사용되는 방식과 매우 유사하게 공용체에 할당하는 데 사용할 수 있는 고유 식별자를 제공합니다.

그러나 명시적 할당이 작동하려면 구문에서 이러한 식을 허용하므로 명명되지 않은 형식을 멤버로 지정하여 공용체 형식을 만들 수 없습니다. 예: v.struct{} = struct{}

따라서 원시 구조체, 공용체 및 함수와 같은 유형은 공용체의 일부가 되고 할당 가능하게 되기 위해 미리 이름을 지정해야 합니다. 이를 염두에 두고 내부 공용체는 다른 멤버 유형일 뿐이므로 중첩 공용체는 특별한 것이 아닙니다.

이제 어떤 구문이 더 나은지 잘 모르겠습니다.

[union|sum|pick|oneof] {
    type1
    package1.type2
    ....
}

위의 내용은 좀 더 유사해 보이지만 그러한 유형에 대해서는 약간 장황합니다.

반면에 type1 | package1.type2 는 일반적인 go 유형처럼 보이지 않을 수 있지만 '|'를 사용하는 이점이 있습니다. OR로 주로 인식되는 기호입니다. 그리고 모호하지 않으면서 장황함을 줄입니다.

@urandom "태그 이름"이 없지만 인터페이스를 허용하는 경우 추가 검사를 통해 합계가 interface{} 로 축소됩니다. 한 가지를 넣을 수 있지만 여러 가지 방법으로 꺼낼 수 있기 때문에 합계 유형이 아닙니다. 태그 이름을 사용하면 합계 유형이 될 수 있고 모호함 없이 인터페이스를 유지할 수 있습니다.

하지만 태그 이름은 인터페이스 문제 그 이상을{}복구합니다. 그들은 유형을 훨씬 덜 마법처럼 만들고 구별하기 위해 많은 유형을 발명하지 않고도 모든 것을 영광스럽게 명시하게 만듭니다. 지적한 대로 명시적 할당 및 유형 리터럴을 사용할 수 있습니다.

하나의 유형에 둘 이상의 태그를 지정할 수 있다는 것이 기능입니다. 연속으로 얼마나 많은 성공 또는 실패가 발생했는지 측정하는 유형을 고려하십시오(1개의 성공은 N개의 실패를 취소하고 그 반대도 마찬가지).

type Counter union {
  Successes, Failures uint 
}

필요한 태그 이름 없이

type (
  Success uint
  Failures uint
  Counter Successes | Failures
)

대입과 같을 것이다 c = Successes(1) 대신 c.Successes = 1 . 당신은 많은 것을 얻지 못한다.

또 다른 예로는 로컬 또는 원격 오류를 나타내는 유형이 있습니다. 태그 이름을 사용하면 쉽게 모델링할 수 있습니다.

type Failure union {
  Local, Remote error
}

오류의 섭리는 실제 오류가 무엇이든 관계없이 태그 이름으로 지정할 수 있습니다. 태그 이름이 없으면 합계에서 직접 인터페이스를 허용하더라도 type Local { error } 하고 원격에서도 동일해야 합니다.

태그 이름은 유니온에서 로컬로 별칭이나 명명된 유형이 아닌 특수한 유형을 생성하는 것입니다. 동일한 유형을 가진 여러 "태그"를 갖는 것은 내 제안에 고유한 것이 아닙니다. 모든 기능 언어(내가 알고 있는)가 하는 일입니다.

내보낸 유형에 대해 내보내지 않은 태그를 만들거나 그 반대로 만드는 기능도 흥미로운 반전입니다.

또한 별도의 태그 및 유형 어설션을 사용하면 한 줄 래퍼를 사용하여 공유 메서드를 공용체로 승격할 수 있는 것과 같은 흥미로운 코드를 사용할 수 있습니다.

그것은 그것이 일으키는 것보다 더 많은 문제를 해결하고 모든 것이 훨씬 더 잘 어울리는 것처럼 보입니다. 솔직히 쓸 때는 확신이 없었지만, Go에 합을 통합하는 것과 관련된 모든 문제를 해결하는 유일한 방법은 이것이 점점 더 확실해지고 있습니다.

이를 좀 더 확장하기 위해 저에게 동기를 부여하는 예는 @rogpeppe io.Reader | io.ReadCloser 입니다. 태그 없이 인터페이스를 허용하는 것은 io.Reader 와 같은 유형입니다.

ReadCloser를 넣고 Reader로 꺼낼 수 있습니다. 당신은 A를 잃는다 | B는 합계 유형의 A 또는 B 속성을 의미합니다.

io.ReadCloser 를 io.Reader io.ReadCloser 로 처리하는 것에 대해 구체적이어야 하는 경우 @bcmills가 지적한 대로 type Reader struct { io.Reader } 등의 래퍼 구조체를 만들고 유형을 Reader | ReadCloser 해야 합니다.

결합되지 않은 메소드 세트가 있는 인터페이스로 합계를 제한하더라도 한 유형이 이러한 인터페이스 중 둘 이상을 구현할 수 있기 때문에 여전히 이 문제가 있습니다. 합계 유형의 명시성을 잃습니다. "A 또는 B"가 아닙니다. "A 또는 B 또는 때로는 원하는 대로"입니다.

설상가상으로 이러한 유형이 다른 패키지에서 가져온 것이라면 A가 B와 동일하게 취급되지 않도록 프로그램을 구성하는 데 매우 주의를 기울였다 하더라도 업데이트 후 갑자기 다르게 작동할 수 있습니다.

원래 나는 문제를 해결하기 위해 인터페이스를 허용하지 않는 것을 탐구했습니다. 아무도 그것에 만족하지 않았습니다! 하지만 a = b 와 같이 a, b의 종류에 따라 의미가 달라지는 문제도 해결하지 못했습니다. 저는 불편합니다. 또한 유형 할당 기능이 작동할 때 선택에서 어떤 유형이 선택되는지에 대한 많은 규칙이 있어야 했습니다. 그것은 많은 마법입니다.

태그를 추가하면 모두 사라집니다.

union { R io.Reader | RC io.ReadCloser } 하면 이 ReadCloser가 의미 있는 경우 독자로 간주되기를 원한다고 명시적으로 말할 수 있습니다. 래퍼 유형이 필요하지 않습니다. 정의에 내포되어 있습니다. 태그 유형에 관계없이 이는 하나의 태그이거나 다른 하나입니다.

단점은 다른 곳에서 io.Reader를 얻는 경우 chan 수신 또는 func 호출이 io.ReadCloser일 수 있으며 적절한 태그에 할당해야 하는 경우 io에 assert를 입력해야 한다는 것입니다. ReadCloser 및 테스트. 그러나 그것은 프로그램의 의도를 훨씬 더 명확하게 만듭니다. 정확히 당신이 의미하는 바는 코드에 있습니다.

또한 태그 어설션은 유형 어설션과 다르기 때문에 정말로 신경 쓰지 않고 io.Reader를 원하면 태그에 관계없이 유형 어설션을 사용하여 이를 가져올 수 있습니다.

이것은 장난감 예제를 조합/합계/등 없이 Go로 변환한 최선의 노력입니다. 아마도 가장 좋은 예는 아니지만 이것이 어떻게 생겼는지 확인하는 데 사용한 것입니다.

제안의 간결한 글머리 기호보다 이해하기 더 쉬울 가능성이 있는 보다 조작적인 방식으로 의미 체계를 보여줍니다.

음역에는 약간의 상용구가 있으므로 일반적으로 반복에 대한 메모와 함께 몇 가지 방법의 첫 번째 인스턴스만 작성했습니다.

노조 제안과 함께 이동:

type fail union { //zero value: (Local, nil)
  Local, Remote error
}

func (f fail) Error() string {
  //Could panic if local/remote nil, but assuming
  //it will be constructed purposefully
  return f.(error).Error()
}

type U union { //zero value: (A, "")
  A, B, C string
  D, E    int
  F       fail
}

//in a different package

func create() pkg.U {
  return pkg.U{D: 7}
}

func process(u pkg.U) {
  switch u := u.[type] {
  case A:
    handleA(u) //undefined here, just doing something with unboxed value
  case B:
    handleB(u)
  case C:
    handleC(u)
  case D:
    handleD(u)
  case E:
    handleE(u)
  case F:
    switch u := u.[type] {
    case Local:
      log.Fatal(u)
    case Remote:
      log.Printf("remote error %s", u)
      retry()
    } 
  }
}

현재 Go로 음역:

(음역과 위의 차이점에 대한 메모가 포함되어 있습니다.)

const ( //simulates tags, namespaced so other packages can see them without overlap
  Fail_Local = iota
  Fail_Remote
)

//since there are only two tags with a single type this can
//be represented precisely and safely
//the error method on the full version of fail can be
//put more succinctly with type embedding in this case

type fail struct { //zero value (Fail_Local, nil) :)
  remote bool
  error
}

// e, ok := f.[Local]
func (f *fail) TagAssertLocal2() (error, bool) { //same for TagAssertRemote2
  if !f.remote {
    return nil, false
  }
  return f.error, true
}

// e := f.[Local]
func (f *fail) TagAssertLocal() error { //same for TagAssertRemote
  if !f.remote {
    panic("invalid tag assert")
  }
  return f.error
}

// f.Local = err
func (f *fail) SetLocal(err error) { //same for SetRemote
  f.remote = false
  f.error = err
}

// simulate tag switch
func (f *fail) TagSwitch() int {
  if f.remote {
    return Fail_Remote
  }
  return Fail_Local
}

// f.(someType) needs to be written as f.TypeAssert().(someType)
func (f *fail) TypeAssert() interface{} {
  return f.error
}

const (
  U_A = iota
  U_B
  // ...
  U_F
)

type U struct { //zero value (U_A, "", 0, fail{}) :(
  kind int //more than two types, need an int
  s string //these would all occupy the same space
  i int
  f fail
}

//s, ok := u.[A]
func (u *U) TagAssertA2() (string, bool) { //similar for B, etc.
  if u.kind == U_A {
    return u.s, true
  }
  return "", false
}

//s := u.[A]
func (u *U) TagAssertA() string { //similar for B, etc.
  if u.kind != U_A {
    panic("invalid tag assert")
  }
  return u.s
}

// u.A = s
func (u *U) SetA(s string) { //similar for B, etc.
  //if there were any pointers or reference types
  //in the union, they'd have to be nil'd out here,
  //since the space isn't shared
  u.kind = U_A
  u.s = s
}

// special case of u.F.Local = err
func (u *U) SetF_Local(err error) { //same for SetF_Remote
  u.kind = U_F
  u.f.SetLocal(err)
}

func (u *U) TagSwitch() int {
  return u.kind
}

func (u *U) TypeAssert() interface{} {
  switch u.kind {
  case U_A, U_B, U_C:
    return u.s
  case U_D, U_E:
    return u.i
  }
  return u.f
}

//in a different package

func create() pkg.U {
  var u pkg.U
  u.SetD(7)
  return u
}

func process(u pkg.U) {
  switch u.TagSwitch() {
  case U_A:
    handleA(u.TagAssertA())
  case U_B:
    handleB(u.TagAssertB())
  case U_C:
    handleC(u.TagAssertC())
  case U_D:
    handleD(u.TagAssertD())
  case U_E:
    handleE(u.TagAssertE())
  case U_F:
    switch u := u.TagAssertF(); u.TagSwitch() {
    case Fail_Local:
      log.Fatal(u.TagAssertLocal())
    case Fail_Remote:
      log.Printf("remote error %s", u.TagAssertRemote())
    }
  }
}

@jimmyfrasche

Union에는 동일한 유형을 가질 수 있는 태그가 포함되어 있으므로 다음 구문이 더 적합하지 않습니다.

func process(u pkg.U) {
  switch v := u {
  case A:
    handleA(v) //undefined here, just doing something with unboxed value
  case B:
    handleB(v)
  case C:
    handleC(v)
  case D:
    handleD(v)
  case E:
    handleE(v)
  case F:
    switch w := v {
    case Local:
      log.Fatal(w)
    case Remote:
      log.Printf("remote error %s", w)
      retry()
    } 
  }
}

내가 보기에 스위치와 함께 사용할 때 공용체는 int 또는 string형과 같은 유형과 매우 유사합니다. 주요 차이점은 이전 유형과 달리 할당할 수 있는 '값'이 유한하고 스위치 자체가 철저하다는 것입니다. 따라서 이 경우에는 개발자의 정신적 작업을 줄여주는 특별한 구문이 필요하지 않습니다.

또한 이 제안에 따라 다음과 같은 코드가 유효할까요?

type Foo union {
    // Completely different types, no ambiguity
    A string
    B int
}

func Bar(f Foo) {
    switch v := f {
        ....
    }
}

....

func main() {
    // No need for Bar(Foo{A: "hello world"})
    Bar("hello world")
    Bar(1)
}

@urandom 가능할 때마다 기존 Go 구문에 대한 유추를 사용하여 의미를 반영하는 구문을 선택했습니다.

인터페이스 유형으로 할 수 있는 일

var i someInterface = someValue //where someValue implements someInterface.
var j someInterface = i //this assignment is different from the last one.

계약이 충족되는 한 someValue 의 유형이 무엇이든 상관없이 괜찮고 모호하지 않습니다.

공용체에 태그†를 도입할 때 때때로 모호할 수 있습니다. 마법 할당은 특정 경우에만 유효합니다. 특별한 케이스는 때때로 명시적이어야만 합니다.

나는 때때로 한 단계를 건너뛸 수 있다는 점을 보지 못합니다. 특히 코드 변경이 그 특별한 경우를 쉽게 무효화할 수 있고 그런 다음 돌아가서 어쨌든 모든 코드를 업데이트해야 할 때 특히 그렇습니다. C int 가 Foo 추가된 경우 Foo/Bar 예제를 사용하려면 Bar(1) 를 변경해야 하지만 Bar("hello world") 는 변경하지 않아야 합니다. 일반적이지 않은 상황에서 몇 번의 키 입력을 저장하기 위해 모든 것을 복잡하게 만들고 때로는 이렇게 보이고 때로는 그렇게 보이기 때문에 개념을 이해하기 어렵게 만듭니다.

† 나는 그들에게 더 나은 이름이 있었으면 좋겠다. 이미 구조체 태그가 있습니다. 레이블이라고 부르고 싶었지만 Go에도 레이블이 있습니다. 그것들을 필드라고 부르는 것이 더 적절하고 가장 혼란스러워 보입니다. 누군가가 자전거를 타고 싶어한다면 이것은 정말로 신선한 코트를 사용할 수 있습니다.

어떤 의미에서 태그가 있는 공용체는 인터페이스보다 구조체와 더 유사합니다. 한 번에 하나의 필드만 설정할 수 있는 특수한 종류의 구조체입니다. 그런 관점에서 보면 Foo/Bar 예제는 다음과 같습니다.

type Foo struct {
  A string
  B int
}

func Bar(f Foo) {...}

func main() {
  Bar("hello world") //same as Bar(Foo{A: "hello world", B: 0})
  Bar(1) //same as Bar(Foo{A: "", B: 1})
}

이 경우에는 분명하지만 좋은 생각은 아니라고 생각합니다.

또한 제안서에서 Bar(Foo{1}) 는 정말로 키 입력을 저장하려는 경우 명확할 때 허용됩니다. 또한 통합에 대한 포인터를 가질 수 있으므로 &Foo{"hello world"} 에는 복합 리터럴 구문이 여전히 필요합니다.

즉, 공용체는 현재 "필드"가 설정된 동적 태그가 있다는 점에서 인터페이스와 유사합니다.

switch v := u.[type] {... 는 인터페이스에 대해 switch v := i.(type) {... 를 훌륭하게 미러링하는 동시에 공용체 값에 대한 직접 유형 전환 및 어설션을 허용합니다. 더 쉽게 식별할 수 있도록 u.[union] 이어야 하지만 어느 쪽이든 구문이 그렇게 무겁지 않고 의미가 명확합니다.

.(type) 가 불필요하다는 동일한 주장을 할 수 있지만, 제 생각에는 항상 무슨 일이 일어나고 있는지 정확히 알고 그것이 완전히 정당화된다는 것을 알 때입니다.

이것이 이러한 선택에 대한 나의 추론이었습니다.

@jimmyfrasche
스위치 구문은 설명 후에도 다소 직관적이지 않은 것 같습니다. 인터페이스를 사용하는 경우 switch v := i.(type) {... 는 전환 사례에 따라 나열되고 .(type) 로 표시되는 가능한 유형을 전환합니다.
그러나 Union을 사용하면 스위치가 가능한 유형이 아니라 값을 통해 전환됩니다. 각 경우는 다른 가능한 값을 나타내며 값은 실제로 동일한 유형을 공유할 수 있습니다. 이는 문자열 및 int 스위치와 더 유사합니다. 여기서 케이스도 값을 나열하고 해당 구문은 간단한 switch v := u {... 입니다. 그런 점에서 합집합 값을 통해 전환하는 것이 switch v := u { ... 되는 것이 더 자연스러워 보입니다. int 및 string의 경우보다 유사하지만 더 제한적이기 때문입니다.

@urandom 구문에 대한 아주 좋은 점입니다. 사실은 레이블이 없는 이전 제안서의 유보물이므로 당시 유형이었습니다. 그냥 아무 생각 없이 그냥 복사했습니다. 지적해주셔서 감사합니다.

switch u {... 작동 것이지만의 문제 switch v := u {... 너무 많은 모양입니다 switch v := f(); v {... (할 것이다 오류보고 더 어려운 명확하지 구성되었다).

@as 가 제안한 대로 union 키워드의 이름이 pick 로 변경된 경우 태그 스위치는 대칭을 유지하는 switch u.[pick] {... 또는 switch v := u.[pick] {... 로 작성될 수 있습니다. 유형 스위치가 있지만 혼란을 일으키지 않고 꽤 멋지게 보입니다.

구현이 int를 켜더라도 여전히 동적 태그 및 저장된 값으로 선택의 암시적 구조 해제가 있습니다. 이는 문법 규칙에 관계없이 명시적이어야 한다고 생각합니다.

태그 필드를 호출하고 필드 어설션 및 필드 전환이 되도록 하는 것은 매우 의미가 있습니다.

편집 : 선택과 함께 반사를 사용하는 것이 어색하지만

[답변이 늦어서 죄송합니다 - 저는 휴가 중이었습니다]

@ianlancetailor 는 다음

당신의 제안에서 볼 수 없는 것은 우리가 이것을 해야 하는 이유입니다. 새로운 종류의 유형을 추가하는 데는 분명한 단점이 있습니다. 바둑에 기대는 모든 사람이 배워야 하는 새로운 개념입니다. 보상 이점은 무엇입니까? 특히, 새로운 유형의 유형은 인터페이스 유형에서 얻을 수 없는 무엇을 제공합니까?

내가 보는 두 가지 주요 이점이 있습니다. 첫 번째는 언어 이점입니다. 두 번째는 성능상의 이점입니다.

• 메시지를 처리할 때, 특히 동시 프로세스에서 읽을 때 각 메시지에는 관련 프로토콜 요구 사항이 있을 수 있으므로 수신할 수 있는 전체 메시지 집합을 알 수 있으면 매우 유용합니다. 주어진 프로토콜에 대해 가능한 메시지 유형의 수는 매우 적을 수 있지만 메시지를 표현하기 위해 개방형 인터페이스를 사용할 때 그 불변성은 명확하지 않습니다. 종종 사람들은 이를 피하기 위해 각 메시지 유형에 대해 다른 채널을 사용하지만 그에 따른 비용이 따릅니다.

• 알려진 가능한 메시지 유형이 적고 포인터가 포함되어 있지 않은 경우가 있습니다. 개방형 인터페이스를 사용하여 이를 표현하려면 인터페이스 값을 만들기 위한 할당이 필요합니다. 가능한 메시지 유형을 제한하는 유형을 사용하면 이를 피할 수 있으므로 GC 압력을 완화하고 캐시 지역성을 높일 수 있습니다.

sum 유형이 해결할 수 있는 특별한 고통은 godoc입니다. ast.Spec 를 예로 들면 다음과 같습니다. https://golang.org/pkg/go/ast/#Spec

많은 패키지는 명명된 인터페이스 유형의 가능한 기본 유형을 수동으로 나열하므로 사용자가 코드를 보거나 이름 접미사 또는 접두사에 의존하지 않고도 아이디어를 빠르게 얻을 수 있습니다.

언어가 이미 가능한 모든 값을 알고 있는 경우 iotas가 있는 열거형 유형과 마찬가지로 godoc 에서 자동화할 수 있습니다. 또한 일반 텍스트가 아닌 실제로 유형에 연결할 수도 있습니다.

편집: 다른 예: https://github.com/mvdan/sh/commit/ebbfda50dfe167bee741460a4491ffec1006bdef

@mvdan 언어 변경 없이 Go1의 스토리를 개선할 수 있는 우수하고 실용적인 포인트입니다. 이에 대해 별도의 문제를 제출하고 이 문제를 참조할 수 있습니까?

죄송합니다. godoc 페이지 내의 다른 이름에 대한 링크만 언급하고 있지만 여전히 수동으로 나열하고 있습니까?

죄송합니다. 더 명확해야 합니다.

godoc의 현재 패키지에 정의된 인터페이스를 구현하는 유형을 자동으로 처리하기 위한 기능 요청을 의미했습니다.

(수동으로 나열된 이름을 연결하기 위한 기능 요청이 어딘가에 있다고 생각하지만 현재로서는 찾을 시간이 없습니다.)

나는 이(이미 매우 긴) 스레드를 인수하고 싶지 않으므로 별도의 문제를 만들었습니다. 위 참조.

@Merovius AST 항목이 열거형보다 합계 유형에 더 많이 적용되기 때문에 이 문제에서 https://github.com/golang/go/issues/19814#issuecomment -298833986에 회신하고

먼저, 합계 유형이 Go에 속하는지 확실하지 않다는 점을 반복해서 말씀드리고 싶습니다. 나는 그들이 확실히 속하지 않는다는 것을 아직 확신하지 못했습니다. 나는 그들이 아이디어를 탐구하고 그들이 맞는지 확인하기 위해 그렇게한다는 가정하에 작업하고 있습니다. 어느 쪽이든 설득할 용의가 있습니다.

둘째, 귀하의 의견에서 점진적인 코드 복구를 언급했습니다. 합계 유형에 새 용어를 추가하는 것은 정의상 인터페이스에 새 메서드를 추가하거나 구조체에서 필드를 제거하는 것과 동등한 주요 변경 사항입니다. 그러나 이것은 올바르고 바람직한 행동입니다.

새로운 종류의 노드를 추가하는 Node 인터페이스로 구현된 AST의 예를 살펴보겠습니다. AST가 외부 프로젝트에 정의되어 있고 AST를 안내하는 프로젝트의 패키지에서 AST를 가져오고 있다고 가정해 보겠습니다.

다음과 같은 경우가 있습니다.

1. 코드는 모든 노드를 이동할 것으로 예상합니다.
   1.1. 기본 문이 없습니다. 코드가 자동으로 올바르지 않습니다.
   1.2. 패닉이 있는 기본 문이 있고 컴파일 시간 대신 런타임에 코드가 실패합니다(테스트를 작성할 때 존재했던 노드에 대해서만 알기 때문에 테스트는 도움이 되지 않습니다).
2. 코드는 노드 유형의 하위 집합만 검사합니다.
   2.1. 이 새로운 종류의 노드는 어쨌든 하위 집합에 없었을 것입니다.
   2.1.1. 이 새 노드가 관심 있는 노드를 포함하지 않는 한 모든 것이 잘 됩니다.
   2.1.2. 그렇지 않으면 코드가 모든 노드를 걸을 것으로 예상되는 것과 같은 상황에 처하게 됩니다.
   2.2. 이 새로운 종류의 노드는 알고 있었다면 관심 있는 하위 집합에 포함되었을 것입니다.

인터페이스 기반 AST의 경우에만 2.1.1이 올바르게 작동합니다. 이것은 무엇보다 우연입니다. 점진적 코드 복구가 작동하지 않습니다. AST는 버전을 올려야 하고 코드는 버전을 올려야 합니다.

철저한 린터가 도움이 되지만 린터가 모든 인터페이스 유형을 검사할 수 없기 때문에 특정 인터페이스를 검사해야 한다고 알려야 합니다. 이는 소스 주석 또는 리포지토리에 있는 일종의 구성 파일을 의미합니다. 소스 내 주석인 경우 정의에 따라 AST가 별도의 프로젝트에 정의되어 있으므로 해당 프로젝트에 따라 철저한 검사를 위해 인터페이스에 태그를 지정해야 합니다. 이것은 전체 커뮤니티가 동의하고 항상 사용하는 하나의 철저한 린터가 있는 경우에만 대규모로 작동합니다.

합계 기반 AST를 사용하면 여전히 버전 관리를 사용해야 합니다. 이 경우의 유일한 차이점은 철저한 린터가 컴파일러에 내장되어 있다는 것입니다.

둘 다 2.2에는 도움이 되지 않지만 무엇을 할 수 있습니까?

합계 유형이 유용할 더 간단한 AST 인접 사례가 있습니다. 바로 토큰입니다. 더 간단한 계산기를 위해 어휘분석기를 작성한다고 가정해 보겠습니다. 연관된 값이 없는 * 와 같은 토큰과 이름을 나타내는 문자열이 있는 Var 와 같은 토큰 및 float64를 보유하는 Val 와 같은 토큰이 있습니다. .

이것을 인터페이스로 구현할 수는 있지만 번거로울 것입니다. 하지만 아마도 다음과 같이 할 것입니다.

package token
type Type int
const (
  Times Type = iota
  // ...
  Var
  Val
)
type Value struct {
  Type
  Name string // only valid if Type == Var
  Number float64 // only valid if Type == Val
}

iota 기반 열거형에 대한 철저한 린터는 잘못된 Type이 사용되지 않도록 할 수 있지만 Type == Times일 때 Name에 할당하거나 Type == Var일 때 Number를 사용하는 사람에 대해서는 잘 작동하지 않습니다. 토큰의 수와 종류가 늘어날수록 악화될 뿐입니다. 여기서 할 수 있는 최선의 방법은 Valid() error 메서드를 추가하는 것입니다. 이 메서드는 모든 제약 조건과 언제 무엇을 할 수 있는지 설명하는 많은 문서를 확인합니다.

합계 유형은 이러한 모든 제약 조건을 쉽게 인코딩하고 정의는 필요한 모든 문서가 될 것입니다. 새로운 종류의 토큰을 추가하는 것은 주요 변경 사항이지만 AST에 대해 말한 모든 내용은 여전히 ​​여기에 적용됩니다.

더 많은 도구가 필요하다고 생각합니다. 나는 그것이 충분하다고 확신하지 못합니다.

@jimmyfrasche

둘째, 귀하의 의견에서 점진적인 코드 복구를 언급했습니다. 합계 유형에 새 용어를 추가하는 것은 정의상 인터페이스에 새 메서드를 추가하거나 구조체에서 필드를 제거하는 것과 동등한 주요 변경 사항입니다.

아니요, 동등하지 않습니다. 점진적 복구 모델에서 이러한 변경을 모두 수행할 수 있습니다(인터페이스의 경우: 1. 모든 구현에 새 메서드 추가, 2. 인터페이스에 메서드 추가. 구조체 필드의 경우: 1. 필드의 모든 사용 제거, 2. 필드 제거). 합계 유형에 케이스를 추가하는 것은 점진적 수리 모델에서 작동 하지 않습니다 . lib를 먼저 추가하면 더 이상 철저하게 확인하지 않기 때문에 모든 사용자가 중단되지만 새 사례가 아직 존재하지 않기 때문에 사용자에게 먼저 추가할 수 없습니다. 제거도 마찬가지입니다.

중요한 변경 사항인지 여부가 아니라 중단을 최소화하면서 조정할 수 있는 주요 변경 사항인지 여부입니다.

그러나 이것은 올바르고 바람직한 행동입니다.

정확히. Sum 유형의 정의와 사람들이 원하는 모든 이유는 근본적으로 점진적 코드 복구 개념과 양립할 수 없습니다.

인터페이스 기반 AST의 경우에만 2.1.1이 올바르게 작동합니다.

아니오, 1.2의 경우에도 올바르게 작동합니다(인식할 수 없는 문법으로 인해 런타임에 실패하는 것은 완벽합니다. 하지만 당황하고 싶지는 않지만 오류를 반환함) 및 2.1의 많은 경우에서도 올바르게 작동합니다. 나머지는 소프트웨어 업그레이드의 근본적인 문제입니다. 라이브러리에 새 기능을 추가하면 라이브러리 사용자가 이를 사용하려면 코드를 변경해야 합니다. 그렇다고 해서 소프트웨어가 올바르지 않다는 의미는 아닙니다.

AST는 버전을 올려야 하고 코드는 버전을 올려야 합니다.

나는 이것이 당신의 말에서 어떻게 이어지는지 전혀 알지 못합니다. 나에게 "이 새로운 문법은 아직 모든 도구에서 작동하지는 않지만 컴파일러에서는 사용할 수 있습니다"라고 말하는 것이 좋습니다. "이 새로운 문법에서 이 도구를 실행하면 런타임에 실패할 것"인 것처럼 괜찮습니다. 최악의 경우 이는 점진적 복구 프로세스에 또 다른 단계를 추가할 뿐입니다. a) AST 패키지 및 파서에 새 노드를 추가합니다. b) 새 노드를 활용하기 위해 AST 패키지를 사용하여 도구를 수정합니다. c) 새 노드를 사용하도록 코드를 업데이트합니다. 예, 새 노드는 a) 및 b)가 완료된 후에만 사용할 수 있습니다. 그러나 이 프로세스의 모든 단계에서 중단 없이 모든 것이 여전히 올바르게 컴파일되고 작동합니다.

점진적인 코드 복구와 철저한 컴파일러 검사가 없는 세상에서 자동으로 괜찮을 것이라는 말은 아닙니다. 여전히 신중한 계획과 실행이 필요하며 유지 관리되지 않은 역 종속성을 여전히 깨뜨릴 수 있으며 전혀 수행할 수 없는 변경 사항이 있을 수 있습니다(생각할 수는 없지만). 그러나 적어도 a) 점진적인 업그레이드 경로가 있고 b) 이것이 런타임에 도구를 중단해야 하는지 여부에 대한 결정은 도구 작성자에게 달려 있습니다. 그들은 알 수 없는 경우에 해야 할 일을 결정할 수 있습니다.

철저한 린터가 도움이 되지만 린터가 모든 인터페이스 유형을 검사할 수 없기 때문에 특정 인터페이스를 검사해야 한다고 알려야 합니다.

왜요? 나는 switchlint™가 default-case가 없는 모든 유형 스위치에 대해 불평하는 것이 괜찮다고 주장하고 싶습니다. 결국 코드가 모든 인터페이스 정의와 함께 작동할 것으로 예상하므로 알 수 없는 구현과 함께 작동하는 코드가 없으면 어쨌든 문제가 될 수 있습니다. 예, 이 규칙에는 예외가 있지만 예외는 이미 수동으로 무시할 수 있습니다.

실제 합계 유형보다 컴파일러에서 "모든 유형 전환은 기본 케이스가 필요하더라도 기본 케이스가 필요합니다"를 적용하는 데 더 동의할 것입니다. 사람들이 알 수 없는 선택에 직면했을 때 코드가 수행해야 할 작업을 결정하도록 하고 강제할 것입니다.

이것을 인터페이스로 구현할 수는 있지만 번거로울 것입니다.

어깨를 으쓱 하는 것은 매우 드물게 발생하는 경우에 일회성 노력입니다. 나에게 괜찮아 보인다.

그리고 FWIW, 나는 현재 합계 유형의 철저한 확인 개념에 대해 논쟁하고 있습니다. 나는 "이러한 구조적으로 정의된 유형 중 하나"라고 말하는 추가된 편의성에 대해 아직 강력한 의견이 없습니다.

@Merovius 점진적 코드 복구에 대한 귀하의 우수한 점에 대해 더 생각해야 할 것입니다. 그동안:

철저함 검사

나는 현재 합계 유형의 철저한 확인 개념에 반대하는 주장만 하고 있습니다.

기본 케이스를 사용하여 완전성 검사를 명시적으로 옵트아웃할 수 있습니다(효과적으로: 기본값은 "그 밖의 모든 것"을 포함하는 케이스를 추가하여 철저하게 만듭니다). 여전히 선택권이 있지만 명시적으로 선택해야 합니다.

나는 switchlint™가 default-case가 없는 모든 유형 스위치에 대해 불평하는 것이 괜찮다고 주장하고 싶습니다. 결국 코드가 모든 인터페이스 정의와 함께 작동할 것으로 예상하므로 알 수 없는 구현과 함께 작동하는 코드가 없으면 어쨌든 문제가 될 수 있습니다. 예, 이 규칙에는 예외가 있지만 예외는 이미 수동으로 무시할 수 있습니다.

흥미로운 아이디어네요. 인터페이스로 시뮬레이트된 합계 유형과 const/iota로 시뮬레이트된 열거형에 도달하지만 알려진 케이스를 놓쳤다고 말하지 않고 알 수 없는 케이스를 처리하지 않았다는 것을 알려줍니다. 어쨌든 시끄러운 것 같습니다. 고려하다:

switch {
case n < 0:
case n == 0:
case n > 0:
}

n이 정수이면 완전하지만(수레의 경우 n != n 누락됨) 유형에 대한 많은 정보를 인코딩하지 않고 기본값이 누락된 것으로 플래그 지정하는 것이 더 쉬울 것입니다. 다음과 같은 경우:

switch {
case p[0](a, b):
case p[1](a, b):
//...
case p[N](a, b):
}

p[i] 가 a 및 b 유형에 대해 등가 관계를 형성하더라도 이를 증명할 수 없으므로 스위치에 기본값이 없는 것으로 플래그를 지정해야 합니다. 이는 매니페스트, 소스의 주석, 허용 목록에 있는 egrep -v 대한 래퍼 스크립트 또는 p[i] 는 완전하지 않습니다.

어쨌든 "모든 상황에서 항상 불이행에 대해 불평하지 않는"경로를 사용한다면 구현하기에는 사소한 린터가 될 것입니다. 그렇게 하고 go-corpus에서 실행하고 실제로 얼마나 시끄럽고 유용한지 확인하는 것은 흥미로울 것입니다.

토큰

대체 토큰 구현:

//Type defined as before
type SimpleToken { Type }
type StringToken { Type; Value string }
type NumberToken { Type; Value float64 }
type Interface interface {
  //some method common to all these types, maybe just token() Interface
}

이는 문자열과 숫자 값을 모두 가지고 있지만 SimpleToken 또는 그 반대여야 하는 유형으로 StringToken 생성을 허용하지 않는 불법 토큰 상태를 정의할 가능성을 제거합니다. 반대로

인터페이스로 그렇게 하려면 토큰당 하나의 유형을 정의해야 하며( type Plus struct{} , type Mul struct{} 등) 대부분의 정의는 유형 이름에 대해 정확히 동일합니다. 일회성 노력이든 아니든 그것은 많은 작업입니다(이 경우 코드 생성에 적합하지만).

허용 가능한 값을 기반으로 토큰 종류를 분할하기 위해 토큰 인터페이스의 "계층 구조"를 가질 수 있다고 가정합니다.

type SimpleToken int //implements token.Interface
const (
  Plus SimpleToken = iota
  // ...
}
type NumericToken interface {
  Interface
  Value() float64
  nt() NumericToken
}
type IntToken struct { //implements NumericToken, and a FloatToken
type StringToken interface { // for Var and Func and Const, etc.
  Interface
  Value() string
  st() StringToken
}

그럼에도 불구하고 문자열이 포함될 때만 포인터가 필요한 구조체 또는 합계 유형과 달리 각 토큰은 해당 값에 액세스하기 위해 포인터 참조가 필요합니다. 따라서 적절한 린터와 godoc의 개선으로 이 경우 합계 유형에 대한 큰 승리는 할당을 최소화하면서 불법 상태와 타이핑의 양(키보드 의미에서)을 허용하지 않는 것과 관련이 있습니다. 이는 중요하지 않은 것 같습니다.

기본 케이스를 사용하여 완전성 검사를 명시적으로 옵트아웃할 수 있습니다(효과적으로: 기본값은 "그 밖의 모든 것"을 포함하는 케이스를 추가하여 철저하게 만듭니다). 여전히 선택권이 있지만 명시적으로 선택해야 합니다.

따라서 어느 쪽이든 우리 둘 다 철저한 확인을 선택하거나 선택하지 않을 수 있습니다. :)

알려진 케이스를 놓쳤다는 것이 아니라 알려지지 않은 케이스를 처리하지 않았다는 것입니다.

효과적으로, 나는 컴파일러가 이미 전체 프로그램 분석을 수행하여 내가 생각 하는 인터페이스에서 어떤 구체적인 유형이 사용되는지를 결정
그러나 솔직히 이것은 첫 번째 원칙에서 주장되며 실제 구현에 대해서는 전혀 모릅니다.

어떤 경우든 a) 전체 프로그램에 정의된 구체적인 유형을 나열하고 b) 모든 유형 스위치에 대해 해당 인터페이스를 구현하는지 여부를 필터링하는 것은 매우 쉬워야 합니다. 당신은 같은 것을 사용하는 경우 이 , 당신은 신뢰할 수있는 목록으로 끝낼 것입니다. 제 생각에는.

나는 도구가 실제로 명시 적으로 옵션을 알리는만큼 신뢰성이 기록 될 수 있다는 것을 100 % 확신 아니지만, 나는 당신이 사례의 90 %를 커버 할 수 있다고 확신하고 당신은 확실히이 외부에서 수행하는 도구를 쓸 수 올바른 주석이 제공된 컴파일러(즉, sum-types를 실제 유형이 아닌 pragma와 유사한 주석으로 만듭니다). 물론 좋은 해결책은 아닙니다.

어쨌든 시끄러운 것 같습니다. 고려하다:

나는 이것이 불공평하다고 생각한다. 귀하가 언급한 사례는 합계 유형과 전혀 관련이 없습니다. 그러한 도구를 어디에 작성해야 한다면 유형 스위치와 표현식이 있는 스위치로 제한할 것입니다. 합 유형도 처리되는 방식인 것 같기 때문입니다.

대체 토큰 구현:

마커 방식이 아닌 이유는 무엇입니까? 유형 필드가 필요하지 않으며 인터페이스 표현에서 무료로 얻을 수 있습니다. marker-method를 계속해서 반복하는 것이 걱정된다면; 내보내지 않은 구조체{}를 정의하고 해당 마커 메서드를 제공하고 각 구현에 포함하여 메서드보다 추가 비용이 없고 옵션당 타이핑이 적습니다.

그럼에도 불구하고 각 토큰에는 해당 값에 액세스하기 위해 포인터 참조가 필요합니다.

예. 그것은 실제 비용이지만 기본적으로 다른 어떤 주장보다 중요하다고 생각하지 않습니다.

나는 이것이 불공평하다고 생각한다.

그건 사실이야.

나는 빠르고 더러운 버전을 작성하고 stdlib에서 실행했습니다. switch 문에 1956개의 히트가 있는지 확인하고 switch { 형식을 건너뛰도록 제한하면 해당 개수가 1677로 줄어듭니다. 결과가 의미있는지 확인하기 위해 해당 위치를 검사하지 않았습니다.

https://github.com/jimmyfrasche/switchlint

확실히 개선의 여지가 많습니다. 아주 세련되지는 않습니다. 풀 리퀘스트를 환영합니다.

(나머지 답변은 나중에 할게요)

편집: 잘못된 마크업 형식

나는 이것이 지금까지의 모든 것에 대한 (상당히 편향된) 요약이라고 생각합니다(그리고 내 두 번째 제안을 자기애적으로 가정함)

장점

• 간결하고, 여러 제약 조건을 자체 문서화 방식으로 간결하게 작성하기 쉽습니다.
• 더 나은 할당 제어
• 최적화하기 쉬움(컴파일러에 알려진 모든 가능성)
• 철저한 확인(원하는 경우 선택 해제 가능)

단점

• 합계 유형의 구성원에 대한 모든 변경은 주요 변경이며 모든 외부 패키지가 완전성 검사를 선택하지 않는 한 점진적인 코드 복구를 허용하지 않습니다.
• 언어에서 배워야 할 또 다른 것, 기존 기능과 일부 개념적 겹침
• 가비지 수집기는 어떤 멤버가 포인터인지 알아야 합니다.
• 1 + 1 + ⋯ + 1 형식의 합계에 대해 어색함

대안

• 1 + 1 + ⋯ + 1 형식의 합계에 대한 iota "enum"
• 더 복잡한 합계를 위해 내보내지 않은 태그 메서드와 인터페이스(생성될 수 있음)
• 또는 열거형 값에 따라 설정되는 필드에 대한 iota 열거형 및 언어 외 규칙이 있는 구조체

에 관계없이

• 더 나은 툴링, 항상 더 나은 툴링

점진적인 수리의 경우, 그리고 그것이 큰 문제인 경우, 유일한 옵션은 외부 패키지가 완전성 검사를 옵트아웃하는 것뿐이라고 생각합니다. 이것은 다른 모든 것과 일치하더라도 미래의 교정에만 관련된 "불필요한" 기본 사례를 갖는 것이 합법적이어야 함을 의미합니다. 나는 그것이 지금 암묵적으로 사실이라고 믿습니다. 그리고 지정하기가 쉽지 않다면 말입니다.

패키지 관리자가 "다음 버전에서 이 합계 유형에 새 멤버를 추가할 예정이니 처리할 수 있는지 확인하십시오"라고 발표하면 switchlint 도구가 필요한 모든 경우를 찾을 수 있습니다. 선택 해제됩니다.

다른 경우처럼 간단하지는 않지만 여전히 수행할 수 있습니다.

외부에서 정의된 합계 유형을 사용하는 프로그램을 작성할 때 기본값을 주석 처리하여 알려진 사례를 놓치지 않았는지 확인한 다음 커밋하기 전에 주석 처리를 제거할 수 있습니다. 또는 기본값이 "불필요함"임을 알려주는 도구가 있을 수 있습니다. 이 도구는 모든 정보를 알고 있으며 미래에 알 수 없는 것에 대비할 수 있음을 알려줍니다.

정의된 패키지에 관계없이 합계 유형을 시뮬레이션하는 인터페이스 유형을 사용할 때 린터로 완전성 검사를 선택하고 싶다고 가정해 보겠습니다.

@Merovius 귀하의 betterSumType() BetterSumType 트릭은 매우 훌륭하지만, 이는 정의 패키지에서 전환이 발생해야 함을 의미합니다(또는 다음과 같은 것을 노출해야 합니다.

func CallBeforeSwitches(b BetterSumType) (BetterSumType, bool) {
    if b == nil {
        return nil, false
    }
    b = b.betterSumType()
    if b == nil {
        return nil, false
    }
    return b, true
}

또한 매번 호출되는 보푸라기).

프로그램의 모든 스위치가 철저한지 확인하는 데 필요한 기준은 무엇입니까?

빈 인터페이스가 될 수 없습니다. 그러면 모든 것이 게임이기 때문입니다. 따라서 적어도 하나의 방법이 필요합니다.

인터페이스에 내보내지 않은 메서드가 없는 경우 모든 유형이 이를 구현할 수 있으므로 철저성은 각 스위치의 호출 그래프에 있는 모든 패키지에 따라 달라집니다. 패키지를 가져오고 해당 인터페이스를 구현한 다음 해당 값을 패키지의 기능 중 하나로 보낼 수 있습니다. 따라서 해당 기능의 스위치는 가져오기 주기를 생성하지 않고는 철저할 수 없습니다. 따라서 최소한 하나의 내보내지 않은 메서드가 필요합니다. (이것은 이전 기준을 포함합니다).

임베딩은 우리가 찾고 있는 속성을 망칠 것이므로 패키지의 임포터 중 어느 누구도 인터페이스 또는 그것을 구현하는 유형을 어느 시점에서든 포함하지 않도록 해야 합니다. 정말 멋진 린터는 임베디드 값을 생성하는 특정 함수를 호출하지 않거나 임베디드 인터페이스가 패키지의 API 경계를 "이스케이프"하지 않는 경우 때때로 임베디드가 괜찮다고 말할 수 있습니다.

철저하게 하려면 인터페이스의 0 값이 절대 전달되지 않는지 확인하거나 철저한 스위치 확인 case nil 도 적용해야 합니다. (후자가 더 쉽지만 nil을 포함하면 "유형 A 또는 유형 B 또는 유형 C" 합계가 "무 또는 유형 A 또는 유형 B 또는 유형 C" 합계로 바뀌므로 전자가 선호됩니다.)

모든 가져오기 트리와 해당 트리 내의 지정된 인터페이스에 대해 이러한 의미 체계를 확인할 수 있는 모든 기능(선택 사항 포함)을 포함하는 린터가 있다고 가정해 보겠습니다.

이제 종속성 D가 있는 프로젝트가 있다고 가정해 보겠습니다. D 패키지 중 하나에 정의된 인터페이스가 프로젝트에서 완전한지 확인하려고 합니다. 그렇게 한다고 가정해 봅시다.

이제 프로젝트 D'에 새 종속성을 추가해야 합니다. D'가 문제의 인터페이스 유형을 정의한 D의 패키지를 가져오지만 이 린터를 사용하지 않으면 우리가 완전한 스위치를 사용하기 위해 보유해야 하는 불변성을 쉽게 파괴할 수 있습니다.

그 문제에 대해 D가 linter를 우연히 전달했다고 가정해 봅시다. D로의 업그레이드는 D'만큼 쉽게 불변성을 파괴할 수 있습니다.

린터가 "지금은 100% 완전 👍" 라고 해도 우리가 아무것도 하지 않아도 바뀔 수 있습니다.

"iota enums"에 대한 철저한 검사기가 더 쉬워 보입니다.

u 가 정수이고 t 가 개별적으로 지정된 값 또는 iota 있는 const 로 사용되는 모든 type t u 에 대해 u 대한 값이 이러한 상수에 포함됩니다.

노트:

• 중복 값은 이 분석에서 별칭으로 처리되고 무시될 수 있습니다. 명명된 모든 상수에는 고유한 값이 있다고 가정합니다.
• 1 << iota 는 적어도 대부분의 경우 powerset으로 취급될 수 있지만 아마도 비트별 보수를 둘러싼 추가 조건이 필요할 것입니다. 당분간은 고려하지 않습니다

약식으로 min(t) 상수를 호출하여 다른 상수에 대해 C , min(t) <= C , 유사하게 max(t) 상수를 다음과 같이 호출합니다. 다른 상수 C , C <= max(t) .

t 가 철저하게 사용되도록 하려면 다음을 확인해야 합니다.

• t 은 항상 명명된 상수입니다(또는 함수 호출과 같은 특정 관용적 위치에서는 0).
• min(t) <= v <= max(t) 외부에 t , v 값의 불평등 비교가 없습니다.
• t 값은 산술 연산 + , / 등에 사용되지 않습니다. 가능한 예외는 결과가 min(t) 와 max(t) 사이에 고정될 때일 수 있습니다 t 를 정의하는 패키지로 제한되어야 합니다.
• 스위치는 t 의 모든 상수 또는 기본 케이스를 포함합니다.

이는 여전히 가져오기 트리의 모든 패키지를 확인해야 하며 관용적 코드에서 무효화될 가능성이 적지만 쉽게 무효화될 수 있습니다.

내 이해에 따르면 이것은 유형 별칭과 유사하게 변경 사항을 깨뜨리지 않을 것이므로 Go 2를 위해 보류하는 이유는 무엇입니까?

유형 별칭은 새로운 키워드를 도입하지 않으며 이는 확실한 주요 변경 사항입니다. 또한 사소한 언어 변경에도 모라토리엄이 있는 것으로 보이며 이는 주요 변경 사항이 될 것입니다. 반영된 합계 값을 처리하기 위해 모든 마샬/비정렬 루틴을 개조하는 것만으로도 엄청난 시련이 될 것입니다.

유형 별칭은 해결 방법이 없는 문제를 수정하고 있습니다. Sum 유형은 유형 안전성에 이점을 제공하지만, 그것이 없는 것은 쇼 스토퍼가 아닙니다.

@rogpeppe 의 원래 제안과 같은 http 패키지에는 Handler 인터페이스 유형과 이를 구현하는 함수 유형 HandlerFunc 있습니다. 현재 http.Handle 함수를 전달하려면 명시적으로 HandlerFunc 로 변환해야 합니다. http.Handle 대신 HandlerFunc | Handler 유형의 인수를 수락하면 HandlerFunc 직접 할당할 수 있는 모든 함수/클로저를 수락할 수 있습니다. 공용체는 이름이 지정되지 않은 유형의 값을 인터페이스 유형으로 변환할 수 있는 방법을 컴파일러에 알려주는 유형 힌트 역할을 효과적으로 수행합니다. HandlerFunc 는 Handler HandlerFunc 구현하므로 공용체 유형은 그렇지 않으면 Handler 처럼 작동합니다.

열거 스레드( https://github.com/golang/go/issues/19814#issuecomment -322752526) 에 대한 귀하의 의견에 대한 @griesemer, 제 제안은 이 스레드의 앞부분 https://github.com/golang/ go/issues/19412#issuecomment -289588569는 합계 유형("신속한 스타일 열거형")이 Go에서 어떻게 작동해야 하는지에 대한 질문을 다룹니다. 만큼 내가 그들을 좋아하는 것처럼, 그들은 이동에 필요한 추가 될 나도 몰라,하지만 난는 그들이 볼 필요가 거라고 추가 된 경우 / 그런 많은 작동 생각하십니까.

그 게시물은 완전하지 않고 이 스레드 전체에 걸쳐, 전후에 설명이 있지만, 이 스레드가 상당히 길기 때문에 이러한 요점을 반복하거나 요약하는 데 신경쓰지 않습니다.

유형 태그가 있는 인터페이스로 시뮬레이션된 합계 유형이 있고 임베딩으로 이를 절대 피할 수 없는 경우 이것이 제가 생각해낸 최선의 방어책입니다. https://play.golang.org/p/FqdKfFojp-

@jimmyfrasche 나는 이것을 얼마 전에 썼습니다.

또 다른 가능한 접근 방식은 다음과 같습니다. https://play.golang.org/p/p2tFm984S8

@rogpeppe 리플렉션을 사용하려는 경우 리플렉션을 사용하지 않는 이유는 무엇입니까?

나는 여기와 다른 이슈에 있는 코멘트를 기반으로 두 번째 제안의 수정된 버전을 작성했습니다.

특히, 나는 철저한 검사를 제거했습니다. 그러나 외부 완전성 검사기는 아래 제안에 대해 작성하는 것이 간단하지만 합계 유형을 시뮬레이트하는 데 사용되는 다른 Go 유형에 대해 작성할 수 있다고 생각하지 않습니다.

편집: 선택 값의 동적 값에 대해 assert를 입력하는 기능을 제거했습니다. 그것은 너무 마술적이고 그것을 허용하는 이유는 코드 생성에서도 마찬가지로 제공됩니다.

Edit2: 선택이 다른 패키지에 정의되어 있을 때 필드 이름이 어설션 및 스위치와 함께 작동하는 방식을 명확히 했습니다.

Edit3: 제한된 임베딩 및 명확한 암시적 필드 이름

Edit4: 스위치에서 기본값을 명확히 합니다.

유형 선택

선택은 구조체와 구문적으로 유사한 복합 유형입니다.

pick {
  A, B S
  C, D T
  E U "a pick tag"
}

위의 A , B , C , D , E 는 선택의 필드 이름이고 S , T 및 U 는 해당 필드의 유형입니다. 필드 이름을 내보내거나 내보낼 수 있습니다.

선택은 간접 지정 없이 재귀적이지 않을 수 있습니다.

합법적 인

type p pick {
    //...
    p *p
}

불법적 인

type p pick {
    //...
    p p
}

선택에 대한 포함은 없지만 선택은 구조체에 포함될 수 있습니다. 선택이 구조체에 포함된 경우 선택의 메서드는 구조체로 승격되지만 선택의 필드는 그렇지 않습니다.

필드 이름이 없는 유형은 유형과 이름이 같은 필드를 정의하기 위한 축약형입니다. (이름이 T *T 예외를 제외하고 유형이 명명되지 않은 경우 오류입니다.)

예를 들어,

type p pick {
    io.Reader
    io.Writer
    string
}

에는 각각의 유형과 함께 Reader , Writer 및 string 세 개의 필드가 있습니다. string 필드는 유니버스 범위에 있어도 내보낼 수 없습니다.

선택 유형의 값은 동적 필드와 해당 필드의 값으로 구성됩니다.

선택 유형의 0 값은 소스 순서의 첫 번째 필드이며 해당 필드의 0 값입니다.

동일한 선택 유형의 두 값인 a 및 b 주어지면 선택 값은 다른 값으로 할당될 수 있습니다.

a = b

선택의 필드 유형 중 하나라도 선택하지 않은 값을 할당하는 것은 불법입니다.

선택 유형에는 주어진 시간에 하나의 동적 필드만 있습니다.

복합 리터럴 구문은 구조체와 유사하지만 추가 제한 사항이 있습니다. 즉, 키가 없는 리터럴은 항상 유효하지 않으며 하나의 키만 지정할 수 있습니다.

다음이 유효합니다.

pick{A string; B int}{A: "string"} //value is (B, "string")
pick{A, B int}{B: 1} //value is (B, 1)
pick{A, B string}{} //value is (A, "")

다음은 컴파일 시간 오류입니다.

pick{A int; B string}{A: 1, B: "string"} //a pick can only have one value at a time
pick{A int; B uint}{1} //pick composite literals must be keyed

pick {A int; B string} 유형의 p 값이 주어지면 다음 할당

p.B = "hi"

p 의 동적 필드를 B 하고 B 의 값을 "hi"로 설정합니다.

현재 동적 필드에 할당하면 해당 필드의 값이 업데이트됩니다. 새 동적 필드를 설정하는 할당은 지정되지 않은 메모리 위치를 0으로 설정해야 합니다. 선택 필드의 선택 또는 구조체 필드에 대한 할당은 필요에 따라 동적 필드를 업데이트하거나 설정합니다.

type P pick {
    A, B image.Point
}

var p P
fmt.Println(P) //{A: {0 0}}

p.A.X = 1 //A is the dynamic field, update
fmt.Println(P) //{A: {1 0}}

p.B.Y = 2 //B is not the dynamic value, create zero image.Point first
fmt.Println(P) //{B: {0 2}}

선택에 있는 값은 필드 어설션 또는 필드 스위치로만 액세스할 수 있습니다.

x := p.[X] //panics if X is not the dynamic field of p
x, ok := p.[X] //returns the zero value of X and false if X is not the dynamic field of p

switch v := p.[var] {
case A:
case B, C: // v is only defined in this case if fields B and C have identical type names
case D:
default: // always legal even if all fields are exhaustively listed above
}

필드 어설션 및 필드 스위치의 필드 이름은 정의된 패키지가 아니라 유형의 속성입니다. pick 를 정의하는 패키지 이름으로 규정되지 않으며 규정될 수도 없습니다.

이것은 유효합니다:

_, ok := externalPackage.ReturnsPick().[Field]

이것은 유효하지 않습니다:

_, ok := externalPackage.ReturnsPick().[externalPackage.Field]

필드 어설션 및 필드 전환은 항상 동적 필드 값의 복사본을 반환합니다.

내보내지 않은 필드 이름은 정의 패키지에서만 주장할 수 있습니다.

유형 어설션 및 유형 스위치는 선택에서도 작동합니다.

//removed, see note at top
//v, ok := p.(fmt.Stringer) //holds if the type of the dynamic field implements fmt.Stringer
//v, ok := p.(int) //holds if the type of the dynamic field is an int

유형 어설션 및 유형 스위치는 항상 동적 필드 값의 복사본을 반환합니다.

선택이 인터페이스에 저장된 경우 인터페이스에 대한 유형 어설션은 선택 자체의 메소드 세트와만 일치합니다. [여전히 사실이지만 위의 내용이 제거되었으므로 중복됨]

모든 유형의 선택이 같음 연산자를 지원하는 경우 다음을 수행합니다.

• 해당 선택의 값을 맵 키로 사용할 수 있습니다.
• 같은 선택의 두 가지 값은 == 그들은 같은 동적 필드가 그 값은 경우 ==
• 값이 == 경우에도 동적 필드가 다른 두 값은 != == 입니다.

선택 유형의 값에는 다른 연산자가 지원되지 않습니다.

픽 타입의 값 P 다른 선택 유형으로 변환 할 수 있습니다 Q 필드 이름의 세트에 해당 유형 IFF에 P 필드 이름과의 하위 집합입니다 그들의 Q 유형.

P 및 Q 가 다른 패키지에 정의되어 있고 내보내지 않은 필드가 있는 경우 해당 필드는 이름 및 유형에 관계없이 다른 것으로 간주됩니다.

예시:

type P pick {A int; B string}
type Q pick {B string; A int; C float64}

//legal
var p P
q := Q(p)

//illegal
var q Q
p := P(Q) //cannot handle field C

두 선택 유형 간의 지정 가능성은 유형 중 하나만 정의되는 한 변환 가능성으로 정의됩니다.

메서드는 정의된 선택 유형에 선언될 수 있습니다.

https://gist.github.com/jimmyfrasche/ba2b709cdc390585ba8c43c989797325 경험 보고서를 작성하고 위키에 추가했습니다.

Edit: and :heart: @mewmew 에게 그 요점에 대한 답글로 훨씬 더 좋고 자세한 보고서를 남겼습니다.

T 유형에 대해 T 유형으로 변환하거나 T 유형의 변수에 할당할 수 있는 유형 목록을 말할 수 있는 방법이 있다면 어떨까요? 예를 들어

type T interface{} restrict { string, error }

할당될 수 있는 유일한 유형이 string 또는 error 가 되도록 T 라는 빈 인터페이스 유형을 정의합니다. 다른 유형의 값을 할당하려고 하면 컴파일 시간 오류가 발생합니다. 이제 말할 수 있다

func FindOrFail(m map[int]string, key int) T {
    if v, ok := m[key]; ok {
        return v
    }
    return errors.New("no such key")
}

func Lookup() {
    v := FindOrFail(m, key)
    if err, ok := v.(error); ok {
        log.Fatal(err)
    }
    s := v.(string) // This type assertion must succeed.
}

합계 유형(또는 선택 유형)의 어떤 핵심 요소가 이러한 접근 방식으로 충족되지 않습니까?

s := v.(string) // This type assertion must succeed.

v 도 nil 일 수 있으므로 이것은 엄밀히 말하면 사실이 아닙니다. 이 가능성을 제거하려면 언어를 상당히 크게 변경해야 합니다. 값이 0이 아닌 유형과 수반되는 모든 것을 도입하는 것을 의미하기 때문입니다. 0 값은 언어의 일부를 단순화하지만 이러한 종류의 기능을 디자인하는 것도 더 어렵게 만듭니다.

흥미롭게도 이 접근 방식은 @rogpeppe 의 원래 제안과 상당히 유사합니다. 여기에 없는 것은 나열된 유형에 대한 강제 변환으로, 앞서 지적한 것과 같은 상황에서 유용할 수 있습니다( http.Handler ). 또 다른 점은 변형이 고유한 태그가 아닌 유형으로 구분되기 때문에 각 변형이 고유한 유형이어야 한다는 것입니다. 이것은 엄격하게 표현이 가능하다고 생각하지만 일부 사람들은 변형 태그와 유형을 구별하는 것을 선호합니다.

@ianlancetaylor

프로

• 닫힌 유형 집합으로 제한하는 것이 가능하며 이것이 가장 중요합니다.
• 정확한 완전성 검사기 작성 가능
• "계약을 충족하는 값을 이 속성에 할당할 수 있습니다"라는 속성을 얻습니다. (나는 이것에 대해 신경 쓰지 않지만 다른 사람들은 그렇게 생각한다고 생각합니다.)

단점

• 그것들은 단지 이점이 있는 인터페이스일 뿐 실제로 다른 종류의 유형은 아닙니다(좋은 이점이 있습니다!)
• 여전히 nil이 있으므로 유형 이론적인 의미에서 실제로 합 유형이 아닙니다. 어떤 A + B + C 를 지정하든 실제로는 선택의 여지가 없는 1 + A + B + C 입니다. 내가 이 작업을 하는 동안 @stevenblenkinsop이 지적했듯이.
• 더 중요한 것은 암시적 포인터 때문에 항상 간접 참조가 있다는 것입니다. 선택 제안을 사용하면 p 또는 *p 하여 메모리 트레이드 오프를 더 잘 제어할 수 있습니다. 최적화로 구별된 공용체(C 의미에서)로 구현할 수 없습니다.
• 0 값을 선택할 수 없습니다. 특히 Go에서 가능한 한 유용한 0 값을 갖는 것이 매우 중요하기 때문에 정말 좋은 속성입니다.
• 아마도 T 에 대한 메소드를 정의할 수 없었을 것입니다. type T restrict {string, error}
• 필드/summands/what-have-you에 대한 레이블을 잃으면 인터페이스 유형과 상호 작용할 때 혼란스러워집니다. 합계 유형의 강력한 "정확히 이것 또는 정확히 저것" 속성을 잃게 됩니다. io.Reader 를 넣고 io.Writer 꺼낼 수 있습니다. 이는 (무제한) 인터페이스에는 의미가 있지만 합계 유형에는 적합하지 않습니다.
• 두 개의 동일한 유형이 다른 것을 의미하도록 하려면 래퍼 유형을 사용하여 명확하게 해야 합니다. 이러한 태그는 구조체 필드가 ​​있는 방식으로 유형에 국한되지 않고 외부 네임스페이스에 있어야 합니다.
• 이것은 귀하의 특정 문구를 너무 많이 읽을 수 있지만 양수인의 유형에 따라 지정 가능성 규칙을 변경하는 것처럼 들립니다( error 지정 가능한 것을 지정할 수 없다는 의미로 읽습니다. to T 는 정확히 오류여야 합니다.

즉, 주요 상자(내가 나열한 처음 두 개의 장점)를 확인하고 그것이 내가 얻을 수 있는 전부라면 심장 박동에 걸릴 것입니다. 그래도 더 나아지길 바랍니다.

유형 어설션 규칙이 적용되었다고 가정했습니다. 따라서 유형은 구체적인 유형과 동일하거나 인터페이스 유형에 할당할 수 있어야 합니다. 기본적으로 인터페이스와 똑같이 작동하지만 모든 값( nil 제외)은 나열된 유형 중 하나 이상에 대해 어설션할 수 있어야 합니다.

@jimmyfrasche
업데이트된 제안에서 유형의 모든 요소가 고유한 유형인 경우 다음 할당이 가능합니까?

type p pick {
    A int
    B string
}

func Foo(P p) {
}

var P p = 42
var Q p = "foo"

Foo(42)
Foo("foo")

그러한 할당이 가능할 때 sum 유형의 유용성은 훨씬 더 큽니다.

선택 제안을 사용하면 p 또는 *p 하여 메모리 트레이드 오프를 더 잘 제어할 수 있습니다.

인터페이스가 스칼라 값을 저장하기 위해 할당하는 이유는 다른 단어가 포인터인지 여부를 결정하기 위해 유형 단어를 읽을 필요가 없기 때문입니다. 토론은 #8405를 참조하십시오. 동일한 구현 고려 사항이 선택 유형에 적용될 가능성이 높으며, 이는 실제로 p 결국 할당되고 로컬이 아님을 의미할 수 있습니다.

@urandom 아니요, 정의가 주어지면 작성해야 할 것입니다.

var p P = P{A: 42} // p := P{A: 42}
var q P = P{B: "foo")
Foo(P{A: 42}) // or Foo({A: 42}) if types can be elided here
Foo(P{B: "foo"})

한 번에 하나의 필드만 설정할 수 있는 구조체로 생각하는 것이 가장 좋습니다.

그것이 없으면 C uint 를 p 하면 p = 42 어떻게 됩니까?

순서와 할당 가능성을 기반으로 많은 규칙을 만들 수 있지만 항상 유형 정의의 변경이 해당 유형을 사용하는 모든 코드에 미묘하고 극적인 영향을 미칠 수 있음을 의미합니다.

가장 좋은 경우 변경은 모호성 부족에 의존하는 모든 코드를 중단하고 다시 컴파일하기 전에 p = int(42) 또는 p = uint(42) 로 변경해야 한다고 말합니다. 한 줄 변경으로 백 줄을 수정할 필요는 없습니다. 특히 해당 줄이 코드에 따라 사람들의 패키지에 있는 경우.

100% 노골적이거나 모든 것을 깨뜨릴 수 있기 때문에 아무도 만질 수 없는 매우 취약한 유형이어야 합니다.

이것은 모든 합계 유형 제안에 적용되지만 명시적 레이블이 있는 경우 레이블이 할당되는 유형에 대해 명시적이기 때문에 여전히 할당 가능성이 있습니다.

@josharian 그래서 내가 올바르게 읽고 있다면 iface가 이전에 Go가 했던 것처럼 두 번째 필드에 단어 크기 값을 숨기는 대신 항상 (*type, *value) 인 이유는 동시 GC가 두 가지 모두를 검사할 필요가 없도록 하기 위함입니다 두 번째 필드가 포인터인지 여부를 확인하기 위해 필드를 사용합니다. 항상 포인터라고 가정할 수 있습니다. 내가 맞았어?

즉, 선택 유형이 다음과 같이 (C 표기법을 사용하여) 구현된 경우

struct {
    int which;
    union {
         A a;
         B b;
         C c;
    } summands;
}

GC는 summands 를 스캔해야 하는지 결정하기 위해 which 를 검사하기 위해 잠금(또는 화려하지만 이와 동등한 것)을 해야 합니다.

iface가 Go가 이전에 했던 것처럼 두 번째 필드에 단어 크기 값을 숨기는 대신 항상 (*type, *value)인 이유는 동시 GC가 두 번째 필드가 포인터인지 확인하기 위해 두 필드를 모두 검사할 필요가 없도록 하기 위해서입니다. - 항상 그렇다고 가정할 수 있습니다.

좋아요.

물론 선택 유형의 제한된 특성으로 인해 일부 대체 구현이 허용됩니다. 선택 유형은 항상 일관된 포인터/비포인터 패턴이 있도록 배치될 수 있습니다. 예를 들어 모든 스칼라 유형은 겹칠 수 있고 문자열 필드는 슬라이스 필드의 시작과 겹칠 수 있습니다(둘 다 "포인터, 비포인터"로 시작하기 때문에). 그래서

pick {
  a uintptr
  b string
  c []byte
}

대략적으로 다음과 같이 정리할 수 있습니다.

[ word 1 (ptr) ] [ word 2 (non-ptr) ] [ word 3 (non-ptr) ]
[    <nil>         ] [                 a           ] [                              ]
[       b.ptr      ] [            b.len          ] [                              ]
[       c.ptr      ] [             c.len         ] [        c.cap             ]

그러나 다른 선택 유형은 이러한 최적의 포장을 허용하지 않을 수 있습니다. (깨진 ASCII에 대해 유감입니다. GitHub가 올바르게 렌더링하도록 할 수 없는 것 같습니다. 요점을 이해하셨으면 합니다.)

정적 레이아웃을 수행하는 이 기능은 선택 유형을 포함하는 것을 선호하는 성능 인수일 수도 있습니다. 여기서 내 목표는 단순히 관련 구현 세부 정보에 플래그를 지정하는 것입니다.

@josharian 그리고 그렇게 해주셔서 감사합니다. 나는 그것에 대해 생각하지 않았습니다. (솔직히 나는 GC를 구별하는 방법에 대한 연구가 있는지 구글링했고, 당신이 그렇게 할 수 있다는 것을 알았고 그것을 하루라고 불렀습니다. 어떤 이유에서인지 내 두뇌는 "동시성"을 연관시키지 않았습니다. 그날 "가기"와 함께: facepalm!).

유형 중 하나가 이미 레이아웃이 있는 구조체를 정의했다면 선택의 폭이 줄어들 것입니다.

한 가지 옵션은 크기가 동등한 구조체(판별자 int의 경우 + 1)와 동일함을 의미하는 포인터가 포함된 경우 summands를 "압축"하지 않는 것입니다. 가능하면 레이아웃을 공유할 수 있는 모든 유형이 수행할 수 있도록 하이브리드 접근 방식을 취할 수 있습니다.

좋은 크기 속성을 잃는 것은 부끄러운 일이지만 실제로는 최적화일 뿐입니다.

포인터가 포함되지 않은 경우에도 항상 1 + 해당 구조체의 크기라고 해도 할당에 대한 제어를 포함하여 형식 자체의 다른 모든 좋은 속성이 있습니다. 추가 최적화는 시간이 지남에 따라 추가될 수 있으며 적어도 귀하가 지적한 대로 가능할 것입니다.

type p pick {
    A int
    B string
}

A와 B가 있어야 합니까? 선택은 유형 집합에서 선택하므로 식별자 이름을 완전히 삭제하지 않는 이유는 무엇입니까?

type p pick {
    int
    string
}
q := p{string: "hello"}

나는 이 형식이 이미 구조체에 유효하다고 생각합니다. 선택에 필요하다는 제약이 있을 수 있습니다.

@as 필드 이름이 생략되면 유형과 동일하므로 예제가 작동하지만 해당 필드 이름은

유형 이름을 기반으로 암시적으로 생성되거나 할당 가능성 및 인터페이스 유형과의 잘못된 상호 작용이 있는 경우에도 필드 이름이 있어야 합니다. 필드 이름은 Go의 나머지 부분과 작동하게 만드는 것입니다.

@ 죄송하지만 당신이 내가 읽은 것과 다른 것을 의미한다는 것을 방금 깨달았습니다.

공식은 작동하지만 구조체 필드처럼 보이지만 일반적인 내보내기/내보내지 않은 항목으로 인해 다르게 동작하는 항목이 있습니다.

유니버스에 있기 때문에 p 정의하는 패키지 외부에서 문자열에 액세스할 수 있습니까?

이건 어떤가요

type t struct {}
type P pick {
  t
  //other stuff
}

?

유형 이름에서 필드 이름을 분리하여 다음과 같은 작업을 수행할 수 있습니다.

pick {
  unexported Exported
  Exported unexported
}

또는

pick { Recoverable, Fatal error }

선택 필드가 구조체 필드처럼 동작하면 구조체 필드에 대해 이미 알고 있는 많은 것을 선택 필드에 대해 생각할 수 있습니다. 유일한 실제 차이점은 한 번에 하나만 선택할 수 있는 필드를 설정할 수 있다는 것입니다.

@jimmyfrasche
Go는 이미 구조체 내부에 익명 유형을 포함하는 것을 지원하므로 범위 제한은 언어에 이미 존재하는 제한이며 유형 별칭으로 문제가 해결되고 있다고 생각합니다. 그러나 가능한 모든 사용 사례를 생각하지 않았다는 것을 인정합니다. 이 관용구가 Go에서 일반적인지 여부에 따라 달라지는 것 같습니다.

package p
type T struct{
    Exported t
}
type t struct{}

작은 _t_는 큰 T에 포함된 패키지에 존재하며 이러한 내보낸 유형을 통해서만 노출됩니다.

@같이

그러나 내가 완전히 따르고 있는지 확신할 수 없습니다.

//with the option to have field names
pick { //T is in the namespace of the pick and the type isn't exposed to other packages
  T t
  //...
}

//without
type T = t //T has to be defined in the outer scope and now t is exposed to other packages
pick {
  T
  //...
}

또한 레이블의 유형 이름만 있는 경우 []string 하려면 type Strings = []string 를 수행해야 합니다.

이것이 내가 구현한 선택 유형을 보고 싶은 방식입니다. 에
특히 Rust와 C++(성능에 대한 황금 표준)가 수행하는 방식입니다.
그것.

철저한 검사를 원하면 검사기를 사용할 수 있습니다. 원해요
성능 승리. 즉, 선택 유형도 nil이 될 수 없습니다.

선택 요소의 구성원 주소를 가져오는 것은 허용되지 않아야 합니다(
단일 스레드의 경우에도 메모리 안전하지 않습니다.
러스트 커뮤니티.). 선택 유형에 대한 다른 제한이 필요한 경우
그러면 됩니다. 그러나 선택 유형이 항상 힙에 할당되는 경우
나쁠 것입니다.

2017년 8월 18일 오후 12시 1분에 "jimmyfrasche" [email protected]이 작성했습니다.

@josharian https://github.com/josharian 그래서 내가 올바르게 읽고 있다면
iface가 이제 숨김 대신 항상 (*type, *value)인 이유
Go가 이전에 했던 것처럼 두 번째 필드의 단어 크기 값은
동시 GC는 두 번째 필드를 확인하기 위해 두 필드를 모두 검사할 필요가 없습니다.
포인터입니다. 항상 그렇다고 가정할 수 있습니다. 내가 맞았어?

즉, 선택 유형이 다음과 같이 (C 표기법을 사용하여) 구현된 경우

구조체 {
정수;
조합 {
에이;
ㄴㄴ;
씨씨;
} 명령;
}

GC는 잠금(또는 멋지지만 동등한 것)을 취해야 합니다.
summands를 스캔해야 하는지 여부를 결정하기 위해 어느 것을 검사합니까?

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/19412#issuecomment-323393003 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AGGWB3Ayi31dYwotewcfgmCQL-XVrfxIks5sZbVrgaJpZM4MTmSr
.

@DemiMarie

Pick 요소의 구성원 주소를 가져오는 것은 허용되지 않아야 합니다(Rust 커뮤니티에서 잘 알려진 것처럼 단일 스레드의 경우에도 메모리 안전하지 않습니다.). 선택 유형에 대한 다른 제한이 필요한 경우에도 마찬가지입니다.

그건 좋은 지적이야. 나는 거기에 그것을 가지고 있었지만 편집에서 잃어 버렸을 것입니다. 나는 선택에서 값에 액세스할 때 항상 같은 이유로 복사본을 반환한다는 것을 포함했습니다.

그것이 사실인 이유의 예로 후손을 위해 다음을 고려하십시오.

v := pick{ A int; B bool }{A: 5}
p := &v.[A] //(this would be illegal but pretending it's not for a second)
v.B = true

v 필드가 A 및 B 가 메모리에서 동일한 위치를 차지하도록 최적화된 경우 p 는 int를 가리키지 않습니다. 부울에. 메모리 안전이 위반되었습니다.

@jimmyfrasche

내용을 주소 지정하지 않으려는 두 번째 이유는 돌연변이 의미론입니다. 값 이 특정 상황에서 간접적으로 저장되는 경우

v := pick{ A int; ... }{A: 5}
v2 := v

v2.[A] = 6 // (this would be illegal under the proposal, but would be 
           // permitted if `v2.[A]` were addressable)

fmt.Println(v.[A]) // would print 6 if the contents of the pick are stored indirectly

pick 가 인터페이스와 유사한 한 곳은 값을 저장하는 경우 값 의미 체계를 유지하려는 것입니다. 당신이 구현 세부로 우회를해야 할 수 있습니다, 유일한 옵션은 주소가 아닌 내용을 확인하는 것입니다 (또는 더 정확하게, mutably 주소를하지만, 차이는 현재 이동에 존재하지 않는) 당신이 앨리어싱을 관찰 할 수 없을 정도로, .

편집: 죄송합니다(아래 참조)

@jimmyfrasche

선택 유형의 0 값은 소스 순서의 첫 번째 필드이며 해당 필드의 0 값입니다.

v.[A] 및 v.(error) 가 올바른 작업을 수행하도록 0 값을 특수 케이스로 지정하지 않는 한 첫 번째 필드를 간접적으로 저장해야 하는 경우에는 작동하지 않습니다.

@stevenblenkinsop "첫 번째 필드를 간접적으로 저장해야 함"이 무엇을 의미하는지 잘 모르겠습니다. 첫 번째 필드가 포인터인지 암시적으로 포인터를 포함하는 유형인지를 의미한다고 가정합니다. 그렇다면 아래에 예가 있습니다. 그렇지 않다면 명확히 해 주시겠습니까?

주어진

var p pick { A error; B int }

0 값 p 에는 동적 필드 A 있고 A 은 nil입니다.

pick 에 저장된 값이 포인터를 포함하는 것을 말하는 것이 아니라 @josharian이 설명한 대로 가비지 수집기에 의해 부과된 레이아웃 제약으로 인해 간접적으로 저장되는 포인터가 아닌 값을 언급한 것입니다. .

귀하의 예에서 p.B 포인터가 아님)는 두 개의 포인터로 구성된 p.A 와 겹치는 스토리지를 공유할 수 없습니다. 간접적으로 저장해야 할 가능성이 큽니다(예: *int 가 아니라 액세스할 때 자동으로 역참조되는 int 표시됨). p.B 가 첫 번째 필드인 경우 pick 의 0 값은 new(int) 이며 초기화가 필요하므로 허용되는 0 값이 아닙니다. nil *int 가 new(int) 로 처리되도록 특수 케이스를 지정해야 합니다.

@jimmyfrasche
아 죄송합니다. 대화를 다시 살펴보면 포인터가 아닌 유형의 간접 저장 인터페이스 메커니즘을 복사하는 대신 인접 저장소를 사용하여 호환되지 않는 레이아웃의 변형을 저장하는 것을 고려하고 있다는 것을 깨달았습니다. 내 마지막 세 가지 의견은 그 경우에 의미가 없습니다.

편집: 이런, 경쟁 조건. 게시한 후 귀하의 댓글을 보았습니다.

@stevenblenkinsop 아, 말인지 알겠습니다 . 하지만 그건 문제가 되지 않습니다.

겹치는 스토리지를 공유하는 것이 최적화입니다. 절대 그렇게 할 수 없습니다. 유형의 의미가 중요한 부분입니다.

컴파일러가 스토리지를 최적화할 수 있고 그렇게 하기로 선택한다면 좋은 보너스입니다.

귀하의 예에서 컴파일러는 동등한 구조체(활성 필드를 알기 위해 태그 추가)와 똑같이 저장할 수 있습니다. 이것은 것입니다

struct {
  which_field int // 0 = A, 1 = B
  A error
  B int
}

0 값은 여전히 ​​모든 바이트 0이며 특별한 경우로 은밀하게 할당할 필요가 없습니다.

중요한 부분은 주어진 시간에 한 필드만 플레이하도록 하는 것입니다.

예를 들어 선택의 모든 유형이 fmt.Stringer 를 만족하는 경우 선택에 대한 다음과 같은 메서드를 작성할 수 있도록 선택에 대한 유형 주장/전환을 허용한 동기

func (p P) String() string {
  return p.(fmt.Stringer).String()
}

그러나 선택 필드의 유형이 인터페이스가 될 수 있기 때문에 이것은 미묘함을 만듭니다.

이전 예에서 P 에 유형 자체가 fmt.Stringer 인 필드가 있는 경우 해당 String 메서드는 동적 필드이고 해당 값이 nil 인 경우 패닉합니다. nil 인터페이스를 입력할 수 없습니다. https://play.golang.org/p/HMYglwyVbl 이것은 항상 사실이지만 정기적으로 나타나지는 않지만 선택과 함께 더 정기적으로 나타날 수 있습니다.

그러나 합계 유형의 폐쇄적인 특성으로 인해 철저한 린터가 이것이 발생하는 모든 곳(잠재적으로 일부 오탐지가 있음)을 찾아 처리해야 하는 사례를 보고할 수 있습니다.

또한 선택 시 메서드를 구현할 수 있다면 해당 메서드가 형식 어설션을 충족하는 데 사용되지 않는다는 것도 놀라운 일입니다.

type Num pick { A int; B float32 }

func (n Num) String() string {
      switch v := n.[var] {
      case A:
          return fmt.Sprint(v)
      case B:
          return fmt.Sprint(v)
      }
}
...
n := Num{A: 5}
s1, ok := p.(fmt.Stringer) // ok == false
var i interface{} = p
s2, ok := i.(fmt.Stringer) // ok == true

유형 어설션이 인터페이스를 만족하는 경우 현재 필드에서 메소드를 승격하도록 할 수 있지만 이는 인터페이스 자체에 정의되지 않은 인터페이스 필드의 값에서 메소드를 승격할지 여부와 같은 고유한 문제에 부딪힙니다. 심지어 이것을 효율적으로 구현하는 방법). 또한 모든 필드에 공통적인 메서드가 선택 자체로 승격될 것으로 예상할 수 있지만 선택이 인터페이스에 저장된 경우 잠재적으로 가상 디스패치 외에 각 호출에서 변형 선택을 통해 디스패치되어야 합니다. 및/또는 필드가 인터페이스인 경우 가상 디스패치로 전송됩니다.

편집: 그건 그렇고, 최적으로 선택을 포장하는 것은 일반적으로 사용되는 탐욕적인 근사치가 있지만 NP-완전인 가장 짧은 일반적인 초문자열 문제의 인스턴스입니다.

규칙은 유형 주장이 선택 값의 동적 필드에 대해 주장하는 선택 값인 경우이지만 선택 값이 인터페이스에 저장된 경우 유형 주장은 선택 유형의 메서드 집합에 있습니다. 처음에는 놀랄 수 있지만 상당히 일관성이 있습니다.

선택 값에 대한 유형 어설션 허용을 삭제하는 것은 문제가 되지 않습니다. 모든 경우를 작성하거나 리플렉션을 사용할 필요 없이 선택의 모든 유형이 공유하는 메소드를 매우 쉽게 홍보할 수 있기 때문에 부끄러운 일입니다.

그러나 코드 생성을 사용하여 작성하는 것은 상당히 쉬울 것입니다.

func (p Pick) String() string {
  switch v := p.[var] {
  case A:
    return v.String()
  case B:
    return v.String()
  //etc
  }
}

계속해서 유형 어설션을 삭제했습니다. 추가해야 할 수도 있지만 제안서의 필수 부분은 아닙니다.

@ianlancetaylor 의 이전 의견 으로 돌아가고 싶습니다. 오류 처리에 대해 좀 더 생각한 후 새로운 관점을 갖게 되었기 때문입니다(특히, https://github.com/golang/go/issues/21161# 문제의견-320294933).

특히, 새로운 유형의 유형은 인터페이스 유형에서 얻을 수 없는 무엇을 제공합니까?

내가 보기에 sum-types의 주요 이점은 여러 값을 반환하는 것과 여러 값 중 하나를 반환하는 것을 구분할 수 있다는 것입니다. 특히 이러한 값 중 하나가 오류 인터페이스의 인스턴스일 때 그렇습니다.

우리는 현재 형식의 많은 기능을 가지고 있습니다

func F(…) (T, error) {
    …
}

같은 그들 중 일부, io.Reader.Read 및 io.Reader.Write 하는 반환 T 과 함께 error 다른 어느 반환 반면에하는 T 또는 error 이지만 둘 다 절대 아닙니다. 이전 스타일의 API의 경우 오류의 경우 T 를 무시하는 것은 종종 버그입니다(예: 오류가 io.EOF ). 후자 스타일의 경우 0이 아닌 T 반환하는 것은 버그입니다.

lint 포함한 자동화 도구는 오류가 nil이 아닌 경우 값이 올바르게 무시되는지(또는 무시되지 않는지) 특정 함수의 사용을 확인할 수 있지만 이러한 검사는 자연스럽게 임의의 함수로 확장되지 않습니다.

예를 들어 proto.Marshal 는 오류가 RequiredNotSetError 인 경우 "값 및 오류" 스타일이 되도록 의도되었지만 그렇지 않은 경우 "값 또는 오류" 스타일로 보입니다. 유형 시스템은 둘을 구별하지 않기 때문에 실수로 회귀를 도입하기 쉽습니다. 즉, 반환해야 할 때 값을 반환하지 않거나 반환하지 않아야 할 때 값을 반환하는 것입니다. 그리고 proto.Marshaler 구현은 문제를 더욱 복잡하게 만듭니다.

반면에 유형을 공용체로 표현할 수 있다면 훨씬 더 명시적일 수 있습니다.

type PartialMarshal struct {
    Data []byte // The marshalled value, ignoring unset required fields.
    MissingFields []string
}

func Marshal(pb Message) []byte | PartialMarshal | error

@ianlancetaylor , 나는 종이에 당신의 제안을 가지고 놀았습니다. 아래에 잘못된 것이 있으면 알려주실 수 있습니까?

주어진

var r interface{} restrict { uint, int } = 1

r 의 동적 유형은 int 이고

var _ interface{} restrict { uint32, int32 } = 1

불법입니다.

주어진

type R interface{} restrict { struct { n int }, etc }
type S struct { n int }

var _ R = S{} 는 불법입니다.

그러나 주어진

type R interface{} restrict { int, error }
type A interface {
  error
  foo()
}
type C struct { error }
func (C) foo() {}

var _ R = C{} 및 var _ R = A(C{}) 모두 합법입니다.

둘 다

interface{} restrict { io.Reader, io.Writer }

그리고

interface{} restrict { io.Reader, io.Writer, *bytes.Buffer }

동등합니다.

비슷하게,

interface{} restrict { error, net.Error }

와 동등하다

interface { Error() string }

주어진

type IO interface{} restrict { io.Reader, io.Writer }
type R interface{} restrict {
  interface{} restrict { int, uint },
  IO,
}

R 의 기본 유형은 다음과 같습니다.

interface{} restrict { io.Writer, uint, io.Reader, int }

편집: 이탤릭체의 작은 수정

@jimmyfrasche 위에서 내가 쓴 것이 제안이라고 말할 만큼 멀리 가지 않을 것입니다. 그것은 아이디어에 더 가깝습니다. 나는 당신의 의견에 대해 생각해야 하지만, 언뜻 보기에는 그럴듯해 보입니다.

@jimmyfrasche 의 제안은 Go에서 선택 유형이 작동할 것으로 직관적으로 예상하는 방식과 거의 비슷합니다. 나는 태그 값이 0에서 시작하는 경우 선택의 0 값에 대해 첫 번째 필드의 0 값을 사용하겠다는 그의 제안이 "0 값은 바이트를 0으로 만드는 것을 의미"와 함께 직관적이라는 점에 특히 주목할 가치가 있다고 생각합니다. 이미 언급되었습니다; 이 스레드는 지금까지 매우 깁니다...). 나는 또한 성능 영향(불필요한 할당 없음)을 좋아하며 그 선택은 인터페이스와 완전히 직교합니다(인터페이스를 포함하는 선택에서 전환하는 놀라운 동작 없음).

변경을 고려할 수 있는 유일한 것은 태그를 변경하는 것입니다. foo.X = 0 는 foo = Foo{X: 0} 수 있는 것 같습니다. 몇 개의 문자가 더 있지만 태그를 재설정하고 값을 0으로 만드는 것이 더 명확합니다. 이것은 사소한 부분이며 그의 제안이 있는 그대로 받아들여진다면 여전히 매우 기쁠 것입니다.

@ns-cweber 감사합니다. 하지만 저는 가치가 0인 행동을 인정할 수 없습니다. 아이디어는 잠시 동안 떠돌아다녔고 @rogpeppe 의 제안에서 이 스레드의 앞부분에 있었습니다(당신이 꽤 길게 지적했듯이). 내 변명은 당신이 준 것과 같았습니다.

foo.X = 0 대 foo = Foo{X: 0} 까지 내 제안은 실제로 둘 다 허용합니다. 당신이 할 수 있도록 선택의 필드 구조체 인 경우 후자에 유용 foo.X.Y = 0 대신 foo = Foo{X: image.Point{X: foo.[X].X, 0}} 런타임에 실패 할 수 있습니다 자세한 것 이외에.

또한 의미론에 대한 엘리베이터 피치를 강화하기 때문에 그대로 유지하는 것이 도움이 된다고 생각합니다. 한 번에 하나의 필드만 설정할 수 있는 구조체입니다.

있는 그대로 허용되지 않도록 차단할 수 있는 한 가지는 구조체에 선택을 포함하는 것이 작동하는 방식입니다. 요전에 구조체를 사용하는 데 미치는 다양한 효과를 간과했다는 사실을 깨달았습니다. 수리할 수 있다고 생각하지만 가장 좋은 수리가 무엇인지 완전히 확신할 수 없습니다. 가장 간단한 방법은 메서드만 상속하고 해당 필드에 도달하기 위해 이름으로 포함된 선택을 직접 참조해야 하며 구조체 필드와 선택 필드가 모두 있는 구조체를 피하기 위해 그 쪽으로 기울고 있다는 것입니다.

@jimmyfrasche 값이 0인 동작에 대해 수정

마지막으로 선택 임베딩에 대한 귀하의 간단한 제안은 제가 직감적으로 생각하는 것처럼 보입니다. 생각이 바뀌어도 기존 코드를 깨뜨리지 않고 단순한 제안에서 복잡한 제안으로 갈 수 있지만 그 반대는 사실이 아닙니다.

@ns-cweber

내가 foo.XY를 설정하는 것을 볼 수 있었지만 선택 필드가 자동으로 변경된다는 것을 깨닫지 못했습니다.

그것은 공정한 지적이지만 그 문제에 대해 언어 또는 모든 언어로 많은 것에 대해 말할 수 있습니다. 일반적으로 바둑에는 안전 레일이 있지만 안전 가위는 없습니다.

그것을 전복시키기 위해 최선을 다하지 않으면 일반적으로 당신을 보호하는 큰 일들이 많이 있습니다. 그러나 당신은 여전히 ​​당신이 무엇을 하고 있는지 알아야 합니다.

이런 실수를 하면 짜증이 날 수 있지만, "I set bar.X = 0 하지만 bar.Y = 0 를 설정하려고 했습니다."라고 가정했을 때와 크게 다르지 않습니다. foo 는 선택 유형입니다.

유사하게 i.Foo() , p.Foo() 및 v.Foo() 모두 동일하게 보이지만 i 가 nil 인터페이스인 경우 p nil 포인터이고 Foo 가 이 경우를 처리하지 않으면 처음 두 개는 패닉을 일으킬 수 있지만 v 가 값 메서드 수신기를 사용하는 경우에는 그렇게 할 수 없습니다(적어도 호출 자체에서는 아님) .

—

임베딩에 관해서는 나중에 느슨해지기 쉽다는 점에서 좋은 점이라 그냥 제안을 수정했습니다.

합계 유형에는 종종 값이 없는 필드가 있습니다. 예를 들어 database/sql 패키지에는 다음이 있습니다.

type NullString struct {
    String string
    Valid  bool // Valid is true if String is not NULL
}

합계 유형/선택/공집합이 있는 경우 다음과 같이 표현될 수 있습니다.

type NullString pick {
  Null   struct{}
  String string
}

이 경우 합계 유형은 구조체에 비해 분명한 이점이 있습니다. 나는 이것이 모든 제안에 예시로 포함할 가치가 있을 만큼 충분히 일반적인 용도라고 생각합니다.

Bikeshedding (미안), 나는 이것이 구문적 지원과 구조체 필드 임베딩 구문과의 불일치에 가치가 있다고 주장합니다.

type NullString union {
  Null
  String string
}

@neild

마지막 포인트 먼저 치기: 게시하기 전 마지막 순간 변경으로(어떤 의미에서든 엄격하게 요구 되지 않음), 필드 이름이 없는 명명된 유형(또는 명명된 유형에 대한 포인터)이 있는 경우 선택이 암시적 필드를 생성한다고 추가했습니다. 유형과 이름이 같습니다. 그것이 최선의 생각은 아닐지 모르지만 "이러한 유형 중 하나"의 일반적인 경우 중 하나를 큰 소란 없이 다룰 것 같았습니다. 마지막 예제를 작성할 수 있다고 가정하면 다음과 같습니다.

type Null = struct{} //though this puts Null in the same scope as NullString
type NullString pick {
  Null
  String string
}

그러나 요점으로 돌아가서 그렇습니다. 그것은 훌륭한 용도입니다. 실제로 type Stoplight pick { Stop, Slow, Go struct{} } 열거형을 빌드하는 데 사용할 수 있습니다. 이것은 const/iota faux-enum과 매우 유사합니다. 심지어 동일한 출력으로 컴파일됩니다. 이 경우의 주요 이점은 상태를 나타내는 숫자가 완전히 캡슐화되어 나열된 세 가지 이외의 상태에 넣을 수 없다는 것입니다.

불행히도 Stoplight 값을 생성하고 설정하는 데 다소 어색한 구문이 있습니다. 이는 이 경우에 악화됩니다.

light := Stoplight{Slow: struct{}{}}
light.Go = struct{}{}

다른 곳에서 제안된 것처럼 {} 또는 _ 를 struct{}{} 약어로 허용하면 도움이 될 것입니다.

많은 언어, 특히 함수형 언어는 레이블을 유형과 동일한 범위에 배치하여 이 문제를 해결합니다. 이것은 많은 복잡성을 생성하고 동일한 범위에 정의된 두 개의 선택이 필드 이름을 공유하는 것을 허용하지 않습니다.

그러나 필드 유형을 인수로 사용하는 선택에서 각 필드의 이름이 같은 함수를 생성하는 코드 생성기로 이 문제를 쉽게 해결할 수 있습니다. 또한 특수한 경우로 유형이 0인 경우 인수를 사용하지 않은 경우 Stoplight 예제의 출력은 다음과 같습니다.

func Stop() Stoplight {
  return Stoplight{Stop: struct{}{}}
}
func Slow() Stoplight {
  return Stoplight{Slow: struct{}{}}
}
func Go() Stoplight {
  return Stoplight{Go: struct{}{}}
}

NullString 예제의 경우 다음과 같습니다.

func Null() NullString {
  return NullString{Null: struct{}{}}
}
func String(s string) NullString {
  return NullString{String: s}
}

예쁘지는 않지만 go generate 떨어져 있고 매우 쉽게 인라인될 수 있습니다.

유형 이름을 기반으로 암시적 필드를 생성한 경우(유형이 다른 패키지의 유형이 아닌 경우) 또는 필드 이름을 공유하는 동일한 패키지에서 두 개의 선택으로 실행된 경우에는 작동하지 않지만 괜찮습니다. 제안은 즉시 모든 것을 수행하지는 않지만 많은 것을 가능하게 하고 프로그래머에게 주어진 상황에 가장 적합한 것을 결정할 수 있는 유연성을 제공합니다.

추가 구문 바이크쉐딩:

type NullString union {
  Null
  Value string
}

var _ = NullString{Null}
var _ = NullString{Value: "some value"}
var _ = NullString{Value} // equivalent to NullString{Value: ""}.

구체적으로 키가 포함되지 않은 요소 목록이 있는 리터럴은 설정할 필드의 이름을 지정하는 것으로 해석됩니다.

이것은 합성 리터럴의 다른 사용과 구문적으로 일치하지 않습니다. 다른 한편으로, 키가 없는 공용체 초기화 프로그램에 대한 합리적인 해석이 없기 때문에 (적어도 저에게는) 공용체/선택/합 유형의 맥락에서 합리적이고 직관적으로 보이는 사용법입니다.

@neild

이것은 합성 리터럴의 다른 사용과 구문적으로 일치하지 않습니다.

그것은 문맥상 이해가 되지만 나에게는 큰 부정적으로 보입니다.

또한 참고

var ns NullString // == NullString{Null: struct{}{}} == NullString{}
ns.String = "" // == NullString{String: ""}

를 처리하기위한 struct{}{} 내가 사용하고 경우 map[T]struct{} I 던져

var set struct{}

어딘가에 theMap[k] = set 하면 유사한 것이 선택과 함께 작동합니다.

추가 bikeshedding: 빈 유형(sum 유형의 컨텍스트에서)은 일반적으로 "null"이 아니라 "unit"으로 명명됩니다.

@bcmills 소타 .

함수형 언어에서 합계 유형을 생성할 때 해당 레이블은 실제로 해당 유형의 값을 생성하는 함수입니다(비록 컴파일러가 패턴 일치를 허용하는 것으로 알고 있는 "유형 생성자" 또는 "타이콘"으로 알려진 특수 함수).

data Bool = False | True

Bool 데이터 유형과 동일한 범위에 True 및 False , 각각 () -> Bool 서명이 있는 두 개의 함수를 만듭니다.

여기서 () 는 유형 발음 단위(단일 값만 있는 유형)를 작성하는 방법입니다. Go에서 이 유형은 다양한 방법으로 작성할 수 있지만 관용적으로 struct{} 로 작성됩니다.

따라서 생성자의 인수 유형 을 단위라고 합니다. 생성자의 이름 에 대한 관례는 일반적으로 이와 같은 옵션 유형으로 사용할 경우 None 이지만 도메인에 맞게 변경할 수 있습니다. 예를 들어 값이 데이터베이스에서 오는 경우 Null 는 좋은 이름입니다.

@bcmills

내가 보기에 sum-types의 주요 이점은 여러 값을 반환하는 것과 여러 값 중 하나를 반환하는 것을 구분할 수 있다는 것입니다. 특히 이러한 값 중 하나가 오류 인터페이스의 인스턴스일 때 그렇습니다.

대안적인 관점에서 저는 이것이 Go의 sum 유형의 주요 단점 이라고 봅니다.

많은 언어는 물론 어떤 값이나 오류를 반환하는 경우에 대해 합 유형을 사용하며 이는 잘 작동합니다. Go에 sum 유형이 추가되면 같은 방식으로 사용하고 싶은 큰 유혹이 있을 것입니다.

그러나 Go에는 이미 이러한 목적으로 여러 값을 사용하는 대규모 코드 생태계가 있습니다. 새 코드가 합계 유형을 사용하여 (값, 오류) 튜플을 반환하는 경우 해당 생태계는 단편화됩니다. 일부 작성자는 기존 코드와의 일관성을 위해 여러 반환을 계속 사용합니다. 일부 저자는 합계 유형을 사용합니다. 일부는 기존 API를 변환하려고 시도합니다. 어떤 이유로든 이전 Go 버전에 매달린 작성자는 새 API에 액세스할 수 없습니다. 그것은 엉망이 될 것이고, 나는 이득이 비용의 가치가 있기 시작할 것이라고 생각하지 않습니다.

새 코드가 합계 유형을 사용하여 (값, 오류) 튜플을 반환하는 경우 해당 생태계는 단편화됩니다.

Go 2에 합계 유형을 추가하고 균일하게 사용하면 문제가 단편화가 아닌 마이그레이션으로 축소됩니다. Go 1(값, 오류) API를 Go 2(값 | 오류)로 변환할 수 있어야 합니다. ) API 및 그 반대의 경우도 있지만 프로그램의 Go 2 부분에서 고유한 유형일 수 있습니다.

Go 2에 합계 유형을 추가하고 균일하게 사용하면

이것은 지금까지 본 것과는 상당히 다른 제안입니다. 표준 라이브러리를 광범위하게 리팩토링해야 하고 API 스타일 간의 변환을 정의해야 하는 등의 작업이 필요합니다. 이 경로로 이동하면 상당히 커집니다. 및 합계 유형의 설계와 관련하여 사소한 codicil로 API 전환에 대한 복잡한 제안.

의도는 Go 1과 Go 2가 동일한 프로젝트에서 원활하게 공존할 수 있도록 하는 것이므로 누군가가 "어떤 이유로" Go 1 컴파일러를 사용하지 못하고 2 라이브러리로 이동합니다. 그러나, 당신은 의존성이있는 경우 A 에 차례로 따라 달라집니다 B 및 B 같은 새로운 기능을 사용하여 업데이트 pick 자사의 API에, 그 휴식 것이 의존성 A 가 새 버전의 사용으로 업데이트하지 않는 한 B . A 는 B 공급하고 이전 버전을 계속 사용할 수 있지만 보안 버그 등으로 인해 이전 버전이 유지 관리되지 않거나 새 버전을 사용해야 하는 경우 B 직접 사용하고 어떤 이유로 프로젝트에 두 가지 버전을 사용할 수 없으므로 문제가 발생할 수 있습니다.

궁극적으로 여기서 문제는 언어 버전과 거의 관련이 없으며 기존 내보낸 함수의 서명을 변경하는 것과 더 관련이 있습니다. 추진력을 제공하는 새로운 기능이 될 것이라는 사실은 약간의 주의를 산만하게 합니다. 의도 허용하는 경우 기존의 API를 사용하도록 변경 pick 이전 버전과의 호환성을 깨지 않고, 다음 몇 가지 종류의 다리 구문이있을 필요가있을 수 있습니다. 예를 들어(완전히 빨갱이처럼):

type ReadResult pick(N int, Err error) {
    N
    PartialResult struct { N; Err }
    Err
}

컴파일러는 레거시 코드에서 액세스할 때 ReadResult 할 수 있으며 특정 변형에 필드가 없으면 0 값을 사용합니다. 다른 길로 가는 방법이나 그만한 가치가 있는지 잘 모르겠습니다. 같은 API를 template.Must 단지 오히려보다는 여러 값을 받아들이는 계속해야 할 수도 있습니다 pick 하고 차이를 만들기 위해 스플래에 의존하고 있습니다. 또는 다음과 같이 사용할 수 있습니다.

type ReadResult pick(N int, Err error) {
case Err == nil:
    N
default:
    PartialResult struct { N; Err }
case N == 0:
    Err
}

이 복잡한 일을하지만, API를 작성하는 방법을 변경하는 기능을 소개하는 세계를 파괴하지 않고 어떻게 전환에 대한 이야기를 필요로 어떻게 볼 수 있습니다. 브리지 구문이 필요하지 않은 방법이 있을 수 있습니다.

합계 유형에서 제품 유형(구조체, 다중 반환 값)으로 이동하는 것은 간단합니다. 값이 아닌 모든 것을 0으로 설정하기만 하면 됩니다. 제품 유형에서 합계 유형으로 이동하는 것은 일반적으로 잘 정의되어 있지 않습니다.

API가 제품 유형 기반 구현에서 합계 유형 기반 구현으로 원활하고 점진적으로 전환하려는 경우 가장 쉬운 경로는 합계 유형 버전에 실제 구현이 있고 제품 ​​유형 버전이 sum 유형 버전, 런타임 검사를 수행하려면 제품 공간으로의 모든 프로젝션이 필요합니다.

그것은 정말 추상적이므로 여기에 예가 있습니다

합계가 없는 버전 1

func Take(i interface{}) error {
  switch i.(type) {
  case int: //do something
  case string:
  default: return fmt.Errorf("invalid %T", i)
  }
}
func Give() (interface{}, error) {
   i := f() //something
   if i == nil {
     return nil, errors.New("whoops v:)v")
  }
  return i
}

합계가 있는 버전 2

type Value pick {
  I int
  S string
}
func TakeSum(v Value) {
  // do something
}
// Deprecated: use TakeSum
func Take(i interface{}) error {
  switch x := i.(type) {
  case int: TakeSum(Value{I: x})
  case string: TakeSum(Value{S: x})
  default: return fmt.Errorf("invalid %T", i)
  }
}
type ErrValue pick {
  Value
  Err error
}
func GiveSum() ErrValue { //though honestly (Value, error) is fine
  return f()
}
// Deprecated: use GiveSum
func Give() (interface{}, error) {
  switch v := GiveSum().(var) {
  case Value:
    switch v := v.(var) {
    case I: return v, nil
    case S: return v, nil
    }
  case Err:
    return nil, v
  }
}

버전 3은 Give/Take를 제거합니다.

버전 4는 GiveSum/TakeSum의 구현을 Give/Take로 이동하고 GiveSum/TakeSum이 Give/Take를 호출하고 GiveSum/TakeSum을 더 이상 사용하지 않도록 합니다.

버전 5는 GiveSum/TakeSum을 제거합니다.

예쁘거나 빠르지는 않지만 비슷한 성격의 다른 대규모 파괴와 동일하며 언어에서 추가로 필요한 것은 없습니다.

(대부분) sum 유형의 유틸리티는 컴파일 타임에 유형 인터페이스 유형에 대한 할당을 제한하는 메커니즘으로{} 실현될 수 있다고 생각합니다.

꿈에서 그것은 다음과 같이 보입니다.

type T1 switch {T2,T3} // only nil, T2 and T3 may be assigned to T1
type T2 struct{}
type U switch {} // only nil may be assigned to U
type V switch{interface{} /* ,... */} // V equivalent to interface{}
type Invalid switch {T2,T2} // only uniquely named types
type T3 switch {int,uint} // switches can contain switches but... 

... 스위치 유형이 명시적으로 정의되지 않은 유형이라고 주장하는 것도 컴파일 타임 오류가 됩니다.

var t1 T1
i,ok := t1.(int) // T1 can't be int, only T2 or T3 (but T3 could be int)
switch t := t1.(type) {
    case int: // compile error, T1 is just nil, T2 or T3
}

go vet는 T3와 같은 유형에 대한 모호한 상수 할당에 대해 잉어하지만 모든 의도와 목적(런타임 시)에 대해 var x T3 = 32 는 var x interface{} = 32 입니다. 스위치나 조랑말과 같은 이름의 패키지에 내장된 일부 미리 정의된 스위치 유형도 그루비할 수 있습니다.

@j7b , @ianlancetaylor 는 https://github.com/golang/go/issues/19412#issuecomment -323256891에서 비슷한 아이디어를 제안했습니다.

나는 나중에 https://github.com/golang/go/issues/19412#issuecomment -325048452에 이것의 논리적 결과가 될 것이라고 생각하는 것을 게시했습니다.

유사성을 감안할 때 많은 부분이 동일하게 적용될 것 같습니다.

그런 것이 작동한다면 정말 좋을 것입니다. 인터페이스에서 인터페이스+제한으로 쉽게 전환할 수 있습니다(특히 Ian의 구문: 인터페이스로 빌드된 기존 의사 합계 끝에 restrict 를 붙이면 됩니다). 런타임 시 인터페이스와 본질적으로 동일하고 대부분의 작업은 불변량이 깨졌을 때 컴파일러가 추가 오류를 내보내도록 하기 때문에 구현하기 쉽습니다.

그러나 나는 그것을 작동시키는 것이 가능하다고 생각하지 않습니다.

너무 가까이가 적합처럼 보이지만 당신이 확대하고 정렬 밖으로 조금 밀어하고 뭔가 다른 팝을 줄 수 있도록 그냥, 꽤 괜찮 아니라는 것을 모든 라인까지. 복구를 시도할 수 있지만 인터페이스와 매우 유사하지만 이상한 경우에는 다르게 동작하는 것을 얻게 됩니다.

어쩌면 내가 뭔가를 놓치고 있는 것 같다.

케이스가 반드시 분리되어 있지 않아도 괜찮다면 제한된 인터페이스 제안에 아무런 문제가 없습니다. 두 인터페이스 유형(예 io.Reader / io.Writer ) 간의 결합이 분리되지 않는다는 것이 당신만큼 놀라운 일은 아니라고 생각합니다. interface{} 할당된 값이 io.Reader 또는 io.Writer 로 저장되었는지 여부를 결정할 수 없다는 사실과 완전히 일치합니다. 각 경우가 구체적인 유형인 한 분리된 공용체를 구성할 수 있다는 사실은 완벽하게 적절해 보입니다.

단점은 공용체가 제한된 인터페이스인 경우 해당 인터페이스에서 직접 메소드를 정의할 수 없다는 것입니다. 그리고 제한된 인터페이스 유형인 경우 pick 유형이 제공하는 보장된 직접 저장소를 얻지 못합니다. 이러한 추가 이점을 얻기 위해 언어에 고유한 종류를 추가하는 것이 가치가 있는지 여부는 확실하지 않습니다.

type T switch {io.Reader,io.Writer} 대한 @jimmyfrasche ReadWriter를 T에 할당하는 것은 괜찮지만 T가 io.Reader 또는 Io.Writer라고 주장할 수만 있습니다. io.Reader 또는 io.Writer를 주장하려면 다른 주장이 필요합니다. 유용한 주장인 경우 스위치 유형에 추가하도록 권장해야 하는 ReadWriter.

@stevenblenkinsop 당신은 방법 없이 선택 제안 을 정의할 수 있습니다. 실제로 메서드와 암시적 필드 이름을 제거하면 선택 임베딩을 허용할 수 있습니다. (분명히 내 생각에는 메서드와 훨씬 덜하지만 암시적 필드 이름이 더 유용한 트레이드 오프입니다.)

그리고 반면에 @ianlancetaylor 의 구문은 다음을 허용합니다.

type IR interface {
  Foo()
  Bar()
} restrict { A, B, C }

A , B , C 각각에 Foo 및 Bar 메서드가 있는 한 컴파일됩니다 C 약 nil 값).

편집: 이탤릭체로 된 설명

나는 어떤 형태의 _restricted interface_가 유용할 것이라고 생각하지만, 나는 그 구문에 동의하지 않는다. 여기 내가 제안하는 것이 있습니다. 반드시 공통 동작을 갖지 않는 도메인 관련 개체를 그룹화하는 대수 데이터 유형과 유사한 방식으로 작동합니다.

//MyGroup can be any of these. It can contain other groups, interfaces, structs, or primitive types
type MyGroup group {
   MyOtherGroup
   MyInterface
   MyStruct
   int
   string
   //..possibly some other types as well
}

//type definitions..
type MyInterface interface{}
type MyStruct struct{}
//etc..

func DoWork(item MyGroup) {
   switch t:=item.(type) {
      //do work here..
   }
}

이 접근 방식은 기존의 빈 인터페이스 interface{} 접근 방식에 비해 몇 가지 이점이 있습니다.

• 함수를 사용할 때 정적 유형 검사
• 사용자는 함수 구현을 볼 필요 없이 함수 서명만으로 어떤 유형의 인수가 필요한지 유추할 수 있습니다.

빈 인터페이스 interface{} 는 관련된 유형의 수를 알 수 없는 경우에 유용합니다. 런타임 검증에 의존할 수 밖에 없습니다. 반면에 유형 수가 제한되고 컴파일 시간에 알려지면 컴파일러가 우리를 돕도록 하지 않겠습니까?

@henryas 저는 더 유용한 비교가 현재 권장되는 (개방형) 합계 유형을 수행하는 방법이라고 생각합니다. 비어 있지 않은 인터페이스(내
나는 당신의 주장이 중요한 방식으로 그것에 적용된다고 생각하지 않습니다.

다음은 Go protobuf에 대한 경험 보고서입니다.

• proto2 구문은 0 값과 설정되지 않은 값이 구별되는 유형인 "선택적" 필드를 허용합니다. 현재 솔루션은 포인터(예: *int )를 사용하는 것입니다. 여기서 nil 포인터는 설정되지 않은 것을 나타내고 set 포인터는 실제 값을 가리킵니다. 원하는 것은 값에 액세스하기만 하면 되는 일반적인 경우를 복잡하게 하지 않고 0과 설정되지 않은 것을 구별할 수 있게 하는 접근 방식입니다(여기서 0 값은 설정되지 않은 경우 괜찮음).

  • 이것은 추가 할당으로 인해 비효율적입니다(비록 구현에 따라 조합이 동일한 운명을 겪을 수 있지만).
  • 포인터를 지속적으로 확인해야 가독성이 떨어지기 때문에 이것은 사용자에게 고통스러운 일입니다(protos에서 0이 아닌 기본값은 확인이 필요하다는 것을 의미할 수 있지만...).

• proto 언어는 proto 버전의 sum 유형인 "one of"를 허용합니다. 현재 취하는 접근 방식은 다음과 같습니다( 전체 예 ).

  • 숨겨진 메소드로 인터페이스 유형 정의(예: type Communique_Union interface { isCommunique_Union() } )
  • Union에서 허용되는 각각의 가능한 Go 유형에 대해 래퍼 구조체를 정의합니다. 래퍼 구조체는 각 유형에 isCommunique_Union 메서드가 있는 허용된 각 유형(예: type Communique_Number struct { Number int32 } )을 래핑하는 것뿐입니다.
  • 래퍼가 할당을 유발하기 때문에 이 또한 비효율적입니다. 가장 큰 값(슬라이스)이 24B를 넘지 않는다는 것을 알고 있기 때문에 sum 유형이 도움이 될 것입니다.

@henryas 저는 더 유용한 비교가 현재 권장되는 (개방형) 합계 유형을 수행하는 방법이라고 생각합니다. 비어 있지 않은 인터페이스(내
나는 당신의 주장이 중요한 방식으로 그것에 적용된다고 생각하지 않습니다.

다음과 같이 개체를 인터페이스로 전달할 수 있도록 내보내기되지 않은 더미 메서드를 개체에 추가하는 것을 의미합니까?

type MyInterface interface {
   belongToMyInterface() //dummy method definition
}

type MyObject struct{}
func (MyObject) belongToMyInterface(){} //dummy method

나는 그것이 전혀 권장되어야한다고 생각하지 않습니다. 해결책이라기보다는 해결 방법에 가깝습니다. 저는 개인적으로 빈 메소드와 불필요한 메소드 정의가 있는 것보다 정적 유형 검증을 포기하고 싶습니다.

다음은 _dummy method_ 접근 방식의 문제입니다.

• 개체와 인터페이스를 어지럽히는 불필요한 메서드 및 메서드 정의.
• 새로운 _group_이 추가될 때마다 개체의 구현을 수정해야 합니다(예: 더미 메서드 추가). 이것은 잘못된 것입니다(다음 요점 참조).
• 대수 데이터 유형(또는 동작이 아닌 _domain_을 기반으로 하는 그룹화)은 도메인에 따라 다릅니다 . 도메인에 따라 개체 관계를 다르게 봐야 할 수 있습니다. 회계사는 창고 관리자와 다르게 문서를 그룹화합니다. 이 그룹화는 개체 자체가 아니라 개체의 소비자와 관련됩니다. 객체는 소비자의 문제에 대해 알 필요가 없으며 알 필요도 없습니다. 송장이 회계에 대해 알아야 할 사항이 있습니까? 그렇지 않은 경우 회계 규칙이 변경될 때마다 _(예: 새 문서 그룹화 적용)_ 구현을 변경해야 하는 이유는 무엇입니까? _dummy method_ 접근 방식을 사용하여 개체를 소비자 도메인에 연결하고 소비자 도메인에 대해 중요한 가정을 합니다. 당신은 이것을 할 필요가 없습니다. 이것은 빈 인터페이스 interface{} 접근 방식보다 훨씬 더 나쁩니다. 더 나은 접근 방식이 있습니다.

@henryas

나는 당신의 세 번째 요점이 강력한 주장이라고 생각하지 않습니다. 회계사가 개체 관계를 다르게 보려는 경우 회계사는 사양에 맞는 고유한 인터페이스를 만들 수 있습니다. 인터페이스에 private 메소드를 추가한다고 해서 이를 만족하는 구체적인 유형이 다른 곳에서 정의된 인터페이스의 하위 집합과 호환되지 않는다는 의미는 아닙니다.

Go 파서는 이 기술을 많이 사용하며 솔직히 말해서 선택이 언어로 선택을 구현하는 것을 보증할 정도로 패키지를 훨씬 더 좋게 만드는 것을 상상할 수 없습니다.

@as 내 요점은 새로운 _관계 보기_가 생성될 때마다 이 보기에 대한 특정 조정을 위해 관련 구체적인 개체를 업데이트해야 한다는 것입니다. 그렇게 하기 위해 개체는 종종 소비자의 도메인에 대해 특정 가정을 해야 하기 때문에 잘못된 것 같습니다. 객체와 소비자가 밀접하게 관련되어 있거나 Go 파서의 경우와 같이 동일한 도메인 내에 거주하는 경우에는 그다지 중요하지 않을 수 있습니다. 그러나 객체가 다른 여러 도메인에서 사용되는 기본 기능을 제공하는 경우 문제가 됩니다. 이제 개체는 _dummy method_ 접근 방식이 작동하기 위해 다른 모든 도메인에 대해 약간 알아야 합니다.

객체에 연결된 많은 빈 메서드가 있고, 이러한 메서드를 필요로 하는 인터페이스가 별도의 도메인/패키지/계층에 있기 때문에 이러한 메서드가 필요한 이유가 독자에게 명확하지 않습니다.

인터페이스를 통한 개방 합계 접근 방식이 합계를 쉽게¹ 사용할 수 없다는 점은 충분히 공평합니다. 명시적 합계 유형은 분명히 합계를 더 쉽게 만들 수 있습니다. 그러나 "합계 유형이 유형 안전성을 제공합니다"와는 매우 다른 주장입니다. 필요한 경우 오늘날에도 유형 안전성을 얻을 수 있습니다.

나는 여전히 다른 언어로 구현된 폐쇄 총액의 두 가지 단점을 봅니다. 하나는 대규모 분산 개발 프로세스에서 이를 발전시키는 어려움입니다. 그리고 두, 나는 이동이 매우 강력한 타입 시스템을 가지고하지 않는 것처럼 그들이 그 종류의 코딩 스타일을 장려하고 대신 코드 프로그램으로, 유형 시스템에 전원을 추가하고 난 것을 생각 - 나는 문제가 혜택을 누릴 수 있음을 느낄 때 더 강력한 유형 시스템, 더 강력한 언어(예: Haskell 또는 Rust)로 이동합니다.

즉, 적어도 두 번째 것은 확실히 선호하는 것 중 하나이며 동의하더라도 단점이 장점을 능가하는 것으로 간주되는지 여부는 개인 취향에 달려 있습니다. 닫힌 합계 유형 없이는 유형이 안전한 합계를 얻을 수 없다는 점을 지적하고 싶었습니다.

[1] 특히, 쉽지는 않지만 여전히 가능합니다 . 예를 들어 다음을 수행할 수 있습니다.

type Node interface {
    node()
}

type Foo struct {
    bar.Baz
}

func (foo) node() {}

@메로비우스
나는 당신의 두 번째 단점에 동의하지 않습니다. 표준 라이브러리에는 합계 유형의 이점이 있지만 이제 빈 인터페이스와 패닉을 사용하여 구현되는 곳이 많다는 사실은 이것이 부족하면 코딩에 해를 끼친다는 것을 보여줍니다. 물론 사람들은 그런 코드가 처음에 작성되었기 때문에 문제가 없고 합계 유형이 필요하지 않다고 말할 수도 있지만 그 논리의 어리석음은 함수에 대해 다른 유형이 필요하지 않다는 것입니다. 서명하고 대신 빈 인터페이스를 사용해야 합니다.

현재 합계 유형을 나타내기 위해 일부 방법과 함께 인터페이스를 사용하는 것과 관련하여 한 가지 큰 단점이 있습니다. 암시적으로 구현되기 때문에 해당 인터페이스에 사용할 수 있는 유형을 모릅니다. 적절한 합계 유형을 사용하면 유형 자체에서 실제로 사용할 수 있는 유형을 정확히 설명했습니다.

나는 당신의 두 번째 단점에 동의하지 않습니다.

"합계 유형은 유형을 사용한 프로그래밍을 권장합니다"라는 말에 동의하지 않습니까, 아니면 그것이 단점이라는 데 동의하지 않습니까? 당신이 첫 번째 의견에 동의하지 않는 것 같지 않기 때문에(귀하의 의견은 기본적으로 이에 대한 재주장입니다) 두 번째 의견에 대해서는 위의 선호도에 달려 있음을 인정했습니다.

표준 라이브러리에는 합계 유형의 이점이 있지만 이제 빈 인터페이스와 패닉을 사용하여 구현되는 곳이 많다는 사실은 이것이 부족하면 코딩에 해를 끼친다는 것을 보여줍니다. 물론 사람들은 그런 코드가 처음에 작성되었기 때문에 문제가 없고 합계 유형이 필요하지 않다고 말할 수도 있지만 그 논리의 어리석음은 함수에 대해 다른 유형이 필요하지 않다는 것입니다. 서명하고 대신 빈 인터페이스를 사용해야 합니다.

이런 종류의 흑백 논쟁 은 실제로 도움이 되지 않습니다 . 나는 합계 유형이 어떤 경우에는 고통을 줄일 것이라는 데 동의합니다. 타입 시스템은 더 강력하게 모든 변화는 어떤 경우에는 통증을 감소시킬 것이다 - 그러나 또한 어떤 경우에는 통증의 원인이됩니다. 따라서 질문은 다른 것보다 중요합니다(즉, 어느 정도 선호도의 문제).

토론은 우리가 파이썬과 같은 유형 시스템(유형 없음)을 원하는지 아니면 coq-esque 유형 시스템(모든 것에 대한 정확성 증명)을 원하는지에 대한 것이어서는 안 됩니다. 논의는 "합계 유형의 이점이 단점보다 더 중요함"이어야 하며 둘 모두를 인정하는 것이 도움이 됩니다.

FTR, 저는 개인적으로 공개 합계 유형에 반대하지 않을 것임을 다시 강조하고 싶습니다(즉, 모든 합계 유형에는 암시적 또는 명시적 "SomethingElse"-케이스가 있음). (대부분 진화하기 어렵다는) 기술적인 장점도 대부분 제공합니다(정적 유형 검사, 언급한 문서, 다른 패키지의 유형을 열거할 수 있습니다...).

그러나 나는 또한 공개 합계가 a) 일반적으로 합계 유형을 추구하는 사람들에게 만족스러운 타협이 아닐 것이며 b) 아마도 Go 팀에 포함되는 것을 보증할 만큼 충분히 큰 이점으로 간주되지 않을 것이라고 가정합니다. 그러나 나는 이러한 가정 중 하나 또는 둘 모두에서 잘못된 것으로 입증될 준비가 되어 있습니다. :)

질문 하나 더:

표준 라이브러리에는 합계 유형의 이점을 얻을 수 있는 위치가 많이 있다는 사실

나는 표준 라이브러리에서 중요한 이점이 있다고 말할 수 있는 두 곳만 생각할 수 있습니다. 바로 Reflect 및 go/ast입니다. 그리고 거기에서도 패키지가 없어도 잘 작동하는 것 같습니다. 이 기준점에서 "풍부한"과 "엄청난"이라는 단어는 과장된 것처럼 보이지만 물론 합법적인 장소를 많이 보지 못할 수도 있습니다.

database/sql/driver.Value 는 합계 유형이 되는 이점이 있습니다(#23077 참조).
https://godoc.corp.google.com/pkg/database/sql/driver#값

그러나 database/sql.Rows.Scan 의 더 많은 공용 인터페이스는 기능 손실 없이는 아닙니다. 스캔은 기본 유형이 int 인 값을 읽을 수 있습니다. 대상 매개변수를 합계 유형으로 변경하려면 입력을 유한 유형 세트로 제한해야 합니다.
https://godoc.corp.google.com/pkg/database/sql#Rows.Scan

@메로비우스

나는 개방형 합계 유형(즉, 모든 합계 유형에는 암시적 또는 명시적 "SomethingElse"-케이스가 있음)에 반대하지 않을 것입니다. 이는 대부분의 기술적인 단점을 완화할 것이기 때문입니다(대부분 진화하기 어렵다)

폐쇄 총액의 "진화하기 어려운" 문제를 완화하는 다른 옵션이 적어도 두 가지 있습니다.

하나는 실제로 합계의 일부가 아닌 유형에 대한 일치를 허용하는 것입니다. 그런 다음 합계에 구성원을 추가하려면 먼저 새 구성원과 일치하도록 해당 소비자를 업데이트하고 소비자가 업데이트된 후에만 해당 구성원을 실제로 추가합니다.

또 다른 방법은 "불가능한" 구성원을 허용하는 것입니다. 즉, 일치 항목에서는 명시적으로 허용되지만 실제 값에서는 명시적으로 허용되지 않는 구성원입니다. 합계에 구성원을 추가하려면 먼저 불가능한 구성원으로 추가한 다음 소비자를 업데이트하고 마지막으로 새 구성원을 가능하게 변경합니다.

database/sql/driver.Value 는 합계 유형이 되는 이점이 있을 수 있습니다.

동의합니다. 그것에 대해 몰랐습니다. 감사 해요 :)

하나는 실제로 합계의 일부가 아닌 유형에 대한 일치를 허용하는 것입니다. 그런 다음 합계에 구성원을 추가하려면 먼저 새 구성원과 일치하도록 해당 소비자를 업데이트하고 소비자가 업데이트된 후에만 해당 구성원을 실제로 추가합니다.

흥미로운 솔루션입니다.

@Merovius 인터페이스는 본질적으로 무한합 유형의 제품군입니다. 무한이든 아니든 모든 합계 유형에는 default: 케이스가 있습니다. 그러나 유한 합계 유형이 없으면 default: 는 이에 대해 알지 못하는 유효한 경우 또는 프로그램 어딘가에 버그인 잘못된 경우를 의미합니다. 유한 합계를 사용하면 전자일 뿐 후자는 절대 아닙니다.

json.Token 및 sql.Null* 유형은 다른 정식 예입니다. go/types는 go/ast와 같은 방식으로 이점을 얻을 수 있습니다. 내부 상태의 도메인을 제한하여 복잡한 배관을 디버깅하고 테스트하는 것이 더 쉬웠을 내보낸 API에 없는 많은 예가 있다고 생각합니다. 일반 라이브러리의 공개 API에서 자주 등장하지 않는 내부 상태 및 애플리케이션 제약 조건에 가장 유용하지만 가끔 사용하기도 합니다.

개인적으로 나는 합계 유형이 Go에게 충분한 추가 전력을 제공하지만 너무 많이는 제공하지 않는다고 생각합니다. Go 유형 시스템은 이미 매우 훌륭하고 유연하지만 단점이 있습니다. 유형 시스템에 추가된 Go2는 이미 존재하는 것만큼 많은 전력을 제공하지 않을 것입니다. 필요한 것의 80-90%가 이미 제자리에 있습니다. 내 말은, 제네릭조차도 근본적으로 새로운 것을 하도록 허용하지 않을 것입니다. 즉, 이미 하고 있는 일을 더 안전하고, 더 쉽고, 더 성능 좋게, 더 나은 도구를 사용할 수 있는 방식으로 할 수 있습니다. 합계 유형은 유사합니다.

합계 유형 스위치에 대해 관련 없는 기본값(모든 경우 + 기본값이 허용됨)을 허용하고 컴파일러가 완전성을 강제하지 않는 경우(린터는 가능하지만) 합계에 사례를 추가하는 것은 간단합니다. ) 다른 공개 API를 변경하는 것과 같습니다.

json.Token 및 sql.Null* 유형은 다른 정식 예입니다.

토큰 - 물론입니다. AST 문제의 또 다른 인스턴스(기본적으로 모든 파서는 합계 유형의 이점을 얻음).

하지만 sql.Null*에 대한 이점은 보이지 않습니다. 제네릭이 없으면(또는 "마법 같은" 제네릭 선택적 내장 기능을 추가하면) 여전히 유형이 있어야 하며 type NullBool enum { Invalid struct{}; Value Int } 와 type NullBool struct { Valid bool; Value Int } 사이에 큰 차이가 없어 보입니다. 예, 차이가 있다는 것을 알고 있지만, 그 차이는 아주 작습니다.

합계 유형 스위치에 대해 관련 없는 기본값(모든 경우 + 기본값이 허용됨)을 허용하고 컴파일러가 완전성을 강제하지 않는 경우(린터는 가능하지만) 합계에 사례를 추가하는 것은 간단합니다. ) 다른 공개 API를 변경하는 것과 같습니다.

위 참조. 그것들은 제가 오픈 썸이라고 부르는 것입니다. 저는 그것들에 덜 반대합니다.

그것들은 제가 오픈 썸이라고 부르는 것입니다. 저는 그것들에 덜 반대합니다.

내 구체적인 제안은 https://github.com/golang/go/issues/19412#issuecomment -323208336이며 개방에 대한 귀하의 정의를 만족시킬 수 있다고 생각하지만 여전히 약간 거칠고 아직 더 많은 것이 있다고 확신합니다. 제거하고 연마하십시오. 특히 나는 모든 사례가 나열되어 있어도 기본 사례가 허용되는지 명확하지 않아 방금 업데이트했습니다.

선택적 유형은 합계 유형의 킬러 앱이 아니라는 데 동의했습니다. 그들은 꽤 훌륭하고 제네릭을 정의하는 것으로 지적했듯이

type Nullable(T) pick { // or whatever syntax (on all counts)
  Null struct{}
  Value T
}

한 번 모든 경우를 다루는 것이 좋습니다. 그러나 당신이 지적했듯이 우리는 제네릭 제품(구조체)에서도 동일한 작업을 수행할 수 있습니다. 유효하지 않은 상태인 Valid = false, Value != 0이 있습니다. 이 시나리오에서는 1 + T만큼 작지 않더라도 2 ⨯ T가 작기 때문에 문제를 일으키는 경우 근절하기 쉽습니다.

물론 케이스가 많고 불변량이 겹치는 더 복잡한 합계라면 방어적 프로그래밍으로도 실수를 하기 쉽고 실수를 발견하기가 더 어려워지므로 불가능한 일을 아예 컴파일하지 않는 것으로 만드는 것은 많은 머리카락을 절약할 수 있습니다. 당기는.

토큰 - 물론입니다. AST 문제의 또 다른 인스턴스(기본적으로 모든 파서는 합계 유형의 이점을 얻음).

나는 약간의 입력을 받고, 약간의 처리를 하고, 약간의 출력을 생성하는 많은 프로그램을 작성합니다. 그리고 저는 일반적으로 이것을 재귀적으로 많은 패스로 나누어 입력을 케이스로 나누고 그 케이스를 기반으로 변환합니다. 원하는 출력. 나는 문자 그대로 파서를 작성하고 있지 않을 수도 있지만(물론 재미있기 때문에 때때로 그렇습니다!) 하지만 AST 문제는 당신이 말했듯이 많은 코드에 적용된다는 것을 알았습니다. 특히 너무 많은 이상한 비즈니스 로직을 다룰 때 그렇습니다. 내 작은 머리에 맞는 요구 사항과 엣지 케이스.

내가 일반 라이브러리를 작성할 때 ETL을 수행하거나 기발한 보고서를 작성하거나 상태 X의 사용자가 Z로 표시되지 않은 경우 작업 Y가 발생하도록 하는 것만큼 자주 API에 나타나지 않습니다. 비록 10분 디버그를 1초로 줄이는 경우에도 내부 상태를 제한할 수 있는 곳을 찾았지만 "오 컴파일러가 내가 틀렸다고 말했다"고 합니다.

Go를 사용하면 특히 합계 유형을 사용하는 곳은 한 고루틴에 3개의 채널을 제공하고 다른 고루틴에 2개의 채널을 제공해야 하는 많은 채널을 선택하는 고루틴입니다. 그것은 나를 사용할 수 있도록에서 무슨 일이 일어나고 있는지 추적하는 데 유용한 chan pick { a A; b B; c C } 이상 chan A , chan B , chan C 비록 chan stuct { kind MsgKind; a A; b B; c C } 수 추가 공간과 더 적은 유효성 검사 비용으로 작업을 신속하게 수행하십시오.

새로운 유형 대신에 기존 인터페이스 유형 전환 기능에 추가된 컴파일 시간 유형 목록 검사는 어떻습니까?

func main() {
    if FlipCoin() == false {
        printCertainTypes(FlipCoin(), int(5))
    } else {
        printCertainTypes(FlipCoin(), string("5"))
    }
}

// this function compiles with main
func printCertainTypes(flip bool, in interface{}) {
    if flip == false {
        switch v := in.(type) {
        case int:
            fmt.Printf(“integer %v\n”, v)
        default:
            fmt.Println(v)
        }
    } else {
        switch v := in.(type) {
        case int:
            fmt.Printf(“integer %v\n”, v)
        case string:
            fmt.Printf(“string %v\n”, v)
        }
    }
}

// this function compiles with main
func printCertainTypes(flip bool, in interface{}) {
    switch v := in.(type) {
    case int:
        fmt.Printf(“integer %v\n”, v)   
    case bool:
        fmt.Printf(“bool %v\n”, v)
    }
    fmt.Println(flip)
    switch v := in.(type) {
    case string:
        fmt.Printf(“string %v\n”, v)
    case bool:
        fmt.Printf(“bool 2 %v\n”, v)
    }
}

// this function emits a type switch not complete error when compiled with main
func printCertainTypes(flip bool, in interface{}) {
    if flip == false {
        switch v := in.(type) {
        case int:
            fmt.Printf(“integer %v\n”, v)
        case bool:
            fmt.Printf(“bool %v\n”, v)
        }
    } else {
        switch v := in.(type) {
        case string:
            fmt.Printf(“string %v\n”, v)
        case bool:
            fmt.Printf(“bool %v\n”, v)
        }
    }
}

// this function emits a type switch not complete error when compiled with main
func printCertainTypes(flip bool, in interface{}) {
    fmt.Println(flip)
    switch v := in.(type) {
    case int:
        fmt.Printf(“integer %v\n”, v)
    case bool:
        fmt.Printf(“bool %v\n”, v)
    }
}

공정하게, 우리는 현재 유형 시스템에서 합계 유형을 근사화하는 방법을 탐색하고 장단점을 비교해야 합니다. 다른 것이 없으면 비교를 위한 기준선을 제공합니다.

표준 수단은 내보내지 않고 아무것도 하지 않는 메서드를 태그로 사용하는 인터페이스입니다.

이에 대한 한 가지 주장은 합계의 각 유형에 이 태그가 정의되어 있어야 한다는 것입니다. 이것은 엄밀히 말하면 사실이 아닙니다. 적어도 구조체인 멤버의 경우에는 다음과 같이 할 수 있습니다.

type Sum interface { sum() }
type sum struct{}
func (sum) sum() {}

구조체에 너비가 0인 태그를 포함하기만 하면 됩니다.

래퍼를 도입하여 합계에 외부 유형을 추가할 수 있습니다.

type External struct {
  sum
  *pkg.SomeType
}

이것은 약간 불쾌하지만.

합계의 모든 멤버가 공통 동작을 공유하는 경우 인터페이스 정의에 해당 메서드를 포함할 수 있습니다.

이와 같은 구성은 유형이 합계에 있다고 말하지만 그 합계에 없는 것은 말할 수 없습니다. 필수 nil 케이스 외에도 동일한 임베딩 트릭을 다음과 같은 외부 패키지에서 사용할 수 있습니다.

import "p"
var member struct {
  p.Sum
}

패키지 내에서 컴파일되지만 불법인 값의 유효성을 검사하도록 주의해야 합니다.

런타임에 일부 유형 안전성을 복구하는 다양한 방법이 있습니다. 나는 다음과 같은 func와 결합된 sum 인터페이스의 정의에 valid() error 메소드를 포함하는 것을 발견했습니다.

func valid(s Sum) error {
  switch s.(type) {
  case nil:
    return errors.New("pkg: Sum must be non-nil")
  case A, B, C, ...: // listing each valid member
    return s.valid()
  }
  return fmt.Errorf("pkg: %T is not a valid member of Sum")
}

한 번에 두 종류의 유효성 검사를 처리할 수 있으므로 유용합니다. 항상 유효한 멤버의 경우 다음을 사용하여 일부 상용구를 피할 수 있습니다.

type alwaysValid struct{}
func (alwaysValid) valid() error { return nil }

이 패턴에 대한 더 일반적인 불만 중 하나는 godoc에서 합계의 구성원 자격을 명확하게 하지 않는다는 것입니다. 또한 멤버를 제외할 수 없고 어쨌든 유효성을 검사해야 하므로 이를 우회하는 간단한 방법이 있습니다. 즉, 더미 메서드를 내보내는 것입니다.
대신에,

//A Node is one of (list of types).
type Node interface { node() }

쓰다

//A Node is only valid if it is defined in this package.
type Node interface { 
  //Node is a dummy method that signifies that a type is a Node.
  Node()
}

우리는 누군가가 Node 를 만족시키는 것을 막을 수 없으므로 그들이 무엇을 하는지 알릴 수 있습니다. 어떤 유형이 Node (중앙 목록 없음)를 충족하는지 한 눈에 명확하게 알 수는 없지만 현재 보고 있는 특정 유형이 Node 충족하는지 여부는 분명합니다.

이 패턴은 합계에 있는 대부분의 유형이 동일한 패키지에 정의되어 있을 때 유용합니다. 아무도 없을 경우, 공통의 의지는 폴백입니다 interface{} 같은 json.Token 또는 driver.Value . 우리는 각각에 대한 래퍼 유형과 함께 이전 패턴을 사용할 수 있지만 결국에는 interface{} 만큼 많이 표시되므로 의미가 거의 없습니다. 이러한 값이 패키지 외부에서 올 것으로 예상하면 정중하게 팩토리를 정의할 수 있습니다.

//Sum is one of int64, float64, or bool.
type Sum interface{}
func New(v interface{}) (Sum, error) {
  switch v.(type) {
  case nil:
    return errors.New("pkg: Sum must be non-nil")
  case int64, float64, bool:
     return v
  }
  return fmt.Printf("pkg: %T is not a valid member of Sum")
}

합계의 일반적인 용도는 "값 없음"과 "0일 수 있는 값"을 구별해야 하는 선택적 유형에 대한 것입니다. 두 가지 방법이 있습니다.

*T nil 포인터로 값이 없음을 나타내고 nil이 아닌 포인터를 역참조한 결과로 값이 0이 될 수도 있습니다.

이전 인터페이스 기반 근사 및 제한이 있는 인터페이스로 합계 유형을 구현하기 위한 다양한 제안과 마찬가지로 여기에는 추가 포인터 역참조 및 가능한 힙 할당이 필요합니다.

선택 사항의 경우 sql 패키지의 기술을 사용하여 이를 피할 수 있습니다.

type OptionalT struct {
  Valid bool
  Value T
}

이것의 주요 단점은 유효하지 않은 상태를 인코딩할 수 있다는 것입니다. Valid는 false일 수 있고 Value는 0이 아닐 수 있습니다. Valid가 false인 경우 Value를 가져올 수도 있습니다(지정되지 않은 경우 0 T를 원할 경우 유용할 수 있음). Value를 0으로 설정하지 않고 Valid를 false로 설정한 다음 Value를 할당하지 않고 Valid를 true로 설정(또는 무시)하면 이전에 버린 값이 실수로 다시 나타납니다. 이는 유형의 불변량을 보호하기 위해 setter 및 getter를 제공하여 해결할 수 있습니다.

가장 단순한 형태의 합계 유형은 값이 아닌 ID에 대해 관심을 가질 때입니다. 열거형입니다.

Go에서 이것을 처리하는 전통적인 방법은 const/iota입니다.

type Enum int
const (
  A Enum = iota
  B
  C
)

OptionalT 유형과 마찬가지로 이것은 불필요한 간접 참조가 없습니다. 인터페이스 합계와 마찬가지로 도메인을 제한하지 않습니다. 유효한 값이 3개이고 유효하지 않은 값이 많기 때문에 런타임에 유효성을 검사해야 합니다. 정확히 두 개의 값이 있으면 bool을 사용할 수 있습니다.

이 유형의 근본적인 수의 문제도 있습니다. A+B == C . 형식화되지 않은 정수 상수를 이 형식으로 너무 쉽게 변환할 수 있습니다. 그것이 바람직한 곳은 많이 있지만 우리는 이것을 얻습니다. 약간의 추가 작업을 통해 이를 ID로만 제한할 수 있습니다.

type Enum struct { v int }
var (
  A = Enum{0}
  B = Enum{1}
  C = Enum{2}
)

이제 이것들은 불투명한 레이블일 뿐입니다. 비교할 수 있지만 그게 전부입니다. 불행히도 이제 우리는 const-ness를 잃었지만, 조금 더 노력하면 다시 얻을 수 있습니다.

func A() Enum { return Enum{0} }
func B() Enum { return Enum{1} }
func C() Enum { return Enum{2} }

우리는 외부 사용자가 일부 상용구와 고도로 인라인 가능한 일부 함수 호출을 희생하여 이름을 변경할 수 없는 상태를 되찾았습니다.

그러나 이것은 유형을 거의 완전히 닫았기 때문에 인터페이스 합계보다 어떤 면에서는 더 좋습니다. 외부 코드는 A() , B() 또는 C() 있습니다. 그들은 VAR의 예에서와 같이 주변의 라벨을 바꿀 수 없습니다 그들은 할 수없는 A() + B() 우리는있는 거 무료로 우리가 원하는 방법을 정의하는 Enum . 동일한 패키지의 코드가 값을 잘못 생성하거나 수정하는 것은 여전히 ​​가능하지만, 이러한 일이 발생하지 않도록 주의를 기울이면 유효성 검사 코드가 필요하지 않은 첫 번째 합계 유형입니다. 존재하는 경우 유효합니다. .

때로는 많은 레이블이 있고 그 중 일부에는 추가 날짜가 있고 동일한 종류의 데이터가 있는 레이블도 있습니다. 3개의 값이 없는 상태(A, B, C), 2개는 문자열 값(D, E), 1개는 문자열 값과 int 값(F)이 있는 값이 있다고 가정해 보겠습니다. 위의 전술을 여러 가지 조합으로 사용할 수 있지만 가장 간단한 방법은

type Value struct {
  Which int // could have consts for A, B, C, D, E, F
  String string
  Int int
}

이것은 위의 OptionalT 유형과 매우 유사하지만 bool 대신 열거형이 있고 Which 값에 따라 설정할 수 있는(또는 설정하지 않을 수 있는) 여러 필드가 있습니다. 유효성 검사는 이것이 적절하게 설정되었는지(또는 아닌지) 주의해야 합니다.

Go에서 "다음 중 하나"를 표현하는 방법에는 여러 가지가 있습니다. 일부는 다른 것보다 더 많은 보살핌이 필요합니다. 종종 런타임 시 불변 또는 관련 없는 역참조 "중 하나"의 유효성을 검사해야 합니다. 그들이 공유하는 주요 단점은 언어의 일부가 아닌 언어로 시뮬레이트되기 때문에 "하나의" 불변이 반사 또는 go/types에 표시되지 않아 메타프로그래밍이 어렵다는 것입니다. 그들을. 메타프로그래밍에서 그것들을 사용하려면 둘 다 sum의 올바른 풍미를 인식하고 검증할 수 있어야 하며 "하나의" 불변이 없는 유효한 코드처럼 모두 보이기 때문에 그것이 당신이 찾고 있는 것이라고 말해야 합니다.

합계 유형이 언어의 일부인 경우 소스 코드에 반영되고 쉽게 소스 코드에서 제거되어 더 나은 라이브러리와 도구를 만들 수 있습니다. 컴파일러는 "하나의" 불변성을 알고 있는 경우 여러 최적화를 수행할 수 있습니다. 프로그래머는 값이 실제로 올바른 도메인에 있는지 확인하는 사소한 유지 관리 대신 중요한 유효성 검사 코드에 집중할 수 있습니다.

이와 같은 구성은 유형이 합계에 있다고 말하지만 그 합계에 없는 것은 말할 수 없습니다. 필수 nil 케이스 외에도 동일한 임베딩 트릭을 다음과 같은 외부 패키지에서 사용할 수 있습니다.
[…]
패키지 내에서 컴파일되지만 불법인 값의 유효성을 검사하도록 주의해야 합니다.

왜요? 패키지 작성자로서 이것은 "당신의 문제"의 영역에서 확고하게 보입니다. io.Reader Read 메서드가 패닉 상태인 io.Reader 를 전달하면 나는 그 상황에서 회복하지 않고 패닉 상태로 내버려 둡니다. 마찬가지로, 내가 선언한 유형의 잘못된 값을 생성하는 데 방해가 된다면 내가 누구와 논쟁을 벌이겠습니까? 즉, "나는 에뮬레이트된 폐쇄 합계를 포함했다"는 문제가 거의(만약에라도) 우연히 발생하는 문제라고 생각합니다.

즉, 인터페이스를 type Sum interface { sum() Sum } 하고 모든 값이 자체적으로 반환되도록 하여 해당 문제를 방지할 수 있습니다. 그렇게 하면 임베딩 상태에서도 제대로 작동하는 sum() 의 반환을 사용할 수 있습니다.

이 패턴에 대한 더 일반적인 불만 중 하나는 godoc에서 합계의 구성원 자격을 명확하게 하지 않는다는 것입니다.

이것은 당신을 도울 수 있습니다 .

이것의 주요 단점은 유효하지 않은 상태를 인코딩할 수 있다는 것입니다. Valid는 false일 수 있고 Value는 0이 아닐 수 있습니다.

이것은 나에게 잘못된 상태가 아닙니다. 0 값은 마법이 아닙니다. sql.NullInt64{false,0} 와 NullInt64{false,42} 사이에는 차이가 없습니다. 둘 다 SQL NULL의 유효하고 동등한 표현입니다. 모든 코드가 Value를 사용하기 전에 Valid를 확인하면 프로그램에서 차이를 관찰할 수 없습니다.

그것은 공정하고 컴파일러가 (아마, "진짜"선택적 항목 / 합계 유형에 대한 것), 만들기 쉽게 그것을 할 수있는이 검사를하고 시행하지 않는 올바른 비판이다. 그러나 잊어 버리면 실수로 0이 아닌 값을 사용하는 것보다 실수로 0 값을 사용하는 것이 더 나을 것이라고 생각하지 않습니다(포인터 모양 유형은 사용할 때 패닉하므로 예외가 가능하므로 큰 소리로 실패 - 그러나 그것들을 위해, 당신은 어쨌든 베어 포인터 모양의 유형을 사용하고 nil 를 "unset"으로 사용해야 합니다).

이 유형의 근본적인 수의 문제도 있습니다. A+B == C. 유형이 지정되지 않은 정수 상수를 이 유형으로 너무 쉽게 변환할 수 있습니다.

이것은 이론적 관심사입니까 아니면 실제로 나타났습니까?

프로그래머는 값이 실제로 올바른 도메인에 있는지 확인하는 사소한 유지 관리 대신 중요한 유효성 검사 코드에 집중할 수 있습니다.

FTR만, 내가 sum-types-as-sum-types를 사용하는 경우(즉, 골든 버라이어티 인터페이스를 통해 문제를 더 우아하게 모델링할 수 없음) 유효성 검사 코드를 작성하지 않습니다. 리시버나 인수로 전달된 포인터가 없는지 확인하지 않는 것처럼(유효한 변형으로 문서화되지 않는 한). 컴파일러가 그것을 처리하도록 강요하는 곳(즉, "함수 끝에서 반환 없음" 스타일 문제)에서 나는 기본 경우에 당황합니다.

개인적으로 나는 Go의 실용적인 언어를 고려합니다. 이 언어는 단순히 안전 기능을 추가하는 것 자체를 위해 또는 "모두가 자신이 더 낫다는 것을 알고 있기 때문에" 추가하는 것이 아니라 입증된 필요를 기반으로 합니다. 실용적인 방법으로 사용하는 것이 좋다고 생각합니다.

표준 수단은 내보내지 않고 아무것도 하지 않는 메서드를 태그로 사용하는 인터페이스입니다.

인터페이스와 합계 유형 사이에는 근본적인 차이점이 있습니다(귀하의 게시물에서 언급하지 않았습니다). 인터페이스를 통해 합계 유형을 근사할 때 실제로 값을 처리할 방법이 없습니다. 소비자로서 당신은 그것이 실제로 무엇을 담고 있는지 전혀 모르고 추측만 할 수 있습니다. 이것은 빈 인터페이스를 사용하는 것보다 낫지 않습니다. 구현이 인터페이스를 정의하는 동일한 패키지에서만 올 수 있는 경우에만 유용합니다. 그래야만 얻을 수 있는 것을 제어할 수 있기 때문입니다.

반면에 다음과 같은 것이 있습니다.

func foo(val string|int|error) {
    switch v:= val.(type) {
    case string:
        ...
    }
}

소비자에게 sum 유형의 값을 사용할 수 있는 모든 권한을 부여합니다. 그 가치는 구체적이며 해석에 열려 있지 않습니다.

@메로비우스
귀하가 언급한 이러한 "공개 합계"에는 "기능 크리프"를 위해 남용할 수 있다는 점에서 일부 사람들이 중요한 결점으로 분류할 수 있는 것이 있습니다. 선택적 함수 인수가 기능으로 거부된 이유는 바로 이 때문입니다.

귀하가 언급한 이러한 "공개 합계"에는 "기능 크리프"를 위해 남용할 수 있다는 점에서 일부 사람들이 중요한 결점으로 분류할 수 있는 것이 있습니다. 선택적 함수 인수가 기능으로 거부된 이유는 바로 이 때문입니다.

그것은 나에게 매우 약한 주장처럼 보입니다. 다른 것이 없다면 그것이 존재하기 때문에 이미 그들이 가능하게하는 것을 허용하고 있습니다. 사실, 우리가 이미 가지고있는 선택적 인수 모든 의도와 목적을, (안 나는 그 패턴처럼,하지만 분명히 이미 언어로 가능하다).

인터페이스와 합계 유형 사이에는 근본적인 차이점이 있습니다(귀하의 게시물에서 언급하지 않았습니다). 인터페이스를 통해 합계 유형을 근사할 때 실제로 값을 처리할 방법이 없습니다. 소비자로서 당신은 그것이 실제로 무엇을 담고 있는지 전혀 모르고 추측만 할 수 있습니다.

나는 이것을 두 번째로 구문 분석을 시도했지만 여전히 할 수 없습니다. 왜 그것들을 사용할 수 없습니까? 일반 내보낸 유형일 수 있습니다. 예, 패키지에서 생성된 유형이어야 하지만(분명히), 그 외에는 실제 닫힌 합계와 비교하여 사용 방법에 제한이 없는 것 같습니다.

나는 이것을 두 번째로 구문 분석을 시도했지만 여전히 할 수 없습니다. 왜 그것들을 사용할 수 없습니까? 일반 내보낸 유형일 수 있습니다. 예, 패키지에서 생성된 유형이어야 하지만(분명히), 그 외에는 실제 닫힌 합계와 비교하여 사용 방법에 제한이 없는 것 같습니다.

더미 메서드를 내보내고 제3자가 "합계 유형"을 구현할 수 있는 경우에는 어떻게 됩니까? 아니면 팀 구성원이 인터페이스의 다양한 소비자에 익숙하지 않고 동일한 패키지에 다른 구현을 추가하기로 결정하고 해당 구현의 인스턴스가 다양한 코드 수단을 통해 이러한 소비자에게 전달되는 매우 현실적인 시나리오입니까? 내 명백한 "파싱할 수 없는" 진술을 반복할 위험이 있습니다. "소비자로서, [합계 값]이 실제로 무엇을 보유하고 있는지 전혀 모르고 추측만 할 수 있습니다." 인터페이스이기 때문에 누가 구현하는지 알려주지 않습니다.

@메로비우스

FTR만, 내가 sum-types-as-sum-types를 사용하는 경우(즉, 골든 버라이어티 인터페이스를 통해 문제를 더 우아하게 모델링할 수 없음) 유효성 검사 코드를 작성하지 않습니다. 리시버나 인수로 전달된 포인터가 없는지 확인하지 않는 것처럼(유효한 변형으로 문서화되지 않는 한). 컴파일러가 그것을 처리하도록 강요하는 곳(즉, "함수 끝에서 반환 없음" 스타일 문제)에서 나는 기본 경우에 당황합니다.

나는 이것을 항상 또는 결코 하지 않습니다 .

잘못된 입력을 전달하는 사람이 즉시 폭발하는 경우 유효성 검사 코드에 신경 쓰지 않습니다.

그러나 잘못된 입력을 전달하는 사람이 결국 패닉을 일으킬 수 있지만 잠시 동안 표시되지 않는 경우 잘못된 입력에 가능한 한 빨리 플래그가 지정되고 아무도 오류가 발생했다는 사실을 알아낼 필요가 없도록 유효성 검사 코드를 작성합니다. (특히 잘못된 값이 도입된 위치를 파악하기 위해 호출 스택에서 150프레임을 더 올라가야 할 수 있기 때문에).

잠재적으로 나중에 디버깅 30분을 절약하기 위해 지금 30분을 보내는 것은 실용적입니다. 특히 저에게는 항상 어리석은 실수를 하고 학교에 빨리 도착하면 다음 어리석은 실수를 저지를 수 있기 때문에 더욱 그렇습니다.

독자를 가져와 즉시 사용하기 시작하는 func가 있는 경우 nil을 확인하지 않겠지만 func가 특정 메서드가 호출될 때까지 독자를 호출하지 않는 구조체의 팩토리라면 nil을 확인하고 패닉을 일으키거나 "reader는 nil이 아니어야 함"과 같은 오류를 반환하여 오류의 원인이 가능한 오류의 원인에 가깝도록 합니다.

godoc - 분석

알고 있지만 유용하지 않습니다. ^C를 누르기 전에 내 작업 공간에서 40분 동안 실행되었으며 패키지를 설치하거나 수정할 때마다 새로 고쳐야 합니다. 하지만 #20131(바로 이 스레드에서 분기되었습니다!)이 있습니다.

즉, 인터페이스를 type Sum interface { sum() Sum } 하고 모든 값이 자체적으로 반환되도록 하여 해당 문제를 방지할 수 있습니다. 그렇게 하면 임베딩 상태에서도 제대로 작동하는 sum() 반환을 사용할 수 있습니다.

나는 그것이 유용하다는 것을 발견하지 못했습니다. 명시적 유효성 검사보다 더 많은 이점을 제공하지 않으며 더 적은 유효성 검사를 제공합니다.

[const/iota 열거형의 멤버를 추가할 수 있다는 사실]이 이론적인 문제입니까, 아니면 실제로 발생했습니까?

그 특정한 것은 이론적인 것이었습니다. 저는 제가 생각할 수 있는 이론적이고 실용적인 모든 장단점을 나열하려고 노력했습니다. 그러나 나의 더 큰 요점은 상당히 일반적으로 사용되지만 언어에서 일종의 유형이 되도록 하는 것만큼 간단한 것은 없는 언어에서 "하나의" 불변성을 표현하려고 시도하는 많은 방법이 있다는 것입니다.

[const/iota 열거에 유형이 지정되지 않은 적분을 할당할 수 있다는 사실]이 이론적인 문제입니까 아니면 실제로 발생했습니까?

그 사람이 실제로 나타났습니다. 무엇이 잘못되었는지 알아내는 데 오랜 시간이 걸리지 않았지만 컴파일러가 "거기, 저 줄, 잘못된 줄입니다"라고 말했다면 훨씬 더 적은 시간이 걸렸을 것입니다. 그 특정 경우를 처리하는 다른 방법에 대한 이야기가 있지만 일반적으로 어떻게 사용되는지 모르겠습니다.

이것은 나에게 잘못된 상태가 아닙니다. 0 값은 마법이 아닙니다. sql.NullInt64{false,0} 와 NullInt64{false,42} 사이에는 차이가 없습니다. 둘 다 SQL NULL의 유효하고 동등한 표현입니다. 모든 코드가 Value를 사용하기 전에 Valid를 확인하면 프로그램에서 차이를 관찰할 수 없습니다.

컴파일러가 이 검사("실제" 옵셔널/합 유형의 경우 그렇게 할 수 있음)를 강제하지 않아 수행하지 않는 것이 더 쉽다는 것은 공정하고 정확한 비판입니다. 그러나 잊어 버리면 실수로 0이 아닌 값을 사용하는 것보다 실수로 0 값을 사용하는 것이 더 나을 것이라고 생각하지 않습니다(포인터 모양 유형은 사용할 때 패닉하므로 예외가 가능하므로 큰 소리로 실패 - 그러나 그것들을 위해, 당신은 어쨌든 베어 포인터 모양의 유형을 사용하고 nil을 "unset"으로 사용해야 합니다).

"모든 코드가 Value를 사용하기 전에 유효한지 확인하는 경우"는 버그가 발생하고 컴파일러가 적용할 수 있는 부분입니다. 나는 그런 버그가 발생했습니다(한 개 이상의 값 필드와 판별자에 대한 두 개 이상의 상태가 있는 패턴의 더 큰 버전이 있음에도 불구하고). 나는 개발 및 테스트 중에 이 모든 것을 찾았고 누구도 야생으로 탈출하지 못했다고 믿고/희망합니다. 실수는 컴파일러에 버그가 있는 경우였습니다. int 유형의 변수에 문자열을 할당하려고 하면 알려주는 것과 같은 방식입니다.

그리고 물론, 나는 선택적 유형에 대해 *T 를 선호하지만 실행 시공간과 코드 가독성 모두에서 관련 비용이 0이 아닙니다.

(특정 예의 경우 실제 값 또는 선택 제안과 함께 올바른 0 값을 가져오는 코드는 간결하고 안전한 v, _ := nullable.[Value] 입니다.)

그것은 내가 원하는 것이 아닙니다. 선택 유형은 값 유형이어야 합니다.
러스트에서처럼. 필요한 경우 첫 번째 단어는 GC 메타데이터에 대한 포인터여야 합니다.

그렇지 않으면 성능이 저하될 수 있습니다.
받아들일 수 없는. 나에게는 오전 10시 41분, "Josh Bleecher Snyder" <
[email protected]>은 다음과 같이 썼습니다.

선택 제안을 사용하면 더 많은 것을 제공하는 ap 또는 *p를 선택할 수 있습니다.
메모리 트레이드 오프에 대한 더 큰 제어.

인터페이스가 스칼라 값을 저장하기 위해 할당하는 이유는
다른 단어가 a인지 여부를 결정하기 위해 유형 단어를 읽어야 합니다.
바늘; 자세한 내용은 #8405 https://github.com/golang/go/issues/8405 를 참조
논의. 동일한 구현 고려 사항이
유형 선택, 이는 실제로 p가 결국 할당되고
어쨌든 비 로컬.

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/19412#issuecomment-323371837 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AGGWB-wQD75N44TGoU6LWQhjED_uhKGUks5sZaKbgaJpZM4MTmSr
.

@urandom

더미 메서드를 내보내고 제3자가 "합계 유형"을 구현할 수 있는 경우에는 어떻게 됩니까?

내보내는 방법과 내보내는 유형 간에 차이가 있습니다. 우리는 서로 과거를 이야기하는 것 같습니다. 나에게 이것은 열린 합계와 닫힌 합계의 차이 없이 잘 작동하는 것 같습니다.

type X interface { x() X }
type IntX int
func (v IntX) x() X { return v }
type StringX string
func (v StringX) x() X { return v }
type StructX struct{
    Foo bool
    Bar int
}
func (v StructX) x() X { return v }

가능한 패키지 외부의 확장은 없지만 패키지의 소비자는 다른 것과 마찬가지로 값을 사용, 생성 및 전달할 수 있습니다.

X 또는 이를 충족하는 로컬 유형 중 하나를 외부에 포함시킨 다음 X를 사용하는 패키지의 함수에 전달할 수 있습니다.

해당 함수가 x를 호출하면 패닉(X 자체가 포함되어 있고 아무 것도 설정되지 않은 경우)하거나 코드가 작동할 수 있는 값을 반환합니다. (그리고 그들이 문서를 읽지 않았기 때문에 이와 같은 것을 시도하고 있다면 그들의 코드는 이미 의심스럽습니다.)

"하지마"라는 메시지와 함께 패닉 상태인 유효성 검사기를 호출하는 것은 이를 처리하고 호출자가 코드를 수정할 수 있도록 하는 가장 놀라운 방법인 것처럼 보입니다.

그 함수가 x를 호출하면 패닉 […]하거나 코드가 작동할 수 있는 값을 반환합니다.

위에서 말했듯이: 잘못된 값의 의도적인 구성이 잘못되었다는 사실에 놀랐다면 기대치를 다시 생각해야 합니다. 그러나 어떤 경우든, 이 특정 토론의 주제는 그것이 아니며 별도의 주장을 분리하는 것이 도움이 될 것입니다. 이것은 @urandom 이 태그 메소드가 있는 인터페이스를 통한 미결 합계가 다른 패키지에서 내성이

문제는 누군가 컴파일하고 패키지에 전달할 수 있는 합계에 없는 형식을 만들 수 있다는 것입니다.

언어에 적절한 합계 유형을 추가하지 않고 처리하는 세 가지 옵션이 있습니다.

1. 상황을 무시하다
2. 유효성 검사 및 패닉/오류 반환
3. 내재된 값을 암묵적으로 추출하고 사용하여 "당신이 의미하는 바를 수행"을 시도하십시오.

3은 1과 2의 이상한 혼합처럼 보입니다. 무엇을 사는지 모르겠습니다.

"의도적으로 잘못된 값을 구성하는 것이 잘못되었다는 사실에 놀랐다면 기대치를 다시 생각해야 합니다"라는 데 동의하지만 3을 사용하면 문제가 발생했음을 알아차리기가 매우 어려울 수 있습니다. 이유를 알기 어려울 것입니다.

2가 코드가 유효하지 않은 상태로 미끄러지는 것을 방지하고 누군가가 잘못한 이유와 수정 방법을 알려주는 경우 플레어를 보내기 때문에 가장 좋은 것 같습니다.

제가 패턴의 의도를 잘못 이해하고 있는 건가요 아니면 다른 철학으로 접근하고 있는 건가요?

@urandom 설명도 감사하겠습니다. 나도 당신이 말하려는 것이 100% 확실하지 않습니다.

문제는 누군가 컴파일하고 패키지에 전달할 수 있는 합계에 없는 형식을 만들 수 있다는 것입니다.

당신은 항상 그렇게 할 수 있습니다. 의심스러우면 컴파일러가 확인하는 합계 유형을 사용하더라도 항상 안전하지 않은 것을 사용할 수 있습니다. 유효한 값). 문제는 "이것이 실제로 얼마나 자주 문제를 일으킬 것이며 그 문제가 얼마나 심각할 것인가"입니다. 제 생각에는 위의 솔루션에 대한 대답은 "거의 없고 매우 낮습니다"입니다. 그러나 어느 쪽이든, 이것에 대해 많은 노력을 기울이는 요점이 없는 것 같습니다. 이 특정 요점에 대한 양측의 주장과 견해가 충분히 명확해야 하며 너무 많은 시끄러운 반복을 피하고 진정으로 초점을 맞추려고 노력하고 있습니다. 새로운 주장. 나는 일류 합계 유형과 인터페이스를 통해 에뮬레이트된 합계 간에 내보내기 가능성에 차이가 없음을 보여주기 위해 구성을 언급했습니다. 그들이 모든 면에서 엄격하게 더 낫다는 것을 보여주려는 것은 아닙니다.

의심스러우면 컴파일러가 확인하는 합계 유형을 사용하더라도 항상 안전하지 않은 것을 사용할 수 있습니다. 유효한 값).

나는 그것이 질적으로 다르다고 생각합니다. 사람들이 이런 방식으로 임베딩을 오용할 때(적어도 proto.Message 및 그것을 구현하는 구체적인 유형에 대해), 그들은 일반적으로 그것이 안전한지와 그것이 깨질 수 있는 불변성에 대해 생각하지 않습니다 . (사용자는 인터페이스가 필요한 동작을 완전히 설명한다고 가정하지만 인터페이스가 통합 또는 합계 유형으로 사용되는 경우에는 그렇지 않은 경우가 많습니다. https://github.com/golang/protobuf/issues/364도 참조하세요.)

대조적으로 누군가가 unsafe 패키지를 사용하여 일반적으로 참조할 수 없는 유형으로 변수를 설정하는 경우 최소한 손상될 ​​수 있는 것과 그 이유에 대해 생각했다고 명시적으로 주장하는 것입니다.

@Merovius 아마도 나는 명확하지 않습니다. 컴파일러가 잘못된 임베딩을 사용했다고 누군가에게 말할 것이라는 사실은 좋은 부수적 이점입니다.

안전 기능의 가장 큰 이점은 반사에 의해 존중되고 go/types로 표시된다는 것입니다. 이는 도구 및 라이브러리에 작업할 더 많은 정보를 제공합니다. Go에서 합계 유형을 시뮬레이트하는 방법은 많이 있지만 모두 비합 유형 코드와 동일하므로 도구 및 라이브러리는 합계 유형이고 특정 패턴을 인식할 수 있어야 한다는 것을 알기 위해 대역 외 정보가 필요합니다. 사용 중이지만 이러한 패턴조차도 상당한 변화를 허용합니다.

또한 유효하지 않은 값을 생성하는 유일한 방법은 안전하지 않게 만들 수 있습니다. 이제 일반 코드, 생성된 코드 및 반영이 있습니다. 후자의 두 가지는 문서를 읽을 수 없는 사람과 달리 문제를 일으킬 가능성이 더 높습니다.

안전의 또 다른 부수적 이점은 컴파일러가 더 많은 정보를 갖고 있고 더 빠른 코드를 생성할 수 있다는 것입니다.

의사 합을 인터페이스로 대체할 수 있는 것 외에도 json.Token 또는 driver.Value 와 같은 "이 일반 유형 중 하나"를 의사 합으로 대체할 수 있다는 사실도 있습니다. 그것들은 거의 없지만 interface{} 가 필요한 곳은 한 곳 적습니다.

또한 유효하지 않은 값을 생성하는 유일한 방법은 안전하지 않게 됩니다.

이 진술로 이어지는 "유효하지 않은 값"의 정의를 이해하지 못하는 것 같습니다.

@neild 당신이 있었다면

var v pick {
  None struct{}
  A struct { X int; Y *T}
  B int
}

그것은 메모리에 배치됩니다

struct {
  activeField int //which of None (0), A (1), or B (2) is the current field
  theInt int // If None always 0
  thePtr *T // If None or B, always nil
}

unsafe를 사용하면 activeField 가 0 또는 2인 경우에도 thePtr 설정하거나 activeField 가 0인 경우에도 theInt 값을 설정할 수 있습니다.

두 경우 모두 이것은 컴파일러가 만드는 가정을 무효화하고 오늘날 우리가 가질 수 있는 것과 같은 종류의 이론적 버그를 허용합니다.

그러나 @bcmills가 지적했듯이 안전하지 않은 것을 사용하는 경우 핵 옵션이기 때문에 무엇을 하고 있는지 더 잘 알 것입니다.

내가 이해할 수 없는 것은 왜 안전하지 않은 것이 잘못된 값을 생성하는 유일한 방법인지입니다.

var t time.Timer

t 는 잘못된 값입니다. t.C 가 설정되지 않았으며 t.Stop 호출하면 패닉 상태가 됩니다. 안전하지 않은 것은 필요하지 않습니다.

일부 언어에는 "유효하지 않은" 값 생성을 방지하기 위해 많은 노력을 기울이는 유형 시스템이 있습니다. Go는 그들 중 하나가 아닙니다. 노조가 그 바늘을 어떻게 크게 움직이는지 모르겠습니다. (물론 노조를 지지하는 다른 이유도 있다.)

@neild 예, 제 정의가 느슨해져서 죄송합니다.

나는 sum 유형의 불변량에 대해 무효라고 말했어야 했다.

물론 합계의 개별 유형은 잘못된 상태일 수 있습니다.

그러나 합계 유형 불변성을 유지하는 것은 프로그래머뿐만 아니라 리플렉션 및 go/types에 액세스할 수 있다는 것을 의미하므로 라이브러리 및 도구에서 이를 조작하면 안전이 유지되고 메타프로그래머에게 더 많은 정보를 제공합니다.

@jimmyfrasche , 가능한 모든 유형을 알려주는 합계 유형과 달리 인터페이스는 유형 목록이 무엇인지 모르거나 적어도 사용할 수 없다는 점에서 불투명합니다. 인터페이스를 구현하는 것입니다. 이것은 코드의 switch 부분을 ​​약간 추측하게 만듭니다.

func F(sum SumInterface) {
    switch v := sum {
    case Screwdriver:
             ...
    default:
           panic ("Someone implementing a new type which gets passed to F and causes a runtime panic 3 weeks into production")
    }
}

따라서 사람들이 인터페이스 기반 합계 유형 에뮬레이션과 관련하여 겪고 있는 대부분의 문제는 톨링 및/또는 관례로 해결할 수 있다고 생각합니다. 예를 들어 인터페이스에 내보내지 않은 메서드가 포함된 경우 가능한 모든 구현(예, 의도적 우회)을 파악하는 것은 간단합니다. 마찬가지로, iota 기반 열거형과 관련된 대부분의 문제를 해결하기 위해 "열거형은 const ( FooA Foo = iota; FooB; FooC ) 형식의 선언이 있는 type Foo int 입니다"라는 간단한 규칙을 사용하면 광범위하고 정확한 도구를 작성할 수 있습니다. 그들에게도.

예, 이것은 실제 합계 유형과 동일하지 않지만(무엇보다도 이것이 얼마나 중요한지 이해하지 못하지만 일류 반사 지원을 얻지는 못함) 기존 솔루션이 내 관점에서 볼 때 종종 칠해지는 것보다 더 잘 나타납니다. 그리고 IMO는 실제로 Go 2에 넣기 전에 해당 디자인 공간을 탐색할 가치가 있습니다. 최소한 사람들에게 정말 중요하다면 말이죠.

(그리고 나는 sum 유형의 장점을 알고 있으므로 내 이익을 위해 다시 말할 필요가 없음을 다시 강조하고 싶습니다. 나는 단지 다른 사람들만큼 중요하지 않고 단점도 보고 따라서 동일한 데이터에 대해 다른 결론에 도달)

@Merovius 좋은 위치입니다.

리플렉트 지원을 통해 라이브러리와 오프라인 도구(린터, 코드 생성기 등)가 정보에 액세스하고 정적으로 정확하게 감지할 수 없는 부적절하게 수정하는 것을 방지할 수 있습니다.

어쨌든 탐색하는 것이 공정한 아이디어이므로 탐색해 보겠습니다.

Go에서 가장 일반적인 의사합 계열을 요약하면 다음과 같습니다. (대략 발생 순서대로)

• const/iota 열거형.
• 동일한 패키지에 정의된 유형에 대한 합계에 대한 태그 메소드와의 인터페이스.
• *T 옵션의 경우 T
• 값이 설정될 수 있는 필드를 결정하는 열거형이 있는 구조체(열거형이 bool이고 다른 필드가 하나만 있는 경우 이것은 또 다른 종류의 선택적 T )
• interface{} 한정된 유형의 가방으로 제한됩니다.

이들 모두는 합계 유형과 비합계 유형 모두에 사용할 수 있습니다. 처음 두 개는 다른 용도로 거의 사용되지 않으므로 합계 유형을 나타내고 가끔 거짓 긍정을 허용한다고 가정하는 것이 합리적일 수 있습니다. 인터페이스 합계의 경우 매개변수 또는 반환이 없고 멤버에 본문이 없는 내보내지 않은 메서드로 제한할 수 있습니다. 열거 형의 경우 그것은 그들이 그냥있을 때 만 인식 할 나을 Type = iota 이오타는 식의 일부로 사용하는 경우가 난처하지 그래서.

선택적 T *T 대한 type O = *T 관례를 제공할 수 있습니다. 별칭 이름이 유형의 일부가 아니기 때문에 약간 어렵지만 감지할 수 있습니다. type O *T 는 감지하기는 쉽지만 코드에서 작업하기는 더 어렵습니다. 반면에 수행해야 하는 모든 것은 기본적으로 유형에 내장되어 있으므로 이를 인식하여 도구로 얻을 수 있는 것은 거의 없습니다. 이것만은 무시합시다. (제네릭은 type Optional(T) *T 라인을 따라 무언가를 허용할 가능성이 높아 "태그 지정"을 단순화할 수 있습니다.)

열거형이 있는 구조체는 도구에서 추론하기 어려울 것입니다. 열거형에 대해 어떤 필드가 어떤 값과 함께 사용됩니까? 열거형의 멤버당 하나의 필드가 있어야 하고 열거형 값과 필드 값이 동일해야 한다는 규칙으로 이것을 단순화할 수 있습니다. 예를 들면 다음과 같습니다.

type Which int
const (
  A Which = iota
  B
  C
)
type Sum struct {
  Which
  A struct{} // has to be included to line up with the value of Which
  B struct { X int; Y float64 }
  C struct { X int; Y int } 
}

그것은 선택적 유형을 얻지 못하지만 인식기에서 "2 필드, 첫 번째는 bool"이라는 특수한 경우를 사용할 수 있습니다.

//gosum: int, float64, string, Foo 와 같은 마법의 주석 없이는 가방 합계에 interface{} 를 사용하는 것을 감지할 수 없습니다.

또는 다음 정의를 가진 특수 패키지가 있을 수 있습니다.

package sum
type (
  Type struct{}
  Enum int
  OneOf interface{}
)

type MyEnum sum.Enum 형식인 경우에만 열거형을 인식하고, sum.Type 를 포함하는 경우에만 인터페이스와 구조체를 인식하고, type GrabBag sum.OneOf 와 같은 interface{} 가방만 인식합니다. type GrabBag sum.OneOf (하지만 주석을 설명하려면 여전히 기계가 인식할 수 있는 주석이 필요합니다). 다음과 같은 장단점이 있습니다.
장점

• 코드에 명시적: 그렇게 표시되면 100% 합계 유형이며 오탐지가 없습니다.
• 이러한 정의에는 의미를 설명하는 문서가 있을 수 있으며 패키지 문서는 이러한 유형과 함께 사용할 수 있는 도구에 연결할 수 있습니다.
• 일부는 반사에 약간의 가시성을 가질 것입니다.
  단점
• 오래된 코드와 stdlib(이를 사용하지 않을 것)에서 많은 거짓 부정.
• 그것들은 유용하게 사용되어야 하므로 채택 속도가 느리고 100%에 도달하지 못할 가능성이 높으며 이 특수 패키지를 인식한 도구의 효율성은 채택의 함수가 될 것이므로 실험적이긴 하지만 매우 흥미롭지만 비현실적일 가능성이 높습니다.

이 두 가지 방법 중 합계 유형을 식별하는 데 사용되는 방법에 관계없이 해당 유형이 인식되었다고 가정하고 해당 정보를 사용하여 빌드할 수 있는 도구의 종류를 확인합니다.

툴링을 생성(스트링거와 같은) 및 내성(골린트와 같은)으로 대략 그룹화할 수 있습니다.

가장 간단한 생성 코드는 누락된 케이스로 switch 문을 채우는 도구입니다. 이것은 편집자가 사용할 수 있습니다. 합계 유형이 합계 유형으로 식별되면 이것은 사소합니다(조금 지루하지만 실제 생성 논리는 언어 지원 여부에 관계없이 동일할 것입니다).

모든 경우에 "하나의" 불변성을 검증하는 함수를 생성하는 것이 가능합니다.

열거형의 경우 스트링거와 같은 더 많은 도구가 있을 수 있습니다. https://github.com/golang/go/issues/19814#issuecomment -291002852에서 몇 가지 가능성을 언급했습니다.

가장 큰 생성 도구는 이 정보로 더 나은 기계어 코드를 생성할 수 있는 컴파일러입니다.

나는 현재 다른 사람을 생각할 수 없습니다. 누군가의 위시리스트에 무언가가 있습니까?

내성의 경우 명백한 후보는 철저한 린트입니다. 언어 지원이 없으면 실제로 두 가지 종류의 린트가 필요합니다.

1. 가능한 모든 상태가 처리되었는지 확인
2. 잘못된 상태가 생성되지 않았는지 확인(1이 수행한 작업을 무효화함)

1은 사소하지만 2는 100% 검증될 수 없고(안전하지 않은 경우를 무시하더라도) 모든 가능한 상태와 기본 케이스가 필요하며 코드를 사용하는 모든 코드가 어쨌든 이 린터를 실행한다고 기대할 수 없습니다.

2 실제로 값을 반영하거나 합계에 대해 유효하지 않은 상태를 생성할 수 있는 모든 코드를 식별할 수는 없지만 합계 유형을 포함하고 함께 func를 호출하는 경우와 같이 많은 간단한 오류를 잡을 수 있습니다. "pkg.F(v)를 작성했지만 pkg.F(v.EmbeddedField)를 의미했습니다." 또는 "2를 pkg.F에 전달했습니다. pkg.B를 사용하세요." 구조체의 경우 "어느 것을 켜고 있고 X의 경우 필드 F를 0이 아닌 값으로 설정했는지"와 같은 정말 명백한 경우를 제외하고는 한 번에 하나의 필드가 설정된다는 불변성을 적용할 수 없습니다. ". 패키지 외부에서 값을 수락할 때 생성된 유효성 검사 함수를 사용하도록 주장할 수 있습니다.

다른 큰 것은 godoc에 나타날 것입니다. godoc은 이미 const/iota를 그룹화하고 #20131은 인터페이스 pseudosums에 도움이 될 것입니다. 불변을 지정하는 것 외에는 정의에 명시되지 않은 구조체 버전과 관련이 없습니다.

뿐만 아니라 오프라인 도구(린터, 코드 생성기 등)

아니요. 정적 정보가 존재합니다. 이를 위해 유형 시스템(또는 반영)이 필요하지 않습니다. 규칙은 잘 작동합니다. 인터페이스에 내보내지 않은 메서드가 포함되어 있으면 모든 정적 도구에서 이를 닫힌 합계로 처리하고(효과적으로 있기 때문에) 원하는 분석/코드 생성을 수행하도록 선택할 수 있습니다. 마찬가지로 iota-enums의 규칙도 마찬가지입니다.

Reflect는 런타임 유형 정보를 위한 것입니다. 어떤 의미에서 컴파일러는 여기에서 sum-by-convention이 작동하도록 하는 데 필요한 정보를 지웁니다(함수 목록, 선언된 유형 또는 선언된 const에 대한 액세스 권한을 제공하지 않기 때문에). 이것이 실제 금액이 이를 가능하게 한다는 데 동의하는 이유입니다.

(또한 FTR은 사용 사례에 따라 필요한 런타임 정보를 생성하기 위해 정적으로 알려진 정보를 사용하는 도구를 가질 수 있습니다. 예를 들어 필요한 태그 메서드가 있는 유형을 열거하고 조회 테이블을 생성할 수 있습니다. 그러나 나는 유스 케이스가 무엇인지 이해하지 못하므로 이것의 실용성을 평가하기가 어렵습니다).

그래서 내 질문은 의도적으로: 런타임에 이 정보를 사용할 수 있는 사용 사례는 무엇입니까?

어쨌든 탐색하는 것이 공정한 아이디어이므로 탐색해 보겠습니다.

내가 "탐구하라"고 말했을 때, 나는 "그것들을 열거하고 그것들에 대해 진공 상태에서 논쟁하라"는 것을 의미하지 않았고, 나는 "이러한 관례를 사용하는 도구를 구현하고 그것들이 얼마나 유용/필요/실용적인지 확인하라"를 의미했다.

경험 보고서 의 장점은

"기존 메커니즘을 사용하려고 시도하는" 부분을 건너뛰고 있습니다. 합계(문제)에 대한 정적인 완전성 검사를 원합니다. 내보내지 않은 메서드가 있는 인터페이스를 찾는 도구를 작성하고, 사용된 모든 유형 스위치에 대한 철저한 검사를 수행하고, 잠시 동안 해당 도구를 사용합니다(기존 메커니즘 사용). 실패한 곳에 기록하십시오.

나는 큰 소리로 생각하고 도구가 사용할 수 있는 생각을 기반으로 정적 인식기에 대한 작업을 시작했습니다. 나는 암묵적으로 피드백과 더 많은 아이디어를 찾고 있었던 것 같다.

FWIW, 만약 당신이 복잡한 경우를 무시하고 작동하는 것들에 집중할 것이라면: a) 인터페이스에서 내보내지 않은 메서드와 b) 기본 유형으로 int를 갖고 단일 const를 갖는 간단한 const-iota-enums 예상 형식 선언 도구를 사용하려면 이 두 가지 해결 방법 중 하나를 사용해야 하지만 IMO는 괜찮습니다(컴파일러 도구를 사용하려면 명시적으로 합계를 사용해야 하므로 괜찮아 보입니다).

그것은 확실히 시작하기에 좋은 곳이며 많은 패키지 세트를 실행하고 얼마나 많은 오탐지/부정성이 있는지 확인한 후 전화를 걸 수 있습니다.

https://godoc.org/github.com/jimmyfrasche/closed

여전히 많은 작업이 진행 중입니다. 생성자에 추가 매개변수를 추가할 필요가 없다고 장담할 수 없습니다. 테스트보다 버그가 더 많을 수 있습니다. 하지만 가지고 놀기에 충분합니다.

가져오기 경로로 지정된 패키지에서 감지된 모든 닫힌 유형도 나열하는 cmds/closed-exporter의 사용 예가 있습니다.

내보내지 않은 메서드로 모든 인터페이스를 감지하기 시작했지만 상당히 일반적이며 일부는 분명히 합계 유형인 반면 다른 일부는 분명히 그렇지 않았습니다. 그냥 빈 태그 방식 규약으로만 한정하면 합형이 많이 없어져서 둘 다 따로 기록하고 패키지를 합형을 넘어 폐쇄형으로 일반화하기로 했다.

열거형을 사용하여 다른 방법으로 이동하여 정의된 유형의 bitset이 아닌 모든 const를 기록했습니다. 발견된 비트셋도 공개할 계획입니다.

일종의 마커 주석이 필요하기 때문에 선택적 구조체 또는 정의된 빈 인터페이스는 아직 감지하지 못하지만 stdlib에 있는 특수한 경우에는 감지합니다.

내보내지 않은 메서드로 모든 인터페이스를 감지하기 시작했지만 상당히 일반적이며 일부는 분명히 합계 유형인 반면 다른 일부는 분명히 그렇지 않았습니다.

그렇지 않은 몇 가지 예를 제공할 수 있다면 도움이 될 것입니다.

@Merovius 죄송합니다 목록을 보관하지 않았습니다. stdlib.sh(cmds/closed-explorer에서)를 실행하여 찾았습니다. 다음에 좋은 예를 만나면 이것을 사용하여 게시할 것입니다.

내가 합계 유형으로 고려하지 않는 것은 여러 구현 중 하나를 연결하는 데 사용되는 모두 내보내지 않은 인터페이스였습니다. 합이 아닌 인터페이스로 많이 사용하고 있었는데, 그냥 내보내지 않아서 닫히게 된 것입니다. 아마도 그것은 차이가 없는 구별일지 모르지만, 나는 추가 조사 후에 항상 마음을 바꿀 수 있습니다.

@jimmyfrasche 나는 그것들이 폐쇄 총액으로 적절하게 취급되어야 한다고 주장합니다. 나는 그들이 동적 유형에 신경 쓰지 않는다면(즉, 인터페이스의 메서드만 호출하는 경우) 정적 린터는 "모든 스위치가 철저하다"고 불평하지 않을 것이라고 주장합니다. 폐쇄 총액으로. 만약, OTOH, 그들이 스위치를 입력 때로는 않고 올바른 것입니다 불평 사례를 생략 - 그게 정확히 린터가 캐치로 추정되는 물건의 종류가 될 것입니다.

유니온 유형이 메모리 사용량을 줄이는 방법을 탐구하는 데 좋은 단어를 넣고 싶습니다. 저는 Go에서 인터프리터를 작성 중이며 Values는 다른 유형에 대한 포인터일 수 있기 때문에 반드시 인터페이스로 구현되어야 하는 Value 유형이 있습니다. 이것은 아마도 C에서 할 수 있는 작은 비트 태그로 포인터를 패킹하는 것과 비교하여 []Value가 두 배의 메모리를 차지함을 의미합니다. 많은 것 같습니까?

언어 사양은 이것을 언급할 필요가 없지만 일부 작은 공용체 유형에 대해 배열의 메모리 사용량을 절반으로 줄이는 것이 공용체에 대한 꽤 설득력 있는 주장이 될 수 있는 것처럼 보입니다. 내가 아는 한 오늘날 Go에서는 불가능한 일을 할 수 있습니다. 대조적으로 인터페이스 위에 공용체를 구현하면 프로그램의 정확성과 이해도에 도움이 될 수 있지만 기계 수준에서는 새로운 작업을 수행하지 않습니다.

성능 테스트를 해본 적이 없습니다. 연구 방향을 제시할 뿐입니다.

대신에 값을 unsafe.Pointer로 구현할 수 있습니다.

2018년 2월 6일 오후 3시 54분에 "Brian Slesinsky" [email protected]이 다음과 같이 썼습니다.

유니온 유형이
메모리 사용량. 저는 Go에서 인터프리터를 작성 중이며 다음과 같은 값 유형이 있습니다.
Values는 포인터가 될 수 있기 때문에 반드시 인터페이스로 구현되어야 합니다.
다른 유형에. 이것은 아마도 []값이 두 배를 차지함을 의미합니다.
할 수 있는 것처럼 작은 비트 태그로 포인터를 패킹하는 것과 비교한 메모리
C. 많은 것 같습니까?

언어 사양은 이것을 언급 할 필요가 없지만 메모리를 자르는 것처럼 보입니다.
일부 작은 공용체 유형에 대해 배열을 반으로 사용하는 것은 꽤 될 수 있습니다.
노조에 대한 설득력 있는 주장? 그것은 당신이 나만큼 할 수 있습니다
오늘 바둑에서 할 수 없다는 것을 알고 있습니다. 이에 반해 노동조합을 시행하는 것은
인터페이스의 상단은 프로그램 정확성 및
이해하기 쉬우나 기계 수준에서 새로운 일은 하지 않습니다.

성능 테스트를 해본 적이 없습니다. 방향을 제시할 뿐이다.
연구.

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

@skybrian 합계 유형의 구현과 관련하여 꽤 주제넘은 것 같습니다. 그것은 합계 유형을 요구할 뿐만 아니라 컴파일러가 합계에 있는 포인터만의 특수한 경우를 인식하고 압축된 포인터로 최적화해야 합니다. 그리고 GC가 포인터에 필요한 태그 비트 수를 인식해야 합니다. , 마스킹합니다. 예를 들면, 나는 이런 일이 일어나는 것을 실제로 보지 못합니다, TBH.

그러면 다음과 같은 결과를 얻을 수 있습니다. Sum 유형은 태그가 지정된 공용체일 것이며 아마도 지금처럼 슬라이스에서 많은 공간을 차지할 것입니다. 슬라이스가 균질하지 않다면 지금 당장 더 구체적인 슬라이스 유형을 사용할 수도 있습니다.

그래. 매우 특별한 경우에 특별히 최적화하면 약간의 메모리를 절약할 수 있지만 실제로 필요한 경우 수동으로 최적화할 수도 있습니다.

@DemiMarie unsafe.Pointer는 App Engine에서 작동하지 않으며 어떤 경우에도 가비지 수집기를 망치지 않고 비트를 포장할 수 없습니다. 가능하더라도 휴대가 불가능합니다.

@Merovius 예, 패킹된 메모리 레이아웃을 이해하려면 런타임 및 가비지 수집기를 변경해야 합니다. 그것은 일종의 요점입니다. 포인터는 Go 런타임에 의해 관리되므로 안전한 방식으로 인터페이스보다 더 나은 작업을 수행하려면 라이브러리나 컴파일러에서 수행할 수 없습니다.

그러나 빠른 인터프리터를 작성하는 것은 드문 사용 사례라는 것을 쉽게 인정할 것입니다. 아마도 다른 사람들이 있습니까? 언어 기능에 동기를 부여하는 좋은 방법은 오늘날 Go에서 쉽게 수행할 수 없는 작업을 찾는 것입니다.

그것은 사실이다.

내 생각에 바둑은 통역사를 쓰기에 가장 좋은 언어는 아니지만,
그러한 소프트웨어의 엄청난 역동성 때문입니다. 고성능이 필요하다면,
핫 루프는 어셈블리로 작성되어야 합니다. 무슨 이유라도 있나요
App Engine에서 작동하는 인터프리터를 작성해야 합니까?

2018년 2월 6일 오후 6시 15분에 "Brian Slesinsky" [email protected]이 다음과 같이 썼습니다.

@DemiMarie https://github.com/demimarie unsafe.Pointer가 앱에서 작동하지 않습니다
엔진, 그리고 어떤 경우에도 당신이
가비지 컬렉터를 망친다. 가능하다 해도 그럴 수 없다.
가지고 다닐 수 있는.

@metrovius 예, 런타임 및 가비지 수집기를 변경해야 합니다.
패킹된 메모리 레이아웃을 이해합니다. 그것은 일종의 요점입니다. 포인터는
Go 런타임에 의해 관리되므로 인터페이스보다 더 나은 작업을 원하는 경우
안전한 방법은 라이브러리나 컴파일러에서 할 수 없습니다.

그러나 나는 빠른 통역사를 쓰는 것이 흔하지 않다는 것을 쉽게 인정할 것입니다.
사례. 아마도 다른 사람들이 있습니까? 동기부여를 하는 좋은 방법인것 같습니다
언어 기능은 오늘 바둑에서 쉽게 할 수 없는 일을 찾는 것입니다.

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

@rogpepp 제안이 상당히 매력적입니다. 또한 @griesemer가 이미 식별한 혜택과 함께 추가 혜택을 잠금 해제할 가능성이 있는지도 궁금합니다.

제안서는 "합계 유형의 메소드 세트는 메소드 세트의 교집합을 보유합니다.
동일한 모든 방법을 제외한 모든 구성 요소 유형
이름이지만 서명이 다릅니다."

그러나 유형은 단순한 메소드 세트 그 이상입니다. 합계 유형이 해당 구성 요소 유형에서 지원하는 연산의 교차를 지원한다면 어떻게 될까요?

예를 들어 다음을 고려하십시오.

var x int|float64

다음이 효과가 있다는 아이디어입니다.

x += 5

전체 유형 스위치를 작성하는 것과 같습니다.

switch i := x.(type) {
case int:
    x = i + 5
case float64:
    x = i + 5
}

또 다른 변형에는 구성 요소 유형 자체가 합계 유형인 유형 스위치가 포함됩니다.

type Num int | float64
type StringOrNum string | Num 
var x StringOrNum

switch i := x.(type) {
case string:
    // Do string stuff.
case Num:
    // Would be nice if we could use i as a Num here.
}

또한 sum 유형과 유형 제약 조건을 사용하는 제네릭 시스템 사이에 잠재적으로 정말 좋은 시너지 효과가 있다고 생각합니다.

var x int|float64

var x, y int | float64 어떻습니까? 여기에 추가할 때의 규칙은 무엇입니까? 어떤 손실 변환이 이루어지나요(왜)? 결과 유형은 무엇입니까?

Go는 의도적으로 (C처럼) 표현식에서 자동 변환을 수행하지 않습니다. 이러한 질문은 대답하기 쉽지 않고 버그로 이어집니다.

그리고 더 많은 재미를 위해:

var x, y, z int|string|rune
x = 42
y = 'a'
z = "b"
fmt.Println(x + y + z)
fmt.Println(x + z + y)
fmt.Println(y + x + z)
fmt.Println(y + z + x)
fmt.Println(z + x + y)
fmt.Println(z + y + x)

모든 int , string 및 rune 에는 + 연산자가 있습니다. 위의 인쇄는 무엇이며 무엇보다 왜 결과가 완전히 혼란스럽지 않을 수 있습니까?

var x, y int | float64 어떻습니까? 여기에 추가할 때의 규칙은 무엇입니까? 어떤 손실 변환이 이루어지나요(왜)? 결과 유형은 무엇입니까?

@Merovius 내 표현이 어떻게 그 인상을 유감스럽게 만들 수 있는지 알 수 있지만 암시적으로 손실 변환이 x + y 는 암시적 변환 가능성을 암시하기 때문에 컴파일되지 않습니다. 그러나 다음 중 하나가 컴파일됩니다.

z = int(x) + int(y)
z = float64(x) + float64(y)

마찬가지로 xyz 예제는 가능한 암시적 변환이 필요하기 때문에 컴파일되지 않습니다.

"지원되는 작업의 교차 지원"은 좋게 들리지만 의도한 바를 제대로 전달하지 못한다고 생각합니다. "모든 구성 요소 유형에 대해 컴파일"과 같은 것을 추가하면 작동 방식을 설명하는 데 도움이 됩니다.

또 다른 예는 모든 구성 요소 유형이 슬라이스 및 맵인 경우입니다. 유형 전환 없이 sum 유형에서 len을 호출할 수 있으면 좋을 것입니다.

모든 int, string 및 rune에는 + 연산자가 있습니다. 위의 인쇄는 무엇이며 무엇보다 왜 결과가 완전히 혼란스럽지 않을 수 있습니까?

"합계 유형이 해당 구성 요소 유형이 지원하는 연산의 교차를 지원하면 어떻게 될까요?"를 추가하고 싶었습니다. "유형은 해당 값에 특정한 작업 및 메서드와 함께 값 집합을 결정합니다."라는 Go Spec의 유형 설명에서 영감을 받았습니다.

내가 말하려고 했던 요점은 유형이 값과 메소드 그 이상이므로 합계 유형이 구성 요소 유형에서 다른 항목의 공통성을 포착하려고 할 수 있다는 것입니다. 이 "기타 항목"은 단순한 연산자 집합보다 더 미묘한 차이가 있습니다.

또 다른 예는 nil과의 비교입니다.

var x []int | []string
fmt.Println(x == nil)  // Prints true
x = []string(nil)
fmt.Println(x == nil)  // Still prints true

두 구성 요소 유형 모두 최소한 하나의 유형은 nil과 비교할 수 있으므로 유형 전환 없이 sum 유형을 nil과 비교할 수 있습니다. 물론 이것은 인터페이스가 현재 작동하는 방식과 다소 상충되지만 https://github.com/golang/go/issues/22729에 따라 나쁘지 않을 수 있습니다.

편집: 평등 테스트는 더 관대해야 하고 하나 이상의 구성 요소 유형에서 잠재적인 일치만 필요로 하기 때문에 여기에서 나쁜 예입니다. 그런 점에서 미러 할당.

문제는 그 결과가 a) 자동 변환과 동일한 문제가 발생하거나 b) 범위가 극도로 (그리고 IMO는 혼란스럽게) 제한된다는 것입니다. 즉, 모든 연산자는 기껏해야 형식화되지 않은 리터럴로만 작동합니다.

또 다른 문제가 있습니다. 허용하면 구성 유형의 진화에 대한 견고성이 더욱 제한됩니다. 이제 이전 버전과의 호환성을 유지하면서 추가할 수 있는 유형은 구성 유형의 모든 작업을 허용하는 유형뿐입니다.

이 모든 것이 아주 작은(있는 경우) 유형의 이익을 위해 정말 지저분해 보입니다.

이제 이전 버전과의 호환성을 유지하면서 추가할 수 있는 유일한 유형은 구성 유형의 모든 작업을 허용하는 유형입니다.

아, 그리고 너무 이것에 대한 명시합니다 : 그것은 당신이 합에 싱글 형에서 매개 변수 또는 반환 형식이나 변수 또는를 ... 확장하고 싶습니다 결정할 수 없다는 것을 의미한다. 새로운 유형을 추가하면 일부 작업(예: 할당)이 컴파일에 실패하기 때문입니다.l

@Merovius는 "합계 유형의 메소드 세트가 메소드 세트의 교집합을 보유하기 때문에 원래 제안에 호환성 문제의 변형이 이미 존재합니다.
모든 구성 요소 유형 중"입니다. 따라서 해당 메서드 집합을 구현하지 않는 새 구성 요소 유형을 추가하면 이전 버전과 호환되지 않는 변경 사항이 됩니다.

아, 그리고 이것에 대해서도 명시적으로 말해야 합니다. 매개변수나 반환 유형 또는 변수를 확장하거나… 새로운 유형을 추가하면 일부 작업(예: 할당)이 컴파일에 실패하기 때문입니다.l

할당 동작은 @rogpeppe 에서 설명한 대로 유지되지만 전반적으로 이 점을 이해하고 있는지 잘 모르겠습니다.

다른 것이 아니라면 유형 스위치 외부의 합계 유형 동작에 대해 원래 rogpeppe 제안을 명확히 해야 한다고 생각합니다. 할당 및 메서드 집합이 포함되지만 그게 전부입니다. 평등은 어떻습니까? 인터페이스가 하는 것보다{} 더 잘할 수 있다고 생각합니다.

var x int | float64
fmt.Println(x == "hello")  // compilation error?
x = 0.0
fmt.Println(x == 0) // true or false?  I vote true :-)

따라서 해당 메서드 집합을 구현하지 않는 새 구성 요소 유형을 추가하면 이전 버전과 호환되지 않는 변경 사항이 됩니다.

항상 메서드를 추가할 수 있지만 새 형식에서 작동하도록 연산자를 오버로드할 수는 없습니다. 이것이 정확히 차이점입니다. 그들의 제안에서 type-assertion/-switch로 래핑을 해제하지 않는 한 합계 값에 대해서만 공통 메서드를 호출하거나 할당할 수 있습니다. 따라서 추가하는 유형에 필요한 메서드가 있는 한 주요 변경 사항은 아닙니다. 사용자가 오버로드할 수 없는 연산자를 사용할 수 있기 때문에 제안서에서는 여전히 주요 변경 사항이 될 것입니다.

(유형 스위치에는 새로운 유형이 포함되지 않기 때문에 합계에 유형을 추가하는 것은 여전히 ​​중요한 변경 사항이라는 점을 지적할 수 있습니다. 이것이 바로 제가 원래 제안에 찬성하지 않는 이유입니다. 바로 그 이유로 폐쇄 총액을 원하지 않습니다)

할당 동작은 @rogpeppe에서 설명한 대로 유지됩니다.

이들의 제안은 합계 값을 할당에 대해 이야기, 나는 (그 구성 부품 중 하나에) 합 값에서 할당에 대해 이야기. 나는 그들의 제안이 이것을 허용하지 않는다는 데 동의하지만 차이점은 그들의 제안이 이러한 가능성을 추가하는 것에 관한 것이 아니라는 것입니다. 즉, 내 주장은 정확히 당신이 제안한 의미론이 특히 유익하지 않다는 것입니다. 왜냐하면 실제로 그들이 얻는 사용법은 심각하게 제한되어 있기 때문입니다.

fmt.Println(x == "hello") // compilation error?

이것은 아마도 그들의 제안에도 추가될 것입니다. 우리는 이미 인터페이스 에 를 가지고 있습니다 . 즉,

비인터페이스 유형 X의 값 x와 인터페이스 유형 T의 값 t는 유형 X의 값이 비교 가능하고 X가 T를 구현하는 경우 비교 가능합니다. t의 동적 유형이 X와 동일하고 t의 동적 값이 x와 동일한 경우 동일합니다. .

fmt.Println(x == 0) // true or false? I vote true :-)

아마도 거짓. 유사하다는 점을 감안하면

var x int|float64 = 0.0
y := 0
fmt.Println(x == y)

컴파일 오류여야 합니다(위에서 결론을 내렸듯이). 이 질문은 형식화되지 않은 숫자 상수와 비교할 때만 의미가 있습니다. 그 시점에서 이것이 사양에 추가되는 방식에 따라 다릅니다. 이것은 인터페이스 유형에 상수를 할당하는 것과 유사하므로 기본 유형을 가져야 한다고 주장할 수 있습니다. 그러면 비교는 거짓이 됩니다. 어떤 IMO가 괜찮은 것 이상인지, 우리는 오늘날 많은 혼란 없이 받아들입니다 . 그러나 합계에 할당/비교하는 경우를 다루는 형식화되지 않은 상수의 사양에 사례를 추가하고 그런 식으로 문제를 해결할 수도 있습니다.

그러나 어느 쪽이든 이 질문에 답한다고 해서 구성 부분에 의미가 있을 수 있는 합계 유형을 사용하는 모든 표현식을 허용할 필요는 없습니다.

하지만 반복해서 말씀드리자면, 저는 액수에 대해 다른 제안을 찬성하는 것이 아닙니다. 나는 이것에 대해 논쟁하고 있습니다.

fmt.Println(x == "hello") // compilation error?

이것은 아마도 그들의 제안에도 추가될 것입니다.

수정: 사양에 명령문이 포함되어 있는 경우 이 컴파일 오류가 이미 포함되어 있습니다.

모든 비교에서 첫 번째 피연산자는 두 번째 피연산자의 유형에 할당할 수 있어야 하며 그 반대의 경우도 마찬가지입니다.

@Merovius 당신은 제안의 변형에 대해 몇 가지 좋은 점을 지적합니다. 더 이상의 논쟁은 삼가겠지만, 0번 질문에 대한 비교는 원래 제안에도 동일하게 적용되기 때문에 조금 더 파고들고 싶습니다.

fmt.Println(x == 0) // true or false? I vote true :-)

아마도 거짓. 유사하다는 점을 감안하면

var x int|float64 = 0.0
y := 0
fmt.Println(x == y)
컴파일 오류여야 합니다(위에서 결론).

첫 번째 줄을 var x float64 = 0.0 로 변경하면 동일한 추론을 사용하여 float64를 0과 비교하는 것이 거짓이어야 한다고 주장할 수 있기 때문에 이 예제가 그다지 매력적이지 않다고 생각합니다. (사소한 점: (a) 0.0이 int에 할당 가능하기 때문에 첫 번째 줄에서 float64(0)을 의미했다고 가정합니다. (b) x==y는 예제에서 컴파일 오류가 아니어야 합니다. 그래도 false로 인쇄되어야 합니다.)

"이것은 인터페이스 유형에 상수를 할당하는 것과 유사하므로 기본 유형을 가져야 한다"는 귀하의 생각이 더 설득력이 있다고 생각합니다(합계 유형을 의미한다고 가정). 따라서 예는 다음과 같습니다.

var x,y int|float64 = float64(0), 0
fmt.Println(x == y) // 거짓

나는 여전히 x == 0 가 사실이어야 한다고 주장합니다. 내 정신 모델은 가능한 한 늦게 유형이 0으로 지정된다는 것입니다. 나는 이것이 바로 내가 그것을 가져온 이유인 인터페이스의 현재 동작에 반대된다는 것을 알고 있습니다. 나는 이것이 "많은 퍼지"로 이어지지 않는다는 데 동의하지만 인터페이스를 nil과 비교하는 유사한 문제로 인해 많은 혼란이 발생했습니다. 합계 유형이 존재하고 이전 평등 의미 체계가 유지된다면 0과 비교하기 위해 비슷한 정도의 혼란을 겪을 것이라고 생각합니다.

첫 번째 줄을 var x float64 = 0.0으로 변경하면 동일한 추론을 사용하여 float64를 0과 비교하는 것이 거짓이어야 한다고 주장할 수 있기 때문에 이 예제가 그다지 매력적이지 않다고 생각합니다.

나는 그것이 되어야 한다고 말하지 않았고, 아마도 그것이 내가 그들의 제안이 구현될 방법에 대한 단순성/유용성 사이의 가장 가능성 있는 절충안으로 인식되는 것을 감안할 때 그렇게 될 것이라고 말했습니다. 나는 가치 판단을 하려고 하지 않았다. 사실, 간단한 규칙으로 우리가 그것을 사실로 인쇄할 수 있다면 나는 아마도 그것을 선호하는 경향이 있을 것입니다. 저는 낙관적이지 않습니다.

float64(0) 를 int(0) 와 비교하는 것(즉, 합계가 var x float64 = 0.0 로 대체된 예)은 false 가 아니지만 컴파일 시간입니다. 오류 (당연히). 이것이 바로 제 요점입니다 . 당신의 제안은 형식이 지정되지 않은 상수와 결합될 때만 정말 유용합니다. 다른 것은 컴파일되지 않기 때문입니다.

(a) 0.0을 int에 할당할 수 있기 때문에 첫 번째 줄에서 float64(0)을 의미했다고 가정합니다.

물론입니다(나는 상수 표현식에 대한 현재 "기본 유형"에 더 가까운 의미론을 가정했지만 현재 문구가 그것을 의미하지 않는다는 데 동의합니다).

(b) x==y는 예제에서 컴파일 오류가 되어서는 안 됩니다. 그래도 false로 인쇄되어야 합니다.)

아니요, 컴파일 시간 오류여야 합니다. e1 가 합계 유형 표현식인 e1 == y 작업은 표현식이 구성 유형을 선택하여 컴파일되는 경우에만 허용되어야 한다고 말했습니다. 내 예에서 x 에는 int|float64 유형이 있고 y 에는 int 유형이 있고 float64 및 int 있다고 가정하면

이 컴파일을 하려면 대체하는 모든 구성 유형 표현식도 컴파일해야 하는 조건을 삭제해야 합니다. 이 시점에서 우리는 이러한 표현식("C 엉망"이라고도 함)에서 사용될 때 유형이 승격되거나 변환되는 방법에 대한 규칙을 설정해야 하는 상황에 있습니다.

과거의 합의는 sum 유형이 인터페이스 유형에 별로 추가되지 않는다는 것이었습니다.

Go의 대부분의 사용 사례에는 실제로 적용되지 않습니다: 사소한 네트워크 서비스 및 유틸리티. 그러나 시스템이 커지면 유용할 가능성이 높습니다.
저는 현재 많은 로직을 통해 구현된 데이터 일관성 보장과 함께 심하게 분산된 서비스를 작성하고 있으며 편리할 상황에 몰렸습니다. 이러한 NPD는 서비스가 커짐에 따라 너무 짜증이 났고 이를 분할할 올바른 방법이 보이지 않습니다.
Go의 유형 시스템 보증은 일반적인 기본 네트워크 서비스보다 더 복잡한 것에 대해 너무 약합니다.

그러나 Rust에 대한 이야기는 Haskell에서 하는 것처럼 NPD 및 오류 처리에 합계 유형을 사용하는 것이 좋지 않다는 것을 보여줍니다. 일반적인 자연 명령형 워크플로가 있고 Haskellish 접근 방식은 이에 잘 맞지 않습니다.

예시

의사 코드에서 iotuils.WriteFile 같은 기능을 고려하십시오. 명령 흐름은 다음과 같습니다.

file = open(name, os.write)
if file is error
    return error("cannot open " + name + " writing: " + file.error)
if file.write(data) is error:
    return error("cannot write into " + name + " : " + file.error)
return ok

Rust에서 어떻게 보이는지

match open(name, os.write)
    file
        match file.write(data, os.write)
            err
                return error("cannot open " + name + " writing: " + err)
            ok
                return ok
    err
        return error("cannot write into " + name + " : " + err)

안전하지만 추합니다.

그리고 내 제안:

type result[T, Err] oneof {
    default T
    Error Err
}

프로그램이 어떻게 생겼는지 ( result[void, string] = !void )

file := os.Open(name, ...)
if !file {
    return result.Error("cannot open " + name + " writing: " + file.Error)
}
if res := file.Write(data); !res {
    return result.Error("cannot write into " + name + " : " + res.Error)
}
return ok

여기서 기본 분기는 익명이고 오류 분기는 .Error 로 액세스할 수 있습니다(알려지면 결과는 오류임). 파일이 성공적으로 열리면 사용자는 변수 자체를 통해 파일에 액세스할 수 있습니다. 먼저 file 가 성공적으로 열렸는지 확인하고 그렇지 않으면 종료합니다(따라서 추가 명령문은 파일이 오류가 아님을 알고 있습니다).

보시다시피 이 접근 방식은 명령적 흐름을 유지하고 형식 안전성을 제공합니다. NPD 처리도 비슷한 방식으로 수행할 수 있습니다.

type Reference[T] oneof {
    default T
    nil
}
// Reference[T] = *T

처리는 결과와 유사합니다.

@sirkon , 귀하의 Rust 예제는 Rust에서와 같이 간단한 합계 유형에 문제가 있다는 것을 확신하지 못합니다. 오히려, 합계 유형에 대한 패턴 일치가 if 문을 사용하여 더 Go-like가 될 수 있음을 시사합니다. 다음과 같은 것:

ferr := os.Open(name, ...)
if err(e) := ferr {           // conditional match and unpack, initializing e
  return fmt.Errorf("cannot open %v: %v", name, e)
}
ok(f) := ferr                  // unconditional match and unpack, initializing f
werr := f.Write(data)
...

(Sum 유형의 정신에서 컴파일러가 무조건 일치하는 경우가 정확히 하나만 남아 있기 때문에 무조건 일치가 항상 성공한다는 것을 증명할 수 없으면 컴파일 오류가 됩니다.)

기본 오류 검사의 경우 한 줄 더 길고 지역 변수를 하나 더 선언하기 때문에 여러 반환 값에 비해 개선된 것처럼 보이지 않습니다. 그러나 (if 문을 더 추가하여) 여러 사례로 확장할 수 있으며 컴파일러는 모든 사례가 처리되는지 확인할 수 있습니다.

@sirkon

Go의 대부분의 사용 사례에는 실제로 적용되지 않습니다: 사소한 네트워크 서비스 및 유틸리티. 그러나 시스템이 커지면 유용할 가능성이 높습니다.
[…]
Go의 유형 시스템 보증은 일반적인 기본 네트워크 서비스보다 더 복잡한 것에 대해 너무 약합니다.

이러한 발언은 불필요하게 대립적이고 경멸적입니다. 그들은 또한 일종의 당혹스러운 TBH입니다. Go로 작성된 매우 크고 사소한 서비스가 있기 때문입니다. 그리고 상당 부분의 개발자가 Google에서 일하고 있다는 점을 감안할 때 크고 사소한 서비스를 작성하는 데 적합하다면 그들이 당신보다 더 잘 알고 있다고 가정해야 합니다. Go는 모든 사용 사례를 다루지 않을 수도 있지만(IMO도 마찬가지임) 경험적으로 "기본 네트워크 서비스"에서만 작동하는 것은 아닙니다.

NPD 처리도 비슷한 방식으로 수행할 수 있습니다.

이것은 귀하의 접근 방식이 실제로 중요한 가치를 추가하지 않는다는 것을 실제로 보여줍니다. 지적했듯이 역참조를 위해 다른 구문을 추가하기만 하면 됩니다. 그러나 AFAICT는 프로그래머가 nil-value(아마도 여전히 패닉 상태일 것입니다)에서 해당 구문을 사용하는 것을 방해하지 않습니다. 즉, *p 사용하여 유효한 모든 프로그램은 p.T 사용하여도 유효합니다(또는 p.default 입니까? 귀하의 아이디어 가 구체적으로 무엇인지 말하기 어렵습니다).

합계 유형이 오류 처리 및 nil-dereferences에 추가할 수 있는 한 가지 이점은 컴파일러에서 패턴 일치를 통해 작업이 안전하다는 것을 증명해야 한다고 강제할 수 있다는 것입니다. 를 생략는 집행 테이블에 중요한 새로운 일을 가지고 보이지 않는 것을하는 제안을 포함 않는 제안은 당신이 "못생긴"로 설명 정확히 무엇을하는 동안, (틀림없이,이 인터페이스를 통해 공개 금액을 사용하는 것보다 더 나쁘다).

@메로비우스

그리고 개발자의 상당 부분이 Google에서 근무한다는 점을 감안할 때 그들이 당신보다 더 잘 알고 있다고 가정해야 합니다.

믿는 자는 복이 있습니다.

지적했듯이 역참조를 위해 다른 구문을 추가하기만 하면 됩니다.

다시

var written int64
...
res := os.Stdout.Write(data) // Write([]byte) -> Result[int64, string] ≈ !int64
written += res // Will not compile as res is a packed result type
if !res {
    // we are living on non-default res branch thus the only choice left is the default
    return Result.Error(...)
}
written += res // is OK

@skybrian

ferr := os.Open(...)

이 중간 변수가 내가 이 생각을 떠나게 만드는 요인입니다. 보시다시피, 제 접근 방식은 특히 오류 및 nil 처리를 위한 것입니다. 이러한 작은 작업은 너무 중요하며 IMO에 특별한 주의를 기울일 가치가 있습니다.

@sirkon 당신은 사람들과 눈을

대화를 정중하게 유지하고 건설적이지 않은 말을 피하십시오. 우리는 일에 대해 의견이 다를 수 있지만 여전히 존경할 만한 담론을 유지합니다. https://golang.org/conduct.

그리고 개발자의 상당 부분이 Google에서 일한다는 점을 감안할 때 그들이 당신보다 더 잘 알고 있다고 가정해야 합니다.

나는 당신이 구글에서 그런 종류의 논쟁을 할 수 있을지 의심스럽다.

@hasufell 그 사람은 독일에서 왔으며 면접관의 자존심과 거물 경영을 펌핑하기 위해 쓰레기 인터뷰를하는 대규모 IT 회사가 없습니다. 나옵니다 .

@sirkon도 마찬가지입니다. Ad-hominem 및 사회적 논쟁은 유용하지 않습니다. 이것은 CoC 문제 이상입니다. 저는 핵심 언어에 대해 이런 종류의 "사회적 논쟁"이 다소 자주 나타나는 것을 보았습니다. 컴파일러 개발자가 더 잘 알고, 언어 디자이너가 더 잘 알고, Google 사람들이 더 잘 압니다.

아니, 그들은하지 않습니다. 지적 권위가 없습니다. 다만 결정권이 있을 뿐이다. 극복해.

대화를 재설정하기 위해 몇 가지 의견을 숨겼 습니다. (그리고 다시 노력한 @agnivade 에게 감사드립니다).

여러분, 우리의 Gopher 가치 에 비추어 이러한 토론에서 귀하의 역할을 고려하십시오. 커뮤니티의 모든 사람은 관점을 가지고 있으며, 우리는 서로를 해석하고 대응하는 방식에서 존중하고 자선하기 위해 노력해야 합니다.

이 토론에 내 2센트를 추가할 수 있습니다.

(인터페이스와 같이) 메소드 세트 이외의 기능으로 서로 다른 유형을 함께 그룹화하는 방법이 필요합니다. 새로운 그룹화 기능은 메소드가 없는 기본(또는 기본) 유형을 포함하고 인터페이스 유형이 관련 유사하게 분류되도록 허용해야 합니다. 우리는 기본 유형(boolean, numeric, string, 심지어 []byte, []int 등)을 있는 그대로 유지할 수 있지만 유형 정의가 패밀리로 그룹화하는 유형 간의 차이점을 추상화할 수 있습니다.

언어에 type _family_ 구조와 같은 것을 추가하는 것이 좋습니다.

구문

유형 패밀리는 다른 유형과 매우 유사하게 정의할 수 있습니다.

type theFamilyName family {
    someType
    anotherType
}

형식 구문은 다음과 같습니다.
FamilyType = "family" "{" { TypeName ";" } "}" .

유형 패밀리는 함수 서명 내부에 정의될 수 있습니다.

func Display(s family{string; fmt.Stringer}) { /* function body */ }

즉, 한 줄 정의에서는 유형 이름 사이에 세미콜론이 필요합니다.

패밀리 유형의 0 값은 nil 인터페이스와 마찬가지로 nil입니다.

(후드에서 패밀리 추상화 뒤에 있는 값은 인터페이스와 매우 유사하게 구현됩니다.)

추론

함수에 대한 인수 또는 함수의 반환으로 유효한 유형을 지정하려는 빈 인터페이스보다 더 정확한 것이 필요합니다.

제안된 솔루션은 더 나은 형식 안전성을 가능하게 하고 컴파일 시간에 완전히 검사되며 런타임에 추가 오버헤드를 추가하지 않습니다.

요점은 _Go 코드가 더 자체 문서화되어야 한다는 것입니다_. 함수가 인수로 취할 수 있는 것은 코드 자체에 내장되어야 합니다.

너무 많은 코드는 "인터페이스{}가 아무 것도 말하지 않음"이라는 사실을 잘못 악용합니다. Go에서 그렇게 널리 사용되는(그리고 남용되는) 구성이 없으면 우리가 많은 것을 할 수 없을 것이라고 _아무것도_ 말합니다.

몇 가지 예

sql.Rows.Scan 함수에 대한 문서에는 함수에 전달할 수 있는 유형을 자세히 설명하는 큰 블록이 포함되어 있습니다.

Scan converts columns read from the database into the following common Go types and special types provided by the sql package:
 *string
 *[]byte
 *int, *int8, *int16, *int32, *int64
 *uint, *uint8, *uint16, *uint32, *uint64
 *bool
 *float32, *float64
 *interface{}
 *RawBytes
 any type implementing Scanner (see Scanner docs)

그리고 sql.Row.Scan 함수의 경우 문서에는 "자세한 내용은 Rows.Scan 문서 참조"라는 문장이 포함되어 있습니다. 자세한 내용은 _일부 다른 기능_에 대한 설명서를 참조하세요. 이것은 Go-like가 아니며 실제로 Rows.Scan 는 *RawBytes 값을 가질 수 있지만 Row.Scan 는 그렇지 않기 때문에 이 문장은 올바르지 않습니다.

문제는 컴파일러가 시행할 수 없는 보증 및 행동 계약에 대한 주석에 의존해야 하는 경우가 많다는 것입니다.

함수에 대한 문서에서 함수가 다른 함수처럼 작동한다고 말할 때("그러므로 다른 함수에 대한 문서를 참조하십시오.") 때때로 해당 함수가 오용된다는 것을 거의 보장할 수 있습니다. 나는 대부분의 사람들이 자신처럼 만 발견했다고 장담하는 *RawBytes 에 인수로 허용되지 않습니다 Row.Scan 단지에서 오류가 발생 후 Row.Scan ( "sql: RawBytes는 Row.Scan에서 허용되지 않습니다"). 유형 시스템이 그러한 실수를 허용한다는 것은 슬픈 일입니다.

대신 다음을 수행할 수 있습니다.

type Value family {
    *string
    *[]byte
    *int; *int8; *int16; *int32; *int64
    *uint; *uint8; *uint16; *uint32; *uint64
    *bool
    *float32; *float64
    *interface{}
    *RawBytes
    Scanner
}

이런 식으로 전달된 값은 지정된 패밀리의 유형 중 하나여야 하며 Rows.Scan 함수 내부의 유형 전환은 예기치 않은 또는 기본 경우를 처리할 필요가 없습니다. Row.Scan 함수에 대한 또 다른 패밀리가 있습니다.

cloud.google.com/go/datastore.Property 구조체에 interface{} 유형의 "값" 필드가 있고 이 모든 문서가 필요한 방법도 고려하십시오.

// Value is the property value. The valid types are:
// - int64
// - bool
// - string
// - float64
// - *Key
// - time.Time
// - GeoPoint
// - []byte (up to 1 megabyte in length)
// - *Entity (representing a nested struct)
// Value can also be:
// - []interface{} where each element is one of the above types
// This set is smaller than the set of valid struct field types that the
// datastore can load and save. A Value's type must be explicitly on
// the list above; it is not sufficient for the underlying type to be
// on that list. For example, a Value of "type myInt64 int64" is
// invalid. Smaller-width integers and floats are also invalid. Again,
// this is more restrictive than the set of valid struct field types.
//
// A Value will have an opaque type when loading entities from an index,
// such as via a projection query. Load entities into a struct instead
// of a PropertyLoadSaver when using a projection query.
//
// A Value may also be the nil interface value; this is equivalent to
// Python's None but not directly representable by a Go struct. Loading
// a nil-valued property into a struct will set that field to the zero
// value.

이것은 다음과 같을 수 있습니다.

type PropertyVal family {
  int64
  bool
  string
  float64
  *Key
  time.Time
  GeoPoint
  []byte
  *Entity
  nil
  []int64; []bool; []string; []float64; []*Key; []time.Time; []GeoPoint; [][]byte; []*Entity
}

(이것이 어떻게 두 가족으로 더 깔끔하게 나눌 수 있는지 상상할 수 있습니다.)

json.Token 유형은 위에서 언급했습니다. 유형 정의는 다음과 같습니다.

type Token family {
    Delim
    bool
    float64
    Number
    string
    nil
}

내가 최근에 얻은 또 다른 예:
같은 함수를 호출하면 sql.DB.Exec 또는 sql.DB.Query 또는의 가변에서 받아 처리하는 기능 interface{} 각 요소는 특정 세트의 형태를 가져야 어디에 자체가 될 _not을 slice_, []interface{} 에서 이러한 함수로 인수를 전달할 때 "확산" 연산자를 사용하는 것을 기억하는 것이 중요합니다. DB.Exec("some query with placeholders", emptyInterfaceSlice) 라고 말하는 것은 잘못되었습니다. 올바른 방법은 DB.Exec("the query...", emptyInterfaceSlice...) emptyInterfaceSlice 유형이 []interface{} 입니다. 이러한 실수를 불가능하게 만드는 우아한 방법은 이 함수가 Value 의 가변 인수를 취하도록 하는 것입니다. 여기서 Value 는 위에서 설명한 대로 패밀리로 정의됩니다.

이 예제의 요점은 interface{} 의 부정확성 때문에 _실제 실수가 발생하고 있다는 것입니다.

var x int | float64 | string | rune
z = int(x) + int(y)
z = float64(x) + float64(y)

의 종류 때문에 이것은 확실히 컴파일러 오류해야 x 전달 될 수있는 정말 호환되지 않습니다 int() .

family 라는 아이디어가 마음에 듭니다. 본질적으로 나열된 유형으로 제한된(제한된?) 인터페이스가 될 것이며 컴파일러는 항상 일치하는지 확인하고 해당 case 의 로컬 컨텍스트 내에서 변수 유형을 변경할 수 있습니다.

문제는 우리가 종종 보증과
컴파일러가 시행할 수 없는 행동 계약.

그것이 사실 내가 다음과 같은 것을 약간 싫어하기 시작한 이유입니다.

func foo() (..., error) 

어떤 종류의 오류가 반환되는지 모르기 때문입니다.

구체적인 유형 대신 인터페이스를 반환하는 몇 가지 다른 것들. 일부 기능
net.Addr 반환하고 실제로 어떤 종류의 net.Addr 반환하고 적절하게 사용하는지 파악하기 위해 소스 코드를 파헤치는 것이 때때로 약간 어렵습니다. 구체적인 유형을 반환하는 데 실제로 큰 단점은 없습니다(인터페이스를 구현하므로 인터페이스를 사용할 수 있는 모든 곳에서 사용할 수 있기 때문).
나중에 다른 종류의 net.Addr 를 반환하도록 메서드를 확장할 계획입니다. 하지만 만약 당신의
API에서 OpError 를 반환한다고 언급한 경우 해당 부분을 "컴파일 시간" 사양으로 지정하지 않는 이유는 무엇입니까?

예를 들어:

 OpError is the error type usually returned by functions in the net package. It describes the operation, network type, and address of an error. 

대개? 어떤 함수가 이 오류를 반환하는지 정확히 알려주지 않습니다. 그리고 이것은 함수가 아니라 유형에 대한 문서입니다. Read 대한 문서에는 OpError가 반환된다는 언급이 없습니다. 또한 하면

err := blabla.(*OpError)

다른 종류의 오류를 반환하면 충돌합니다. 이것이 내가 이것을 함수 선언의 일부로 보고 싶은 이유입니다. 적어도 *OpError | error 는 반환한다고 말할 것입니다.
이러한 오류와 컴파일러는 미래에 프로그램을 충돌시키는 검사되지 않은 형식 주장을 수행하지 않도록 합니다.

BTW: Haskell의 유형 다형성과 같은 시스템이 아직 고려되지 않았습니까? 또는 '특성' 기반 유형 시스템 예:

func calc(a < add(a, a) a >, b a) a {
   return add(a, b)
}

func drawWidgets(widgets []< widgets.draw() error >) error {
  for _, widgets := range widgets {
    err := widgets.draw()
    if err != nil {
      return err
    }
  }
  return nil
}

a < add(a, a) a 는 "a의 유형이 무엇이든 간에 add(typeof a, typeof a) typeof a) 함수가 있어야 함"을 의미합니다. < widgets.draw() error> 는 "위젯의 유형이 무엇이든 간에 오류를 반환하는 메서드 그리기를 제공해야 함"을 의미합니다. 이렇게 하면 보다 일반적인 함수를 만들 수 있습니다.

func Sum(a []< add(a,a) a >) a {
  sum := a[0]
  for i := 1; i < len(a); i++ {
    sum = add(sum,a[i])
  }
  return sum
}

(이것은 기존의 "제네릭"과 같지 않습니다.)

다른 종류의 net.Addr 를 반환하도록 나중에 메서드를 확장할 계획인 경우를 제외하고는 구체적인 유형을 반환하는 데 실제로 큰 단점이 없습니다(인터페이스를 구현하고 따라서 인터페이스를 사용할 수 있는 모든 곳에서 사용할 수 있기 때문입니다). .

또한 Go에는 변형 하위 유형이 없으므로 필요한 경우 func() *FooError 를 func() error 로 사용할 수 없습니다. 인터페이스 만족도에 특히 중요합니다. 마지막으로 이것은 컴파일되지 않습니다.

func Foo() (FooVal, FooError) {
    // ...
}

func Bar(f FooVal) (BarVal, BarError) {
    // ...
}

func main() {
    foo, err := Foo()
    if err != nil {
        log.Fatal(err)
    }
    bar, err := Bar(foo) // Type error: Can not assign BarError to err (type FooError)
    if err != nil {
        log.Fatal(err)
    }
}

즉, 이 작업을 수행하려면(어떻게든 할 수만 있다면) 훨씬 더 정교한 유형 추론이 필요합니다. 현재 Go는 단일 표현식의 로컬 유형 정보만 사용합니다. 내 경험에 따르면 이러한 유형의 유추 알고리즘은 상당히 느릴 뿐만 아니라(컴파일 속도가 느려지고 일반적으로 런타임 제한도 없음) 이해하기 훨씬 어려운 오류 메시지를 생성합니다.

또한 Go에는 변형 하위 유형이 없으므로 필요한 경우 func() *FooError를 func() 오류로 사용할 수 없습니다. 인터페이스 만족도에 특히 중요합니다. 마지막으로 이것은 컴파일되지 않습니다.

나는 이것이 Go에서 잘 작동할 것이라고 예상했지만 현재 관행은 error 사용하는 것이기 때문에 나는 이것을 우연히 본 적이 없습니다. 그러나 예, 이 경우 이러한 제한으로 인해 실제로 error 를 반환 유형으로 사용해야 합니다.

func main() {
    foo, err := Foo()
    if err != nil {
        log.Fatal(err)
    }
    bar, err := Bar(foo) // Type error: Can not assign BarError to err (type FooError)
    if err != nil {
        log.Fatal(err)
    }
}

나는 이것을 허용하는 언어를 알지 못하지만 (esolang은 제외) "유형 세계"(기본적으로 variable -> type 의 지도임)를 유지하기만 하면 됩니다. - "유형 세계"에서 유형을 업데이트한 변수를 할당합니다.

이 작업을 수행하기 위해 복잡한 유형 추론이 필요하다고 생각하지 않지만 변수 유형을 추적해야 하지만 어쨌든 그렇게 해야 한다고 가정합니다.

var int i = 0;
i = "hi";

어떤 변수/선언에 어떤 유형이 있는지 기억해야 하며 i = "hi" 에 대해 문자열을 할당할 수 있는지 확인하기 위해 i 에 대한 "유형 조회"를 수행해야 합니다.

func () *ConcreteError 를 func() error 할당하는 것을 복잡하게 만드는 실질적인 문제가 있습니까(예: 런타임 이유/컴파일된 코드 이유)? 현재 다음과 같은 함수로 래핑해야 할 것 같습니다.

type MyFunc func() error

type A struct {
}

func (_ *A) Error() string { return "" }

func NewA() *A {
    return &A{}
}

func main() {
    var err error = &A{}
    fmt.Println(err.Error())
    var mf MyFunc = MyFunc(func() error { return NewA() }) // type checks fine
        //var mf MyFunc = MyFunc(NewA) // doesn't type check
    _ = mf
}

func (a, b) c 직면했지만 func (x, y) z 를 받았다면 z 가 c (및 a , b 는 x , y 할당할 수 있어야 합니다. 이는 최소한 유형 수준에서 복잡한 유형 추론을 포함하지 않습니다(단지 유형은 다른 유형에 할당 가능/호환 가능). 물론 이것이 런타임/컴파일에 문제를 일으키는지 여부는... 잘 모르겠습니다. 하지만 적어도 형식 수준을 엄격하게 살펴보면 왜 이것이 복잡한 형식 유추를 포함하는지 알 수 없습니다. 유형 검사기는 x 가 a 할당될 수 있는지 이미 알고 있으므로 func () x 가 func () a 할당될 수 있는지 여부도 쉽게 알 수 있습니다. 물론 이것이 쉽게 가능하지 않은 실제적인 이유(런타임 표현에 대해 생각하는 것)가 있을 수 있습니다. (나는 그것이 실제 유형 검사가 아니라 실제 핵심이라고 의심하고 있습니다.)

이론적으로 위의 스니펫에서와 같이 자동으로 함수를 래핑하는 런타임 문제(있는 경우)를 해결할 수 있습니다. _잠재적으로 거대한_ 단점은 func와 func의 비교를 망친다는 것입니다(래핑된 func가 func와 같지 않기 때문입니다). 랩).

나는 이것을 허용하는 언어를 알지 못합니다 (글쎄, esolang 제외)

정확하지는 않지만 강력한 유형 시스템을 가진 언어는 일반적으로 변수를 실제로 사용 하지 않는 기능적 언어이기 때문에(따라서 식별자를 재사용하는 기능이 실제로 필요하지 않기 때문이라고 주장하고 싶습니다.) FWIW, 예를 들어 Haskell의 유형 시스템이 이것을 잘 처리할 수 있다고 주장합니다. 적어도 FooError 또는 BarError 다른 속성을 사용하지 않는 한 err 가 error 유형임을 추론하고 처리할 수 있습니다. 물론 이 정확한 상황이 함수형 언어로 쉽게 전환되지 않기 때문에 이것은 가상의 것입니다.

그러나 나는 당신이 어쨌든 그렇게 할 필요가 있다고 가정합니다. 왜냐하면

차이의 존재, 귀하의 예제에서 i 첫 번째 행 다음에 명확하고 잘 알려진 유형을 가지고 int 그리고 당신은 할당 할 때 당신은 다음 유형의 오류로 실행 string . 한편, 내가 언급한 것과 같이 식별자의 모든 사용은 본질적으로 사용된 유형에 대한 일련의 제약 조건을 생성하고 유형 검사기는 주어진 모든 제약 조건을 충족하는 가장 일반적인 유형을 유추하려고 시도합니다(또는 이를 충족하는 유형이 없다고 불평합니다. 계약). 그것이 형식적 유형 이론이 필요한 이유입니다.

func () *ConcreteError 를 func() error 할당하는 것을 복잡하게 만드는 실질적인 문제가 있습니까(예: 런타임 이유/컴파일된 코드 이유)?

실용적인 문제가 있지만 func 경우 해결할 수 있다고 생각합니다(인터페이스 전달 작동 방식과 유사하게 un/-wrapping 코드를 내보냄으로써). 나는 Go의 변화에 대해 약간 썼고 하단에서 볼 수 있는 몇 가지 실용적인 문제를 설명했습니다. 그래도 추가할 가치가 있다고 완전히 확신하지는 않습니다. 즉, 중요한 문제를 자체적으로 해결하는지 확신할 수 없습니다.

잠재적으로 큰 단점은 func와 func의 비교를 망친다는 것입니다(래핑된 func가 감싸는 func와 같지 않기 때문에).

기능은 비교할 수 없습니다.

어쨌든, TBH, 이 모든 것이 이 문제의 주제에서 약간 벗어난 것 같습니다. :)

참고: 방금 했습니다 . 좋지는 않지만 유형 안전합니다. (#19814 FWIW에서도 동일한 작업을 수행할 수 있습니다.)

파티에 조금 늦었지만 바둑 4년 후의 느낌을 여러분과 함께 나누고 싶습니다.

• 다중 가치 반환은 큰 실수였습니다.
• Nil-able 인터페이스는 실수였습니다.
• 포인터는 "선택 사항"의 동의어가 아니므로 구별된 공용체를 대신 사용해야 합니다.
• JSON 문서에 필수 필드가 포함되지 않은 경우 JSON 언마샬러에서 오류를 반환해야 합니다.

지난 4년 동안 나는 이와 관련된 많은 문제를 발견했습니다.

• 오류가 발생하면 가비지 데이터가 반환됩니다.
• 구문 혼란(오류의 경우 0 값 반환).
• 다중 오류 반환(혼동 API, 제발 그렇게 하지 마세요!).
• nil 가리키는 포인터를 가리키는 nil이 아닌 인터페이스("Go는 쉬운 언어입니다"라는 말을 나쁜 농담처럼 만드는 사람들을 혼란스럽게 합니다).
• 선택되지 않은 JSON 필드는 서버를 충돌시킵니다(예!).
• 확인되지 않은 반환된 포인터는 서버를 크래시하지만 반환된 포인터는 선택 사항(아마도 유형)을 나타내며 따라서 nil (예!)

그러나 이러한 모든 문제를 해결하는 데 필요한 변경 사항은 실제로는 실현되지 않을 이전 버전과 호환되지 않는 Go 2.0.0(Go2 아님) 버전이 필요합니다. 어쨌든...

오류 처리는 다음과 같이 표시되어야 합니다.

// Divide returns either a float64 or an arbitrary error
func Divide(dividend, divisor float64) float64 | error {
  if dividend == 0 {
    return errors.New("dividend is zero")
  }
  if divisor == 0 {
    return errors.New("divisor is zero")
  }
  return dividend / divisor
}

func main() {
  // type-switch statements enforce completeness:
  switch v := Divide(1, 0).(type) {
  case float64:
    log.Print("1/0 = ", v)
  case error:
    log.Print("1/0 = error: ", v)
  }

  // type-assertions, however, do not:
  divisionResult := Divide(3, 1)
  if v, ok := divisionResult.(float64); ok {
    log.Print("3/1 = ", v)
  }
  if v, ok := divisionResult.(error); ok {
    log.Print("3/1 = error: ", v.Error())
  }
  // yet they don't allow asserting types not included in the union:
  if v, ok := divisionResult.(string); ok { // compile-time error!
    log.Print("3/1 = string: ", v)
  }
}

인터페이스는 차별된 공용체를 대체하는 것이 아니라 완전히 다른 두 동물입니다. 컴파일러는 판별된 공용체에 대한 유형 전환이 완전한지 확인합니다. 즉, 케이스가 가능한 모든 유형을 포괄한다는 의미입니다. 이를 원하지 않으면 유형 주장 문을 사용할 수 있습니다.

나는 사람들이 _nil 값에 대한 non-nil 인터페이스_에 대해 완전히 혼란스러워하는 것을 너무 자주 보았습니다 : https://play.golang.org/p/JzigZ2Q6E6F. 일반적으로 사람들은 error 인터페이스가 nil 가리키는 커스텀 오류 유형의 포인터를 가리키고 있을 때 혼란스러워 합니다. 이것이 제가 인터페이스를 nil-able로 만드는 것이 실수라고 생각하는 이유 중 하나입니다.

인터페이스는 접수원과 같아서 대화를 하면 사람이라는 것을 알 수 있지만 Go에서는 카드보드 모양일 수 있으며 대화를 시도하면 세상이 갑자기 무너집니다.

옵셔널(아마도 유형)에 대해 유니온을 구별해야 하고 인터페이스에 nil 포인터를 전달하면 패닉이 발생해야 합니다.

type CustomErr struct {}
func (err *CustomErr) Error() string { return "custom error" }

func CouldFail(foo int) error | nil {
  var err *customErr
  if foo > 10 {
    // you can't return a nil pointer as an interface value
    return err // this will panic!
  }
  // no error
  return nil
}

func main() {
  // assume no error
  if err, ok := CouldFail().(error); ok {
    log.Fatalf("it failed, Jim! %s", err)
  }
}

포인터와 아마도 유형은 상호 교환할 수 없습니다. 선택적 유형에 대한 포인터를 사용하면 API가 혼란스러워지기 때문에 좋지 않습니다.

// P returns a pointer to T, but it's not clear whether or not the pointer
// will always reference a T instance. It might be an optional T,
// but the documentation usually doesn't tell you.
func P() *T {}

// O returns either a pointer to T or nothing, this implies (but still doesn't guarantee)
// that the pointer is always expected to not be nil, in any other case nil is returned.
func O() *T | nil {}

그런 다음 JSON도 있습니다. 컴파일러가 사용하기 전에 강제로 검사하도록 하기 때문에 이것은 유니온에서는 절대 일어날 수 없습니다 . JSON 문서에 필수 필드(포인터 유형의 필드 포함)가 포함되어 있지 않으면 JSON 언마샬러가 실패해야 합니다.

type DataModel struct {
  // Optional needs to be type-checked before use
  // and is therefore allowed to no be included in the JSON document
  Optional string | nil `json:"optional,omitempty"`
  // Required won't ever be nil
  // If the JSON document doesn't include it then unmarshalling will return an error
  Required *T `json:"required"`
}

추신
저는 또한 현재 기능적 언어 디자인 작업을 하고 있으며 이것이 오류 처리를 위해 판별된 공용체를 사용하는 방법입니다.

read = (s String) -> (Array<Byte> or Error) => match s {
  "A" then Error<NotFound>
  "B" then Error<AccessDenied>
  "C" then Error<MemoryLimitExceeded>
  else Array<Byte>("this is fine")
}

main = () -> ?Error => {
  // assume the result is a byte array
  // otherwise throw the error up the stack wrapped in a "type-assertion-failure" error
  r = read("D") as Array<Byte>
  log::print("data: %s", r)
}

언젠가는 이것이 현실이 되는 것을 보고 싶습니다. 제가 조금이나마 도움이 되었으면 합니다.

아마도 문제는 우리가 제안으로 너무 많은 것을 다루려고 하는 것입니다. 단기적으로 언어에 추가하는 것이 훨씬 더 쉬울 수 있도록 대부분의 가치를 가져오는 단순화된 버전을 사용할 수 있습니다.

내 관점에서 이 단순화된 버전은 nil 와 관련이 있을 것 입니다. 다음은 주요 아이디어입니다(거의 모든 아이디어가 이미 주석에서 언급되었습니다).

1. 허용 | "discriminated unions"의
   <any pointer type> | nil
   포인터 유형은 다음과 같습니다. 포인터, 함수, 채널, 슬라이스 및 맵(Go 포인터 유형)
2. 베어 포인터 유형에 nil 할당을 금지합니다. nil을 지정하려면 유형이 <pointer type> | nil 여야 합니다. 예를 들어:

var n *int       = nil // Does not compile, wrong type
var n *int | nil = nil // Ok!

var set map[string] bool       = nil // Does not compile
var set map[string] bool | nil = nil // Ok!

var myFunc func(int) err       = nil // Nope!
var myFunc func(int) err | nil = nil // All right.

이것이 주요 아이디어입니다. 다음은 주요 아이디어에서 파생된 아이디어입니다.

1. 베어 포인터 유형의 변수를 선언하고 초기화하지 않은 상태로 둘 수 없습니다. 그렇게 하려면 | nil 판별 유형을 추가해야 합니다.

var maybeAString *string       // Wrong: invalid initial value
var maybeAString *string | nil // Good

1. 베어 포인터 유형을 "nilable" 포인터 유형에 할당할 수 있지만 그 반대는 할 수 없습니다.

var value int = 42
var barePointer *int = &value          // Valid
var nilablePointer *int | nil = &value // Valid

nilablePointer = barePointer // Valid
barePointer = nilablePointer // Invalid: Incompatible types

1. 다른 사람들이 지적했듯이 "nilable" 포인터 유형에서 값을 가져오는 유일한 방법은 유형 스위치를 사용하는 것입니다. 예를 들어, 위의 예와 다음, 우리가 정말 값 지정하려면 nilablePointer 에 barePointer , 우리는해야 할 것입니다 :

switch val := nilablePointer.(type) {
  case *int:
    barePointer = val // Yeah! Types are compatible now. It is imposible that "val = nil"
  case nil:
    // Do what you need to do when nilablePointer is nil
}

그리고 그게 다야. 나는 차별된 공용체를 훨씬 더 많이 사용할 수 있다는 것을 알고 있지만(특히 오류를 반환하는 경우), 위에서 작성한 것을 고수하면 더 적은 노력으로 언어에 엄청난 가치를 가져다줄 것입니다. 필요 이상으로 복잡합니다.
이 간단한 제안을 통해 얻을 수 있는 이점:

• a) nil 포인터 오류가 없습니다 . 좋아요, 4단어가 그렇게 큰 의미를 가진 적은 없었습니다. 그렇기 때문에 다른 관점에서 말할 필요가 있다고 생각합니다. No Go 프로그램은 _EVER_ nil pointer dereference 오류가 다시 발생합니다! 💥
• b) "성능 대 의도"를 거래하지 않고 함수 매개변수에 대한 포인터를 전달할 수 있습니다.
  이것이 의미하는 바는 함수에 대한 포인터가 아닌 구조체를 전달하려는 경우가 있다는 것입니다. 왜냐하면 해당 함수가 nullity에 대해 걱정하고 매개 변수를 확인하도록 강제하는 것을 원하지 않기 때문입니다. . 그러나 일반적으로 복사 오버헤드를 피하기 위해 포인터를 전달합니다.
• c) 더 이상 nil 맵이 없습니다! 응! 우리는 "safe nil-slice"와 "unsafe nil-maps"에 대한 불일치로 끝낼 것입니다. 지도는 초기화되거나 map | nil 유형이 됩니다. 이 경우 유형 스위치를 사용해야 합니다 😃

그러나 여기에는 많은 가치를 가져다주는 또 다른 무형 자산이 있습니다. 바로 개발자의 마음의 평화입니다 . 포인터, 기능, 채널, 맵 등을 사용하여 작업하고 플레이할 수 있으며 그것들이 0이 되는 것에 대해 걱정할 필요가 없다는 편안한 느낌을 받을 수 있습니다. _내가 지불할거야!_ 😂

이 더 간단한 제안서 버전으로 시작하는 이점은 미래에 전체 제안서를 진행하거나 단계별로 진행하는 것을 중단하지 않는다는 것입니다. , 하지만 지금은 잊어버리자).

한 가지 문제는 제안의 이 간단한 버전도 이전 버전과 호환되지 않지만 gofix 로 쉽게 고칠 수 있다는 것입니다. 모든 포인터 유형 선언을 <pointer type> | nil 됩니다.

어떻게 생각하나요? 이것이 약간의 빛을 비추고 언어에 nil-safety를 포함하는 속도를 높일 수 있기를 바랍니다. 이 방법("차별화된 조합"을 통해)이 이를 달성하는 더 간단하고 직교적인 방법인 것 같습니다.

@alvaroloes

베어 포인터 유형의 변수를 선언하고 초기화하지 않은 상태로 둘 수 없습니다.

이것이 문제의 핵심입니다. 그것은 Go가 하는 일이 아닙니다. 모든 유형은 0 값, 마침표를 갖습니다. 그렇지 않으면, 예를 들어 make([]T, 100) 가 무엇을 합니까? 당신이 언급한 다른 것들(예: 쓰기 시 패닉이 발생하는 nil 맵)은 이 기본 규칙의 결과입니다. (그리고 제쳐두고, 나는 nil-slice가 맵보다 더 안전하다고 말하는 것이 정말로 사실이라고 생각하지 않습니다. nil-slice에 쓰는 것은 nil-map에 쓰는 것만큼 패닉할 것입니다.)

다시 말해서, 당신의 제안은 실제로 그렇게 간단하지 않습니다. Go 언어의 매우 기본적인 디자인 결정에서 상당히 벗어나기 때문입니다.

Go가 하는 더 중요한 일은 단순히 모든 것에 0의 가치를 부여하는 것이 아니라 0의 가치를 유용하게 만드는 것이라고 생각합니다. Nil 맵은 0 값이지만 유용하지 않습니다. 사실 해롭습니다. 따라서 유용하지 않은 경우 0 값을 허용하지 않는 이유는 무엇입니까? 이와 관련하여 Go를 변경하면 도움이 될 것이지만 제안은 실제로 그렇게 간단하지 않습니다.

위의 제안은 Swift 및 기타에서와 같이 선택적/비선택적 종류와 비슷합니다. 멋지지만 다음과 같습니다.

1. 그것은 거의 모든 프로그램을 깨뜨릴 것이고 수정은 gofix에 사소한 것이 아닙니다. 제안에 따라 값을 풀기 위해 유형 전환이 필요하므로 모든 것을 <pointer type> | nil 로 바꿀 수는 없습니다.
2. 이것이 실제로 사용 가능하고 견딜 수 있으려면 이러한 선택 사항에 대해 훨씬 더 많은 구문 설탕이 필요합니다. 예를 들어 스위프트를 보자. 언어에는 특히 옵셔널과 함께 작동하는 많은 기능이 있습니다. 가드, 옵셔널 바인딩, 옵셔널 체인, nil 병합 등. 저는 Go가 그 방향으로 갈 것이라고 생각하지 않지만 옵셔널이 없으면 작업이 귀찮을 것입니다.

따라서 유용하지 않은 경우 0 값을 허용하지 않는 이유는 무엇입니까?

위 참조. 이는 저렴해 보이는 일부 품목에는 매우 사소하지 않은 비용이 수반된다는 의미입니다.

이와 관련하여 Go를 변경하면 도움이 될 것입니다.

이점이 있지만 유익한 것과는 다릅니다. 해로움도 있습니다. 어느 쪽이 더 무거운지는 선호도와 트레이드오프에 달려 있습니다. Go 디자이너는 이것을 선택했습니다.

FTR, 이것은 이 스레드의 일반적인 패턴 이며 모든 합계 유형 개념에 대한 주요 반론 중 하나입니다. 즉, 0 값이 무엇인지 말해야 합니다. 이것이 새로운 아이디어가 명시적으로 다루어야 하는 이유입니다. 그러나 다소 실망스럽게도 요즘 여기에 게시하는 대부분의 사람들은 나머지 스레드를 읽지 않고 그 부분을 무시하는 경향이 있습니다.

🤔 아하! 나는 내가 놓치고 있는 것이 분명하다는 것을 알았다. 도! "단순한"이라는 단어에는 복잡한 의미가 있습니다. 좋아, 내 이전 댓글에서 "단순한" 단어를 자유롭게 제거하십시오.

몇몇 분들께 실망을 드렸다면 죄송합니다. 조금이나마 도움이 되고자 하는 의도였습니다. 나는 스레드를 따라가려고 노력하지만 이것에 쓸 여가 시간이 너무 없습니다.

다시 문제로 돌아가서 이것을 보류하는 주된 이유는 0 값인 것 같습니다.
잠시 생각하고 많은 옵션을 버리고 가치를 추가할 수 있고 언급할 가치가 있다고 생각하는 유일한 것은 다음과 같습니다.

올바르게 기억한다면 모든 유형의 0 값은 메모리 공간을 0으로 채우는 것으로 구성됩니다.
이미 알고 있듯이 포인터가 아닌 유형에는 문제가 없지만 포인터 유형에 대한 버그의 원인이 됩니다.

type S struct {
    n int
}
var s S 
s.n  // Fine

var s *S
s.n // runtime error

var f func(int)
f() // runtime error

따라서 다음과 같이 하면 어떻게 될까요?

• 모든 포인터 유형에 대해 유용한 0 값 정의
• 처음 사용할 때만 초기화하십시오(지연 초기화).

나는 이것이 확실하지 않은 다른 문제에서 제안되었다고 생각합니다. 이 제안의 주요 걸림돌을 다루기 때문에 여기에 씁니다.

다음은 포인터 유형에 대한 0 값 목록일 수 있습니다. 이러한 0 값은 값에 액세스할 때만 사용

| 포인터 유형 | 제로 값 | 동적 제로 값 | 댓글 |
| --- | --- | --- | --- |
| *T | nil | 새로운(T) |
| []티 | nil | []T{} |
| 지도[T]U | nil | 지도[T]U{} |
| func | nil | 멍청이 | 따라서 함수의 동적 0 값은 아무 작업도 수행하지 않고 0 값을 반환합니다. 반환 값 목록이 error 에서 끝나면 함수가 "no operation"이라는 기본 오류가 반환됩니다. |
| chan T | nil | 메이크(찬티) |
| interface | nil | - | 모든 메소드가 위에서 설명한 noop 함수로 초기화되는 기본 구현 |
| 차별 노조 | nil | 첫 번째 유형의 동적 0 값 | |

이제 이러한 유형이 초기화되면 현재와 같이 nil 가 됩니다. 차이점은 nil 에 액세스하는 순간입니다. 그 순간 동적 제로 값이 사용됩니다. 몇 가지 예:

type S struct {
    n int
}
var s *S
if s == nil { // true. Nothing different happens here
...
}
s.n = 1       // At this moment the go runtime would check if it is nil, and if it is, 
              // do "s = new(S)". We could say the code would be replaced by:
/*
if s == nil {
    s = new(S)
}
s.n = 1
*/

// -------------
var pointers []*S = make([]*S, 100) // Everything as usual
for _,p := range pointers {
    p.n = 1 // This is translated to:
    /*
        if p == nil {
            p = new(S)
        }
        p.n = 1
    */
}

// ------------
type I interface {
    Add(string) (int, error)
}

var i I
n, err := i.Add("yup!") // This method returns 0, and the default error "Noop"
if err != nil { // This condition is true and the error is returned
    return err
}

구현 세부 사항과 가능한 어려움이 누락되었을 수 있지만 먼저 아이디어에 집중하고 싶었습니다.

주요 단점은 포인터 유형의 값에 액세스할 때마다 nil-check를 추가한다는 것입니다. 그러나 나는 말할 것입니다 :

• 우리가 얻는 이점에 대한 좋은 절충안입니다. 배열/슬라이스 액세스의 경계 검사에서도 동일한 상황이 발생하며 우리는 안전을 위해 성능 저하를 지불하는 것을 수락합니다.
• nil-checks는 배열 바운드 검사와 같은 방식으로 피할 수 있습니다. 포인터 유형이 현재 범위에서 초기화된 경우 컴파일러는 이를 알고 nil-check 추가를 피할 수 있습니다.

이를 통해 이전 주석에서 설명한 모든 이점과 함께 값에 액세스하기 위해 유형 스위치를 사용할 필요가 없으며(차별화된 공용체에만 해당) go 코드를 다음과 같이 깨끗하게 유지합니다. 지금이야.

어떻게 생각하나요? 이미 논의되었다면 사과드립니다. 또한 이 의견 제안이 차별적인 노동 조합보다 nil 와 더 관련이 있다는 것을 알고 있습니다. 나는 이것을 nil 관련 문제로 옮길 수 있지만 내가 말했듯이 구별 된 공용체의 주요 문제인 유용한 0 값을 수정하려고 시도하기 때문에 여기에 게시했습니다.

다시 문제로 돌아가서 이것을 보류하는 주된 이유는 0 값인 것 같습니다.

해결해야 할 중요한 기술적 이유 중 하나 입니다. 저에게 주된 이유는 점진적인 수리를 절대적으로 불가능하게 만들기 때문입니다(위 참조). 즉, 개인적으로 그것을 구현하는 방법의 문제가 아니라 근본적으로 그 개념에 반대한다는 것입니다.
어쨌든 어떤 이유가 "주요"인지는 실제로 취향과 선호도의 문제입니다.

따라서 다음과 같이 하면 어떻게 될까요?

• 모든 포인터 유형에 대해 유용한 0 값 정의
• 처음 사용할 때만 초기화하십시오(지연 초기화).

포인터 유형을 전달하면 실패합니다. 예

func F(p *T) {
    *p = 42 // same as if p == nil { p = new(T) } *p = 42
}

func G() {
    var p *T
    F(p)
    fmt.Println(p == nil) // Has to be true, as F can't modify p. But now F is silently misbehaving
}

이 토론은 새롭지만은 않습니다. 참조 유형이 작동하는 방식에는 이유가 있으며 Go 개발자가 이에 대해 생각하지 않은 것은 아닙니다. :)

이것이 문제의 핵심입니다. 그것은 Go가 하는 일이 아닙니다. 모든 유형은 0 값, 마침표를 갖습니다. 그렇지 않으면 예를 들어 make([]T, 100)이 무엇을 하는지에 대해 대답해야 합니까?

T 에 0 값이 없으면 이 (및 new(T) )는 허용되지 않아야 합니다. make([]T, 0, 100) 를 수행한 다음 append 를 사용하여 슬라이스를 채워야 합니다. 더 크게( v[:0][:100] ) 다시 자르는 것도 오류여야 합니다. [10]T 는 기본적으로 불가능한 유형입니다(배열 포인터에 대한 슬라이스를 주장하는 기능이 언어에 추가되지 않는 한). 그리고 이전 버전과의 호환성을 유지하려면 기존의 nilable 유형을 nilable로 표시하는 방법이 필요합니다.

이것은 제네릭이 추가되는 경우 문제가 될 수 있습니다. 즉, 일부 경계를 충족하지 않는 한 모든 유형 매개변수를 0 값이 아닌 것으로 처리해야 합니다. 유형의 하위 집합은 기본적으로 모든 곳에서 초기화 추적이 필요합니다. 이것은 그 위에 합계 유형을 추가하지 않고도 그 자체로 상당히 큰 변화가 될 것입니다. 확실히 가능하지만 비용/편익 분석의 비용 측면에 크게 기여합니다. 초기화를 단순하게 유지하려는 의도적인 선택("항상 0 값")은 초기화 추적이 1일차부터 언어로 된 경우보다 초기화를 더 복잡하게 만드는 영향을 미칩니다.

해결해야 할 중요한 기술적 이유 중 하나입니다. 나에게 주된 이유는 점진적인 수리를 절대적으로 불가능하게 만들기 때문입니다(위 참조). 즉, 개인적으로 그것을 구현하는 방법의 문제가 아니라 근본적으로 그 개념에 반대한다는 것입니다.
어쨌든 어떤 이유가 "주요"인지는 실제로 취향과 선호도의 문제입니다.

알겠습니다. 이해합니다. 우리는 또한 다른 사람들의 관점도 봐야 합니다(당신이 그렇게 하지 않는다는 말은 아닙니다. 나는 단지 요점을 말하고 있습니다 :wink:). 그들이 이것을 프로그램을 작성하는 데 강력한 것으로 보는 곳입니다. Go에 어울리나요? 그것은 아이디어가 어떻게 실행되고 언어에 통합되는지에 달려 있으며, 그것이 우리 모두가 이 스레드에서 하려고 하는 것입니다(내 생각에)

포인터 유형을 전달하면 실패합니다. 예를 들어(...)

나는 이것을 잘 이해하지 못한다. 이것이 왜 실패입니까? nil 값을 가진 포인터인 함수 매개변수에 값을 전달하기

// Augmenting your example with more comments:
func FCurrentGo(p *T) {
    // Here "p" is just a value, which happens to be a pointer type. Doing...
    *p = 42
    // ...without checking first for "nil" is the recipe for hiding a bug that will crash the entire program, 
    // which is exactly what is happening in current Go code bases

    // The correct code would be:
    if p == nil {
        // panic or return error
    }
    *p = 42
}

func FWithDynamicZero(p *T) {
    // Here, again, p is just a value of a pointer type. Doing...
    *p = 42
    // would allocate a new T and assign 42. It is true that this doesn't have any effect on the "outside
    // world", which could be considered "incorrect" because you expected the function to do that.
    // If you really want to be sure "p" is pointing to something valid in the "outside world", then
    // check that:
    if p == nil {
        // panic or return error
    }
    *p = 42
}

func main() {
    var p *T
    FCurrentGo(p) // This will crash the program
        FWithDynamicZero(p) // This won't have any effect on "p". This is expected because "p" is not pointing
                            // to anything. No crash here.
    fmt.Println(p == nil) // It is true, as expected
}

포인터가 아닌 수신기 메서드에서도 비슷한 상황이 발생하며 Go를 처음 접하는 사람들에게는 혼란스럽습니다(하지만 일단 이해하고 나면 이해가 됩니다).

type Point struct {
    x, y int
}

func (p Point) SetXY(x, y int) {
    p.x = x
    p.y = y
}

func main() {
    p := Point{x: 1, y: 2}
    p.SetXY(24, 42)

    pointerToP := &Point{x: 1, y: 2}
    pointerToP.SetXY(24, 42)

    fmt.Println(p, pointerToP) // Will print "{1 2} &{1 2}", which could confuse at first
}

따라서 다음 중에서 선택해야 합니다.

• A) 충돌로 인한 실패
• B) 포인터가 함수에 전달될 때 포인터가 가리키는 값을 자동으로 수정하지 않는 오류.

두 경우에 대한 수정 사항은 동일합니다. 작업을 수행하기 전에 nil을 확인하십시오. 그러나 나에게는 A) 훨씬 더 해롭습니다(전체 응용 프로그램이 충돌합니다!).
B) "조용한 오류"로 간주될 수 있지만 오류로 간주하지 않습니다. 함수에 대한 포인터를 전달할 때만 발생하며, 내가 보여줬듯이 유사한 방식으로 동작하는 구조체가 있는 경우가 있습니다. 이것은 그것이 가져오는 엄청난 이점을 고려하지 않고 있습니다.

참고: 나는 "나의" 아이디어를 맹목적으로 옹호하려는 것이 아니라 진정으로 Go(이미 정말 좋은)를 개선하려고 노력하고 있습니다. 그 아이디어를 가치가 없게 만드는 몇 가지 다른 점이 있다면, 나는 그것을 버리거나 다른 방향으로 계속 생각하는 것을 신경 쓰지 않습니다.

참고 2: 결국 이 아이디어는 "nil" 값에만 해당되며 판별된 공용체와 관련이 없습니다. 그래서 나는 이것을 오염시키는 것을 피하기 위해 다른 문제를 만들 것입니다.

알겠습니다. 이해합니다. 우리는 다른 사람들의 관점도 봐야 합니다.

하지만 그 칼은 양쪽을 잘라냅니다. 당신은 "이것을 보류한 주된 이유는". 그 진술은 우리가 이 제안의 효과 를 원하는지 여부에 대해 우리 모두가 동의하고 있음을 의미합니다. 나는 그것이 특정 제안을 하는 기술적인 세부 사항이라는 데 확실히 동의할 수 있습니다(또는 적어도 모든 제안이 해당 질문에 대해 말해야 한다는 점) ). 그러나 나는 모든 사람들이 실제로 그것을 원한다고 가정하는 평행 세계로 조용히 재구성되는 토론을 좋아하지 않습니다.

이것이 왜 실패입니까?

포인터를 사용하는 함수는 적어도 종종 pointee를 수정하겠다고 약속하기 때문입니다. 함수가 조용히 아무 것도 하지 않는다면 나는 그것을 버그로 간주할 것입니다. 또는 적어도 이런 식으로 nil-panic을 방지함으로써 새로운 종류의 버그를 도입한다는 것은 쉽게 주장할 수 있습니다.

거기에 뭔가를 기대하는 함수에 nil 포인터를 전달하면 그것은 버그입니다. 그리고 버그가 많은 소프트웨어를 조용히 계속하는 것의 실제 가치를 보지 못합니다. 나는 non-nilable 포인터를 지원함으로써 컴파일 타임에 그 버그를 잡는 원래의 아이디어에서 가치를 볼 수 있지만, 나는 그 버그가 전혀 포착되지 않도록 허용하는 요점을 보지 못합니다.

말하자면, 당신은 nilable이 아닌 포인터의 실제 제안과 일종의 다른 문제를 다루고 있습니다. 그 제안의 경우 런타임 패닉은 문제가 아니라 단지 증상입니다 . 문제는 실수로 통과하는 버그입니다. nil 는 예상하지 못한 것으로 이 버그는 런타임에만 포착됩니다.

포인터가 아닌 수신기 메서드에서도 비슷한 상황이 발생합니다.

나는 이 비유를 사지 않는다. IMO 고려하는 것이 완전히 합리적입니다.

func Foo(p *int) { *p = 42 }

func main() {
    var v int
    Foo(&v)
    if v != 42 { panic("") }
}

올바른 코드가 됩니다. 고려하는 것이 합리적이지 않다고 생각합니다

func Foo(v int) { v = 42 }

func main( ){
    var v int
    Foo(v)
    if v != 42 { panic("") }
}

정확하다. 아마도 당신이 Go의 절대적인 초보자 이고 모든 값이 참조인 언어에서 온 경우일 수 있습니다(솔직히 하나를 찾기가 힘들지만 Python과 Java조차도 대부분의 값 참조만 만듭니다). 그러나 IMO는 그 경우에 대해 최적화하는 것은 헛된 일입니다. 사람들이 포인터 대 값에 대해 어느 정도 익숙하다고 가정하는 것은 공평합니다. 노련한 Go 개발자라도 예를 들어 포인터 수신기가 해당 필드에 액세스하는 메서드가 올바른 것으로 간주하고 해당 메서드를 호출하는 코드가 올바른 것으로 볼 것이라고 생각합니다. 실제로 이것이 nil -pointers를 정적으로 방지하기 위한 전체 주장 입니다. 의도치 않게 포인터가 0이 되고 런타임에 올바른 모양의 코드가 실패하는 것은 너무 쉽습니다.

두 경우에 대한 수정 사항은 동일합니다. 작업을 수행하기 전에 nil을 확인하십시오.

현재 의미 체계의 IMO 수정 사항은 nil을 확인 하지 않고 누군가가 nil을 전달하면 버그로 간주하는 것입니다. 귀하의 예에서 다음과 같이 작성하십시오.

// The correct code would be:
if p == nil {
    // panic or return error
}
*p = 42

그러나 나는 그 코드가 정확하다고 생각하지 않습니다. nil -check는 nil 역참조하면 이미 패닉 상태이므로 아무 작업도 수행하지 않습니다.

그러나 나에게는 A) 훨씬 더 해롭습니다(전체 응용 프로그램이 충돌합니다!).

괜찮습니다. 그러나 많은 사람들이 이에 대해 강하게 동의하지 않을 것이라는 점을 염두에 두십시오. 저는 개인적으로 손상된 데이터와 잘못된 가정을 계속하는 것보다 항상 충돌이 더 낫다고 생각합니다. 이상적인 세계에서 내 소프트웨어에는 버그가 없고 충돌도 없습니다. 덜 이상적인 세상에서는 내 프로그램에 버그가 있고 감지될 때 충돌하여 안전하게 실패합니다. 최악의 상황에서 내 프로그램에는 버그가 있고 문제가 발생하면 계속해서 혼란을 일으킬 것입니다.

하지만 그 칼은 양쪽을 잘라냅니다. 당신은 "이를 보류한 주된 이유는"라고 말했습니다. 그 진술은 우리 모두가 이 제안의 효과를 원하는지 여부에 동의한다는 것을 의미합니다. 나는 그것이 특정 제안을 보류하는 기술적인 세부 사항이라는 데 확실히 동의할 수 있습니다(또는 적어도 모든 제안은 해당 질문에 대해 말해야 함). 그러나 나는 토론이 모든 사람이 실제로 그것을 원한다고 가정하는 평행 세계로 조용히 재구성되는 것을 좋아하지 않습니다.

글쎄, 나는 이것을 암시하고 싶지 않았다. 그렇게 이해하셨다면 제가 단어를 잘못 선택했을 수도 있고 사과드립니다. 가능한 솔루션에 대한 몇 가지 아이디어를 제공하고 싶었습니다. 그게 전부입니다.

나는 _"... 이것을 막는 주된 이유는...."라고 썼습니다. 그렇기 때문에 0 값이 이것을 유지하는 주요 요소라고 가정했습니다. 그래서 그것은 나의 잘못된 가정이었습니다.

nil 자동으로 처리하는 것과 컴파일할 때 확인하는 것과 관련하여: 컴파일할 때 확인하는 것이 더 낫다는 데 동의합니다. "동적 0 값"은 내가 모든 유형의 값이 0이어야 하는 문제를 해결하는 데 중점을 둘 때 원래 제안에 대한 반복이었습니다. 또 다른 동기는 그것이 차별적 노동조합 제안의 주요 걸림돌이기도 하다고 _생각_했기 때문입니다.
nil 관련 문제에만 초점을 맞추면 컴파일 시간에 nil이 아닌 포인터 유형을 확인하는 것이 좋습니다.

어느 시점에서 우리("우리"는 전체 Go 커뮤니티를 의미함)가 _어떤 종류의_ 변화를 받아들여야 한다고 말하고 싶습니다. 예를 들어: nil 오류를 완전히 방지할 수 있는 좋은 솔루션이 있고 이를 보류하는 것이 "모든 유형의 값은 0이고 0으로 만들어집니다"라는 설계 결정인 경우 다음 아이디어를 고려할 수 있습니다. 가치가 있다면 그 결정에 약간의 조정이나 변경을 가하는 것.

내가 이것이 당신의 문장이라고 말하는 주된 이유는 _"모든 유형에는 0 값, 마침표 "_가 있습니다. 나는 일반적으로 "완전히 마침표를 쓰는 것"을 좋아하지 않습니다. 오해하지 마세요! 나는 당신이 그렇게 생각한다는 것을 완전히 인정합니다. 그것은 단지 제 생각입니다. 나는 더 나은 솔루션으로 이어질 수 있는 길을 숨길 수 있기 때문에 어떤 독단도 선호하지 않습니다.

마지막으로 이에 대해:

괜찮습니다. 그러나 많은 사람들이 이에 대해 강하게 동의하지 않을 것이라는 점을 염두에 두십시오. 저는 개인적으로 손상된 데이터와 잘못된 가정을 계속하는 것보다 항상 충돌이 더 낫다고 생각합니다. 이상적인 세계에서 내 소프트웨어에는 버그가 없고 충돌도 없습니다. 덜 이상적인 세상에서는 내 프로그램에 버그가 있고 감지될 때 충돌하여 안전하게 실패합니다. 최악의 상황에서 내 프로그램에는 버그가 있고 문제가 발생하면 계속해서 혼란을 일으킬 것입니다.

나는 이것에 전적으로 동의합니다. 큰 소리로 실패하는 것이 조용히 실패하는 것보다 항상 낫습니다. 그러나 Go에는 다음과 같은 문제가 있습니다.

• 수천 개의 고루틴이 있는 앱이 있는 경우 그 중 하나에서 처리되지 않은 패닉으로 인해 전체 프로그램이 중단됩니다. 이것은 패닉을 일으키는 스레드만 충돌하는 다른 언어와 다릅니다.

(상당히 위험하긴 하지만) 그것을 제쳐두고, 아이디어는 전체 범주의 실패( nil 관련 실패)를 피하는 것입니다.

따라서 이것을 계속 반복하고 해결책을 찾도록 합시다.

시간과 에너지를 주셔서 감사합니다!

나는 Haskell의 합 유형보다 Rust의 구별된 공용체 구문을 보고 싶습니다. 변형 이름을 지정하고 더 나은 패턴 일치 구문 제안을 허용합니다.
구현은 태그 필드(단위 유형, 변형 수에 따라 다름) 및 통합 필드(데이터 보유)가 있는 구조체와 같이 수행할 수 있습니다.
이 기능은 닫힌 변형 집합에 필요합니다(컴파일 시간 확인을 통해 상태 표현이 훨씬 쉽고 깨끗함). 인터페이스와 그 표현에 대한 질문에 따르면, 나는 인터페이스가 일부 요구 사항에 맞는 모든 유형에 관한 것이지만 sum 유형 사용 사례가 다르기 때문에 sum 유형의 구현은 sum 유형의 또 다른 경우 이상이어야 한다고 생각합니다.

통사론:

type Type enum {
         Tuple (int,int),
         One int,
         None,
};

위의 예에서 크기는 sizeof((int,int))입니다.
패턴 일치는 새로 생성된 일치 연산자를 사용하거나 다음과 같이 기존 스위치 연산자 내에서 수행할 수 있습니다.

var a Type
switch (a) {
         case Tuple{(b,c)}:
                    //do something
         case One{b}:
                    //do something else
         case None:
                    //...
}

생성 구문:
var a Type = Type{One=12}
열거형 인스턴스 생성에서는 하나의 변형만 지정할 수 있습니다.

0 값(문제):
이름을 알파벳 순서로 정렬할 수 있습니다. enum 값이 0이면 정렬된 멤버 목록의 첫 번째 멤버 유형 값이 0이 됩니다.

PS Zero Value 문제의 솔루션은 대부분 합의에 의해 정의됩니다.

나는 합계의 0 값을 첫 번째 사용자 정의 합계 필드의 0 값으로 유지하는 것이 덜 혼란스러울 것이라고 생각합니다.

나는 합계의 0 값을 첫 번째 사용자 정의 합계 필드의 0 값으로 유지하는 것이 덜 혼란스러울 것이라고 생각합니다.

그러나 필드 선언 순서에 따라 값을 0으로 만드는 것이 더 나쁘다고 생각합니다.

누군가가 디자인 문서를 작성했습니까?

내가 하나가:
19412-discriminated_unions_and_pattern_matching.md.zip

나는 이것을 바꿨다:

나는 합계의 0 값을 첫 번째 사용자 정의 합계 필드의 0 값으로 유지하는 것이 덜 혼란스러울 것이라고 생각합니다.

이제 Zero Value (Problem)에 대한 내 제안 동의서에서 urandoms 위치로 이동했습니다.

UPD: 디자인 문서가 변경되고 약간 수정되었습니다.

나는 내장 합계 유형이 필요한 두 가지 최근 사용 사례가 있습니다.

1. 예상대로 AST 트리 표현. 처음에는 첫눈에 솔루션인 라이브러리를 찾았지만, 접근 방식은 nilable 필드가 많은 대형 구조체를 사용하는 것이었습니다. 두 세계의 최악 IMO. 물론 유형 안전성은 없습니다. 대신 우리 자신을 썼습니다.
2. 미리 정의된 백그라운드 작업 대기열이 있습니다. 현재 개발 중인 검색 서비스가 있고 검색 작업이 너무 길 수 있습니다. 그래서 우리는 검색 인덱스 작업 작업을 채널로 전송하여 백그라운드에서 실행하기로 결정했습니다. 그러면 디스패처가 추가로 처리할 작업을 결정할 것입니다. 방문자 패턴을 사용할 수 있지만 분명히 간단한 gRPC 요청에 대한 과잉입니다. 그리고 그것은 파견자와 방문자 사이의 유대를 소개하기 때문에 적어도 말하기는 특히 명확하지 않습니다.

두 경우 모두 다음과 같이 구현했습니다(두 번째 작업의 예에서).

type Task interface {
    task()
}

type SearchAdd struct {
    Ctx   context.Context
    ID    string
    Attrs Attributes
}

func (SearchAdd) task() {}

type SearchUpdate struct {
    Ctx         context.Context
    ID          string
    UpdateAttrs UpdateAttributes
}

func (SearchUpdate) task() {}

type SearchDelete struct {
    Ctx context.Context
    ID  string
}

func (SearchDelete) task() {}

그리고

task := <- taskChannel

switch v := task.(type) {
case tasks.SearchAdd:
    resp, err := search.Add(task.Ctx, &search2.RequestAdd{…}
    if err != nil {
        log.Error().Err(err).Msg("blah-blah-blah")
    } else {
        if resp.GetCode() != search2.StatusCodeSuccess  {
            …
        } 
    }
case tasks.SearchUpdate:
    …
case tasks.SearchDelete:
    …
}

이것은 거의 좋습니다. 나쁜 점은 Go가 완전한 유형 안전성을 제공하지 않는다는 것입니다. 즉, 새로운 검색 색인 작업 작업이 추가된 후 컴파일 오류가 발생하지 않습니다.

sum 유형을 사용하는 IMHO는 방문자의 기능이 많지 않고 작으며 방문자 자체가 고정 유형인 방문자 및 발송자 집합으로 일반적으로 해결되는 이러한 종류의 작업에 대한 가장 명확한 솔루션입니다.

나는 진정으로 다음과 같은 것을 가지고 있다고 믿습니다.

type Task oneof {
    // SearchAdd holds a data for a new record in the search index
    SearchAdd {
        Ctx   context.Context
        ID    string
        Attrs Attributes   
    }

    // SearchUpdate update a record
    SearchUpdate struct {
        Ctx         context.Context
        ID          string
        UpdateAttrs UpdateAttributes
    }

    // SearchDelete delete a record
    SearchDelete struct {
        Ctx context.Context
        ID  string
    }
}

+

switch task {
case tasks.SearchAdd:
    // task is tasks.SearchAdd in this scope
case tasks.SearchUpdate:
case tasks.SearchDelete:
}

Go가 현재 상태에서 허용하는 다른 접근 방식보다 훨씬 더 Goish 정신이 될 것입니다. Haskellish 패턴 매칭이 필요하지 않으며 특정 유형까지 juist 다이빙하면 충분합니다.

앗, 구문 제안의 요점을 놓쳤습니다. 수정합니다.

두 가지 버전, 하나는 일반 합계 유형용이고 하나는 열거형용 합계 유형:

일반 합계 유형

type Sum oneof {
    T₁ TypeDecl₁
    T₂ TypeDecl₂
    …
    Tₙ TypeDeclₙ
}

여기서 T₁ ... Tₙ 는 Sum ( oneof 는 범위 외부에 노출)와 동일한 수준의 유형 정의이고 Sum 선언 T₁ ... Tₙ 만족하는 일부 인터페이스.

처리는 oneof 개체에 대해 암시적으로 수행되고 모든 변형이 나열되었는지 컴파일러 검사가 있어야 한다는 점을 제외하고는 (type) 스위치가 있는 것과 유사합니다.

실수형 안전한 열거

type Enum oneof {
    Value = iota
}

명시적으로 나열된 값만 Enum이고 다른 모든 값은 그렇지 않다는 점을 제외하면 iota of const와 매우 유사합니다.

switch task {
case tasks.SearchAdd:
    // task is tasks.SearchAdd in this scope
case tasks.SearchUpdate:
case tasks.SearchDelete:
}

Go가 현재 상태에서 허용하는 다른 접근 방식보다 훨씬 더 Goish 정신이 될 것입니다. Haskellish 패턴 매칭이 필요하지 않으며 특정 유형까지 juist 다이빙하면 충분합니다.

task 변수의 의미를 조작하는 것은 허용되지만 좋은 생각이라고 생각하지 않습니다.

```go
switch task {
case tasks.SearchAdd:
    // task is tasks.SearchAdd in this scope
case tasks.SearchUpdate:
case tasks.SearchDelete:
}

Go가 현재 상태에서 허용하는 다른 접근 방식보다 훨씬 더 Goish 정신이 될 것입니다. Haskellish 패턴 매칭이 필요하지 않으며 특정 유형까지 juist 다이빙하면 충분합니다.

나는 작업 변수의 의미를 조작하는 것이 허용되지만 좋은 생각이라고 생각하지 않습니다.
```

그럼 방문자 여러분의 건승을 빕니다.

@sirkon 방문자는 무엇을 의미합니까? 나는 이 구문이 마음에 들었지만 스위치는 다음과 같이 작성되어야 합니다.

switch task {
case Task.SearchAdd:
    // task is Task.SearchAdd in this scope
case Task.SearchUpdate:
case Task.SearchDelete:
}

또한 Task 가치가 없는 것은 무엇입니까? 예를 들어:

var task Task

nil 일까요? 그렇다면 switch 에 추가 case nil 가 있어야 합니까?
아니면 첫 번째 유형으로 초기화됩니까? 유형 선언의 순서가 이전에는 없었던 방식으로 중요하기 때문에 이것은 어색할 것입니다. 그러나 숫자 열거형에는 아마도 괜찮을 것입니다.

나는 이것이 switch task.(type) 와 동일하다고 가정하고 있지만 스위치는 모든 케이스가 거기에 있어야 하는 것이 맞습니까? as in.. 하나의 경우를 놓치면 컴파일 오류가 발생합니다. 그리고 default 허용되지 않습니다. 맞나요?

방문자에 대해 무엇을 의미 합니까?

이러한 종류의 기능을 위한 Go의 유일한 유형 안전 옵션입니다. 특정 사례 집합의 경우 훨씬 더 나쁩니다(미리 정의된 대안의 수가 제한됨).

또한 Task의 가치가 없는 것은 무엇입니까? 예를 들어:

var task Task

나는 이것이 Go에서 nilable 유형이어야한다는 것을 두려워합니다.

아니면 첫 번째 유형으로 초기화됩니까?

특히 의도 한 목적에 대해 너무 이상할 것입니다.

나는 이것이 스위치 작업과 동일하다고 가정하고 있습니다.(유형) 하지만 스위치는 모든 경우가 있어야 합니다. 맞죠? as in.. 하나의 경우를 놓치면 컴파일 오류가 발생합니다.

네, 그러죠.

그리고 기본값은 허용되지 않습니다. 맞나요?

아니요, 기본값이 허용됩니다. 그러나 낙심했다.

추신: Go @ianlancetaylor 및 다른 Go 사람들이 합계 유형에 대해 가지고 있는 아이디어를 얻은 것 같습니다. Go는 nil 값을 제어할 수 없기 때문에 nilness가 NPD에 취약한 것처럼 보입니다.

nil이면 괜찮을 것 같아요. case nil 가 switch 문에 대한 요구 사항이었으면 합니다. 전에 if task != nil 것도 괜찮습니다. 저는 별로 좋아하지 않습니다 :|

이것도 허용될까요?

type Foo oneof {
  A = 3
  B = "3"
  C = 3.0
  D = struct { E bool }{ true }
}

이것도 허용될까요?

type Foo oneof {
  A = 3
  B = "3"
  C = 3.0
  D = struct { E bool }{ true }
}

음, const는 없습니다.

type Foo oneof {
    A <type reference>
}

또는

type Foo oneof {
    A = iota
    B
    C
}

또는

type Foo oneof {
    A = 1
    B = 2
    C = 3
}

iota와 값의 조합이 없습니다. 또는 값에 대한 제어와 조합하여 반복해서는 안 됩니다.

FWIW, 최신 제네릭 디자인 에서 흥미로운 점은 0 값에 대한 함정을 피하면서 sum 유형의 사용 사례 중 적어도 일부를 해결할 수 있는 또 다른 장소를 보여주었다는 것입니다. 그것은 어떤 면에서 요약적이지만 형식이 아닌 제약 조건을 설명하기 때문에 0 값을 가질 필요가 없는 분리 계약을 정의합니다(해당 형식의 변수를 선언할 수 없기 때문에). 즉, 가능한 유형의 제한된 집합을 취하는 함수를 작성하고 해당 집합의 컴파일 시간 형식 검사를 사용하는 것이 가능합니다.

물론 지금은 있는 그대로의 디자인이 여기에서 의도한 사용 사례에 대해 실제로 작동하지 않습니다. 분리는 기본 유형 또는 메서드만 나열하므로 여전히 널리 열려 있습니다. 그리고 물론, 일반적인 아이디어라고 해도 일반적인(또는 종합적인) 함수나 값을 인스턴스화할 수 없기 때문에 매우 제한적입니다. 그러나 IMO는 sum의 사용 사례 중 일부를 처리하기 위한 디자인 공간이 sum 유형 자체의 아이디어보다 훨씬 더 크다는 것을 보여줍니다. 따라서 합계에 대해 생각하는 것은 특정 문제보다는 특정 솔루션에 더 집착합니다.

어쨌든. 흥미롭다고만 생각했습니다.

@Merovius 는 sum 유형의 일부 사용 사례를 처리할 수 있는 최신 일반 디자인에 대해 훌륭한 지적을 했습니다. 예를 들어 스레드에서 이전에 사용된 이 함수는 다음과 같습니다.

func addOne(x int|float64) int|float64 {
    switch x := x.(type) {
    case int:
        return x + 1
    case float64:
         return x + 1
    }
}

될 것입니다:

contract intOrFloat64(T) {
    T int, float64
}

func addOne(type T intOrFloat64) (x T) T {
    return x + 1
}

합계 유형 자체에 관한 한, 제네릭이 결국 출시되면 이를 도입하는 이점이 Go와 같은 간단한 언어에 대한 비용을 능가하는지 여부에 대해 지금보다 훨씬 더 의심스럽습니다.

그러나 무언가가 수행되어야 한다면 가장 간단하고 가장 방해가 적은 솔루션 IMO는 @ianlancetaylor 의 '제한된 인터페이스' 아이디어가 될 것입니다. 이 아이디어는 오늘날의 '무제한' 인터페이스와 똑같은 방식으로 구현되지만 만족할 수 있을 뿐입니다. 지정된 유형별로. 사실, 제네릭 디자인 책에서 한 장을 꺼내 인터페이스 블록의 첫 번째 줄에 형식 제약 조건을 만든 경우:

type intOrFloat64 interface{ type int, float64 }    

그러면 새 키워드(예: restrict )가 전혀 필요하지 않으므로 완전히 이전 버전과 호환됩니다. 여전히 인터페이스에 메서드를 추가할 수 있으며 메서드가 지정된 모든 형식에서 지원되지 않으면 컴파일 시간 오류가 발생합니다.

제한된 인터페이스 유형의 변수에 값을 할당하는 데 전혀 문제가 없습니다. RHS의 값 유형(또는 유형이 지정되지 않은 리터럴의 기본 유형)이 지정된 유형 중 하나와 정확히 일치하지 않으면 단순히 컴파일되지 않습니다. 그래서 우리는:

var v1 intOrFloat64 = 1        // compiles, dynamic type int
var v2 intOrFloat64 = 1.0      // compiles, dynamic type float64
var v3 intOrFloat64 = 1 + 2i   // doesn't compile, complex128 is not a specified type

지정된 유형과 일치하지 않는 유형 전환의 경우 컴파일 시간 오류가 되고 완전성 검사가 구현될 수 있습니다. 그러나 제한된 인터페이스 값을 오늘날과 같은 동적 유형 값으로 변환하려면 유형 어설션이 여전히 필요합니다.

0 값은 이 접근 방식에서 문제가 되지 않습니다. 제한된 인터페이스의 0 값은 nil (현재 아무것도 포함하지 않음을 의미)이고 지정된 유형은 물론 내부적으로 자체 0 값을 가지며 nil nilable 유형의 경우.

이 모든 것이 나에게 완벽하게 실행 가능한 것처럼 보이지만 앞서 말했듯이 컴파일 시간의 안전성은 추가 복잡성의 가치가 있다는 것입니다. 내 자신의 프로그래밍에서 합 유형의 필요성을 실제로 느껴본 적이 없기 때문에 의심이 듭니다.

IIUC 제네릭은 동적 유형이 아니므로 이 요점은 유효하지 않습니다. 그러나 인터페이스가 계약으로 작동하도록 허용되면(나는 의심스럽습니다) sumtypes에 대한 철저한 검사 및 열거형을 해결하지 못할 것입니다.

@alanfo , @Merovius 힌트 주셔서 감사합니다. 이 논의가 다음과 같은 방향으로 가고 있다는 것이 흥미롭습니다.

나는 잠시 동안 관점을 바꾸는 것을 좋아합니다. 위에서 언급한 유형 제한을 허용하는 매개변수화된 인터페이스로 계약을 완전히 대체할 수 없는 이유를 이해하려고 합니다. 현재로서는 그러한 "합계" 인터페이스 유형이 "합계" 유형으로 사용될 때 가능한 동적 값을 인터페이스에 열거된 유형으로 정확히 제한하기를 원한다는 점을 제외하고는 강력한 기술적 이유가 없습니다. 동일한 인터페이스가 계약 위치에 사용되었습니다. 인터페이스의 열거 유형은 합리적으로 유용한 일반 제한이 되기 위해 기본 유형으로 제공되어야 합니다.

@굿와인
나는 제네릭 디자인이 합계 유형으로 수행할 수 있는 모든 것을 다룰 것이라고 제안하지 않았습니다. @Merovius 가 그의 마지막 게시물에서 명확하게 설명했듯이 그렇지 않을 것입니다. 특히 제네릭에 대해 제안된 형식 제약 조건은 기본 제공 형식과 이 형식에서 파생된 형식만 다룹니다. 화폐의 관점에서 전자는 너무 좁고 후자는 너무 넓다.

그러나 제네릭 디자인을 사용하면 컴파일러가 시행할 제한된 유형 집합에서 작동하는 함수를 작성할 수 있으며 이는 현재로서는 전혀 할 수 없는 것입니다.

제한된 인터페이스에 관한 한 컴파일러는 사용할 수 있는 정확한 유형을 알고 있으므로 유형 switch 문에서 철저한 검사를 수행하는 것이 가능해집니다.

@그리제머

제네릭 디자인 문서 초안이 ("계약 대신 인터페이스를 사용하지 않는 이유" 섹션에서) 제네릭 제약 조건을 표현하는 데 전자보다 후자가 더 나은 수단으로 간주되는 이유를 매우 명확하게 설명했다고 생각하면서 당신이 말하는 것에 의아해합니다.

특히, 계약은 형식 매개변수 간의 관계를 표현할 수 있으므로 단일 계약만 필요합니다. 모든 유형 매개변수는 계약에 나열된 메소드의 수신자 유형으로 사용할 수 있습니다.

매개변수화 여부에 관계없이 인터페이스에 대해서도 마찬가지입니다. 제약 조건이 있는 경우 각 유형 매개변수에 별도의 인터페이스가 필요합니다.

그래프 예제에서 볼 수 있듯이 불가능하지는 않지만 인터페이스를 사용하여 유형 매개변수 간의 관계를 표현하는 것이 더 어색합니다.

그러나 인터페이스에 유형 제약 조건을 추가한 다음 일반 및 합계 유형 목적으로 사용하여 "한 돌로 두 마리의 새를 죽일" 수 있다고 생각한다면 (당신이 언급한 문제는 별도로) 제 생각에는 아마도 이것이 기술적으로 실현 가능하다는 것이 옳을 것입니다.

인터페이스 유형 제약 조건이 제네릭에 관한 한 '내장되지 않은' 유형을 포함할 수 있는지 여부는 실제로 중요하지 않지만 정확한 유형(및 파생 유형이 아님)으로 제한하기 위해 어떤 방법을 찾아야 할 필요가 있습니다. 그래서 그들은 합계 유형에 적합합니다. 현재 키워드를 계속 사용하려면 후자에 const type 를 사용할 수도 있습니다(또는 const ).

@griesemer 매개변수화된 인터페이스 유형이 계약을 직접 대체하지 못하는 몇 가지 이유가 있습니다.

1. 유형 매개변수는 다른 매개변수화된 유형과 동일합니다.
   와 같은 유형으로

   type C2(type T C1) interface { ... }
   

   유형 매개변수 T 는 인터페이스 자체 외부에 존재합니다. T 로 전달된 모든 유형 인수는 C1 계약을 충족하기 위해 이미 알려져 있어야 하며 인터페이스의 본문은 T 더 이상 제한할 수 없습니다. 이는 전달된 결과로 계약 본문에 의해 제약을 받는 계약 매개변수와 다릅니다. 이는 함수에 대한 각 유형 매개변수가 다른 유형 매개변수의 제약 조건에 매개변수로 전달되기 전에 독립적으로 제약되어야 함을 의미합니다.

2. 인터페이스 본문에 수신기 유형의 이름을 지정할 방법이 없습니다.
   인터페이스는 다음과 같이 작성할 수 있어야 합니다.

   type C3(type U C1) interface(T) {
       Add(T) T
   }
   

   여기서 T 는 수신기 유형을 나타냅니다.

3. 일부 인터페이스 유형은 제네릭 제약 조건을 충족하지 않습니다.
   수신기 유형의 여러 값에 의존하는 작업은 동적 디스패치와 호환되지 않습니다. 따라서 이러한 작업은 인터페이스 값에서 사용할 수 없습니다. 이는 인터페이스가 자체를 만족하지 않음을 의미합니다(예: 동일한 인터페이스로 제한되는 유형 매개변수에 대한 유형 인수로). 이것은 놀라운 것입니다. 한 가지 해결책은 그러한 인터페이스에 대한 인터페이스 값 생성을 전혀 허용하지 않는 것이지만, 이는 어쨌든 여기에서 구상 중인 사용 사례를 허용하지 않습니다.

기본 유형 제약 조건과 유형 ID 제약 조건을 구별하는 것과 관련하여 작동할 수 있는 한 가지 방법이 있습니다. 다음과 같은 사용자 정의 제약 조건을 정의할 수 있다고 상상해보십시오.

contract (T) indenticalTo(U) {
    *T *U
}

(여기서 저는 발명된 표기법을 사용하여 단일 유형을 "수신자"로 지정하고 있습니다. 수신자가 있는 func가 "메소드"로 발음되는 것처럼 명시적 수신자 유형이 있는 계약을 "제약조건"으로 발음하겠습니다. 컨트랙트 이름 뒤의 매개변수는 일반형 매개변수로, 제약 본문에서 제약 조건 절의 왼쪽에 나타날 수 없습니다.)

리터럴 포인터 유형의 기본 유형이 자체이기 때문에 이 제약 조건은 T 가 U 동일함을 의미합니다. 이것은 제약 조건으로 선언되었기 때문에 (identicalTo(int)), (identicalTo(uint)), ... 를 제약 조건 분리로 쓸 수 있습니다.

계약은 일종의 합계 유형을 표현하는 데 유용할 수 있지만 일반적인 합계 유형을 표현할 수는 없다고 생각합니다. 초안에서 본 바에 따르면 구체적인 유형을 나열해야 하므로 다음과 같이 작성할 수 없습니다.

contract Foo(T, U) {
    T U, int64
}

알려지지 않은 유형과 하나 이상의 알려진 유형의 일반 합계 유형을 표현해야 하는 것은 무엇입니까? 디자인이 그러한 구성을 허용하더라도 두 매개변수가 사실상 같은 것이기 때문에 사용하면 이상하게 보일 것입니다.

인터페이스가 유형 제약 조건을 포함하도록 확장된 다음 디자인에서 계약을 대체하는 데 사용되는 경우 초안 제네릭 디자인이 어떻게 변경될지에 대해 좀 더 생각했습니다.

다른 수의 유형 매개변수를 고려하면 상황을 분석하는 것이 가장 쉬울 것입니다.

매개변수 없음

변경 없음 :)

하나의 매개변수

여기에는 실제 문제가 없습니다. 매개변수화된 인터페이스(일반이 아닌 것과 대조적으로)는 인터페이스를 인스턴스화하기 위해 참조되는 유형 매개변수 및/또는 다른 독립적인 고정 유형이 필요한 경우에만 필요합니다.

두 개 이상의 매개변수

이전에 언급했듯이 각 유형 매개변수는 제약 조건이 전혀 필요하지 않은 경우 개별적으로 제약되어야 합니다.

매개변수화된 인터페이스는 다음과 같은 경우에만 필요합니다.

1. 자신을 참조하는 형식 매개변수입니다.

2. 인터페이스가 유형 매개변수 섹션에서 _이미 선언된_ 다른 유형 매개변수를 참조했습니다(여기서 역추적하고 싶지 않을 것입니다).

3. 인터페이스를 인스턴스화하기 위해 몇 가지 다른 독립적인 고정 유형이 필요했습니다.

이 중 (2)는 그래프 예제에서와 같이 서로 참조하는 유형 매개변수를 배제하므로 실제로 유일한 골칫거리입니다. 하나가 'Node' 또는 'Edge'를 먼저 선언했는지 여부에 관계없이 제한 인터페이스는 여전히 다른 하나가 유형 매개변수로 전달되어야 합니다.

그러나 디자인 문서에 표시된 대로 매개변수화되지 않은(자신을 참조하지 않기 때문에) NodeInterface 및 EdgeInterface를 최상위 수준에서 선언하면 이 문제를 해결할 수 있습니다. 선언 명령. 그런 다음 이러한 인터페이스를 사용하여 Graph 구조체의 형식 매개변수와 연결된 'New' 메서드의 형식 매개변수를 제한할 수 있습니다.

따라서 계약 아이디어가 더 낫다고 해도 여기서 극복할 수 없는 문제는 없는 것 같습니다.

아마도 comparable 는 이제 계약이 아닌 내장 인터페이스가 될 수 있습니다.

물론 인터페이스는 이미 가능한 것처럼 서로 내장될 수 있습니다.

인터페이스 메서드에 대한 수신기를 지정할 수 없기 때문에 포인터 메서드 문제(계약에 지정해야 하는 경우)를 어떻게 처리할지 잘 모르겠습니다. 포인터 메서드를 나타내기 위해 일부 특수 구문(예: 메서드 이름 앞에 별표 표시)이 필요할 수 있습니다.

이제 @stevenblenkinsop 의 관찰로 질지 궁금합니다. 어쨌든 누군가가 합리적인 사용 사례를 생각할 수 없다면 이것이 정말로 유용한 기능인지 확신할 수 없습니다.

개인적으로 일부 인터페이스 유형이 제네릭 제약 조건을 충족하지 못한다는 사실이 놀랍지 않다고 생각합니다. 인터페이스 유형은 어떤 경우에도 유효한 수신자 유형이 아니므로 메소드를 가질 수 없습니다.

함수에 내장된 sameTo()에 대한 Steven의 아이디어는 효과가 있지만 합계 유형을 지정하는 것은 잠재적으로 장황한 것 같습니다. 나는 유형의 전체 행을 정확한 것으로 지정할 수 있는 구문을 선호합니다.

물론 @urandom 은 현재 제네릭 초안이 존재하므로 구체적인(내장 또는 집계 내장) 유형만 나열할 수 있다는 것이 맞습니다. 그러나 제네릭 및 합계 유형 모두에 대해 제한된 인터페이스가 대신 사용되는 경우 이는 분명히 변경되어야 합니다. 따라서 다음과 같은 것이 통합 환경에서 허용된다는 점을 배제하지 않습니다.

interface Foo(T) {
    const type T, int64  // 'const' indicates types are exact i.e. no derived types
}

왜 우리는 Discriminated Unions의 부재에 대한 또 다른 산책을 발명하는 대신 언어에 Discriminated Unions를 추가할 수 없습니까?

@griesemer 당신은 알고 있을 수도 있고 모를 수도 있지만, 저는 처음부터 인터페이스를 사용하여 제약 조건을 지정하는 데 찬성했습니다. :) 저는 더 이상 그 게시물에서 제기한 정확한 아이디어가 갈 길이라고 생각하지 않습니다(특히 사물 나는 연산자를 다룰 것을 제안한다). 그리고 저는 가장 최근에 반복된 계약 디자인이 이전 버전보다 훨씬 더 마음에 듭니다. 그러나 일반적으로 제약 조건으로서의 (확장 가능성이 있는) 인터페이스가 실행 가능하고 고려할 가치가 있다는 데 전적으로 동의합니다.

@urandom

나는 당신이 그것들로 일반적인 합계 유형을 표현할 수 있다고 생각하지 않습니다.

제 요점은 "합 유형을 만들 수 있습니다"가 아니라 "합 유형이 그 유형으로 해결하는 몇 가지 문제를 해결할 수 있습니다"라는 점을 다시 강조하고 싶습니다. 문제 설명이 "합계 유형을 원합니다"인 경우 합계 유형이 유일한 솔루션이라는 것은 놀라운 일이 아닙니다. 나는 단순히 당신이 그들과 함께 해결하고 싶은 문제에 초점을 맞춘다면 그것들 없이도 가능하다는 것을 표현하고 싶었습니다.

@alanfo

그래프 예제에서 볼 수 있듯이 불가능하지는 않지만 인터페이스를 사용하여 유형 매개변수 간의 관계를 표현하는 것이 더 어색합니다.

"어색하다"는 것은 주관적인 것 같아요. 개인적으로 매개변수화된 인터페이스를 사용하는 것이 더 자연스럽고 그래프 예제가 매우 좋은 예라고 생각합니다. 나에게 그래프는 일종의 에지와 일종의 노드 사이의 관계가 아니라 엔터티입니다.

그러나 TBH, 나는 그들 중 어느 것도 정말로 다소 어색하다고 생각하지 않습니다. 당신은 거의 똑같은 것을 표현하기 위해 거의 똑같은 코드를 작성합니다. 그리고 FWIW 에는 이에 대한

@stevenblenkinsop

인터페이스 본문에 수신기 유형의 이름을 지정할 방법이 없습니다.

이 문제를 해결하는 방법은 usage-site에서 type-arguments를 사용하는 것입니다. 즉

type Adder(type T) interface {
    Add(t T) T
}

func Sum(type T Adder(T)) (vs []T) T {
    var t T
    for _, v := range vs {
        t = t.Add(v)
    }
    return t
}

이것은 통합이 작동하는 방식에 대해 약간의 주의가 필요하므로 자체 참조 유형 매개변수를 허용할 수 있지만 작동하도록 만들 수 있다고 생각합니다.

당신의 1.과 3. 나는 정말로 이해하지 못합니다. 인정해야합니다. 나는 몇 가지 구체적인 예에서 이익을 얻을 것입니다.

어쨌든, 이 논의를 계속하는 마지막에 이것을 삭제하는 것은 다소 정직하지 않지만, 이것은 아마도 제네릭 디자인의 세부 사항을 통해 이야기하는 올바른 문제가 아닐 것입니다. 이번 호의 디자인 공간을 조금 더 넓히기 위해 가져왔습니다. :) 화폐 유형에 대한 토론에 새로운 아이디어가 나온지 꽤 오래 된 것 같기 때문입니다.

```go
switch task {
case tasks.SearchAdd:
    // task is tasks.SearchAdd in this scope
case tasks.SearchUpdate:
case tasks.SearchDelete:
}

Go가 현재 상태에서 허용하는 다른 접근 방식보다 훨씬 더 Goish 정신이 될 것입니다. Haskellish 패턴 매칭이 필요하지 않으며 특정 유형까지 juist 다이빙하면 충분합니다.
나는 작업 변수의 의미를 조작하는 것이 허용되지만 좋은 생각이라고 생각하지 않습니다.

그럼 방문자 여러분의 건승을 빕니다.

왜 그 패턴 매칭은 Go에서 할 수 없다고 생각합니까? 패턴 일치의 예가 부족하면 예를 들어 Rust를 참조하십시오.

@Merovius re: "나에게 그래프는 엔티티입니다"

컴파일 타임 엔티티입니까 아니면 런타임에 표현이 있습니까? 계약과 인터페이스의 주요 차이점 중 하나는 인터페이스가 런타임 개체라는 것입니다. 가비지 수집에 참여하고 다른 런타임 개체에 대한 포인터 등을 갖습니다. 계약에서 인터페이스로 변환하는 것은 포함된 노드/꼭짓점(몇 개)에 대한 포인터가 있는 새로운 임시 런타임 객체를 도입하는 것을 의미합니다. 이는 그래프 함수 모음이 있을 때 어색해 보입니다. 함수의 필요에 따라 자체 방식으로 그래프의 다양한 부분을 가리키는 매개변수를 가져옵니다.

"그래프"가 객체처럼 보이고 계약이 실제로 특정 하위 그래프를 지정하지 않기 때문에 계약에 "그래프"를 사용하면 직관이 잘못 인도될 수 있습니다. 수학이나 법률에서와 같이 나중에 사용할 용어 집합을 정의하는 것과 비슷합니다. 어떤 경우에는 그래프 계약과 그래프 인터페이스를 모두 원할 수 있으므로 성가신 이름 충돌이 발생할 수 있습니다. 그러나 머리 위로 더 좋은 이름이 생각나지 않습니다.

이와 대조적으로 판별된 공용체는 런타임 개체입니다. 구현을 제한하지 않으면서 그것들의 배열이 어떨지 생각해야 합니다. N개 항목 배열에는 N개의 판별자와 N개의 값이 필요하며 수행할 수 있는 다양한 방법이 있습니다. (Julia는 때때로 판별자와 값을 별도의 배열에 넣는 흥미로운 표현을 가지고 있습니다.)

interface{} 체계를 사용하여 현재 모든 곳에서 발생하는 오류의 감소를 제안하지만 | 연산자의 연속 입력을 제거하려면 다음을 제안합니다.

type foobar union {
    int
    float64
}

많은 interface{} 를 이런 종류의 안전으로 대체하는 유스 케이스만으로도 라이브러리에 엄청난 이득이 될 것입니다. 암호화 라이브러리에 있는 것의 절반만 보면 이것을 사용할 수 있습니다.

같은 문제 : 아 당신은에 준 ecdsa.PrivateKey 대신 *ecdsa.PrivateKey - 여기에만 ecdsa.PrivateKey가 지원하는 일반 오류입니다. 이것들이 명확한 공용체 유형이어야 한다는 단순한 사실은 유형 안전성을 상당히 증가시킬 것입니다.

이 제안은 int|float64 비해 더 많은 _공간_을 차지하지만 사용자가 이에 대해 생각하게 합니다. 코드 기반을 훨씬 더 깨끗하게 유지합니다.

interface{} 체계를 사용하여 현재 모든 곳에서 발생하는 오류의 감소를 제안하지만 | 연산자의 연속 입력을 제거하려면 다음을 제안합니다.

type foobar union {
    int
    float64
}

많은 interface{} 를 이런 종류의 안전으로 대체하는 유스 케이스만으로도 라이브러리에 엄청난 이득이 될 것입니다. 암호화 라이브러리에 있는 것의 절반만 보면 이것을 사용할 수 있습니다.

같은 문제 : 아 당신은에 준 ecdsa.PrivateKey 대신 *ecdsa.PrivateKey - 여기에만 ecdsa.PrivateKey가 지원하는 일반 오류입니다. 이것들이 명확한 공용체 유형이어야 한다는 단순한 사실은 유형 안전성을 상당히 증가시킬 것입니다.

이 제안은 int|float64 비해 더 많은 _공간_을 차지하지만 사용자가 이에 대해 생각하게 합니다. 코드 기반을 훨씬 더 깨끗하게 유지합니다.

this(comment)를 참조하십시오. 제 제안입니다.

실제로 우리는 두 가지 아이디어를 언어로 소개할 수 있습니다. 이것은 ADT를 수행하는 두 가지 기본 방법의 존재로 이어지지만 다른 구문을 사용합니다.

기능, 특히 패턴 일치에 대한 제 제안은 호환성 및 이전 코드 기반 기능의 이점을 활용할 수 있는 기능에 대한 것입니다.

하지만 너무 과해보이지 않나요?

또한 sum 유형은 기본값으로 nil 를 갖도록 할 수 있습니다. 물론 모든 스위치에 nil 케이스가 필요합니다.
패턴 매칭은 다음과 같이 할 수 있습니다.
-- 선언

type U enum{
    A(int64),
    B(string),
}

-- 매칭

...
var a U
...
switch a {
    case A{b}:
         //process b here
    case B{b}:
         //...
    case nil:
         //...
}
...

패턴 일치가 마음에 들지 않으면 위의 Sirkon 제안을 참조하십시오.

또한 sum 유형은 기본값으로 nil 를 갖도록 할 수 있습니다. 물론 모든 스위치에 nil 케이스가 필요합니다.

컴파일 타임에 초기화되지 않은 값을 허용하지 않는 것이 더 쉽지 않을까요? 초기화된 값이 필요한 경우 합계 유형에 추가할 수 있습니다. 즉

type U enum {
  None
  A(string)
  B(uint64)
}
...
var a U.None
...
switch a {
  case U.None: ...
  case U.A(str): ...
  case U.B(i): ...
}

또한 sum 유형은 기본값으로 nil 를 갖도록 할 수 있습니다. 물론 모든 스위치에 nil 케이스가 필요합니다.

컴파일 타임에 초기화되지 않은 값을 허용하지 않는 것이 더 쉽지 않을까요? 초기화된 값이 필요한 경우 합계 유형에 추가할 수 있습니다. 즉

기존 코드를 끊습니다.

또한 sum 유형은 기본값으로 nil 를 갖도록 할 수 있습니다. 물론 모든 스위치에 nil 케이스가 필요합니다.

컴파일 타임에 초기화되지 않은 값을 허용하지 않는 것이 더 쉽지 않을까요? 초기화된 값이 필요한 경우 합계 유형에 추가할 수 있습니다. 즉

기존 코드를 끊습니다.

합계 유형이 있는 기존 코드가 없습니다. 기본값은 유형 자체에 정의된 값이어야 한다고 생각합니다. 첫 번째 항목, 첫 번째 알파벳 또는 기타.

합계 유형이 있는 기존 코드가 없습니다. 기본값은 유형 자체에 정의된 값이어야 한다고 생각합니다. 첫 번째 항목, 첫 번째 알파벳 또는 기타.

나는 처음에 당신의 생각에 동의했지만, 약간의 숙고 후에, Union에 대한 새로운 예약 이름은 ​​이전에 일부 코드베이스(union, enum 등)에서 사용될 수 있었습니다.

nil을 확인해야 하는 의무는 사용하기에 상당히 고통스러울 것이라고 생각합니다.

Go2.0에서만 해결할 수 있는 하위 호환성을 위한 브레이킹 체인지 같습니다.

합계 유형이 있는 기존 코드가 없습니다. 기본값은 유형 자체에 정의된 값이어야 한다고 생각합니다. 첫 번째 항목, 첫 번째 알파벳 또는 기타.

그러나 모든 것이 불가능한 기존 go 코드가 많이 있습니다. 그것은 확실히 변화를 깨뜨릴 것입니다. 설상가상으로, gofix 및 유사한 도구는 변수 유형을 옵션(동일한 유형)으로만 변경하여 최소한 못생긴 코드를 생성할 수 있으며, 다른 모든 경우에는 단순히 세상의 모든 것을 깨뜨릴 것입니다.

다른 것이 없다면, Reflect.Zero 는 무언가 를 반환해야 합니다. 그러나 이것들은 모두 해결할 수 있는 기술적 장애물입니다. 예를 들어, 이 장애물은 합계 유형의 0 값이 잘 정의되어 있고 그렇지 않은 경우 "패닉"이 될 경우 매우 분명합니다. 더 큰 문제는 어떤 선택이 올바른 사람이 왜 아직도 여부 및 방법 대형의 언어로 어떤 선택 맞습니다. IMO, 이러한 문제를 해결하는 가장 좋은 방법은 합계 유형이 특정 문제를 해결하거나 부족하게 생성된 문제를 해결하는 구체적인 사례에 대해 이야기하는 것입니다. 경험 보고서 의

특히 "0 값이 없어야 하며 초기화되지 않은 값을 생성할 수 없어야 함"과 "기본값은 첫 번째 항목이어야 함"이 위에서 여러 번 언급되었음을 유의하십시오. 따라서 이렇게 해야 한다고 생각하든 그렇지 않으면 실제로 새로운 정보를 추가하지 않습니다. 그러나 그것은 이미 방대한 스레드를 미래가 관련 정보를 찾기 위해 훨씬 더 길고 더 어렵게 만듭니다.

Reflect.Kind를 고려해보자. 기본 int 값이 0인 Invalid Kind가 있습니다. Reflect.Kind를 수락하는 함수가 있고 해당 유형의 초기화되지 않은 변수를 전달하면 Invalid가 됩니다. Reflect.Kind가 가상적으로 합계 유형으로 변경될 수 있는 경우 nil 값에 의존하기보다는 이름이 잘못된 항목을 기본 항목으로 갖는 동작을 유지해야 합니다.

이제 html/template.contentType을 고려해 보겠습니다. Plain 유형은 기본값이며 실제로는 대체이므로 stringify 함수에 의해 이와 같이 처리됩니다. 가상의 미래에는 그 행동이 여전히 필요할 뿐만 아니라 nil 값을 사용하는 것도 불가능합니다. nil은 이 유형의 사용자에게 아무 의미가 없기 때문입니다. 여기에서 항상 명명된 값을 반환하는 것은 거의 필수이며 해당 값이 무엇인지에 대한 명확한 기본값이 있습니다.

대수/가변/합/무엇이든 데이터 유형이 잘 작동하는 또 다른 예입니다.

따라서 우리는 트랜잭션 없이 noSQL 데이터베이스를 사용하고 있지만(분산 시스템, 트랜잭션은 우리에게 적합하지 않음) 분명한 이유로 데이터 무결성과 일관성을 좋아하며 일반적으로 단일에 대한 약간 복잡한 조건부 업데이트 쿼리로 동시 액세스 문제를 해결해야 합니다. 레코드(단일 레코드 쓰기는 원자적임).

삽입, 추가 또는 삭제할 수 있는 항목 집합을 작성하는 새 작업이 있습니다(이 작업 중 하나만).

우리가 같은 것을 가질 수 있다면

type EntityOp oneof {
    Insert   Reference
    NewState string
    Delete   struct{}
}

방법은 그냥

type DB interface {
    …
    Capture(ctx context.Context, processID string, ops map[string]EntityOp) (bool, error)
}

합계 시간의 한 가지 환상적인 용도는 AST에서 노드를 나타내는 것입니다. 또 다른 방법은 nil 를 컴파일 타임에 확인되는 option 로 바꾸는 것입니다.

@DemiMarie 하지만 오늘의 Go에서는 이 합계도 0이 될 수 있습니다. 위에서 제안한 것처럼 nil을 각 열거형의 변형으로 만들 수 있습니다. 각 스위치에는 case nil이 있지만 이 의무는 그리 나쁘지 않습니다. 기존의 모든 go 코드를 깨뜨리지 않고 이 기능을 원함(현재 우리는 모든 것을 무효화할 수 있음)

그것이 여기에 속하는지 모르겠지만 이 모든 것은 "문자열 리터럴 유형"이라는 매우 멋진 기능이 존재하는 Typescript로 남아 있으며 우리는 그렇게 할 수 있습니다.

var name: "Peter" | "Consuela"; // string type with compile-time constraint

제 생각에는 기존의 숫자 열거형보다 훨씬 나은 문자열 열거형과 같습니다.

@메로비우스
구체적인 예는 임의의 JSON으로 작업하는 것입니다.
Rust에서는 다음과 같이 나타낼 수 있습니다.
열거형 값 {
없는,
부울(bool),
번호(번호),
문자열(문자열),
배열(Vec),
개체(지도),
}

두 가지 장점으로 결합 유형:

1. 코드 자체 문서화
2. 컴파일러 또는 go vet 가 공용체 유형의 잘못된 사용을 확인하도록 허용
   (예: 모든 유형이 선택되지 않은 스위치)

구문의 경우 다음은 alias 유형 과 같이 Go1 과 호환되어야 합니다.

type Token = int | float64 | string

공용체 유형은 내부적으로 인터페이스로 구현될 수 있습니다. 중요한 것은 공용체 유형을 사용하여 코드를 더 읽기 쉽게 하고 다음과 같은 오류를 포착할 수 있다는 것입니다.

var tok Token

switch t := tok.(type) {
case int:
    // do something
}

모든 Token 유형이 스위치에서 사용되지 않기 때문에 컴파일러는 오류를 발생시켜야 합니다.

이것의 문제는 (내가 아는 한) 포인터 유형(또는 string 와 같은 포인터를 포함하는 유형)과 포인터가 아닌 유형을 함께 저장할 방법이 없다는 것입니다. 레이아웃이 다른 유형도 작동하지 않습니다. 자유롭게 수정해 주세요. 그러나 문제는 정확한 GC가 포인터와 단순 변수를 동시에 사용할 수 있는 변수와 잘 작동하지 않는다는 것입니다.

interface{} 현재 하는 것처럼 암시적 권투의 길을 갈 수 있습니다. 그러나 이것이 충분한 이점을 제공한다고 생각하지 않습니다. 여전히 영광스러운 인터페이스 유형처럼 보입니다. 대신 일종의 vet 수표를 개발할 수 있습니까?

가비지 수집기는 레이아웃을 결정하기 위해 유니온에서 태그 비트를 읽어야 합니다. 이것은 불가능한 것은 아니지만 gc를 느리게 할 수 있는 런타임에 대한 큰 변경이 될 것입니다.

대신 어떤 종류의 수의사 검사를 개발할 수 있습니까?

https://github.com/BurntSushi/go-sumtype

가비지 수집기는 레이아웃을 결정하기 위해 유니온에서 태그 비트를 읽어야 합니다.

인터페이스가 포인터가 아닌 것을 포함할 수 있을 때 인터페이스에 존재했던 것과 정확히 동일한 인종입니다. 그 디자인은 명시 적으로 멀리 이동되었습니다.

go-sumtype 재미있습니다. 감사합니다. 그러나 동일한 패키지가 두 개의 공용체 유형을 정의하면 어떻게 될까요?

컴파일러는 내부적으로 공용체 유형을 인터페이스로 구현할 수 있지만 균일한 구문과 표준 유형 검사를 추가합니다.

유니온 유형을 사용하는 N개의 프로젝트가 있고 각각이 다르고 N이 충분히 큰 경우 이를 수행하는 한 가지 방법 을 도입하는 것이 최상의 솔루션일 수 있습니다.

그러나 동일한 패키지가 두 개의 공용체 유형을 정의하면 어떻게 될까요?

별로? 로직은 유형별로 다르며 더미 메서드를 사용하여 구현자를 인식합니다. 더미 메서드에 다른 이름을 사용하면 됩니다.

유형 레이아웃을 지정하는 @skybrian IIRC 현재 비트맵은 현재 한 곳에 저장되어 있습니다. 개체당 이러한 항목을 추가하면 많은 점프가 추가되고 모든 선택적 개체가 GC 루트가 됩니다.

이것의 문제는 (내 지식으로는) 포인터 유형(또는 문자열과 같은 포인터를 포함하는 유형)과 포인터가 아닌 유형을 함께 저장할 방법이 없다는 것입니다.

나는 이것이 필요하다고 생각하지 않는다. 컴파일러는 포인터 맵이 일치할 때 유형에 대한 레이아웃을 겹칠 수 있고 그렇지 않으면 그렇지 않을 수 있습니다. 일치하지 않으면 연속적으로 배치하거나 현재 인터페이스에 사용되는 포인터 접근 방식을 사용하는 것이 좋습니다. 구조체 멤버에 대해 인접하지 않은 레이아웃을 사용할 수도 있습니다.

그러나 이것이 충분한 이점을 제공한다고 생각하지 않습니다. 여전히 영광스러운 인터페이스 유형처럼 보입니다.

내 제안 에서 공용체 유형은 _정확히_ 영광스러운 인터페이스 유형입니다. 공용체 유형은 열거된 유형 집합만 저장할 수 있는 인터페이스의 하위 집합일 뿐입니다. 이것은 잠재적으로 컴파일러가 특정 유형 세트에 대해 보다 효율적인 저장 방법을 선택할 수 있는 자유를 제공하지만, 이는 주요 동기가 아니라 구현 세부사항입니다.

@rogpeppe - 호기심에 sum 유형을 직접 사용할 수 있습니까? 아니면 알려진 유형으로 명시적으로 캐스트해야 합니까? 알려진 유형으로 지속적으로 캐스트해야 하는 경우 인터페이스를 통해 이미 제공된 것보다 이것이 제공하는 이점이 무엇인지 정말로 모르기 때문입니다. 내가 볼 수있는 주요 이점은 일종의 컴파일 타임 오류 검사입니다. 비정렬화는 런타임에 계속 발생하므로 잘못된 유형이 전달되는 문제가 발생할 가능성이 더 큽니다. 다른 이점은 더 제한적인 인터페이스로, 언어 변경을 보증하지 않는다고 생각합니다.

내가 할 수

type FooType int | float64

func AddOne(foo FooType) FooType {
    return foo + 1
}

// if this can be done, what happens here?
type FooType nil | int
func AddOne(foo FooType) FooType {
    return foo + 1
}

이 작업을 수행할 수 없으면 다음과 큰 차이가 없습니다.

type FooType interface{}

func AddOne(foo FooType) (FooType, error) {
    switch v := foo.(type) {
        case int:
              return v + 1, nil
        case float64:
              return v + 1.0, nil
    }

    return nil, fmt.Errorf("invalid type %T", foo)
}

// versus
type FooType int | float64

func AddOne(foo FooType) FooType {
    switch v := foo.(type) {
        case int:
              return v + 1
        case float64:
              return v + 1.0
    }

    // assumes the compiler knows that there is no other type is 
    // valid and thus this should always returns a value
    // Would the compiler error out on incomplete switch types?
}

@xibz

궁금해서 sum 유형을 직접 사용할 수 있습니까? 아니면 알려진 유형으로 명시적으로 캐스트해야 합니까? 알려진 유형으로 지속적으로 캐스트해야 하는 경우 인터페이스를 통해 이미 제공된 것보다 이것이 제공하는 이점이 무엇인지 정말로 모르기 때문입니다.

@rogpeppe 틀리면 지적해주세요🙏
항상 패턴 일치를 수행해야 하는 것(함수형 프로그래밍 언어에서 합계 유형으로 작업할 때 "캐스팅"이 호출되는 방식)은 실제로 합계 유형을 사용할 때의 가장 큰 이점 중 하나입니다. 개발자가 합계 유형의 가능한 모든 모양을 명시적으로 처리하도록 하는 것은 개발자가 실제로는 다른 유형이지만 주어진 유형이라고 생각하는 변수를 사용하지 못하도록 하는 방법입니다. 과장된 예는 JavaScript에서 다음과 같습니다.

const a = "1" // string "1"
const b = a + 5 // string "15" and not number 6

이 작업을 수행할 수 없으면 다음과 큰 차이가 없습니다.

나는 당신이 몇 가지 장점을 스스로 말한 것 같아요. 그렇지 않습니까?
↓

내가 볼 수있는 주요 이점은 일종의 컴파일 타임 오류 검사입니다. 비정렬화는 런타임에 계속 발생하므로 잘못된 유형이 전달되는 문제가 발생할 가능성이 더 큽니다. 다른 이점은 더 제한적인 인터페이스로, 언어 변경을 보증하지 않는다고 생각합니다.

// Would the compiler error out on incomplete switch types?

함수형 프로그래밍 언어가 하는 일에 따라 이것이 가능하고 구성 가능해야 한다고 생각합니다 👍

@xibz 는 컴파일 타임 대 런타임에 수행할 수 있기 때문에 성능도 있지만, 제네릭이 있기를 바랍니다. 내가 죽기 하루 전입니다.

@xibz

궁금해서 sum 유형을 직접 사용할 수 있습니까? 아니면 알려진 유형으로 명시적으로 캐스트해야 합니까?

형식의 모든 멤버가 해당 메서드를 공유하는 경우 메서드를 호출할 수 있습니다.

int | float64 를 예로 들면 결과는 다음과 같습니다.

var x int|float64 = int(2)
var y int|float64 = float64(0.5)
fmt.Println(x * y)

int 에서 float64 로 암시적 변환을 수행합니까? 또는 float64 에서 int . 아니면 패닉에 빠질까요?

거의 맞습니다. 대부분의 경우 사용하기 전에 유형 확인을 해야 합니다. 단점이 아니라 장점이라고 생각합니다.

런타임 이점이 중요할 수 있습니다. 예제 유형을 계속하려면 [](int|float64) 유형의 슬라이스는 포인터를 포함할 필요가 없습니다. 그 이유는 유형의 모든 인스턴스를 몇 바이트(정렬 제한으로 인해 16바이트)로 나타낼 수 있기 때문입니다. 경우에 따라 성능이 크게 향상됩니다.

@rogpeppe

대부분의 경우 사용하기 전에 유형 확인을 해야 합니다. 단점이 아니라 장점이라고 생각합니다.

단점이 아니라는 점에는 동의합니다. 인터페이스와 달리 이것이 우리에게 어떤 이점을 제공하는지 알아보려고 합니다.

형식의 슬라이스는 몇 바이트(정렬 제한으로 인해 16바이트)로 형식의 모든 인스턴스를 나타낼 수 있기 때문에 포인터를 포함할 필요가 없으며, 이는 경우에 따라 상당한 성능 향상으로 이어질 수 있습니다.

흠, 나는 내가 이것의 중요한 부분을 사는지 너무 확신하지 못합니다. 아주 드문 경우지만 메모리 크기가 절반으로 줄어들 것이라고 확신합니다. 즉, 저장된 메모리가 언어 변경에 충분하지 않다고 생각합니다.

@stouf

항상 패턴 일치를 수행해야 하는 것(함수형 프로그래밍 언어에서 합계 유형으로 작업할 때 "캐스팅"이 호출되는 방식)은 실제로 합계 유형 사용의 가장 큰 이점 중 하나입니다.

그러나 아직 인터페이스로 처리되지 않은 언어에 어떤 이점이 있습니까? 원래 나는 화폐를 좋아했는데, 생각하기 시작하면서 그것이 가져다줄 혜택을 잃어버렸습니다.

그렇긴 해도 sum 유형을 사용하여 더 깔끔하고 읽기 쉬운 코드를 제공할 수 있다면 100% 찬성할 것입니다. 그러나 겉으로 보기에는 인터페이스 코드와 거의 동일하게 보입니다.

개인 메서드 및 각 구현과의 인터페이스를 통해 합계 유형 에뮬레이션을 생성하는 작은 유틸리티를 만들었습니다. 일부 사용자에게는 도움이 될 수 있습니다: https://github.com/sirkon/go-oneof

제네릭에 대한 최근 디자인 초안에서는 합계 유형이 이에 연결될 수 있습니다.

초안에서 계약 대신 인터페이스를 사용하는 아이디어가 떠올랐고 인터페이스는 유형 목록을 지원해야 합니다.

type Foo interface { 
     int64, int32, int, uint, uint32, uint64
}

그 자체는 메모리로 가득 찬 공용체를 생성하지 않지만 제네릭 함수 또는 구조체에서 사용할 때 박싱되지 않고 유한 유형 목록을 처리할 때 최소한 유형 안전성을 제공합니다.

그리고 아마도 유형 스위치 내에서 이러한 특정 인터페이스를 사용하려면 그러한 스위치가 철저해야 할 것입니다.

이것은 이상적인 짧은 구문(예: Foo | int32 | []Bar )은 아니지만, 뭔가 있습니다.

제네릭에 대한 최근 디자인 초안에서는 합계 유형이 이에 연결될 수 있습니다.

초안에서 계약 대신 인터페이스를 사용하는 아이디어가 떠올랐고 인터페이스는 유형 목록을 지원해야 합니다.

type Foo interface { 
     int64, int32, int, uint, uint32, uint64
}

그 자체는 메모리로 가득 찬 공용체를 생성하지 않지만 제네릭 함수 또는 구조체에서 사용할 때 박싱되지 않고 유한 유형 목록을 처리할 때 최소한 유형 안전성을 제공합니다.

그리고 아마도 유형 스위치 내에서 이러한 특정 인터페이스를 사용하려면 그러한 스위치가 철저해야 할 것입니다.

이것은 이상적인 짧은 구문(예: Foo | int32 | []Bar )은 아니지만, 뭔가 있습니다.

내 제안과 매우 유사합니다. https://github.com/golang/go/issues/19412#issuecomment -520306000

type foobar union {
  int
  float
}

@mathieudevos 와우, 저는 사실 그게 꽤 마음에

나에게 최신 제네릭 제안에서 가장 이상한 점(사실 유일하게 남아 있는 이상한 점)은 인터페이스의 유형 목록입니다. 그들은 단지 아주 적합 하지 않습니다. 그런 다음 유형 매개변수 제약 조건으로만 사용할 수 있는 일부 인터페이스를 사용하게 됩니다.

union 개념은 "메소드 및 원시 유형을 포함하는 제약 조건"을 달성하기 위해 interface 에 union 를 포함할 수 있기 때문에 제 생각에는 훌륭하게 작동합니다. 인터페이스는 그대로 계속 작동하며 유니온을 중심으로 정의된 시맨틱으로 일반 코드에서 사용할 수 있으며 이상한 느낌이 사라집니다.

// Ordinary interface
type Stringer interface {
    String() string
}

// Type union
type Foobar union {
    int
    float
}

// Equivalent to an interface with a type list
type FoobarStringer interface {
    Stringer
    Foobar
}

// Unions can intersect
type SuperFoo union {
    Foobar
    int
}

// Doesn't compile since these unions can't intersect
type Strange interface {
    Foobar
    union {
        int
        string
    }
}

편집 - 사실, 방금 이 CL을 보았습니다: https://github.com/golang/go/commit/af48c2e84b52f99d30e4787b1b8d527b5cd2ab64

이 변경의 주요 이점은 일반
(비제약) 유형 목록이 있는 인터페이스 사용

...엄청난! 인터페이스는 일반 및 제약 조건 사용 전반에 걸쳐 의미 체계를 통합하는 합계 유형으로 완전히 사용할 수 있습니다. (물론 아직 켜지지 않았지만, 나는 그것이 향하고 있는 훌륭한 목적지라고 생각한다.)

현재 제네릭 디자인 초안에서 sum 유형의 버전이 나타나는 방식에 대해 논의하기 위해 #41716을 열었습니다.

대수 데이터 유형에 대한 @henryas 의 오래된 제안을 공유하고 싶었습니다. 제공된 사용 사례로 매우 잘 작성되었습니다.
https://github.com/golang/go/issues/21154
아쉽게도 당일 @mvdan 에 의해 작품 감상 없이 마감되었습니다. 나는 그 사람이 정말로 그렇게 느꼈을 것이라고 확신하고 따라서 gh 계정에서 더 이상 활동이 없습니다. 그 사람에게 미안합니다.

나는 #21154를 정말 좋아한다. 그러나 (따라서 @mvdan 의) 주석은 속임수로 닫는

예, 해당 문제에서 설명한 것과 유사한 방식으로 더 높은 수준의 비즈니스 논리를 모델링할 수 있는 기능을 정말 갖고 싶습니다. 열거형과 같은 제한된 옵션에 대한 합계 유형 및 다른 문제에서와 같이 제안된 허용 유형은 도구 상자에서 훌륭할 것입니다. 지금은 Go의 비즈니스/도메인 코드가 약간 투박하게 느껴질 때가 있습니다.

내 유일한 피드백은 인터페이스 내부의 type foo,bar 가 약간 어색하고 2급처럼 보이며 null 허용과 null 허용이 아닌(가능한 경우) 선택이 있어야 한다는 데 동의합니다.

@ProximaB "gh 계정에 더 이상 활동이 없습니다"라고 말하는 이유를 이해하지 못합니다. 그 이후로 그들은 Go 프로젝트에 관한 많은 다른 문제들에 대해서도 작성하고 댓글을 달았습니다. 나는 그들의 활동이 그 문제에 의해 전혀 영향을 받았다는 증거를 보지 못했습니다.

게다가, 나는 Daniel이 이 문제의 속임수로 그 문제를 닫는 것에 강력하게 동의합니다. @andig 가 다른 것을 제안한다고 말하는 이유를 이해하지 못합니다. 내가 #21154의 텍스트를 이해할 수 있는 한, 그것은 우리가 여기서 논의하고 있는 것과 정확히 동일한 것을 제안하며, 정확한 구문조차도 이 메가스레드의 어딘가에서 이미 제안되어도 전혀 놀라지 않을 것입니다(의미론, 여러 번). 사실, Daniels 종결이 이 문제의 길이만큼 옳았다는 것이 입증되었다고까지 말할 수 있습니다. 이미 #21154에 대한 매우 상세하고 미묘한 논의가 포함되어 있기 때문에 모든 것을 반복하는 것은 힘들고 중복되었을 것이기 때문입니다.

나는 제안을 속임수로 마감하는 것이 실망스러울 수 있다는 점에 동의하고 이해합니다. 그러나 나는 그것을 피하는 실용적인 방법을 모릅니다. 한 곳에서 토론을 하는 것은 관련된 모든 사람에게 유익한 것으로 보이며, 동일한 문제에 대해 토론 없이 여러 문제를 열어 두는 것은 분명히 무의미합니다.

게다가, 나는 Daniel이 이 문제의 속임수로 그 문제를 닫는 것에 강력하게 동의합니다. @andig 가 다른 것을 제안한다고 말하는 이유를 이해하지 못합니다. 내가 #21154의 텍스트를 이해할 수 있는 한, 그것은 우리가 여기서 논의하고 있는 것과 정확히 같은 것을 제안합니다.

이 문제를 다시 읽고 동의합니다. 이 문제와 제네릭 계약을 혼동한 것 같습니다. 합계 유형을 강력히 지지합니다. 가혹하게 들릴 의도는 아니었으니 그런 식으로 들리셨다면 사과를 받아주세요.

저는 사람이고 원예 문제는 때때로 까다로울 수 있으므로 실수를 할 때 반드시 지적하십시오. :) 하지만 이 경우 특정 합계 유형 제안이 https:/ 와 같이 이 스레드에서 분기되어야 한다고 생각합니다

저는 사람이고 원예 문제는 때때로 까다로울 수 있으므로 실수를 할 때 반드시 지적하십시오. :) 하지만 이 경우 특정 합계 유형 제안이 #19412 처럼 이 스레드에서 분기되어야 한다고 생각합니다.

@mvdan 은 인간이 아닙니다. 날 믿어. 나는 그의 이웃이다. 농담이야.

관심을 가져주셔서 감사합니다. 나는 내 제안에 그렇게 집착하지 않습니다. 자유롭게 조작하고 수정하고 일부를 격추하십시오. 저는 실생활에 바빠서 토론에 적극적으로 참여할 기회가 없었습니다. 사람들이 내 제안을 읽고 실제로 좋아한다는 것을 아는 것이 좋습니다.

원래 의도는 공통 동작을 공유하지 않아도 되는 도메인 관련성을 기준으로 유형을 그룹화하고 컴파일러에서 이를 적용하도록 하는 것입니다. 제 생각에는 이것은 컴파일 중에 수행되는 정적 검증 문제일 뿐입니다. 컴파일러가 유형 간의 복잡한 관계를 유지하는 코드를 생성할 필요가 없습니다. 생성된 코드는 이러한 도메인 유형을 일반 인터페이스 유형인 것처럼 정상적으로 처리할 수 있습니다.{} 차이점은 이제 컴파일러가 컴파일 시 추가 정적 유형 검사를 수행한다는 것입니다. 이것이 기본적으로 내 제안 #21154의 핵심입니다.

@henryas 반가워요 ! 😊
Golang이 오리 타이핑을 사용하지 않았더라면 유형 간의 관계가 훨씬 더 엄격해지고 제안서에서 설명한 대로 도메인 관련성을 기준으로 개체를 그룹화할 수 있었을지 궁금합니다.

@henryas 반가워요 ! 😊
Golang이 오리 타이핑을 사용하지 않았더라면 유형 간의 관계가 훨씬 더 엄격해지고 제안서에서 설명한 대로 도메인 관련성을 기준으로 개체를 그룹화할 수 있었을지 궁금합니다.

그럴 수는 있지만 Go 1과의 호환성 약속을 깨뜨릴 것입니다. 명시적 인터페이스가 있는 경우 합계 유형이 필요하지 않을 것입니다. 그러나 오리 타이핑이 반드시 나쁜 것은 아닙니다. 그것은 어떤 것들을 더 가볍고 편리하게 만듭니다. 나는 오리 타이핑을 즐긴다. 작업에 적합한 도구를 사용하는 것입니다.

@henryas 동의합니다. 가설적인 질문이었습니다. 바둑 제작자는 모든 기복을 확실히 깊이 생각했습니다.
반면에 인터페이스 준수 확인과 같은 코딩 가이드는 절대 나타나지 않습니다.
https://github.com/uber-go/guide/blob/master/style.md#verify -interface-compliance

이 주제를 벗어난 토론을 다른 곳에서 할 수 있습니까? 이 문제에 많은 사람들이 구독하고 있습니다.
오픈 인터페이스 만족은 Go의 시작 이후부터 계속되어 왔으며 앞으로도 변하지 않을 것입니다.