@derekparker #19412에서 Go2 제안에 대한 토론이 있습니다.

오늘 일찍 읽었지만 유효한 유형 값에 중점을 둔 유효한 유형에 더 초점을 맞춘 것 같습니다. 아마도 이것은 그 제안의 하위 집합일 수도 있지만 오늘날 Go에 포함될 수 있는 유형 시스템에 대한 덜 광범위한 변경이기도 합니다.

열거형은 모든 유형이 동일하고 메서드에 의해 각각에 연결된 값이 있는 합계 유형의 특별한 경우입니다. 더 입력해야 하지만 효과는 동일합니다. 그럼에도 불구하고, 그것은 하나 또는 다른 것이 될 것이며, 합계 유형은 더 많은 근거를 다루며 합계 유형조차도 가능성이 낮습니다. Go1 호환성 계약으로 인해 Go2까지는 아무 일도 일어나지 않습니다. 어쨌든 이러한 제안에는 최소한 새 키워드가 필요하기 때문입니다.

충분히 공평하지만 이러한 제안 중 어느 것도 호환성 계약을 위반하지 않습니다. 합계 유형이 Go1에 추가하기에는 "너무 큽니다"라는 의견이 있었습니다. 그렇다면 이 제안은 Go2에서 전체 금액 유형으로 가는 디딤돌이 될 수 있는 귀중한 중간 지점입니다.

둘 다 식별자로 사용하여 유효한 Go1 코드를 깨뜨릴 새 키워드가 필요합니다.

나는 그것이 해결 될 수 있다고 생각한다.

새로운 언어 기능에는 매력적인 사용 사례가 필요합니다. 모든 언어 기능은 유용하거나 아무도 제안하지 않습니다. 문제는 언어를 복잡하게 만들고 모든 사람이 새로운 개념을 배우도록 요구하는 것을 정당화할 만큼 유용합니까? 여기서 매력적인 사용 사례는 무엇입니까? 사람들은 이것을 어떻게 사용할까요? 예를 들어, 사람들은 유효한 열거형 값 집합을 반복할 수 있기를 기대합니까? 그렇다면 어떻게 하시겠습니까? 이 제안이 일부 스위치에 기본 케이스를 추가하지 않도록 하는 것 이상을 수행합니까?

현재 Go에서 열거형을 작성하는 관용적 방법은 다음과 같습니다.

type SearchRequest int

const (
    Universal SearchRequest = iota
    Web
    Images
    Local
    News
    Products
    Video
)

이것은 OR:ed(연산자 | 사용)할 수 있는 플래그를 쉽게 생성할 수 있다는 장점이 있습니다.

type SearchRequest int

const (
    Universal SearchRequest = 1 << iota
    Web
    Images
    Local
    News
    Products
    Video
)

enum 키워드를 도입하면 훨씬 더 짧아질 것 같지 않습니다.

@md2perpe 열거형이 아닙니다.

1. 열거하거나 반복할 수 없습니다.
2. 유용한 문자열 표현이 없습니다.
3. 그들은 정체성이 없습니다:

```가다
패키지 메인

수입(
"fmt"
)

함수 메인() {
유형 SearchRequest 정수
상수 (
범용 검색 요청 = iota
편물
)

const (
    Another SearchRequest = iota
    Foo
)

fmt.Println("Should be false: ", (Web == Foo))
    // Prints: "Should be false:  true"

}
````

Go가 일류 시민으로서 일부 열거형이 필요하다는 @derekperkins 의 말에 전적으로 동의합니다. 어떻게 생겼을지는 모르겠지만, Go 1 유리집을 부수지 않고 는 가능할 거라고 생각합니다.

@md2perpe iota 는 열거형에 접근하는 매우 제한된 방법으로 제한된 상황에서 잘 작동합니다.

1. int 가 필요합니다.
2. 외부 상태를 나타내지 않고 패키지 내부에서만 일관성을 유지해야 합니다.

외부 플래그에 매우 일반적인 문자열이나 다른 유형을 나타내야 하는 즉시 iota 는 작동하지 않습니다. 외부/데이터베이스 표현과 일치시키려면 iota 를 사용하지 않을 것입니다. 왜냐하면 소스 코드에서 순서를 지정하고 재정렬하면 데이터 무결성 문제가 발생할 수 있기 때문입니다.

이것은 단순히 코드를 더 짧게 만들기 위한 편의상의 문제가 아닙니다. 이것은 오늘날 언어로 시행할 수 없는 방식으로 데이터 무결성을 허용하는 제안입니다.

@ianlancetaylor

예를 들어, 사람들은 유효한 열거형 값 집합을 반복할 수 있기를 기대합니까? 그렇다면 어떻게 하시겠습니까?

@bep이 언급한 것처럼 견고한 사용 사례라고 생각합니다. 반복은 표준 Go 루프처럼 보이고 정의된 순서대로 반복될 것이라고 생각합니다.

for i, val := range SearchRequest {
...
}

Go에서 iota 이상을 추가했다면 그 시점에서 대수 데이터 유형을 선택하지 않는 이유는 무엇입니까?

정의 순서에 따른 정렬을 확장하고 protobuf의 예를 따르면 필드의 기본값은 첫 번째 정의된 필드가 될 것이라고 생각합니다.

@bep 편리하지는 않지만 다음 속성을 모두 얻을 수 있습니다.

package main

var SearchRequests []SearchRequest
type SearchRequest struct{ name string }
func (req SearchRequest) String() string { return req.name }

func Request(name string) SearchRequest {
    req := SearchRequest{name}
    SearchRequests = append(SearchRequests, req)
    return req
}

var (
    Universal = Request("Universal")
    Web       = Request("Web")

    Another = Request("Another")
    Foo     = Request("Foo")
)

func main() {
    fmt.Println("Should be false: ", (Web == Foo))
    fmt.Println("Should be true: ", (Web == Web))
    for i, req := range SearchRequests {
        fmt.Println(i, req)
    }
}

컴파일 타임 체크된 열거형은 좋은 생각이 아니라고 생각합니다. 나는 go가 바로 지금 이것을 가지고 있다고 믿습니다. 내 추론은

• 컴파일 시 확인된 열거형은 추가 또는 제거의 경우에 역방향 또는 순방향 호환이 되지 않습니다. #18130은 점진적인 코드 복구를 가능하게 하기 위해 상당한 노력을 기울였습니다. 열거형은 그 노력을 파괴할 것입니다. 열거형 집합을 변경하려는 모든 패키지는 자동으로 모든 가져오기 도구를 강제로 중단합니다.
• 원래 주석이 주장하는 것과 달리 protobuf(특정 이유 때문에)는 실제로 열거형 필드의 유효성을 확인하지 않습니다. proto2는 enum에 대한 알 수 없는 값을 알 수 없는 필드로 취급해야 한다고 지정하고 proto3은 생성된 코드가 인코딩된 값 으로 이를 표현할 방법이 있어야 한다고 지정합니다(go가 현재 fake-enums에서 수행하는 것과 정확히 같습니다).
• 결국, 그것은 실제로 많이 추가 되지 않습니다. 스트링거 도구를 사용하여 스트링화를 얻을 수 있습니다. 센티넬 MaxValidFoo const를 추가하여 반복을 얻을 수 있습니다(그러나 위의 주의 사항 참조. 요구 사항이 없어야 함). 처음부터 두 개의 const-decls 가 없어야 합니다. 이를 확인하는 도구를 CI에 통합하기만 하면 됩니다.
• 나는 int 이외의 다른 유형이 실제로 필요하다고 생각하지 않습니다. 스트링거 도구는 이미 스트링과 스트링 간의 변환을 다루고 있어야 합니다. 결국 생성된 코드는 컴파일러가 생성하는 것과 동일합니다("string-enum"에 대한 비교가 바이트를 반복할 것이라고 진지하게 제안하지 않는 한...)

전반적으로 저에게는 엄청난 -1입니다. 아무것도 추가하지 않을 뿐만 아니라; 적극적으로 아프다.

Go의 현재 열거형 구현은 매우 간단하고 충분한 컴파일 시간 검사를 제공한다고 생각합니다. 실제로 기본 패턴 일치가 있는 일종의 Rust 열거형을 기대하지만 Go1 보증을 깨뜨릴 수 있습니다.

열거형은 합계 유형의 특별한 경우이고 일반적인 지혜는 합계 유형을 시뮬레이트하기 위해 인터페이스를 사용해야 한다는 것이므로 대답은 분명히 https://play.golang.org/p/1BvOakvbj2 입니다.

(확실하지 않은 경우: 예, 농담입니다. 고전적인 프로그래머 방식에서는 한 단계 더 나아가겠습니다.)

진지하게 말하자면, 이 스레드에서 논의된 기능의 경우 몇 가지 추가 도구가 유용할 것입니다.

스트링거 도구와 마찬가지로 "레인저" 도구는 위에서 링크한 코드에서 Iter func에 해당하는 기능을 생성할 수 있습니다.

유선을 통해 더 쉽게 보낼 수 있도록 {Binary,Text}{Marshaler,Unmarshaler} 구현을 생성할 수 있습니다.

나는 가끔 아주 유용할 이와 같은 작은 것들이 많이 있을 것이라고 확신합니다.

인터페이스로 시뮬레이션된 합계 유형의 철저한 검사를 위한 몇 가지 검사/린터 도구가 있습니다. 케이스가 누락되거나 잘못된 형식화되지 않은 상수가 사용되는 경우를 알려주는 iota 열거형에 대한 것이 없을 이유가 없습니다(아마도 0 이외의 다른 값을 보고해야 합니까?).

언어 변경 없이도 개선의 여지가 분명히 있습니다.

열거형은 이미 확립된 유형 시스템을 보완합니다. 이 문제의 많은 예에서 보여주듯이 열거형의 구성 요소는 이미 존재합니다. 채널이 더 많은 기본 유형을 기반으로 하는 높은 수준의 추상화인 것처럼 열거형도 동일한 방식으로 빌드되어야 합니다. 인간은 오만하고 서투르며 건망증이 있습니다. 열거형과 같은 메커니즘은 인간 프로그래머가 프로그래밍 오류를 줄이는 데 도움이 됩니다.

@bep 나는 당신의 세 가지 요점에 모두 동의하지 않습니다. Go 관용적 열거형은 유효한 값의 반복이 없고 문자열로의 자동 변환이 없으며 반드시 고유한 ID를 갖지 않는 C 열거형과 매우 유사합니다.

반복은 있으면 좋지만 대부분의 경우 반복을 원할 경우 첫 번째 값과 마지막 값에 대해 상수를 정의하는 것이 좋습니다. iota 는 자동으로 마지막 값을 만들기 때문에 새 값을 추가할 때 업데이트할 필요가 없는 방식으로 그렇게 할 수도 있습니다. 언어 지원이 의미 있는 차이를 만드는 상황은 열거형 값이 연속적이지 않은 경우입니다.

문자열로의 자동 변환은 작은 값일 뿐입니다. 특히 이 제안에서 문자열 값은 int 값에 해당하도록 작성되어야 하므로 직접 문자열 값 배열을 명시적으로 작성하는 것보다 얻을 수 있는 것은 거의 없습니다. 다른 제안에서는 더 많은 가치가 있을 수 있지만 변수 이름이 문자열 표현과 일치하도록 강제하는 것에도 단점이 있습니다.

마지막으로, 고유한 정체성은 전혀 유용한 기능인지 확신이 서지 않습니다. 열거형은 Haskell과 같은 합계 유형이 아닙니다. 그들은 이름이 지정된 숫자입니다. 예를 들어 열거형을 플래그 값으로 사용하는 것은 일반적입니다. 예를 들어, ReadWriteMode = ReadMode | WriteMode 를 가질 수 있고 이것은 유용한 것입니다. 다른 값을 가질 수도 있습니다. 예를 들어 DefaultMode = ReadMode 가 있을 수 있습니다. 어떤 방법으로도 누군가가 const DefaultMode = ReadMode 를 쓰는 것을 막을 수는 없습니다. 별도의 선언에서 발생하도록 요구하는 데 어떤 목적이 있습니까?

@bep 나는 당신의 세 가지 요점에 모두 동의하지 않습니다. Go 관용적 열거형은 유효한 값의 반복이 없고 문자열로의 자동 변환이 없으며 반드시 고유한 ID를 갖지 않는 C 열거형과 매우 유사합니다.

@alercah , 이 idomatic Go 를 "승리적인 논쟁"으로 논의에 끌어들이지 마십시오. Go에는 내장된 Enum이 없으므로 존재하지 않는 일부 idom에 대해 이야기하는 것은 거의 의미가 없습니다.

Go는 더 나은 C/C++ 또는 덜 장황한 Java 로 제작되었으므로 후자와 비교하는 것이 더 합리적입니다. 그리고 Java에는 Enum type 가 내장되어 있습니다("Java 프로그래밍 언어 열거형 유형은 다른 언어의 열거형 유형보다 훨씬 강력합니다. "): https://docs.oracle.com/javase/tutorial/java /javaOO/enum.html

그리고 "훨씬 더 강력한 부분"에 동의하지 않을 수 있지만 Java Enum 유형에는 내가 언급한 세 가지 기능이 모두 있습니다.

나는 Go가 더 가볍고 단순하다는 주장에 감사할 수 있으며, 이 방식을 유지하려면 약간의 타협이 필요하며, 이 스레드에서 작동하는 몇 가지 해킹 해결 방법을 보았지만 iota int만으로는 열거형을 만들 수 없습니다.

열거 및 자동 문자열 변환은 '생성 이동' 기능의 좋은 후보입니다. 우리는 이미 몇 가지 솔루션을 가지고 있습니다. Java 열거형은 고전적인 열거형과 합계 유형의 중간에 있습니다. 그래서 제 생각에는 나쁜 언어 디자인입니다.
관용적인 Go의 핵심은 X 언어에서 Y 언어로 모든 기능을 복사해야 하는 강력한 이유가 아닙니다. 누군가에게 익숙하다는 이유 때문입니다.

Java 프로그래밍 언어 열거형 유형은 다른 언어의 열거형보다 훨씬 강력합니다.

그것은 10년 전에 사실이었습니다. 합계 유형 및 패턴 일치로 구동되는 Rust의 Option의 최신 제로 비용 구현을 참조하십시오.

관용적인 Go의 핵심은 X 언어에서 Y 언어로 모든 기능을 복사해야 하는 강력한 이유가 아닙니다. 누군가에게 익숙하다는 이유 때문입니다.

나는 여기에 주어진 결론에 그다지 동의하지 않지만 _ 관용적 바둑_을 사용하는 것은 바둑을 예술적인 받침대 위에 올려놓는 것입니다. 대부분의 소프트웨어 프로그래밍은 상당히 지루하고 실용적입니다. 그리고 종종 드롭다운 상자를 열거형으로 채워야 하는 경우가 많습니다.

//go:generate enumerator Foo,Bar
한 번 작성하면 모든 곳에서 사용할 수 있습니다. 이 예는 추상적임에 유의하십시오.

@bep 원래 댓글을 잘못 읽으신 것 같습니다. "Go idiomatic enums"는 Foo int + const-decl + iota 유형을 사용하는 현재 구성을 참조해야 하며, "제안하는 것이 관용적이지 않습니다"라고 말하는 것이 아닙니다.

@rsc Go2 레이블과 관련하여 이는 이 제안을 제출한 제 추론에 어긋납니다. #19412는 전체 합계 유형 제안으로, 여기에서 내 간단한 열거형 제안보다 더 강력한 상위 집합이며 Go2에서 보고 싶습니다. 내 관점에서 볼 때 향후 5년 내에 Go2가 발생할 가능성은 희박하고 더 짧은 시간 내에 무언가가 발생하는 것을 보고 싶습니다.

새로운 예약 키워드 enum 에 대한 제 제안이 BC에서 불가능하다면 완전한 언어 통합이든 go vet 에 내장된 도구든 이를 구현하는 다른 방법이 있습니다. 처음에 말했듯이 구문에 대해서는 특별히 신경 쓰지 않지만 새로운 사용자에게 상당한 인지 부담을 주지 않으면서 오늘날 Go에 가치 있는 추가 기능이 될 것이라고 굳게 믿습니다.

Go 2 이전에는 새 키워드를 사용할 수 없습니다. Go 1 호환성 보장에 대한 명백한 위반입니다.

개인적으로, 나는 아직 열거형에 대한 설득력 있는 주장을 보지 못하고 있습니다. 그 문제에 관해서는 Go 2의 경우에도 합계 유형에 대한 것입니다. 나는 그것이 일어날 수 없다고 말하는 것이 아닙니다. 그러나 Go 언어의 목표 중 하나는 언어의 단순성입니다. 언어 기능이 유용하다는 것만으로는 충분하지 않습니다. 모든 언어 기능은 유용합니다. 유용하지 않으면 아무도 제안하지 않습니다. Go에 기능을 추가하려면 기능에 언어를 복잡하게 만들 가치가 있을 만큼 충분히 매력적인 사용 사례가 있어야 합니다. 가장 매력적인 사용 사례는 적어도 지금은 큰 어색함이 없이는 기능 없이는 작성할 수 없는 코드입니다.

Go에서 열거형을 보고 싶습니다. 제한된 수의 유효한 입력이 있는 노출된 API(또는 내 앱 외부의 제한된 API로 작업)를 제한하고 싶은 자신을 끊임없이 찾고 있습니다. 나에게 이것은 열거 형을위한 완벽한 장소입니다.

예를 들어, 일종의 RPC 스타일 API에 연결하고 지정된 작업/작동 코드 집합이 있는 클라이언트 앱을 만들 수 있습니다. 이를 위해 const 를 사용할 수 있지만 누군가(저를 포함하여!)가 잘못된 코드를 보내는 것을 막는 것은 없습니다.

반면에 동일한 API에 대해 서버 측을 작성하는 경우 열거형에 switch 문을 작성할 수 있으면 좋을 것입니다. 그러면 컴파일러 오류(또는 적어도 일부 go vet 경고) 열거형의 모든 가능한 값이 확인되지 않은 경우(또는 최소한 default: 이 존재하는 경우).

나는 이것이 (열거형) Swift 가 정말로 옳았 던 영역이라고 생각합니다.

일종의 RPC 스타일 API에 연결하고 지정된 작업/작동 코드 집합이 있는 클라이언트 앱을 만들 수 있습니다. 이를 위해 const를 사용할 수 있지만 누군가(저를 포함하여!)가 잘못된 코드를 보내는 것을 막는 것은 없습니다.

열거형으로 해결하는 것은 끔찍한 생각입니다. 즉, 갑자기 RPC가 실패하거나 롤백 시 데이터를 읽을 수 없게 되기 때문에 이제 새 열거형 값을 추가할 수 없습니다. proto3 에서 생성된 열거형 코드가 "알 수 없는 코드" 값을 지원해야 하는 이유는 이것이 고통을 통해 배운 교훈이기 때문입니다( proto2 가 이것을 해결한 방법과 비교하면 더 좋지만 여전히 매우 나쁨). 애플리케이션이 이 경우를 정상적으로 처리할 수 있기를 원합니다.

@Merovius 귀하의 의견을 존중하지만 정중하게 동의하지 않습니다. 유효한 값만 사용되었는지 확인하는 것은 열거형의 주요 용도 중 하나입니다.

열거형은 모든 상황에 적합하지 않지만 일부 상황에는 적합합니다! 적절한 버전 관리 및 오류 처리는 대부분의 상황에서 새 값을 처리할 수 있어야 합니다.

uh-oh 상태의 외부 프로세스를 처리하려면 당연히 필수입니다.

열거형(또는 보다 일반적이고 유용한 합계 유형)을 사용하면 컴파일러에서 강제로 처리해야 하는 합계/열거형에 명시적 "알 수 없는" 코드를 추가할 수 있습니다. 기록하고 다음 요청으로 이동).

처리해야 하는 X 케이스가 있다는 것을 알고 있을 때 합계 유형이 프로세스 내부에 더 유용하다는 것을 알았습니다. 작은 X의 경우 관리하기 어렵지 않지만 큰 X의 경우 특히 리팩토링할 때 컴파일러가 저에게 소리를 지르는 것에 감사합니다.

API 경계를 넘어 사용 사례는 더 적고 확장성 측면에서 항상 오류가 발생해야 하지만 AST 또는 "day of 이 시점에서 범위가 거의 확정되는 주" 값입니다(캘린더 시스템 선택까지).

@jimmyfrasche 요일을 알려드릴 수는 있지만 AST는 제공하지 않습니다. 문법은 진화합니다. 오늘은 유효하지 않은 것이 내일은 완전히 유효할 수 있으며 여기에는 AST에 새로운 노드 유형을 추가하는 것이 포함될 수 있습니다. 컴파일러 검사 합계 유형을 사용하면 파손 없이는 불가능합니다.

그리고 왜 이것이 수의사 검진으로 해결할 수 없는지 모르겠습니다. 철저한 경우에 대해 완벽하게 적합한 정적 검사를 제공하고 점진적인 수리 가능성을 제공합니다.

서버 API용 클라이언트를 구현하는 작업을 하고 있습니다. 일부 인수 및 반환 값은 API의 열거형입니다. 총 45개의 열거형이 있습니다.

Go에서 열거형 상수를 사용하는 것은 다른 열거형 유형에 대한 일부 값이 동일한 이름을 공유하기 때문에 제 경우에는 실현 가능하지 않습니다. 아래 예에서 Destroy 가 두 번 나타나므로 컴파일러에서 Destroy redeclared in this block 오류가 발생합니다.

type TaskAllowedOperations int
const (
    _ TaskAllowedOperations = iota
    Cancel
    Destroy
)

type OnNormalExit int
const (
    _ OnNormalExit = iota
    Destroy
    Restart
)

따라서 나는 다른 표현을 생각해 내야 할 것입니다. 이상적으로는 IDE가 주어진 유형에 대해 가능한 값을 표시하여 클라이언트 사용자가 더 쉽게 사용할 수 있도록 하는 것입니다. Go에서 일급 시민으로 enum을 갖는 것은 그것을 만족시킬 것입니다.

@kongslund 완벽한 구현이 아니라는 것을 알고 있지만 귀하가 관심을 가질 만한 코드 생성기를 만들었습니다. 유형 선언 위의 주석에서 열거형을 선언하기만 하면 나머지는 자동으로 생성됩니다.

// ENUM(_, Cancel, Destroy)
type TaskAllowedOperations int

// ENUM(_, Destroy, Restart)
type OnNormalExit int

생성할 것이다

const(
  _ TaskAllowedOperations = iota
  TaskAllowedOperationsCancel
  TaskAllowedOperationsDestroy
)

const(
  _ OnNormalExit = iota
  OnNormalExitDestroy
  OnNormalExitRestart
)

더 나은 부분은 접두사를 제외하는 String() 메서드를 생성하여 "Destroy" 를 TaskAllowedOperations 또는 OnNormalExit 로 구문 분석할 수 있다는 것입니다.

https://github.com/abice/go-enum

이제 플러그가 빠져서...

나는 개인적으로 enum이 go 언어의 일부로 포함되지 않은 것에 대해 신경 쓰지 않습니다. 이는 문제에 대한 나의 원래 느낌이 아닙니다. 처음 갔을 때 왜 그렇게 많은 선택을 했는지에 대해 종종 혼란스러운 반응을 보였습니다. 그러나 언어를 사용한 후에는 그 언어가 고수하는 단순함을 갖는 것이 좋으며, 추가로 필요한 것이 있으면 다른 누군가도 이를 필요로 하고 특정 문제를 돕기 위해 멋진 패키지를 만들 가능성이 있습니다. 내 재량에 따라 크러프트의 양을 유지합니다.

이 토론에서 많은 유효한 요점이 제기되었습니다. 일부는 열거형 지원에 찬성하고 많은 사람은 반대합니다(최소한 제안이 처음에 "열거형"이 무엇인지에 대해 말한 한). 나를 위해 튀어나온 몇 가지:

• 소개 예제(오늘날 Go의 열거형)는 오해의 소지가 있습니다. 해당 코드가 생성되고 거의 아무도 손으로 그런 Go 코드를 작성하지 않을 것입니다. 사실, 제안(언어 지원으로 어떻게 생겼는지)은 실제로 Go에서 이미 수행한 작업에 훨씬 더 가깝습니다.

• @jediorange 는 Swift가 "정말로 (열거형) 옳았다"고 언급했습니다. 그럴 수도 있지만 Swift 열거형은 모든 종류의 개념을 함께 혼합하는 놀라울 정도로 복잡한 짐승입니다. Go에서 우리는 의도적으로 다른 언어 기능과 겹치는 메커니즘을 피하고 그 대가로 더 많은 직교성을 얻었습니다. 프로그래머의 결과는 열거형이나 클래스, 합계 유형(있는 경우) 또는 인터페이스 중에서 어떤 기능을 사용할지 결정할 필요가 없다는 것입니다.

• @ianlancetaylor 의 언어 기능의 유용성에 대한 요점을 가볍게 여겨서는 안 됩니다. 수많은 유용한 기능이 있습니다. 문제는 어떤 것이 진정으로 설득력 있고 비용을 들일 만한 가치가 있는가(언어의 복잡성, 따라서 가독성, 구현의 추가 복잡성)입니다.

• 사소한 점으로, Go의 iota 정의 상수는 물론 int로 제한되지 않습니다. 상수인 한 (이름 지정 가능) 기본 유형(float, 부울, 문자열 포함: https://play.golang.org/p/lhd3jqqg5z)으로 제한됩니다.

• @merovius 는 (정적!) 컴파일 시간 검사의 한계에 대해 좋은 지적을 합니다. 확장할 수 없는 열거형이 확장이 바람직하거나 예상되는(장수명 API 표면이 시간이 지남에 따라 진화하는) 연결에 적합한지 매우 의심스럽습니다.

의미 있는 진전이 있기 전에 답변이 필요하다고 생각하는 이 제안에 대한 몇 가지 질문이 있습니다.

1) 제안된 열거형에 대한 실제 기대치는 무엇입니까? @bep 은 열거 가능성, 반복 가능성, 문자열 표현, 정체성을 언급합니다. 더 있나요? 덜 있습니까?

2) 1)의 목록을 가정하면 열거형을 확장할 수 있습니까? 그렇다면 어떻게? (같은 패키지에? 다른 패키지에?) 확장할 수 없다면 그 이유는 무엇입니까? 실무에서 문제가 되지 않는 이유는 무엇입니까?

3) 네임스페이스: Swift에서 enum 유형은 새로운 네임스페이스를 도입합니다. 네임스페이스 이름이 모든 곳에서 반복될 필요가 없도록 하는 중요한 기계(구문 설탕, 유형 추론)가 있습니다. 예를 들어, Month 열거형 값의 경우 올바른 컨텍스트에서 Month.January(또는 더 나쁜 경우 MyPackage.Month.January) 대신 .January를 쓸 수 있습니다. 열거형 네임스페이스가 필요합니까? 그렇다면 열거형 네임스페이스는 어떻게 확장됩니까? 실제로 이 작업을 수행하려면 어떤 종류의 구문 설탕이 필요합니까?

4) 열거형 값이 상수입니까? 불변의 가치?

5) 열거형 값에 대해 어떤 종류의 연산이 가능합니까(예: 반복 외에): 하나는 앞으로, 하나는 뒤로 이동할 수 있습니까? 추가 내장 함수 또는 연산자가 필요합니까? (모든 반복이 순서대로 되는 것은 아닙니다.) 마지막 열거형 값을 지나 앞으로 이동하면 어떻게 됩니까? 런타임 오류인가요?

(https://github.com/golang/go/issues/19814#issuecomment-322771922에서 다음 단락의 표현을 수정했습니다. 아래에서 부주의한 단어 선택에 대해 사과드립니다.)

이러한 질문에 실제로 답하려고 하지 않으면 이 제안은 의미가 없습니다("나는 내가 원하는 것을 하는 열거형을 원합니다"는 제안이 아닙니다).

이러한 질문에 실제로 답하려고 하지 않으면 이 제안은 의미가 없습니다.

@griesemer 당신은 많은 요점/질문을 가지고 있습니다 -- 하지만 이 질문에 답하지 않는다는 의미로 이 제안에 라벨을 붙이는 것은 거의 의미가 없습니다. 기여에 대한 기준은 이 프로젝트에서 높게 설정되어 있지만 컴파일러에서 박사 학위 없이도 _무언가를 제안_할 수 있어야 하며 제안이 _구현할 준비가 된_ 디자인일 필요는 없습니다.

• Go는 매우 필요한 토론을 시작했기 때문에 이 제안이 필요했습니다 => 가치와 의미
• 제안 #21473 => 가치와 의미로도 이어진다면

소개 예제(오늘날 Go의 열거형)는 오해의 소지가 있습니다. 해당 코드가 생성되고 거의 아무도 손으로 그런 Go 코드를 작성하지 않을 것입니다. 사실, 제안(언어 지원으로 어떻게 생겼는지)은 실제로 Go에서 이미 수행한 작업에 훨씬 더 가깝습니다.

@griesemer 동의하지 않습니다. Go 변수 이름에 전체 대문자를 그대로 두지 말았어야 했는데, Go 커뮤니티에서 존경하는 Google 직원이 작성한 손글씨 코드가 제 제안과 거의 같아 보이는 곳이 많이 있습니다. 우리는 코드베이스에서 동일한 패턴을 매우 자주 따릅니다. 다음은 Google Cloud Go 라이브러리에서 가져온 예시입니다.

// ACLRole is the level of access to grant.
type ACLRole string

const (
    RoleOwner  ACLRole = "OWNER"
    RoleReader ACLRole = "READER"
    RoleWriter ACLRole = "WRITER"
)

그들은 여러 장소에서 동일한 구성을 사용합니다.
https://github.com/GoogleCloudPlatform/google-cloud-go/blob/master/bigquery/table.go#L78 -L116
https://github.com/GoogleCloudPlatform/google-cloud-go/blob/master/storage/acl.go#L27 -L49

나중에 iota 를 사용하는 것이 괜찮다면 상황을 더 간결하게 만들 수 있는 방법에 대한 토론이 있었습니다. 이는 그 자체로 유용할 수 있지만 제한된 사용 사례에 해당합니다. 자세한 내용은 이전 댓글을 참조하세요. https://github.com/golang/go/issues/19814#issuecomment -290948187

@bep 공정한 포인트; 부주의한 단어 선택에 대해 사과드립니다. 이번에는 위의 마지막 단락을 더 정중하고 명확하게 표현하여 다시 시도하겠습니다.

의미 있는 진전을 이루기 위해서는 이 제안을 지지하는 사람들이 열거형의 중요한 기능이라고 생각하는 것에 대해 좀 더 정확해야 한다고 생각합니다(예를 들어 https://github.xml에서 몇 가지 질문에 답함으로써). com/golang/go/issues/19814#issuecomment-322752526). 지금까지의 논의에서 원하는 기능이 상당히 모호하게 설명되어 있습니다.

아마도 첫 번째 단계로 기존 Go가 어떻게 (상당히) 부족하고 열거형이 문제를 더 나은/빠른/명확하게 해결할 수 있는지 등을 보여주는 사례 연구를 갖는 것이 매우 유용할 것입니다. Gophercon에서 @rsc 의 훌륭한 강연 을 참조하십시오. Go2 언어 변경에 대해.

@derekperkins 나는 열거형이 아닌 (유형이 지정된) 상수 정의를 호출합니다. 나는 우리의 불일치가 "열거형"이 무엇인지에 대한 다른 이해로 인한 것이라고 생각합니다. 따라서 위의 질문입니다.

(내 이전 https://github.com/golang/go/issues/19814#issuecomment-322774830은 @derekparker 가 아니라 @derekperkins로 갔어야 했습니다. 자동 완성은 저를 이겼습니다.)

@derekperkins 코멘트에서 판단하고 내 자신의 질문에 부분적으로 답하면 Go "enum"이 최소한 다음과 같은 특성을 가져야 한다고 생각합니다.

• (새) 유형에서 값 집합을 그룹화하는 기능
• 최소한의 구문 오버헤드 또는 상용구로 해당 유형으로 이름(및 해당 값이 있는 경우 해당 값)을 쉽게 선언할 수 있습니다.
• 오름차순 선언 순서로 이러한 값을 반복하는 기능

그 소리가 맞습니까? 그렇다면 이 목록에 무엇을 더 추가해야 합니까?

귀하의 질문은 모두 좋은 질문입니다.

제안된 열거형에 대한 실제 기대치는 무엇입니까? @bep 은 열거 가능성, 반복 가능성, 문자열 표현, 정체성을 언급합니다. 더 있나요? 덜 있습니까?

1)의 목록을 가정하면 열거형을 확장할 수 있습니까? 그렇다면 어떻게? (같은 패키지에? 다른 패키지에?) 확장할 수 없다면 그 이유는 무엇입니까? 실무에서 문제가 되지 않는 이유는 무엇입니까?

열거형이 두 가지 이유로 확장될 수 있다고 생각하지 않습니다.

1. 열거형은 허용되는 값의 전체 범위를 나타내야 하므로 확장하는 것은 의미가 없습니다.
2. 일반 Go 유형이 외부 패키지에서 확장될 수 없는 것처럼 이는 동일한 메커니즘 및 개발자 기대치를 유지합니다.

네임스페이스: Swift에서 enum 유형은 새로운 네임스페이스를 도입합니다. 네임스페이스 이름이 모든 곳에서 반복될 필요가 없도록 하는 중요한 기계(구문 설탕, 유형 추론)가 있습니다. 예를 들어, Month 열거형 값의 경우 올바른 컨텍스트에서 Month.January(또는 더 나쁜 경우 MyPackage.Month.January) 대신 .January를 쓸 수 있습니다. 열거형 네임스페이스가 필요합니까? 그렇다면 열거형 네임스페이스는 어떻게 확장됩니까? 실제로 이 작업을 수행하려면 어떤 종류의 구문 설탕이 필요합니까?

내가 언급한 모든 예에서 유형 이름을 접두사로 사용하기 때문에 네임스페이스가 어떻게 생겨났는지 이해합니다. 누군가가 네임스페이스를 추가하는 것에 대해 강하게 느낀다면 반대하지는 않겠지만, 이는 이 제안의 범위를 벗어납니다. 접두사는 현재 시스템에 잘 맞습니다.

열거형 값은 상수입니까? 불변의 가치?

나는 상수를 생각할 것입니다.

열거형 값에 대해 어떤 종류의 작업이 가능합니까(예: 반복 외에): 하나는 앞으로, 하나는 뒤로 이동할 수 있습니까? 추가 내장 함수 또는 연산자가 필요합니까? (모든 반복이 순서대로 되는 것은 아닙니다.) 마지막 열거형 값을 지나 앞으로 이동하면 어떻게 됩니까? 런타임 오류인가요?

나는 기본적으로 슬라이스/배열(맵이 아님)에 대한 표준 Go 방식을 사용합니다. 열거형 값은 선언 순서에 따라 반복 가능합니다. 최소한 범위 지원이 있을 것입니다. 나는 인덱스를 통해 열거형에 액세스하는 것을 피하지만 그것에 대해 강하게 느끼지는 않습니다. 이를 지원하지 않으면 잠재적인 런타임 오류가 제거됩니다.

직접 할당이든 유형 캐스팅이든 상관없이 열거형에 잘못된 값을 할당하면 새로운 런타임 오류(패닉?)가 발생합니다.

이것을 올바르게 요약하면 제안한 열거형 값은 유형이 지정된 상수와 비슷하지만(상수와 마찬가지로 사용자 정의 상수 값이 있을 수 있음) 다음과 같습니다.

• 또한 동일한 선언에서 열거형 값과 연결된 열거형 유형을 정의합니다(그렇지 않으면 상수일 뿐입니다).
• 선언 외부에서 기존 열거형 유형의 열거형 값을 캐스팅/생성하는 것은 불가능합니다.
• 그것들을 반복하는 것이 가능합니다

그 말이 맞는 것 같습니까? (이것은 Pascal이 약 45년 전에 개척한 열거형에 대해 언어가 취한 고전적인 접근 방식과 일치합니다).

예, 그것이 바로 제가 제안하는 것입니다.

switch 문은 어떻습니까? 제안의 주요 동인 중 하나인 AIUI.

열거형을 켤 수 있다는 것은 기본적으로 무엇이든 켤 수 있기 때문에 암시되어 있다고 생각합니다. 스위치의 열거 형을 완전히 만족하지 못한 경우 swift에 오류가 있지만 수의사가 처리 할 수 ​​있습니다.

@jediorange 나는 특히 마지막 부분에 대한 질문, 즉 제안을 완전하게 유지하기 위해 철저한 검사가 있어야 하는지 여부에 대해 언급했습니다. "아니오"는 물론 완벽하게 좋은 대답입니다.

이 문제의 원래 메시지 는 protobuf를 동기로 언급합니다. 나는 지금 주어진 의미론을 사용하여 protobuf-compiler가 모든 열거형에 대해 추가 "인식할 수 없는" 경우를 생성해야 한다는 점을 명시적으로 말하고 싶습니다(충돌을 방지하기 위한 일부 이름 맹글링 체계를 의미함). 또한 디코딩된 열거형 값이 컴파일된 범위에 없는 경우 열거형을 사용하여 생성된 구조체에 추가 필드를 추가해야 합니다. 현재 자바 에 대해 수행되는 것과 같습니다. 또는 int 를 계속 사용할 가능성이 더 높습니다.

@Merovius 내 원래 제안은 제안의 주요 동기가 아닌 예로 protobufs를 언급했습니다. 당신은 그 통합에 대해 좋은 지적을 했습니다. 아마도 직교 문제로 취급되어야 한다고 생각합니다. 내가 본 대부분의 코드는 생성된 protobuf 유형을 내부적으로 사용하는 것을 선호하는 앱 수준 구조체로 변환합니다. protobuf가 변경되지 않고 계속될 수 있고 앱 제작자가 이를 Go 열거형으로 변환하려는 경우 변환 프로세스에서 발생하는 극단적인 경우를 처리할 수 있다는 것이 제 생각에 이해가 됩니다.

@derekperkins 추가 질문:

• 명시적으로 초기화되지 않은 열거형 변수의 0 값은 무엇입니까? 일반적으로 0이 될 수 없다고 가정합니다(메모리 할당/초기화를 복잡하게 함).

• 열거형 값으로 제한된 산술을 수행할 수 있습니까? 예를 들어, Pascal에서(내가 한 번 프로그래밍한 것을 옛날로 거슬러 올라가면) 놀랍게도 1단계 이상으로 반복해야 하는 경우가 많았습니다. 때로는 열거형 값을 계산하고 싶을 때도 있었습니다.

• 반복과 관련하여 go 생성 생성 반복(및 stringify) 지원이 충분하지 않은 이유는 무엇입니까?

명시적으로 초기화되지 않은 열거형 변수의 0 값은 무엇입니까? 일반적으로 0이 될 수 없다고 가정합니다(메모리 할당/초기화를 복잡하게 함).

초기 제안서에서 언급했듯이 이것은 더 엄격한 결정 중 하나입니다. 정의 순서가 반복에 중요하다면 첫 번째 정의된 값을 기본값으로 하는 것도 마찬가지로 의미가 있다고 생각합니다.

열거형 값으로 제한된 산술을 수행할 수 있습니까? 예를 들어, Pascal에서(내가 한 번 프로그래밍한 것을 옛날로 거슬러 올라가면) 놀랍게도 1단계 이상으로 반복해야 하는 경우가 많았습니다. 때로는 열거형 값을 계산하고 싶을 때도 있었습니다.

숫자 기반 열거형을 사용하든 문자열 기반 열거형을 사용하든 모든 열거형에 암시적 0 기반 인덱스가 있음을 의미합니까? 인덱스 기반이 아닌 지원되는 range 반복에만 의존한다고 앞서 언급한 이유는 배열이나 맵 또는 그 아래에 있는 무엇이든 사용할 수 있는 기본 구현을 노출하지 않기 때문입니다. 인덱스를 통해 열거형에 액세스해야 할 필요는 없지만 그것이 유익한 이유가 있다면 허용하지 않을 이유가 없다고 생각합니다.

반복과 관련하여 go 생성 생성 반복(및 stringify) 지원이 충분하지 않은 이유는 무엇입니까?

반복은 개인적으로 주요 사용 사례는 아니지만 제안에 가치를 추가한다고 생각합니다. 그것이 원동력이라면 go generate 이면 충분할 것입니다. 그것은 가치 안전을 보장하는 데 도움이 되지 않습니다. Stringer() 인수는 원시 값이 iota 또는 int 또는 "실제" 값을 나타내는 다른 유형이 될 것이라고 가정합니다. 또한 (Un)MarshalJSON , (Un)MarshalBinary , Scanner/Valuer 및 Stringer 값이 통신에 사용되었는지 확인하는 데 사용할 수 있는 기타 직렬화 방법을 생성해야 합니다. Go가 내부적으로 사용하는 모든 것.

@griesemer 적어도 값 추가/제거와 관련하여 열거형의 확장성에 대한 귀하의 질문에 완전히 대답하지 못했을 수도 있습니다. 그것들을 편집할 수 있는 능력은 이 제안의 필수적인 부분입니다.

@Merovius 에서 https://github.com/golang/go/issues/19814#issuecomment -290969864

열거형 집합을 변경하려는 모든 패키지는 자동으로 모든 가져오기 도구를 강제로 중단합니다.

이것이 다른 주요 API 변경 사항과 어떻게 다른지 모르겠습니다. 유형, 기능 또는 기능 서명이 변경되는 경우와 마찬가지로 BC를 정중하게 처리하는 것은 패키지 작성자에게 달려 있습니다.

구현의 관점에서 기본값이 모두 0이 아닌 유형을 지원하는 것은 매우 복잡합니다. 오늘날에는 그러한 유형이 없습니다. 그러한 기능을 요구하는 것은 이 아이디어에 반대되는 표시로 간주되어야 합니다.

언어에서 채널을 만드는 데 make 가 필요한 유일한 이유는 채널 유형에 대해 이 기능을 유지하기 위해서입니다. 그렇지 않으면 make 는 선택 사항일 수 있으며 채널 버퍼 크기를 설정하거나 기존 변수에 새 채널을 할당하는 데만 사용됩니다.

@derekperkins 대부분의 다른 API 변경 사항은 점진적인 복구를 위해 조정될 수 있습니다. Russ Cox 설명 을 읽는 것이 좋습니다. 많은 내용이 매우 명확해집니다.

(현재 const+iota 구조와 같은) 개방형 열거형은 (예를 들어) a) 새 값을 사용하지 않고 정의하고, b) 새 값을 처리하기 위해 역 종속성을 업데이트하고, c) 값을 사용하기 시작함으로써 점진적인 복구를 허용합니다. 또는 값을 제거하려면 a) 값 사용을 중지하고 b) 제거할 값을 언급하지 않도록 역 종속성을 업데이트하고 c) 값을 제거합니다.

닫힌(컴파일러에서 철저한 검사) 열거형을 사용하면 이것이 불가능합니다. 값 처리를 제거하거나 새 값을 정의하면 컴파일러는 누락된 스위치 케이스에 대해 즉시 불평합니다. 그리고 값을 정의하기 전에 값 처리를 추가할 수 없습니다.

문제는 개별 변경 사항이 중단되는 것으로 간주될 수 있는지 여부에 관한 것이 아니라(분리될 수 있음) 중단되지 않는 분산 코드 기반에 대해 중단되지 않는 커밋 시퀀스가 ​​있는지 여부에 관한 것입니다.

구현의 관점에서 기본값이 모두 0이 아닌 유형을 지원하는 것은 매우 복잡합니다. 오늘날에는 그러한 유형이 없습니다. 그러한 기능을 요구하는 것은 이 아이디어에 반대되는 표시로 간주되어야 합니다.

@ianlancetaylor 확실히 전체 구현에 대해 말할 수는 없지만 열거형이 0 기반 배열로 구현된 경우( @griesemer 가 찬성하는 것처럼 들림) 인덱스가 0인 것처럼 보입니다. "all-bits-zero"로 두 배가 될 수 있습니다.

닫힌(컴파일러에서 철저한 검사) 열거형을 사용하면 이것이 불가능합니다.

@Merovius go vet 또는 @jediorange 가 제안한 것과 컴파일러가 시행한 유사한 도구로 완전성을 확인했다면 걱정을 덜 수 있습니까?

@derekperkins 그들의 유해성에 대해 그렇습니다. 유용성이 부족해서가 아닙니다. 버전 왜곡의 동일한 문제는 일반적으로 고려되는 대부분의 사용 사례(시스템 호출, 네트워크 프로토콜, 파일 형식, 공유 개체 등)에서도 발생합니다. proto3에는 개방형 열거형이 필요하고 proto2에는 그렇지 않은 이유가 있습니다. 이는 많은 중단과 데이터 손상 사건에서 배운 교훈입니다. Google은 이미 버전 왜곡을 방지하기 위해 꽤 주의를 기울이고 있습니다. 내 관점에서는 기본 케이스가 있는 개방형 열거형이 올바른 솔루션일 뿐입니다. 그리고 잘못된 값에 대한 안전성 주장과는 별개로, 내가 말할 수 있는 바에 따르면 그것들은 실제로 테이블에 많은 것을 가져오지 않습니다.

이 모든 것을 말하지만, 나는 결정자가 아닙니다.

@derekperkins https://github.com/golang/go/issues/19814#issuecomment -322818206에서 (귀하의 관점에서) 다음을 확인하고 있습니다.

• 열거형 선언은 명명된 열거형 값(상수)과 함께 열거형 유형을 선언합니다.
• 그것들을 반복하는 것이 가능합니다
• 선언 외부의 열거형에 값을 추가할 수 없습니다.
  그리고 나중에: 열거형에 대한 전환은 철저해야 합니다(또는 아닐 수도 있음)(덜 중요해 보임)

https://github.com/golang/go/issues/19814#issuecomment -322895247에서 다음과 같이 말하고 있습니다.

• 첫 번째 정의된 값은 아마도 기본(영) 값이어야 합니다(이것은 반복에 중요하지 않으며 열거형 변수 초기화에 중요합니다)
• 반복은 주요 동기가 아닙니다.

그리고 https://github.com/golang/go/issues/19814#issuecomment -322903714에서 "편집 기능이 이 제안의 중요한 부분"이라고 말하고 있습니다.

혼란스럽습니다. 따라서 반복은 주요 동기가 아닙니다. 좋습니다. 이는 상수인 열거형 값의 열거형 선언을 최소한 남겨두고 선언 외부로 확장할 수 없습니다. 하지만 지금 당신은 그것들을 편집하는 능력이 중요하다고 말하고 있습니다. 그게 무슨 뜻이야? 확실히 그것들이 확장될 수 있다는 것은 아닙니다(모순이 될 것입니다). 그들은 변수입니까? (그러나 그들은 상수가 아닙니다).

https://github.com/golang/go/issues/19814#issuecomment -322903714에서 열거형을 0 기반 배열로 구현할 수 있다고 말하고 있습니다. 이것은 열거형 선언이 0부터 시작하는 상수 인덱스인 열거형 이름의 정렬된 목록과 함께 열거형 값의 배열(공간이 자동으로 예약됨)에 새로운 유형을 도입한다는 것을 의미합니다. 이게 네가 말하는거야? 그렇다면 고정 크기 배열과 함께 사용할 상수 인덱스 목록을 선언하는 것으로 충분하지 않은 이유는 무엇입니까? 배열 경계 검사는 열거형 범위를 "확장"할 수 없으며 반복이 이미 가능하다는 것을 자동으로 확인합니다.

내가 무엇을 놓치고 있습니까?

혼란스럽습니다. 따라서 반복은 주요 동기가 아닙니다. 좋습니다.

나는 열거형을 원하는 내 나름의 이유가 있으며 @bep 와 다른 사람들을 포함하여 이 스레드의 다른 사람들이 제안의 필요한 부분으로 표현한 것을 고려하려고 합니다.

이는 상수인 열거형 값의 열거형 선언을 최소한 남겨두고 선언 외부로 확장할 수 없습니다. 하지만 지금 당신은 그것들을 편집하는 능력이 중요하다고 말하고 있습니다. 그게 무슨 뜻이야? 확실히 그것들이 확장될 수 있다는 것은 아닙니다(모순이 될 것입니다). 그들은 변수입니까? (그러나 그들은 상수가 아닙니다).

내가 편집하라고 말할 때 @Merovius 의 요점은 그것들이 열린 열거형이라는 것입니다. 빌드 시 상수이지만 영원히 잠겨 있지는 않습니다.

#19814(주석)에서 열거형을 0부터 시작하는 배열로 구현할 수 있다고 말합니다.

이것은 https://github.com/golang/go/issues/19814#issuecomment -322884746 및 @ianlancetaylor 의 https를 기반으로 하여 배후에서 구현될 수 있다고 상상하는 방법에 대해 내 급여 수준을 넘어 추측한 것일 뿐입니다. //github.com/golang/go/issues/19814#issuecomment -322899668

"열거형 값으로 제한된 산술을 수행할 수 있습니까? 예를 들어, Pascal에서(내가 한 번 프로그래밍한 것을 옛날로 거슬러 올라가면) 놀랍게도 종종 > 1단계에서 반복해야 했습니다. 때로는 열거형 값을 계산하고 싶었습니다."

정수가 아닌 열거형에 대해 어떻게 할 계획인지 모르겠습니다. 따라서 해당 산술이 열거형의 각 멤버에 선언 순서에 따라 암시적으로 인덱스를 할당해야 하는지 여부에 대한 제 질문입니다.

구현의 관점에서 기본값이 모두 0이 아닌 유형을 지원하는 것은 매우 복잡합니다. 오늘날에는 그러한 유형이 없습니다. 그러한 기능을 요구하는 것은 이 아이디어에 반대되는 표시로 간주되어야 합니다.

다시 말하지만 컴파일러가 어떻게 작동하는지 몰라서 대화를 계속하려고 했습니다. 결국 저는 급진적인 것을 제안하려고 하지 않습니다. 이전에 언급했듯이 "이것은 Pascal이 약 45년 전에 개척한 열거형에 대해 언어가 취한 고전적인 접근 방식과 일치할 것입니다", 그리고 그것은 청구서에 맞습니다.

관심을 표명하신 다른 분들은 부담 없이 참여해 주십시오.

또 다른 질문은 이러한 열거형을 사용하여 배열이나 슬라이스로 색인을 생성할 수 있는지 여부입니다. 슬라이스는 종종 enum->value 매핑을 나타내는 매우 효율적이고 간결한 방법이며 맵을 요구하는 것은 불행한 일이라고 생각합니다.

@derekperkins 그래, 우리(또는 적어도 나)가 다시 원점으로 돌아가게 하는 것이 걱정된다. 해결하려는 문제는 무엇입니까? 우리가 현재 상수와 아마도 iota로 하는 일을 작성하는 더 좋은 방법을 원하십니까? 즉, (아마도) 지나치게 부담스러운 표기법에 대한 일부 구문 설탕? (그냥 이해하려고 노력하는 좋은 대답입니다.)

당신은 그것들을 원하는 자신만의 이유가 있다고 언급했습니다. 아마도 그 이유가 무엇인지 조금 더 설명할 수 있을 것입니다. 당신이 맨 처음에 준 예는 나에게별로 의미가 없지만 아마도 나는 뭔가를 놓치고있을 것입니다.

있는 그대로 모든 사람은 이 제안("열거형")이 수반하는 내용에 대해 약간씩 다른 이해를 가지고 있습니다. 다양한 응답에서 분명해졌습니다. Pascal 열거형과 Swift 열거형 사이에는 엄청난 범위의 가능성이 있습니다. 당신(또는 다른 누군가)이 제안된 내용을 매우 명확하게 설명하지 않는 한(나는 구현을 요구하지 않습니다. 명심하십시오), 의미 있는 진전을 이루거나 이 제안의 장점에 대해 토론하는 것조차 어려울 것입니다.

말이 돼?

@griesemer 그것은 완전히 말이 되며 @rsc가 Gophercon 에서 이야기한 통과 기준을 이해합니다. 당신은 분명히 나보다 훨씬 더 깊은 이해를 가지고 있습니다. #21473에서 vars에 대한 iota는 당시에 매력적인 사용 사례가 없었기 때문에 구현되지 않았다고 언급했습니다. enum 가 처음부터 포함되지 않은 것과 같은 이유인가요? 그것이 Go에 가치를 더할 것인지 여부에 대한 귀하의 의견을 알고 싶습니다. 만약 그렇다면, 어디에서 프로세스를 시작하시겠습니까?

@derekperkins https://github.com/golang/go/issues/19814#issuecomment -323144075의 질문과 관련하여: 당시 (Go의 디자인에서) 우리는 비교적 단순한(Pascal 또는 C 스타일) 열거형만 고려하고 있었습니다. 모든 세부 사항을 기억하지 못하지만 열거형에 필요한 추가 기계에 대한 이점이 충분하지 않다는 느낌은 확실히 있었습니다. 우리는 그것들이 본질적으로 미화되는 지속적인 선언이라고 느꼈습니다.

이러한 전통적인 열거형에도 문제가 있습니다. 산술 연산을 수행할 수 있지만(그냥 정수임) "(열거형) 범위를 벗어남"은 무엇을 의미합니까? Go에서는 상수일 뿐이며 "범위를 벗어남"은 존재하지 않습니다. 또 다른 하나는 반복입니다. Pascal에는 enum 유형의 변수 값을 앞뒤로 전진시키는 특별한 내장 함수(SUCC 및 PRED로 생각합니다)가 있습니다(C에서는 ++ 또는 --만 수행). 그러나 동일한 문제가 여기에도 나타납니다. 끝을 넘으면 어떻게 됩니까(++ 또는 Pascal에 해당하는 SUCC를 사용하여 열거형 값에 걸쳐 범위를 지정하는 for 루프의 매우 일반적인 문제). 마지막으로 열거형 선언은 요소가 열거형 값인 새 유형을 도입합니다. 이러한 값에는 이름(열거형 선언에 정의된 값)이 있지만 해당 이름은 유형과 동일한 범위에 있습니다(Pascal, C의 경우). 이것은 약간 불만족스럽습니다. 두 개의 서로 다른 열거형을 선언할 때 각 열거형 유형에 대해 충돌 없이 동일한 열거형 값 이름을 사용할 수 있기를 희망하지만 이는 불가능합니다. 물론 Go는 그것을 해결하지도 못하지만 상수 선언 역시 새로운 이름 공간을 도입하는 것처럼 보이지 않습니다. 더 좋은 솔루션은 각 열거형에 이름 공간을 도입하는 것이지만 열거형 값이 사용될 때마다 열거형 유형 이름으로 한정해야 하므로 성가신 일입니다. Swift는 가능한 경우 열거형 유형을 추론하여 이 문제를 해결한 다음 점이 접두사로 붙은 열거형 값 이름을 사용할 수 있습니다. 그러나 그것은 꽤 많은 기계입니다. 그리고 마지막으로 때때로(종종 공개 API에서) 열거형 선언을 확장해야 합니다. 그것이 가능하지 않다면(귀하가 코드를 소유하지 않은 경우) 문제가 있는 것입니다. 상수를 사용하면 이러한 문제가 존재하지 않습니다.

아마도 더 많은 것이 있을 것입니다. 이것이 바로 생각나는 것입니다. 결국 우리는 이미 가지고 있는 직교 도구를 사용하여 Go에서 열거형을 에뮬레이트하는 것이 더 낫다고 결정했습니다. 잘못된 할당을 덜 발생시키는 사용자 정의 정수 유형과 구문 설탕에 대한 iota 메커니즘(및 능력은 반복되는 초기화 표현식을 생략함)입니다.

따라서 내 질문은 다음과 같습니다. 약간의 구문 오버헤드로 Go에서 적절하게 에뮬레이트할 수 없는 특수 열거형 선언에서 무엇을 얻고자 합니까? 열거형과 선언 외부로 확장할 수 없는 열거형 유형을 생각할 수 있습니다. 나는 Swift에서처럼 열거형 값에 대해 더 많은 기능을 생각할 수 있습니다.

Go의 go Generator를 사용하면 열거를 쉽게 해결할 수 있습니다. 우리는 이미 스트링거를 가지고 있습니다. 확장을 제한하는 것은 API 경계에서 문제가 됩니다. 열거형 값에 대한 더 많은 기능(예: Swift에서)은 많은 직교 개념을 혼합하기 때문에 Go와 매우 다르게 보입니다. Go에서는 기본 빌딩 블록을 사용하여 이를 달성할 수 있습니다.

@griesemer 사려 깊은 답변에 감사드립니다. 나는 그것들이 기본적으로 영광스러운 상수 선언이라는 데 동의하지 않습니다. Go에서 타입 안전성을 갖는 것은 훌륭하고, enum 가 나에게 개인적으로 제공할 주요 가치는 가치 안전성이다. 오늘날 Go에서 이를 모방하는 방법은 해당 변수의 모든 진입점에서 유효성 검사 기능을 실행하는 것입니다. 장황하고 실수하기 쉽지만 오늘날과 같은 언어로 가능합니다. 나는 이미 열거형 앞에 유형 이름을 접두사로 붙여 네임스페이스를 지정했는데, 장황하지만 큰 문제는 아닙니다.

나는 개인적으로 iota 에 대한 대부분의 사용을 싫어합니다. 멋지긴 하지만 대부분의 경우 enum 같은 값은 db 또는 외부 API와 같은 외부 리소스에 매핑되며, 재정렬하는 경우 값이 변경되지 않아야 한다는 점을 더 명시적으로 표현하는 것이 좋습니다. iota 는 문자열 값 목록을 사용하기 때문에 enum 를 사용하는 대부분의 장소에서 도움이 되지 않습니다.

결국 이 제안을 얼마나 더 명확히 할 수 있을지 모르겠습니다. 바둑에 어떤 방식으로든 지원을 해준다면 정말 좋겠습니다. 정확한 구현에 관계없이 여전히 사용할 수 있으며 코드를 더 안전하게 만들 수 있습니다.

Go가 오늘 열거하는 표준 방식(https://github.com/golang/go/issues/19814#issuecomment-290909885 참조)이 거의 정확하다고 생각합니다.
몇 가지 단점이 있습니다.

1. 그것들은 반복될 수 없다
2. 그들은 문자열 표현이 없습니다
3. 클라이언트는 가짜 열거형 값을 도입할 수 있습니다.

나는 #1 없어도 괜찮아.
go:generate + stringer는 #2에 사용할 수 있습니다. 그것이 사용 사례를 처리하지 못하는 경우 "열거형"의 기본 유형을 int 대신 문자열로 만들고 문자열 상수 값을 사용하십시오.

3은 오늘의 바둑에서 다루기 힘든 것입니다. 나는 이것을 잘 처리할 수 있는 어리석은 제안을 가지고 있습니다.

유형 정의에 explicit 키워드를 추가합니다. 이 키워드는 해당 유형이 정의된 패키지의 const 블록에서 변환을 제외하고 이 유형으로의 변환을 금지합니다. (또는 restricted ? 아니면 enum 가 explicit type ?)

위에서 언급한 예를 다시 사용하여,

//go:generate stringer -type=SearchRequest
explicit type SearchRequest int

const (
    Universal SearchRequest = iota
    Web
    Images
    Local
    News
    Products
    Video
)

const 블록 내에서 int 에서 SearchRequest 로의 변환이 있습니다. 그러나 패키지 작성자만 새 SearchRequest 값을 도입할 수 있으며 실수로 값을 도입할 가능성은 거의 없습니다(예 SearchRequest 를 예상하는 함수에 int 전달).

저는 이 솔루션을 적극적으로 제안하고 있지는 않지만, don't-accidentally-construct-an-invalid-one은 오늘날 Go에서 캡처할 수 없는 열거형의 두드러진 속성이라고 생각합니다. 내보내지 않은 필드 경로).

열거형의 흥미로운 위험은 유형이 지정되지 않은 상수와 관련이 있다고 생각합니다. 명시적 형식 변환을 작성하는 사람들은 자신이 무엇을 하는지 알고 있습니다. 특정 상황에서 Go가 명시적 유형 변환을 금지하는 방법을 기꺼이 고려하겠지만, 이는 열거형 유형의 개념과 완전히 일치한다고 생각합니다. 모든 유형에 적용되는 아이디어입니다.

그러나 형식화되지 않은 상수는 명시적 형식 변환에 해당하지 않는 방식으로 실수로 예기치 않게 형식 값을 생성할 수 있습니다. 그래서 explicit 에 대한 @randall77 의 제안은 단순하게 형식화되지 않은 상수가 암시적으로 형식으로 변환되지 않을 수 있다는 의미로 단순화될 수 있다고 생각합니다. 명시적 형식 변환은 항상 필요합니다.

특정 상황에서 Go가 명시적 유형 변환을 금지하는 방법을 기꺼이 고려할 것입니다.

@ianlancetaylor 명시적이든 암시적이든 선택적으로 유형 변환을 허용하지 않으면 처음에 이 제안을 만들게 된 문제를 해결할 수 있습니다. 그러면 원래 패키지만 생성하여 모든 유형을 충족할 수 있습니다. const 선언뿐만 아니라 모든 유형을 지원하기 때문에 어떤 면에서는 enum 솔루션보다 훨씬 낫습니다.

@randall77 , @ianlancetaylor explicit 제안이 해당 유형의 0 값과 함께 작동하도록 하려면 어떻게 해야 합니까?

@derekperkins 유형 변환을 모두 허용하지 않으면 encoding/* 패키지와 같은 일반 인코더/디코더에서 이러한 유형을 사용할 수 없습니다.

@Merovius 내 생각에 @ianlancetaylor 는 암시적 변환(예: 제한된 유형에 유형이 지정되지 않은 상수 할당)에 대해서만 제한을 제안합니다. 명시적 변환은 여전히 ​​가능합니다.

@griesemer 알아요 :) 하지만 @derekperkins 가 다르게 제안하는 것을 이해했습니다.

명시적 변환을 허용하는 것이 우리가 이 "명시적" 한정자에 대해 생각하는 바로 그 이유를 훼손하지 않습니까? 누군가가 임의의 값을 "명시적" 유형으로 변환하기로 결정할 수 있다면 주어진 값이 지금보다 열거된 상수 중 하나라는 보장이 더 이상 없습니다.

아마도 가장 중요한 유형이 지정되지 않은 상수의 우연하거나 의도하지 않은 사용에 도움이 될 것이라고 생각합니다.

명시적 변환을 허용하지 않는 것이 "바둑의 정신"에 있는지 여부에 대해 질문하는 것 같습니다. 명시적 변환을 허용하지 않는 것은 코드 작성을 기반으로 프로그래밍하는 것보다 유형을 기반으로 프로그래밍하는 방향으로 큰 진전을 이루고 있습니다. 나는 Go가 후자에 대해 분명한 입장을 취하고 있다고 생각한다.

@griesemer @Merovius @ianlancetaylor 의 인용문을 다시 게시하겠습니다. 제 제안이 아니라 그의 제안이었기 때문입니다.

특정 상황에서 Go가 명시적 유형 변환을 금지하는 방법을 기꺼이 고려할 것입니다.

@rogpeppe 와 @Merovius 는 모두 결과에 대해 좋은 점을 지적합니다. 명시적 변환을 허용하지만 암시적 변환은 허용하지 않는 것은 유효한 유형을 보장하는 문제를 해결하지 못하지만 일반 인코딩을 잃는 것은 꽤 큰 단점이 될 것입니다.

여기저기서 우여곡절이 많았지만 좋은 아이디어가 있었던 것 같아요. 여기에 내가 보고 싶은 것(또는 유사한 것)이 요약되어 있으며, 이는 다른 사람들이 말한 것과 일치하는 것 같습니다. 나는 언어 디자이너나 컴파일러 프로그래머가 아니라는 것을 공개적으로 인정합니다. 그래서 그것이 얼마나 잘 작동할지 모르겠습니다.

1. 기본 유형(string, uint, int, rune 등)에만 기반을 둔 열거형. 기본 유형이 필요하지 않으면 기본적으로 uint?
2. 열거형의 모든 유효한 값은 유형 선언 -- 상수로 선언해야 합니다. 형식 선언에 선언되지 않은 잘못된 값은 열거형 형식으로 변환할 수 없습니다.
3. 디버깅을 위한 자동 문자열 표현(있는 것이 좋습니다).
4. 컴파일 타임은 열거형의 switch 문에서 완전성을 검사합니다. 선택적으로 ( go vet ?를 통해) default 케이스를 권장합니다. 이는 향후 변경 사항에 대해 이미 철저한(오류 가능성이 있는) 경우에도 마찬가지입니다.
5. 0 값은 본질적으로 유효하지 않아야 합니다(열거형 선언에 있는 것이 아님). 저는 개인적으로 슬라이스가 하는 것처럼 nil 가 되기를 바랍니다.

마지막 것은 _아마도_ 약간 논란의 여지가 있습니다. 그리고 그것이 효과가 있을지 확신할 수 없지만 의미상으로 적합할 것이라고 생각합니다. nil 슬라이스를 확인하는 것과 마찬가지로 nil 에 대한 수표를 넣을 수 있습니다.

반복에 관해서는 실제로 사용하지 않을 것이라고 생각하지만 그로 인한 피해는 보지 않습니다.

선언할 수 있는 방법의 예:

type MetadataBlockType enum[uint] {
    StreamInfo:    0
    Padding:       1
    Application:   2
    SeekTable:     3
    VorbisComment: 4
    CueSheet:      5
    Picture:       6
}

또한 유형을 유추하고 "점 구문"을 사용하는 Swift 스타일은 _좋은_이지만 반드시 필요한 것은 아닙니다 .

열거형 정수형
상수 (
알 수 없는 EnumA = iota
AAA
)

유형 EnumB int
상수 (
알 수 없는 EnumB = iota
비비비
)

단일 Go 파일이나 동일한 패키지에 두 개의 코드가 존재할 수 없으며 심지어 하나라도 다른 패키지에서 가져올 수 없습니다.

Enum을 구현하는 C# 방식을 구현하십시오.
유형 요일 열거형 {Sat, Sun, Mon, Tue, Wed, Thu, Fri}
type Days enum[int] { Sat:1 , Sun, Tue, Wed, Thu, Fri}
type Days enum[string] { Sat: "Saturay" , Sun:"Sunday" 등}

@KamyarM 그보다 나은 방법은 무엇입니까?

type Days int
const (
  Sat Days = 1+iota
  Sun
  ...
)

그리고

type Days string
const (
  Sat Days = "Saturday"
  Sun      = "Sunday"
  ...
)

새로운 접근 방식/인수에 대한 의견을 제한하도록 친절하게 요청하고 싶습니다. 많은 사람들이 이 스레드를 구독하고 있으며 소음/반복을 추가하는 것은 그들의 시간과 관심을 무시하는 것으로 인식될 수 있습니다. ↑ 이전 댓글에 대한 자세한 답변을 포함하여 많은 토론이 있습니다. 당신은 말한 모든 것에 동의하지 않을 것이고 어느 쪽도 지금까지 그 논의의 결과를 좋아하지 않을 것입니다. 그러나 단순히 그것을 무시해도 생산적인 방향으로 나아가는 데 도움이 되지 않습니다.

명명 충돌 문제가 없기 때문에 더 좋습니다. 또한 컴파일러 유형 검사를 지원합니다. 언급한 접근 방식은 없는 것보다 더 잘 구성했지만 컴파일러는 할당할 수 있는 항목을 제한하지 않습니다. 해당 유형의 객체에 요일이 아닌 정수를 할당할 수 있습니다.
var a 일
a = 10
컴파일러는 실제로 그것에 대해 아무 것도 하지 않습니다. 그래서 이런 종류의 열거형은 별로 의미가 없습니다. 그 외에는 GoLand와 같은 IDE에서 더 잘 구성되어 있습니다.

나는 그런 것을보고 싶다

type WeekDay enum string {
  Monday "mon"
  Tuesday "tue"
  // etc...
}

또는 자동 iota 사용:

// this assumes that iota automatically assigned to the first declared enum key
// and values have unsigned integer type
// value is positional, so if you decide to rename your key 
// you don't have to change everything in db
// also it is easy to grow your lists
type WeekDay enum {
  Monday
  Tuesday
}

이렇게 하면 사용이 간편하고 간편해집니다.

func makeItWorkOn(day WeekDay) {
  // your implementation
}

또한 enum에는 값을 검증하는 내장 메소드가 있어야 사용자 입력에서 무언가를 검증할 수 있습니다.

if day in WeekDay {
  makeItWorkOn(day)
}

그리고 다음과 같은 간단한 것들:

if day == WeekDay.Monday {
 // whatever
}

솔직히 말해서, 내가 가장 좋아하는 구문은 다음과 같습니다(KISS).

// type automatically inferred from values or `iota`
enum WeekDay {
  Monday "mon"
  Tuesday "tue"
}

@zoonman 마지막 예제는 Go의 다음 원칙을 따르지 않습니다. 함수 선언은 func 로 시작하고, 유형 선언은 type 로 시작하고, 변수 선언은 var 로 시작합니다. , ...

@md2perpe 저는 Go "유형" 원칙을 따르려고 하지 않습니다. 매일 코드를 작성하고 있으며 제가 따르는 유일한 원칙은 단순하게 유지하는 것입니다.
_원칙을 따르기 위해_ 작성해야 하는 코드보다 더 많은 시간이 낭비됩니다.
TBH 바둑 초보자지만 비판할 부분이 많다.
예를 들어:

struct User {
  Id uint
  Email string
}

보다 쓰기 쉽고 이해하기 쉽습니다.

type User struct {
  Id uint
  Email string
}

유형을 사용해야 하는 예를 알려드릴 수 있습니다.

// this is terrible because it blows your mind off
// especially if you Go newbie
// this should not be allowed by compiler/linter:
w := map[string]interface{}{"type": 0, "connected": true}

// it has to be splitted into type definition
type WeirdJSON map[string]interface{}

// and used like
w := WeirdJSON{"type": 0, "connected": true}

나는 Asm, C, C++, Pascal, Perl, PHP, Ruby, Python, JavaScript, TypeScript, 지금은 Go로 코드를 작성했습니다. 나는 그 모든 것을 보았다. 이 경험은 코드가 간결하고 읽기 쉽고 이해하기 쉬워야 함을 알려줍니다.

기계 학습 프로젝트를 만들고 MIDI 파일을 구문 분석해야 합니다.
거기에서 SMPTE 타임코드를 구문 분석해야 합니다. 나는 iota와 관용적 방법을 사용하는 것이 꽤 어렵다는 것을 알지만, 그것이 나를 막지는 못한다)

const (
        SMTPE0 int8 = ((-24 - (1 + (iota - 1) * 3) % 6 * (iota - 1) / ((iota - 1) | 0x01)) - 10 * ((iota - 1) % 2) - 5 * (iota / 3 - iota / 4) ) * iota / (iota | 0x01)
    SMTPE24 
    SMTPE25
    SMTPE29
    SMTPE30
)
const (
   _SMTPE0 int8 = 0 
   _SMTPE24 int8 = -24
   _SMTPE25 int8 = -25
   _SMTPE29 int8 = -29
   _SMTPE30 int8 = -30
)

물론 방어 프로그래밍으로 런타임 검사가 필요할 수도 있습니다...

func IsSMTPE(status int8) bool {
    j := 4
    for i:= 0; i >= -30; i -= j % 6{
        if i == int(status){ 
            return true
        }
        j+=3
    }

    return status == 0
}

플레이그라운드 참조

열거형은 어떤 경우에는 프로그래머의 라이브를 더 간단하게 만듭니다. 열거형은 도구일 뿐이므로 적절하게 사용하면 시간을 절약하고 생산성을 높일 수 있습니다. C++, C# 또는 다른 언어와 같이 Go 2에서 이것을 구현하는 데 문제가 없다고 생각합니다. 이 예는 농담이지만 ​​문제를 분명히 보여줍니다.

@treeter12 귀하의 예가 "문제를 명확하게 보여 주는" 방법을 알 수 없습니다. 열거형이 어떻게 이 코드를 더 낫거나 더 안전하게 만들까요?

enum과 동일한 논리를 구현한 C# 클래스가 있습니다.

 public enum SMTPE : sbyte
   {
        SMTPE0 = 0,
        SMTPE24 = -24,
        SMTPE25 = -25,
        SMTPE29 = -29,
        SMTPE30 = -30
   }

   public class TestClass
   {
        public readonly SMTPE smtpe;

        public TestClass(SMTPE smtpe)
        {
            this.smtpe = smtpe;
        }
   } 

컴파일 시간 열거형을 사용하면 다음을 수행할 수 있습니다.

1. 런타임 검사가 없습니다.
2. 팀별 오류 가능성을 크게 줄입니다(컴파일 시간에 잘못된 값을 전달할 수 없음).
3. 그것은 iota 개념과 모순되지 않습니다.
4. 상수에 대해 하나의 이름이 있는 것보다 논리를 이해하기가 더 쉽습니다(상수가 일부 낮은 수준의 프로토콜 값을 나타내는 것이 중요함).
5. ToString() 메서드를 아날로그로 만들어 값을 간단하게 표현할 수 있습니다. (CONNECTION_ERROR.NO_INTERNET은 0x12보다 낫습니다). 스트링거에 대해 알고 있지만 열거형을 사용한 명시적 코드 생성은 없습니다.
6. 일부 언어에서는 값, 범위 등의 배열을 얻을 수 있습니다.
7. 코드를 읽는 동안 이해하기 쉽습니다(머리에서 계산할 필요 없음).

결국 몇 가지 일반적인 인적 오류를 방지하고 성능을 절약하기 위한 도구일 뿐입니다.

@streeter12 의미를 명확히 해주셔서 감사합니다. 여기서 Go 상수에 비해 유일한 장점은 유형 시스템이 열거형 값 중 하나 외에 다른 값을 허용하지 않기 때문에 잘못된 값을 도입할 수 없다는 것입니다. 확실히 있으면 좋겠지만 대가도 따릅니다. 이 열거형을 해당 코드 외부로 확장할 방법이 없습니다. 외부 열거형 확장은 Go에서 표준 열거형을 사용하지 않기로 결정한 주요 이유 중 하나입니다.

일부 확장이 열거형을 사용하지 않도록 하는 간단한 필요에 답하십시오.
FE는 상태 머신이 열거형 대신 상태 패턴을 사용하도록 해야 합니다.

열거형에는 고유한 범위가 있습니다. 나는 열거 형없이 몇 가지 큰 프로젝트를 완료합니다. enum 외부 정의 코드를 확장하는 것은 끔찍한 아키텍처 결정이라고 생각합니다. 당신은 당신의 동료가 하는 일을 통제할 수 없고 그것은 몇 가지 재미있는 오류를 만듭니다)

그리고 많은 경우 대규모 프로젝트에서 오류를 크게 줄이는 인적 요소 열거를 잊었습니다.

@streeter12 불행히도 현실은 종종 열거형을 확장해야 한다는 것입니다.

enum/sum 유형을 확장하는 @griesemer 는 별도의 때로는 호환되지 않는 유형을 생성합니다.

열거형/합계에 대한 명시적 유형이 없더라도 Go에서는 여전히 그렇습니다. 패키지에 {1, 2, 3} 값이 필요한 "열거형 유형"이 있고 "확장된 열거형 유형"에서 4를 전달하면 여전히 암시적 "유형"의 계약을 위반한 것입니다.

열거형/합계를 확장해야 하는 경우 때때로 호환되지 않는 경우를 명시적으로 처리하는 명시적 To/From 변환 함수도 생성해야 합니다.

이 제안 또는 #19412와 같은 유사한 제안에 대한 그 주장과 사람들 사이의 단절은 "때때로 변환 함수를 작성하는 것" 대신 "컴파일러가 처리할 수 있는 기본 유효성 검사 코드를 항상 작성"하는 것이 트레이드 오프라는 것이 이상하다고 생각한다는 것입니다. 어쨌든 다시 써야 할 것입니다."

어느 쪽이 옳다 그르다거나 그것이 고려되어야 할 유일한 절충안이라는 말은 아니지만, 나는 내가 알아차린 양쪽 사이의 의사소통에서 병목 현상을 식별하고 싶었습니다.

이 제안 또는 #19412와 같은 유사한 제안에 대한 그 주장과 사람들 사이의 단절은 "때때로 변환 함수를 작성하는 것" 대신 "컴파일러가 처리할 수 있는 기본 유효성 검사 코드를 항상 작성"하는 것이 트레이드 오프라는 것이 이상하다고 생각한다는 것입니다. 어쨌든 다시 써야 할 것입니다."

아주 잘 진술

@jimmyfrasche 그것은 내가 개인적으로 절충안을 설명하는 방식이 아닙니다. 저는 "컴파일러가 처리할 수 있는 기본 유효성 검사 코드를 항상 작성하는 것"과 "Go를 사용하는 모든 사람이 배우고 이해해야 하는 유형 시스템에 완전히 새로운 개념을 추가하는 것"이라고 말하고 싶습니다.

아니면 다른 식으로 말하겠습니다. 내가 말할 수 있는 한, Go의 열거형 유형에서 누락된 유일한 중요한 기능은 유형화되지 않은 상수의 할당 유효성 검사가 없고 명시적 변환에 대한 검사가 없으며 모든 값이 스위치. 이러한 기능은 모두 열거된 유형의 개념과 독립적인 것 같습니다. 다른 언어가 열거형을 가지고 있다는 사실이 Go에도 열거형이 필요하다는 결론에 이르게 해서는 안 됩니다. 예, 열거형은 이러한 누락된 기능을 제공합니다. 그러나 그것들을 얻기 위해 완전히 새로운 종류의 유형을 추가하는 것이 정말로 필요합니까? 그리고 언어 복잡성의 증가가 이점을 누릴 가치가 있습니까?

@ianlancetaylor 언어에 복잡성을 추가하는 것은 확실히 고려해야 할 유효한 사항이며 "다른 언어에 포함되어 있기 때문에"는 확실히 논쟁거리가 아닙니다. 저는 개인적으로 열거형이 그 자체로 가치가 있다고 생각하지 않습니다. (그러나 그들의 일반화, 합계 유형은 확실히 나에게 많은 상자를 표시합니다).

유형이 할당 가능성을 선택 해제하는 일반적인 방법은 좋을 것이지만 이것이 기본 형식 외부에서 얼마나 널리 유용할지 확신할 수 없습니다.

컴파일러에게 유효한 값의 전체 목록을 알려주지 않고 "스위치에서 처리되는 모든 값 확인"이라는 개념이 얼마나 일반화될 수 있는지 잘 모르겠습니다. 열거형 및 합계 유형 외에 내가 생각할 수 있는 유일한 것은 Ada의 범위 유형과 같은 것이지만 변환 또는 반영될 때마다 오프셋을 처리하기 위해 0이 범위에 있거나 코드가 생성 되어야 하는 경우가 아니면 0 값과 자연스럽게 호환되지 않습니다. 에. (다른 언어에는 유사한 유형의 패밀리가 있고 일부는 파스칼 패밀리에 있지만 현재로서는 Ada가 유일합니다)

어쨌든, 나는 구체적으로 다음을 언급했습니다.

여기서 Go 상수에 비해 유일한 장점은 유형 시스템이 열거형 값 중 하나 외에 다른 값을 허용하지 않기 때문에 잘못된 값을 도입할 수 없다는 것입니다. 확실히 있으면 좋겠지만 대가도 따릅니다. 이 열거형을 해당 코드 외부로 확장할 방법이 없습니다. 외부 열거형 확장은 Go에서 표준 열거형을 사용하지 않기로 결정한 주요 이유 중 하나입니다.

그리고

불행히도 현실은 종종 열거형을 확장해야 한다는 것입니다.

내가 말한 이유 때문에 그 주장은 나에게 효과가 없습니다.

@jimmyfrasche 이해했습니다; 어려운 문제입니다. 이것이 Go에서 우리가 그것을 해결하려고 시도하지 않고 대신 상수 값을 반복할 필요 없이 상수 시퀀스를 쉽게 생성할 수 있는 메커니즘을 제공한 이유입니다.

(지연 발송 - https://github.com/golang/go/issues/19814#issuecomment-349158748에 대한 응답으로 발송되었습니다.)

@griesemer 실제로 Go 1에 대한 올바른 요청이었지만 일부는 Go 2에 대해 재평가할 가치가 있습니다.

언어에는 열거형에서 원하는 _거의_ 모든 것을 얻을 수 있을 만큼 충분합니다. 유형 정의보다 더 많은 코드가 필요하지만 생성기가 대부분을 처리할 수 있으며 열거형 유형과 함께 제공되는 모든 기능을 얻는 대신 상황에 맞게 정의할 수 있습니다.

이 접근 방식은 https://play.golang.org/p/7ud_3lrGfx 를 제외한 모든 것을 제공합니다.

1. 정의 패키지 내의 안전
2. 완전성을 위해 스위치를 린트하는 기능

그 접근 방식은 작고 단순한 합계 유형†에도 사용할 수 있지만 사용하기가 더 어색하므로 https://github.com/golang/go/issues/19412#issuecomment -323208336과 같은 것이 추가될 것이라고 생각합니다. 이 언어는 코드 생성기에서 문제 1과 2를 피하는 열거형 유형을 만드는 데 사용할 수 있습니다.

† 이 구성의 json.Token 스케치는 https://play.golang.org/p/YFffpsvx5e 를 참조하세요.

우리는 트레이드 오프가 "어쨌든 작성해야 하는 변환 함수를 가끔 작성" 대신 "항상 컴파일러가 처리할 수 있는 기본 유효성 검사 코드를 작성"하는 것이 이상하다고 생각합니다.

나에게 - 점진적인 수리 를 강력히 지지하는 진영의 대표자 - 이것은 올바른(ish) 절충안처럼 보입니다. 솔직히, 점진적 수리에 대해 이야기하지 않더라도 나는 그것이 더 나은 멘탈 모델이라고 생각할 것입니다.

첫째, type-checked enum은 어쨌든 소스 코드에 삽입된 값만 확인할 수 있습니다. 열거형이 네트워크를 통해 이동하거나 디스크에 유지되거나 프로세스 간에 교환되는 경우 모든 베팅이 해제됩니다(대부분의 열거형 사용이 이 범주에 속함). 따라서 런타임에 비호환성을 처리하는 문제를 해결하지 못할 것입니다. 그리고 유효하지 않은 열거형 값을 만났을 때 보편적으로 적용되는 기본 동작은 없습니다. 종종 오류가 발생하고 싶을 수 있습니다. 때로는 기본값으로 강제 변환하고 싶을 수도 있습니다. 대부분의 경우 재직렬화 시 손실되지 않도록 보존하고 전달하려고 합니다.

물론 유효성이 확인되고 필요한 동작이 구현되는 신뢰 경계가 있어야 하며 해당 경계 내의 모든 것이 해당 동작을 신뢰할 수 있어야 한다고 주장할 수도 있습니다. 그리고 정신적 모델은 이 신뢰 경계가 과정이어야 한다는 것입니다. 바이너리의 모든 코드는 원자적으로 변경되고 내부적으로 일관성을 유지하기 때문입니다. 그러나 그 정신적 모델은 점진적인 수리라는 아이디어에 의해 침식됩니다. 갑자기, 자연적인 신뢰 경계는 원자적 수리를 적용하는 단위와 일관성이 있다고 신뢰하는 단위로서 패키지(또는 저장소)가 됩니다.

그리고 개인적으로 저는 그것이 자기 일관성의 매우 자연스럽고 훌륭한 단위라는 것을 알았습니다. 패키지는 의미 체계, 규칙 및 규칙을 머릿속에 간직할 수 있을 만큼 충분히 커야 합니다. 이것이 내보내기가 유형 수준이 아닌 패키지 수준에서 작동하는 이유와 최상위 선언의 범위가 프로그램 수준이 아닌 패키지 수준인 이유이기도 합니다. 패키지 수준에서도 알 수 없는 열거형 값의 올바른 처리를 결정하기에 충분해 보입니다. 이를 확인하고 내부적으로 원하는 동작을 유지하는 내보내지 않은 기능이 있습니다.

나는 철저한 검사를 포함하여 유형 검사된 열거형을 갖는 제안보다 모든 스위치에 기본 케이스가 필요하다는 제안에 훨씬 더 동의합니다.

@Merovius 운영 체제 프로세스와 패키지는 둘 다 신뢰 경계입니다.

프로세스 외부에서 들어오는 정보는 유입될 때 유효성을 검사해야 하며 프로세스에 대한 적절한 표현으로 비정렬화되어야 하며 실패할 경우 적절한 주의를 기울여야 합니다. 그것은 결코 사라지지 않습니다. 나는 거기에 합계/열거형 유형에 특정한 것을 실제로 보지 않습니다. 구조체에 대해서도 같은 말을 할 수 있습니다. 때로는 추가 필드나 너무 적은 필드를 얻을 수 있습니다. 구조체는 여전히 유용합니다.

즉, 열거형 유형을 사용하면 이러한 오류를 모델링하는 특정 사례를 포함할 수 있습니다. 예를 들어

type FromTheNetwork enum {
  // pretend all the "valid" values are listed here
  Missing // the value was not included in the message
  Unknown // the value was not in the set of the valid values
  Error // there was an error attempting to read the value
}

합계 유형을 사용하면 더 나아갈 수 있습니다.

type FromTheNetwork pick {
  Missing struct{} // Not included in message
  Valid somepkg.TheSumBeingReceived // Include valid states with composition
  Unknown []byte // Raw bytes of unknown value received
  Error error // The error from attempting to read the value
}

(전자는 오류 사례에 특정한 필드가 있는 구조체에서 유지되지 않는 한 유용하지 않지만 해당 필드의 유효성은 열거형 값에 따라 다릅니다. sum 유형은 본질적으로 a이므로 이를 처리합니다. 한 번에 하나의 필드만 설정할 수 있는 구조체입니다.)

패키지 수준에서 여전히 높은 수준의 유효성 검사를 처리해야 하지만 낮은 수준의 유효성 검사는 유형과 함께 제공됩니다. 유형의 도메인을 줄이면 패키지를 작게 유지하고 머리 속에 넣을 수 있습니다. 또한 편집기가 모든 case X: 행을 작성하고 실제 코드를 채우도록 남겨두거나 린터를 사용하여 모든 코드가 모든 경우를 검사하는지 확인할 수 있도록 도구에 대한 의도가 더 명확해집니다. 이전에 컴파일러에서 철저함을 유지하는 것에 대해 이야기했습니다).

나는 거기에 합계/열거형 유형에 특정한 것을 실제로 보지 않습니다. 구조체에 대해서도 같은 말을 할 수 있습니다. 때로는 추가 필드나 너무 적은 필드를 얻을 수 있습니다. 구조체는 여전히 유용합니다.

(현재 iota에서 구성한 것과 같은) 개방형 열거형에 대해 이야기하고 있다면 당연히 그렇습니다. 우리가 닫힌 열거형(사람들이 열거형에 대해 이야기할 때 일반적으로 이야기하는 것)이나 철저한 검사가 포함된 열거형에 대해 이야기하는 경우 확실히 특별합니다. 확장할 수 없기 때문입니다.

구조체와의 비유는 이것을 다소 완벽하게 설명합니다. Go 1 호환성 약속은 키가 없는 구조체 리터럴을 모든 프로미스에서 제외합니다. 따라서 키가 있는 구조체 리터럴을 사용하는 것은 go vet이 이를 확인하는 "최고"로 강력하게 간주되는 관행이었습니다. 이유는 정확히 같습니다. 키가 없는 구조체 리터럴을 사용하는 경우 구조체는 더 이상 확장할 수 없습니다.

네. 이와 관련하여 구조체는 열거형과 정확히 같습니다. 그리고 우리는 확장 가능한 방식으로 사용하는 것이 바람직하다는 데 커뮤니티로서 동의했습니다.

즉, 열거형 유형을 사용하면 이러한 오류를 모델링하는 특정 사례를 포함할 수 있습니다.

귀하의 예는 패키지 경계가 아닌 프로세스 경계(네트워크 오류에 대해 이야기함으로써)만 다룹니다. FromTheNetwork 에 "InvalidInternalState"를 추가하면 패키지가 어떻게 작동합니까? 다시 컴파일하기 전에 스위치를 수정해야 합니까? 그런 다음 점진적 복구 모델에서는 확장할 수 없습니다. 처음에 컴파일하려면 기본 케이스가 필요합니까? 그러면 열거형에 아무런 의미가 없는 것 같습니다.

다시 말하지만, 열거형을 여는 것은 다른 질문입니다. 나는 다음과 같은 일을 할 것입니다.

유형의 도메인을 줄이면 패키지를 작게 유지하고 머리 속에 넣을 수 있습니다. 또한 도구에 대한 의도를 더 명확하게 하여 편집기가 모든 대소문자 X: 행을 작성하고 실제 코드를 채우도록 남겨두거나 린터를 사용하여 모든 코드가 모든 경우를 검사하는지 확인할 수 있습니다.

그러나 이를 위해 유형으로 실제 열거형이 필요하지 않습니다. 이러한 linting 도구는 iota 를 사용하여 $ const -declarations 를 발견적으로 확인할 수도 있습니다. 여기서 모든 케이스는 지정된 유형이고 "열거형"으로 간주하고 원하는 검사를 수행합니다. 모든 스위치에 기본값이 있어야 하거나 모든 (알려진) 경우를 확인해야 하는 자동 완성 또는 린팅을 돕기 위해 이러한 "관례에 따른 열거형"을 사용하는 도구를 사용하고 싶습니다. 나는 대부분 그렇게 행동하는 enum-keyword를 추가하는 것에 반대하지 않을 것입니다. 즉, 열거형이 열려 있고(모든 정수 값을 사용할 수 있음) 추가 범위를 제공하고 모든 스위치에 기본값이 있어야 합니다. 그들은 내 일정을 해치지 않을 것입니다). 그것이 제안된 것이라면 - 좋습니다. 그러나 이 제안을 지지하는 대다수(물론 초기 텍스트는 아님)가 의미하는 바는 아닌 것 같습니다.

우리는 점진적인 복구와 확장성을 유지하는 것의 중요성에 대해 동의하지 않을 수 있습니다. 예를 들어 많은 사람들은 의미론적 버전 관리가 해결하는 문제에 대한 더 나은 솔루션이라고 믿습니다. 그러나 그것들이 중요하다고 생각 한다면 열거형을 해롭거나 무의미하다고 보는 것이 완벽하게 타당하고 합리적입니다. 그리고 그것은 내가 대답하고 있던 질문이었습니다. 사람들이 컴파일러에서 확인하는 대신 모든 곳에서 확인을 요구하는 것을 합리적으로 절충할 수 있는 방법. 답변: API의 확장성과 진화를 중시함으로써 어쨌든 사용 사이트에서 이러한 확인이 필요합니다.

때때로 enum의 반대자들은 확장할 수 없다고 말했지만 직렬화/전환 후에도 여전히 확인이 필요하며 호환성 등을 다시 깨뜨릴 수 있습니다.

이것이 열거형 문제가 아닌 주요 문제는 개발 및 구성 문제입니다.
열거형을 사용하는 것이 터무니없는 예를 제시하려고 하지만 몇 가지 상황을 더 자세히 살펴보겠습니다.

예 1. 저는 저수준 개발자이고 일부 레지스터 주소, 확립된 저수준 프로토콜 값 등에 대해 const가 필요합니다. 지금 Go에서는 단 하나의 솔루션을 얻었습니다. 많은 경우에 추악할 것이기 때문에 iota 없이 const를 사용하는 것입니다. . 하나의 패키지에 대해 여러 상수 블록을 얻을 수 있습니다. 나는 20개의 상수를 모두 얻었고 그들이 같은 유형과 비슷한 이름을 가지고 있다면 오류를 만들 수 있습니다. 프로젝트가 크면 이 오류가 발생합니다. 방어적 프로그래밍, TDD로 이것을 방지하려면 중복 검사 코드(중복 코드 = 중복 오류/테스트)를 차단해야 합니다. 전송을 사용하면 유사한 문제가 발생하지 않으며 이 경우 값이 변경되지 않습니다(프로덕션에서 레지스터 주소가 변경되는 상황을 찾아보십시오.)). 우리는 여전히 가끔 파일/넷 등에서 얻은 값이 범위 내에 있는지 확인하지만 이를 중앙 집중화하는 데 문제가 없습니다(c# Enum.TryParse 참조).예를 들어). enum을 사용하면 이 경우 개발 시간과 성능을 절약할 수 있습니다.

예제 2. 상태/오류 로직이 있는 작은 모듈을 개발 중입니다. 열거형을 비공개로 설정하면 아무도 이 열거형에 대해 알지 못하며 1의 모든 이점과 함께 문제 없이 변경/확장할 수 있습니다. 코드를 비공개 논리에 기반한 경우 개발에서 문제가 발생했습니다.

예제 3. 광범위한 응용 프로그램을 위해 자주 변경되고 확장 가능한 모듈을 개발하고 있습니다. 공개 논리/인터페이스를 결정하기 위해 열거형 또는 다른 상수를 사용하는 것은 이상한 솔루션입니다. 클라이언트-서버 아키텍처에 새 열거형 번호를 추가하면 충돌이 발생할 수 있지만 상수를 사용하면 예측할 수 없는 모델 상태를 얻을 수 있고 디스크에 저장할 수도 있습니다. 나는 예측할 수 없는 상태보다 충돌을 선호합니다. 이것은 역순응성/확장 문제가 열거형이 아니라 개발 문제라는 것을 보여줍니다. 이 경우 어떤 열거형이 적합하지 않다는 것을 이해한다면 사용하지 마십시오. 선택할 수 있는 충분한 능력이 있다고 생각합니다.

내 생각에 consts와 컴파일 시간 enum의 주요 차이점은 enum에는 두 가지 주요 계약이 있다는 것입니다.

1. 네이밍 계약.
2. 가치 계약.
   이 단락에 대한 찬성과 반대의 모든 주장은 이전에 고려되었습니다.
   계약 프로그래밍을 사용한다면 이것의 이점을 쉽게 이해할 수 있습니다.

얼마나 많은 다른 것들에 단점이 있는지 열거합니다.
브레이크 호환성 없이는 변경할 수 없습니다. 그러나 SOLID 원칙에서 O를 알고 있다면 이는 열거형뿐만 아니라 일반적인 개발에도 적용됩니다. 누군가는 병렬 논리와 가변 구조체로 내 프로그램을 못생겼다고 말할 수 있습니다. 가변 구조를 금지하자? 이 대신 변경 가능/변경 불가 구조체를 추가하고 개발자가 선택하도록 할 수 있습니다.

이상으로 Iota에도 단점이 있다는 점을 말씀드리고 싶습니다.

1. 항상 int 유형이 있습니다.
2. 머리에 값을 계산해야 합니다. 값을 계산하는 데 많은 시간을 허비할 수 있으며 문제가 없는지 확인하십시오.
   enums/const를 사용하면 F12를 눌러 모든 값을 볼 수 있습니다.
3. Iota 표현식은 이것을 테스트하는 데 필요한 코드 표현식입니다.
   일부 프로젝트에서는 이러한 이유로 iota 사용을 완전히 거부했습니다.

열거 형을 사용하는 것이 어리석은 예를 들어보십시오.

무뚝뚝한 말을 해서 실례합니다만, 이 댓글 이후에 당신이 여기에 설 근거가 별로 없다고 생각합니다.

그리고 나는 당신이 말한 대로 하지도 않았습니다. 나는 그것들이 얼마나 필요한지 보여주고 그들이 얼마나 상처를 주는지 보여주기 위해 예를 들었습니다.

우리는 합리적으로 동의하지 않을 수 있지만 적어도 모두가 선의로 논쟁해야 합니다.

실시예 1

나는 당신에게 "등록 이름"을 정말로 변경할 수 없는 것으로 줄 수도 있지만 프로토콜 값과 관련하여 확장성과 호환성을 위해 임의의 값을 취하도록 하는 입장이 합리적이라고 단호합니다. 다시 말하지만, proto2 -> proto3에는 정확히 그 변경 사항이 포함되어 있으며 학습된 경험에서 그렇게 했습니다.

그리고 어느 쪽이든, 나는 린터가 이것을 잡지 못하는 이유를 알 수 없습니다.

나는 20개의 상수를 모두 얻었고 그들이 같은 유형과 비슷한 이름을 가지고 있다면 오류를 만들 수 있습니다. 프로젝트가 크면 이 오류가 발생합니다.

이름을 잘못 입력하는 경우 열거형을 닫아도 도움이 되지 않습니다. 기호 이름을 사용하지 않고 대신 int/string-literals를 사용하는 경우에만.

실시예 2

개인적으로 '큰 프로젝트가 아니다'라는 선에 '단일 패키지'를 확고히 두는 편이다. 따라서 열거형을 확장할 때 대소문자를 잊거나 코드 위치를 변경할 가능성이 훨씬 적다고 생각합니다.

그리고 어느 쪽이든, 나는 린터가 이것을 잡지 못하는 이유를 알 수 없습니다.

실시예 3

이것이 열거형에 대해 제시되는 가장 일반적인 사용 사례입니다. 적절한 사례: 이 특정 문제는 이를 근거로 사용합니다. 자주 언급되는 또 다른 경우는 위장된 클라이언트-서버 아키텍처인 syscall입니다. 이 예제의 일반화는 "두 개 이상의 독립적으로 개발된 구성 요소가 이러한 값을 교환하는 모든 코드"로, 믿을 수 없을 정도로 광범위하며, 이에 대한 대부분의 사용 사례와 점진적 수리 모델에서는 내보낸 모든 API도 포함합니다. .

FTR, 나는 여전히 열거형이 해롭다는 것을 누구에게도 납득시키려 하지 않습니다(저는 그렇게 하지 않을 것이라고 확신합니다). 내가 어떻게 그들이 그러한 결론에 도달했는지, 그리고 왜 내가 그들에게 유리한 주장이 설득력이 없다고 생각하는지 설명하기 위해서입니다.

항상 int 유형이 있습니다.

iota 는 (반드시 그렇지는 않지만 무엇이든), const 블록은 그렇지 않고 다양한 상수 유형을 가질 수 있습니다. 사실, 가장 일반적으로 제안되는 열거형 구현의 상위 집합입니다.

머리에 값을 계산해야 합니다.

다시 말하지만, 이것을 열거형을 위한 인수로 사용할 수 없습니다. 열거형 선언에서와 마찬가지로 상수를 작성할 수 있습니다.

Iota 표현식은 이것을 테스트하는 데 필요한 코드 표현식입니다.

모든 표현식을 테스트할 필요는 없습니다. 그것이 즉시 명백하다면, 테스트는 과잉입니다. 그렇지 않은 경우 상수를 적어 두십시오. 어쨌든 테스트에서 그렇게 할 것입니다.

iota 는 현재 Go에서 열거형을 수행하는 데 권장되는 방법이 아닙니다. const 선언은 그렇습니다. iota 는 연속적이거나 형식적인 const 선언을 작성할 때 타이핑을 저장하는 보다 일반적인 방법으로만 사용됩니다.

그리고 예, Go의 개방형 열거형에는 분명히 단점이 있습니다. 그것들은 위에서 광범위하게 언급되었습니다. 스위치의 경우를 잊어버려 버그가 발생할 수 있습니다. 네임스페이스를 사용하지 않습니다. 실수로 잘못된 값이 되는(버그로 이어지는) 비 기호 상수를 사용할 수 있습니다.
그러나 고정된 솔루션(열거형 유형)을 사용하여 문제를 해결하는 특정 절충점에 대해 논쟁하는 것보다 이러한 단점에 대해 이야기하고 제안된 솔루션의 단점에 대해 측정하는 것이 더 생산적인 것 같습니다.

나에게 대부분의 단점은 특정 종류의 const 선언을 감지하고 사용법을 확인하는 linter-tool을 사용하여 현재 언어에서 대부분 실용적으로 해결할 수 있습니다. 네임 스페이싱은 이런 식으로 해결할 수 없으며 좋지 않습니다. 그러나 그 문제에 대한 다른 해결책도 열거형과 다를 수 있습니다.

나는 당신에게 "등록 이름"을 정말로 변경할 수 없는 것으로 줄 수도 있지만 프로토콜 값과 관련하여 확장성과 호환성을 위해 임의의 값을 취하도록 하는 입장이 합리적이라고 단호합니다. 다시 말하지만, proto2 -> proto3에는 정확히 그 변경 사항이 포함되어 있으며 학습된 경험에서 그렇게 했습니다.

이것이 내가 확립된 가치를 말한 이유입니다. Fe wav 형식 기반은 수년 동안 변경되지 않았으며 뛰어난 백 기능을 제공합니다. 새로운 값을 유지할 수 있는 경우 열거형을 사용하고 일부 값을 추가할 수 있습니다.

이름을 잘못 입력하는 경우 열거형을 닫아도 도움이 되지 않습니다. 기호 이름을 사용하지 않고 대신 int/string-literals를 사용하는 경우에만.

예, 좋은 이름을 지정하는 데는 도움이 되지 않지만 한 이름으로 몇 가지 값을 구성하는 데는 도움이 될 수 있습니다. 어떤 경우에는 개발 프로세스를 더 빠르게 만듭니다. 자동 타이핑을 통해 변형 수를 하나로 줄일 수 있습니다.

이것이 열거형에 대해 제시되는 가장 일반적인 사용 사례입니다. 적절한 사례: 이 특정 문제는 이를 근거로 사용합니다. 자주 언급되는 또 다른 경우는 위장된 클라이언트-서버 아키텍처인 syscall입니다. 이 예제의 일반화는 "두 개 이상의 독립적으로 개발된 구성 요소가 이러한 값을 교환하는 모든 코드"로, 믿을 수 없을 정도로 광범위하며, 이에 대한 대부분의 사용 사례와 점진적 수리 모델에서는 내보낸 모든 API도 포함합니다. .

그러나 상수/열거형을 사용/사용하지 않는 것은 문제의 핵심을 제거하지 않으며 여전히 역순응성에 대해 생각해야 합니다. 나는 문제가 enums/const가 아니라 우리의 사용 사례에 있다고 말하고 싶습니다.

개인적으로 '큰 프로젝트가 아니다'라는 선에 '단일 패키지'를 확고히 두는 편이다. 따라서 열거형을 확장할 때 대소문자를 잊거나 코드 위치를 변경할 가능성이 훨씬 적다고 생각합니다.

이 경우에도 이름 변환 및 컴파일 시간 확인의 이점이 있습니다.

모든 표현식을 테스트할 필요는 없습니다. 그것이 즉시 명백하다면, 테스트는 과잉입니다. 그렇지 않은 경우 상수를 적어 두십시오. 어쨌든 테스트에서 그렇게 할 것입니다.

Ofcouuse 나는 모든 코드 라인을 테스트해야 하는 것은 아니지만, 선례가 있는 경우 이를 테스트하거나 다시 작성해야 한다는 것을 이해합니다. 나는 이것을 iota 없이 만드는 방법을 알고 있지만 나의 오래된 예는 단지 농담일 뿐입니다.

다시 말하지만, 이것을 열거형을 위한 인수로 사용할 수 없습니다. 열거형 선언에서와 마찬가지로 상수를 작성할 수 있습니다.

열거형에 대한 인수가 아닙니다.

@메로비우스

우리가 닫힌 열거형(사람들이 열거형에 대해 이야기할 때 일반적으로 이야기하는 것)이나 철저한 검사가 포함된 열거형에 대해 이야기하는 경우 확실히 특별합니다. 확장할 수 없기 때문입니다.

또한 안전하게 확장할 수 없습니다.

당신이 가지고 있다면

package p
type Enum int
const (
  A Enum = iota
  B
  C
)
func Make() Enum {...}
func Take(Enum) {...}

그리고

package q
import "p"
const D enum = p.C + 1

q 내에서 $#$ D 를 사용하는 것이 안전합니다( p Enum(3) 에 대한 자체 레이블을 추가하지 않는 한). 다시 p 로 전달: p.Make 의 결과를 가져오고 상태를 D 로 전환할 수 있지만 p.Take 를 호출하는 경우 다음과 같은지 확인해야 합니다. q.D 전달되지 않고 A , B , C 중 하나만 가져오거나 버그가 있는지 확인해야 합니다. 다음을 수행하여 이 문제를 해결할 수 있습니다.

package q
import "p"
type Enum int
const (
    A = p.A
    B = p.B
    C = p.C
    D = C + 1
)
// needs to return an error if passed D or an unknown state of Enum
func To(Enum) (p.Enum, error) {...}
// needs to return an error if p.Enum has a value not known to the author
// at the time this package was written.
func From(p.Enum) (Enum, error) {...}

언어에 닫힌 유형이 있든 없든 당신은 닫힌 유형을 갖는 모든 문제가 있지만 컴파일러가 당신을 감시하지 않습니다.

귀하의 예는 패키지 경계가 아닌 프로세스 경계(네트워크 오류에 대해 이야기함으로써)만 다룹니다. FromTheNetwork에 "InvalidInternalState"를 추가하면 패키지가 어떻게 작동합니까? 다시 컴파일하기 전에 스위치를 수정해야 합니까? 그런 다음 점진적 복구 모델에서는 확장할 수 없습니다. 처음에 컴파일하려면 기본 케이스가 필요합니까? 그러면 열거형에 아무런 의미가 없는 것 같습니다.

열거형 유형을 사용하는 경우에도 위와 같이 수행하고 추가 상태 및 쓰기 변환 기능으로 고유한 버전을 정의해야 합니다.

그러나 sum 유형은 열거형으로 사용되는 경우에도 구성할 수 있으므로 이러한 방식으로 매우 자연스럽고 안전하게 "확장"할 수 있습니다. 나는 예를 들었지만 더 명확하게 주어진

package p
type Enum pick {
  A, B, C struct{}
}

Enum 는 다음과 같이 "확장"될 수 있습니다.

package q
import "p"
type Enum pick {
  P p.Enum
  D struct{}
}

이번에는 p D 추가하는 것이 완전히 안전합니다. 유일한 단점은 q.Enum p.Enum 상태로 이동하려면 이중 전환해야 하지만 명시적이고 명확하며 앞서 언급했듯이 편집자가 뼈대를 뱉을 수 있다는 것입니다. 자동으로 꺼집니다.

그러나 이를 위해 유형으로 실제 열거형이 필요하지 않습니다. 이러한 린팅 도구는 또한 모든 케이스가 주어진 유형이고 "열거형"이라고 간주하고 원하는 검사를 수행하는 iota를 사용하여 const 선언을 발견적으로 확인할 수 있습니다. 모든 스위치에 기본값이 있어야 하거나 모든 (알려진) 경우를 확인해야 하는 자동 완성 또는 린팅을 돕기 위해 이러한 "관례에 따른 열거형"을 사용하는 도구를 사용하고 싶습니다.

여기에는 두 가지 문제가 있습니다.

const/iota를 통해 해당 도메인의 하위 집합에 레이블이 지정된 정의된 정수 유형이 있는 경우:

첫째, 닫힌 열거형이나 열린 열거형을 나타낼 수 있습니다. 주로 닫힌 유형을 시뮬레이션하는 데 사용되지만 일반적으로 사용되는 값에 단순히 이름을 지정하는 데 사용할 수도 있습니다. 가상의 파일 형식에 대해 열린 열거형을 고려하십시오.

const (
  //Name is the ID of a record field
  Name Record = iota
  //EmpID is the ID of an employee ID field
  EmpID

  //Intermediate values are reserved for future versions

  //Custom is the base of custom fields. Any custom field must have a unique ID greater than Custom.
  Custom Record = 42
)

이것은 0, 1 및 42가 레코드 유형의 도메인임을 말하는 것이 아닙니다. 계약은 훨씬 더 미묘하며 모델링할 종속 유형이 필요합니다. (확실히 너무 지나칠 것입니다!)

둘째, 상수 레이블이 있는 정의된 정수 유형이 도메인이 제한됨을 의미한다고 경험적으로 가정할 수 있습니다. 위로부터 오탐을 얻을 수 있지만 완벽한 것은 없습니다. go/types를 사용하여 정의에서 이 유사 유형을 추출한 다음 해당 유형의 값에 대한 모든 스위치를 찾고 찾아 모든 스위치에 필요한 레이블이 포함되어 있는지 확인할 수 있습니다. 이것은 도움이 될 수 있지만 이 시점에서 완전함을 보여주지는 않았습니다. 우리는 모든 유효한 값의 적용 범위를 보장했지만 유효하지 않은 값이 생성되지 않았다는 것을 증명하지 않았습니다. 그렇게 하는 것은 불가능합니다. 값의 모든 소스, 싱크 및 변환을 찾고 유효하지 않은 값이 생성되지 않았음을 정적으로 보장하기 위해 추상적으로 해석할 수 있다 하더라도, 반영이 참을 인식하지 못하기 때문에 런타임 시 값에 대해 아무 말도 할 수 없을 것입니다. 유형 시스템에서 인코딩되지 않기 때문에 유형의 도메인입니다.

고유한 문제가 있지만 enum 및 sum 유형에 대한 대안이 여기에 있습니다.

range m n 유형 리터럴이 최소 m 및 최대 n(모든 v에 대해 m ≤ v ≤ n)인 정수 유형을 생성한다고 가정해 보겠습니다. 이를 통해 열거형의 도메인을 다음과 같이 제한할 수 있습니다.

package p
type Enum range 0 2
const (
  A Enum = iota
  B
  C
)

도메인의 크기 = 레이블의 수이기 때문에 switch 문이 모든 가능성을 소진하는지 여부를 100% 확신으로 린트하는 것이 가능합니다. 그 열거형을 외부적으로 확장하려면 매핑을 처리하기 위한 유형 변환 함수를 절대적으로 생성해야 하지만 어쨌든 그렇게 해야 한다고 주장합니다.

물론, 실제로 구현해야 할 놀랍도록 미묘한 유형의 유형이며 나머지 Go에서는 잘 작동하지 않습니다. 또한 이것과 일부 틈새 사용 사례 외에는 많이 사용되지 않습니다.

우리는 점진적인 복구와 확장성을 유지하는 것의 중요성에 대해 동의하지 않을 수 있습니다. 예를 들어 많은 사람들은 의미론적 버전 관리가 해결하는 문제에 대한 더 나은 솔루션이라고 믿습니다. 그러나 그것들이 중요하다고 생각한다면 열거형을 해롭거나 무의미하다고 보는 것이 완벽하게 타당하고 합리적입니다. 그리고 그것은 내가 대답하고 있던 질문이었습니다. 사람들이 컴파일러에서 확인하는 대신 모든 곳에서 확인을 요구하는 것을 합리적으로 절충할 수 있는 방법. 답변: API의 확장성과 진화를 중시함으로써 어쨌든 사용 사이트에서 이러한 확인이 필요합니다.

기본 열거형 유형의 경우 동의합니다. 이 토론을 시작할 때 총액 유형보다 선택되었다면 단순히 불행했을 것입니다. 그러나 지금은 그들이 왜 해로운지 이해합니다. 저를 위해 그것을 명확히 해 주신 당신과 @griesemer 에게 감사드립니다.

합계 유형의 경우 귀하가 말한 내용이 컴파일 시간에 스위치를 완전하게 사용할 필요가 없는 타당한 이유라고 생각합니다. 나는 여전히 폐쇄형이 많은 이점을 가지고 있다고 생각하며 여기에서 살펴본 세 가지 유형 중 sum 유형이 다른 단점 없이 가장 유연합니다. 다른 좋은 유형과 마찬가지로 잘못된 값으로 인한 오류를 방지하면서 확장성이나 점진적 복구를 방해하지 않고 유형을 닫을 수 있습니다.

내가 파이썬, 자바스크립트 및 기타 일반적인 유형이 없는 언어보다 golang을 사용하는 주된 이유는 유형 안전성입니다. 저는 Java로 많은 작업을 수행했으며 Java가 제공하는 golang에서 한 가지 그리워하는 것은 안전한 열거형입니다.

열거형으로 유형을 구별할 수 있다는 점에 동의하지 않습니다. int가 필요한 경우 Java처럼 대신 int를 사용하십시오. 안전한 열거형이 필요한 경우 다음 구문을 제안합니다.

type enums enum { foo, bar, baz }

@rudolfschmidt , 나는 당신에게 동의합니다. 그것도 그렇게 보일 수 있습니다:

type DaysOfTheWeek enum {
  Monday
  Tuesday
}

그러나 여기에는 작은 함정이 있습니다. 데이터를 검증하거나 JSON으로 변환하거나 또는 FS와 상호 작용해야 하는 경우 enum 를 제어할 수 있어야 합니다.
열거형이 부호 없는 정수 집합이라고 맹목적으로 가정하면 iota로 끝날 수 있습니다.
혁신을 하려면 사용 편의성을 생각해야 합니다.
예를 들어 들어오는 JSON 내부의 값이 enum의 유효한 요소인지 얼마나 쉽게 검증할 수 있습니까?
소프트웨어가 변경되고 있다고 말하면 어떻게 됩니까?

암호 화폐 목록이 있다고 가정해 보겠습니다.

type CryptoCurrency enum {
  BTC
  ETH
  XMR
}

우리는 여러 타사 시스템과 데이터를 교환합니다. 수천 가지가 있다고 가정해 보겠습니다.
당신은 긴 기록, 저장 데이터의 수를 가지고 있습니다. 시간이 지나면 BitCoin은 결국 죽습니다. 아무도 그것을 사용하지 않습니다.
따라서 구조에서 삭제하기로 결정합니다.

type CryptoCurrency enum {
  ETH
  XMR
}

이로 인해 데이터가 변경됩니다. enum의 모든 값이 이동했기 때문입니다. 괜찮습니다. 데이터 마이그레이션을 실행할 수 있습니다. 귀하의 파트너는 어떻습니까? 그들 중 일부는 그렇게 빨리 움직이지 않고, 일부는 자원이 없거나 여러 가지 이유로 그렇게 할 수 없습니다.
그러나 당신은 그들로부터 데이터를 수집하고 있습니다. 그래서 당신은 2개의 열거형을 갖게 될 것입니다: old and new; 둘 다 사용하는 데이터 매퍼.
이는 열거형에 대한 정의의 유연성과 그러한 종류의 데이터를 검증하고 마샬링/언마샬링하는 기능을 제공해야 함을 알려줍니다.

type CryptoCurrency enum {
  ETH = 1, // reminds const?
  XMR = 2
}
// this is real life case 
v := 3
if v is CryptoCurrency {
 // right?
} else {
 // nope, provide default value
 v = CryptoCurrency.ETH
}

열거형과 사용 사례의 적용 가능성에 대해 생각해야 합니다.

수천 줄의 상용구 코드를 절약할 수 있다면 2개의 새로운 키워드를 배울 수 있습니다.

중간 지점은 실제로 열거형 값을 제한하지 않고 열거형 값의 유효성을 검사할 수 있는 기능을 갖는 것입니다. 열거형 유형은 거의 동일하게 유지됩니다. 명명된 상수의 무리입니다. 열거형 유형의 변수는 열거형의 기본 유형 값과 같을 수 있습니다. 그 위에 추가하는 것은 볼 값의 유효성을 검사하는 기능입니다. 유효한 열거형 값이 포함되어 있는지 여부입니다. 그리고 stringification과 같은 다른 보너스가 있을 수 있습니다.

매우 자주 나는 모든 곳에 열거형이 있는 프로토콜(protobuf 또는 thrift)이 있는 상황에 처해 있습니다. 나는 그들 각각을 검증해야 하고, 열거형 값이 나에게 알려지지 않았다면, 그 메시지를 버리고 오류를 보고해야 합니다. 그런 종류의 메시지를 처리할 수 있는 다른 방법이 없습니다. 열거형이 상수의 집합인 언어의 경우 가능한 모든 조합을 확인하는 엄청난 양의 switch 문을 작성하는 것 외에 다른 방법이 없습니다. 엄청난 양의 코드와 실수가 있을 수 밖에 없습니다. C#과 같은 것으로 열거형 검증을 위한 내장 지원을 사용하여 많은 시간을 절약할 수 있습니다. 일부 protobuf 구현은 실제로 내부적으로 그렇게 하고 있는 경우 예외를 발생시킵니다. 로깅이 얼마나 쉬운지는 말할 것도 없고 상자에서 바로 문자열화를 얻을 수 있습니다. protobuf가 Stringer 구현을 생성하는 것은 좋지만 코드의 모든 것이 protobuf인 것은 아닙니다.

그러나 값을 저장할 수 있는 기능은 메시지를 버리고 싶지 않고 유효하지 않은 경우에도 메시지로 무언가를 수행하는 다른 경우에 유용합니다. 클라이언트는 일반적으로 메시지를 버릴 수 있지만 서버 측에서는 종종 모든 것을 데이터베이스에 저장해야 합니다. 콘텐츠를 버리는 것은 선택 사항이 아닙니다.

그래서 나에게는 열거형 값을 검증하는 능력에 진정한 가치가 있습니다. 유효성 검사만 수행하는 수천 줄의 상용구 코드를 절약할 수 있습니다.

이 기능을 도구로 제공하는 것은 나에게 매우 간단해 보입니다. 그 일부가 이미 스트링거 도구에 있습니다. enumer Foo 와 같이 호출할 도구가 있는 경우 Foo fmt.Stringer #$ 메서드와 다음을 확인하는 Known() bool 메서드 저장된 값이 알려진 값의 범위에 있습니다. 그러면 문제가 완화됩니까?

@Merovius 는 다른 것이 없으면 유용할 것입니다. 그러나 나는 일반적으로 autogen에 반대합니다. 유용하고 제대로 작동하는 경우는 한 번 컴파일할 수 있는 매우 안정적인 프로토콜이 있는 protobuf와 같은 것입니다. 일반적으로 열거형에 사용하는 것은 단순한 유형 시스템의 목발처럼 느껴집니다. 그리고 Go가 언어 자체의 철학에 어긋나는 타입 안전성에 관한 모든 것을 살펴봅니다. 언어를 지원하는 대신 실제로 언어 생태계의 일부가 아닌 이 인프라를 기반으로 개발을 시작합니다. 언어에서 누락된 것을 구현하는 것이 아니라 조사를 위한 외부 도구를 남겨두십시오.

. 일반적으로 열거형에 사용하는 것은 단순한 유형 시스템의 목발처럼 느껴집니다.

왜냐하면 Go의 유형 시스템은 유명하고 의도적으로 단순하기 때문입니다. 그러나 그것은 문제가 아니라 문제를 완화할 수 있는지 여부였습니다. "나는 그것을 좋아하지 않는다"를 제외하고 나는 그것이 어떻게 그렇지 않은지 정말로 알지 못한다(당신이 어쨌든 열린 열거형을 가정한다면).

그리고 Go가 언어 자체의 철학에 어긋나는 타입 안전성에 관한 모든 것을 살펴봅니다.

Go는 "형식 안전성에 관한 모든 것"이 아닙니다. Idris와 같은 언어는 모두 유형 안전성에 관한 것입니다. Go는 대규모 엔지니어링 문제 에 관한 것이므로 해결하려는 문제에 따라 설계가 진행됩니다. 예를 들어, 해당 유형 시스템은 API 변경으로 인한 광범위한 버그를 포착하고 일부 대규모 리팩토링을 가능하게 합니다. 그러나 학습을 용이하게 하고 코드베이스의 분산을 줄이며 타사 코드의 가독성을 높이기 위해 의도적으로 단순하게 유지되었습니다.

따라서 관심 있는 사용 사례(열린 열거형)가 언어 변경 없이 쉽게 읽을 수 있는 코드를 생성하는 도구로 해결할 수 있다면 Go의 철학과 매우 일치하는 것 같습니다. 특히, 기존 기능의 하위 집합인 새로운 언어 기능을 추가하는 것은 Go의 디자인과 일치하지 않는 것 같습니다.

반복해서 말씀드리자면, 관심 있는 상용구를 생성하는 도구를 사용하여 실제 문제를 해결하지 못하는 방법을 확장할 수 있다면 도움이 될 것입니다. .

토론에서 나온 몇 가지 아이디어를 결합했습니다. 이에 대해 어떻게 생각하시나요?

몇 가지 기본 정보:

1. 다른 모든 유형과 마찬가지로 열거형을 확장할 수 있습니다.
2. 그들은 상수처럼 저장되지만 유형 이름을 접두사로 사용합니다. 이유: 현재 iota-enums를 사용할 때 모든 상수의 접두사로 열거형 이름을 쓸 것입니다. 이 기능을 사용하면 그냥 피할 수 있습니다.
3. 그것들은 불변이며 다른 모든 상수처럼 취급됩니다.
4. 열거형을 반복할 수 있습니다. 이렇게 하면 지도처럼 작동합니다. 키는 열거형 이름이고 값은 열거형 값입니다.
5. 다른 모든 유형과 마찬가지로 열거형에 메서드를 추가할 수 있습니다.
6. 모든 열거형 값은 자동 생성된 메서드에 있어야 합니다.
7. Name() 는 열거형 변수의 이름을 반환합니다.
8. Index() 는 자동으로 증가하는 열거형 인덱스를 반환합니다. 배열이 시작되는 곳에서 시작됩니다.

암호:
```가다
패키지 메인

//예제 A
type Country enum[struct] { //enum은 다른 유형을 확장할 수 있습니다(예제 B 참조).
Austria("AT", "Austria", false) // const처럼 액세스할 수 있지만 유형은 다음과 같습니다.
Germany("DE", "Germany", true) //접두사(예: Country.Austria)

//The struct will automatically begin when it doesn't match the format EnumName(...) anymore
Code, CountryName string
HasMerkel bool //Totally awesome

}

// 열거형은 다른 모든 유형과 같은 메서드를 가질 수 있습니다.
func(c 국가) test() {}

함수 메인() {
println(Country.Austria.CountryName) //오스트리아
println(국가.독일.코드) //DE

/* Prints:
Austria
0
Germany
1
 */
for name, country := range Country {
    println(name) //Austria
    println(name == country.Name()) //true ; also autogenerated 
    println(country.Index()) //Auto generated increasing index
}

}

//예제 B
유형 쿨니스 enum[int] {
아주멋진(10)
쿨(5)
쿨하지 않다(0)
}```

@sinnlosername 열거형은 매우 이해하기 쉬운 것이어야 한다고 생각합니다. 이전 토론에서 제시된 아이디어 중 일부를 결합하는 것이 반드시 열거형에 대한 최상의 아이디어로 이어지는 것은 아닙니다.

나는 다음이 이해하기 쉬울 것이라고 믿습니다.

선언

type Day enum {
    Monday
    Tuesday
    ...
    Sunday
}

문자열 변환( Stringer 인터페이스 사용):

func (d Day) String() string {
    switch d {
    case Monday:
        return "mon"
    case Tuesday:
        return "tues"
    ...
    case Sunday:
        return "sun"
    }
}

간단합니다. 이것의 이점은 enum을 전달할 때 더 강력한 유형 안전성을 허용한다는 것입니다.

사용 예

func IsWeekday(d Day) bool {
    return d != Saturday && d != Sunday
}

여기서 Day 를 나타내기 위해 string 상수를 사용한다면 IsWeekday 는 "sat" 또는 "sun" 가 아닌 모든 문자열이 는 평일입니다(즉, IsWeekday("abc") 는 무엇을 반환해야 합니까?). 대조적으로, 위에 표시된 함수의 영역은 제한되어 있으므로 입력과 관련하여 함수가 더 의미가 있습니다.

@ljeabmreosn

아마 그래야 한다

func IsWeekday(d Day) bool {
    return d != Day.Saturday && d != Day.Sunday
}

필요한 방법으로 언어를 개선하기 위해 golang 팀을 기다리는 것을 포기했습니다. 모든 사람이 Rust lang을 살펴보라고 권할 수 있습니다. 이미 enum 및 제네릭 등과 같은 원하는 기능이 모두 있습니다.

우리는 2018년 5월 14일에 있으며 enum 지원에 대해 여전히 논의하고 있습니다. 도대체 무엇을 의미합니까? 개인적으로 골랑에 실망했습니다.

기능을 기다리는 동안 답답할 수 있다는 점을 이해합니다. 그러나 이와 같이 건설적이지 않은 댓글을 게시하는 것은 도움이 되지 않습니다. 귀하의 의견을 존중해 주십시오. https://golang.org/conduct를 참조하세요.

감사 해요.

@agnivade @rudolfschmidt 에 동의해야 합니다. GoLang은 이러한 기능, API의 부족 및 Go 제작자의 과거 실수를 변경하거나 수용하는 것에 대한 저항이 너무 많기 때문에 내가 가장 좋아하는 언어가 아닙니다. 하지만 직장에서 최근 프로젝트에 사용할 언어에 대한 결정권자는 내가 아니었기 때문에 지금은 선택의 여지가 없습니다. 그래서 나는 모든 단점을 가지고 일해야합니다. 근데 솔직히 GoLang에서 코드쓰는거 고문같네;-)

필요한 방법으로 언어를 개선하기 위해 golang 팀을 기다리는 것을 포기했습니다.

• 필요하다는 단어는 "내가 원하는 것"을 의미하지 않습니다.

실제로 모든 현대 언어의 핵심 기능이 필요합니다. GoLang에는 몇 가지 좋은 기능이 있지만 프로젝트가 보수적이라면 살아남지 못할 것입니다. 열거형이나 제네릭과 같은 기능은 좋아하지 않는 사람들에게는 단점이 없지만 사용하려는 사람들에게는 많은 이점이 있습니다.

그리고 "하지만 단순하게 지내고 싶어"라고 말하지 마세요. "단순한" 것과 "실제 기능이 없는 것" 사이에는 큰 차이가 있습니다. Java는 매우 간단하지만 많은 기능이 누락되었습니다. 따라서 Java 개발자가 마법사이거나 이 인수가 잘못되었습니다.

실제로 모든 현대 언어의 핵심 기능이 필요합니다.

확신하는. 이러한 핵심 기능을 튜링 완전성이라고 합니다. _모든 것_은 디자인 선택입니다. Turing 완전성과 C++(예:) 사이에는 많은 공간이 있으며 그 공간에서 많은 언어를 찾을 수 있습니다. 분포는 전역 최적값이 존재하지 않음을 나타냅니다.

GoLang에는 몇 가지 좋은 기능이 있지만 프로젝트가 보수적이라면 살아남지 못할 것입니다.

혹시. 지금까지 계속 성장하고 있습니다. IMO, 보수적이지 않았다면 여전히 성장하지 않았을 것입니다. 우리의 의견은 모두 주관적이며 기술적으로 그다지 가치가 없습니다. 규칙을 정하는 것은 디자이너의 경험과 취향입니다. 다른 의견을 갖는 것은 괜찮지만 디자이너가 의견을 공유할 것이라고 보장할 수는 없습니다.

BTW, 만약 사람들이 요구하는 기능의 10%가 채택된다면 오늘날 바둑이 어떨지 상상한다면 지금쯤이면 바둑을 더 이상 사용하지 않을 것입니다.

사실 당신은 내 대답의 가장 중요한 논거를 놓쳤습니다. 그것은 이미 당신이 말한 것들 중 일부에 반대이기 때문일 수 있습니다.

"열거형이나 제네릭과 같은 기능은 좋아하지 않는 사람들에게는 단점이 없지만 사용하려는 사람들에게는 많은 이점이 있습니다."

그리고 이러한 보수성이 골랑 성장의 원인이라고 생각하는 이유는 무엇입니까? 나는 이것이 golang의 효율성과 훌륭한 표준 라이브러리 세트와 관련이 있을 가능성이 더 높다고 생각합니다.

또한 Java는 Java 9에서 중요한 사항을 변경하려고 할 때 일종의 "충돌"을 경험했는데, 이로 인해 많은 사람들이 대안을 찾도록 했을 것입니다. 그러나 이 충돌이 발생하기 전에 Java를 살펴보십시오. 개발자의 삶을 더 쉽게 만들어주는 기능이 점점 더 많아지기 때문에 지속적으로 성장했습니다.

"열거형이나 제네릭과 같은 기능은 좋아하지 않는 사람들에게는 단점이 없지만 사용하려는 사람들에게는 많은 이점이 있습니다."

그것은 매우 명백하게 사실이 아닙니다. 모든 기능은 결국 내가 가져오려는 stdlib 및/또는 패키지에 포함됩니다. _모든 사람_은 새로운 기능이 좋든 싫든 상관없이 새 기능을 처리해야 합니다.

지금까지 계속 성장하고 있습니다. IMO, 보수적이지 않았다면 여전히 성장하지 않았을 것입니다.

느린 성장(있는 경우)이 보수성 때문이 아니라 표준 라이브러리, 이미 존재하는 언어 기능 세트, 도구 때문이라고 생각합니다. 그것이 나를 여기로 데려온 것이다. 언어 기능을 추가해도 그런 점에서 저에게는 아무 것도 바뀌지 않을 것입니다.

C#과 Typescript 또는 심지어 Rust/Swift를 보면. 그들은 미친 같은 새로운 기능을 추가하고 있습니다. C#은 여전히 ​​위아래로 변동하는 상위 언어입니다. Typescript는 매우 빠르게 성장하고 있습니다. Rust/Swift도 마찬가지입니다. 반면 바둑은 2009년과 2016년에 폭발적인 인기를 얻었습니다. 그러나 그 사이에는 전혀 성장하지 않았고 실제로 손실되었습니다. Go에 대해 이미 알고 있고 어떤 이유로 더 일찍 선택하지 않은 경우 Go는 새로운 개발자에게 줄 것이 없습니다. Go의 디자인이 정체되어 있기 때문입니다. 다른 언어가 기능을 추가하는 것은 다른 할 일이 없기 때문이 아니라 실제 사용자 기반에서 요구하기 때문입니다. 사람들은 코드 기반이 끊임없이 변화하는 문제 영역에서 관련성을 유지하기 위해 새로운 기능이 필요합니다. async/await처럼. 실제 문제를 해결하는 데 필요했습니다. 이제 많은 언어로 볼 수 있다는 것은 놀라운 일이 아닙니다.

결국에는 Go 2가 있을 것이며 많은 새로운 개발자를 가져올 것이라고 절대적으로 확신할 수 있습니다. 새롭고 빛나기 때문이 아니라 새로운 기능으로 인해 누군가가 마침내 전환하거나 사용해 볼 수 있기 때문입니다. 보수가 그렇게 중요했다면 우리는 이러한 제안을 했을 것입니다.

느린 성장(있는 경우)이 보수성 때문이 아니라 표준 라이브러리, 이미 존재하는 언어 기능 세트, 도구 때문이라고 생각합니다. 그것이 나를 여기로 데려온 것이다.

그리고 그것은 보수적인 태도의 결과입니다. 언어가 [반]년 정도마다 무언가/모든 것을 망가뜨린다면, 당신이 그것을 가져오는 사람이 훨씬 더 적기 때문에 당신이 바둑에 대해 당신이 가치 있다고 말하는 것을 아무것도 하지 않을 것입니다.

언어 기능을 추가해도 그런 점에서 저에게는 아무 것도 바뀌지 않을 것입니다.

당신은 그것에 대해 확신합니까? 위 참조.

BTW, 2017 설문 조사 결과 를 보셨습니까?

언어가 [반]년 정도마다 무언가/모든 것을 깨뜨리면

그런 다음 아무것도 부수지 마십시오. C#은 수많은 기능을 추가했으며 이전 버전과의 호환성을 위반한 적이 없습니다. 그들에게도 선택지가 아닙니다. C++도 마찬가지라고 생각합니다. Go가 무언가를 중단하지 않고 기능을 추가할 수 없다면 Go에 문제가 있고 아마도 구현 방법에 문제가 있을 수 있습니다.

BTW, 2017 설문 조사 결과를 보셨습니까?

내 의견은 2017/2018 설문 조사, TIOBE 지수 및 다양한 언어로 진행되는 상황에 대한 일반적인 관찰을 기반으로 합니다.

@cznic
모두가 그것들을 다루어야 하지만 당신은 그것들을 사용할 필요가 없습니다. iota 열거형 및 맵을 사용하여 코드를 작성하는 것을 선호하는 경우에도 이 작업을 수행할 수 있습니다. 그리고 제네릭이 마음에 들지 않는다면 제네릭이 없는 라이브러리를 사용하십시오. Java는 둘 다 가질 수 있음을 증명합니다.

그런 다음 아무것도 부수지 마십시오.

좋은 생각. 그러나 제안된 언어 변경의 대부분은 아닐지라도 _이것만 포함하여_ 많은 부분이 변경 사항을 깨고 있습니다.

C#은 수많은 기능을 추가했으며 이전 버전과의 호환성을 위반한 적이 없습니다.

사실을 확인하십시오: Visual C# 2010 주요 변경 사항 . (첫 번째 웹 검색 결과가 유일한 예인지 아닌지 짐작할 수 있습니다.)

내 의견은 2017/2018 설문 조사, TIOBE 지수 및 다양한 언어로 진행되는 상황에 대한 일반적인 관찰을 기반으로 합니다.

그렇다면 설문 조사 결과 응답자 수가 매년 70%씩 증가하는 것으로 나타났는데 언어가 증가하지 않는 것을 어떻게 알 수 있습니까?

"브레이킹 체인지"를 어떻게 정의합니까? 모든 go 코드 줄은 열거형이나 제네릭을 추가한 후에도 계속 작동합니다.

모두가 그것들을 다루어야 하지만 당신은 그것들을 사용할 필요가 없습니다. iota 열거형 및 맵을 사용하여 코드를 작성하는 것을 선호하는 경우에도 이 작업을 수행할 수 있습니다. 그리고 제네릭이 마음에 들지 않는다면 제네릭이 없는 라이브러리를 사용하십시오. Java는 둘 다 가질 수 있음을 증명합니다.

동의할 수 없습니다. 예를 들어 제네릭과 같은 언어가 나오면 내가 사용하지 않더라도 모든 곳에서 사용될 것입니다. 내부적으로 API를 변경하지 않는 경우에도. 그 결과 제네릭을 사용하는 프로그램의 빌드 속도를 늦추지 않고는 제네릭을 언어에 추가할 방법이 확실히 없기 때문에 제네릭의 영향을 많이 받습니다. 일명 "공짜 점심 없음".

"브레이킹 체인지"를 어떻게 정의합니까? 모든 go 코드 줄은 열거형이나 제네릭을 추가한 후에도 계속 작동합니다.

당연히 아니지. 이 코드는 이 제안으로 더 이상 컴파일되지 않습니다.

package foo

var enum = 42

필요하다는 단어는 "내가 원하는 것"을 의미하지 않습니다.

물론, 그것은 의미하지 않으며, 나는 결코 그것을 의미하지 않습니다. 물론 그런 기능은 필요없다고 대답할 수 있지만, 일반적으로 필요한 것만 대답할 수 있습니다. 아무것도 필요하지 않으며 펜과 종이로 돌아갈 수 있습니다.

Golang은 대규모 팀을 위한 언어라고 주장합니다. golang을 사용하여 대규모 코드 기반을 개발할 수 있는지 확실하지 않습니다. 이를 위해 가능한 한 런타임 오류를 피하기 위해 정적 컴파일 및 유형 검사가 필요합니다. 열거형과 제네릭 없이 어떻게 그렇게 할 수 있습니까? 이러한 기능은 화려하거나 좋은 것은 아니지만 진지한 개발에 절대적으로 필요한 기능입니다. 인터페이스가 없으면 모든 곳에서{} 인터페이스를 사용하게 됩니다. 코드에서 인터페이스를 사용해야 하는 경우{} 데이터 유형을 갖는 것이 무슨 의미가 있습니까?

물론 선택의 여지가 없다면 그렇게 할 것입니다. 그러나 이미 모든 것을 제공하고 golang보다 훨씬 더 빠른 실행을 제공하는 Rust와 같은 대안이 있다면 왜 선택해야 합니까? go가 다음과 같은 사고 방식을 가진 미래가 있는지 정말 궁금합니다.

필요하다는 단어는 "내가 원하는 것"을 의미하지 않습니다.

나는 오픈 소스에 대한 모든 기여를 존중하며 golang이 취미 프로젝트라면 어떤 것이든 괜찮지만 golang은 진지하게 받아들이기를 원하며 현재로서는 지루한 개발자를 위한 장난감에 가깝고 그것을 변경할 의지가 보이지 않습니다.

api는 변경할 필요가 없으며 새로운 api 부분만 제네릭을 사용할 수 있지만 인터넷에는 제네릭이 없는 대안이 항상 있을 수 있습니다.

그리고 둘 다 약간 느린 컴파일과 "enum"이라는 변수가 최소한의 효과입니다. 실제로 99%의 사람들은 알아차리지도 못하고 나머지 1%는 견딜 수 있는 약간의 작은 변화만 추가하면 됩니다. 이것은 예를 들어 자바의 퍼즐과 비교할 수 없습니다.

그리고 둘 다 약간 느린 컴파일과 "enum"이라는 변수가 최소한의 효과입니다. 실제로 99%의 사람들은 알아차리지도 못하고 나머지 1%는 견딜 수 있는 약간의 작은 변화만 추가하면 됩니다.

누군가가 그런 멋진 성능을 가진 디자인과 구현을 가지고 올 수 있다면 모두가 기뻐할 것입니다. #15292에 기여해 주세요.

그러나 이것이 "백킹 데이터가 전혀없는 내 호의로 숫자 뽑기"라는 게임이라면 죄송하지만 참여하지 않습니다.

제네릭과의 속도 차이에 대한 수치가 있습니까?

그리고 네, 그 숫자들은 어떤 데이터로도 뒷받침되지 않습니다. 왜냐하면 그것들은 단지 "열거형"이라는 변수를 가질 확률이 그리 높지 않다는 것을 말해주기 때문입니다.

열거형을 Go에 추가할지 여부와 방법에 대한 특정 질문에 대해 이 호를 구독하는 사람들이 많다는 것을 모두에게 상기시키고 싶습니다. "바둑은 좋은 언어입니까?"에 대한 일반적인 질문입니다. "Go가 기능 제공에 더 집중해야 합니까?" 다른 포럼에서 더 잘 논의될 것입니다.

제네릭과의 속도 차이에 대한 수치가 있습니까?

아니, 그래서 내가 아무 것도 게시하지 않았습니다. 나는 단지 비용이 0이 될 수 없다고 게시했습니다.

그리고 네, 그 숫자들은 어떤 데이터로도 뒷받침되지 않습니다. 왜냐하면 그것들은 단지 "열거형"이라는 변수를 가질 확률이 그리 높지 않다는 것을 말해주기 때문입니다.

섞인 것입니다. 감속은 제네릭에 관한 것이었습니다. "enum"은 이전 버전과의 호환성에 관한 것이고 false "_Every_ go 코드 줄은 열거형이나 제네릭을 추가한 후에도 계속 작동합니다." 주장하다. (나를 강조한다)

@Merovius 당신 말이 맞아요, 이제 입 다물겠습니다.

이것을 이 문제의 주제인 열거형 유형으로 다시 가져오면 Go에 제네릭이 필요한 이유에 대한 주장을 완전히 이해하지만 Go에 열거형 유형이 필요한 이유에 대한 주장에 대해서는 훨씬 더 불안정합니다. 사실, 위의 https://github.com/golang/go/issues/19814#issuecomment -290878151에서 질문했는데 여전히 불안합니다. 그것에 대한 좋은 대답이 있었다면 나는 그것을 놓쳤습니다. 누군가 그것을 반복하거나 지적할 수 있습니까? 감사 해요.

@ianlancetaylor 나는 유스 케이스가 복잡하다고 생각하지 않습니다. 값이 미리 정의된 값 세트에 속하도록 하는 안전한 유형의 방법을 원하기 때문입니다. 이는 오늘날 Go에서는 불가능합니다. 유일한 해결 방법은 본질적으로 신뢰할 수 없는 RPC 및 함수 호출을 포함하여 코드에 대한 모든 가능한 진입점에서 수동으로 유효성을 검사하는 것입니다. 반복을 위한 다른 구문상의 장점은 많은 일반적인 사용 사례를 더 쉽게 만듭니다. 가치가 있다는 것을 발견했는지 여부는 주관적이고 분명히 위의 주장 중 어느 것도 그 힘에 대해 설득력이 없었기 때문에 본질적으로 언어 수준에서 해결되는 것을 포기했습니다.

@ianlancetaylor : 모든 것은 유형 안전성과 관련이 있습니다. 유형을 사용하여 오타로 인한 런타임 오류의 위험을 최소화하거나 호환되지 않는 유형을 사용합니다. 현재 go에서 쓸 수 있습니다.

if enumReference == 1

현재 열거형은 숫자 또는 기타 기본 데이터 유형이기 때문입니다.

해당 코드는 전혀 가능하지 않아야 하며 피해야 합니다. 몇 년 전에 Java 커뮤니티에서 했던 것과 동일한 토론이 그들이 중요성을 이해했기 때문에 열거형을 도입한 이유입니다.

만 쓸 수 있어야 합니다.

if enumReference == enumType

if enumReference == 1 가 더 숨겨진 방식으로 발생하고 런타임에만 볼 수 있는 추가 문제로 이어질 수 있는 시나리오를 상상하는 데 너무 많은 환상이 필요하지 않습니다.

나는 단지 언급하고 싶다: Go는 그것의 잠재력을 가지고 있지만, 당신이 프로그래밍의 새로운 개념이나 패러다임에 대해 논의하는 것처럼 여기에서 수년 동안 입증되고 이해된 것들과 개념이 논의된다는 것이 이상합니다. 유형 안전성을 보장하는 다른 방법이 있다면 열거형보다 더 나은 것이 있을 수 있지만 나는 그것을 보지 못합니다.

Go는 잠재력이 있지만 프로그래밍의 새로운 개념이나 패러다임에 대해 논의하는 것처럼 여기에서 수년 동안 입증되고 이해된 것들과 개념이 논의된다는 것이 이상합니다.

Afais, 특히 제네릭, 합계 유형 등에 대한 다른 토론을 따르는 동안... 그것은 보유 여부가 아니라 구현 방법에 관한 것입니다. Javas 유형 시스템은 확장성이 뛰어나고 사양이 잘 지정되어 있습니다. 그것은 큰 차이입니다.

Go에서 사람들은 컴파일러의 복잡성을 증가시키지 않으면서 언어에 기능을 추가하는 방법을 찾으려고 합니다. 그것은 일반적으로 잘 작동하지 않으며 초기 아이디어를 포기하게 만듭니다.

나 역시 이러한 우선 순위가 현재의 형식과 품질에서 다소 무의미하다고 생각하지만 가장 좋은 방법은 가능한 가장 간단하고 방해가 적은 구현을 찾는 것 입니다. 다른 것은 더 이상 얻을 수 없습니다.

@derekperkins @rudolfschmidt 감사합니다. C++에 열거형 유형이 있지만 제안하는 기능은 C++에 없다는 점을 분명히 하고 싶습니다. 그래서 이것에 대해 분명한 것은 없습니다.,

일반적으로 열거형 유형의 변수가 해당 열거형의 값만 받아들일 수 있다면 그것은 쓸모가 없을 것입니다. 특히 임의의 정수에서 열거형 유형으로의 변환이 있어야 합니다. 그렇지 않으면 네트워크 연결을 통해 열거형을 보낼 수 없습니다. 글쎄, 할 수는 있지만 각 열거형 값에 대해 대소문자가 있는 스위치를 작성해야 하므로 정말 지루해 보입니다. 따라서 변환을 수행할 때 컴파일러는 유형 변환 중에 값이 유효한 열거형 값인지 확인하는 것을 생성합니까? 값이 유효하지 않으면 당황합니까?

열거형 값은 순차적이어야 합니까, 아니면 C++에서와 같이 모든 값을 가질 수 있습니까?

Go에서 상수는 유형이 없으므로 정수에서 열거형으로의 변환을 허용하면 if enumVal == 1 를 금지하는 것이 이상할 것입니다. 하지만 우리는 할 수 있다고 생각합니다.

Go의 일반적인 디자인 원칙 중 하나는 Go를 작성하는 사람들이 유형이 아니라 코드를 작성한다는 것입니다. 코드를 작성할 때 도움이 되는 열거형 유형의 이점은 아직 보지 못했습니다. 그들은 우리가 일반적으로 Go에 없는 종류의 유형 제약 세트를 추가하는 것 같습니다. 좋든 나쁘든 Go는 유형의 값을 제어하는 ​​메커니즘을 제공하지 않습니다. 따라서 Go에 열거형을 추가하는 것에 찬성하는 주장은 아직 설득력이 없어 보입니다.

다시 말하지만 열거형을 오늘날과 같이 유지하고 그 위에 기능을 추가하는 것을 선호합니다.

• enum 유형에는 기본 값 유형과 연관된 몇 가지 명명된 상수가 있습니다.
• 컴파일러는 기본 유형이 호환되는 한 임의 값에서 열거형 값으로의 변환을 허용해야 합니다. int 유형의 값은 모든 정수 열거형 유형으로 변환할 수 있어야 합니다.
• 유효하지 않은 열거형 값으로 이어지는 변환이 허용됩니다. 열거형은 변수가 취할 수 있는 값에 제약을 두어서는 안 됩니다.

그 위에 제공하는 것은 다음과 같습니다.

• 열거형 값의 문자열화. 내 경험상 UI 및 로깅에 매우 유용합니다. 열거형 값이 유효하면 문자열화는 상수의 이름을 반환합니다. 유효하지 않은 경우 기본 값의 문자열 표현을 반환합니다. -1 가 일부 열거형 유형 Foo 의 유효한 열거형 값이 아닌 경우 문자열화는 -1 를 반환해야 합니다.
• 개발자가 값이 런타임에 유효한 열거형 값인지 결정할 수 있도록 합니다. 모든 유형의 프로토콜로 작업할 때 매우 유용합니다. 프로토콜이 발전함에 따라 프로그램이 알지 못하는 새로운 열거형 값이 도입될 수 있습니다. 아니면 단순한 실수일 수도 있습니다. 지금 당장은 열거형 값이 엄격하게 순차적인지 확인하거나(항상 시행할 수 있는 것이 아님) 가능한 모든 값을 수동으로 확인해야 합니다. 그런 종류의 코드는 매우 빠르게 커지고 실수가 발생할 수 있습니다.
• 개발자가 열거형 유형의 가능한 모든 값을 열거할 수 있습니다. 나는 사람들이 여기에서 이것을 요구하는 것을 보았고 다른 언어에도 이것을 가지고 있지만 실제로 나 자신이 그것을 필요로 한 기억이 없으므로 이에 찬성하는 개인적인 경험이 없습니다.

내 정당성은 코드를 작성하고 버그를 피하는 것입니다. 이러한 모든 작업은 개발자가 손으로 수행하거나 코드를 복잡하게 만들고 스크립트를 작성하는 외부 도구를 도입하기까지 지루하고 불필요합니다. 이러한 기능은 열거형을 지나치게 복잡하고 제한하지 않으면서 필요한 모든 것을 다룹니다. 나는 Go가 Swift나 Java의 열거형과 같은 것을 필요로 하지 않는다고 생각합니다.

switch 문이 가능한 모든 열거형 값을 포함하는지 컴파일 타임에 검증하는 것에 대한 논의가 있었습니다. 내 제안으로는 아무 소용이 없습니다. 소진 검사를 수행해도 유효하지 않은 열거형 값은 다루지 않으므로 이를 처리하려면 기본 케이스가 있어야 합니다. 이는 점진적인 코드 복구를 지원하는 데 필요합니다. 여기서 우리가 할 수 있는 일은 switch 문에 기본 케이스가 없으면 경고를 생성하는 것뿐입니다. 그러나 그것은 언어를 변경하지 않고도 할 수 있습니다.

@ianlancetaylor 나는 당신의 주장에 몇 가지 결함이 있다고 생각합니다.

일반적으로 열거형 유형의 변수가 해당 열거형의 값만 받아들일 수 있다면 그것은 쓸모가 없을 것입니다. 특히 임의의 정수에서 열거형 유형으로의 변환이 있어야 합니다. 그렇지 않으면 네트워크 연결을 통해 열거형을 보낼 수 없습니다.

프로그래머를 위한 추상화는 괜찮습니다. Go 는 많은 추상화를 제공합니다. 예를 들어 다음 코드는 컴파일되지 않습니다.

package main

import "fmt"

const NULL = 0x0

func main() {
    str := "hello"
    if &str == NULL {
        fmt.Println("str is null")
    }
}

그러나 C 에서는 이 스타일의 프로그램이 컴파일됩니다. Go 는 강력한 형식이고 C 는 그렇지 않기 때문입니다.

열거형의 인덱스는 내부적으로 저장될 수 있지만 변수의 주소와 유사한 추상화로 사용자에게 숨겨집니다.

@zerkms 예, 그것은 하나의 가능성이지만 d 유형이 주어지면 유형 추론이 가능해야 합니다. 그러나 (귀하의 예에서와 같이) 열거형의 정규화된 사용은 읽기가 조금 더 쉽습니다.

@ianlancetaylor 당신이 말하는 열거형의 C 버전입니다. 나는 많은 사람들이 그것을 원하지만, imo:

열거형 값에는 숫자 속성이 없어야 합니다. 각 열거형 유형의 값은 숫자나 다른 열거형 유형과 관련이 없는 컴파일 시간에 적용되는 개별 레이블의 고유한 유한한 유니버스여야 합니다. 이러한 값 쌍으로 할 수 있는 유일한 것은 == 또는 != 입니다. 다른 작업은 메서드 또는 함수로 정의할 수 있습니다.

구현은 해당 값을 정수로 컴파일하지만 안전하지 않거나 반사를 제외하고 프로그래머에게 직접 노출되어야 하는 정당한 이유가 있는 근본적인 것은 아닙니다. 같은 이유로 false bool(0) 를 할 수 없습니다.

열거형을 숫자나 다른 유형으로 변환하려면 모든 케이스를 작성하고 상황에 적합한 오류 처리를 포함합니다. 그것이 지루하다면 스트링거와 같은 코드 생성기를 사용하거나 적어도 switch 문의 경우를 채우기 위해 무언가를 사용합니다.

프로세스 외부로 값을 보내는 경우 잘 정의된 표준을 따르거나 소스에서 컴파일된 프로그램의 다른 인스턴스와 대화하고 있거나 무언가를 만들어야 하는 경우 int가 좋습니다. 문제를 일으킬 수 있는 경우에도 가능한 한 가장 작은 공간에 적합하지만 일반적으로 이들 중 어느 것도 유지되지 않으며 값이 유형 정의의 소스 순서에 영향을 받지 않도록 문자열 표현을 사용하는 것이 좋습니다. 다른 누군가가 정의에서 알파벳순으로 유지하기 위해 Blue가 Green 앞에 추가되어야 한다고 결정했기 때문에 프로세스 A의 Green이 프로세스 B의 Blue가 되는 것을 원하지 않습니다. 당신은 unrecognized color "Blue" 를 원합니다.

여러 상태를 추상적으로 나타내는 좋은 안전한 방법입니다. 이러한 상태가 의미하는 바를 정의하는 것은 프로그램을 떠나는 것입니다.

(물론 종종 데이터를 해당 상태와 연결하고 해당 데이터의 유형은 상태마다 다릅니다. . .)

@ljeabmreosn 내 요점은 Go가 정수에서 열거형 유형으로 변환을 허용한다면 유형이 지정되지 않은 상수가 자동으로 열거형 유형으로 변환되는 것이 당연하다는 것입니다. Go는 정수에서 포인터 유형으로의 변환을 허용하지 않기 때문에 반대 예는 다릅니다.

@jimmyfrasche 정수와 열거형 사이를 변환하는 스위치를 작성해야 한다면 Go에서 깔끔하게 작동할 것이라는 데 동의하지만 솔직히 언어 자체에 추가하는 것은 충분히 유용하지 않은 것 같습니다. 합계 유형의 특별한 경우가 되며, 이에 대해서는 #19412를 참조하십시오.

여기에 많은 제안이 있습니다.

일반적인 의견: 열거형에 대해 변환하거나 변환할 수 있는 기본 값(예: int)을 노출하지 않는 제안에 대해 답변해야 할 몇 가지 질문이 있습니다.

열거형 유형의 0 값은 무엇입니까?

한 열거형에서 다른 열거형으로 어떻게 이동합니까? 나는 많은 사람들에게 요일이 열거형의 정식 예라고 생각하지만 수요일에서 목요일로 "증가"하고 싶을 수도 있습니다. 나는 그것을 위해 큰 switch 문을 작성하고 싶지 않을 것입니다.

(또한 "문자열화"와 관련하여 요일에 대한 올바른 문자열은 언어 및 로케일에 따라 다릅니다.)

@josharian stringification은 일반적으로 열거형 값의 이름을 컴파일러가 자동으로 문자열로 변환하는 것을 의미합니다. 현지화 또는 아무것도 없습니다. 로컬라이제이션과 같은 그 위에 무언가를 구축하려는 경우 다른 수단을 사용하여 수행하고 다른 언어는 이를 수행할 수 있는 풍부한 언어 및 프레임워크 도구를 제공합니다.

예를 들어 일부 C# 유형에는 문화 정보도 사용하는 ToString 재정의가 있습니다. 또는 DateTime 개체 자체를 사용하고 형식 및 문화 정보를 모두 허용하는 ToString 메서드를 사용할 수 있습니다. 그러나 이러한 재정의는 표준이 아닙니다. 모든 사람이 상속하는 $#$4$ object 클래스에는 ToString() 있습니다. Go의 스트링거 인터페이스와 거의 비슷합니다.

따라서 현지화는 일반적으로 이 제안과 열거에서 벗어나야 한다고 생각합니다. 구현하고 싶다면 다른 방법으로 수행하십시오. 예를 들어 사용자 정의 스트링거 인터페이스와 같습니다.

@josharian 구현 측면에서 여전히 int이고 0 값은 모든 비트가 0이므로 0 값은 소스 순서의 첫 번째 값이 됩니다. 예를 들어 월요일 또는 일요일에 한 주가 시작되는지 여부를 결정하는 0 값을 선택할 수 있기 때문에 실제로는 꽤 좋습니다. 물론, 나머지 항의 순서가 그런 영향을 미치지 않고 값을 재정렬하는 것이 첫 번째 요소를 변경하면 사소하지 않은 영향을 미칠 수 있다는 것은 덜 좋은 일입니다. 그러나 이것은 실제로 const/iota와 다르지 않습니다.

@creker 가 말한 것을 다시 문자열화하십시오. 확장하려면

var e enum {
  Sunday
  Monday
  //etc.
}
fmt.Println(reflect.ValueOf(e))

일요일을 인쇄하려면 0이 아닙니다. 레이블은 표시가 아니라 값입니다.

분명히 하기 위해 암시적 String 메서드가 있어야 한다고 말하는 것이 아닙니다. 레이블이 유형의 일부로 저장되고 리플렉션을 통해 액세스할 수 있다는 것뿐입니다. (아마도 Println은 열거형이나 이와 유사한 것에서 반사.Value에 대해 Label()을 호출합니까? fmt가 부두를 수행하는 방법에 대해 깊이 살펴보지 않았습니다.)

한 열거형에서 다른 열거형으로 어떻게 이동합니까? 나는 많은 사람들에게 요일이 열거형의 정식 예라고 생각하지만 수요일에서 목요일로 "증가"하고 싶을 수도 있습니다. 나는 그것을 위해 큰 switch 문을 작성하고 싶지 않을 것입니다.

리플렉션이나 큰 스위치가 맞는 것 같아요. 일반 패턴은 해당 유형의 팩토리 함수 또는 유형에 대한 메소드를 생성하기 위해 go generate로 쉽게 채워질 수 있습니다(그리고 아마도 컴파일러가 이를 표현에 대한 산술 연산으로 낮추기 위해 인식할 수도 있음).

모든 열거형에 전체 순서가 있거나 순환적이라고 가정하는 것은 의미가 없습니다. type failure enum { none; input; file; network } 가 주어지면 잘못된 입력이 파일 오류보다 적거나 파일 오류를 늘리면 네트워크 오류가 발생하거나 네트워크 오류를 늘리면 성공하게 되는 것이 정말 의미가 있습니까?

주요 용도가 순환 순서 값을 위한 것이라고 가정하면 이를 처리하는 또 다른 방법은 매개변수화된 정수 유형의 새 클래스를 만드는 것입니다. 이것은 잘못된 구문이지만 토론을 위해 I 가 정수 유형이고 N 가 정수 상수인 I%N 라고 가정해 보겠습니다. 이 유형의 값을 가진 모든 산술은 암시적으로 mod N입니다. 그러면 다음을 수행할 수 있습니다.

type Weekday uint%7
const (
  Sunday Weekday = iota
  //etc.

그래서 토요일 + 1 == 일요일 및 평일(456) == 월요일. 유효하지 않은 요일을 구성하는 것은 불가능합니다. 그러나 const/iota 외부에서 유용할 수 있습니다.

@ianlancetaylor 가 내가 정말로 원하는 것은 합계 유형이라고 지적했듯이 숫자 y를 전혀 원하지 않을 때.

임의의 모듈식 산술 유형을 도입하는 것은 흥미로운 제안입니다. 그러면 열거형은 다음과 같은 형식이 될 수 있습니다. 그러면 간단한 String 메서드를 얻을 수 있습니다.

var Weekdays = [...]string{"Sunday", ..., "Saturday"}

type Weekday = uint % len(Weekdays)

임의의 크기의 int와 결합하면 int128, int256 등도 얻을 수 있습니다.

몇 가지 내장 기능을 정의할 수도 있습니다.

type uint8 = uint%(1<<8)
// etc

컴파일러는 이전보다 더 많은 범위를 증명할 수 있습니다. 그리고 API는 유형을 통해 보다 정확한 어설션을 제공할 수 있습니다. 예를 들어 math/bits 의 함수 Len64 $는 이제 uint % 64 를 반환할 수 있습니다.

RISC-V 포트에서 작업할 때 명령어 인코딩 구성 요소가 12비트이기 때문에 uint12 유형을 원했습니다. uint % (1<<12) 수 있습니다. 많은 비트 조작, 특히 프로토콜에서 이점을 얻을 수 있습니다.

물론 단점도 상당합니다. Go는 유형보다 코드를 선호하는 경향이 있으며 이는 유형이 많습니다. + 및 -와 같은 연산은 갑자기 %만큼 비용이 많이 들 수 있습니다. 어떤 종류의 유형 매개변수가 없으면 거의 모든 라이브러리 기능과 상호 운용하기 위해 표준 uint8 , uint16 등으로 변환해야 하며 다시 변환하면 경계를 숨길 수 있습니다. 실패(자체 복잡성을 도입하는 범위를 벗어난 패닉 변환을 수행할 방법이 없는 경우). 그리고 HTTP 상태 코드에 uint % 1000 를 사용하는 것과 같이 과도하게 사용되는 것을 볼 수 있습니다.

그럼에도 불구하고 흥미로운 아이디어입니다. :)

기타 사소한 답변:

그것은 일종의 내면을 누설하는 것입니다.

이것은 그들이 정말로 int라고 생각하게 만듭니다. :)

일반적인 패턴은 go generate로 쉽게 채울 수 있습니다.

어쨌든 열거형으로 코드를 생성해야 하는 경우 String 함수 및 경계 검사 등을 생성하고 언어 지원의 무게 대신 코드 생성으로 열거형을 수행할 수 있을 것 같습니다.

모든 열거형에 전체 순서가 있거나 순환적이라고 가정하는 것은 의미가 없습니다.

그럴 수 있지. 이것은 소수의 구체적인 사용 사례를 갖는 것이 우리가 열거형에서 원하는 것을 정확히 명확하게 하는 데 도움이 될 것이라고 생각하게 만듭니다. 명확한 요구 사항이 없을 것이며 다른 언어 구성(즉, 현상 유지)을 사용하여 열거형을 에뮬레이트하는 것이 가장 합리적일 것이라고 생각합니다. 그러나 그것은 가설일 뿐입니다.

@creker 가 말한 것을 다시 문자열화하십시오.

그럴 수 있지. 그러나 얼마나 많은 경우가 요일과 같을지 궁금합니다. 확실히 사용자가 대면하는 모든 것. 그리고 문자열화는 열거형에 대한 주요 요청 중 하나인 것 같습니다.

@josharian 실제로 int인 열거형은 아마도 비슷한 메커니즘이 필요할 것입니다. 그렇지 않으면 enum { A; B; C}(42) 는 무엇입니까?

컴파일러 오류라고 말할 수 있지만 런타임에 int로 변환하거나 int에서 변환할 수 있으므로 더 복잡한 코드에서는 작동하지 않습니다.

A 또는 런타임 패닉입니다. 두 경우 모두 제한된 도메인이 있는 정수 유형을 추가합니다. 런타임 패닉인 경우 다른 항목이 둘러싸일 때 오버플로 패닉이 발생하는 정수 유형을 추가하는 것입니다. A라면 몇 가지 의식으로 uint%N을 추가한 것입니다.

다른 옵션은 A, B 또는 C 중 어느 것도 허용하지 않는 것이지만 이것이 오늘날 const/iota를 사용하는 것이므로 이득이 없습니다.

int%N이라고 말하는 모든 이유는 int인 열거형에도 똑같이 적용되는 것처럼 보입니다. (하지만 그들과 같은 것이 포함된다면 나는 화를 내지 않을 것입니다).

순수함을 없애면 그 수수께끼가 사라집니다. 일부 int-iness를 다시 추가하려는 경우 코드 생성이 필요하지만 그렇게 하지 않을 수도 있습니다. 이를 통해 도입할 int-iness의 정도와 종류를 제어할 수 있습니다. no "를 추가할 수 있습니다. next" 메서드, 순환적 next 메서드, 가장자리에서 떨어지면 오류를 반환하는 next 메서드. (또한 Monday*Sunday - Thursday 가 합법화되는 것으로 끝나지 않습니다.) 추가 강성으로 인해 더 가단성 있는 건축 자재가 됩니다. 판별된 공용체는 무엇보다도 pick { A, B, C struct{} } 와 같이 int-y가 아닌 다양성을 멋지게 모델링합니다.

이와 같은 정보를 언어로 제공하는 것의 주요 이점은 다음과 같습니다.

1. 잘못된 값은 불법입니다.
2. 정보는 반영할 수 있고 프로그램이 가정이나 주석(현재 반영할 수 없음) 없이 이에 대해 조치를 취할 수 있도록 하는 이동/유형을 사용할 수 있습니다.

언어로 이와 같은 정보를 제공하는 주요 이점은 다음과 같습니다. 잘못된 값은 불법입니다.

모든 사람이 이것을 이점으로 보는 것은 아니라는 점을 강조하는 것이 중요하다고 생각합니다. 나는 확실히하지 않습니다. 값을 소비할 때는 더 쉽게 만들지만 값을 생성할 때는 더 어렵게 만드는 경우가 많습니다. 어느 쪽이 더 무거울지는 지금까지는 개인의 취향에 달려 있는 것 같습니다. 따라서 이것이 전체적으로 순 이익인지 여부에 대한 질문도 마찬가지입니다.

또한 불법적인 값을 허용하지 않는 것이 중요하다고 생각하지 않습니다. 유효성을 스스로 확인할 수단이 이미 있는 경우(위의 제안에서와 같이), 그 제한이 주는 이점은 무엇입니까? 나에게 그것은 일을 복잡하게 할 뿐입니다. 내 응용 프로그램에서 대부분의 경우 열거형에는 유효하지 않거나 알 수 없는 값이 포함될 수 있으며 응용 프로그램에 따라 이 문제를 해결해야 했습니다. 완전히 폐기하거나 일부 기본값으로 다운그레이드하거나 그대로 저장해야 합니다.

잘못된 값을 허용하지 않는 엄격한 열거형은 앱이 외부 세계와 격리되어 있고 잘못된 입력을 받을 방법이 없는 매우 제한된 경우에 유용할 수 있다고 생각합니다. 자신만 보고 사용할 수 있는 내부 열거형과 같습니다.

iota를 사용하는 const는 컴파일 시간에 안전하지 않고 검사는 런타임으로 지연되며 안전한 검사는 유형 수준이 아닙니다. 그래서 저는 iota가 enum을 문자 그대로 대체할 수 없다고 생각합니다. 저는 enum이 더 강력하기 때문에 enum을 선호합니다.

잘못된 값은 불법입니다.
모든 사람이 이것을 이점으로 보는 것은 아니라는 점을 강조하는 것이 중요하다고 생각합니다.

저는 이 논리가 이해가 되지 않습니다. 유형은 값의 집합입니다. 값이 해당 유형에 없는 변수에는 유형을 할당할 수 없습니다. 내가 뭔가 오해하고 있는 걸까?

추신: 열거형은 합계 유형의 특별한 경우이며 그 문제가 이 문제보다 우선해야 한다는 데 동의합니다.

다시 말해서/좀 더 정확하게 하자면 모든 사람이 열거형을 닫는 데 이점이 있다고 생각하는 것은 아닙니다.

그런 식으로 엄격하기를 원한다면 a) "잘못된 값은 불법입니다"는 동어반복이고 b) 따라서 이점으로 간주될 수 없습니다. const 기반 열거형을 사용하면 해석상 잘못된 값도 불법입니다. 유형은 훨씬 더 많은 값을 허용합니다.

열거형이 int이고 모든 int가 적법한 경우(유형 시스템의 관점에서) 유일한 이점은 유형의 명명된 값이 반영된다는 것입니다.

그것은 기본적으로 단지 const/iota이지만 fmt 패키지가 리플렉션을 사용하여 이름을 가져올 수 있기 때문에 스트링거를 실행할 필요가 없습니다. (원본에 있는 이름과 문자열을 다르게 하려면 여전히 stringer를 실행해야 합니다.)

@jimmyfrasche 문자열 화는 좋은 보너스입니다. 위의 제안에서 읽을 수 있듯이 저에게 주요 기능은 런타임에 주어진 값이 주어진 열거형 유형의 유효한 값인지 확인하는 기능입니다.

예를 들어 다음과 같이 주어진

type Foo enum {
    Val1 = 1
    Val2 = 2
}

그리고 반사 방법은 다음과 같습니다.

func IsValidEnum(v {}interface) bool

우리는 다음과 같이 할 수 있습니다.

a := Foo.Val1
b := Foo(-1)
reflection.IsValidEnum(a) //returns true
reflection.IsValidEnum(b)  //returns false

실제 사례의 경우 Java가 수행한 것을 맹목적으로 따르는 대신 이 중간 지점을 완벽하게 포착한 C#의 열거형 을 볼 수 있습니다. C#에서 유효성을 확인하려면 Enum.IsDefined static method 를 사용합니다.

@crecker 그것과 const/iota의 유일한 차이점은
반사에 저장된 정보. 전체적으로 큰 이득은 아니다
새로운 유형의 유형.

약간 미친 아이디어:

동일한 패키지에 선언된 모든 const의 이름과 값을 저장합니다.
반영할 수 있는 방식으로 정의된 유형으로. 그것은
그러나 좁은 클래스의 const 사용법을 골라내는 것은 이상합니다.

위의 내 제안에서 읽을 수 있듯이 나를 위한 주요 기능

IMO는 이 논의를 끌고 있는 주요 사항 중 하나를 보여줍니다. "주요 기능" 집합이 무엇인지에 대한 명확성이 부족합니다. 사람들마다 그것에 대해 약간 다른 생각을 가지고 있는 것 같습니다.
개인적으로 나는 여전히 그 세트를 발견하기 위한 경험 보고서 의 형식을 좋아합니다. 목록에 하나가 있습니다(개인적으로는 "잘못된 것" 섹션이 실제로 발생한 것이 아니라 잘못 될 수 있는 것에 대해서만 언급한다는 사실에 여전히 언급하고 싶습니다). 유형 검사의 부족으로 인해 중단/버그가 발생하거나 예를 들어 대규모 리팩토링을 수행하지 못하는 경우를 설명하는 몇 가지를 추가하면 도움이 될 것입니다.

@jimmyfrasche 하지만 입력 데이터의 유효성을 검사하는 많은 응용 프로그램의 큰 문제를 해결합니다. 유형 시스템의 도움 없이는 수동으로 수행해야 하며 몇 줄의 코드로 수행할 수 있는 작업이 아닙니다. 일종의 유형 지원 유효성 검사를 사용하면 이를 해결할 수 있습니다. 그 위에 문자열화를 추가하면 기본 유형 값이 아닌 올바른 형식의 이름을 갖게 되므로 로깅이 단순화됩니다.

반면에 열거형을 엄격하게 만들면 가능한 사용 사례가 심각하게 제한됩니다. 예를 들어 이제 프로토콜에서 쉽게 사용할 수 없습니다. 유효하지 않은 값도 보존하려면 열거형을 삭제하고 일반 값 유형을 사용해야 하며, 필요한 경우 나중에 열거형으로 변환할 수 있습니다. 경우에 따라 잘못된 값을 삭제하고 오류가 발생할 수 있습니다. 다른 경우에는 일부 기본값으로 다운그레이드할 수 있습니다. 어느 쪽이든, 당신은 오류를 피하는 데 도움이 되는 대신 유형 시스템의 제한과 싸우고 있습니다.

Java 열거형 문제를 해결하기 위해 Java용 protobuf가 생성해야 하는 것을 살펴보십시오.

유효성 검사와 관련하여 @Merovius 는 이미 여러 번 다루었다고 생각합니다. 유효성 검사 없이는 입력 유효성을 검사하기 위해 엄청난 양의 복사-붙여넣기 코드를 작성해야 합니다. 문제는 분명하며 제안된 솔루션이 이를 어떻게 도울 수 있는지도 알 수 있습니다. 저는 모든 사람이 알고 있는 대규모 응용 프로그램에서 작업하지 않지만 해당 유효성 검사 코드의 오류가 동일한 열거형 개념을 사용하여 여러 언어로 여러 번 저를 물었습니다.

반면에 잘못된 값을 허용하지 않는 열거형을 구현하는 데 찬성하는 어떤 주장도 볼 수 없습니다(뭔가 놓친 경우 사과). 이론상으로는 멋지고 깔끔하지만 실제 응용 프로그램에서는 도움이 되지 않는 것 같습니다.

사람들이 열거형에서 원하는 기능은 그리 많지 않습니다. 문자열화, 유효성 검사, 유효하지 않은 값 측면에서 엄격/느슨함, 열거 - 내가 볼 수 있는 것과 거의 비슷합니다. 모두 (물론 나를 포함하여)이 시점에서 그것들을 섞습니다. 엄격함/느슨함은 상충되는 성격 때문에 주요 논쟁거리인 것 같습니다. 나는 모든 사람이 하나 또는 다른 것에 동의하지 않을 것이라고 생각합니다. 어쩌면 해결책은 둘 다 어떤 식으로든 통합하고 프로그래머가 선택하도록 하는 것일 수 있지만 실제 세계에서 어떻게 작동하는지 볼 수 있는 언어가 있는지 모르겠습니다.

@crecker 위의 내보내기 데이터에 const를 저장하라는 내 제안
상황은 당신이 요구하는 종류의 것을 허용합니다
새로운 종류의 도입 없이.

이것이 관용적 방법인지 확실하지 않으며 언어도 처음이지만 다음은 작동하고 간결합니다.

type Day struct {
    value string
}

// optional, if you need string representation
func (d Day) String() string { return d.value }

var (
    Monday = Day{"Monday"}
    Tuesday = Day{"Tuesday"}
)

func main() {
    getTask(Monday)
}

func getTask(d Day) string {
    if d == Monday {
        fmt.Println("today is ", d, "!”) // today is Monday !
        return "running"
    }

    return "nothing to do"
}

장점 :

• type Day func getTask 에 전달할 수 없습니다.
  https://play.golang.org/p/4JZOIG5PbRX

• 값을 재정렬해도 코드가 손상되지 않습니다( 대신 iota 가 까다롭습니다)

• 코드 생성기가 필요 없음

• 지도와 함께 사용할 수 있습니다
  https://play.golang.org/p/KlTNWrJpbDi

• 반복될 수 있다
  https://play.golang.org/p/ld3TNtenEkD

단점 :

• 컴파일러가 불평하지 않고 익명 구조체를 getTask 에 전달할 수 있습니다.
  https://play.golang.org/p/NaV38og7e2h

• 상수 구조체는 지원되지 않으며 var 만 지원됩니다.
  https://play.golang.org/p/X6KSpACA4N0

열거형이 정말로 필요합니까?

누군가가 다음과 같은 일을 하지 못하도록 막는 것:

NotADay := Day{"NotADay"}
getTask(NotADay)

그러한 변수의 소비자는 예상 값을 적절하게 확인하여 이를 포착할 수도 있고 포착하지 못할 수도 있습니다(예를 들어 토요일이나 일요일이 아닌 것은 평일인 것처럼 switch 문의 가정을 통해 나쁜 하락이 없다고 가정). 런타임까지. 런타임이 아닌 컴파일 타임에 이런 유형의 실수를 잡는 것이 더 좋을 것 같습니다.

@bpkroth
자체 패키지에 Day 이 있고 선택한 필드 및 메서드만 노출하면 package day Day 유형의 새 값을 만들 수 없습니다.
또한 이 방법으로 익명 구조체를 getTask 에 전달할 수 없습니다.

./day/day.go

package day

type Day struct {
    value string
}

func (d Day) String() string { return d.value }

var (
    Monday  = Day{"Monday"}
    Tuesday = Day{"Tuesday"}
    Days    = []Day{Monday, Tuesday}
)

./main.go

package main

import (
    "fmt"
    "github.com/somePath/day"
)

func main() {
    january := day.Day{"january"} // implicit assignment of unexported field 'value' in day.Day literal

    var march struct {
        value string
    }
    march.value = "march"
    getTask(march) // cannot use march (type struct { value string }) as type day.Day in argument to getTask

    getTask(day.Monday)
}

func getTask(d day.Day) string {
    if d == day.Monday {
        fmt.Println("today is ", d, "!") // today is Monday !
        return "running"
    }

    return "nothing to do"
}

func iterateDays() {
    for _, d := range day.Days {
        fmt.Println(d)
    }
}

열거형, 삼항 연산자, 사용하지 않는 변수를 사용한 컴파일, 합계 유형, 제네릭, 기본 매개변수 등과 같은 가장 간단하고 유용한 기능을 추가하지 않을 것을 주장하는 다른 언어는 평생 본 적이 없습니다.

Golang은 개발자가 얼마나 멍청할 수 있는지 알아보기 위한 사회적 실험입니까?

@gh67uyyghj 누군가 귀하의 댓글을 주제가 아닌 것으로 표시했습니다! 누군가 내 대답에 똑같이 할 것이라고 생각합니다. 하지만 귀하의 질문에 대한 대답은 YES라고 생각합니다. GoLang에서 기능이 없다는 것은 기능이 있다는 것을 의미하므로 GoLang에 없는 모든 기능은 실제로 다른 프로그래밍 언어에는 없는 GoLang의 기능입니다!!

@L-oris 이것은 열거형을 유형으로 구현하는 매우 흥미로운 방법입니다. 그러나 어색하게 느껴지며 enum 키워드(필연적으로 언어를 좀 더 복잡하게 함)를 사용하면 다음을 더 쉽게 수행할 수 있습니다.

• 쓰다
• 읽다
• 이유

귀하의 예에서 (오늘날 작동하기 때문에 훌륭함) 열거 형 (어떤 형태로든)을 갖는 것은 다음이 필요함을 의미합니다.

• 구조체 유형 만들기
• 메소드 생성
• 변수 생성(라이브러리 사용자는 해당 값을 변경할 수 없지만 상수는 제외)

이것은 읽고, 쓰고, 추론하는 데 더 오래 걸립니다(훨씬 더 길지는 않지만).

따라서 구문 제안은 언어에 단순성과 부가 가치 측면에서 올바른 메모를 제공한다고 생각합니다.

@andradei 감사합니다
예, 해결 방법이지만 언어의 목표는 작고 단순하게 유지하는 것입니다.
수업을 놓치고 있다고 주장할 수도 있지만 Java로 이동해 보겠습니다. :)

차라리 Go 2 제안, 더 나은 오류 처리에 집중하고 싶습니다. 이 열거 형보다 더 많은 가치를 제공 할 것입니다.

귀하의 요점으로 돌아가기:

• 그렇게 많은 상용구는 아닙니다. 최악의 경우 생성기를 가질 수 있습니다(하지만 실제로 그렇게 많은 코드가 있습니까?)
• 새 키워드를 추가하여 얼마나 많은 "단순성"을 달성하고 있으며, 이 키워드가 가질 수 있는 전체 특정 동작 세트는 무엇입니까?
• 방법을 조금 창의적으로 사용하면 해당 열거형에 흥미로운 기능을 추가할 수도 있습니다.
• 가독성을 위해 익숙해지는 것이 더 중요합니다. 그 위에 주석을 추가하거나 변수에 접두사를 붙일 수 있습니다.

package day

// Day Enum
type Day struct {
    value string
}

@L-oris 알겠습니다. Go 2의 제안도 기대됩니다. 나는 제네릭이 열거형보다 언어의 복잡성을 더 증가시킬 것이라고 주장합니다. 그러나 귀하의 요점을 고수하려면 다음을 수행하십시오.

• 실제로 그렇게 많은 상용구가 아닙니다.
• 열거형의 개념이 얼마나 잘 알려진 것인지 확인해야 합니다. 대부분의 사람들이 그것이 무엇인지 알고 있다고 말할 수 있습니다(하지만 증명할 수는 없습니다). 언어의 복잡성은 그 이점에 대해 지불하기에 좋은 "가격"이 될 것입니다.
• 예를 들어 열거형이 없다는 것은 Generetad protobuf 코드를 확인할 때나 열거형을 모방하는 데이터베이스 모델을 만들려고 할 때만 발생하는 문제입니다.
• 그것도 사실이다.

나는 이 제안에 대해 많은 생각을 했고, 단순함이 생산성에 큰 가치가 있다는 것을 알 수 있습니다. 그리고 분명히 필요한 변경이 없는 한 유지하려는 이유를 알 수 있습니다. 열거형은 또한 언어를 너무 급격하게 변경하여 더 이상 Go가 아닐 수 있으며, 이에 대한 장단점을 평가하는 데 오랜 시간이 걸릴 것 같습니다. 그래서 나는 코드가 여전히 읽기 쉬운 당신과 같은 간단한 솔루션이 적어도 현재로서는 좋은 솔루션이라고 생각했습니다.

여러분, 미래에 이 기능을 정말 원합니다!. _요즘_에서 포인터 와 " 열거형 "을 정의하는 방법은 잘 어울리지 않습니다. 예: https://play.golang.org/p/A7rjgAMjfCx

enum에 대한 제 제안은 다음과 같습니다. 우리는 이것을 새로운 유형으로 간주해야 합니다. 예를 들어 임의의 구조와 다음 구현으로 열거형을 사용하고 싶습니다.

package application

type Status struct {
Name string
isFinal bool
}

enum Status {
     Started = &Status{"Started",false}
     Stopped = &Status{"Stopped",true}
     Canceled = &Status{"Canceled",true}
}

// application.Status.Start - to use

이 구조를 어떻게 마샬링하고 어떻게 작동하는지, 어떻게 문자열로 변경하는지 등은 이해할 수 있습니다.
물론 "다음" 기능을 재정의할 수 있다면 훌륭할 것입니다.

이를 위해 Go는 먼저 깊은 불변 구조체를 지원해야 합니다. 불변 유형이 없으면 열거형으로 이 작업을 수행하여 동일한 것을 가질 수 있다고 상상할 수 있습니다.

type Status enum {
  Started
  Stopped
}

func isFinal(s Status) bool {
  exhaustive switch(s) {
    case Started: return false;
    case Stopped: return true;
  }
}

더 심플해 보여야 할 것 같아요

func isFinal(s Status) bool {
  return s == Status.Stopped
}

Go2에 대한 제안

논리적으로 열거형은 유형 인터페이스를 제공해야 합니다.
이전 열거형은 분리되어야 한다고 언급했습니다.
특정 네임스페이스에 연결된 명시적으로 명명된 상수입니다.

enum Status uint8 {
  Started  // Status.Started == 0
  Stopped // Status.Stopped == 1, etc, like we have used iota
}
// or 
enum Status string  {
  Started // Status.Started == "Started", like it works with JSON
  Stopped // Status.Stopped == "Stopped", etc
}
// unless you wanna define its values explicitly
enum Status {
  Started "started"  // compiler can infer underlying type
  Stopped "finished"
}
// and enums are type extensions and should be used like this
type MyStatus Status

MyStatus validatedStatus // holds a nil until initialized

// for status value validation we can use map pattern
if validatedStatus, ok := MyStatus[s]; ok {
  // this value is a valid status
  // and we can use it later as regular read-only string
  // or like this
  if validatedStatus == MyStatus.Started {
     fmt.Printf("Hey, my status is %s", validatedStatus)
  }
}

열거형은 "상수 컨테이너"인 유형 확장입니다.

유형 애호가를 위해

유형으로 보고 싶은 사람들을 위한 구문 대안

type Status uint8 enum {
  Started  // Status.Started == 0
  Stopped // Status.Stopped == 1, etc, like we have used iota
}

그러나 우리는 또한 명시적인 최상위 선언을 피할 수 있습니다.

type Status enum {
  Started  // Status.Started == 0
  Stopped // Status.Stopped == 1, etc, like we have used iota
}

유효성 검사 예는 동일하게 유지됩니다.

그러나 경우에

type Status1 uint8 enum {
  Started  // Status1.Started == 0
  Stopped // Status1.Stopped == 1, etc, like we have used iota
}

type Status2 uint8 enum {
  Started  // Status1.Started == 0
  Stopped // Status1.Stopped == 1, etc, like we have used iota
}

Status1.Started == Status2.Started는 어떻습니까?
마샬링에 대해?

포지션을 바꾸면?

type Status uint8 enum {
  Started  // Status.Started == 0
  InProcess
  Stopped // Status.Stopped == 1, etc, like we have used iota
}

나는 불변 유형에 대해 @Goodwine 에 동의합니다.

마샬링은 흥미로운 질문입니다.
이것은 모두 기본 값을 어떻게 처리할 것인지에 달려 있습니다. 실제 값을 사용하려는 경우 Status1.Started 는 Status2.Started 와 같습니다.
우리가 상징적 해석을 한다면 그것들은 다른 값으로 간주될 것입니다.

무언가를 삽입하면 값이 변경됩니다( iota 와 동일한 방식).
이를 피하기 위해 개발자는 선언과 함께 값을 지정해야 합니다.

type Status uint8 enum {
  Started  0
  InProcess 2
  Stopped 1
}

이것은 분명한 것입니다.
이러한 문제를 피하려면 열거형 값의 어휘 해석을 기반으로 예측 가능한 컴파일러 출력을 제공해야 합니다. 사용자 정의 유형 캐스팅이 정의되지 않는 한 해시 테이블을 작성하거나 기호 이름(문자열)을 고수하는 가장 간단한 방법을 가정합니다.

Rust가 Enum을 구현하는 방식이 마음에 듭니다.

유형이 지정되지 않은 기본값

enum IpAddr {
    V4,
    V6,
}

사용자 정의 유형

enum IpAddr {
    V4(string),
    V6(string),
}

home := IpAddr.V4("127.0.0.1");
loopback := IpAddr.V6("::1");

복합 유형

enum Message {
    Quit,
    Move { x: int32, y: int32 },
    Write(String),
    ChangeColor(int32, int32, int32),
}

C#에서와 같이 정수 형식으로 저장되는 간단한 열거형이 있어도 좋을 것입니다.

위의 내용은 enum 를 넘어 _discriminated unions_ 입니다. 특히 _pattern matching_에서 더 강력합니다. 이는 switch 에 대한 약간의 확장이 될 수 있습니다. 다음과 같습니다.

switch something.(type) {
case Quit:
        ...
case ChangeColor; r, g, b := something:
        ...
case Write: // Here `something` is known to be a string
        ...
// Ideally Go would warn here about the missing case for "Move"
}

언급 한 것처럼 위험 할 수 있으므로 열거 형에 대한 컴파일 시간 검사가 필요하지 않습니다.

여러 번 필요한 것은 주어진 유형의 모든 상수를 반복하는 것이었습니다.

• 검증을 위해 (우리가 이것을 수락하거나 단순히 알 수없는 옵션을 무시하려는 것이 매우 확실한 경우)
  
  
  
  • 또는 가능한 상수 목록(드롭다운을 생각해 보세요).
  
  

iota로 유효성 검사를 수행하고 목록의 끝을 지정할 수 있습니다. 그러나 코드 내부 이외의 다른 용도로 iota를 사용하면 잘못된 줄에 상수를 삽입하여 내용이 중단되기 때문에 상당히 위험합니다. 다른 것들보다 찾기가 훨씬 더 어렵습니다). 또한 상수가 숫자일 때 실제로 무엇을 나타내는지에 대한 설명이 없습니다. 다음 요점으로 이어집니다.

멋진 추가 기능은 이름을 stringify로 지정하는 것입니다.

누군가가 다음과 같은 일을 하지 못하도록 막는 것:

NotADay := Day{"NotADay"}
getTask(NotADay)

그러한 변수의 소비자는 예상 값을 적절하게 확인하여 이를 포착할 수도 있고 포착하지 못할 수도 있습니다(예를 들어 토요일이나 일요일이 아닌 것은 평일인 것처럼 switch 문의 가정을 통해 나쁜 하락이 없다고 가정). 런타임까지. 런타임이 아닌 컴파일 타임에 이런 유형의 실수를 잡는 것이 더 좋을 것 같습니다.

@L-oris 그래서 이것에 대해:

package main
import "yet/it/is/not/a/good/practice/in/Go/enum/example/day"

func main()
{
  // var foo day.Day
  foo := day.Day{}
  bar(foo)
}

func bar(day day.Day)
{
  // xxxxxxxxxx
}

우리가 원하는 것은 [return "nothing to do"]에 의한 런타임 침묵 및 이상한 버그가 아니라 컴파일 타임/코딩 타임 ERROR REPORTING !
이해하다?

1. enum 는 실제로 새로운 유형입니다. type State string 가 하는 일이므로 관용적으로 새 키워드를 도입할 필요가 없습니다. Go는 소스 코드의 공간을 절약하는 것이 아니라 가독성, 목적의 명확성에 관한 것입니다.

2. 유형 안전성 부족, 실제 문자열/int에 대한 새로운 string - 또는 int 기반 유형을 혼동하는 것이 핵심 장애물입니다. 모든 열거형 절은 const 로 선언되어 컴파일러가 확인할 수 있는 알려진 값 집합을 만듭니다.

3. Stringer 인터페이스는 모든 유형을 사람이 읽을 수 있는 텍스트로 나타내는 관용구입니다. 사용자 정의 없이 type ContextKey string 열거형은 이것이 문자열 값이고 iota -generated 열거형의 경우 JavaScript의 XHR ReadyState 코드 (0 - 미전송, 4 - 완료)와 마찬가지로 정수입니다.

   오히려 문제는 사용자 정의 func (k ContextKey) String() string 구현의 오류 가능성에 있습니다. 이는 일반적으로 알려진 모든 열거형 절 상수를 포함해야 하는 스위치를 사용하여 수행됩니다.

4. Swift와 같은 언어에는 _exhaustive switch_라는 개념이 있습니다. 이것은 const 집합에 대한 유형 검사와 해당 검사를 호출하는 관용적 방법을 구축하는 데 모두 좋은 접근 방식입니다. 일반적으로 필요한 String() 함수는 구현하기에 좋은 사례입니다.

제안

package main

import (
    "context"
    "strconv"
    "fmt"
    "os"
)

// State is an enum of known system states.
type DeepThoughtState int

// One of known system states.
const (
    Unknown DeepThoughtState = iota
    Init
    Working
    Paused
    ShutDown
)

// String returns a human-readable description of the State.
//
// It switches over const State values and if called on
// variable of type State it will fall through to a default
// system representation of State as a string (string of integer
// will be just digits).
func (s DeepThoughtState) String() string {
    // NEW: Switch only over const values for State
    switch s.(const) {
    case Unknown:
        return fmt.Printf("%d - the state of the system is not yet known", Unknown)
    case Init:
        return fmt.Printf("%d - the system is initializing", Init)
    } // ERR: const switch must be exhaustive; add all cases or `default` clause

    // ERR: no return at the end of the function (switch is not exhaustive)
}

// RegisterState allows changing the state
func RegisterState(ctx context.Context, state string) (interface{}, error) {
    next, err := strconv.ParseInt(state, 10, 32)
    if err != nil {
        return nil, err
    }
    nextState := DeepThoughtState(next)

    fmt.Printf("RegisterState=%s\n", nextState) // naive logging

        // NEW: Check dynamically if variable is a known constant
    if st, ok := nextState.(const); ok {
        // TODO: Persist new state
        return st, nil
    } else {
        return nil, fmt.Errorf("unknown state %d, new state must be one of known integers", nextState)
    }
}

func main() {
    _, err := RegisterState(context.Background(), "42")
    if err != nil {
        fmt.Println("error", err)
        os.Exit(1)
    }
    os.Exit(0)
    return
}

PS Swift 열거형의 관련 값은 제가 가장 좋아하는 특수 효과 중 하나입니다. Go에서는 그들을 위한 자리가 없습니다. 열거형 데이터 옆에 값을 갖고 싶다면 — 두 개를 감싸는 강력한 형식의 struct 를 사용하세요.

몇 달 전에 나는 열거된 유형이 제대로 처리되는지 확인하는 린터에 대한 개념 증명을 작성했습니다. https://github.com/loov/enumcheck

현재 주석을 사용하여 항목을 열거형으로 표시합니다.

type Letter byte // enumcheck

const (
    Alpha Letter = iota
    Beta
    Gamma
)

func Switch(x Letter) {
    switch x { // error: "missing cases Beta and Gamma"
    case Alpha:
        fmt.Println("alpha")
    case 4: // error: "implicit conversion of 4 to Letter"
        fmt.Println("beta")
    default: // error: "Letter shouldn't have a default case"
        fmt.Println("default")
    }
}

모든 암시적 변환을 처리하는 방법을 알아내는 데 어려움을 겪었지만 기본적인 경우에는 제대로 작동합니다.

참고로, 현재는 아직 작업 중이므로 상황이 변경될 수 있습니다. 예를 들어 주석 대신 유형에 주석을 추가하기 위해 일부 스텁 패키지를 사용할 수 있지만 주석은 현재 충분합니다.

현재 Go1의 열거형 구현은 내가 알고 있는 모든 언어에서 가장 이상하고 가장 불분명한 열거형 구현입니다. C조차도 그것들을 더 멋지게 구현합니다. iota 물건은 해킹처럼 보입니다. 그리고 대체 iota는 무엇을 의미합니까? 그 키워드를 어떻게 외워야 할까요? Go는 배우기 쉬워야 합니다. 그러나 그것은 단지 기발합니다.

@pofl :
Go 열거형이 꽤 어색하다는 데 동의하지만 iota 는 실제로는 일반적인 영어 단어입니다.

이오타
_명사_

1. 아주 소량; 조금; 성령 강림 대축일.
2. 그리스 알파벳의 아홉 번째 글자(I, ι).
3. 이 문자가 나타내는 모음 소리.

아마도 그들은 언어의 사용 측면에서 정의 1로 가고 있었던 것 같습니다.

여기에 있는 이전 의견에 대한 답변으로:
Go에서도 차별된 공용체를 정말 원하지만 실제 열거형과 분리되어야 한다고 생각합니다. 현재 제네릭이 진행되고 있는 방식으로 인터페이스의 유형 목록을 통해 식별된 공용체와 매우 유사한 것을 실제로 얻을 수 있습니다. #41716을 참조하십시오.

Go에서 iota 를 사용하는 것은 APL에서의 사용을 기반으로 합니다. 인용 https://en.wikipedia.org/wiki/Iota :

일부 프로그래밍 언어(예: A+, APL, C++[6], Go[7])에서 iota(소문자 기호 ⍳ 또는 식별자 iota로)는 연속 정수 배열을 나타내고 생성하는 데 사용됩니다. 예를 들어, APL ⍳4에서는 1 2 3 4가 됩니다.