CL https://golang.org/cl/22057 에 이 문제가 언급되어 있습니다.

우리의 https://golang.org/wiki/NoMeToo 정책을 모두에게 미리 상기시켜 드리겠습니다. 이모티콘 파티는 위에 있습니다.

다른 곳에서 온 토론의 개요를 제공하려고 하는 Summary of Go Generics Discussions 가 있습니다. 또한 제네릭을 사용하려는 문제를 해결하는 방법에 대한 몇 가지 예를 제공합니다.

연결된 제안서에는 구현을 복잡하게 만들고 형식 안전성을 감소시킬 수 있는 두 가지 "요구 사항"이 있습니다.

• 인스턴스화될 때까지 알려지지 않은 유형을 기반으로 제네릭 유형을 정의합니다.
• 제네릭 형식이나 함수의 정의와 그 사용 사이에 명시적인 관계가 필요하지 않습니다. 즉, 프로그램은 유형 T가 일반 G를 구현한다고 명시적으로 말할 필요가 없습니다.

이러한 요구 사항은 예를 들어 일반 유형이 특성 경계에 의해 제한되는 Rust의 특성 시스템과 유사한 시스템을 제외하는 것 같습니다. 왜 이것들이 필요합니까?

C++ std::basic_string에서와 같이 매우 낮은 수준에서 표준 라이브러리에 제네릭을 빌드하고 싶은 유혹이 생깁니다., 표준::할당자>. 이것은 이점이 있습니다. 그렇지 않으면 아무도 하지 않을 것입니다. 그러나 이해할 수 없는 C++ 오류 메시지에서와 같이 광범위하고 때로는 놀라운 효과가 있습니다.

C++의 문제는 생성된 코드의 유형 검사에서 발생합니다. 코드 생성 전에 추가 유형 검사가 필요합니다. C++ 개념 제안은 제네릭 코드 작성자가 제네릭 유형의 요구 사항을 지정할 수 있도록 하여 이를 가능하게 합니다. 그렇게 하면 코드 생성 전에 컴파일이 유형 검사에 실패할 수 있고 간단한 오류 메시지가 인쇄될 수 있습니다. C++ 제네릭(개념 없음)의 문제는 제네릭 코드가 제네릭 형식의 사양 _is_이라는 것입니다. 이것이 이해할 수 없는 오류 메시지를 생성하는 것입니다.

제네릭 코드는 제네릭 형식의 사양이 되어서는 안 됩니다.

@tamird 인터페이스가 아닌 유형 T를 정의하고 나중에 T가 I를 구현하도록 인터페이스 유형 I을 정의할 수 있는 것은 Go 인터페이스 유형의 필수 기능입니다. https://golang.org/doc/faq#implements_interface 참조 . Go가 "G를 구현하는 데 사용할 수 있습니다."라고 명시적으로 말한 T 유형과만 제네릭 유형 G를 사용할 수 있는 제네릭 형식을 구현했다면 일관성이 없을 것입니다.

저는 Rust에 익숙하지 않지만 T가 G를 구현하는 데 사용할 수 있다고 명시적으로 명시해야 하는 언어를 모릅니다. 언급한 두 가지 요구 사항이 G가 T에 요구 사항을 부과할 수 없다는 것을 의미하지는 않습니다. 내가 T에 요구 사항을 부과하는 것처럼 요구 사항은 G와 T를 독립적으로 작성할 수 있음을 의미합니다. 그것은 제네릭에게 매우 바람직한 기능이며, 나는 그것을 포기하는 것을 상상할 수 없습니다.

@ianlancetaylor https://doc.rust-lang.org/book/traits.html 은 Rust의 특성을 설명합니다. 나는 그들이 일반적으로 좋은 모델이라고 생각하지만 오늘날 존재하는 바둑에는 적합하지 않을 것입니다.

@sbunc 저도 컨셉이 답이라고 생각했는데, 지난번 제안에 앞서 다양한 제안에 흩어져 있는 아이디어를 보실 수 있습니다. 그러나 개념이 원래 C++11이 된 것을 위해 계획되었고 지금은 2016년이고 여전히 논쟁의 여지가 있고 C++ 언어에 포함되기에 특히 가깝지 않다는 점은 실망스럽습니다.

접근 방식 평가에 대한 지침으로 학술 문헌에 가치가 있습니까?

주제에 대해 읽은 유일한 문서는 개발자가 제네릭 유형의 이점을 얻는가?입니다. (페이월 죄송합니다. pdf 다운로드로 가는 길을 구글링할 수 있습니다.) 다음과 같은 내용이 있었습니다.

결과적으로 실험에 대한 보수적 해석
제네릭 유형은 절충안으로 간주될 수 있습니다.
긍정적인 문서화 특성과
부정적인 확장성 특성. 흥미진진한 부분
을 사용하는 상황을 보여주었다는 연구이다.
(강한) 정적 유형 시스템은 시스템에 부정적인 영향을 미쳤습니다.
개발 시간과 동시에 예상되는 이점-
적합성(유형오류 수정시간 단축)은 나타나지 않았다.
우리는 그러한 작업이 미래의 실험에 도움이 될 수 있다고 생각합니다.
유형 시스템의 영향을 식별합니다.

또한 https://github.com/golang/go/issues/15295 도 참조 하는 경량의 유연한 객체 지향 제네릭 을 참조하십시오.

결정을 안내하기 위해 학계에 의지한다면 사전 문헌 검토를 수행하고 증거에 의존하는 연구와 경험적 연구를 다르게 평가할 것인지 일찍 결정하는 것이 더 나을 것이라고 생각합니다.

Barbara Liskov의 http://dl.acm.org/citation.cfm?id=2738008 :

현대 객체 지향 프로그래밍 언어에서 일반 프로그래밍에 대한 지원은 어색하고 원하는 표현력이 부족합니다. 일반적인 사용 사례에서 가볍고 단순하게 유지하면서 표현력을 추가하고 정적 검사를 강화하는 표현적 일반성 메커니즘을 도입합니다. 유형 클래스 및 개념과 마찬가지로 메커니즘을 통해 기존 유형이 유형 제약 조건을 소급하여 모델링할 수 있습니다. 표현력을 위해 모델을 명시적으로 정의하고 선택하여 제약 조건을 확인할 수 있는 명명된 구성으로 노출합니다. 그러나 일반성을 일반적으로 사용하는 경우 형식은 추가 프로그래머 노력 없이 암시적으로 제약 조건을 목격합니다.

나는 그들이 거기에서 한 것이 꽤 멋지다고 생각합니다. 이것이 멈출 곳이 잘못된 경우 죄송하지만 /proposals에서 의견을 말할 곳을 찾을 수 없었고 여기에서 적절한 문제를 찾지 못했습니다.

Go 1.xy 소스 코드 컴파일러에 대한 Go 제네릭 소스 코드인 하나 이상의 실험적 트랜스파일러를 갖는 것은 흥미로울 수 있습니다.
내 의견에 대한 너무 많은 이야기/인수, 그리고 아무도 Go에 대한 _일종의 제네릭 을 구현하기 위해 _시도하는_ 소스 코드를 작성하지 않습니다.

Go 및 제네릭에 대한 지식과 경험을 얻으려면 작동하는 것과 작동하지 않는 것을 확인하십시오.
모든 Go 제네릭 솔루션이 실제로 좋지 않다면; Go에 대한 제네릭이 없습니다.

제안서에 바이너리 크기와 메모리 공간에 대한 영향도 포함될 수 있습니까? 컴파일러 최적화가 작동하도록 각 구체적인 값 유형에 대해 코드 중복이 있을 것으로 예상합니다. 구체적인 포인터 유형에 대한 코드 중복이 없다는 보장을 바랍니다.

저는 Pugh Decision 매트릭스를 제공합니다. 내 기준에는 명료성 영향(소스 복잡성, 크기)이 포함됩니다. 또한 기준에 대한 가중치를 결정하기 위해 기준에 순위를 매겼습니다. 물론 자신의 것이 다를 수 있습니다. 나는 "인터페이스"를 기본 대안으로 사용하고 이것을 "복사/붙여넣기" 제네릭, 템플릿 기반 제네릭(D 언어 작동 방식과 같은 것을 염두에 둠) 및 런타임 인스턴스화 스타일 제네릭이라고 부르는 것과 비교했습니다. 나는 이것이 지나친 단순화라고 확신합니다. 그럼에도 불구하고 선택을 평가하는 방법에 대한 몇 가지 아이디어를 촉발할 수 있습니다... 이것은 내 Google 시트에 대한 공개 링크여야 합니다. 여기

@yizhouzhang 및 @andrewcmyers 에 핑을 보내 Go의 제네릭과 같은 속(genus)에 대한 의견을 표명할 수 있습니다. 좋은 궁합이 될 것 같습니다 :)

Genus에 대해 생각해 낸 제네릭 디자인은 정적, 모듈식 유형 검사가 있으며 유형이 일부 인터페이스를 구현한다는 사전 선언이 필요하지 않으며 합리적인 성능을 제공합니다. Go의 제네릭에 대해 생각하고 있다면 확실히 살펴보겠습니다. Go에 대한 나의 이해로 볼 때 그것은 잘 맞는 것 같습니다.

다음은 ACM 디지털 라이브러리 액세스가 필요하지 않은 논문에 대한 링크입니다.
http://www.cs.cornell.edu/andru/papers/genus/

Genus 홈페이지는 http://www.cs.cornell.edu/projects/genus/ 입니다.

아직 컴파일러를 공개적으로 출시하지 않았지만 곧 출시할 계획입니다.

사람들이 가지고 있는 모든 질문에 기꺼이 답변해 드립니다.

@mandolyte 의 결정 매트릭스 측면에서 Genus는 17점으로 공동 1위입니다. 하지만 점수를 매기기 위해 몇 가지 기준을 더 추가할 것입니다. 예를 들어, 위에서 관찰한 @sbunc 와 같은 다른 것들처럼 모듈식 유형 검사는 중요하지만 템플릿 기반 체계에는 부족합니다. Genus 논문에 대한 기술 보고서 에는 다양한 제네릭 디자인을 비교하는 훨씬 더 큰 표가 34페이지에 있습니다.

방금 이전 토론의 유용한 요약 인 Go Generics 문서 전체를 살펴보았습니다. 내 생각에 Genus의 제네릭 메커니즘은 C++, Java 또는 C#에 대해 식별된 문제를 겪지 않습니다. Genus 제네릭은 Java와 달리 구체화되어 런타임에 유형을 찾을 수 있습니다. 또한 기본 유형에서 인스턴스화할 수 있으며 실제로 원하지 않는 위치에서 암시적 복싱을 얻을 수 없습니다. T는 기본 형식인 T 배열입니다. 유형 시스템은 Haskell 및 Rust에 가장 가깝습니다. 실제로는 조금 더 강력하지만 직관적이기도 합니다. 기본 전문화 ala C#은 현재 Genus에서 지원되지 않지만 가능합니다. 대부분의 경우 특수화는 링크 시간에 결정할 수 있으므로 실제 런타임 코드 생성이 필요하지 않습니다.

CL https://golang.org/cl/22163 에 이 문제가 언급되어 있습니다.

새로운 언어 개념을 추가할 필요가 없는 일반 유형을 제한하는 방법: https://docs.google.com/document/d/1rX4huWffJ0y1ZjqEpPrDy-kk-m9zWfatgCluGRBQveQ/edit?usp=sharing.

속은 정말 멋져 보이고 예술의 중요한 발전임이 분명하지만 바둑에 어떻게 적용될지 모르겠습니다. Go 유형 시스템/철학과 통합하는 방법에 대한 스케치가 있는 사람이 있습니까?

문제는 바둑 팀이 벽을 막으려는 시도라는 것입니다. 제목은 바둑 팀의 의도를 명확하게 나타냅니다. 그리고 그것이 모든 수용자를 제지하기에 충분하지 않다면 ian이 제안한 광범위한 영역에서 요구되는 기능은 당신이 제네릭을 원하면 그들이 당신을 원하지 않는다는 것을 분명히 합니다. 바둑팀과 대화를 시도하는 것조차 무의미하다. 이동 중에 제네릭을 찾는 사람들에게 나는 언어를 골절(fracture)이라고 말합니다. 새로운 여정을 시작하십시오. 많은 사람들이 따를 것입니다. 나는 이미 포크에서 수행된 몇 가지 훌륭한 작업을 보았습니다. 자신을 조직하고 대의를 위해 결집하십시오.

Genus 디자인을 기반으로 Go에 대한 제네릭 확장을 작업하려는 사람이 있다면 기꺼이 도와드리겠습니다. 기존 언어와 조화를 이루는 디자인을 제작할 만큼 바둑을 잘 모릅니다. 첫 번째 단계는 연습된 예제와 함께 밀짚맨 디자인 제안이 될 것이라고 생각합니다.

@andrewcmyers 는 @ianlancetaylor 가 당신과 함께 일하기를 바랍니다. 몇 가지 예를 살펴보는 것만으로도 많은 도움이 될 것입니다.

나는 Genus 논문을 읽었습니다. 내가 이해하는 한 Java에는 좋은 것처럼 보이지만 Go에는 자연스럽게 적합하지 않은 것 같습니다.

Go의 주요 측면 중 하나는 Go 프로그램을 작성할 때 작성하는 대부분이 코드라는 것입니다. 이것은 작성하는 것의 훨씬 더 많은 부분이 유형인 C++ 및 Java와 다릅니다. 속은 대부분 유형에 관한 것 같습니다. 코드보다는 제약 조건과 모델을 작성합니다. Go의 유형 시스템은 매우 간단합니다. Genus의 유형 시스템은 훨씬 더 복잡합니다.

소급 모델링의 아이디어는 Java에 분명히 유용하지만 Go에는 전혀 맞지 않는 것 같습니다. 사람들은 이미 어댑터 유형을 사용하여 기존 유형을 인터페이스와 일치시킵니다. 제네릭을 사용할 때 더 이상 필요하지 않습니다.

이러한 아이디어가 Go에 적용되는 것을 보는 것은 흥미로울 것입니다. 그러나 저는 그 결과에 대해 낙관적이지 않습니다.

저는 Go 전문가는 아니지만 유형 시스템이 제네릭 이전 Java보다 간단해 보이지 않습니다. 유형 구문은 좋은 방식으로 약간 더 가볍지만 근본적인 복잡성은 거의 같습니다.

Genus에서 제약 조건은 유형이지만 모델 은 코드입니다. 모델은 어댑터이지만 실제 래핑 레이어를 추가하지 않고 적응합니다. 이것은 전체 개체 배열을 새 인터페이스에 적용하려는 경우에 매우 유용합니다. 소급 모델링을 사용하면 어레이를 원하는 인터페이스를 충족하는 객체 어레이로 취급할 수 있습니다.

실제로 사용하는 것이 더 간단하더라도 유형 이론적인 의미에서 Java(제네릭 이전)보다 복잡하더라도 놀라지 않을 것입니다.

상대적인 복잡성을 제외하고는 Genus가 1:1로 매핑할 수 없을 정도로 다릅니다. 하위 유형이 큰 것 같지 않습니다.

관심이 있는 경우:

내가 언급한 관련 철학/디자인 차이점에 대한 가장 간단한 요약은 다음 FAQ 항목에 포함되어 있습니다.

• https://golang.org/doc/faq#implements_interface
• https://golang.org/doc/faq#overloading
• https://golang.org/doc/faq#covariant_types
• https://golang.org/doc/faq#variant_types

대부분의 언어와 달리 Go 사양은 https://golang.org/ref/spec#Constants 에서 시작하는 유형 시스템의 관련 속성에 대해 매우 짧고 명확하며 "블록"(모두 11페이지 미만 인쇄).

Java 및 C# 제네릭과 달리 Genus 제네릭 메커니즘은 하위 유형 지정을 기반으로 하지 않습니다. 반면에 Go에는 하위 유형이 있지만 구조적 하위 유형이 있는 것 같습니다. 이는 또한 미리 선언된 관계에 의존하기보다는 구조적 특징이 있는 Genus 접근 방식과도 잘 일치합니다.

Go에 구조적 하위 유형이 있다고 생각하지 않습니다.

기본 유형이 동일한 두 유형은 따라서 동일하지만
서로 대체 가능, https://play.golang.org/p/cT15aQ-PFr

이것은 필드의 공통 하위 집합을 공유하는 두 가지 유형으로 확장되지 않습니다.
https://play.golang.org/p/KrC9_BDXuh.

2016년 4월 28일 목요일 오후 1:09, Andrew Myers [email protected]
썼다:

Java 및 C# 제네릭과 달리 Genus 제네릭 메커니즘은
서브타이핑. 반면에 Go에는 하위 유형이 있는 것 같습니다.
그러나 구조적 하위 유형. 그것은 또한 Genus 접근 방식과도 잘 일치합니다.
미리 선언된 것에 의존하기 보다는 구조적 풍미가 있는
관계.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/golang/go/issues/15292#issuecomment -215298127

감사합니다. 유형이 인터페이스를 구현하는 시기에 대해 일부 언어를 잘못 해석하고 있었습니다. 사실, 적당한 확장을 가진 Go 인터페이스가 Genus 스타일 제약으로 사용될 수 있는 것처럼 보입니다.

그것이 바로 내가 당신에게 핑을 보낸 이유입니다. 속은 제네릭과 같은 Java/C#보다 훨씬 더 나은 접근 방식인 것 같습니다.

인터페이스 유형을 전문화하는 것과 관련하여 몇 가지 아이디어가 있었습니다. 예를 들어 _패키지 템플릿_ 접근 방식 "제안" 1 2 이 그 예입니다.

헐; 박사; 인터페이스 전문화가 있는 일반 패키지는 다음과 같습니다.

package set
type E interface { Equal(other E) bool }
type Set struct { items []E }
func (s *Set) Add(item E) { ... }

버전 1. 패키지 범위 전문화 포함:

package main
import items set[[E: *Item]]

type Item struct { ... }
func (a *Item) Equal(b *Item) bool { ... }

var xs items.Set
xs.Add(&Item{})

버전 2. 선언 범위 전문화:

package main
import set

type Item struct { ... }
func (a *Item) Equal(b *Item) bool { ... }

var xs set.Set[[E: *Item]]
xs.Add(&Item{})

패키지 범위 제네릭은 사용이 기본 알고리즘 및 데이터 구조로 제한되어 있기 때문에 사람들이 제네릭 시스템을 크게 남용하는 것을 방지합니다. 기본적으로 새로운 언어 추상화 및 기능 코드 구축을 방지합니다.

선언 범위 전문화는 비용으로 더 많은 가능성을 가지며 남용되기 쉽고 더 장황합니다. 그러나 기능 코드는 가능합니다. 예:

type E interface{}
func Reduce(zero E, items []E, fn func(a, b E) E) E { ... }

Reduce[[E: int]](0, []int{1,2,3,4}, func(a, b int)int { return a + b } )
// there are probably ways to have some aliases (or similar) to make it less verbose
alias ReduceInt Reduce[[E: int]]
func ReduceInt Reduce[[E: int]]

인터페이스 전문화 접근 방식에는 다음과 같은 흥미로운 속성이 있습니다.

• 인터페이스를 사용하는 기존 패키지는 특수화할 수 있습니다. 예를 들어 sort.Sort[[Interface:MyItems]](...) 를 호출할 수 있고 인터페이스 대신 구체적인 유형에 대한 정렬 작업을 수행할 수 있습니다(인라이닝으로 인한 잠재적인 이점 포함).
• 테스트가 단순화되었습니다. 제네릭 코드가 인터페이스에서 작동하는지 확인하기만 하면 됩니다.
• 작동 방식을 설명하는 것은 쉽습니다. 즉, [[E: int]] 가 E int $ 로 대체한다고 상상해 보십시오.

그러나 패키지 간에 작업할 때 자세한 정보 문제가 있습니다.

type op
import "set"

type E interface{}
func Union(a, b set.Set[[set.E: E]]) set.Set[[set.E: E]] {
    result := set.New[[set.E: E]]()
    ...
}

_물론, 모든 것은 구현하는 것보다 진술하는 것이 더 간단합니다. 내부적으로는 아마도 수많은 문제와 작동 방식이 있을 것입니다._

_PS, 느린 제네릭 진행에 대해 불평하는 사람들에게 저는 컴파일러/런타임 버그, SSA, GC, http2와 같이 커뮤니티에 더 큰 이점이 있는 문제에 더 많은 시간을 할애한 Go Team에 박수를 보냅니다._

@egonelbre 패키지 수준 제네릭이 "남용"을 방지할 것이라는 귀하의 요지는 대부분의 사람들이 간과하고 있다고 생각하는 정말 중요한 것입니다. 그것에 더하여 상대적 의미론적 및 구문론적 단순성(패키지 및 가져오기 구조만 영향을 받음)으로 인해 Go에서 매우 매력적입니다.

@andrewcymyers 흥미롭게도 Go 인터페이스가 Genus 스타일 제약 조건으로 작동한다고 생각합니다. 나는 그들이 당신이 그들과 함께 다중 유형 매개 변수 제약 조건을 표현할 수 없다는 문제가 여전히 있다고 생각했을 것입니다.

그러나 내가 방금 깨달은 한 가지는 Go에서 인터페이스를 인라인으로 작성할 수 있다는 것입니다. 따라서 올바른 구문을 사용하면 인터페이스를 모든 매개변수 범위에 넣고 다중 매개변수 제약 조건을 캡처할 수 있습니다.

type [V, E] 그래프 [V interface { Edges() E }, E interface { Endpoints() (V, V) }] ...

제약 조건으로서의 인터페이스의 더 큰 문제는 메서드가 Java에서처럼 Go에서 널리 사용되지 않는다는 것입니다. 기본 제공 형식에는 메서드가 없습니다. java.lang.Object와 같은 범용 메소드 세트는 없습니다. 사용자는 특별히 필요하지 않는 한 일반적으로 유형에 대해 Equals 또는 HashCode와 같은 메소드를 정의하지 않습니다. 이러한 메소드는 유형을 맵 키로 사용하거나 동등성이 필요한 알고리즘에서 사용할 수 있는 자격을 부여하지 않기 때문입니다.

(Go의 평등은 흥미로운 이야기입니다. 언어는 특정 요구 사항을 충족하는 경우 유형 "=="를 제공합니다(https://golang.org/ref/spec#Logical_operators 참조, "comparable" 검색). " =="는 맵 키로 사용할 수 있지만 "=="에 해당하지 않는 유형이라면 맵 키로 작동하도록 작성할 수 있는 것이 없습니다.)

메서드가 널리 퍼져 있지 않고 기본 제공 형식의 속성을 쉽게 표현할 수 있는 방법이 없기 때문에(예: 사용하는 연산자) 코드 자체를 일반 제약 메커니즘으로 사용하는 것이 좋습니다. 위의 4월 18일 내 댓글에 있는 링크를 참조하세요. 이 제안에는 문제가 있지만 한 가지 좋은 기능은 일반 숫자 코드가 번거로운 메서드 호출 대신 일반 연산자를 계속 사용할 수 있다는 것입니다.

다른 방법은 메소드가 없는 유형에 메소드를 추가하는 것입니다. 기존 언어에서 Java보다 훨씬 가벼운 방법으로 이 작업을 수행할 수 있습니다.

유형 정수 정수
func (i Int) Less(j Int) bool { return i < j }

Int 유형은 int의 모든 연산자 및 기타 속성을 "상속"합니다. Int와 int를 함께 사용하려면 둘 사이를 캐스팅해야 하지만 고통스러울 수 있습니다.

여기서 속 모델이 도움이 될 수 있습니다. 그러나 그것들은 매우 단순하게 유지되어야 합니다. 나는 @ianlancetaylor 가 더 많은 코드, 더 적은 유형을 작성하면서 Go의 특성을 너무 좁게 정의했다고 생각합니다. 일반적인 원칙은 Go가 복잡성을 싫어한다는 것입니다. 우리는 Java와 C++를 보고 절대 거기에 가지 않겠다고 결심했습니다. (죄가 없습니다.)

따라서 모델과 유사한 기능에 대한 한 가지 빠른 아이디어는 다음과 같습니다. 사용자가 위의 Int와 같은 유형을 작성하고 일반 인스턴스화에서 "int with Int"를 허용합니다. 즉, int 유형을 사용하지만 Int처럼 취급한다는 의미입니다. 그러면 키워드, 상속 의미 등을 포함하는 모델이라는 명백한 언어 구성이 없습니다. 이것이 가능한지 알 수 있을 만큼 모델을 잘 이해하지 못하지만, 바둑의 정신에 더 가깝습니다.

@jba 우리는 복잡성을 피한다는 원칙에 확실히 동의합니다. "가능한 한 간단하지만 더 이상 간단하지 않습니다." 적어도 처음에는 이러한 이유로 일부 Genus 기능을 Go에서 제외할 것입니다.

Genus 접근 방식의 좋은 점 중 하나는 내장 유형을 원활하게 처리한다는 것입니다. Java의 기본 유형에는 메소드가 없으며 Genus는 이 동작을 상속합니다. 대신, Genus는 기본 유형을 _마치_ 마치 제약 조건을 충족하기 위한 목적으로 상당히 많은 방법 모음을 가지고 있는 것처럼 취급합니다. 해시 테이블은 키를 해시하고 비교할 수 있어야 하지만 모든 기본 유형이 이 제약 조건을 충족합니다. 따라서 Map[int, boolean] 과 같은 유형 인스턴스화는 더 이상 소란을 피우지 않고도 완벽하게 합법적입니다. 이를 달성하기 위해 정수의 두 가지 특징(int 대 Int)을 구별할 필요가 없습니다. 그러나 int 가 일부 용도를 위한 충분한 연산을 갖추고 있지 않다면 위의 Int 사용과 거의 똑같은 모델을 사용합니다.

언급할 가치가 있는 또 다른 것은 속(Genus)에서 "자연 모델"이라는 개념입니다. 일반적으로 제네릭 형식을 사용하기 위해 모델을 선언할 필요가 없습니다. 형식 인수가 제약 조건을 충족하면 자연 모델이 자동으로 생성됩니다. 우리의 경험은 이것이 일반적인 경우라는 것입니다. 명시적 명명된 모델을 선언하는 것은 일반적으로 필요하지 않습니다. 그러나 모델이 필요한 경우(예: 비표준 방식으로 int를 해시하려는 경우) 구문은 제안한 Map[int with fancyHash, boolean] 과 유사 합니다. Genus는 일반적인 사용 사례에서는 구문적으로 가볍지만 필요할 때 예비 전력이 있다고 주장합니다.

@egonelbre 여기서 제안하는 것은 Scala에서 지원하는 가상 유형처럼 보입니다. Kresten Krab Thorup의 ECOOP'97 논문 "가상 유형이 있는 Java의 Genericity"가 있으며 이 방향을 탐구합니다. 우리는 또한 우리 작업에서 가상 유형 및 가상 클래스에 대한 메커니즘을 개발했습니다("J&: 확장 가능한 소프트웨어 구성을 위한 중첩 교차", OOPSLA'06).

리터럴 초기화는 Go에 널리 퍼져 있기 때문에 함수 리터럴이 어떻게 생겼는지 궁금해야 했습니다. 나는 이것을 처리하는 코드가 Go 생성, 수정 및 이름 바꾸기에 주로 존재한다고 생각합니다. 아마도 누군가에게 영감을 줄 것입니다 :-)

// (일반) func 유형 정의
유형 Sum64 func (X, Y) float64 {
float64(X) + float64(Y) 반환
}

// 위치적으로 하나를 인스턴스화합니다.
나는 := 42
변수 합 = 86
합계 := &Sum64{i, j}

// 명명된 매개변수 유형으로 인스턴스화
합계 := &Sum64{ X: 정수, Y: 정수}

// 이제 사용...
result := sum(i, j) // 결과는 128

Ian의 제안은 너무 많은 것을 요구합니다. 모든 기능을 한 번에 개발할 수는 없으며 몇 달 동안 미완성 상태로 존재할 것입니다.

그동안 완료되지 않은 프로젝트는 완료될 때까지 공식 Go 언어라고 부를 수 없습니다. 생태계가 파편화될 위험이 있기 때문입니다.

따라서 문제는 이것을 계획하는 방법입니다.

또한 프로젝트의 큰 부분은 참조 말뭉치를 개발하는 것입니다.
새로운 go 2.0 기능을 사용하면서 우리 모두가 관용적이라는 데 동의하는 방식으로 실제 일반 컬렉션, 알고리즘 및 기타 항목을 개발합니다.

가능한 구문?

// Module defining generic type
module list(type t)

type node struct {
    next *node
    data t
}

// Module using generic type:
import (
    intlist "module/path/to/list" (int)
    funclist "module/path/to/list" (func (int) int)
)

l := intlist.New()
l.Insert(5)

@md2perpe , 구문은 이 문제의 어려운 부분이 아닙니다. 사실, 가장 쉽습니다. 위의 토론 및 링크된 문서를 참조하십시오.

@md2perpe 우리는 내부적으로 일반성을 위한 방법으로 전체 패키지("모듈")를 매개변수화하는 것에 대해 논의했습니다. 이는 구문 오버헤드를 줄이는 방법인 것 같습니다. 그러나 다른 문제가 있습니다. 예를 들어 패키지 수준이 아닌 유형으로 매개변수화하는 방법이 명확하지 않습니다. 그러나 이 아이디어는 여전히 자세히 조사할 가치가 있습니다.

관점을 공유하고 싶습니다. 병렬 세계에서 모든 Go 함수 서명은 항상 인터페이스 유형만 언급하도록 제한되었으며 오늘날 제네릭에 대한 수요 대신 인터페이스 값과 관련된 간접 참조를 방지하는 방법이 있습니다. (언어를 변경하지 않고) 그 문제를 어떻게 해결할지 생각해 보십시오. 몇 가지 아이디어가 있습니다.

@thwd 라이브러리 작성자는 인터페이스를 계속 사용하지만 오늘날 필요한 유형 전환 및 유형 주장 없이도 마찬가지입니다. 그리고 라이브러리 사용자는 라이브러리가 있는 그대로 유형을 사용하는 것처럼 단순히 구체적인 유형을 전달하고 컴파일러가 두 유형을 조정할까요? 그리고 그 이유를 설명할 수 없다면? (예: 모듈로 연산자가 라이브러리에서 사용되었지만 사용자가 일부를 제공했습니다.

나는 가까운가? :-)

@만돌라이트 네! 이 스레드를 오염시키지 않기 위해 이메일을 교환합시다. "me at thwd dot me"에서 저에게 연락할 수 있습니다. 관심이 있는 이 글을 읽는 다른 사람; 이메일을 보내주시면 스레드에 추가하겠습니다.

type system 및 collection library 에 대한 훌륭한 기능입니다.
잠재적인 구문:

type Element<T> struct {
    prev, next *Element<T>
    list *List<T>
    value T
}
type List<E> struct {
    root Element<E>
    len int
}

interface

type Collection<E> interface {
    Size() int
    Add(e E) bool
}

super type 또는 type implement :

func contain(l List<parent E>, e E) bool
<V> func (c Collection<child E>)Map(fn func(e E) V) Collection

위의 일명 자바:

boolean contain(List<? super E>, E e)
<V> Collection Map(Function<? extend E, V> mapFunc);

@leaxoy 앞에서 말했듯이 구문은 여기서 어려운 부분이 아닙니다. 위의 논의를 참조하십시오.

인터페이스 비용이 믿을 수 없을 정도로 크다는 점에 유의하십시오.

인터페이스 비용이 "믿을 수 없을 정도로"라고 생각하는 이유를 자세히 설명해 주십시오.
크기가 큰.
C++의 전문화되지 않은 가상 호출보다 나빠서는 안 됩니다.

@minux 성능 비용에 대해서는 말할 수 없지만 코드 품질과 관련하여 말할 수 있습니다. interface{} 는 컴파일 타임에 확인할 수 없지만 제네릭은 확인할 수 있습니다. 제 생각에 이것은 대부분의 경우 interface{} 사용의 성능 문제보다 더 중요합니다.

@xoviat

이것에 필요한 처리가 컴파일러 속도를 늦추지 않기 때문에 이것에 실제로 불리한 점은 없습니다.

(적어도) 두 가지 단점이 있습니다.

하나는 링커에 대한 작업 증가입니다. 두 유형에 대한 전문화가 동일한 기본 기계 코드를 생성하는 경우 해당 코드의 두 복사본을 컴파일하고 연결하고 싶지 않습니다.

다른 하나는 매개변수화된 패키지가 매개변수화된 방법보다 표현력이 떨어진다는 것입니다. (자세한 내용은 첫 번째 의견에서 링크된 제안을 참조하십시오.)

하이퍼 유형이 좋은 생각입니까?

func getAddFunc (aType type) func(aType, aType) aType {
    return func(a, b aType) aType {
        return a+b
    }
}

하이퍼 유형이 좋은 생각입니까?

여기에서 설명하는 것은 C++로 유형 매개변수화(즉, 템플릿)입니다. aType 유형에 주어진 정보에서 + 연산이 있는지 알 수 있는 방법이 없기 때문에 모듈식 방식으로 유형 검사를 하지 않습니다. CLU, Haskell, Java, Genus에서와 같은 제약 유형 매개변수화가 솔루션입니다.

@golang101 나는 그와 관련된 상세한 제안을 가지고 있습니다. 목록에 추가하기 위해 CL을 보내겠지만 채택될 가능성은 거의 없습니다.

CL https://golang.org/cl/38731 에 이 문제가 언급되어 있습니다.

@andrewcmyers

aType 유형에 주어진 정보에서 + 연산이 있는지 알 수 있는 방법이 없기 때문에 모듈식 방식으로 유형 검사를 하지 않습니다.

물론 있습니다. 그 제약 조건은 함수 정의에 암시적이며 해당 형식의 제약 조건은 getAddFunc 의 모든 (전이) 컴파일 타임 호출자에게 전파될 수 있습니다.

제약 조건은 Go _type_의 일부가 아닙니다. 즉, 언어의 런타임 부분의 유형 시스템에서 인코딩할 수 없습니다. 그러나 이것이 모듈 방식으로 평가될 수 없다는 것을 의미하지는 않습니다.

내 제안을 2016-09-compile-time-functions.md 로 추가했습니다.

채택되리라고는 기대하지 않지만 최소한 흥미로운 기준점으로 작용할 수 있을 것입니다.

@bcmills 제네릭에 대한 고려를 제외하고 컴파일 시간 함수는 강력한 아이디어라고 생각합니다. 예를 들어, 나는 popcount가 필요한 스도쿠 솔버를 작성했습니다. 속도를 높이기 위해 가능한 다양한 값에 대한 팝카운트를 미리 계산하고 Go 소스 로 저장했습니다. 이것은 go:generate 로 할 수 있는 것입니다. 그러나 컴파일 시간 함수가 있는 경우 해당 조회 테이블은 컴파일 시간에 계산되어 기계 생성 코드가 리포지토리에 커밋되지 않도록 할 수 있습니다. 일반적으로 기억할 수 있는 수학 함수는 컴파일 시간 함수가 있는 미리 만들어진 조회 테이블에 적합합니다.

더 추측적으로 말하면, 예를 들어 표준 소스에서 protobuf 정의를 다운로드하고 이를 사용하여 컴파일 타임에 유형을 빌드할 수도 있습니다. 그러나 컴파일 타임에 허용하기에는 너무 많은 작업이 아닐까?

컴파일 시간 함수는 너무 강력하면서도 동시에 너무 약하다고 느낍니다. 너무 유연하고 이상한 방식으로 오류가 발생할 수 있습니다. / C++ 템플릿이 수행하는 방식으로 컴파일 속도가 느려지지만 다른 한편으로는 너무 정적이고 일류 기능과 같은 것에 적응하십시오.

두 번째 부분에서는 "특정 유형의 조각을 처리하고 하나의 요소를 반환하는 함수 조각"이나 임시 구문 []func<T>([]T) T 과 같은 것을 만들 수 있는 방법이 없습니다. 본질적으로 모든 정적으로 유형이 지정된 기능 언어에서 수행하기가 매우 쉽습니다. 실제로 필요한 것은 일부 소스 코드 수준 코드 생성이 아니라 매개변수 유형을 취할 수 있는 값 입니다.

@분심

두 번째 부분에서는 "특정 유형의 조각을 처리하고 하나의 요소를 반환하는 함수 조각"과 같은 것을 만들 수 있는 방법이 없습니다.

단일 유형 매개변수에 대해 이야기하는 경우 내 제안에서 다음과 같이 작성합니다.

const func SliceOfSelectors(T gotype) gotype { return []func([]T)T (type) }

유형 매개변수와 값 매개변수를 혼합하는 것에 대해 이야기하고 있다면 제 제안은 이를 허용하지 않습니다. 컴파일 시간 함수의 일부는 unboxed 값과 런타임 매개변수의 종류에 대해 작동할 수 있다는 것입니다. 나는 당신이 설명하는 것이 값의 권투를 필요로 한다고 생각합니다.

네, 하지만 제 생각에는 "boxedness"를 나타내는 특수 구문을 사용하여 type-safety를 유지하면서 boxing이 필요한 종류의 것을 허용해야 한다고 생각합니다. "제네릭" 추가의 큰 부분은 interface{} 의 오버헤드를 피할 수 없는 경우에도 interface{} 의 유형-불안전성을 실제로 방지하는 것입니다. (아마도 "이미" 박싱된 포인터 및 인터페이스 유형이 있는 특정 매개변수 유형 구성만 허용할 수 있습니까? Java의 Integer 등 boxed 객체는 값 유형 조각이 까다롭지만 완전히 나쁜 생각은 아닙니다.)

컴파일 타임 함수가 C++과 매우 유사하며 Go2가 작성된 소스 코드 조작에 기반한 해킹보다는 사운드 유형 이론에 기반을 둔 최신 매개변수 유형 시스템을 갖기를 기대하는 나 같은 사람들에게는 매우 실망스러울 것입니다. 제네릭이 없는 언어로.

@bcmills
당신이 제안하는 것은 모듈화되지 않을 것입니다. 모듈 A가 모듈 D를 사용하는 모듈 C를 사용하는 모듈 B를 사용하는 경우, A의 구현자가 D를 알지 못하더라도 D에서 유형 매개변수가 사용되는 방식에 대한 변경 사항을 A로 다시 전파해야 할 수 있습니다. 시스템에 있습니다. 모듈 시스템이 제공하는 느슨한 결합은 약해지고 소프트웨어는 더 부서지기 쉽습니다. 이것은 C++ 템플릿의 문제 중 하나입니다.

반면에 CLU, ML, Haskell 또는 Genus와 같은 언어에서와 같이 유형 서명이 유형 매개변수에 대한 요구 사항을 캡처하는 경우 종속된 모듈의 내부에 액세스하지 않고도 모듈을 컴파일할 수 있습니다.

@분심

"제네릭" 추가의 큰 부분은 실제로 인터페이스의 오버헤드를 피할 수 없는 경우에도{}인터페이스의 유형 안전하지 않음을 피하는 것입니다.

"피할 수 없는"은 상대적입니다. 권투의 오버헤드는 2009년 Russ의 게시물(https://research.swtch.com/generic)에서 3번 항목입니다.

Go2가 소스 코드 조작에 기반한 해킹보다는 사운드 유형 이론에 기반을 둔 현대적인 매개변수 유형 시스템을 갖기를 기대합니다.

좋은 "소리 유형 이론"은 규범적이지 않고 서술적입니다. 내 제안은 특히 gotype 가 type 종류를 나타내고 전체 1차 유형 시스템이 두 번째 시스템으로 호이스팅되는 2차 람다 미적분학(시스템 F 라인을 따라)에서 가져옵니다. -order("컴파일 타임") 유형.

또한 CMU의 Davies, Pfenning 등의 모달 유형 이론 작업과도 관련이 있습니다. 몇 가지 배경 지식 을 위해 런타임 코드 생성을 위한 스테이징 사양으로 스테이징 된 계산 및 모달 유형의 모달 분석으로 시작하겠습니다.

내 제안의 기본 유형 이론이 학술 문헌보다 덜 형식적으로 지정되어 있는 것이 사실이지만 그것이 없다는 것을 의미하지는 않습니다.

@andrewcmyers

모듈 A가 모듈 D를 사용하는 모듈 C를 사용하는 모듈 B를 사용하는 경우 A의 구현자가 D를 알지 못하더라도 D에서 유형 매개변수가 사용되는 방식에 대한 변경 사항을 A로 다시 전파해야 할 수 있습니다. 시스템에 있습니다.

그것은 오늘날 Go에서 이미 사실입니다. 주의 깊게 살펴보면 주어진 Go 패키지에 대해 컴파일러가 생성한 개체 파일에 내보낸 API에 영향을 미치는 전이적 종속성 부분에 대한 정보가 포함되어 있음을 알 수 있습니다.

모듈 시스템이 제공하는 느슨한 결합은 약해지고 소프트웨어는 더 부서지기 쉽습니다.

Go API에서 구체적인 유형이 아닌 interface 유형을 내보내는 것을 옹호하는 데 동일한 주장이 사용되었다고 들었고 그 반대의 경우가 더 일반적입니다. 조기 추상화는 유형을 과도하게 제한하고 API의 확장을 방해합니다. (이러한 예 중 하나는 #19584를 참조하십시오.) 이 주장에 의존하려면 몇 가지 구체적인 예를 제공해야 한다고 생각합니다.

이것은 C++ 템플릿의 문제 중 하나입니다.

내가 보기에 C++ 템플릿의 주요 문제는 다음과 같습니다(특정 순서 없음).

• 과도한 구문 모호성.
  ㅏ. 유형 이름과 값 이름 사이의 모호성.
  비. 연산자 과부하에 대한 지나치게 광범위한 지원으로 인해 연산자 사용에서 제약 조건을 추론하는 능력이 약화됩니다.
• 메타프로그래밍을 위한 과부하 해결에 대한 과도한 의존(또는 동등하게 메타프로그래밍 지원의 임시 진화).
  ㅏ. 특히 wrt 참조 축소 규칙.
• SFINAE 원칙을 지나치게 광범위하게 적용하여 전파하기 매우 어려운 제약 조건과 유형 정의에 너무 많은 암시적 조건이 발생하여 오류 보고가 매우 어렵습니다.
• AST 대체 및 고차 컴파일 아티팩트 대신 토큰 붙여넣기 및 텍스트 포함(C 전처리기)을 남용합니다(다행히도 모듈로 적어도 부분적으로 해결되는 것으로 보입니다).
• C++ 컴파일러를 위한 좋은 부트스트래핑 언어가 부족하여 수명이 긴 컴파일러 계보(예: GCC 도구 체인)에서 잘못된 오류 보고가 발생합니다.
• 연산자 집합을 다른 이름의 "개념"에 매핑하여 이름이 두 배로(때로는 곱하기) (연산자 자체를 기본 제약으로 취급하는 대신) 이름이 다릅니다.

저는 10년 동안 계속해서 C++로 코딩해 왔으며 C++의 결함에 대해 길게 논의하게 되어 기쁩니다.

반면에 모듈 A의 유형에 단일 메소드를 추가하고 모듈 D에서 사용할 수 있도록 O(N) 종속성 체인을 업데이트해야 합니까? 그것은 정기적으로 나를 느리게 만드는 종류의 문제입니다. 매개변수와 느슨한 결합이 충돌하는 경우에는 언제든지 매개변수를 선택합니다.

그래도 나는 메타프로그래밍과 파라메트릭 다형성을 분리해야 한다고 굳게 믿고 있으며, C++의 혼동이 C++ 템플릿이 짜증나는 근본 원인입니다. 간단히 말해서, C++는 스테로이드에서 본질적으로 매크로를 사용하여 유형 이론 아이디어를 구현하려고 시도합니다. 이는 프로그래머가 템플릿을 실제 매개변수 다형성으로 생각하고 예기치 않은 동작에 영향을 받기 때문에 매우 문제가 됩니다. 컴파일 타임 함수는 메타프로그래밍과 go generate 해킹을 대체하기 위한 좋은 아이디어이지만 제네릭 프로그래밍을 수행하는 축복된 방법이 되어야 한다고 생각하지 않습니다.

"실제" 매개변수 다형성 은 느슨한 결합을 돕고 충돌하지 않아야 합니다. 또한 나머지 유형 시스템과 긴밀하게 통합되어야 합니다. 예를 들어 현재 인터페이스 시스템에 통합되어야 인터페이스 유형의 많은 용도를 다음과 같이 다시 작성할 수 있습니다.

func <T io.Reader> ReadAll(in T)

이것은 (Rust의 사용법과 같은) 인터페이스 오버헤드를 피해야 하지만 이 경우에는 별로 유용하지 않습니다.

더 좋은 예는 sort 패키지일 수 있습니다.

func <T Comparable> Sort(slice []T)

여기서 Comparable 는 단순히 유형이 구현할 수 있는 오래된 인터페이스입니다. 그런 다음 Comparable 를 구현하는 값 유형 조각에서 $#$ Sort $#$ 를 인터페이스 유형으로 묶지 않고 호출할 수 있습니다.

@bcmills 유형 시스템에 의해 제한되지 않는 전이적 종속성은 C++에 대한 귀하의 불만 중 일부가 핵심이라고 생각합니다. 모듈 A, B, C 및 D를 제어하는 ​​경우 전이 종속성은 그다지 문제가 되지 않습니다. 일반적으로 모듈 A를 개발 중이며 모듈 D가 아래에 있다는 것을 약하게만 인식할 수 있으며 반대로 D의 개발자는 이제 모듈 D가 D에서 볼 수 있는 선언을 변경하지 않고 유형 매개변수에 대해 일부 새 연산자를 사용하기 시작하거나 해당 유형 매개변수를 고유한 새 모듈 E에 대한 유형 인수로 사용하는 경우 암시적 제약 조건 - 이러한 제약 조건은 제약 조건을 충족하는 형식 인수를 사용하지 않을 수 있는 모든 클라이언트에 침투합니다. 아무 것도 개발자 D에게 그들이 그것을 날리고 있다고 말하지 않습니다. 사실상, 디버깅의 모든 어려움과 함께 일종의 전역 유형 유추를 갖게 됩니다.

나는 속[ PLDI'15 ]에서 우리가 취한 접근 방식이 훨씬 더 낫다고 믿습니다. 형식 매개변수에는 명시적이지만 가벼운 제약 조건이 있습니다(작동 제약 조건 지원에 대한 귀하의 요점을 이해합니다. CLU는 1977년에 이를 올바르게 수행하는 방법을 보여주었습니다). 속 유형 검사는 완전 모듈식입니다. 일반 코드는 코드 공간을 최적화하기 위해 한 번만 컴파일되거나 우수한 성능을 위해 특정 유형 인수에 특화될 수 있습니다.

@andrewcmyers

이제 모듈 D가 D에서 볼 수 있는 선언을 변경하지 않고 형식 매개변수 […]에 대해 일부 새 연산자를 사용하기 시작하면 [클라이언트]가 제약 조건을 충족하는 형식 인수를 사용하지 않을 수 있습니다. 아무 것도 개발자 D에게 그들이 그것을 날리고 있다고 말하지 않습니다.

물론, 하지만 이는 이미 일반 프로그래밍 메커니즘과 독립적인 Go의 많은 암시적 제약 조건에 대해 사실입니다.

예를 들어, 함수는 인터페이스 유형의 매개변수를 수신하고 초기에 해당 메소드를 순차적으로 호출할 수 있습니다. 해당 함수가 나중에 이러한 메서드를 동시에 호출하도록 변경되면(추가 고루틴을 생성하여) "동시 사용에 안전해야 함" 제약 조건이 유형 시스템에 반영되지 않습니다.

마찬가지로, 오늘날 Go 유형 시스템은 변수 수명에 대한 제약을 지정하지 않습니다. io.Writer 의 일부 구현은 전달된 슬라이스에 대한 참조를 유지하고 나중에 읽을 수 있다고 잘못 가정합니다(예: 실제 쓰기를 비동기식으로 수행하여 백그라운드 고루틴에서) 그러나 Write 호출자가 후속 Write 에 대해 동일한 백업 슬라이스를 재사용하려고 하면 데이터 경쟁이 발생합니다.

또는 유형 스위치를 사용하는 함수가 스위치의 유형 중 하나에 추가된 메소드의 다른 경로를 취할 수 있습니다.

또는 오류를 생성하는 함수가 해당 조건을 보고하는 방식을 변경하면 특정 오류 코드를 검사하는 함수가 중단될 수 있습니다. (예를 들어 https://github.com/golang/go/issues/19647을 참조하세요.)

또는 오류 주변의 래퍼가 추가되거나 제거되면 특정 오류 유형을 확인하는 기능이 중단될 수 있습니다(Go 1.5의 표준 net 패키지에서 발생한 것처럼).

또는 API에 노출된 채널의 버퍼링이 변경되어 교착 상태 및/또는 경합이 발생할 수 있습니다.

...등등.

Go는 이와 관련하여 드문 일이 아닙니다. 암시적 제약 조건은 실제 프로그램에서 도처에 있습니다.

명시적 주석에서 모든 관련 제약 조건을 캡처하려고 하면 결국 두 가지 방향 중 하나로 가게 됩니다.

한 방향으로, 종속 유형 및 주석으로 구성된 복잡하고 매우 포괄적인 시스템을 구축하면 주석이 주석을 추가하는 코드의 상당 부분을 요약하게 됩니다. 분명히 알 수 있듯, 그 방향은 나머지 Go 언어의 디자인과 전혀 일치하지 않습니다. Go는 포괄적인 정적 타이핑보다 사양 단순성과 코드 간결성을 선호합니다.

다른 방향에서 명시적 주석은 주어진 API에 대한 관련 제약의 하위 집합만 다룰 것입니다. 이제 주석은 잘못된 보안 감각을 제공합니다. 암시적 제약 조건의 변경으로 인해 코드가 여전히 손상될 수 있지만 명시적 제약 조건이 있으면 개발자가 "유형 안전" 변경 사항도 호환성을 유지한다고 생각하도록 오도합니다.

명시적 소스 코드 주석을 통해 이러한 종류의 API 안정성을 달성해야 하는 이유는 나에게 분명하지 않습니다. 설명하는 API 안정성은 소스 코드 분석을 통해 (코드의 중복성을 줄이면서) 달성할 수도 있습니다. 예를 들어, api 도구 가 코드를 분석하고 언어의 형식 시스템에서 표현할 수 있는 것보다 훨씬 더 풍부한 제약 조건 집합을 출력하도록 하고 guru 도구 에 다음을 제공하는 것을 상상할 수 있습니다. 주어진 API 함수, 메서드 또는 매개변수에 대해 계산된 제약 조건 집합을 쿼리하는 기능.

@bcmills 완벽을 선의 적으로 만들고 있지 않습니까? 예, 유형 시스템에서 캡처하기 어려운 암시적 제약 조건이 있습니다. (그리고 좋은 모듈식 설계는 가능한 경우 그러한 암시적 제약을 도입하지 않습니다.) 확인하려는 모든 속성을 정적으로 확인할 수 있는 포괄적인 분석이 있으면 좋을 것입니다. 실수를 하고 있다. 최근 자동 오류 진단 및 현지화 진행 에도 불구하고 숨이 가쁘지 않습니다. 우선 분석 도구는 사용자가 제공한 코드만 분석할 수 있습니다. 개발자는 자신과 연결될 수 있는 모든 코드에 항상 액세스할 수 있는 것은 아닙니다.

유형 시스템에서 쉽게 포착할 수 있는 제약 조건이 있는 곳에서 프로그래머에게 이를 기록할 수 있는 기능을 제공하지 않는 이유는 무엇입니까? 우리는 정적으로 제한된 유형 매개변수로 프로그래밍한 40년의 경험을 가지고 있습니다. 이것은 효과가 있는 간단하고 직관적인 정적 주석입니다.

소프트웨어 모듈을 계층화하는 더 큰 소프트웨어를 구축하기 시작하면 어쨌든 그러한 암시적 제약을 설명하는 주석을 작성하기 시작합니다. 그것을 표현할 수 있는 훌륭하고 확인 가능한 방법이 있다고 가정하면 컴파일러가 농담을 하도록 하여 도움이 될 수 있도록 하지 않겠습니까?

다른 암시적 제약 조건의 일부 예에는 오류 처리가 포함됩니다. 예외에 대한 경량 정적 검사[ PLDI 2016 ]가 이러한 예를 해결할 것이라고 생각합니다.

@andrewcmyers

유형 시스템에서 쉽게 포착할 수 있는 제약 조건이 있는 곳에서 프로그래머에게 이를 기록할 수 있는 기능을 제공하지 않는 이유는 무엇입니까?
[…]
소프트웨어 모듈을 계층화하는 더 큰 소프트웨어를 구축하기 시작하면 어쨌든 그러한 암시적 제약을 설명하는 주석을 작성하기 시작합니다. 그것을 표현할 수 있는 훌륭하고 확인 가능한 방법이 있다고 가정하면 컴파일러가 농담을 하도록 하여 도움이 될 수 있도록 하지 않겠습니까?

사실 이 점에 전적으로 동의하며 메모리 관리와 관련하여 종종 비슷한 주장을 사용합니다. (어쨌든 데이터의 앨리어싱 및 보존에 대한 불변성을 문서화해야 하는 경우 컴파일 타임에 이러한 불변성을 적용하지 않는 이유는 무엇입니까?)

그러나 나는 그 주장을 한 단계 더 발전시킬 것입니다. 그 반대도 성립합니다! 제약 조건에 대한 주석을 작성할 필요가 _없다_면(코드로 작업하는 사람에게 컨텍스트에서 명백하기 때문에) 컴파일러에 대해 해당 주석을 작성해야 하는 이유는 무엇입니까? 내 개인적인 취향에 관계없이 Go의 가비지 수집 및 0 값 사용은 "프로그래머에게 명백한 불변성을 명시하지 않아도 됨"에 대한 편견을 분명히 나타냅니다. Genus 스타일 모델링이 주석으로 표현될 많은 제약을 표현할 수 있는 경우일 수 있지만 주석에서도 생략될 제약을 제거한다는 측면에서 어떻게 됩니까?

제 생각에 Genus 스타일 모델은 단순한 주석 그 이상인 것 같습니다. 어떤 경우에는 실제로 코드의 의미를 변경하지만 단지 제한하지 않습니다. 이제 우리는 행동을 매개변수화하기 위해 인터페이스와 유형 모델이라는 두 가지 다른 메커니즘을 갖게 됩니다. 이는 Go 언어의 주요 변화를 나타냅니다. 우리는 시간이 지남에 따라 인터페이스에 대한 몇 가지 모범 사례(예: "소비자 측에서 인터페이스 정의")를 발견했으며 그 경험이 근본적으로 다른 시스템으로 번역될지는 분명하지 않습니다. Go 1 호환성을 무시합니다.

또한 Go의 뛰어난 속성 중 하나는 사양을 오후에 읽을 수 있다는 것입니다(대부분 이해할 수 있음). Genus 스타일의 제약 조건 시스템이 Go 언어를 크게 복잡하게 만들지 않고 추가할 수 있다는 것은 분명하지 않습니다. 사양 변경에 대한 구체적인 제안이 궁금할 것입니다.

다음은 "메타프로그래밍"에 대한 흥미로운 데이터 포인트입니다. sync 및 atomic 패키지의 특정 유형(즉, atomic.Value 및 sync.Map )에서 CompareAndSwap 메서드를 지원하는 것이 좋습니다. 그러나 그것들은 우연히 비교될 수 ​​있는 유형에 대해서만 작동합니다. 나머지 atomic.Value 및 sync.Map API는 이러한 메서드 없이도 유용하므로 해당 사용 사례의 경우 SFINAE(또는 다른 종류의 조건부 정의 API)와 같은 것이 필요하거나 더 복잡한 유형의 계층 구조로 돌아갑니다.

나는 원주민 음절을 사용하는 이 창의적인 구문 아이디어 를 버리고 싶습니다.

@bcmills 이 세 가지 사항에 대해 자세히 설명해 주시겠습니까?

1. 유형 이름과 값 이름 사이의 모호성.
2. 연산자 오버로딩에 대한 지나치게 광범위한 지원
   3.메타프로그래밍을 위한 과부하 해결에 대한 과도한 의존

@mahdix 물론입니다.

1. 유형 이름과 값 이름 사이의 모호성.

이 기사 는 좋은 소개를 제공합니다. C++ 프로그램을 구문 분석하려면 어떤 이름이 유형이고 어떤 이름이 값인지 알아야 합니다. 템플릿 C++ 프로그램을 구문 분석할 때 템플릿 매개 변수의 구성원에 대해 해당 정보를 사용할 수 없습니다.

Go에서 합성 리터럴에 대해 비슷한 문제가 발생하지만 모호성은 값과 유형이 아니라 값과 필드 이름 사이에 있습니다. 이 Go 코드에서:

const a = someValue
x := T{a: b}

a 은 리터럴 필드 이름입니까, 아니면 맵 키 또는 배열 인덱스로 사용되는 상수 a 입니까?

1. 연산자 오버로딩에 대한 지나치게 광범위한 지원

인수 종속 조회 는 시작하기에 좋은 곳입니다. C++에서 연산자 오버로드는 수신기 유형의 메서드 또는 여러 네임스페이스의 자유 함수로 발생할 수 있으며 이러한 오버로드를 해결하기 위한 규칙은 매우 복잡합니다.

이러한 복잡성을 피하는 방법은 여러 가지가 있지만 가장 간단한 방법은 현재 Go에서와 같이 연산자 오버로딩을 완전히 허용하지 않는 것입니다.

1. 메타프로그래밍을 위한 과부하 해결에 대한 과도한 의존

<type_traits> 라이브러리는 시작하기에 좋은 곳입니다. 과부하 해결이 어떻게 작동하는지 보려면 친숙한 이웃 libc++ 의 구현을 확인하십시오.

Go가 메타프로그래밍을 지원한다면(심지어 그것이 매우 의심스럽습니다), 조건부 정의를 보호하기 위한 기본 작업으로 과부하 해결을 포함하지 않을 것입니다.

@bcmills
C++를 사용한 적이 없기 때문에 사전 정의된 '인터페이스' 구현을 통한 연산자 오버로딩이 복잡성 측면에서 어느 정도 의미가 있는지 설명해 주시겠습니까? Python과 Kotlin이 그 예입니다.

ADL 자체는 대부분 언급되지 않은 C++ 템플릿의 큰 문제라고 생각합니다. 왜냐하면 컴파일러가 인스턴스화 시간까지 모든 이름의 확인을 지연시키고 부분적으로 "이상적인" 및 " 게으른" 컴파일러는 여기에서 다르게 동작하며 표준이 허용합니다. 연산자 오버로딩을 지원한다는 사실은 지금까지 가장 나쁜 부분이 아닙니다.

이 제안은 템플릿을 기반으로 하며 매크로 확장을 위한 시스템으로는 충분하지 않습니까? go generate 나 gotemplate과 같은 프로젝트에 대해 말하는 것이 아닙니다. 나는 이것에 대해 더 이야기하고 있습니다.

macro MacroFoo(stmt ast.Statement) {
    ....
}

매크로는 상용구와 리플렉션 사용을 줄일 수 있습니다.

C++는 제네릭이 템플릿이나 매크로를 기반으로 해서는 안 되는 좋은 예라고 생각합니다. 특히 Go가 최적화를 제외하고 컴파일 타임에 "인스턴스화"될 수 없는 익명 함수와 같은 것을 가지고 있다는 것을 고려하면.

@samadadi 당신은 "당신들에게 무엇이 문제인가"라고 말하지 않고 당신의 요점을 전달할 수 있습니다. 그러나 복잡성에 대한 주장은 이미 여러 번 제기되었습니다.

Go는 지난 40년 동안 그 기능이 점점 더 중요해지고 있음에도 불구하고 매개변수 다형성(제네릭)에 대한 지원을 생략하여 단순성을 달성하려는 첫 번째 언어가 아닙니다. 제 경험에 따르면 2학기 프로그래밍 과정의 필수 언어입니다.

언어에 기능이 없는 문제는 프로그래머가 결국 더 나쁜 해결 방법에 의존하게 된다는 것입니다. 예를 들어, Go 프로그래머는 다양한 원하는 유형에 대한 "실제" 코드를 생성하기 위해 매크로 확장되는 코드 템플릿을 작성하는 경우가 많습니다. 그러나 실제 프로그래밍 언어는 컴파일러가 보는 언어가 아니라 사용자가 입력하는 언어입니다. 따라서 이 전략은 C++ 템플릿의 모든 취약성과 코드 팽창이 있는 (더 이상 표준이 아닌) 언어를 사용하고 있음을 의미합니다.

https://blog.golang.org/toward-go2 에 언급된 대로 "경험 보고서"를 제공해야 필요성과 설계 목표를 결정할 수 있습니다. 잠시 시간을 내어 관찰한 거시적 사례를 기록해 주시겠습니까?

이 버그를 주제 및 시민으로 유지하십시오. 그리고 다시, https://golang.org/wiki/NoMeToo. 추가할 독특하고 건설적인 정보가 있는 경우에만 의견을 말하십시오.

@mandolyte 제네릭에 대한 (부분) 대체물로 코드 생성을 옹호하는 웹에서 자세한 설명을 찾는 것은 매우 쉽습니다.
https://appliedgo.net/generics/
https://www.calhoun.io/using-code-generation-to-survive-without-generics-in-go/
http://blog.ralch.com/tutorial/golang-code-generation-and-generics/

분명히 많은 사람들이 이 접근 방식을 취하고 있습니다.

@andrewcmyers , 코드 생성을 사용할 때 몇 가지 제한 사항과 편의상 주의 사항이 있습니다.
일반적으로 - 이 접근 방식이 최고/충분히 좋다고 생각한다면 go 도구 체인 내에서 다소 유사한 생성을 허용하려는 노력이 축복이 될 것이라고 생각합니다.

• 이 경우 컴파일러 최적화가 어려울 수 있지만 런타임은 일관되고 코드 유지 관리, 사용자 경험(단순성...), 표준 모범 사례 및 통합 코드 표준이 유지될 수 있습니다.
  또한 - 개발자가 작성하지 않은 코드 라인을 볼 디버깅 도구(프로파일러, 단계 디버거 등)를 제외하고 모든 도구 체인은 동일하게 유지되지만 디버깅하는 동안 ASM 코드로 들어가는 것과 약간 비슷합니다. 읽을 수 있는 코드입니다 :) .

단점 - go 도구 체인 내에서 이 접근 방식에 대한 전례가 없습니다.

요약하자면, 코드 생성을 빌드 프로세스의 일부로 고려하십시오. 너무 복잡하지 않고 매우 안전하며 런타임에 최적화되어 있으며 단순성을 유지할 수 있고 언어에서 매우 작은 변경이 가능합니다.

IMHO: 저렴한 가격으로 쉽게 타협할 수 있습니다.

명확히 하자면, gen, cpp, gofmt -r 또는 기타 매크로/템플릿 도구로 수행되는 매크로 스타일 코드 생성이 표준화되더라도 제네릭 문제에 대한 좋은 솔루션이라고 생각하지 않습니다. C++ 템플릿과 동일한 문제가 있습니다: 코드 팽창, 모듈식 유형 검사 부족, 디버깅 어려움. 다른 제네릭 코드의 관점에서 제네릭 코드를 빌드하는 것은 자연스러운 것처럼 시작할수록 악화됩니다. 내 생각에 장점은 제한적입니다. Go 컴파일러 작성자의 삶을 비교적 단순하게 유지하고 효율적인 코드를 생성합니다. 명령 캐시 압력이 없는 한 최신 소프트웨어에서 자주 발생하는 상황입니다!

요점은 코드 생성이
따라서 제네릭은 이러한 사용 사례의 대부분을 해결해야 합니다.

2017년 7월 26일 수요일 22:41 Andrew Myers, 알림 @github.com 작성:

분명히 말해서, 나는 매크로 스타일 코드 생성을 고려하지 않습니다.
gen, cpp, gofmt -r 또는 기타 매크로/템플릿 도구를 사용하여
표준화된 경우에도 제네릭 문제에 대한 솔루션입니다. 그것은 같은
C++ 템플릿으로서의 문제: 코드 팽창, 모듈식 유형 검사 부족,
디버깅 어려움. 건물을 짓기 시작하면 할수록 악화됩니다.
다른 제네릭 코드의 관점에서 제네릭 코드. 제가 생각하는 장점은
제한적: Go 컴파일러 작성자의 삶을 비교적 단순하게 유지합니다.
명령어 캐시가 없는 한 효율적인 코드를 생성합니다.
압력, 현대 소프트웨어의 빈번한 상황!

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/15292#issuecomment-318242016 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AT4HVb2SPMpe5dlEDUQeadIRKPaB74zoks5sR_jSgaJpZM4IG-xv
.

의심할 여지 없이 코드 생성은 "언어의 일부"로 모양과 느낌을 만들기 위해 일부 언어 지원으로 마무리되더라도 실제 솔루션이 아닙니다.

제 요점은 매우 비용 효율적이었습니다.

Btw, 코드 생성 대체품 중 일부를 보면 언어가 더 나은 도구를 제공했다면 훨씬 더 읽기 쉽고 빠르며 잘못된 개념(예: 포인터 배열 대 값 반복)이 없었을 수 있음을 쉽게 알 수 있습니다. 이것을 위해.

그리고 아마도 그것이 패치처럼 느껴지지 않을 단기적으로 해결하기에 더 나은 방법일 것입니다.
"가는 것이 관용적일 수 있는 최고의 제네릭 지원"을 생각하기 전에(위의 일부 구현은 완전한 통합을 달성하는 데 몇 년이 걸릴 것이라고 생각합니다) 어쨌든 필요한 "언어로" 지원되는 일부 기능 세트를 구현합니다(예: 구조 딥 카피)를 사용하면 이러한 코드 생성 솔루션을 훨씬 더 유용하게 사용할 수 있습니다.

@bcmills 및 @ianlancetaylor 의 제네릭 제안을 읽은 후 다음과 같은 관찰을 했습니다.

컴파일 타임 함수와 퍼스트 클래스 타입

나는 컴파일 타임 평가라는 아이디어를 좋아하지만 순수 함수로 제한하는 것의 이점을 보지 못합니다. 이 제안은 내장 gotype 를 도입하지만 const 함수와 함수 범위 내에서 정의된 모든 데이터 유형으로 사용을 제한합니다. 라이브러리 사용자의 관점에서 인스턴스화는 "New"와 같은 생성자 함수로 제한되며 다음과 같은 함수 서명으로 이어집니다.

const func New(K, V gotype, hashfn Hashfn(K), eqfn Eqfn(K)) func()*Hashmap(K, V, hashfn, eqfn)

여기서 반환 유형은 순수 함수로 제한되기 때문에 함수 유형으로 분리할 수 없습니다. 또한 서명은 서명 자체에 두 개의 새로운 "유형"(K 및 V)을 정의합니다. 즉, 단일 매개변수를 구문 분석하려면 전체 매개변수 목록을 구문 분석해야 합니다. 이것은 컴파일러에는 문제가 없지만 패키지의 공개 API에 복잡성이 추가되는지 궁금합니다.

Go의 유형 매개변수

매개변수화된 유형은 일반 프로그래밍의 대부분의 사용 사례를 허용합니다(예: 일반 데이터 구조 및 다양한 데이터 유형에 대한 연산을 정의하는 기능). 제안은 더 나은 컴파일 오류, 더 빠른 컴파일 시간 및 더 작은 바이너리를 생성하는 데 필요한 유형 검사기의 개선 사항을 철저하게 나열합니다.

"유형 검사기" 섹션에서 제안은 "인덱싱 가능", "비교 가능", "호출 가능", "복합" 등과 같이 프로세스 속도를 높이는 몇 가지 유용한 유형 제한을 나열합니다. 내가 이해하지 못하는 것은 사용자가 자신의 유형 제한을 지정하도록 허용하지 않는 이유는 무엇입니까? 제안서에는 다음과 같이 나와 있습니다.

매개변수화된 함수에서 매개변수화된 유형을 사용하는 방법에는 제한이 없습니다.

그러나 식별자에 더 많은 제약 조건이 연결되어 있으면 컴파일러를 지원하는 효과가 있지 않을까요? 고려하다:

HashMap[Anything,Anything] // Compiler must always compare the implementation and usages to make sure this is valid.

대

HashMap[Comparable,Anything] // Compiler can first filter out instantiations for incomparable types before running an exhaustive check.

유형 매개변수에서 유형 제약 조건을 분리하고 사용자 정의 제약 조건을 허용하면 가독성이 향상되어 일반 패키지를 더 쉽게 이해할 수 있습니다. 흥미롭게도, 유형 연역 규칙의 복잡성과 관련하여 제안 끝에 나열된 결함은 해당 규칙이 사용자에 의해 명시적으로 정의된 경우 실제로 완화될 수 있습니다.

@smasher164

나는 컴파일 타임 평가라는 아이디어를 좋아하지만 순수 함수로 제한하는 것의 이점을 보지 못합니다.

이점은 별도의 컴파일이 가능하다는 것입니다. 컴파일 타임 함수가 전역 상태를 수정할 수 있는 경우 컴파일러는 해당 상태를 사용할 수 있거나 링커가 링크 타임에 순서를 지정할 수 있는 방식으로 편집 내용을 저널링해야 합니다. 컴파일 타임 함수가 로컬 상태를 수정할 수 있다면 어떤 상태가 로컬인지 전역인지 추적하는 방법이 필요합니다. 둘 다 복잡성을 추가하고 어느 쪽이 이를 상쇄할 만큼 충분한 이점을 제공할지는 분명하지 않습니다.

@smasher164

내가 이해할 수 없는 것은 사용자가 자신의 유형 제한을 지정하도록 허용하지 않는 이유입니다.

해당 제안의 유형 제한은 언어 구문의 작업에 해당합니다. 이는 새로운 기능의 표면적을 줄입니다. 모든 구문적 제약이 사용법에서 유추될 수 있기 때문에 유형을 제약하기 위해 추가 구문을 지정할 필요가 없습니다.

식별자에 더 많은 제약 조건이 연결되어 있으면 컴파일러를 지원하는 효과가 있지 않을까요?

언어는 컴파일러 작성자가 아니라 사용자를 위해 설계되어야 합니다.

모든 구문 제약이 사용법에서 추론될 수 있기 때문에 제약 유형을 위한 추가 구문을 지정할 필요가 없습니다.

이것은 C++이 내려간 경로입니다. 관련 용도를 식별하려면 글로벌 프로그램 분석이 필요합니다. 코드는 모듈식 방식으로 프로그래머가 추론할 수 없으며 오류 메시지는 장황하고 이해할 수 없습니다.

필요한 작업을 지정하는 것은 매우 쉽고 간단할 수 있습니다. 예를 들어 CLU(1977)를 참조하십시오.

@andrewcmyers

관련 용도를 식별하려면 글로벌 프로그램 분석이 필요합니다. 코드는 프로그래머가 모듈 방식으로 추론할 수 없습니다.

그것은 "모듈식"의 특정 정의를 사용하고 있습니다. 귀하가 가정하는 것만큼 보편적이지 않다고 생각합니다. 2013년 제안에 따라 각 기능 또는 유형은 비모수적 기능의 런타임(및 런타임 제한)이 하단에서 파생되는 것과 똑같은 방식으로 가져온 패키지에서 상향식으로 추론된 명확한 제약 조건 세트를 갖습니다. 오늘 콜 체인에서 올라갑니다.

guru 또는 유사한 도구를 사용하여 추론된 제약 조건을 쿼리할 수 있으며 내보낸 패키지 메타데이터의 로컬 정보를 사용하여 해당 쿼리에 응답할 수 있습니다.

오류 메시지는 장황하고 이해할 수 없습니다.

우리는 순진하게 생성된 오류 메시지가 이해할 수 없다는 것을 보여주는 몇 가지 예(GCC 및 MSVC)가 있습니다. 암시적 제약 조건에 대한 오류 메시지가 본질적으로 나쁘다고 가정하는 것은 무리라고 생각합니다.

유추된 제약 조건의 가장 큰 단점은 완전히 이해하지 않고도 제약 조건을 도입하는 방식으로 유형을 사용하기 쉽게 만든다는 것입니다. 최상의 경우 이는 사용자가 예기치 않은 컴파일 시간 오류에 직면할 수 있음을 의미하지만 최악의 경우 실수로 새로운 제약 조건을 도입하여 소비자를 위해 패키지를 중단할 수 있음을 의미합니다. 명시적으로 지정된 제약 조건은 이를 방지합니다.

나는 또한 개인적으로 명시적 제약이 기존 Go 접근 방식과 일치하지 않는다고 생각하지 않습니다. 인터페이스가 명시적 런타임 유형 제약이기 때문입니다.

우리는 순진하게 생성된 오류 메시지가 이해할 수 없다는 것을 보여주는 몇 가지 예(GCC 및 MSVC)가 있습니다. 암시적 제약 조건에 대한 오류 메시지가 본질적으로 나쁘다고 가정하는 것은 무리라고 생각합니다.

비-로컬 유형 추론(당신이 제안한 것)이 잘못된 오류 메시지를 생성하는 컴파일러 목록은 그보다 훨씬 깁니다. 여기에는 SML, OCaml 및 GHC가 포함되며, 이미 오류 메시지를 개선하기 위해 많은 노력을 기울였으며 최소한 일부 명시적 모듈 구조가 도움이 되었습니다. 당신은 더 잘할 수 있을 것이고 당신이 제안한 체계로 좋은 오류 메시지를 위한 알고리즘을 생각해낸다면 당신은 좋은 출판물을 갖게 될 것입니다. 해당 알고리즘의 시작점으로 오류 지역화에 대한 POPL 2014 및 PLDI 2015 문서가 유용할 수 있습니다. 그들은 어느 정도 최첨단입니다.

모든 구문적 제약이 사용법에서 추론될 수 있기 때문입니다.

그것이 유형 검사 가능한 일반 프로그램의 폭을 제한하지 않습니까? 예를 들어 type-params 제안은 "반복 가능" 제약 조건을 지정하지 않습니다. 현재 언어에서 이것은 슬라이스 또는 채널에 해당하지만 복합 유형(예: 연결 목록)은 이러한 요구 사항을 반드시 충족하지는 않습니다. 다음과 같은 인터페이스 정의

type Iterable[T] interface {
    Next() T
}

연결 목록의 경우에는 도움이 되지만 이제 이 인터페이스를 충족하려면 내장 슬라이스 및 채널 유형을 확장해야 합니다.

"나는 Iterables, slices, 또는 channel인 모든 유형의 집합을 받아들입니다"라는 제약 조건은 사용자, 패키지 작성자 및 컴파일러 구현자에게 윈-윈-윈 상황처럼 보입니다. 내가 말하려는 요점은 제약 조건이 구문적으로 유효한 프로그램의 상위 집합이며 일부는 언어 관점에서 이해되지 않을 수 있지만 API 관점에서만 의미가 있을 수 있다는 것입니다.

언어는 컴파일러 작성자가 아니라 사용자를 위해 설계되어야 합니다.

동의하지만 다르게 표현했어야 했습니다. 향상된 컴파일러 효율성은 사용자 정의 제약 조건의 부작용일 수 있습니다. 사용자는 어쨌든 컴파일러보다 API 동작에 대해 더 잘 알고 있기 때문에 주요 이점은 가독성입니다. 여기서 절충안은 일반 프로그램이 수용하는 것에 대해 약간 더 명시적이어야 한다는 것입니다.

대신에 어떡해

type Iterable[T] interface {
    Next() T
}

우리는 "제약조건"에서 "인터페이스"의 개념을 분리했습니다. 그럼 우리는

type T generic

type Iterable class {
    Next() T
}

여기서 "class"는 Java 스타일 클래스가 아닌 Haskell 스타일 유형 클래스를 의미합니다.

"유형 클래스"를 "인터페이스"와 분리하면 두 아이디어의 비직교성을 해결하는 데 도움이 될 수 있습니다. 그러면 Sortable (sort.Interface 무시)는 다음과 같이 보일 수 있습니다.

type T generic

type Comparable class {
    Less(a, b T) bool
}

type Sortable class {
    Next() Comparable
}

다음은 @andrewcmyers 의 Genus 의 "유형 클래스 및 개념" 섹션과 Go에 대한 적용 가능성에 대한 몇 가지 피드백입니다.

이 섹션에서는 유형 클래스 및 개념의 제한 사항을 설명합니다.

첫째, 제약 조건 만족이 고유하게 목격되어야 합니다.

이 제한 사항을 이해하고 있는지 잘 모르겠습니다. 분리된 식별자에 제약 조건을 묶으면 주어진 유형에 고유하지 못하게 되지 않습니까? Genus의 "where" 절은 본질적으로 주어진 제약 조건에서 유형/제약 조건을 구성하지만 이는 주어진 유형에서 변수를 인스턴스화하는 것과 유사하게 보입니다. 이러한 방식의 제약 조건은 종류 와 유사합니다.

다음은 Go에 적용된 제약 조건 정의의 극적인 단순화입니다.

kind Any interface{} // accepts any type that satisfies interface{}.
type T Any // Declare a type of Any kind. Also binds it to an identifier.
kind Eq T == T // accepts any type for which equality is defined.

따라서 지도 선언은 다음과 같이 표시됩니다.

type Map[K Eq, V Any] struct {
}

Genus에서 다음과 같이 보일 수 있습니다.

type Map[K, V] where Eq[K], Any[V] struct {
}

기존 Type-Params 제안에서 다음과 같이 보일 것입니다.

type Map[K,V] struct {
}

제약 조건이 기존 유형 시스템을 활용하도록 허용하면 언어 기능 간의 중복을 제거하고 새로운 기능을 쉽게 이해할 수 있다는 데 모두 동의할 수 있다고 생각합니다.

둘째, 그들의 모델은 단일 유형을 적응시키는 방법을 정의하는 반면 하위 유형이 있는 언어에서는 각 적응 유형이 일반적으로 모든 하위 유형을 나타냅니다.

이 제한은 언어가 이미 명명된/무명 유형과 겹치는 인터페이스 간에 좋은 변환 규칙을 가지고 있기 때문에 Go에 덜 적절해 보입니다.

주어진 예제는 모델을 솔루션으로 제안하는데, 이는 Go에 유용하지만 필수 기능은 아닌 것 같습니다. 예를 들어 라이브러리가 http.Handler를 구현하는 유형을 예상하고 사용자가 컨텍스트에 따라 다른 동작을 원하는 경우 어댑터를 작성하는 것은 간단합니다.

type handleFunc func(http.ResponseWriter, *http.Request)
func (f handlerFunc) ServeHTTP(w http.ResponseWriter, r *http.Request) { f(w,r) }

사실 이것이 표준 라이브러리 가 하는 일입니다.

@smasher164

첫째, 제약 조건 만족이 고유하게 목격되어야 합니다.
이 제한 사항을 이해하고 있는지 잘 모르겠습니다. 분리된 식별자에 제약 조건을 묶으면 >그것이 주어진 유형에 고유하지 않게 되지 않습니까?

아이디어는 Haskell과 달리 Genus에서 동일한 유형의 동일한 제약 조건을 여러 가지 방식으로 충족할 수 있다는 것입니다. 예를 들어 HashSet[T] 가 있는 경우 일반적인 방법으로 문자열을 해시하려면 HashSet[String] 을 쓸 수 있지만 $#$ CaseInsens 와 문자열을 해시하고 비교하려면 HashSet[String with CaseInsens] 를 쓸 수 있습니다. 아마도 대소문자를 구분하지 않는 방식으로 문자열을 처리하는 모델입니다. 속은 실제로 이 두 가지 유형을 구별합니다. 이것은 Go에게 과도할 수 있습니다. 유형 시스템이 이를 추적하지 않더라도 유형이 제공하는 기본 작업을 재정의할 수 있는 것은 여전히 ​​중요한 것 같습니다.

종류 모든 인터페이스{} // 인터페이스{}를 충족하는 모든 유형을 허용합니다.
type T Any // Any 종류의 유형을 선언합니다. 또한 식별자에 바인딩합니다.
종류 Eq T == T // 동등성이 정의된 모든 유형을 허용합니다.
유형 맵[K Eq, V Any] 구조체 { ...
}

Genus에서 이에 대한 도덕적 등가물은 다음과 같습니다.

constraint Any[T] {}
// Just use Any as if it were a type
constraint Eq[K] {
   boolean equals(K);
}
class Map[K, V] where Eq[K] { ... }

Familia에서는 다음과 같이 작성합니다.

interface Eq {
    boolean equals(This);
}
class Map[K where Eq, V] { ... }

편집: #4146에 설명된 대로 반사 기반 솔루션을 선호하여 이를 철회합니다. 아래에 설명된 제네릭 기반 솔루션은 컴포지션 수에서 선형적으로 증가합니다. 리플렉트 기반 솔루션에는 항상 성능 핸디캡이 있지만 런타임에 자체 최적화하여 컴포지션 수에 관계없이 핸디캡이 일정하도록 할 수 있습니다.

이것은 제안이 아니라 제안을 디자인할 때 고려해야 할 잠재적인 사용 사례입니다.

오늘날 Go 코드에는 두 가지 공통점이 있습니다.

• 추가 기능을 제공하기 위해 인터페이스 값 래핑(프레임워크에 대해 http.ResponseWriter 래핑)
• 때때로 인터페이스 값이 갖는 선택적 메소드가 있음(예 Temporary() bool net.Error )

이것들은 좋고 유용하지만 섞이지 않습니다. 인터페이스를 래핑하면 래핑 유형에 정의되지 않은 메서드에 액세스할 수 있는 기능을 잃게 됩니다. 즉, 주어진

type MyError struct {
  error
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.error)
}

해당 구조체에서 오류를 래핑하면 원래 오류에 대한 추가 메서드가 숨겨집니다.

구조체에서 오류를 래핑하지 않으면 추가 컨텍스트를 제공할 수 없습니다.

허용된 일반 제안을 통해 다음과 같은 것을 정의할 수 있다고 가정해 보겠습니다(아무도 집중하지 않도록 의도적으로 추하게 만들려고 했던 임의의 구문).

type MyError generic_over[E which_is_a_type_satisfying error] struct {
  E
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.E)
}

임베딩을 활용하면 오류 인터페이스를 만족하는 모든 구체적인 유형을 임베드할 수 있고 이를 래핑하고 다른 메소드에 액세스할 수 있습니다. 불행히도 이것은 우리를 거기에 이르게 할 뿐입니다.

여기서 정말 필요한 것은 오류 인터페이스의 임의 값을 가져와서 동적 유형을 포함하는 것입니다.

이것은 즉시 두 가지 우려 사항을 제기합니다.

• 유형은 런타임에 생성되어야 합니다(어쨌든 리플렉션에 필요할 수 있음)
• 오류 값이 nil이면 유형 생성이 패닉 상태가 되어야 합니다.

그것들이 당신의 생각을 해치지 않았다면, "항상 인터페이스 값의 동적 유형에 대해 인스턴스화"라고 말하는 일반 매개변수 목록의 주석에 의해 인터페이스를 동적 유형으로 "도약"하는 메커니즘이 필요합니다. " 또는 유형과 값이 올바르게 연결될 수 있도록 인터페이스를 언박싱하기 위해 유형 인스턴스화 중에만 호출할 수 있는 일부 마술 함수에 의해.

그것 없이는 인터페이스의 동적 유형이 아닌 오류 유형 자체에서 MyError 를 인스턴스화하는 것입니다.

정보를 추출하고 (어떻게든) 적용할 마법의 unbox 함수가 있다고 가정해 보겠습니다.

func wrap(ec extraContext, err error) error {
  if err == nil {
    return nil
  }
  return MyError{
    E: unbox(err),
    extraContext: ec,
  }
}

이제 동적 유형이 *net.DNSError 인 nil이 아닌 오류 err 가 있다고 가정해 보겠습니다. 그럼 이

wrapped := wrap(getExtraContext(), err)
//wrapped 's dynamic type is a MyStruct embedding E=*net.DNSError
_, ok := wrapped.(net.Error)
fmt.Println(ok)

true 를 인쇄합니다. 그러나 err 의 동적 유형이 *os.PathError 였다면 false로 인쇄되었을 것입니다.

데모에서 사용된 둔한 구문을 고려할 때 제안된 의미가 명확하기를 바랍니다.

나는 또한 더 적은 메커니즘과 의식으로 그 문제를 해결할 더 좋은 방법이 있기를 희망하지만 위의 방법이 효과가 있을 수 있다고 생각합니다.

@jimmyfrasche 원하는 것을 이해하고 있다면 래퍼가 없는 적응 메커니즘입니다. 원본을 숨기는 다른 개체로 래핑하지 않고 유형이 제공하는 작업 집합을 확장할 수 있기를 원합니다. Genus가 제공하는 기능입니다.

@andrewcmyers 아니요.

Go의 구조체는 임베딩을 허용합니다. 이름은 없지만 유형이 있는 필드를 구조체에 추가하는 경우 두 가지 작업을 수행합니다. 유형과 이름이 같은 필드를 만들고 해당 유형의 모든 메서드에 투명하게 디스패치를 ​​허용합니다. 그것은 상속처럼 들리지만 그렇지 않습니다. Foo() 메서드가 있는 유형 T가 있는 경우 다음은 동일합니다.

type S struct {
  T
}

그리고

type S struct {
  T T
}
func (s S) Foo() {
  s.T.Foo()
}

(Foo가 "this"라고 하면 항상 T 유형입니다.)

구조체에 인터페이스를 포함할 수도 있습니다. 이것은 구조체에 인터페이스의 계약에 있는 모든 메서드를 제공합니다(암시적 필드에 일부 동적 값을 할당해야 하지만 그렇지 않으면 null 포인터 예외와 동일한 패닉이 발생함)

Go에는 형식의 메서드 측면에서 계약을 정의하는 인터페이스가 있습니다. 계약을 충족하는 모든 유형의 값은 해당 인터페이스의 값에 박싱될 수 있습니다. 인터페이스 값은 내부 유형 매니페스트(동적 유형)에 대한 포인터와 해당 동적 유형의 값(동적 값)에 대한 포인터입니다. 인터페이스 값에 대한 유형 주장 을 수행하여 (a) 비인터페이스 유형에 대해 주장하는 경우 동적 값을 얻거나 (b) 동적 값도 충족하는 다른 인터페이스에 주장하는 경우 새 인터페이스 값을 얻을 수 있습니다. 객체가 선택적 메서드를 지원하는지 확인하기 위해 객체를 "기능 테스트"하기 위해 후자를 사용하는 것이 일반적입니다. 이전 예제를 재사용하기 위해 일부 오류에는 "Temporary() bool" 메서드가 있으므로 다음을 사용하여 일시적인 오류인지 확인할 수 있습니다.

func isTemp(err error) bool {
  if t, ok := err.(interface{ Temporary() bool}); ok {
    return t.Temporary()
  }
  return false
}

추가 기능을 제공하기 위해 유형을 다른 유형으로 래핑하는 것도 일반적입니다. 이것은 비인터페이스 유형에서 잘 작동합니다. 인터페이스를 래핑할 때 이에 대해 알지 못하는 메소드도 숨기고 "기능 테스트" 유형 주장으로 복구할 수 없습니다. 래핑된 유형은 선택적 메소드가 있더라도 인터페이스의 필수 메소드만 노출합니다. . 고려하다:

type A struct {}
func (A) Foo()
func (A) Bar()

type I interface {
  Foo()
}

type B struct {
  I
}

var i I = B{A{}}

i Bar 를 호출하거나 i의 동적 유형이 B라는 것을 알지 못하는 한 그것이 존재한다는 것을 알 수 없습니다. .

이로 인해 특히 오류 또는 Reader와 같은 일반적인 인터페이스를 처리하는 실제 문제가 발생합니다.

인터페이스에서 동적 유형과 값을 제거하는 방법이 있다면(일부 안전하고 제어된 방식으로) 새 유형을 매개변수화하고 포함된 필드를 값으로 설정하고 새 인터페이스를 반환할 수 있습니다. 그러면 원래 인터페이스를 만족하는 값을 얻고 추가하려는 향상된 기능이 있지만 원래 동적 유형의 나머지 메서드는 여전히 기능 테스트를 위해 존재합니다.

@jimmyfrasche 과연. Genus가 허용하는 것은 한 가지 유형을 사용하여 boxing 하지 않고 "인터페이스" 계약을 충족시키는 것입니다. 값에는 여전히 원래 유형과 원래 작업이 있습니다. 또한 프로그램은 형식이 계약을 충족하기 위해 사용해야 하는 작업을 지정할 수 있습니다. 기본적으로 형식이 제공하는 작업이지만 형식에 필요한 작업이 없는 경우 프로그램에서 새 작업을 제공할 수 있습니다. 또한 유형이 사용할 작업을 대체할 수도 있습니다.

@jimmyfrasche @andrewcmyers 해당 사용 사례는 https://github.com/golang/go/issues/4146#issuecomment -318200547도 참조하세요.

@jimmyfrasche 나에게 중요한 문제는 변수의 동적 유형/값을 얻는 것 같습니다. 임베딩을 제쳐두고 단순화 된 예는 다음과 같습니다.

type MyError generic_over[E which_is_a_type_satisfying error] struct {
  e E
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.e)
}

e 에 할당된 값은 error 를 구현하는 *net.DNSError 와 같은 동적(또는 구체적인) 유형을 가져야 합니다. 다음은 미래의 언어 변경이 이 문제를 해결할 수 있는 몇 가지 가능한 방법입니다.

1. 변수의 동적 값을 알아내는 마법 같은 unbox 같은 함수가 있습니다. 이는 구체적이지 않은 모든 유형(예: 공용체)에 적용됩니다.
2. 언어 변경이 유형 변수를 지원하는 경우 변수의 동적 유형을 가져오는 수단을 제공하십시오. 유형 정보를 사용하여 unbox 함수를 직접 작성할 수 있습니다. 예를 들어,

func unbox(v T1) T2 {
    t := dynTypeOf(v)
    return v.(t)
}

wrap 는 이전과 같은 방식으로 작성하거나 다음과 같이 작성할 수 있습니다.

func wrap(ec extraContext, err error) error {
  if err == nil {
    return nil
  }
  t := dynTypeOf(err)
  return MyError{
    e: v.(t),
    extraContext: ec,
  }
}

1. 언어 변경이 유형 제약 조건을 지원하는 경우 다음과 같은 대안이 있습니다.

type E1 which_is_a_type_satisfying error
type E2 which_is_a_type_satisfying error

func wrap(ec extraContext, err E1) E2 {
  if err == nil {
    return nil
  }
  return MyError{
    e: err,
    extraContext: ec,
  }
}

이 예에서는 오류를 구현하는 모든 유형의 값을 허용합니다. error wrap 의 모든 사용자는 하나를 받게 됩니다. 단, MyError e 타입은 전달받은 err 와 동일하며, 인터페이스 타입에 한정되지 않는다. 2와 같은 동작을 원하면

var iface error = ...
wrap(getExtraContext(), unbox(iface))

아무도 하지 않은 것 같기 때문에 https://blog.golang.org/toward-go2에서 요구하는 제네릭에 대한 매우 명백한 "경험 보고서"를 지적하고 싶습니다.

첫 번째는 내장 map 유형입니다.

m := make(map[string]string)

다음은 내장 chan 유형입니다.

c := make(chan bool)

마지막으로 표준 라이브러리에는 제네릭이 더 안전하게 작동하는 interface{} 대안이 있습니다.

• heap.Interface (https://golang.org/pkg/container/heap/#Interface)
• list.Element (https://golang.org/pkg/container/list/#Element)
• ring.Ring (https://golang.org/pkg/container/ring/#Ring)
• sync.Pool (https://golang.org/pkg/sync/#풀)
• 예정된 sync.Map (https://tip.golang.org/pkg/sync/#Map)
• atomic.Value (https://golang.org/pkg/sync/atomic/#Value)

내가 놓친 다른 사람들이있을 수 있습니다. 요점은 위의 각 항목에서 제네릭이 유용할 것으로 예상된다는 것입니다.

(참고: 여기에 sort.Sort 는 포함하지 않습니다. 제네릭 대신 인터페이스를 사용할 수 있는 방법에 대한 훌륭한 예이기 때문입니다.)

http://www.yinwang.org/blog-cn/2014/04/18/golang
제네릭이 중요하다고 생각합니다. 그렇지 않으면 유사한 유형을 처리할 수 없습니다. 인터페이스가 문제를 해결할 수 없는 경우가 있습니다.

간단한 구문과 유형 시스템은 Go의 중요한 장점입니다. 제네릭을 추가하면 언어가 Scala나 Haskell처럼 엉망이 됩니다. 또한 이 기능은 "이것을 끝내자"에서 "CS 이론과 수학에 대해 이야기합시다"로 커뮤니티 가치를 궁극적으로 변화시킬 의사 학계 팬보이를 끌어들일 것입니다. 제네릭을 피하십시오. 그것은 심연으로 가는 길입니다.

@bxqgit 이 시민을 지켜주세요. 누구를 욕할 필요도 없습니다.

미래에 어떤 일이 일어날지에 대해서는 두고 볼 것이지만 제 시간의 98% 동안 제네릭이 필요하지 않다는 것을 알고 있습니다. 필요할 때마다 제네릭을 사용할 수 있기를 바랍니다. 그것들이 어떻게 사용되는지 vs 어떻게 잘못 사용되는지는 다른 논의입니다. 사용자 교육은 프로세스의 일부여야 합니다.

@bxqgit
제네릭 데이터 구조(트리, 스택, 큐, ...) 또는 제네릭 함수(Map, Filter, Reduce, ...)와 같은 제네릭이 필요한 상황이 있으며 이러한 상황은 제네릭 대신 인터페이스를 사용하여 불가피합니다. 이러한 상황은 코드 작성자와 코드 리더 모두에게 엄청난 복잡성을 추가하고 런타임 시 코드 효율성에 나쁜 영향을 미치므로 인터페이스를 사용하고 복잡한 작성을 반영하려고 시도하는 것보다 언어 제네릭에 추가하는 것이 훨씬 더 합리적이어야 합니다. 그리고 비효율적인 코드.

@bxqgit 제네릭을 추가한다고 해서 반드시 언어에 복잡성이 추가되는 것은 아니며 간단한 구문으로도 달성할 수 있습니다. 제네릭을 사용하면 @riwogo 가 말했듯이 데이터 구조에 매우 유용한 가변 컴파일 시간 유형 제약 조건을 추가합니다.

go의 현재 인터페이스 시스템은 매우 유용하지만, 예를 들어 인터페이스와 함께 실행 시간 유형 제약 조건이 필요한 목록의 일반 구현이 필요할 때 매우 나쁩니다. 그럼에도 불구하고 제네릭을 추가하면 제네릭 유형을 다음에서 대체할 수 있습니다. 실제 유형으로 컴파일 시간이 필요하므로 제약 조건이 필요하지 않습니다.

또한 뒤에 있는 사람들은 "CS 이론과 수학"이라고 부르는 것을 사용하여 언어를 개발하고 "이를 수행하는" 사람들이기도 합니다.

또한 뒤에 있는 사람들은 "CS 이론과 수학"이라고 부르는 것을 사용하여 언어를 개발하고 "이를 수행하는" 사람들이기도 합니다.

개인적으로 나는 Go 언어 디자인에서 CS 이론과 수학을 많이 보지 않습니다. 제 생각에는 상당히 원시적인 언어입니다. 또한 당신이 이야기하는 사람들은 제네릭을 피하기로 결정하고 일을 끝냈습니다. 잘 작동한다면 왜 변경합니까? 일반적으로 언어의 구문을 지속적으로 발전시키고 확장하는 것은 나쁜 습관이라고 생각합니다. 그것은 Haskell과 Scala의 혼란으로 이어지는 복잡성을 추가할 뿐입니다.

템플릿은 복잡하지만 Generics는 간단합니다.

정렬 패키지의 SortInts, SortFloats, SortStrings 함수를 살펴보십시오. 또는 SearchInts, SearchFloats, SearchStrings. 또는 io/ioutil 패키지에 있는 byName의 Len, Less 및 Swap 메서드. 순수한 상용구 복사.

복사 및 추가 기능은 슬라이스를 훨씬 더 유용하게 만들기 때문에 존재합니다. 제네릭은 이러한 기능이 필요하지 않음을 의미합니다. 제네릭을 사용하면 사용자 생성 데이터 유형은 말할 것도 없고 맵 및 채널에 대해 유사한 기능을 작성할 수 있습니다. 물론 슬라이스는 가장 중요한 복합 데이터 유형이며 이것이 이러한 기능이 필요한 이유이지만 다른 데이터 유형은 여전히 ​​유용합니다.

내 투표는 일반화된 애플리케이션 제네릭에 반대하고 여러 기본 유형에서 작동하는 append 및 copy $와 같은 더 많은 기본 제공 제네릭 기능에 찬성입니다. 컬렉션 유형에 sort 및 search 를 추가할 수 있습니까?

내 응용 프로그램의 경우 누락된 유일한 유형은 정렬되지 않은 집합입니다(https://github.com/golang/go/issues/7088). slice 와 같은 일반 유형을 얻을 수 있도록 이것을 기본 제공 유형으로 원합니다. map . 작업을 컴파일러에 넣고(각 기본 유형 및 선택한 struct 유형 세트에 대한 벤치마킹 후 최상의 성능을 위해 조정) 애플리케이션 코드에서 추가 주석을 유지합니다.

$#$ sync.Map 대신 smap 내장도 부탁드립니다. 내 경험에 따르면 런타임 유형 안전을 위해 interface{} 를 사용하는 것은 설계상의 결함입니다. 컴파일 타임 유형 검사는 Go를 사용하는 주요 이유입니다.

@pciet

내 경험에 따르면{} 런타임 유형 안전을 위해 인터페이스를 사용한 것은 설계 결함입니다.

작은(유형 안전) 래퍼를 작성할 수 있습니까?
https://play.golang.org/p/tG6hd-j5yx

@pierrre 그 래퍼는 reflect.TypeOf(item).AssignableTo(type) 수표보다 낫습니다. 그러나 map + sync.Mutex 또는 sync.RWMutex 를 사용하여 자신의 유형을 작성하는 것은 sync.Map 에 필요한 유형 주장 없이 동일한 복잡성입니다.

내 동기화된 맵은 유형을 만드는 대신 옆에 var myMapLock = sync.RWMutex{} 가 있는 뮤텍스의 전역 맵에 사용되었습니다. 이것은 더 깨끗할 수 있습니다. 제네릭 내장 유형은 나에게 맞는 것처럼 들리지만 내가 할 수 없는 작업이 필요하며 유형 어설션 대신 내 접근 방식을 선호합니다.

제네릭에 대한 주요 노출이 C++ 템플릿을 통해 이루어졌기 때문에 많은 Go 프로그래머가 발생하는 것으로 보이는 제네릭에 대한 부정적인 본능적 반응이 발생했다고 생각합니다. 이것은 C++가 첫날부터 비극적으로 잘못된 제네릭을 얻었고 그 이후로 그 실수를 더욱 악화시켰기 때문에 불행한 일입니다. Generics for Go는 훨씬 간단하고 오류가 발생하기 쉽습니다.

내장된 매개변수화된 유형을 추가하여 Go가 점점 더 복잡해지는 것을 보는 것은 실망스러울 것입니다. 프로그래머가 자신의 매개변수화된 유형을 작성할 수 있도록 언어 지원을 추가하는 것이 좋습니다. 그런 다음 핵심 언어를 복잡하게 만드는 대신 특수 유형을 라이브러리로 제공할 수 있습니다.

@andrewcmyers "Generics for Go는 훨씬 간단하고 오류가 발생하기 쉽습니다." --- C#의 제네릭과 같습니다.

내장 매개변수화된 유형을 추가하여 Go가 점점 더 복잡해지는 것을 보는 것은 실망스럽습니다.

이 문제에 대한 추측에도 불구하고 나는 이것이 일어날 가능성이 극히 낮다고 생각합니다.

매개변수화된 유형의 복잡성 측정에 대한 지수는 분산입니다.
Go의 유형(인터페이스를 제외하고)은 불변이며 이것은 할 수 있고 그래야 합니다.
규칙을 지켰다.

기계적 컴파일러 지원 "유형 복사 붙여넣기" 제네릭 구현
Go의 기본에 충실한 방식으로 문제의 99%를 해결할 것입니다.
얕음과 놀라움의 원칙.

그건 그렇고, 이것과 수십 개의 다른 실행 가능한 아이디어가 논의되었습니다.
이전에 일부는 훌륭하고 실행 가능한 접근 방식으로 절정에 이르렀습니다. 이에
요점, 나는 그들이 모두 어떻게 사라졌는지에 대해 경계선 은박지 모자를 쓰고 있습니다.
조용히 허공으로.

2017년 11월 28일 23시 54분에 "Andrew Myers" [email protected] 이 다음과 같이 썼습니다.

나는 많은 사람들이 제네릭에 대한 부정적인 본능적 반응이
프로그래머는 제네릭에 대한 주요 노출이
C++ 템플릿을 통해. C++가 비극적으로 제네릭을 얻었기 때문에 이것은 불행한 일입니다.
첫날부터 잘못되었고 그 이후로 실수를 복잡하게 만들었습니다. 제네릭
Go는 훨씬 간단하고 오류가 발생하기 쉽습니다.

추가함으로써 Go가 점점 더 복잡해지는 것을 보는 것은 실망스럽습니다.
내장 매개변수화된 유형. 언어를 추가하는 것이 좋습니다.
프로그래머가 자신의 매개변수화된 유형을 작성할 수 있도록 지원합니다. 그런 다음
특수 유형은 복잡하지 않고 라이브러리로 제공될 수 있습니다.
핵심 언어.

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

예, 템플릿 없이 제네릭을 가질 수 있습니다. 템플릿은 주로 메타프로그래밍 기능을 위한 고급 매개변수 다형성의 한 형태입니다.

@ianlancetaylor Rust는 프로그램이 Q 기존 유형에 T 특성을 구현하는 것을 허용합니다. 단, 해당 크레이트가 T 또는 Q 를 정의한다면

그냥 생각: Simon Peyton Jones(예, Haskell로 유명함) 및/또는 Rust 개발자가 도움을 줄 수 있는지 궁금합니다. Rust와 Haskell은 아마도 모든 프로덕션 언어 중 가장 발전된 두 가지 유형 시스템을 가지고 있을 것이며 Go는 그들로부터 배워야 합니다.

Generic Java 작업을 한 Phillip Wadler 도 있으며, 이는 결국 Java가 현재 구현한 제네릭 구현으로 이어집니다.

@tarcieri 나는 Java의 제네릭이 그다지 좋지 않다고 생각하지만 전투 테스트를 거쳤습니다.

@DemiMarie 다행스럽게도 Andrew Myers가 여기에 참여했습니다.

제 개인적인 경험에 비추어 볼 때, 다른 언어와 다른 유형 시스템에 대해 많이 알고 있는 사람들이 아이디어를 검토하는 데 매우 도움이 될 수 있다고 생각합니다. 하지만 애초에 아이디어를 내려면 바둑에 매우 익숙한 사람들, 현재 어떻게 작동하는지, 미래에 어떻게 합리적으로 작동할 수 있는지가 필요한 사람들입니다. Go는 무엇보다도 단순한 언어로 설계되었습니다. Go보다 훨씬 더 복잡한 Haskell 또는 Rust와 같은 언어에서 아이디어를 가져오는 것은 적합하지 않을 것입니다. 그리고 일반적으로 이미 적당한 양의 Go 코드를 작성하지 않은 사람들의 아이디어는 적합하지 않을 것입니다. 아이디어가 나쁘다는 것이 아니라 나머지 언어와 잘 맞지 않을 뿐입니다.

예를 들어 Go는 이미 인터페이스 유형을 사용하는 일반 프로그래밍을 부분적으로 지원하고 이미 Reflect 패키지를 사용하여 (거의) 완전한 지원을 제공한다는 점을 이해하는 것이 중요합니다. 제네릭 프로그래밍에 대한 이러한 두 가지 접근 방식은 여러 가지 이유로 만족스럽지 않지만 Go의 제네릭에 대한 모든 제안은 이들과 잘 상호 작용하는 동시에 단점을 해결해야 합니다.

사실 제가 여기 있는 동안 저는 인터페이스를 사용한 제네릭 프로그래밍에 대해 잠시 생각했고 만족스럽지 못한 세 가지 이유를 생각해 냈습니다.

1. 인터페이스는 모든 작업이 메서드로 표현되어야 합니다. 이는 채널 유형과 같은 내장 유형에 대한 인터페이스를 작성하는 것을 어렵게 만듭니다. 모든 채널 유형은 보내기 및 받기 작업에 대해 <- 연산자를 지원하며 Send 및 Receive 메서드로 인터페이스를 작성하는 것은 쉽지만 채널 값을 할당하기 위해 해당 인터페이스 유형에 대해서는 상용구 플레이트 Send 및 Receive 메소드를 작성해야 합니다. 이러한 상용구 방법은 각기 다른 채널 유형에 대해 정확히 동일하게 보일 것이므로 지루합니다.

2. 인터페이스는 동적으로 유형이 지정되므로 정적으로 유형이 다른 값을 결합하는 오류는 컴파일 시간이 아니라 런타임에만 포착됩니다. 예를 들어 Send 및 Receive 메서드를 사용하여 두 채널을 단일 채널로 병합하는 Merge 함수는 두 채널에 동일한 유형의 요소가 있어야 하지만 확인은 런타임에만 수행할 수 있습니다.

3. 인터페이스는 항상 박스형입니다. 예를 들어, 다른 유형을 인터페이스 값에 넣지 않고 인터페이스를 사용하여 다른 유형의 쌍을 집계할 수 있는 방법이 없으므로 추가 메모리 할당과 포인터 추적이 필요합니다.

Go에 대한 제네릭 제안에 대해 kibitz가 된 것을 기쁘게 생각합니다. 아마도 최근에 코넬에서 제네릭에 대한 연구가 증가하고 있다는 사실도 흥미로울 것입니다. 이는 Go로 할 수 있는 일과 관련이 있는 것 같습니다.

http://www.cs.cornell.edu/andru/papers/familia/ (Zhang & Myers, OOPSLA'17)
http://io.livecode.ch/learn/namin/unsound (Amin & Tate, OOPSLA'16)
http://www.cs.cornell.edu/projects/genus/ (Zhang et al., PLDI '15)
https://www.cs.cornell.edu/~ross/publications/shapes/shapes-pldi14.pdf (Greenman, Muehlboeck & Tate, PLDI '14)

정렬되지 않은 세트 유형에 대한 벤치마킹 맵 대 슬라이스에서 각각에 대해 별도의 단위 테스트를 작성했지만 인터페이스 유형을 사용하면 이 두 테스트 목록을 하나로 결합할 수 있습니다.

type Item interface {
    Equal(Item) bool
}

type Set interface {
    Add(Item) Set
    Remove(Item) Set
    Combine(...Set) Set
    Reduce() Set
    Has(Item) bool
    Equal(Set) bool
    Diff(Set) Set
}

항목 제거 테스트:

type RemoveCase struct {
    Set
    Item
    Out Set
}

func TestRemove(t *testing.T) {
    for i, c := range RemoveCases {
        if c.Out.Equal(c.Set.Remove(c.Item)) == false {
            t.Fatalf("%v failed", i)
        }
    }
}

이렇게 하면 이전에 분리된 케이스를 문제 없이 하나의 케이스 조각에 넣을 수 있습니다.

var RemoveCases = []RemoveCase{
    {
        Set: MapPathSet{
            &Path{{0, 0}}:         {},
            &Path{{0, 1}, {1, 1}}: {},
        },
        Item: Path{{0, 0}},
        Out: MapPathSet{
            &Path{{0, 1}, {1, 1}}: {},
        },
    },
    {
        Set: SlicePathSet{
            {{0, 0}},
            {{0, 1}, {1, 1}},
        },
        Item: Path{{0, 0}},
        Out: SlicePathSet{
            {{0, 1}, {1, 1}},
        },
    },
}

각각의 구체적인 유형에 대해 인터페이스 메소드를 정의해야 했습니다. 예를 들어:

func (the MapPathSet) Remove(an Item) Set {
    return MapDelete(the, an.(Path))
}

func (the SlicePathSet) Remove(an Item) Set {
    return SliceDelete(the, an.(Path))
}

이러한 일반 테스트는 제안된 컴파일 타임 유형 검사를 사용할 수 있습니다.

type Item generic {
    Equal(Item) bool
}

func (the SlicePathSet) Remove(an Item) Set {
    return SliceDelete(the, an)
}

출처: https://github.com/pciet/pathsetbenchmark

그것에 대해 더 생각해보면, 유형이 해당 인터페이스 메소드에 전달되었는지 알기 위해 프로그램을 실행해야 하기 때문에 그러한 테스트에 대해 컴파일 타임 유형 검사가 가능할 것 같지 않습니다.

그렇다면 인터페이스이고 구체적으로 사용될 때 컴파일러에 의해 추가된 보이지 않는 유형 주장이 있는 "일반" 유형은 어떻습니까?

@andrewcmyers "Familia" 논문은 흥미로웠습니다. 핵심 개념은 상속이었습니다. 상속 대신 구성에 의존하는 Go와 같은 언어의 경우 개념이 어떻게 변할까요?

감사 해요. 상속 부분은 Go에 적용되지 않습니다. Go의 제네릭에만 관심이 있다면 문서의 섹션 4 이후 읽기를 중단할 수 있습니다. Go와 관련된 해당 문서의 주요 내용은 인터페이스가 현재 Go에 사용되는 방식 과 일반 추상화의 유형에 대한 제약 조건 모두에서 인터페이스를 사용하는 방법을 보여줍니다. 이는 언어에 완전히 새로운 구성을 추가하지 않고도 Haskell 유형 클래스의 기능을 사용할 수 있음을 의미합니다.

@andrewcmyers Go에서 이것이 어떻게 보이는지 예를 들어 주시겠습니까?

Go와 관련된 이 문서의 주요 내용은 인터페이스가 현재 Go에 사용되는 방식과 일반 추상화의 유형에 대한 제약 조건 모두에서 인터페이스를 사용하는 방법을 보여줍니다.

내 이해는 Go 인터페이스가 유형에 대한 제약 조건을 정의한다는 것입니다. 유형 제약 조건이 무엇을 의미하는지 이해하지 못합니다.

나는 Haskell에 익숙하지 않지만 빠른 개요를 읽으면 Go 인터페이스에 맞는 유형이 해당 유형 클래스에 적합할 것이라고 추측합니다. Haskell 유형 클래스의 차이점을 설명할 수 있습니까?

Familia와 Go의 구체적인 비교는 흥미로울 것입니다. 논문을 공유해 주셔서 감사합니다.

Go 인터페이스는 구조적 하위 유형 지정을 통해 유형에 대한 제약 조건을 설명하는 것으로 볼 수 있습니다. 그러나 해당 형식 제약 조건은 일반 프로그래밍에 대해 원하는 제약 조건을 캡처할 만큼 충분히 표현적이지 않습니다. 예를 들어 Familia 논문에서는 Eq 라는 형식 제약 조건을 표현할 수 없습니다.

Go에서 보다 일반적인 프로그래밍 기능에 대한 동기에 대한 몇 가지 생각:

따라서 언어에 추가할 필요가 없는 일반 테스트 목록이 있습니다. 내 생각에 내가 제안한 제네릭 유형은 Go 목표를 직접 이해하는 데 만족하지 않고 일반적으로 허용되는 프로그래밍 용어와 관련이 많지 않으며 실패에 대한 패닉이 있기 때문에 유형 어설션을 수행하는 것이 추악하지 않습니다. 좋아. 나는 이미 내 필요에 맞는 Go의 일반 프로그래밍 기능에 만족합니다.

그러나 sync.Map은 다른 사용 사례입니다. 표준 라이브러리에는 맵과 뮤텍스가 있는 구조체를 넘어 성숙한 일반 동기화 맵 구현이 필요합니다. 유형 처리를 위해 비인터페이스{} 유형을 설정하고 유형 어설션을 수행하는 다른 유형으로 이를 래핑하거나, 첫 번째 항목 다음에 오는 항목이 동일한 유형과 일치해야 하도록 내부적으로 반영 검사를 추가할 수 있습니다. 둘 다 런타임 검사가 있고 래핑은 각 사용 유형에 대해 각 메서드를 다시 작성해야 하지만 입력에 대한 컴파일 시간 유형 검사를 추가하고 출력 유형 주장을 숨깁니다. 내부 검사를 통해 어쨌든 출력 유형 주장을 수행해야 합니다. 어느 쪽이든 실제로 인터페이스를 사용하지 않고 인터페이스 변환을 수행하고 있습니다. interface{}는 언어의 핵이며 새로운 Go 프로그래머에게 명확하지 않을 것입니다. 내 의견으로는 json.Marshal이 좋은 디자인이지만(추악하지만 합리적인 구조체 태그 포함).

나는 sync.Map이 표준 라이브러리에 있기 때문에 이상적으로는 단순한 구조체가 더 성능이 좋은 측정된 사용 사례에 대한 구현을 교체해야 한다고 덧붙일 것입니다. 동기화되지 않은 맵은 Go 동시 프로그래밍의 일반적인 초기 함정이며 표준 라이브러리 수정이 작동해야 합니다.

일반 맵에는 컴파일 타임 유형 검사만 있으며 이러한 스캐폴딩이 필요하지 않습니다. 나는 sync.Map이 동일해야 하거나 Go 2의 표준 라이브러리에 있어서는 안 된다고 주장합니다.

내장 유형 목록에 sync.Map을 추가하고 향후 유사한 요구 사항에 대해 동일한 작업을 수행할 것을 제안했습니다. 그러나 내 이해는 Go 프로그래머가 컴파일러에서 작업하지 않고 이 작업을 수행할 수 있는 방법을 제공하고 오픈 소스 승인 문제가 이 토론의 배경이 되는 아이디어라는 것입니다. 내 보기에 sync.Map 수정은 이 제네릭 제안이 무엇이어야 하는지 부분적으로 정의하는 실제 사례입니다.

sync.Map을 내장으로 추가하면 어디까지 갈까요? 당신은 모든 컨테이너를 특수 케이스합니까?
sync.Map이 유일한 컨테이너는 아니며 일부는 다른 것보다 어떤 경우에는 더 좋습니다.

@Azareal : @chowey 는 8월에 다음을 나열했습니다.

마지막으로, 표준 라이브러리는 제네릭이 더 안전하게 작동하는{}대체 인터페이스로 가득합니다.

• heap.Interface(https://golang.org/pkg/container/heap/#Interface)
• list.Element(https://golang.org/pkg/container/list/#Element)
• ring.Ring (https://golang.org/pkg/container/ring/#Ring)
• sync.Pool(https://golang.org/pkg/sync/#Pool)
• 예정된 sync.Map (https://tip.golang.org/pkg/sync/#Map)
• atomic.Value(https://golang.org/pkg/sync/atomic/#Value)

내가 놓친 다른 사람들이있을 수 있습니다. 요점은 위의 각 항목에서 제네릭이 유용할 것으로 예상된다는 것입니다.

그리고 평등을 위해 비교할 수 있는 유형에 대해 정렬되지 않은 집합을 원합니다.

가능한 최상의 구현이 일반적으로 사용되도록 벤치마킹을 기반으로 각 유형에 대한 런타임의 변수 구현에 많은 작업을 투입하고 싶습니다.

인터페이스가 없고{} 제네릭이 없는 이러한 표준 라이브러리 유형에 대해 동일한 목표를 달성하는 Go 1을 사용하여 합리적인 대안 구현이 있는지 궁금합니다.

golang 인터페이스와 하스켈 유형 클래스는 두 가지를 극복합니다(매우 훌륭합니다!).

1.) (Type Constraint) 인터페이스 이름 하나의 태그로 서로 다른 유형을 그룹화합니다.
2.) (디스패치) 인터페이스 구현을 통해 주어진 기능 세트에 대해 각 유형에 대해 다르게 디스패치하도록 제안합니다.

하지만,

1.) 때때로 int, float64 및 string 그룹과 같은 익명 그룹만 원할 때가 있습니다. 그러한 인터페이스의 이름을 NumericandString으로 어떻게 지정해야 합니까?

2.) 매우 자주, 인터페이스의 각 유형에 대해 다르게 디스패치하고 싶지 않고 나열된 모든 유형의 인터페이스에 대해 하나의 메소드만 제공하기를 원합니다(인터페이스 의 기본 메소드로 가능할 수도 있음)

3.) 매우 자주 그룹에 대해 가능한 모든 유형을 열거하고 싶지 않습니다. 대신 당신은 게으른 길을 가고 일부 인터페이스 A를 구현하는 모든 유형 T를 원하고 컴파일러는 편집하는 모든 소스 파일과 컴파일 시간에 적절한 함수를 생성하는 데 사용하는 모든 라이브러리에서 모든 유형을 검색하기를 원한다고 말합니다.

마지막 요점은 인터페이스 다형성을 통해 가능하지만 캐스트를 포함하는 런타임 다형성이라는 단점이 있으며 둘 이상의 인터페이스 또는 여러 인터페이스 중 하나를 구현하는 유형을 포함하도록 함수의 매개변수 입력을 어떻게 제한합니까? 방법은 다른 인터페이스를 확장하는 새로운 인터페이스(인터페이스 중첩을 통해)를 도입하여 유사하지만 모범 사례가 아닌 것을 달성하는 것입니다.

그런데.
나는 go가 이미 다형성을 가지고 있으므로 정확히 go는 더 이상 C와 같은 단순한 언어가 아니라고 말하는 사람들을 인정합니다. 그것은 높은 수준의 시스템 프로그래밍 언어입니다. 따라서 다형성을 확장하지 않는 이유는 무엇입니까?

다음은 일반적인 순서 없는 집합 유형을 위해 오늘 시작한 라이브러리입니다. https://github.com/pciet/unordered

이것은 문서화 및 테스트 예제에서 컴파일 시간 유형 안전성을 위해 래퍼 패턴(@pierrre에게 감사)을 입력하고 런타임 유형 안전성에 대한 반영 검사를 제공합니다.

제네릭에는 어떤 요구 사항이 있습니까? 이전에 인터페이스 사용을 중심으로 한 표준 라이브러리 제네릭 유형에 대한 저의 부정적인 태도{}; 내 불만은 의도된 표현할 수 없는 제약 조건을 문서화하는{} 인터페이스에 대한 패키지별 유형(예: pciet/unordered의 type Item interface{} )으로 해결할 수 있습니다.

지금은 문서만으로도 우리를 얻을 수 있을 때 언어 기능을 추가할 필요가 없다고 생각합니다. 일반 기능을 제공하는 표준 라이브러리에는 이미 많은 양의 테스트를 거친 코드가 있습니다(https://github.com/golang/go/issues/23077 참조).

귀하의 코드는 런타임에 유형을 검사합니다(그리고 그 관점에서 볼 때 더 나쁘지는 않은 경우 interface{} 보다 더 나은 방법은 없습니다). 제네릭을 사용하면 컴파일 타임 유형 검사와 함께 컬렉션 유형을 가질 수 있습니다.

@zerkms 런타임 검사는 asserting = false로 설정하여 끌 수 있습니다(표준 라이브러리에는 들어가지 않음). 컴파일 타임 검사에 대한 사용 패턴이 있으며 어쨌든 유형 검사는 인터페이스 구조체(사용 인터페이스는 유형 검사보다 더 많은 비용을 추가합니다. 인터페이스가 작동하지 않는 경우 고유한 유형을 작성해야 합니다.

최대 성능의 일반 코드가 핵심 요구 사항이라고 말하고 있습니다. 내 사용 사례에는 없었지만 표준 라이브러리가 더 빨라질 수 있고 다른 사람들이 그런 것을 필요로 할 수도 있습니다.

asserting = false를 설정하여 런타임 검사를 끌 수 있습니다.

그렇다면 정확성을 보장하는 것은 없습니다

최대 성능의 일반 코드가 핵심 요구 사항이라고 말하고 있습니다.

나는 그런 말을하지 않았다. 유형 안전성은 매우 중요합니다. 귀하의 솔루션은 여전히 interface{} 감염되었습니다.

그러나 아마도 표준 라이브러리가 더 빨라질 수 있고 다른 사람들이 그런 것을 필요로 할 수도 있습니다.

핵심 개발 팀이 내가 필요로 하는 모든 것을 신속하게 구현하는 데 만족한다면 그럴 수 있습니다.

@pciet

지금은 문서만으로도 우리를 얻을 수 있을 때 언어 기능을 추가할 필요가 없다고 생각합니다.

이렇게 말하지만 슬라이스 형태의 일반 언어 기능과 make 함수를 사용하는 데 문제가 없습니다.

지금은 문서만으로도 우리를 얻을 수 있을 때 언어 기능을 추가할 필요가 없다고 생각합니다.

그렇다면 왜 정적으로 유형이 지정된 언어를 사용하는 것을 귀찮게 할까요? Python과 같은 동적으로 유형이 지정된 언어를 사용하고 문서에 의존하여 올바른 데이터 유형이 API로 전송되었는지 확인할 수 있습니다.

Go의 장점 중 하나는 컴파일러에서 향후 버그를 방지하기 위해 일부 제약 조건을 적용할 수 있는 기능이라고 생각합니다. 이러한 기능은 향후 더 많은 버그를 방지하기 위해 다른 제약을 적용하기 위해 확장될 수 있습니다(제네릭 지원 포함).

이렇게 말하지만 슬라이스 형태의 일반 언어 기능과 make 함수를 사용하는 데 문제가 없습니다.

기존 기능으로 인해 일반적인 프로그래밍 솔루션이 있고 Go 1 유형 시스템에서 변경해야 하는 강력한 실제 이유가 있어야 하는 균형 잡힌 지점에 도달할 수 있습니다. 변경이 언어를 개선하는 방법이 아니라 fmt 및 데이터베이스 표준 라이브러리 패키지에서 인터페이스에 대한 많은 런타임 유형 전환을 유지하는 것과 같이 현재 사람들이 직면하고 있는 문제는 수정될 것입니다.{}

그렇다면 왜 정적으로 유형이 지정된 언어를 사용하는 것을 귀찮게 할까요? Python과 같은 동적으로 유형이 지정된 언어를 사용하고 문서에 의존하여 올바른 데이터 유형이 API로 전송되었는지 확인할 수 있습니다.

정적으로 유형이 지정된 언어와 조직 대신 Python으로 시스템을 작성하라는 제안을 들었습니다.

표준 라이브러리를 사용하는 대부분의 Go 프로그래머는 문서 없이 또는 구현을 보지 않고는 완전히 설명할 수 없는 유형을 사용합니다. 매개변수 하위 유형이 있는 유형 또는 제약 조건이 적용된 일반 유형은 프로그래밍 방식으로 이러한 경우의 하위 집합만 수정하고 표준 라이브러리에서 이미 수행된 많은 작업을 생성합니다.

합계 유형에 대한 제안에서 인터페이스에 할당된 가능한 값이 포함된 인터페이스 유형 전환 케이스와 일치하지 않을 때 함수 또는 메소드에서 인터페이스 사용에서 빌드 오류가 발생하는 인터페이스 유형 스위치에 대한 빌드 기능을 제안했습니다.

인터페이스를 취하는 함수/메서드는 기본 케이스가 없고 유형에 대한 케이스가 없기 때문에 빌드 시 일부 유형을 거부할 수 있습니다. 기능을 구현할 수 있는 경우 이는 합리적인 일반 프로그래밍 추가처럼 보입니다.

Go 인터페이스가 구현자의 유형을 캡처할 수 있다면 현재 Go 구문과 완전히 호환되는 제네릭 형식이 있을 수 있습니다. 즉, 단일 매개변수 형식의 제네릭( 데모 )입니다.

일반 컨테이너 유형을 위한 @dc0d 나는 이 기능이 래퍼 유형을 요구하지 않고 컴파일 타임 유형 검사를 추가한다고 믿습니다: https://gist.github.com/pciet/36a9dcbe99f6fb71f5fc2d3c455971e5

@pciet 맞습니다. 제공된 코드 4번에서 샘플은 슬라이스 및 채널(및 배열)에 대해 유형이 캡처되었음을 나타냅니다. 하지만 맵의 경우에는 그렇지 않습니다. 왜냐하면 구현자라는 하나의 유형 매개변수만 있기 때문입니다. 그리고 맵은 2가지 타입의 매개변수가 필요하기 때문에 래퍼 인터페이스가 필요합니다.

BTW 나는 그 코드의 시연 목적을 생각의 줄로 강조해야합니다. 저는 언어 디자이너가 아닙니다. 이것은 Go에서 제네릭 구현에 대해 생각하는 가설적인 방법일 뿐입니다.

• 현재 Go와 호환 가능
• 단순(현재 구현자를 참조하는 다른 OO에서 _느낌_ _ 비슷한 단일 일반 유형 매개변수)

영향을 최소화하면서 중요한 사용 사례와 표현의 유연성을 최대화하려는 맥락에서 일반성과 모든 가능한 사용 사례에 대한 논의는 매우 복잡한 분석입니다. 우리 중 누군가가 그것을 생성적 본질이라고도 불리는 짧은 원칙 세트로 증류할 수 있을지 확신할 수 없습니다. 노력하고있어. 어쨌든, 여기에 이 ​​스레드에 대한 _cursory_ 정독의 초기 생각 중 일부가 있습니다.

@adg 는 다음과 같이 썼습니다.

이 문제와 함께 @ianlancetaylor 의 일반 제네릭 제안 이 있으며 여기에는 Go용 일반 프로그래밍 메커니즘에 대한 4가지 결함이 있는 특정 제안이 포함됩니다.

Afaics, 다음과 같이 발췌한 링크된 섹션은 현재 인터페이스에 일반성이 부족한 경우를 설명하지 않습니다. _"어떤 T에 대해 호출자 제공 유형 T에 대한 인터페이스를 취하고 같은 타입 T.”_.

임의의 T에 대해 유형 T의 인수를 취하고 동일한 유형의 값을 리턴하는 메소드로 인터페이스를 작성할 수 있는 방법은 없습니다.

그렇다면 호출 사이트 유형의 코드에서 결과 값으로 유형 T가 있는지 어떻게 확인할 수 있습니까? 예를 들어, 상기 인터페이스는 유형 T를 빌드하기 위한 팩토리 메소드를 가질 수 있습니다. 이것이 우리가 유형 T에서 인터페이스를 매개변수화해야 하는 이유입니다.

인터페이스는 단순한 유형이 아닙니다. 그것들은 또한 가치입니다. 인터페이스 값을 사용하지 않고 인터페이스 유형을 사용할 수 있는 방법은 없으며 인터페이스 값이 항상 효율적인 것은 아닙니다.

인터페이스가 현재 작동하는 유형 T에서 명시적으로 매개변수화될 수 없기 때문에 유형 T에 프로그래머가 액세스할 수 없다는 데 동의했습니다.

그래서 typeclass bounds는 type T를 입력으로 사용하고 type T에 필요한 인터페이스를 나타내는 where 또는 requires 절을 갖는 함수 정의 사이트에서 수행합니다. 많은 상황에서 이러한 인터페이스 사전은 컴파일 타임에 자동으로 단일화될 수 있으므로 사전 포인터(인터페이스용)가 런타임에 함수에 전달되지 않습니다(현재 Go 컴파일러가 인터페이스에 적용한다고 가정하는 단일화?). 위 인용문에서 '값'은 입력 유형 T를 의미하며 유형 T에 의해 구현된 인터페이스 유형에 대한 메소드 사전을 의미하지 않는다고 가정합니다.

그런 다음 데이터 유형(예: struct )에 대한 유형 매개변수를 허용하면 위의 유형 T 자체가 매개변수화될 수 있으므로 실제로 T<U> 유형을 갖게 됩니다. U 에 대한 지식을 유지해야 하는 이러한 유형을 위한 팩토리를 고급 유형(HKT) 이라고 합니다.

제네릭은 유형이 안전한 다형성 컨테이너를 허용합니다.

또한 아래에서 논의되는 _이기종_ 컨테이너 문제를 참조하십시오. 따라서 다형성이란 컨테이너의 값 유형(예: 컬렉션의 요소 유형)의 일반성을 의미하지만 컨테이너에 둘 이상의 값 유형을 동시에 넣어 이질적으로 만들 수 있는지 여부에 대한 문제도 있습니다.

@tamird 는 다음과 같이 썼습니다.

이러한 요구 사항은 예를 들어 일반 유형이 특성 경계에 의해 제한되는 Rust의 특성 시스템과 유사한 시스템을 제외하는 것 같습니다.

Rust의 특성 경계는 본질적으로 유형 클래스 경계입니다.

@alex 는 다음과 같이 썼습니다.

러스트의 특징. 나는 그들이 일반적으로 좋은 모델이라고 생각하지만 오늘날 존재하는 바둑에는 적합하지 않을 것입니다.

왜 그들이 적합하지 않다고 생각합니까? 아마도 당신은 런타임 디스패치를 ​​사용하는 특성 객체가 단형성보다 성능이 떨어진다고 생각하고 있습니까? 그러나 그것들은 typeclass bounds genericity 원칙과 별도로 고려될 수 있습니다(아래의 이기종 컨테이너/컬렉션에 대한 나의 논의 참조). Afaics, Go의 인터페이스는 이미 특성과 유사한 경계이며 초기에 바인딩하는 OOP의 안티 패턴(아직 컴파일 단계에 있더라도 사전을 호출 사이트의 데이터 유형에 늦게 바인딩하는 typeclasses의 목표를 달성합니다. 시간) 데이터 유형에 대한 사전(인스턴스화/구성 시). Typeclasses는 (적어도 자유도의 부분적인 개선) OOP가 할 수 없는 표현 문제 를 해결할 수 있습니다.

@jimmyfrasche 는 다음과 같이 썼습니다.

• https://golang.org/doc/faq#covariant_types

나는 typeclasses가 실제로 하위 유형이 아니며 상속 관계를 표현하지 않는다는 위의 링크에 동의합니다. 그리고 서브클래싱이 하는 것처럼 상속과 "일반성"(매개변수 다형성보다 재사용 또는 모듈성에 대한 더 일반적인 개념)을 불필요하게 병합하지 않는 데 동의합니다.

그러나 언어가 공용체와 교차를 지원하는 경우 상속 계층 구조(일명 하위 유형 지정 ⁾ 가 할당(함수 입력) 및 from(함수 출력)에서 불가피하다는 점도 지적하고 싶습니다. 예를 들어 int ν string int 또는 string 에서 할당을 수락할 수 있지만 둘 다 int ν string 에서 할당을 수락할 수 없습니다. 공용체 없이 정적으로 유형이 다른 이종 컨테이너/컬렉션을 제공하는 유일한 대안은 서브클래싱 또는 실존적 경계 다형성(Rust에서는 특성 객체, Haskell에서는 실존적 수량화라고도 함)입니다. 위의 링크에는 실존주의와 조합 간의 균형에 대한 논의가 포함되어 있습니다. Afaik, 이제 Go에서 이기종 컨테이너/컬렉션을 수행하는 유일한 방법은 모든 유형을 빈 interface{} ^에 포함시키는 것입니다. 정적 타이핑의 요점을 이깁니다.

피해야 할 "반패턴"은 가상 상속이라고도 불리는 하위 분류입니다(암시적 포함 및 평등 문제에 대한 "EDIT#2" 참조).

¹ _{구조적으로 또는 명목상으로 일치하는지 여부에 관계없이 하위 유형은 비교 집합에 기반한 Liskov 대체 원리와 반환 값과 반대되는 함수 입력을 사용한 할당 방향(예: struct 또는 interface 의 유형 매개변수) 때문입니다.}

² _{무한한 비결정론의 우주를 유형 검사할 수 없기 때문에 절대주의는 적용되지 않습니다. 그래서 내가 이해하는 바와 같이 이 스레드는 일반성 문제에 대해 wrt를 입력하는 수준으로 최적("스위트 스팟") 제한을 선택하는 것에 관한 것입니다.}

@andrewcmyers 는 다음과 같이 썼습니다.

Java 및 C# 제네릭과 달리 Genus 제네릭 메커니즘은 하위 유형 지정을 기반으로 하지 않습니다.

Java, Scala, Ceylon 및 C++에서 복사하고 싶지 않은 최악의 안티 패턴은 상속 및 하위 분류( 구조적 하위 유형 지정 아님)입니다( C++ 템플릿 문제와 관련 없음).

@thwd 는 다음과 같이 썼습니다.

매개변수화된 유형의 복잡성 측정에 대한 지수는 분산입니다. Go의 유형(인터페이스를 제외하고)은 불변이며 규칙을 유지할 수 있고 유지해야 합니다.

불변으로 하위 유형을 지정하면 공분산의 복잡성을 피할 수 있습니다. 불변성은 또한 하위 분류의 일부 문제(예: Rectangle 대 Square )를 개선하지만 다른 문제(예: 암시적 포함, 평등 등)는 개선하지 않습니다.

@bxqgit 은 다음과 같이 썼습니다.

간단한 구문과 유형 시스템은 Go의 중요한 장점입니다. 제네릭을 추가하면 언어가 Scala나 Haskell처럼 엉망이 됩니다.

스칼라는 OOP, 서브클래싱, FP, 일반 모듈, HKT 및 유형 클래스( implicit 를 통해)를 모두 하나의 PL로 병합하려고 시도합니다. 아마도 typeclasses만으로도 충분할 수 있습니다.

Haskell은 typeclass 제네릭 때문에 둔감할 필요는 없지만 모든 곳에서 순수 함수를 시행하고 제어된 명령 효과를 모델링하기 위해 모나딕 범주 이론을 사용하기 때문에 더 가능성이 높습니다.

따라서 예를 들어 Rust에서 이러한 PL의 둔함과 복잡성을 유형 클래스와 연관시키는 것은 옳지 않다고 생각합니다. 그리고 Rust의 수명+배타적 가변성 차용 추상화에 대해 typeclass를 탓하지 맙시다.

Afaics, Go_의 _Type 매개변수의 의미론 섹션에서 @ianlancetaylor 가 직면한 문제는 개념화 문제입니다. 왜냐하면 그가 (afaics) 분명히 무의식적으로 typeclasses 를 재발명하기 때문입니다.

SortableSlice 와 PSortableSlice 를 병합하여 두 세계의 장점을 모두 누릴 수 있습니까? 좀 빠지는; Less 메소드가 있는 유형이나 내장 유형을 지원하는 매개변수화된 함수를 작성할 방법이 없습니다. 문제는 Less 메서드가 없는 형식에 대해 SortableSlice.Less 를 인스턴스화할 수 없으며 일부 형식에 대해서만 메서드를 인스턴스화하고 다른 형식에는 인스턴스화할 수 없다는 것입니다.

$#$ []T $#$에 대한 Less 메서드의 typeclass 바운드에 대한 requires Less[T] 절은 []T T 에 있습니다. []T . 각 T 에 대한 Less[T] 유형 클래스( Less 메소드 포함) 구현은 메소드의 함수 본문에 구현을 제공하거나 < 구현으로 Sortable[U] 의 메소드가 구현 유형을 나타내는 U 유형 매개변수(예: []T )가 필요한 경우 HKT U[T] 가 필요하다고 생각합니다. Afair @keean 에는 HKT가 필요하지 않은 T 값 유형에 대해 별도의 유형 클래스를 사용하여 정렬을 구조화하는 또 다른 방법 이 있습니다.

[]T Sortable[U] typeclass를 구현하고 있을 수 있습니다. 여기서 U 는 []T 입니다.

(기술적 측면: 일부 유형 인수에 대해서만 메소드를 인스턴스화하고 다른 유형 인수에 대해서는 인스턴스화하지 않는 메커니즘을 사용하여 SortableSlice 및 PSortableSlice 를 병합할 수 있는 것처럼 보일 수 있습니다. 그러나 결과는 컴파일을 희생하는 것입니다. -시간 유형 안전성, 잘못된 유형을 사용하면 런타임 패닉이 발생합니다. Go에서는 이미 인터페이스 유형 및 메소드 및 유형 주장을 사용하여 런타임에 동작을 선택할 수 있습니다. 유형 매개변수를 사용하여 이를 수행하는 다른 방법을 제공할 필요가 없습니다. .)

호출 사이트에 바인딩된 유형 클래스의 선택은 정적으로 알려진 T 에 대해 컴파일 타임에 확인됩니다. 이기종 동적 디스패치가 필요한 경우 이전 게시물에서 설명한 옵션을 참조하십시오.

@keean 이 시간을 내서 여기 와서 typeclass를 설명하는 데 도움이 되기를 바랍니다. 그가 더 전문가이고 제가 이러한 개념을 배우는 데 도움이 되었기 때문입니다. 제 설명에 약간의 오류가 있을 수 있습니다.

내 이전 게시물을 이미 읽은 사람들을 위한 PS 참고 사항, 이기종 컨테이너에 대한 요점을 보다 일관성 있게 만들기 위해 게시한 후 약 10시간(잠시 후)에 광범위하게 편집했습니다.

주기 섹션이 잘못된 것 같습니다. struct 의 S[T]{e} 인스턴스의 런타임 구성은 호출된 일반 함수의 구현 선택과 아무 관련이 없습니다. 그는 아마도 컴파일러가 인수 유형에 대한 일반 함수의 구현을 전문화하는지 알지 못하지만 이러한 유형은 모두 컴파일 타임에 알려져 있다고 생각하고 있을 것입니다.

아마도 유형 검사 섹션 사양은 @keean의 통합 알고리즘을 위한 노드로 고유한 유형의 연결된 그래프 개념을 연구하여 단순화할 수 있습니다. 가장자리로 연결된 모든 고유한 유형은 일치하는 유형을 가져야 하며 할당을 통해 또는 소스 코드에서 다른 방식으로 연결되는 모든 유형에 대해 가장자리가 생성됩니다. 합집합과 교집합이 있는 경우(이전 게시물에서) 할당 방향을 고려해야 합니다( 어떻게든? ). 각각의 고유한 알 수 없는 유형은 Top 의 LUB(최소 상한) 및 Bottom 의 GLB(최대 하한)로 시작하여 제약 조건이 이러한 경계를 변경할 수 있습니다. 연결된 유형에는 호환 가능한 경계가 있어야 합니다. 제약 조건은 모두 typeclass 경계여야 합니다.

구현 중:

예를 들어, 각 인스턴스화에 대해 새 함수 복사본을 생성하여 매개변수화된 함수를 구현하는 것이 항상 가능합니다. 여기서 새 함수는 유형 매개변수를 유형 인수로 대체하여 생성됩니다.

정확한 기술 용어는 monomorphization 이라고 생각합니다.

이 접근 방식은 상당한 추가 컴파일 시간과 코드 크기 증가를 대가로 가장 효율적인 실행 시간을 산출합니다. 인라인하기에 충분히 작은 매개변수화된 함수에는 좋은 선택일 수 있지만 대부분의 다른 경우에는 좋지 않은 절충안이 될 것입니다.

프로파일링은 프로그래머에게 어떤 기능이 단형성으로부터 가장 많은 이점을 얻을 수 있는지 알려줄 것입니다. 아마도 Java Hotspot 옵티마이저는 런타임에 단일화 최적화를 수행합니까?

@egonelbre 는 다음과 같이 썼습니다.

다른 곳에서 온 토론의 개요를 제공하려고 하는 Summary of Go Generics Discussions 가 있습니다.

개요 섹션은 컨테이너의 인스턴스에 대한 boxing 참조의 보편적인 사용이 C++의 템플릿 단일화에 완전히 반대되는 유일한 디자인 축임을 암시하는 것 같습니다. 그러나 유형 클래스 경계( C++ 템플릿으로도 구현될 수 있지만 항상 단일화됨)는 컨테이너 유형 매개변수가 아닌 함수에 적용됩니다. 따라서 개요에는 각 유형 클래스 경계 함수를 단일화할지 여부를 선택할 수 있는 유형 클래스에 대한 설계 축이 누락되었습니다. 유형 클래스를 사용하여 우리는 항상 프로그래머를 더 빠르게 만들고(더 적은 상용구) 컴파일러/실행을 더 빠르게/느리게 만드는 것과 코드 팽창을 더 크게/더 작게 만드는 것 사이에서 보다 세련된 균형을 얻을 수 있습니다. 내 이전 게시물에 따르면 아마도 최적은 단일화할 기능의 선택이 프로파일러 기반(자동으로 또는 주석에 의해 더 가능성이 높음)인 경우일 것입니다.

문제: 일반 데이터 구조 섹션에서:

단점

• 일반 구조는 모든 용도에서 기능을 축적하는 경향이 있으므로 컴파일 시간이 증가하거나 코드가 부풀어 오르거나 더 똑똑한 링커가 필요합니다.

유형 클래스의 경우 인터페이스를 사용하는 함수에 제공되는 데이터 유형에 대해서만 인터페이스를 구현하면 되므로 이는 사실이 아니거나 문제가 되지 않습니다. Typeclass는 모든 데이터 유형을 class 구현을 위한 메소드에 바인딩하는 OOP와 달리 인터페이스에 대한 구현의 늦은 바인딩에 관한 것입니다.

또한 모든 메서드를 단일 인터페이스에 넣을 필요는 없습니다. 함수 선언에 바인딩된 유형 클래스의 requires 절(컴파일러에서 암시적으로 유추하더라도)은 필요한 인터페이스를 혼합 및 일치시킬 수 있습니다.

• 일반 구조와 이에 작동하는 API는 호출자에게 인지 부담을 줄 수 있는 특수 목적 API보다 더 추상적인 경향이 있습니다.

이 우려를 상당히 개선한다고 생각하는 반대 논거는 본질적으로 동일한 일반 알고리즘의 무한한 수의 특수 사례 재구현을 학습하는 인지 부담이 무한하다는 것입니다. 반면에 추상적인 일반 API를 배우는 것은 제한적입니다.

• 심층 최적화는 매우 일반적이지 않고 컨텍스트에 따라 다르므로 일반 알고리즘에서 최적화하기가 더 어렵습니다.

이것은 유효한 사기가 아닙니다. 80/20 규칙은 프로파일링할 때 필요하지 않은 코드에 무한한 복잡성(예: 조기 최적화)을 추가하지 말라고 말합니다. 프로그래머는 20%의 경우에서 자유롭게 최적화할 수 있고 나머지 80%는 일반 API의 제한된 복잡성과 인지 부하에 의해 처리됩니다.

여기서 우리가 실제로 얻고 있는 것은 언어 및 일반 API 도움말의 규칙성입니다. 그 단점은 실제로 올바르게 개념화되지 않았습니다.

대체 솔루션:

• 복잡한 구조 대신 단순한 구조 사용
  
  
  
  • 예를 들어 Set 대신 map[int]struct{} 사용
  
  

Rob Pike(그리고 나는 그가 비디오에서 그 요점을 말하는 것도 봤습니다)는 일반 컨테이너가 일반 기능을 만들기에 충분하지 않다는 요점을 놓치고 있는 것 같습니다. T in map[T] 가 필요하므로 입력, 출력 및 자체 struct 에 대한 함수에서 일반 데이터 유형을 전달할 수 있습니다. 컨테이너 유형 매개변수에 대한 제네릭은 제네릭 API를 표현하는 데 완전히 부족하고 제네릭 API는 제한된 복잡성과 인지 부하 및 언어 생태계에서 규칙성을 얻기 위해 필요합니다. 또한 제네릭이 아닌 코드에서 요구하는 리팩토링 수준(쉽게 리팩토링할 수 없는 모듈의 합성 가능성 감소)이 증가하는 것을 보지 못했습니다. 이것이 제가 첫 번째 게시물에서 언급한 표현 문제에 대한 것입니다.

일반 접근 방식 섹션에서:

패키지 템플릿
이것은 Modula-3, OCaml, SML(소위 "펑터") 및 Ada에서 사용하는 접근 방식입니다. 전문화를 위해 개별 유형을 지정하는 대신 전체 패키지가 제네릭입니다. 가져올 때 유형 매개변수를 수정하여 패키지를 전문화합니다.

내가 틀릴 수도 있지만 이것은 정확하지 않은 것 같습니다. ML 펑터(FP 펑터와 혼동하지 말 것)는 유형 매개변수화된 상태로 출력을 반환할 수도 있습니다. 그렇지 않으면 다른 제네릭 함수 내에서 알고리즘을 사용할 방법이 없으므로 제네릭 모듈은 다른 제네릭 모듈을 재사용할 수 없습니다(구체 유형을 사용하여 다른 제네릭 모듈로 가져옴). 이것은 제네릭, 모듈 재사용 등의 요점을 지나치게 단순화한 다음 완전히 놓치려는 시도로 보입니다.

오히려 내 이해 는 패키지(일명 모듈) 유형 매개변수화를 통해 유형 매개변수를 struct , interface 및 func 그룹화에 적용할 수 있다는 것입니다.

더 복잡한 유형 시스템
이것이 Haskell과 Rust가 취하는 접근 방식입니다.
[…]
단점:

• 더 간단한 언어에 맞추기 어렵습니다(https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwGlB-n40kJ).

링크된 문서에서 @ianlancetaylor 인용:

당신이 그것을 믿는다면, 그것은 지적 가치가
Go 런타임의 맵 및 슬라이스 코드는 다음과 같은 의미에서 일반적이지 않습니다.
유형 다형성을 사용합니다. 본다는 점에서 일반적이다.
유형을 이동하고 비교하는 방법을 보려면 반사 정보를 입력하십시오.
가치. 그러므로 우리는
유형을 사용하는 비다형성 코드를 작성하여 Go의 "일반" 코드
정보를 효율적으로 반영한 다음 해당 코드를
컴파일 시간 유형 안전 상용구(맵 및 슬라이스의 경우
물론 이 보일러 플레이트는 컴파일러에서 제공합니다).

그리고 제네릭이 추가된 Go 상위 집합에서 컴파일러가 변환하면 Go 코드로 출력됩니다. 그러나 포장은 내가 이미 언급한 구성 가능성이 부족하기 때문에 포장과 같은 일부 묘사를 기반으로 하지 않습니다. 좋은 구성 가능한 제네릭 유형 시스템에 대한 지름길은 없다는 것이 요점입니다. 실제로 제네릭이 아닌 구성할 수 없는 일부 해킹을 추가하면 결국 패치워크의 반자동 일반성과 모퉁이 케이스의 불규칙성과 Go 생태계 코드를 만드는 해결 방법의 클러스터 관성을 생성할 것이기 때문에 올바르게 수행하거나 아무 것도 하지 않습니다. 이해할 수 없는.

또한 크고 복잡한 Go 프로그램을 작성하는 대부분의 사람들이
제네릭에 대한 상당한 필요성을 찾지 못했습니다. 지금까지는 더 그랬다.
짜증나는 사마귀--에 대한 상용구를 세 줄 작성해야 합니다.
유용한 쓰기에 대한 주요 장벽이 아니라 정렬할 각 유형
암호.

예, 이것은 완전한 유형 클래스 시스템으로 가는 것이 정당화될 수 있는지 여부에 대한 내 생각 중 하나였습니다. 모든 라이브러리가 이를 기반으로 한다면 분명히 아름다운 조화가 될 수 있지만 일반성에 대한 기존 Go 핵의 관성에 대해 생각하고 있다면 아마도 많은 프로젝트에서 추가로 얻을 수 있는 시너지가 낮을 것입니다. ?

그러나 typeclass 구문의 변환기가 Go가 제네릭을 모델링할 수 있는 기존 수동 방식을 에뮬레이트하면(편집: @andrewcmyers 상태가 그럴듯 하다는 것을 방금 읽었습니다), 이것은 덜 번거롭고 유용한 시너지 효과를 찾을 수 있습니다. 예를 들어, 튜플을 에뮬레이트하는 struct 에 구현된 interface 로 두 개의 매개변수 유형 클래스를 에뮬레이트할 수 있거나 @jba 가 컨텍스트에서 인라인 interface 를 사용하는 아이디어를 언급 했다는 것을 깨달았습니다 . type 와 함께 이름을 지정하지 않는 한 분명히 struct 는 명목상 형식 대신 구조적으로 입력됩니까? 또한 interface 의 방법이 다른 interface 를 입력할 수 있음을 확인했습니다. 하지만 잠이 덜 깬 상태에서 더 생각해 볼 필요가 있습니다.

대부분의 Go 팀이 C++를 좋아하지 않는다고 말하는 것이 타당하다고 생각합니다.
하나의 Turing 완전한 언어가 겹쳐진 템플릿
두 언어가 가질 수 있는 또 다른 튜링 완전 언어
완전히 다른 구문과 두 언어의 프로그램은
매우 다른 방식으로 작성되었습니다. C++ 템플릿은 경고 역할을 합니다.
복잡한 구현이 전체에 퍼져 있기 때문입니다.
표준 라이브러리로 인해 C++ 오류 메시지가
놀라움과 놀라움. 이것은 Go가 따라갈 길이 아닙니다.

나는 아무도 동의하지 않을 것입니다! 단형성의 이점은 Turing 완전한 제네릭 메타프로그래밍 엔진의 단점과 직교합니다.

Btw, C++ 템플릿의 설계 오류 는 생성적(적용적) ML 펑터의 결함과 동일한 생성적 본질 로 보입니다 . 최소 전력의 원칙이 적용됩니다.

@ianlancetailor 는 다음과 같이 썼습니다.

내장 매개변수화된 유형을 추가하여 Go가 점점 더 복잡해지는 것을 보는 것은 실망스럽습니다.

이 문제에 대한 추측에도 불구하고 나는 이것이 일어날 가능성이 극히 낮다고 생각합니다.

나는 희망한다. 나는 Go가 일관된 제네릭 시스템을 추가하거나 제네릭이 없을 것이라는 점을 받아들여야 한다고 굳게 믿습니다.

나는 트랜스파일러에 대한 포크가 발생할 가능성이 더 높다고 생각합니다. 부분적으로는 그것을 구현하기 위한 자금이 있고 그렇게 하는 데 관심이 있기 때문입니다. 그러나 나는 여전히 상황을 분석하고 있다.

그것은 생태계를 파괴할 것이지만 적어도 Go는 최소한의 원칙에 순수하게 남을 수 있습니다. 따라서 생태계 파괴를 피하고 내가 원하는 다른 혁신 을 허용하기 위해 아마도 그것을 상위 집합으로 만들지 않고 대신 Zero로 이름을 지정할 것입니다.

@pciet 은 다음과 같이 썼습니다.

내 투표는 일반화된 애플리케이션 제네릭에 반대하고 여러 기본 유형에서 작동하는 append 및 copy $와 같은 더 많은 기본 제공 제네릭 기능에 찬성입니다. 컬렉션 유형에 sort 및 search 를 추가할 수 있습니까?

이 관성을 확장하면 포괄적인 제네릭 기능이 Go로 만들어지는 것을 막을 수 있습니다. 제네릭을 원하는 사람들은 더 푸른 목초지로 떠날 것입니다. @andrewcmyers는 다음과 같이 반복했습니다.

내장된 매개변수화된 유형을 추가하여 Go가 점점 더 복잡해지는 것을 보는 것은 ~입니다~ 실망스러울 것입니다. 프로그래머가 자신의 매개변수화된 유형을 작성할 수 있도록 언어 지원을 추가하는 것이 좋습니다.

@shelby3

Afaik, 이제 Go에서 이기종 컨테이너/컬렉션을 수행하는 유일한 방법은 모든 유형을 빈 인터페이스에 포함시키는 것입니다.{} 이 인터페이스는 타이핑 정보를 버리고 있으며 캐스트 및 런타임 유형 검사가 필요하다고 가정합니다. 정적 타이핑.

Go에서 인터페이스 컬렉션의 정적 유형 검사에 대해서는 위의 주석에서 래퍼 패턴을 참조하세요.{}

좋은 구성 가능한 제네릭 유형 시스템에 대한 지름길은 없다는 것이 요점입니다. 실제로 제네릭이 아닌 구성 불가능한 해킹을 추가하기 때문에 올바르게 수행하거나 아무 것도 하지 않습니다.

이것을 더 설명할 수 있습니까? 컬렉션 유형의 경우 포함된 항목의 필요한 일반 동작을 정의하는 인터페이스가 있는 경우 함수를 작성하는 것이 합리적으로 보입니다.

@pciet 이 코드는 말 그대로 @shelby3 가 설명하고 반패턴을 고려했던 것과 똑같은 일을 하고 있습니다. 이전에서 인용:

이것은 문서화 및 테스트 예제에서 컴파일 시간 유형 안전성을 위해 래퍼 패턴(@pierrre에게 감사)을 입력하고 런타임 유형 안전성에 대한 반영 검사를 제공합니다.

유형 정보가 없는 코드를 작성하고 유형별로 반사를 사용하여 캐스트 및 런타임 유형 검사를 추가합니다. 이것이 바로 @shelby3 가 불평했던 것입니다. 나는 이 접근법을 "단일형화(monomorphization-by-hand)"라고 부르는 경향이 있으며, 컴파일러에 가장 적합하다고 생각하는 지루한 잡일입니다.

이 접근 방식에는 여러 가지 단점이 있습니다.

• 손으로 또는 go generate 와 유사한 도구로 유지 관리되는 유형별 래퍼가 필요합니다.
• (도구 대신 손으로 하는 경우) 런타임까지 잡히지 않는 상용구에서 실수를 할 수 있는 기회
• 더 느리고 더 많은 메모리를 사용하는 정적 디스패치 대신 동적 디스패치가 필요합니다.
• 컴파일 시간 형식 어설션 대신 런타임 리플렉션을 사용하므로 속도도 느립니다.
• 구성 불가능: 추상화하려는 비어 있지 않은 모든 인터페이스에 대해 다른 간접 계층을 핸드롤링하지 않는 한 유형에 대한 유형 클래스와 유사한(또는 인터페이스와 유사한) 경계를 사용할 기회가 없는 구체적인 유형에 대해 전적으로 작동합니다.

이것을 더 설명할 수 있습니까? 컬렉션 유형의 경우 포함된 항목의 필요한 일반 동작을 정의하는 인터페이스가 있는 경우 함수를 작성하는 것이 합리적으로 보입니다.

이제 구체적인 유형 대신 또는 추가로 경계를 사용하려는 모든 곳에서 모든 인터페이스 유형에 대해서도 동일한 유형 검사 상용구를 작성해야 합니다. 그것은 당신이 작성해야 하는 정적 유형 래퍼의 (아마도 조합적) 폭발을 더 복잡하게 만들 뿐입니다.

내가 아는 한 인터페이스 조합에 대한 경계와 같이 오늘날 Go의 유형 시스템에서는 전혀 표현할 수 없는 아이디어도 있습니다. 우리가 가지고 있다고 상상해보십시오.

type Foo interface {
    ...
}

type Bar interface {
    ...
}

순전히 정적 유형 검사를 사용하여 Foo 및 Bar 모두를 구현하는 유형을 원한다는 것을 어떻게 표현합니까? 내가 아는 한 이것은 Go에서는 불가능합니다(정적 유형 안전을 피하면서 실패할 수 있는 런타임 검사에 의존하지 않음).

유형 클래스 기반 제네릭 시스템을 사용하면 이것을 다음과 같이 표현할 수 있습니다.

func baz<T Foo + Bar>(t T) {
    ...
}

@tarcieri

순수한 정적 유형 검사를 사용하여 Foo와 Bar를 모두 구현하는 유형을 원한다는 것을 어떻게 표현합니까?

단순히 다음과 같이:

type T interface {
    Foo
    Bar
}

func baz(t T) { ... }

@sbinet 깔끔함 , TIL

개인적으로 나는 런타임 리플렉션이 잘못된 기능이라고 생각하지만 그건 나일뿐... 관심 있는 사람이 있으면 이유를 설명할 수 있습니다.

모든 종류의 제네릭을 구현하는 사람은 먼저 Stepanov의 "프로그래밍 요소"를 여러 번 읽어야 한다고 생각합니다. 그것은 많은 Not Invented Here 문제와 바퀴를 재발명하는 것을 피할 것입니다. 읽고 나면 "C++ 개념"과 "Haskell Typeclasses"가 제네릭을 수행하는 올바른 방법인 이유가 분명해야 합니다.

이 문제가 다시 활성화된 것 같습니다.
여기는 밀짚모자 프로포즈 놀이터
https://go-li.github.io/test.html
여기에서 데모 프로그램을 붙여넣기만 하면 됩니다.
https://github.com/go-li/demo

이 단일 매개변수를 평가해 주셔서 감사합니다.
함수 제네릭.

우리는 해킹된 gccgo를 유지하고
이 프로젝트는 당신 없이는 불가능했을 것이므로 우리는
다시 기여하고 싶었습니다.

또한 귀하가 채택한 제네릭이 무엇이든, 계속해서 훌륭한 작업을 수행하기를 기대합니다!

@anlhord 이에 대한 구현 세부 정보는 어디에 있습니까? 구문에 대해 어디에서 읽을 수 있습니까? 무엇을 구현합니까? 구현되지 않은 것은 무엇입니까? 이 구현의 사양은 무엇입니까? 그것에 대한 장단점은 무엇입니까?

플레이그라운드 링크에는 이에 대한 최악의 예가 포함되어 있습니다.

package main

import "fmt"

func main() {
    fmt.Println("Hello, playground")
}

그 코드는 그것을 사용하는 방법과 내가 무엇을 테스트할 수 있는지에 대해 아무 것도 알려주지 않습니다.

이러한 사항을 개선할 수 있다면 귀하의 제안이 무엇인지, 이전 제안과 어떻게 비교되는지 더 잘 이해하는 데 도움이 될 것입니다. / 여기에서 제기된 다른 사항이 어떻게 적용되는지 확인하십시오.

이것이 귀하의 의견에 대한 문제를 이해하는 데 도움이 되기를 바랍니다.

@joho 는 다음과 같이 썼습니다.

접근 방식 평가에 대한 지침으로 학술 문헌에 가치가 있습니까?

주제에 대해 읽은 유일한 문서는 개발자가 제네릭 유형의 이점을 얻 습니까? (페이월 죄송합니다. pdf 다운로드로 가는 길을 구글링할 수 있습니다.) 다음과 같은 내용이 있었습니다.

결과적으로 실험에 대한 보수적 해석
제네릭 유형은 절충안으로 간주될 수 있습니다.
긍정적인 문서화 특성과
부정적인 확장성 특성.

Go는 이미 interface (명시적인 T 일반 유형 매개변수 없이) 유형 클래스를 가지고 있기 때문에 OOP와 서브클래싱(예: Java 및 C++의 클래스)은 둘 다 심각하게 고려되지 않을 것이라고 가정합니다. Java는 많은 사람들이 패턴을 반대한다고 주장했기 때문에 복사하지 말아야 할 항목으로 인용되었습니다. Upthread 나는 그 주장의 일부에 연결했습니다. 관심이 있는 사람이 있으면 해당 분석에 대해 더 자세히 알아볼 수 있습니다.

나는 아직 upthread 에 언급된 Genus system 과 같은 새로운 연구를 공부하지 않았습니다. 나는 Scala에 대한 불만으로 인해 많은 패러다임(예: 서브클래싱, 다중 상속, OOP, 특성 선형화, implicit , typeclasses, 추상 유형 등)을 혼합하려고 시도하는 "주방 싱크" 시스템을 경계합니다. Scala 3(일명 Dotty 및 DOT 미적분)에서 개선될 수 있지만 실제로는 많은 코너 케이스가 있습니다. 비교 테이블 이 실험용 Scala 3 또는 현재 버전의 Scala와 비교되고 있는지 궁금합니다.

따라서 OOP+서브클래싱에 비해 확장성과 유연성이 크게 향상되는 입증된 일반성 시스템 측면에서 ML 펑터와 Haskell 유형 클래스가 남아 있습니다.

나는 @keean 의 비공개 토론 중 일부를 기록했고 ML functor 모듈과 typeclasses에 대해 가지고 있었습니다. 하이라이트는 다음과 같습니다.

• typeclasses _model algebra_ (그러나 확인된 공리 없이 ) 각 인터페이스에 대해 단 한 가지 방법으로만 각 데이터 유형을 구현합니다. 따라서 호출 사이트에서 주석 없이 컴파일러가 구현을 암시적으로 선택할 수 있습니다.

• 적용 펑터에는 참조 투명성이 있는 반면 생성 펑터는 각 인스턴스화에 대해 새 인스턴스를 생성하므로 초기화 순서가 변하지 않습니다.

• ML 펑터는 유형 클래스보다 강력하고 유연하지만 더 많은 주석과 잠재적으로 더 많은 코너 케이스 상호 작용을 희생해야 합니다. 그리고 @keean 에 따르면 더 복잡한 유형 시스템인 종속 유형( 관련 유형 의 경우)이 필요합니다. @keean 은 Stepanov 의 _대수학 플러스 유형 클래스로서의 일반성의 표현이 충분히 강력하고 유연 하다고 생각합니다. 그래서 이것이 최첨단의 잘 입증된(하스켈에서 그리고 현재는 Rust에서) 일반성을 위한 최적의 지점인 것 같습니다. 그러나 공리는 유형 클래스에 의해 시행되지 않습니다 .

• 표현식 문제의 다른 축을 따라 확장하는 유형 클래스가 있는 이기종 컨테이너에 대한 공용체를 추가하는 것을 제안했지만 O(log n) 억제되지 않은 변경 가능한 명령에 비해

@larsth 는 다음과 같이 썼습니다.

Go 1.xy 소스 코드 컴파일러에 대한 Go 제네릭 소스 코드인 하나 이상의 실험적 트랜스파일러를 갖는 것은 흥미로울 수 있습니다.

_{추신: Go가 그런 정교한 타이핑 시스템을 채택할지 의심스럽습니다. 하지만 이전 게시물에서 언급한 것처럼 기존 Go 구문에 대한 변환기를 고려하고 있습니다(하단 편집 참조). 그리고 저는 매우 바람직한 Go 기능과 함께 강력한 일반 시스템을 원합니다. Go의 Typeclass 제네릭이 내가 원하는 것처럼 보입니다.}

@bcmills 는 일반성을 위한 컴파일 시간 함수에 대한 그의 제안에 대해 썼습니다.

Go API에서 구체적인 유형이 아닌 interface 유형을 내보내는 것을 옹호하는 데 동일한 주장이 사용되었다고 들었고 그 반대의 경우가 더 일반적입니다. 조기 추상화는 유형을 과도하게 제한하고 API의 확장을 방해합니다. (이러한 예 중 하나는 #19584를 참조하십시오.) 이 주장에 의존하려면 몇 가지 구체적인 예를 제공해야 한다고 생각합니다.

유형 시스템 추상화는 필연적 으로 어느 정도의 자유도를 포기하고 때로는 "안전하지 않은"(즉, 정적으로 확인된 추상화를 위반하여) 이러한 제약 조건에서 벗어나지만 간결하게 주석이 달린 불변으로 모듈식 디커플링.

일반성을 위한 시스템을 설계할 때, 특히 Go의 핵심 철학이 고려되는 경우(예: 평균적인 프로그래머가 우선순위) 생태계의 규칙성과 예측 가능성을 주요 목표 중 하나로 늘리고 싶을 것입니다.

최소 전력의 원칙이 적용됩니다. 일반성을 위한 "숨겨진" 컴파일 시간 함수의 위력/유연성은 예를 들어 생태계에서 소스 코드의 가독성에 해를 끼칠 수 있는 능력과 비교해야 합니다(여기서 모듈식 디커플링은 독자가 주어진 모듈/패키지를 이해하기 위해 암시적 전이 종속성으로 인해 잠재적으로 무한한 양의 코드를 읽을 필요가 없습니다!). 유형 클래스 구현 인스턴스의 암시적 해결은 해당 대수학이 준수되지 않는 경우 이 문제가 있습니다.

물론, 하지만 이는 이미 일반 프로그래밍 메커니즘과 독립적인 Go의 많은 암시적 제약 조건에 대해 사실입니다.

예를 들어, 함수는 인터페이스 유형의 매개변수를 수신하고 초기에 해당 메소드를 순차적으로 호출할 수 있습니다. 해당 함수가 나중에 이러한 메서드를 동시에 호출하도록 변경되면(추가 고루틴을 생성하여) "동시 사용에 안전해야 함" 제약 조건이 유형 시스템에 반영되지 않습니다.

그러나 afaik Go는 이러한 효과를 모듈화하기 위해 추상화를 설계하려고 시도하지 않았습니다. Rust는 그런 추상화를 가지고 있습니다. (btw 내가 생각하기에 일부/대부분의 사용 사례에 대해 과도한 pita/tsuris/limiting이며 더 쉬운 단일 스레드 모델 추상화를 주장하지만 불행히도 Go는 생성된 모든 고루틴을 동일한 스레드로 제한하는 것을 지원하지 않습니다 ) . 그리고 Haskell은 참조 투명성을 위해 순수 함수를 시행하기 때문에 효과에 대한 모나딕 제어가 필요합니다.

@alerca 는 다음과 같이 썼습니다.

유추된 제약 조건의 가장 큰 단점은 완전히 이해하지 않고도 제약 조건을 도입하는 방식으로 유형을 사용하기 쉽게 만든다는 것입니다. 최상의 경우 이는 사용자가 예기치 않은 컴파일 시간 오류에 직면할 수 있음을 의미하지만 최악의 경우 실수로 새로운 제약 조건을 도입하여 소비자를 위해 패키지를 중단할 수 있음을 의미합니다. 명시적으로 지정된 제약 조건은 이를 방지합니다.

동의. 유형의 불변량이 명시적으로 주석 처리되지 않았기 때문에 다른 모듈의 코드를 은밀히 중단할 수 있다는 것은 매우 교활한 일입니다.

@andrewcmyers 는 다음과 같이 썼습니다.

명확히 하자면, gen, cpp, gofmt -r 또는 기타 매크로/템플릿 도구로 수행되는 매크로 스타일 코드 생성이 표준화되더라도 제네릭 문제에 대한 좋은 솔루션이라고 생각하지 않습니다. C++ 템플릿과 동일한 문제가 있습니다: 코드 팽창, 모듈식 유형 검사 부족, 디버깅 어려움. 다른 제네릭 코드의 관점에서 제네릭 코드를 빌드하는 것은 자연스러운 것처럼 시작할수록 악화됩니다. 내 생각에 장점은 제한적입니다. Go 컴파일러 작성자의 삶을 비교적 단순하게 유지하고 효율적인 코드를 생성합니다. 명령 캐시 압력이 없는 한 최신 소프트웨어에서 자주 발생하는 상황입니다!

@keean 님 의 의견에 동의 하는 것 같습니다.

@shelby3 댓글 감사합니다. 다음에 문서 자체에서 직접 댓글/편집을 할 수 있습니까? 수정해야 할 부분을 추적하는 것이 더 쉽고 모든 메모가 적절한 응답을 받도록 하는 것이 더 쉽습니다.

개요 섹션은 Java의 인스턴스에 대한 boxing 참조의 보편적 사용을 의미하는 것 같습니다 ...

포괄적인 목록이 아님을 명확히 하기 위해 주석을 추가했습니다. 사람들이 서로 다른 절충안의 요지를 얻을 수 있도록 주로 거기에 있습니다. 다양한 접근 방식의 전체 목록은 아래에 있습니다.

일반 구조는 모든 용도에서 기능을 축적하는 경향이 있으므로 컴파일 시간이 증가하거나 코드가 부풀어 오르거나 더 똑똑한 링커가 필요합니다.
유형 클래스의 경우 인터페이스를 사용하는 함수에 제공되는 데이터 유형에 대해서만 인터페이스를 구현하면 되므로 이는 사실이 아니거나 문제가 되지 않습니다. Typeclass는 모든 데이터 유형을 클래스 구현을 위한 메소드에 바인딩하는 OOP와 달리 인터페이스에 대한 구현의 늦은 바인딩에 관한 것입니다.

그 진술은 장기적으로 일반 데이터 구조에 어떤 일이 일어나는지에 관한 것입니다. 다시 말해서, 일반적인 데이터 구조는 종종 다른 목적을 위해 여러 개의 작은 구현을 갖는 것보다 모든 다른 용도를 수집하게 됩니다. 예를 들어 https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html을 보십시오.

"기계적 설계"와 "많은 유연성"만으로는 좋은 "일반 솔루션"을 만들기에 충분하지 않다는 점에 유의하는 것이 중요합니다. 또한 좋은 지침, 물건을 어떻게 사용해야 하는지, 무엇을 피해야 하는지, 사람들이 어떻게 사용하는지 고려하는 것도 필요합니다.

일반 구조와 이에 작동하는 API는 목적에 맞게 제작된 API보다 추상적인 경향이 있습니다...

이 우려를 크게 개선한다고 생각하는 반대 논거는 본질적으로 동일한 일반 알고리즘의 무한한 수의 특수 사례 재구현을 학습하는 인지 부담이 무한하다는 것입니다...

많은 유사한 API의 인지 부하에 대한 메모를 추가했습니다.

특수한 경우의 재구현은 실제로 제한이 없습니다. 고정된 수의 전문화만 볼 수 있습니다.

이것은 유효한 사기가 아닙니다.

당신은 어떤 점에 동의하지 않을 수도 있고, 나는 그들 중 상당수에 어느 정도 동의하지 않습니다. 그러나 나는 그들의 관점을 이해하고 사람들이 매일 직면하는 문제를 이해하려고 노력합니다. 문서의 목표는 "어떤 것이 누군가에게 얼마나 성가신 일인지"를 판단하는 것이 아니라 다양한 의견을 수집하는 것입니다.

그러나 이 문서는 "실제 문제로 추적 가능한 문제"에 대한 입장을 취합니다. 포럼에서 추상적이고 용이한 문제는 이해가 구축되지 않은 채 무의미한 수다로 흘러가는 경향이 있기 때문입니다.

여기서 우리가 실제로 얻고 있는 것은 언어 및 일반 API 도움말의 규칙성입니다.

물론 실제로는 1% 미만의 경우에만 이러한 최적화 스타일이 필요할 수 있습니다.

대체 솔루션:

대체 솔루션은 제네릭을 대체하기 위한 것이 아닙니다. 그러나 오히려 다양한 종류의 문제에 대한 잠재적 솔루션 목록입니다.

패키지 템플릿

내가 틀릴 수도 있지만 이것은 정확하지 않은 것 같습니다. ML 펑터(FP 펑터와 혼동하지 말 것)는 유형 매개변수화된 상태로 출력을 반환할 수도 있습니다.

더 명확한 표현을 제공하고 필요한 경우 두 가지 접근 방식으로 나눌 수 있습니까?

@egonelbre 또한 응답해 주셔서 감사합니다. 그래서 어떤 점에서 내 생각을 더 명확히 해야 하는지 알 수 있습니다.

다음에 문서 자체에서 직접 댓글/편집을 할 수 있습니까?

사과를 드리고 싶지만 Google 문서의 토론 기능을 사용한 적이 없고 배울 시간이 없으며 나중에 참조할 수 있도록 Github에 있는 토론에 연결할 수 있기를 원합니다.

예를 들어 https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html을 보십시오.

Scala 컬렉션 라이브러리의 디자인은 이전 핵심 팀원 중 한 명을 포함하여 많은 사람들에게 비판을 받았습니다. LtU에 게시된 댓글 이 대표적입니다. 참고 이 스레드의 이전 게시물 중 하나에 다음을 추가하여 이 문제를 해결했습니다.

나는 Scala에 대한 불만으로 인해 많은 패러다임(예: 서브클래싱, 다중 상속, OOP, 특성 선형화, implicit , typeclasses, 추상 유형 등)을 혼합하려고 시도하는 "주방 싱크" 시스템을 경계합니다. Scala 3(Dotty 및 DOT 미적분이라고도 함)에서 개선될 수 있지만 실제로는 많은 코너 케이스가 있습니다.

Scala의 컬렉션 라이브러리는 다형성을 위한 typeclasses만 있는 PL용으로 만들어진 라이브러리를 대표할 것이라고 생각하지 않습니다. 스칼라 컬렉션은 복잡한 계층 구조를 유발하는 상속 방지 패턴을 사용하고 CanBuildFrom implicit 도우미와 결합하여 복잡성 예산을 폭발시켰습니다. 그리고 Stepanov의 _프로그래밍의 요소_ 가 대수라는 @keean의 요점을 준수하면 우아한 컬렉션 라이브러리가 생성될 수 있다고 생각합니다. 수학을 기반으로 하는 펑터(FP) 기반 컬렉션 라이브러리(예: Haskell을 복사하지 않음 )에 대한 첫 번째 대안이었습니다. 나는 이것을 실제로 보고 싶습니다. 이것이 제가 새로운 PL의 디자인에 대해 그와 협력/토론하고 있는 한 가지 이유입니다. 그리고 이 순간부터 나는 그 언어를 처음에 Go로 변환할 계획 입니다 . 그래서 우리는 그것이 어떻게 작동하는지 보기 위해 곧 실험을 할 수 있기를 바랍니다.

내 생각에 바둑 커뮤니티/철학은 실패한 실험으로 언어를 서두르고 오염시키는 것보다 실제로 작동하는 것이 무엇인지 확인하고 나중에 입증되면 채택하기를 기다리고 있습니다. 반복해서 말했듯이 이러한 모든 추상적인 주장은 그다지 건설적이지 않기 때문입니다(PL 디자인 이론가를 제외하고). 또한 위원회에서 일관된 제네릭 시스템을 설계하는 것은 아마도 불가능할 것입니다.

또한 좋은 지침, 물건을 어떻게 사용해야 하는지, 무엇을 피해야 하는지, 사람들이 어떻게 사용하는지 고려하는 것도 필요합니다.

그리고 프로그래머가 동일한 언어로 사용할 수 있는 다양한 패러다임을 혼합하지 않는 것이 도움이 될 것이라고 생각합니다. 그것은 분명히 필요하지 않습니다( @keean 그리고 나는 그 주장을 증명해야 합니다). 복잡성 예산은 유한하며 포함된 기능만큼 중요한 것은 PL에서 제외 된다는 철학에 우리 둘 다 책임이 있다고 생각합니다.

그러나 이 문서는 "실제 문제로 추적 가능한 문제"에 대한 입장을 취합니다. 포럼에서 추상적이고 용이한 문제는 이해가 구축되지 않은 채 무의미한 수다로 흘러가는 경향이 있기 때문입니다.

동의. 그리고 모든 사람이 추상적 요점을 따르는 것도 어렵습니다. 악마는 세부 사항과 실제 결과에 있습니다.

물론 실제로는 1% 미만의 경우에만 이러한 최적화 스타일이 필요할 수 있습니다.

Go에는 이미 일반성을 위한 interface 가 있으므로 호출 사이트에서 제공하는 인터페이스의 인스턴스에 대해 T 유형에 대한 매개변수 다형성이 필요하지 않은 경우를 처리할 수 있습니다.

어디선가 읽었던 것 같은데, 실제로 Go의 표준 라이브러리가 가장 업데이트된 관용구를 최적으로 사용하는 데 일관성이 없다는 주장입니다. 나는 아직 바둑에 대한 경험이 없기 때문에 그것이 사실인지 모르겠습니다. 내가 말하고 있는 요점은 선택된 제네릭 패러다임이 모든 라이브러리를 감염시킨다는 것입니다. 따라서 예, 지금으로서는 코드의 1%만 필요하다고 주장할 수 있습니다. 왜냐하면 제네릭의 필요성을 피하는 관용구가 이미 있기 때문입니다.

당신이 맞을 수도 있습니다. 또한 특정 언어 기능을 얼마나 사용할 것인지에 대해 회의적입니다. 실험을 통해 알아가는 것이 제가 나아갈 길이라고 생각합니다. PL 설계는 반복적인 프로세스이며, 문제는 프로세스를 반복하기 어렵게 만드는 관성과 싸워야 한다는 것입니다. 따라서 Rob Pike가 아이디어를 실험하고 테스트하기 위해 프로그램용 코드를 작성하는 프로그램(생성 도구 및 트랜스파일러 작성을 의미)을 작성하도록 제안한 동영상에서 Rob Pike가 옳다고 생각합니다.

특정 기능 세트가 현재 Go에 있는 기능보다 실제로 우수하다는 것을 보여줄 수 있을 때(희망은 사용의 인기도), 이를 Go에 추가하는 것에 대한 합의 형식을 볼 수 있습니다. 다른 사람들도 Go로 변환할 수 있는 실험적인 시스템을 만들도록 권장합니다.

더 명확한 표현을 제공하고 필요한 경우 두 가지 접근 방식으로 나눌 수 있습니까?

나는 Go에 지나치게 단순한 템플릿 기능을 추가하려는 시도를 막고자 하는 사람들에게 제 목소리를 추가하고 그것이 제네릭이라고 주장합니다. IOW, 결국 나쁜 관성이 되지 않을 적절한 기능의 제네릭 시스템은 제네릭에 대해 지나치게 단순한 디자인을 갖고자 하는 욕구와 근본적으로 양립할 수 없다고 생각합니다. 제네릭 시스템인 Afaik은 잘 고려되고 검증된 전체론적 설계가 필요합니다. @larsth 가 쓴 것을 되새기며 진지한 제안을 하는 사람들은 먼저 트랜스파일러를 구축(또는 gccgo 프론트엔드의 포크에서 구현)한 다음 제안을 실험하여 우리 모두가 그 한계를 더 잘 이해할 수 있도록 권장합니다. @ianlancetaylor 가 나쁜 관성의 오염이 Go에 추가될 것이라고 생각하지 않았다는 업스레드를 읽도록 권장받았습니다. 패키지 수준 매개변수화 제안에 대한 구체적인 불만 사항, 제안한 사람에 대한 내 제안은 우리 모두가 함께 사용할 수 있는 컴파일러를 만들지 여부를 고려한 다음 우리가 좋아하는 것과 싫어하는 것에 대한 예에 대해 이야기할 수 있습니다. t는 그것에 대해 좋아합니다. 그렇지 않으면 추상적으로 설명된 제안을 올바르게 이해하지 못하기 때문에 서로 과거 이야기를 하고 있습니다. 나는 매개변수화된 패키지가 매개변수화된 다른 패키지에서 어떻게 재사용될 수 있는지 이해하지 못하기 때문에 제안을 이해하지 못할 것입니다. IOW, 패키지가 매개변수를 사용하는 경우 매개변수가 있는 다른 패키지도 인스턴스화해야 합니다. 그러나 제안은 매개변수화된 패키지를 인스턴스화하는 유일한 방법은 유형 매개변수가 아니라 구체적인 유형을 사용하는 것이라고 말하는 것 같았습니다.

너무 긴 사과. 내가 오해하지 않았는지 확인하고 싶습니다.

@shelby3 아, 그럼 처음 불만을 잘못 이해했습니다. 먼저 "Generics Approaches"의 섹션이 구체적인 제안이 아님을 분명히 해야 합니다. 그것들은 접근 방식, 즉 구체적인 제네릭 접근 방식에서 취할 수 있는 더 큰 디자인 결정입니다. 그러나 그룹화는 기존 구현 또는 구체적/비공식 제안에 의해 강력하게 동기가 부여됩니다. 또한, 나는 그 목록에서 여전히 누락된 적어도 5개의 큰 아이디어가 있다고 생각합니다.

"패키지 템플릿" 접근 방식의 경우 두 가지 변형이 있습니다(문서의 링크된 토론 참조).

1. "인터페이스" 기반 일반 패키지,
2. 명시적으로 일반 패키지.

1. 특별한 일을 하기 위해 일반 패키지가 필요하지 않습니다. 예를 들어 현재 container/ring 는 전문화에 사용할 수 있습니다. 패키지에 있는 인터페이스의 모든 인스턴스를 구체적인 유형으로 교체하고 순환 가져오기를 무시하는 것으로 여기에서 "특화"를 상상해 보십시오. 해당 패키지 자체가 다른 패키지를 전문화할 때 "인터페이스"를 전문화로 사용할 수 있습니다. 그러면 이 사용도 전문화될 것입니다.

2. 두 가지로 볼 수 있습니다. 하나는 각 가져오기에서 재귀적 구체적인 전문화입니다. 템플릿/매크로와 유사하지만 "부분적으로 적용된 패키지"는 없습니다. 물론 기능적 측면에서도 볼 수 있습니다. 일반 패키지는 매개변수가 포함된 부분적이며 사용자는 이를 전문화합니다.

예, 하나의 매개변수화된 패키지를 다른 패키지에서 사용할 수 있습니다.

@larsth 가 쓴 내용을 반영하듯, 진지한 제안을 하는 사람들은 먼저 트랜스파일러를 구축(또는 gccgo 프론트엔드의 포크에서 구현)한 다음 제안을 실험하여 우리 모두가 그 한계를 더 잘 이해할 수 있도록 권장합니다.

나는 이것이 그 접근 방식을 명시적으로 지시하지 않았다는 것을 알고 있지만 아이디어를 테스트하기 위해 4개의 다른 프로토타입이 있습니다. 물론 완전한 트랜스파일러는 아니지만 몇 가지 아이디어를 테스트하기에 충분합니다. 즉, "다른 패키지에서 매개변수화된 패키지 사용" 사례를 구현한 사람이 있는지 확실하지 않습니다.

매개변수화된 패키지는 ML 모듈과 매우 흡사합니다(ML 기능자는 매개변수가 다른 패키지일 수 있음). 이것이 "적용적" 또는 "생성적"으로 작동할 수 있는 두 가지 방법이 있습니다. 적용 펑터는 값 또는 유형 별칭과 같습니다. 생성 펑터를 구성해야 하며 각 인스턴스가 다릅니다. 이에 대해 생각하는 또 다른 방법은 패키지가 적용 가능하려면 순수해야 한다는 것입니다(즉, 패키지 수준에서 변경 가능한 변수가 아님). 패키지 수준에 상태가 있는 경우 해당 상태를 초기화해야 하므로 생성적이어야 하며 생성적 패키지의 어떤 "인스턴스"를 실제로 다른 패키지에 매개변수로 전달하는지가 중요합니다. 이 인스턴스는 차례로 생성적이어야 합니다. 예를 들어 Ada 패키지는 생성적입니다.

생성 패키지 접근 방식의 문제점은 매개변수를 사용하여 패키지를 인스턴스화하는 많은 상용구를 생성한다는 것입니다. 이것이 어떻게 생겼는지 보려면 Ada 제네릭을 볼 수 있습니다.

유형 클래스는 함수에서만 사용되는 유형을 기반으로 유형 클래스를 암시적으로 선택하여 이 상용구를 방지합니다. 또한 유형 클래스를 다중 디스패치로 제한된 오버로딩으로 볼 수 있습니다. 여기서 오버로드 해결은 컴파일 시간에 거의 항상 정적으로 발생합니다. 단, 다형성 재귀 및 존재 유형(본질적으로 캐스팅할 수 없는 변형이므로 변형이 확인하는 인터페이스).

적용 펑터는 값 또는 유형 별칭과 같습니다. 생성 펑터를 구성해야 하며 각 인스턴스가 다릅니다. 이에 대해 생각하는 또 다른 방법은 패키지가 적용 가능하려면 순수해야 한다는 것입니다(즉, 패키지 수준에서 변경 가능한 변수가 아님). 패키지 수준에 상태가 있는 경우 해당 상태를 초기화해야 하므로 생성적이어야 하며 생성적 패키지의 어떤 "인스턴스"를 실제로 다른 패키지에 매개변수로 전달하는지가 중요합니다. 이 인스턴스는 차례로 생성적이어야 합니다. 예를 들어 Ada 패키지는 생성적입니다.

정확한 용어를 알려주셔서 감사합니다. 이러한 아이디어를 문서에 통합하는 방법을 생각해야 합니다.

또한 "생성된 패키지에 대한 자동 유형 별칭"을 가질 수 없는 이유를 알 수 없습니다. 어떤 의미에서는 "적용 펑터"와 "생성 펑터" 접근 방식 사이에 있습니다. 분명히 패키지에 어떤 형태의 상태가 포함되어 있으면 디버그하고 이해하기가 복잡해질 수 있습니다.

생성 패키지 접근 방식의 문제점은 매개변수를 사용하여 패키지를 인스턴스화하는 많은 상용구를 생성한다는 것입니다. 이것이 어떻게 생겼는지 보려면 Ada 제네릭을 볼 수 있습니다.

내가 아는 한, C++ 템플릿보다 상용구를 덜 생성하지만 유형 클래스보다는 더 많이 생성합니다. 문제를 보여주는 Ada에 대한 좋은 실제 프로그램이 있습니까? _(실제로 누군가가 프로덕션에서 사용하고 있던 코드를 의미합니다.)_

물론, 내 Ada go-board를 살펴보십시오. https://github.com/keean/Go-Board-Ada/blob/master/go.adb

이것은 상당히 느슨한 프로덕션 정의이지만 코드는 최적화되고 C++ 버전과 같은 성능을 발휘하며 오픈 소스이며 알고리즘은 몇 년에 걸쳐 개선되었습니다. C++ 버전도 볼 수 있습니다: https://github.com/keean/Go-Board/blob/master/go.cpp

이것은 Ada 제네릭이 C++ 템플릿보다 깔끔한 솔루션임을 보여줍니다(그러나 어렵지는 않습니다). 반면에 참조 반환에 대한 제한으로 인해 Ada의 데이터 구조에 빠르게 액세스하기가 어렵습니다. .

명령형 언어에 대한 패키지 제네릭 시스템을 살펴보고 싶다면 Ada를 가장 잘 살펴봐야 한다고 생각합니다. 그들이 다중 패러다임으로 가고 모든 OO 항목을 Ada에 추가하기로 결정한 것은 수치스러운 일입니다. Ada는 향상된 Pascal이고 Pascal은 작고 우아한 언어입니다. Pascal과 Ada 제네릭은 여전히 ​​작은 언어였지만 제 생각에는 훨씬 더 나았을 것입니다. Ada의 초점이 OO 접근 방식으로 옮겨갔기 때문에 좋은 문서와 제네릭으로 동일한 작업을 수행하는 방법에 대한 예제를 찾기가 어려워 보입니다.

유형 클래스에 몇 가지 장점이 있다고 생각하지만 Ada 스타일 제네릭으로 살 수 있습니다. Ada를 더 널리 사용하는 데 방해가 되는 몇 가지 문제가 있습니다. 값/객체가 잘못되었다고 생각합니다(이를 올바르게 이해하는 언어는 거의 없다고 생각합니다. 'C'가 유일한 것들 중 하나임), 포인터(접근 변수)로 작업하고 안전 포인터 추상화를 생성하기 어렵고 런타임 다형성이 있는 패키지를 사용하는 방법을 제공하지 않습니다(객체 모델을 제공합니다. 그러나 패키지를 사용하여 런타임 다형성을 갖는 방법을 찾는 대신 완전히 새로운 패러다임을 추가합니다.

런타임 다형성에 대한 해결책은 패키지를 일급으로 만들어 패키지 서명의 인스턴스를 함수 인수로 전달할 수 있도록 하는 것입니다. 여기에는 불행히도 종속 유형이 필요합니다(스칼라에 대한 종속 개체 유형에서 수행한 작업 참조). 원래 유형 시스템).

그래서 패키지 제네릭이 작동할 수 있다고 생각하지만 Ada가 모든 엣지 케이스를 처리하는 데 수십 년이 걸렸습니다. 따라서 프로덕션 제네릭 시스템을 살펴보고 프로덕션에서 정제가 사용되는 것이 무엇인지 확인할 것입니다. 그러나 Ada는 패키지가 일급이 아니며 런타임 다형성에서 사용할 수 없기 때문에 여전히 부족하며 이 문제를 해결해야 합니다.

@keean 은 다음과 같이 썼습니다 .

개인적으로 나는 런타임 리플렉션이 잘못된 기능이라고 생각하지만 그건 나일뿐... 관심 있는 사람이 있으면 이유를 설명할 수 있습니다.

유형 삭제는 실용적인 의미 가 있는 "무료 정리"를 가능하게 합니다. 쓰기 가능(그리고 명령형 코드에 대한 전이 관계로 인해 읽을 수도 있음?) 런타임 리플렉션은 모든 코드에서 참조 투명성을 보장하는 것을 불가능하게 하므로 특정 컴파일러 최적화가 불가능하고 유형 안전 모나드가 불가능합니다. Rust에는 아직 불변 기능조차 없다는 것을 알고 있습니다. OTOH, 리플렉션은 정적으로 입력할 수 없는 경우에는 불가능했던 다른 최적화 를 가능하게 합니다.

나는 또한 upthread를 언급했습니다.

그리고 제네릭이 추가된 Go 상위 집합에서 컴파일러가 변환하면 Go 코드로 출력됩니다. 그러나 포장은 내가 이미 언급한 구성 가능성이 부족하기 때문에 포장과 같은 일부 묘사를 기반으로 하지 않습니다. 좋은 구성 가능한 제네릭 유형 시스템에 대한 지름길은 없다는 것이 요점입니다. 실제로 제네릭이 아닌 구성할 수 없는 일부 해킹을 추가하면 결국 패치워크의 반자동 일반성과 모퉁이 케이스의 불규칙성과 Go 생태계 코드를 만드는 해결 방법의 클러스터 관성을 생성할 것이기 때문에 올바르게 수행하거나 아무 것도 하지 않습니다. 이해할 수 없는.

@keean 은 다음과 같이 썼습니다.

[...] 패키지가 적용 가능하려면 순수해야 합니다(즉, 패키지 수준에서 변경 가능한 변수가 아님)

그리고 불변 변수를 초기화하기 위해 불순한 함수를 사용할 수 없습니다.

@egonelbre 는 다음과 같이 썼습니다.

예, 하나의 매개변수화된 패키지를 다른 패키지에서 사용할 수 있습니다.

내가 분명히 염두에 둔 것은 "일급 매개변수화된 패키지"와 @keean 이 이후에 언급한 상응하는 런타임(동적) 다형성이었습니다.

편집: 하지만 "일급" 모듈에는 두 가지 가능한 의미가 있습니다. Successor ML 및 MixML 에서와 같은 일급 값으로서의 모듈과 1ML에서와 같이 일급 유형이 있는 일급 값과 구별되는 모듈 및 필요한 절충안 모듈 재귀(즉 , 혼합 )에서.

@keean 은 다음과 같이 썼습니다.

런타임 다형성에 대한 해결책은 패키지를 일급으로 만들어 패키지 서명의 인스턴스를 함수 인수로 전달할 수 있도록 하는 것입니다. 여기에는 불행히도 종속 유형이 필요합니다(스칼라에 대한 종속 개체 유형에서 수행한 작업 참조). 원래 유형 시스템).

종속 유형이란 무엇을 의미합니까? (편집: 나는 이제 그가 "값에 의존하지 않는" 타이핑, 즉 " 결과 유형이 [런타임?] 인수 [의 유형]에 의존하는 함수 "를 의미했다고 가정합니다.) 확실히 예를 들어 int 의 값에 의존하지 않습니다 F-ing 모듈 은 시스템 F _ω 에서 ML 모듈을 모델링하는 데 "종속" 유형이 절대적으로 필요하지 않다는 것을 보여주었습니다. @rossberg 가 모든 단형성 요구 사항을 제거하기 위해 타이핑 모델을 재구성했다고 가정하면 내가 지나치게 단순화 했습니까?

생성 패키지 접근 방식의 문제는 많은 상용구를 생성한다는 것입니다 […]
유형 클래스는 함수에서만 사용되는 유형을 기반으로 유형 클래스를 암시적으로 선택하여 이 상용구를 방지합니다.

적용 가능한 ML 펑터가 있는 상용구도 없나요? typeclass 구현 인스턴스의 전역 고유성 기준의 고유한 반모듈성 을 방지하는 데 필요한 제한을 도입 하지 않고 간결함 을 유지하는 typeclass 및 ML functor(모듈)의 알려진 통합은 없습니다 .

Typeclasses 는 각 유형을 한 가지 방식으로만 구현할 수 있으며 그렇지 않으면 제한을 극복하기 위해 newtype 래퍼 상용구가 필요합니다. 다음은 알고리즘을 구현하는 여러 방법의 또 다른 예 입니다. Afaics, @keean 은 data 유형을 래핑하여 값 유형에 대해 일반적으로 다른 관계의 이름을 지정하여 명시적으로 선택된 Relation 로 암시적 선택을 재정의하여 유형 클래스 정렬 예제 에서 이 제한을 해결했지만 의심스럽습니다. 그러한 전술이 모듈화의 모든 변형에 일반적인지 여부. 그러나 더 일반화된 솔루션(고아가 될 수 있는 구현에 대해 기본값이 아닌 것을 사용하여 고아 해결을 위해 제안된 버전 관리에 대한 개선으로 고아 제한 과 결합될 수 있는 전역 고유성의 모듈성 문제를 개선 하는 데 도움이 될 수 있음) 모든 typeclass interface 에 암시적으로 추가 유형 매개변수 , 지정하지 않으면 기본적으로 일반 암시적 일치로 설정되지만 지정되면(또는 지정되지 않은 경우 다른 ² 와 일치하지 않음) 동일한 값을 가진 구현을 선택합니다. 쉼표로 구분된 사용자 정의 값 목록에서 (따라서 이것은 특정 implement 인스턴스의 이름을 지정하는 것보다 더 일반화된 모듈식 일치입니다). 쉼표로 구분된 목록은 구현이 두 개 이상의 자유도에서 구별될 수 있도록 하기 위한 것입니다(예: 두 개의 직교 전문화가 있는 경우). 원하는 기본값이 아닌 특수화는 함수 선언이나 호출 사이트에서 지정할 수 있습니다. 호출 사이트에서, 예: f<non-default>(…) .

그렇다면 유형 클래스가 있는 경우 매개변수화된 모듈이 필요한 이유는 무엇입니까? 예를 들어 패키지 모듈이 여러 파일에 걸쳐 있고 암시적으로 내용을 열 수 있기를 원한다는 점에서 해당 목적을 위해 typeclass를 재사용하는 것은 적합하지 않기 때문에 (← 클릭할 중요한 링크) 대체에 대해서만 Afaics 추가 상용구 없이 모듈을 범위에 넣습니다 . 따라서 아마도 _syntactical-only_ replacement-only(첫 번째 클래스가 아님) 패키지 매개변수화로 진행하는 것이 함수 수준에 대해 나중에 유형 클래스를 추가하는 경우 기능과의 호환성 및 비중첩성을 유지하면서 모듈 수준의 일반성을 해결할 수 있는 합리적인 첫 번째 단계입니다. 일반성. 매크로 가 예를 들어 유형이 지정되었는지 아니면 구문적("전처리기"라고도 함) 대체인지 ​​여부에 문제가 있습니다. 유형이 지정되면 모듈은 유형 클래스의 기능을 복제합니다. 이는 PL의 중복되는 패러다임/개념을 최소화하고 중복의 상호 작용으로 인한 잠재적인 모서리 경우(예 : ML 펑터와 유형 클래스를 모두 제공하려고 시도할 때 의 경우)의 관점에서 모두 바람직하지 않습니다 . ). 내보낸 서명을 수정하지 않는 모듈 내 캡슐화된 구현에 대한 수정으로 인해 모듈 소비자가 호환되지 않을 수 있기 때문에 형식화된 모듈은 더 모듈적입니다(앞서 언급한 유형 클래스 중첩 구현 인스턴스의 모듈화 방지 문제 제외). 이에 대한 @keean의 생각을 읽고 싶습니다.

[...] 다형성 재귀 및 존재 유형에 대한 예외(이는 본질적으로 캐스팅할 수 없는 변형이며 변형이 확인하는 인터페이스만 사용할 수 있음).

다른 독자들을 돕기 위해. "다형성 재귀"는 상위 유형, 예를 들어 컴파일러가 콜백 함수의 본문을 컴파일 타임에 알 수 없기 때문에 단일화할 수 없는 런타임에 설정된 매개변수화된 콜백을 의미한다고 생각합니다. 존재 유형은 내가 앞에서 언급한 대로 Rust의 특성 객체와 동일합니다. 이는 가상 상속을 서브클래싱하는 class 보다 표현식 문제에서 나중에 바인딩을 사용하여 이기종 컨테이너를 얻는 한 가지 방법이지만 표현식에서 확장에 개방적이지는 않습니다 . 변경할 수 없는 데이터 구조가 있는 공용체 또는 O(log n) 성능 비용이 있는 ³ 을 복사하는 것과 같은 문제가 있습니다.

¹ _{위의 예에서 HKT가 필요하지 않은 이유는 SET 는 elem 유형이 필요하지 않기 때문입니다. set<elem> set 의 일반 유형의 유형 매개변수입니다. set<elem> .}

² _{그러나 기본이 아닌 구현이 두 개 이상 존재하고 기본 구현이 없는 경우 선택이 모호하므로 컴파일러에서 오류를 생성해야 합니다.}

³ _{데이터 구조가 단일 연결 목록과 같은 히스토리를 분리할 만큼 충분히 똑똑한 경우 변경할 수 없는 데이터 구조로 변경하는 경우 반드시 전체 데이터 구조를 복사할 필요는 없습니다.}

func pick(a CollectionOfT, count uint) []T 를 구현하는 것은 제네릭의 좋은 예가 될 것입니다(https://github.com/golang/go/issues/23717에서):

// pick returns a slice (len = n) of pseudorandomly chosen elements 
// in unspecified order from c which is an array, slice, or map.
for i, e := range pick(c, n) {

여기서 인터페이스 접근 방식은{} 복잡합니다.

나는 이 문제에 대해 C++ 템플릿 접근 방식의 주요 문제 중 하나가 컴파일 타임 메타프로그래밍을 위한 메커니즘으로 오버로드 해결에 의존한다는 점을 몇 번 언급한 적이 있습니다.

Herb Sutter도 같은 결론에 도달한 것 같습니다. 이제 C++에서 컴파일 타임 프로그래밍에 대한 흥미로운 제안이 있습니다.

Go reflect 패키지와 Go의 컴파일 시간 기능에 대한 이전 제안과 공통되는 몇 가지 요소가 있습니다.

안녕.
Go에 대한 제약 조건이 있는 제네릭에 대한 제안서를 작성했습니다. 여기에서 읽을 수 있습니다 . 아마도 15292의 문서로 추가될 수 있습니다. 대부분 제약 조건에 관한 것이며 Go의 Taylors 유형 매개변수에 대한 수정으로 읽습니다.
이것은 Go에서 '유형 안전' 제네릭을 수행하는 실행 가능한(믿는) 방법의 예로서 의도되었으며, 이 토론에 무언가를 추가할 수 있기를 바랍니다.
이 매우 긴 스레드(대부분)를 읽었지만 모든 링크를 따라가지 않았기 때문에 다른 사람들도 비슷한 제안을 했을 수 있습니다. 그렇다면 사과드립니다.

브. Chr.

구문 바이크쉐딩:

constraint[T] Array {
    :[#]T
}

될 수있다

type [T] Array constraint {
    _ [...]T
}

Go to me와 더 비슷해 보입니다. :-)

여기에 몇 가지 요소가 있습니다.

한 가지는 : 를 _ 로 바꾸고 # 를 ... 로 바꾸는 것입니다.
원하신다면 하시면 될 것 같아요.

또 다른 것은 constraint[T] Array 를 type[T] Array constraint 로 바꾸는 것입니다.
그것은 제약 조건이 유형이라는 것을 나타내는 것처럼 보입니다. 이는 제가 옳지 않다고 생각합니다. 공식적으로 제약 조건은 모든 유형 집합에 대한 _predicate_입니다. 유형 집합에서 { true , false } 집합으로의 매핑.
또는 원하는 경우 제약 조건을 단순히 _유형의_ 집합으로 생각할 수 있습니다.
_a_ 유형이 아닙니다.

브. Chr.

constraint 가 interface 가 아닌 이유는 무엇입니까?

type [T io.Writer] List struct { 
    element T; 
    next *List[T];
}

인터페이스는 다음 제안과 함께 제약 조건으로 조금 더 유용할 것입니다. #23796 또한 제안 자체에 약간의 장점을 줄 것입니다.

또한 sum 유형에 대한 제안이 어떤 형식(#19412)으로 수락되면 해당 유형을 제한하는 데 사용해야 합니다.

나는 constraint 키워드라고 생각하지만 큰 제약 조건을 반복하지 않고 방심으로 인한 오류를 방지하기 위해 이와 같은 키워드를 추가해야합니다.

마지막으로, bikeshedding 부분의 경우 과밀을 피하기 위해 정의 끝에 제약 조건을 나열해야 한다고 생각합니다.

// similar to the map[T]... syntax
// also no constraint
type List[T] struct {
    element T
    next *List[T]
}

// with constraint
type List[T] struct {
    element T
    next *List[T]
} where T is io.Writer | encoding.BinaryMarshaler

type BigConstraint constraint {
     io.Writer
     SomeFunc() int
     AnotherFunc()
     AField int64
     StringField string
}


// with predefined constraint
type List[T, U] struct {
    element T
    val U
    next *List[T, U]
} where T is BigConstraint | encoding.BinaryMarshaler,
    U is io.Reader

@urandom : 인터페이스를 명시적으로 구현하지 않고 암시적으로 구현하는 것이 가장 큰 장점이라고 생각합니다. 이 댓글 의 @surlykke 제안 은 다른 Go 구문에 훨씬 더 가깝다고 생각합니다.

@surlykke 제안서에 이 중 하나라도 답이 있으면 사과드립니다.

제네릭의 사용은 내장 스타일 기능을 허용하는 것입니다. 이것을 사용하여 응용 프로그램 수준의 len을 어떻게 구현합니까? 메모리 레이아웃은 허용되는 각 입력마다 다르므로 인터페이스보다 이것이 더 나은 점은 무엇입니까?

앞서 설명한 "선택"에는 맵으로의 인덱싱과 슬라이스로의 인덱싱이 다른 유사한 문제가 있습니다. 맵의 경우 먼저 슬라이스로의 변환이 있는 경우 동일한 선택 코드를 사용할 수 있지만 어떻게 수행됩니까?

컬렉션은 또 다른 용도입니다.

// An unordered collection of comparable items.
type [T Comparable] Set []T

func (a Set) Diff(from Set) Set {
    // the implementation is the same as one with
    //     type Comparable interface { Equal(Comparable) bool }
    //     type Set []Comparable
}

// compile error
d := Set[int]{1, 2}.Diff(Set[string]{“abc”, “def”})

// Go 1, easier to read but runtime error
d := Set{1, 2}.Diff(Set{“abc”, “def”})

컬렉션 유형의 경우 가독성 트레이드오프가 있기 때문에 이것이 Go 1 제네릭보다 큰 승리라고 확신하지 못합니다.

유형 매개변수에는 어떤 형태의 제약 조건이 있어야 한다는 데 동의합니다. 그렇지 않으면 우리는 C++ 템플릿의 실수를 반복할 것입니다. 문제는 제약 조건이 얼마나 표현력이 있어야 하느냐는 것입니다.

한쪽 끝에서는 인터페이스만 사용할 수 있습니다. 그러나 지적했듯이 많은 유용한 패턴은 그런 식으로 캡처할 수 없습니다.

그런 다음 유용한 제약 조건 세트를 개척하고 이를 표현하기 위한 새로운 구문을 제공하려는 귀하의 아이디어 및 유사한 아이디어가 있습니다. 구문을 더 추가하는 문제를 제외하고 어디에서 중지해야 하는지 명확하지 않습니다. 지적하신 바와 같이, 귀하의 제안은 많은 패턴을 포착하지만 전부는 아닙니다.

다른 극단에는 내가 이 문서 에서 제안하는 아이디어가 있습니다. Go 코드 자체를 제약 언어로 사용합니다. 이러한 방식으로 거의 모든 제약 조건을 캡처할 수 있으며 새로운 구문이 필요하지 않습니다.

@jba
좀 장황합니다. Go에 람다 구문이 있다면 좀 더 입맛에 맞을 것입니다. 반면에 해결하려는 가장 큰 문제는 유형이 일종의 연산자를 지원하는지 여부를 확인하는 것입니다. Go에 다양한 연산자에 대해 미리 정의된 인터페이스가 있다면 더 쉬울 수 있습니다.

func equal[T](x, y T) bool
    where T is runtime.Equitable {
    return x == y
}

func copyable[T](x, y []T) int {
    return copy(x, y)
}

또는 이러한 라인을 따라 뭔가.

문제가 내장 기능 확장과 관련된 것이라면 문제는 어댑터 유형을 생성하는 언어 방식에 있을 수 있습니다. 예를 들어, https://github.com/golang/go/issues/16721 및 sort.Slice 뒤에 있는 전체 이유는 sort.Interface와 관련이 있지 않습니까?
https://github.com/golang/go/issues/21670#issuecomment -325739411을 보면 @Sajmani 의 인터페이스 리터럴이 있다는 아이디어는 유형 매개변수가 빌트인과 쉽게 작동하는 데 필요한 요소일 수 있습니다.
Iterator의 다음 정의를 보십시오.

type [T] Iterator interface {
    Next() (elem T, done bool)
}

print 가 단순히 목록을 반복하고 그 내용을 인쇄하는 함수인 경우 다음 예제에서는 인터페이스 리터럴을 사용하여 print 에 대한 만족스러운 인터페이스를 구성합니다.

func SliceIterator(slice []T) Iterator {
    i := 0
    return Iterator{
        Next: func() (elem int, done bool) {
            v := slice[i]
            if i+1 == len(slice) {
                return v, true
            }
            i++
            return v, false
        },
    }
}

func main() {
    arr := []int{1,2,3,4,5}
    // SliceIterator works for an arbitrary slice
    print(SliceIterator(arr))
}

인터페이스를 만족시키는 것이 유일한 책임인 유형을 전역적으로 선언하면 이미 이 작업을 수행할 수 있습니다. 그러나 함수에서 메소드로의 이러한 변환은 인터페이스(따라서 "제약조건")를 보다 쉽게 ​​충족시킵니다. 간단한 어댑터(예: 정렬의 "widgetsByName")로 최상위 선언을 오염시키지 않습니다.
이 LinkedList 예제에서 볼 수 있듯이 사용자 정의 유형은 분명히 이 기능도 활용할 수 있습니다.

type ListNode struct {
    v string
    next *ListNode
}
func (l *ListNode) Iterator() Iterator {
    ptr := l
    return Iterator{
        Next: func() (elem int, done bool) {
            v := ptr.v
            if ptr.next == nil {
                return v, true
            }
            ptr = ptr.next
            return v, false
        },
    }
}

@geovanisouza92 : 내가 설명한 제약 조건은 인터페이스(필드, 연산자)보다 표현력이 뛰어납니다. 제약을 도입하는 대신 인터페이스를 확장하는 것을 간략하게 고려했지만, Go의 기존 요소에 너무 거슬리는 변경이 될 것이라고 생각합니다.

@pciet '응용 프로그램 수준'이 무엇을 의미하는지 잘 모르겠습니다. Go에는 배열, 배열에 대한 포인터, 슬라이스, 문자열 및 채널에 적용할 수 있는 내장 len 함수가 있으므로 내 제안에서 유형 매개변수가 기본 유형으로 이들 중 하나를 갖도록 제한되는 경우 , len 가 적용될 수 있습니다.

@pciet Comparable 제약/인터페이스를 사용한 예에 대해. 다음을 정의하는 경우(인터페이스 변형):

type Comparable interface { Equal(Comparable) bool }
type Set []Comparable

그런 다음 Comparable 를 구현하는 모든 것을 Set 에 넣을 수 있습니다. 다음과 비교하십시오.

constraint [T] Comparable { Equal(t T) bool }
type [T Comparable[T]] Set []T
...
type FooSet Set[Foo] // Where Foo satisfies constraint Comparable

여기서 Foo 유형의 값만 FooSet 에 넣을 수 있습니다. 그것은 더 강력한 유형 안전성입니다.

@urandom 다시 말하지만, 저는 다음을 좋아하지 않습니다.

type MyConstraint constraint {....}

나는 상수가 유형이라고 믿지 않기 때문입니다. 또한 다음을 절대 허용하지 않습니다.

var myVar MyConstraint

그것은 나에게 의미가 없습니다. 제약 조건이 유형이 아니라는 또 다른 표시입니다.

@urandom Bikeshedding에서: 제약 조건은 유형 매개변수 바로 옆에 선언되어야 한다고 생각합니다. 다음과 같이 정의된 일반 함수를 고려하십시오.

func MyFunc(i) {
     if (i>0) fmt.Println("It's positive")
} with i being an integer

왼쪽에서 오른쪽으로 읽을 수 없습니다. 대신 먼저 func MyFunc(i) 를 읽고 이것이 함수 정의인지 확인합니다. 그런 다음 i 가 무엇인지 파악하기 위해 끝까지 이동한 다음 함수 본문으로 돌아가야 합니다. 이상적이지 않습니다. 그리고 일반적인 정의가 어떻게 달라야 하는지 모르겠습니다.
그러나 분명히 이 논의는 Go에 제약 조건이 있어야 하는지 아니면 제네릭이 있어야 하는지에 대한 논의와 직교합니다.

@surlykke
타입이 아니어도 괜찮습니다. 가장 중요한 것은 여러 유형에서 참조할 수 있도록 이름이 있다는 것입니다.

함수의 경우 Rust 구문을 따르면 다음과 같습니다.

func MyFunc[I](i I) int64
     where I is being an integer {
   return 42
}

따라서 함수 이름이나 매개변수와 같은 것을 숨기지 않으며 제네릭 유형에 대한 제약 조건이 무엇인지 확인하기 위해 함수 본문의 끝으로 이동할 필요가 없습니다.

후세를 위해 @surlykke , 제안을 추가할 수 있는 위치를 찾을 수 있습니까?
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

모든 제안을 "컴파일"할 수 있는 좋은 장소입니다.

제가 여러분 모두에게 제기하는 또 다른 질문은 제네릭 유형의 다양한 인스턴스화를 전문화하는 방법입니다. type-params 제안에서 이를 수행하는 방법은 각 인스턴스화된 유형에 대해 동일한 템플릿 함수를 생성하여 유형 매개변수를 유형 이름으로 바꾸는 것입니다. 다른 유형에 대해 별도의 기능을 가지려면 유형 매개변수에서 유형 전환을 수행하십시오.

컴파일러가 유형 매개변수에서 유형 전환을 볼 때 각 어설션에 대해 별도의 구현을 생성할 수 있다고 가정하는 것이 안전합니까? 아니면 주장된 구조체의 중첩된 유형 매개변수가 코드 생성에 대한 매개변수 측면을 생성할 수 있기 때문에 최적화와 너무 관련되어 있습니까?

컴파일 시간 함수 제안에서 이러한 선언이 컴파일 시간에 생성된다는 것을 알고 있기 때문에 유형 전환은 런타임 비용을 발생시키지 않습니다.

실제 시나리오: math/bits 패키지의 경우를 고려하면 각 uintXX $에 대해 $ OnesCount 를 호출하는 형식 주장을 수행하는 것이 효율적인 비트 조작 라이브러리를 갖는 것보다 낫습니다. 그러나 type-assertion이 다음과 같이 변환된 경우

func OnesCount(x T) int {
    switch x.(type) {
    case uint:
        // separate uint functionality...
    case uint8:
        // separate uint8 functionality...
    case uint16:
        // separate uint16 functionality...
    case uint32:
        // separate uint32 functionality...
    case uint64:
        // separate uint64 functionality...
    }
}

전화

var x uint8 = 255
bits.OnesCount(x)

그런 다음 생성된 다음 함수를 호출합니다(여기서 이름은 중요하지 않음).

func $OnesCount_uint8(x uint8) {
    // separate uint8 functionality...
}

@jba 흥미로운 제안이지만 나에게 그것은 주로 매개변수 함수 자체의 정의가 일반적으로 제약 조건을 정의하기에 충분하다는 사실을 강조합니다.

"함수에 사용된 연산자"를 제약 조건으로 사용하려는 경우 첫 번째에 사용된 연산자의 하위 집합을 포함하는 두 번째 함수를 작성하면 어떤 이점이 있습니까?

@bcmills 그 중 하나는 사양이고 다른 하나는 구현입니다. 정적 입력과 동일한 이점이 있습니다. 오류를 더 일찍 잡을 수 있습니다.

구현이 사양, 즉 C++ 템플릿인 경우 구현을 변경하면 잠재적으로 종속 항목이 손상될 수 있습니다. 이것은 나중에 종속 항목이 다시 컴파일되고 발견자가 오류 메시지를 이해할 컨텍스트가 없을 때까지 발견되지 않을 수 있습니다. 동일한 패키지의 사양으로 로컬에서 파손을 감지할 수 있습니다.

@mandolyte 어디에 추가해야 할지 잘 모르겠습니다. '제약이 있는 제네릭'이라는 '제네릭 접근 방식' 아래의 단락이 아닐까요?
이 문서에는 유형 매개변수를 제한하는 방법이 많이 포함되어 있지 않은 것 같습니다. 따라서 내 제안이 언급될 단락을 추가하면 제한에 대한 다른 접근 방식도 거기에 나열될 수 있습니다.

@surlykke 문서에 대한 일반적인 접근 방식은 옳다고 생각되는 것을 변경하는 것이며 나머지 문서와 함께 이를 수용, 통합 및 구성하려고 노력할 것입니다. 여기 에 섹션을 추가했습니다. 내가 놓친 것을 자유롭게 추가하십시오.

@egonelbre 정말 좋네요. 감사 해요!

@jba
당신의 제안은 마음에 들지만 golang에게는 너무 무거운 것 같아요. 그것은 C++의 많은 템플릿을 생각나게 합니다. 내가 생각하는 주요 문제는 그것으로 정말 복잡한 코드를 작성할 수 있다는 것입니다.
제한된 유형 집합이 겹치기 때문에 두 개의 일반 인터페이스 인스턴스가 겹치는지 결정하는 것은 컴파일 시간을 느리게 만드는 어려운 작업입니다. 코드 생성도 마찬가지입니다.

제안된 제약 조건이 이동에 더 가볍다고 생각합니다. 내가 들은 바에 따르면 유형 클래스라고도 하는 제약 조건은 언어의 유형 시스템에 직각으로 구현될 수 있다는 것입니다.

나는 우리가 함수 본문의 암시적 제약을 사용해서는 안 된다는 데 강력히 동의해야 합니다. 이들은 C++ 템플릿의 가장 심각한 오작동 중 하나로 널리 간주됩니다.

• 제약 조건은 쉽게 볼 수 없습니다. godoc은 이론적으로 모든 제약 조건을 문서에 열거할 수 있지만 암시적으로를 제외하고는 소스 코드에서 볼 수 없습니다.
• 이 때문에 예상치 못한 방식으로 함수를 사용하려고 할 때만 표시되는 추가 제약 조건을 실수로 포함할 수 있습니다. 제약 조건의 명시적 지정을 요구함으로써 프로그래머는 그들이 도입하는 제약 조건을 정확히 알아야 합니다.
• 어떤 종류의 제약 조건이 훨씬 더 임시로 허용되는지에 대한 결정을 내립니다. 예를 들어 다음 함수를 정의할 수 있습니까? 여기서 T, U 및 V에 대한 실제 제약 조건은 무엇입니까? 프로그래머가 제약 조건을 명시적으로 지정하도록 요구하는 경우 허용하는 제약 조건 종류에 대해 보수적입니다(천천히 그리고 의도적으로 확장할 수 있음). 어쨌든 보수적으로 하려고 한다면 이와 같은 함수에 대해 어떻게 오류 메시지를 줄까요? "오류: 잘못된 제약 조건을 부과하기 때문에 uv()를 T에 할당할 수 없습니다"?

func[T, U, V] Foo(u U, v V) {
  var t T = u.v(V) + 1;
}

• 다른 제네릭 함수에서 제네릭 함수를 호출하면 위의 상황이 더 악화됩니다. 이제 작성하거나 읽고 있는 함수의 제약 조건을 이해하기 위해 모든 호출 수신자의 제약 조건을 살펴봐야 하기 때문입니다.
• 디버깅은 매우 어려울 수 있습니다. 오류 메시지는 제약 조건의 소스를 찾기에 충분한 정보를 제공하지 않거나 함수의 내부 세부 정보를 누출해야 하기 때문입니다. 예를 들어 F 에 T 유형에 대한 요구 사항이 있고 F 작성자가 해당 요구 사항이 어디에서 왔는지 알아 내려고하면 컴파일러는 제약 조건을 발생시키는 명령문이 정확히 무엇인지 알려주십시오(특히 일반 호출 수신자에서 온 경우). 그러나 F 의 사용자는 해당 정보를 원하지 않으며 실제로 오류 메시지에 포함되어 있으면 사용자의 오류 메시지에서 F 의 구현 세부 정보가 누출됩니다. 끔찍한 사용자 경험입니다.

@alerca

예를 들어 다음 함수를 정의할 수 있습니까?

func[T, U, V] Foo(u U, v V) {
  var t T = u.v(V) + 1;
}

아니요. $ V 는 유형이고 t 변수는 사용되지 않기 때문에 $ u.v(V) 는 구문 오류입니다.

그러나 이 함수를 정의할 수 있습니다. 이 함수는 의도한 것일 수 있습니다.

func[T, U, V] Foo(u U, v V) {
    var _ T = u.v(v) + 1;
}

여기서 T, U 및 V에 대한 실제 제약 조건은 무엇입니까?

• V 유형은 제한되지 않습니다.
• U 유형에는 u.v V 에서 할당할 수 있는 단일 매개변수 또는 일부 유형의 varargs를 허용하는 v 메소드가 있어야 합니다. 유형 V .
  
  
  
  • U.v 는 함수 유형의 필드일 수 있지만 이는 틀림없이 메소드를 의미해야 합니다. #23796을 참조하십시오.
  
  
• U.v 반환된 유형은 1 상수가 추가되기 때문에 숫자여야 합니다.
• U.v T 에 할당할 수 있어야 합니다. u.v(…) + 1 가 T 유형의 변수에 할당되기 때문입니다.
• U.v 의 반환 유형은 숫자이고 T 에 할당할 수 있으므로 T 유형은 숫자여야 합니다.

(제외: U 및 V 에는 이러한 유형의 인수가 값으로 전달되기 때문에 "복사 가능" 제약 조건이 있어야 하지만 기존의 비제네릭 유형 시스템은 적용하지 않습니다. 그 제약 중 하나입니다. 그것은 별도의 제안에 대한 문제입니다.)

프로그래머가 제약 조건을 명시적으로 지정하도록 요구하는 경우 허용하는 제약 조건 종류에 대해 보수적입니다(천천히 그리고 의도적으로 확장할 수 있음).

네, 맞습니다. 하지만 제약 조건을 생략하면 해당 제약 조건이 암시적이든 아니든 심각한 결함이 됩니다. IMO에서 제약의 더 중요한 역할은 모호성을 해결하는 것입니다. 예를 들어, 위의 제약 조건에서 컴파일러는 u.v 를 단일 인수 또는 가변 메서드로 인스턴스화할 준비가 되어 있어야 합니다.

가장 흥미로운 모호성은 구조체 유형과 복합 유형을 명확하게 해야 하는 리터럴에서 발생합니다.

func[T] Foo() (t T) {
    x := 42;
    t = T{x: "some string"}  // Is x an index, or a field name?
    _ = x
}

어쨌든 보수적으로 하려고 한다면 이와 같은 함수에 대해 어떻게 오류 메시지를 줄까요? "오류: 잘못된 제약 조건을 부과하기 때문에 uv()를 T에 할당할 수 없습니다"?

이 예제에서 충돌하는 제약 조건이 보이지 않기 때문에 무엇을 요구하는지 잘 모르겠습니다. "불법 구속"이란 무엇을 의미합니까?

디버깅은 매우 어려울 수 있습니다. 오류 메시지는 제약 조건의 소스를 찾기에 충분한 정보를 제공하지 않거나 함수의 내부 세부 정보를 누출해야 하기 때문입니다.

모든 관련 제약 조건이 유형 시스템으로 표현될 수 있는 것은 아닙니다(https://github.com/golang/go/issues/22876#issuecomment-347035323 참조). 런타임 패닉으로 인해 일부 제약 조건이 적용됩니다. 일부는 경합 감지기에 의해 시행됩니다. 가장 위험한 제약 조건은 문서화될 뿐 전혀 감지되지 않습니다.

이러한 모든 "내부 세부 정보 누출"은 어느 정도입니다. (https://xkcd.com/1172/도 참조하십시오.)

예를 들어, […] F의 작성자가 해당 요구 사항이 어디에서 왔는지 알아내려고 하면 컴파일러가 제약 조건을 발생시키는 문장이 정확히 무엇인지(특히 일반 호출 수신자에서 온 경우) 컴파일러가 경고하기를 원합니다. 그러나 F의 사용자는 그 정보를 원하지 않습니다[.]

아마도? 이것이 API 작성자가 Haskell 및 ML과 같은 유형 유추 언어에서 유형 주석을 사용하는 방법이지만 일반적으로 심층 매개변수("고차") 유형의 토끼 구멍으로 이어집니다.

예를 들어 다음과 같은 기능이 있다고 가정합니다.

func [F, Arg, Result] InvokeAsync(f F, x Arg) (<-chan Result) {
    c := make(chan result, 1)
    go func() { c <- f(x) }()
    return c
}

Arg 유형에 대한 명시적 제약을 어떻게 표현합니까? F 의 특정 인스턴스화에 의존합니다. 이러한 종류의 종속성은 제약에 대한 최근 제안의 많은 부분에서 누락된 것 같습니다.

아니오. uv(V)는 V가 유형이고 변수 t가 사용되지 않기 때문에 구문 오류입니다.

그러나 이 함수를 정의할 수 있습니다. 이 함수는 의도한 것일 수 있습니다.

네, 그런 의도였습니다. 죄송합니다.

T 유형은 숫자여야 합니다. U.v 의 반환 유형은 숫자이고 T 에 할당할 수 있기 때문입니다.

우리는 정말로 이것을 제약이라고 생각해야 합니까? 다른 제약 조건에서 추론할 수 있지만 이것을 별개의 제약 조건이라고 하는 것이 다소 유용합니까? 암시적 제약 조건은 명시적 제약 조건이 하지 않는 방식으로 이 질문을 합니다.

네, 맞습니다. 하지만 제약 조건을 생략하면 해당 제약 조건이 암시적이든 아니든 심각한 결함이 됩니다. IMO에서 제약의 더 중요한 역할은 모호성을 해결하는 것입니다. 예를 들어, 위의 제약 조건에서 컴파일러는 uv를 단일 인수 또는 가변 메서드로 인스턴스화할 준비가 되어 있어야 합니다.

나는 언어에서와 같이 "우리가 허용하는 제약 조건"을 의미했습니다. 명시적 제약 조건을 사용하면 제약 조건이 "무엇이든 컴파일하게 만드는 것"이라고 말하는 것보다 사용자가 작성할 수 있도록 허용할 제약 조건의 종류를 결정하는 것이 훨씬 쉽습니다. 예를 들어, 위의 예제 Foo 는 실제로 T , U 또는 V 와 별도의 암시적 추가 유형을 포함합니다. 왜냐하면 우리는 반환 유형을 고려해야 하기 때문입니다. u.v . 이 유형은 f 의 선언에서 어떤 식으로든 명시적으로 참조되지 않습니다. 가지고 있어야 하는 속성은 완전히 암시적입니다. 마찬가지로 더 높은 순위( forall ) 유형을 허용할 의향이 있습니까? 내 머리 꼭대기에서 예제를 생각해 낼 수는 없지만 더 높은 순위의 유형 경계를 암시적으로 작성할 수 없다고 스스로 확신할 수도 없습니다.

또 다른 예는 함수가 오버로드된 구문을 활용하도록 허용해야 하는지 여부입니다. 암시적으로 제약된 함수가 일반 유형 T 의 일부 t 에 대해 for i := range t 하면 T 가 배열, 슬라이스, 채널, 또는 지도. 그러나 의미 체계는 상당히 다릅니다. 특히 T 가 채널 유형인 경우에는 더욱 그렇습니다. 예를 들어 t == nil ( T 가 배열인 한 발생할 수 있음)인 경우 반복은 nil 슬라이스 또는 맵에 요소가 없기 때문에 아무 작업도 수행하지 않거나 영원히 차단됩니다. 그것이 nil 채널에서 받는 것이기 때문입니다. 이것은 일어나기를 기다리고 있는 큰 발총입니다. 비슷하게 m[i] = ... ; m 가 맵이 되도록 하려면 코드가 범위를 벗어난 할당에서 패닉을 일으킬 수 있으므로 실제로 슬라이스가 되지 않도록 보호해야 합니다.

사실, 이것은 암시적 제약 조건에 대한 또 다른 주장에 적합하다고 생각합니다. API 작성자는 제약 조건을 추가하기 위해 인위적인 명령문을 작성할 수 있습니다. 예를 들어 for _, _ := range t { break } 는 맵, 슬라이스 및 배열을 계속 허용하면서 채널을 방지합니다. x = append(x) 는 x 가 슬라이스 유형을 갖도록 합니다. var _ = make(T, 0) 는 슬라이스, 맵 및 채널을 허용하지만 배열은 허용하지 않습니다. 다른 사람이 올바른 코드를 작성하지 않은 유형으로 함수를 호출할 수 없도록 제약 조건을 암시적으로 추가하는 방법에 대한 레시피 북이 있습니다. 키 유형도 알지 못하면 지도 유형에 대해서만 컴파일하는 코드를 작성할 방법이 생각나지 않습니다. 그리고 저는 이것이 전혀 가설이라고 생각하지 않습니다. 맵과 슬라이스는 대부분의 애플리케이션에서 상당히 다르게 작동합니다.

이 예제에서 충돌하는 제약 조건이 보이지 않기 때문에 무엇을 요구하는지 잘 모르겠습니다. "불법 구속"이란 무엇을 의미합니까?

언어가 더 높은 순위의 제약 조건을 허용하지 않기로 결정한 경우와 같이 언어에서 허용하지 않는 제약 조건을 의미합니다.

모든 관련 제약 조건을 유형 시스템으로 표현할 수 있는 것은 아닙니다(#22876(주석) 참조). 런타임 패닉으로 인해 일부 제약 조건이 적용됩니다. 일부는 경합 감지기에 의해 시행됩니다. 가장 위험한 제약 조건은 문서화될 뿐 전혀 감지되지 않습니다.

이러한 모든 "내부 세부 정보 누출"은 어느 정도입니다. (https://xkcd.com/1172/도 참조하십시오.)

#22876이 어떻게 여기에 나오는지 잘 모르겠습니다. 다른 종류의 제약 조건을 표현하기 위해 유형 시스템을 사용하려고 합니다. 임의의 복잡성을 가진 유형 시스템을 사용하더라도 값이나 프로그램에 대한 일부 제약 조건을 표현할 수 없다는 것은 항상 사실입니다. 그러나 여기서는 유형 에 대한 제약 조건에 대해서만 이야기하고 있습니다. 컴파일러는 "이 제네릭을 T 유형으로 인스턴스화할 수 있습니까?"라는 질문에 답할 수 있어야 합니다. 이는 암시적이든 명시적이든 제약 조건을 이해해야 함을 의미합니다. (C++ 및 Rust와 같은 일부 언어는 임의의 계산에 의존할 수 있으므로 일반적으로 이 질문을 결정할 수 없으며 따라서 Halting Problem으로 이어집니다. 그러나 여전히 충족되어야 하는 제약 조건을 표현합니다.)

내 말은 "다음 예에서는 어떤 오류 메시지가 표시되어야 합니까?"와 비슷합니다.

func [U] DirectlyConstrained(U t) {
    t.DoSomething();
}
func [T] IndirectlyConstrained(T t) {
    DirectlyConstrainted(t);
}
func Illegal() {
    IndirectlyConstrained(4);
}

Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() 라고 말할 수 있습니다. 이 오류 메시지는 IndirectlyConstrained 사용자에게 유용합니다. 왜냐하면 누락되었다는 제약 조건을 명확하게 설정하기 때문입니다. 그러나 IndirectlyConstrained 에 해당 제약 조건이 있는 이유를 디버그하려는 사람에게 정보를 제공하지 않습니다. 이는 큰 함수인 경우 큰 사용성 문제입니다. Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N 를 추가할 수 있지만 이제 IndirectlyConstrained 의 구현에 대한 세부 정보가 누출됩니다. 게다가 IndirectlyConstrained 에 제약 조건이 있는 이유를 설명하지 않았으므로 다른 Note: this constraint exists on U because DirectlyConstrained calls t.DoSomething() on line M 를 추가해야 합니까? 암시적 제약 조건이 호출 스택의 4단계 아래에 있는 일부 호출 수신자로부터 온다면 어떻게 될까요?

또한 명시적으로 매개변수로 나열되지 않은 유형에 대해 이 오류 메시지의 형식을 지정하는 방법은 무엇입니까? 예를 들어 위의 예에서 IndirectlyConstrained 가 DirectlyConstrained(t.U()) $ 를 호출하는 경우. 유형을 어떻게 참조합니까? 이 경우 the type of t.U() 라고 말할 수 있지만 값이 반드시 단일 표현식의 결과일 필요는 없습니다. 여러 문장을 통해 구축될 수 있습니다. 그런 다음 오류 메시지에 넣을 올바른 유형으로 표현식을 합성해야 하고, 코드에는 나타나지 않는 것입니다. 제약 조건을 위반한 불쌍한 호출자.

Arg 유형에 대한 명시적 제약을 어떻게 표현합니까? 그것들은 F의 특정 인스턴스화에 의존합니다. 이러한 종류의 의존성은 제약에 대한 최근 제안에서 누락된 것 같습니다.

F 를 삭제하고 f func (Arg) Result 가 되도록 합니다. 예, 가변 함수를 무시하지만 Go의 나머지 부분도 무시합니다. varargs funcs 를 호환 가능한 서명에 할당할 수 있도록 하는 제안은 별도로 수행할 수 있습니다.

진정으로 고차 유형 경계가 필요한 경우 제네릭 v1에 포함하는 것이 의미가 있을 수도 있고 그렇지 않을 수도 있습니다. 명시적 제약은 우리가 고차 유형을 지원할지 여부와 방법을 명시적으로 결정하도록 강요합니다. 지금까지 고려의 부족은 Go가 현재 내장 유형의 속성을 참조할 방법이 없다는 사실의 증상이라고 생각합니다. 제네릭 시스템이 모든 숫자 유형 또는 모든 정수 유형에 대해 제네릭 함수를 허용하는 방법에 대한 일반적인 공개 질문이며 대부분의 제안은 이에 대해 많이 집중하지 않았습니다.

다음 프로젝트에서 제 제네릭 구현을 평가해 주세요.
http://go-li.github.io/

Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() 라고 말할 수 있습니다. 이 오류 메시지 [...]는 IndirectlyConstrained 에 해당 제약 조건이 있는 이유를 디버그하려는 사람에게 정보를 제공하지 않습니다. 이는 큰 함수인 경우 큰 사용성 문제입니다.

나는 당신이 여기서 만들고 있는 큰 가정을 지적하고 싶습니다. go build 의 오류 메시지는 프로그래머가 문제를 진단하는 데 사용할 수 있는 _유일한_ 도구입니다.

비유를 사용하려면: 런타임에 error 를 만나면 디버깅을 위한 몇 가지 옵션이 있습니다. 오류 자체에는 오류를 설명하는 데 적절하거나 적절하지 않을 수 있는 간단한 메시지만 포함되어 있습니다. 그러나 그것이 당신이 사용할 수 있는 유일한 정보는 아닙니다. 예를 들어, 프로그램이 내보낸 모든 로그 명령문도 가지고 있으며, 정말 지독한 버그라면 대화형 디버거에 로드할 수 있습니다.

즉, 런타임 디버깅은 대화식 프로세스입니다. 그렇다면 컴파일 타임 오류에 대해 비대화형 디버깅을 가정해야 하는 이유⸮ 한 가지 대안으로 유형 제약 조건에 대해 guru 도구를 가르칠 수 있습니다. 그러면 컴파일러의 출력은 다음과 같습니다.

somefile.go:123: Argument `4` to DirectlyConstrained has type `int`,
    but DirectlyConstrained requires a type `T` with method `DoSomething()`.
    (For more detail, run `guru contraints path/to/somefile.go:#1033`.)

이는 일반 패키지 사용자에게 즉각적인 호출 사이트를 디버그하는 데 필요한 정보를 제공하지만 _또한_ 패키지 유지 관리자(및 중요하게는 편집 환경)가 추가 조사를 위해 이동 경로를 제공합니다.

Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N 를 추가할 수 있지만 이제 IndirectlyConstrained 의 구현에 대한 세부 정보가 누출됩니다.

네, 어쨌든 정보가 누출된다는 의미입니다. 이미 guru describe 를 사용하여 구현 내부를 엿볼 수 있습니다. 디버거를 사용하여 실행 중인 프로그램 내부를 엿볼 수 있으며 스택을 조회할 수 있을 뿐만 아니라 임의의 하위 수준 기능으로 단계를 내려갈 수도 있습니다.

관련성이 없는 정보는 기본적으로 숨겨야 한다는 데 절대적으로 동의하지만, 그렇다고 해서 절대적으로 숨겨야 한다는 의미는 아닙니다.

암시적으로 제한된 함수가 i := range t 제네릭 유형 T 의 일부 t 에 대해 수행하는 경우 T 가 배열, 슬라이스, 채널인 경우 구문이 작동합니다. , 또는 지도. 그러나 의미론은 특히 T 가 채널 유형인 경우 상당히 다릅니다.

나는 그것이 유형 제약 조건에 대한 더 강력한 주장이라고 생각하지만 일부 사람들이 제안하는 것만큼 장황한 명시적 제약 조건이 필요하지는 않습니다. 호출 사이트를 명확하게 하려면 reflect.Kind 에 가까운 것으로 유형 매개변수를 제한하는 것으로 충분해 보입니다. 코드에서 이미 명확한 작업을 설명할 필요가 없습니다. 대신 " T 는 슬라이스 유형입니다"와 같은 것만 말하면 됩니다. 그러면 훨씬 더 간단한 제약 조건 세트가 생성됩니다.

• 인덱스 작업의 대상이 되는 유형은 선형 또는 연관으로 레이블이 지정되어야 합니다.
• range 작업의 대상이 되는 유형은 nil-empty 또는 nil-blocking으로 레이블이 지정되어야 합니다.
• 리터럴이 있는 유형은 필드 또는 인덱스가 있는 것으로 레이블이 지정되어야 합니다.
• (아마도) 숫자 연산이 있는 유형은 고정 또는 부동 소수점으로 레이블이 지정되어야 합니다.

이는 다음과 같이 훨씬 더 좁은 제약 조건 언어로 이어집니다.

TypeConstraint = "sliceable" | "map" | "chan" | "struct" | "integer" | "float" | "type"

다음과 같은 예가 있습니다.

func[T:integer, U, V] Foo(u U, v V) {
    var _ T = u.v(v) + 1;
}

func [S:sliceable, T] append(s S, x ...T) S {
    dst := s
    if cap(s) - len(s) < len(x) {
        dst = make(S, len(s), nextSizeClass(cap(s)))
        copy(dst, s)
    }
    copy(dst[len(s):cap(s)], x)
    return dst[:len(s)+len(x)]
}

유형 별칭을 도입하여 사용자 지정 제네릭으로 큰 단계를 이동했다고 생각합니다.
유형 별칭은 수퍼 유형(유형 유형)을 가능하게 합니다.
유형을 사용하는 값과 같이 취급할 수 있습니다.

설명을 더 쉽게 하기 위해 새로운 코드 요소 genre 를 추가할 수 있습니다.
장르와 유형의 관계는 유형과 가치의 관계와 같다.
즉, 장르는 유형의 유형을 의미합니다.

구조체 및 인터페이스 및 함수 종류를 제외한 각 유형은 미리 선언된 장르에 해당합니다.

• 부울
• 끈
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint, Uintptr
• 플로트32, 플로트64
• Complex64, Complex128
• 배열, 슬라이스, 맵, 채널, 포인터, UnsafePointer

Comaprable, Numeric, Interger, Float, Complex, Container 등과 같은 미리 선언된 다른 장르가 있습니다. Type 를 사용할 수 있습니다. 또는 * 는 모든 유형의 장르를 나타냅니다.

모든 기본 제공 장르의 이름은 모두 대문자로 시작합니다.

각 구조체, 인터페이스 및 함수 유형은 장르에 해당합니다.

사용자 지정 장르를 선언할 수도 있습니다.

genre Addable = Numeric | String
genre Orderable = Interger | Float | String
genre Validator = func(int) bool // each parameter and result type must be a specified type.
genre HaveFieldsAndMethods = {
    width  int // we must use a specific type to define the fields.
    height int // we can't use a genre to define the fields.
    Load(v []byte) error // each parameter and result type must be a specified type.
    DoSomthing()
}
genre GenreFromStruct = aStructType // declare a genre from a struct type
genre GenreFromInterface = anInterfaceType // declare a genre from an interface type
genre GenreFromStructInterface = aStructType + anInterfaceType
genre ComparableStruct = HaveFieldsAndMethods & Comprable
genre UncomparableStruct = HaveFieldsAndMethods &^ Comprable

다음 설명을 일관되게 하려면 장르 수식어가 필요합니다.
장르 수정자는 Const 로 표시됩니다. 예를 들어:

• Const Integer 는 장르이며( Integer 와 다름) 해당 인스턴스는 정수여야 하는 상수 값이어야 합니다. 그러나 상수 값은 특수한 유형으로 볼 수 있습니다.
• Const func(int) bool 는 장르( func(int) bool 와 다름)이며 해당 인스턴스는 delcared 함수 값이어야 합니다. 그러나 함수 선언은 특수한 유형으로 볼 수 있습니다.

(수정자 솔루션은 약간 까다롭습니다. 다른 더 나은 디자인 솔루션이 있을 수 있습니다.)

좋아, 계속하자.
다른 개념이 필요합니다. 좋은 이름을 찾기가 쉽지 않다.
그냥 crate 라고 합시다.
일반적으로 크레이트와 장르의 관계는 기능과 유형의 관계와 같습니다.
크레이트는 유형을 매개변수로 취하고 유형을 리턴할 수 있습니다.

크레이트 선언( lib 패키지에 다음 코드가 선언되어 있다고 가정):

crate Example [T Float, S {width, height T}, N Const Integer] [*, *, *] {
    type MyArray [N]T

    func Add(a, b T) T {
        return a+b
    }

    type M struct {
        x T
        y S
    }

    func (m *M) Area() T {
        m.DoSomthing()
        return m.y.width * m.y.height
    }

    func (m *M) Perimeter() T {
        return 2 * Add(m.y.width, m.y.height)
    }

    export M, Add, MyArray
}

위의 상자를 사용합니다.

import "lib"

// We can use AddFunc as a normal delcared function.
// Its genre is "Const func (a, b T) T"
type Rect, AddFunc, Array = lib.Example[float32, struct{x, y float32}, 100]

func demo() {
    var r Rect
    a, p = r.Area(), r.Perimeter()
    _ = AddFunc(a, p)
}

내 아이디어는 위에 표시된 다른 사람들의 많은 아이디어를 흡수합니다.
그들은 지금 매우 성숙하지 않습니다.
나는 그것들이 약간 흥미롭다고 생각해서 여기에 게시합니다.
더 이상 개선하고 싶지 않습니다.
아이디어에 구멍을 뚫어 너무 많은 뇌세포가 죽었습니다.
이 아이디어가 다른 고퍼들에게 영감을 줄 수 있기를 바랍니다.

당신이 "장르"라고 부르는 것을 실제로는 "종류"라고 부르며,
함수형 프로그래밍 커뮤니티. 당신이 상자라고 부르는 것은 제한적입니다
일종의 ML 펑터.

2018년 4월 4일 수요일 오후 12시 41분 dotahor [email protected] 작성:

나는 우리가
유형 별칭.
유형 별칭은 수퍼 유형(유형 유형)을 가능하게 합니다.
유형을 사용하는 값과 같이 취급할 수 있습니다.

설명을 더 쉽게 하기 위해 새로운 코드 요소인 장르를 추가할 수 있습니다.
장르와 유형의 관계는 유형 간의 관계와 같다.
그리고 가치.
즉, 장르는 유형의 유형을 의미합니다.

구조체 및 인터페이스 및 함수 종류를 제외한 각 유형,
미리 선언된 장르에 해당합니다.

• 부울
• 끈
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint,
  Uintptr
  & Float32, Float64
• Complex64, Complex128
• 배열, 슬라이스, 맵, 채널, 포인터, UnsafePointer

Comaprable, Numeric,
Interger, Float, Complex, Container 등. Type 또는 *를 사용할 수 있습니다.
모든 유형의 장르.

모든 기본 제공 장르의 이름은 모두 대문자로 시작합니다.

각 구조체, 인터페이스 및 함수 유형은 장르에 해당합니다.

사용자 지정 장르를 선언할 수도 있습니다.

장르 추가 가능 = 숫자 | 끈
장르 주문 가능 = Interger | 플로트 | 끈
장르 Validator = func(int) bool // 각 매개변수와 결과 유형은 지정된 유형이어야 합니다.
장르 HaveFieldsAndMethods = {
width int // 필드를 정의하려면 특정 유형을 사용해야 합니다.
height int // 장르를 사용하여 필드를 정의할 수 없습니다.
Load(v []byte) error // 각 매개변수와 결과 유형은 지정된 유형이어야 합니다.
두썸씽()
}
장르 GenreFromStruct = aStructType // 구조체 유형에서 장르 선언
장르 GenreFromInterface = anInterfaceType // 인터페이스 유형에서 장르 선언
장르 GenreFromStructInterface = aStructType | 인터페이스 유형

다음 설명을 일관되게 하려면 장르 수식어가 필요합니다.
장르 수정자는 Const로 표시됩니다. 예를 들어:

• Const Integer는 장르이며 해당 인스턴스는 상수 값이어야 합니다.
  정수여야 하는 유형입니다.
  그러나 상수 값은 특수한 유형으로 볼 수 있습니다.
• Const func(int) bool은 장르이며 해당 인스턴스는 선언되어야 합니다.
  함수 값.
  그러나 함수 선언은 특수한 유형으로 볼 수 있습니다.

(수정자 솔루션은 약간 까다롭습니다. 다른 더 나은 디자인이 있을 수 있습니다.
솔루션.)

좋아, 계속하자.
다른 개념이 필요합니다. 좋은 이름을 찾기가 쉽지 않다.
그냥 상자라고 합시다.
일반적으로 상자와 장르의 관계는 다음과 같습니다.
함수와 유형 사이.
크레이트는 유형을 매개변수로 취하고 유형을 리턴할 수 있습니다.

크레이트 선언(다음 코드가 lib에 선언되어 있다고 가정합니다.
패키지):

크레이트 예 [T Float, S {너비, 높이 T}, N Const Integer] [*, *, *] {
유형 MyArray [N]T

func 더하기(a, b T) T {
반환 + b
}

// 크레이트 범위 장르. 상자에서만 사용할 수 있습니다.

// M은 장르 G의 유형입니다.
유형 M 구조체 {
x T
y 에스
}

func (m *M) 면적() T {
m.DoSomthing()
내 너비 * 내 높이를 반환
}

func (m *M) 둘레() T {
return 2 * 추가(mywidth, myheight)
}

내보내기 M, 추가, MyArray
}

위의 상자를 사용합니다.

"lib" 가져오기

// 우리는 AddFunc를 일반적인 delcared 함수로 사용할 수 있습니다.
유형 Rect, AddFunc, Array = lib.Example(float32, struct{x, y float32})

기능 데모() {
var r 사각형
a, p = r.Area(), r.Perimeter()
_ = AddFunc(a, p)
}

내 아이디어는 위에 표시된 다른 사람들의 많은 아이디어를 흡수합니다.
그들은 지금 매우 성숙하지 않습니다.
나는 그것들이 약간 흥미롭다고 생각해서 여기에 게시합니다.
더 이상 개선하고 싶지 않습니다.
아이디어에 구멍을 뚫어 너무 많은 뇌세포가 죽었습니다.

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

종류와 장르 사이에 약간의 차이가 있다고 생각합니다.

그건 그렇고, 크레이트가 하나의 유형만 반환하는 경우 해당 호출을 유형으로 직접 사용할 수 있습니다.

package lib

// export a type
crate List [T *] * {
    type List struct {
        ...
    }

    export List
}

그걸 써:

import "lib"

var l lib.List[int]

현재 시스템의 "유형 연역"과 같은 일부 "장르 연역" 규칙이 있을 것입니다.

@dotaheor , @DemiMarie 가 맞습니다. 귀하의 "장르" 개념은 유형 이론의 "종류"와 정확히 같습니다. (귀하의 제안에는 하위 유형 규칙이 필요하지만 드문 일이 아닙니다.)

제안서의 genre 키워드는 새로운 종류를 기존 종류의 슈퍼 종류로 정의합니다. crate 키워드는 Type 의 하위 종류가 아닌 종류인 "상자 서명"이 있는 개체를 정의합니다.

공식 시스템으로서 귀하의 제안은 다음과 같습니다.

상자 ::= χ | ⋯
유형 ::= τ | χ | int | bool | ⋯ | func(τ) | func(τ) τ | []τ | χ[τ₁, …]

크레이트 시그 ::= [κ₁, …] ⇒ [κₙ, …]
종류 ::= κ | exactly τ | kindOf κ | Map | Chan | ⋯ | Const κ | Type | 크레이트 시그

일부 유형 이론 표기법을 남용하려면:

• “⊢”는 “~을 수반한다”로 읽으십시오.
• " k1 ⊑ k2 "를 " k1 는 k2 의 하위 종류"로 읽습니다.
• ":"를 "종종"으로 읽으십시오.

그런 다음 규칙은 다음과 같습니다.

⊢ τ : exactly τ
⊢ exactly τ ⊑ kindOf exactly τ
⊢ kindOf exactly τ ⊑ Type

τ : κ₁ ∧ κ₁ ⊑ κ₂ ⊢ τ : κ₂

τ₁ : Type ∧ τ₂ : Type ⊢ kindOf exactly map[τ₁]τ₂ ⊑ Map
⊢ Map ⊑ Type

κ₁ ⊑ κ₂ ⊢ Const κ₁ ⊑ Const κ₂

[…]
(등, 모든 내장형에 대해)

유형 정의는 종류를 부여하고 기본 종류는 기본 제공 유형의 종류로 축소됩니다.

type τ₁ τ₂ ∧ τ₂ : κ ⊢ τ₁ : kindOf κ

⊢ kindOf kindOf κ ⊑ kindOf κ
⊢ kindOf Map ⊑ Map
[…]

genre 는 새 하위 유형 관계를 정의합니다.
genre κ = κ₁ | κ₂ ⊢ κ₁ ⊑ κ
genre κ = κ₁ | κ₂ ⊢ κ₂ ⊑ κ

( Numeric 등을 | 로 정의할 수 있습니다.)

genre κ = κ₁ & κ₂ ∧ ( κ₃ ⊑ κ₁ ) ∧ ( κ₃ ⊑ κ₂ ) ⊢ κ₃ ⊑ κ

상자 확장 규칙은 다음과 유사합니다.
type τₙ, … = χ[τ₁, …] ∧ ( χ : [κ₁, …] ⇒ [κₙ, …] ) ∧ ( τ₁ : κ₁ ) ∧ ⋯ ⊢ τₙ : κₙ

물론 이것은 모두 종류에 대한 이야기입니다. 이를 유형 시스템으로 바꾸려면 유형 규칙도 필요합니다. 🙂

그래서 당신이 설명하고 있는 것은 꽤 잘 이해된 형태의 매개변수입니다. 잘 이해하고 있다는 점에서는 좋은데, 바둑이 도입한 고유의 문제를 해결하는 데 도움이 되지 않는다는 점에서 아쉽다.

Go에서 소개하는 정말 흥미롭고 난해한 문제는 주로 동적 유형 검사에 관한 것입니다. 유형 매개변수는 유형 주장 및 리플렉션과 어떻게 상호 작용해야 합니까?

(예를 들어, 매개변수 유형의 메소드로 인터페이스를 정의할 수 있어야 합니까? 그렇다면 런타임에 새로운 매개변수를 사용하여 해당 인터페이스의 값을 유형 주장하면 어떻게 될까요?)

관련 메모에서 코드를 내장 및 사용자 정의 유형보다 제네릭으로 만드는 방법에 대한 논의가 있었습니까? bigint 및 기본 정수를 처리할 수 있는 코드를 만드는 것과 같은가요?

관련 메모에서 코드를 내장 및 사용자 정의 유형보다 제네릭으로 만드는 방법에 대한 논의가 있었습니까? bigint 및 기본 정수를 처리할 수 있는 코드를 만드는 것과 같은가요?

Genus 및 Familia와 같은 유형 클래스 기반 메커니즘은 이를 효율적으로 수행할 수 있습니다. 자세한 내용은 PLDI 2015 문서를 참조하십시오.

@DemiMarie
"장르" == "특성 세트"라고 생각합니다.

[편집하다]
traits 가 더 나은 키워드일 수 있습니다.
우리는 각 종류도 특성 세트를 볼 수 있습니다.

대부분의 특성은 단일 유형에 대해서만 정의됩니다.
그러나 더 복잡한 특성은 두 유형 간의 관계를 정의할 수 있습니다.

[편집 2]
두 개의 특성 세트 A와 B가 있다고 가정하면 다음 작업을 수행할 수 있습니다.

A + B: union set
A - B: difference set
A & B: intersection set

인수 유형의 특성 세트는 해당 매개변수 장르(특성 세트)의 상위 세트여야 합니다.
결과 유형의 특성 집합은 해당 결과 장르(특성 집합)의 하위 집합이어야 합니다.

(임호)

여전히 Go에 제네릭을 추가하려면 Type Aliases를 다시 바인딩하는 것이 좋습니다. 언어에 큰 변화가 필요하지 않습니다. 이러한 방식으로 일반화된 패키지는 여전히 Go 1.x에서 사용할 수 있습니다. 그리고 유형 별칭의 기본 유형을 이미 해당 제약 조건을 충족하는 것으로 설정하여 추가할 수 있기 때문에 제약 조건을 추가할 필요가 없습니다. 리바인딩 유형 별칭의 가장 중요한 측면은 기본 제공 복합 유형(슬라이스, 맵 및 채널)을 변경하고 일반화할 필요가 없다는 것입니다.

@dc0d

유형 별칭이 제네릭을 어떻게 대체해야 합니까?

@sighoya 리바인딩 유형 별칭은 제네릭(유형 별칭뿐 아니라)을 대체할 수 있습니다. 패키지가 다음과 같은 패키지 수준 유형 별칭을 도입한다고 가정해 보겠습니다.

package likedlist

type T = interface{}

type LinkedList struct {
    // ...
}

Type Alias ​​Rebinding(및 컴파일러 기능)이 제공되면 빈 인터페이스 대신 다른 구체적인 유형에 대한 연결 목록을 생성하기 위해 이 패키지를 사용할 수 있습니다.

package main

import (
    "likedlist"
)

type intLL = likedlist.LinkedList(likedlist.T = int)
type stringLL = likedlist.LinkedList(likedlist.T = string)

func main() {}

별칭을 그대로 사용하면 다음 방법이 더 깔끔합니다.

// pkg.go
package pkg

type ListNode struct {
    prev, next *ListNode
    element    ?Element
}

func Add(x, y ?T) ?T {
    return x+y
}



// main.go
package main

import "pkg"

type intList = pkg.ListNode[Element=int]
func stringAdd = pkg.Add[T=string]

func main() {
}

@dc0d 와 정확히 어떻게 구현되나요? 코드는 훌륭하지만 실제로 내부에서 작동하는 방식에 대해서는 아무 것도 알려주지 않습니다. 그리고 제네릭 제안의 역사를 살펴보면 Go의 경우 모양과 느낌뿐만 아니라 매우 중요합니다.

@dotaheor Go 1.x와 호환되지 않습니다.

@creker 저는 이 기술을 사용하여 코드를 생성하고 Type Alias ​​Rebinding의 개념으로 탄생한 도구( goreuse )를 구현했습니다.

여기 에서 찾을 수 있습니다. 도구를 설명하는 15분 분량의 비디오가 있습니다.

@dc0d 따라서 특수 구현을 생성하는 C++ 템플릿처럼 작동합니다. 나는 그것이 Go 팀으로 받아들여질 것이라고 생각하지 않습니다. (솔직히 저와 여기 있는 다른 많은 사람들도) C++ 템플릿과 유사한 것에 반대하는 것 같습니다. 바이너리를 늘리고 컴파일 속도를 늦추며 의미 있는 오류를 생성하지 못할 수도 있습니다. 게다가 Go가 지원하는 바이너리 전용 패키지와 호환되지 않습니다. 이것이 C++가 헤더 파일에 템플릿을 작성하기로 선택한 이유입니다.

@크레커

따라서 사용되는 모든 유형에 대해 특수 구현을 생성하는 C++ 템플릿과 유사하게 작동합니다.

잘 모르겠습니다(C++를 작성한지 약 16년이 되었습니다). 그러나 당신의 설명을 보면 그럴 것 같습니다. 그러나 나는 그들이 동일한지 또는 어떻게 동일한지 확실하지 않습니다.

나는 그것이 Go 팀으로 받아들여질 것이라고 생각하지 않습니다. (솔직히 저와 여기 있는 다른 많은 사람들도) C++ 템플릿과 유사한 것에 반대하는 것 같습니다.

물론 여기 있는 모든 사람들은 우선 순위에 따라 선호하는 데 충분한 이유가 있습니다. 내 목록의 첫 번째는 Go 1.x와의 호환성입니다.

바이너리를 증가시키며,

그것은 수도.

컴파일 속도가 느려지고,

( goreuse 로 경험할 수 있으므로) 의심스럽습니다.

게다가 Go가 지원하는 바이너리 전용 패키지와 호환되지 않습니다.

잘 모르겠다. 제네릭을 구현하는 다른 방법이 이를 지원합니까?

의미 있는 오류를 생성할 수 없습니다.

이것은 약간 번거로울 수 있습니다. 여전히 컴파일 시간에 발생하며 일부 도구를 사용하여 상당 부분 보상할 수 있습니다. 게다가 패키지의 유형 매개변수 역할을 하는 유형 별칭이 인터페이스인 경우 구체적으로 제공된 유형에서 할당 가능한지 간단히 확인할 수 있습니다. int 및 string 및 구조체와 같은 기본 유형에 대한 문제는 여전히 남아 있습니다.

@dc0d

나는 그것에 대해 조금 생각합니다.
인터페이스에서 내부적으로 설정되는 것 외에도 귀하의 예에서 'T'

type T=interface{}

는 변경 가능한 유형 변수로 처리되지만 특정 유형에 대한 별칭, 즉 유형에 대한 const 참조여야 합니다.
원하는 것은 T Type이지만 이것은 제네릭의 도입을 의미합니다.

@sighoya 말씀하신 내용을 이해했는지 잘 모르겠습니다.

인터페이스에서 내부적으로 설정됩니다.

사실이 아니다. 내 원래 의견에 설명된 대로 제약 조건을 충족하는 특정 유형을 사용할 수 있습니다. 예를 들어 유형 매개변수 유형 별칭은 다음과 같이 선언할 수 있습니다.

type T = int

그리고 + 연산자(또는 - 또는 * ; 해당 연산자가 패키지 본문에서 사용되는지 여부에 따라 다름)가 있는 유형만 유형 값으로 사용할 수 있습니다. 해당 유형 매개변수에 있습니다.

따라서 유형 매개변수 자리 표시자로 사용할 수 있는 것은 인터페이스만이 아닙니다.

그러나 이것은 제네릭의 도입을 의미합니다.

이것은 Go 언어 자체에서 제네릭을 도입/구현하는 _is_ 방법입니다.

@dc0d

다형성을 제공하려면 인터페이스{}를 사용합니다. 이렇게 하면 나중에 T를 모든 유형으로 설정할 수 있습니다.

'type T=Int'를 설정하면 많은 이점이 없습니다.

나중에 설정할 수 있는 '유형 T'가 먼저 선언되지 않음/정의되지 않음이라고 말하면 제네릭과 같은 것이 있습니다.

문제는 'T'가 모듈/패키지 전체를 보유하고 어떤 함수나 구조체에도 국한되지 않는다는 것입니다(좋아요. 외부에서 액세스할 수 있는 구조체의 중첩 형식 선언일 수도 있음).

왜 대신 쓰지 않습니까?:

fun<type T>(t T)

또는

fun[type T](t T)

또한 처음에 형식 매개 변수 전문화 없이 일반 함수 또는 구조체를 호출할 때 올바른 형식을 추론할 수 있는 형식 유추 기계가 필요합니다.

@dc0d 가 썼다

그리고 + 연산자(또는 - 또는 *; 해당 연산자가 패키지 본문에서 사용되는지 여부에 따라 다름)가 있는 유형만 해당 유형 매개변수에 있는 유형 값으로 사용할 수 있습니다.

이에 대해 더 자세히 설명해 주시겠습니까?

@시고야

다형성을 제공하려면 인터페이스{}를 사용합니다. 이렇게 하면 나중에 T를 모든 유형으로 설정할 수 있습니다.

다형성은 유형 별칭을 다시 바인딩할 때 호환 가능한 유형을 갖는 것으로 달성되지 않습니다. 유일한 실제 제약 조건은 일반 패키지의 본문입니다. 기계적으로 호환되어야 합니다.

이에 대해 더 자세히 설명해 주시겠습니까?

예를 들어 패키지 수준 유형 매개변수 유형 별칭이 다음과 같이 정의된 경우:

package genericadd

type T = int

func Add(a, b T) T { return a + b }

그러면 다음과 같이 거의 모든 숫자 유형을 T 에 할당할 수 있습니다.

package main

import (
    "genericadd"
)

var add = genericadd.Add(
    T = float64
)

func main() {
    var (
        a, b float64
    )

    println(add(a, b))
}

@dc0d

그러나 나는 그들이 동일한지 또는 어떻게 동일한지 확실하지 않습니다.

그들은 내가 보는 것과 거의 동일하게 작동한다는 점에서 동일합니다. 모든 클래스 템플릿 인스턴스화에 대해 컴파일러는 클래스 템플릿과 해당 매개변수 목록의 특정 조합을 처음 사용하는 경우 고유한 구현을 생성합니다. 동일한 클래스 템플릿의 여러 구현이 있으므로 이진 크기가 증가합니다. 컴파일러는 이제 이러한 구현을 생성하고 모든 종류의 검사를 수행해야 하므로 컴파일 속도가 느려집니다. C++의 경우 컴파일 시간이 엄청나게 늘어날 수 있습니다. 장난감 예제는 빠르지만 C++ 예제도 마찬가지입니다.

잘 모르겠다. 제네릭을 구현하는 다른 방법이 이를 지원합니까?

다른 언어는 문제가 없습니다. 특히 나에게 가장 친숙한 C#. 그러나 Go 팀이 완전히 배제한 런타임 코드 생성을 사용합니다. Java도 작동하지만 구현이 가장 좋지는 않습니다. ianlancetaylor 제안 중 일부는 내가 이해하는 바이너리 전용 패키지를 처리할 수 있습니다.

내가 이해하지 못하는 유일한 것은 바이너리 전용 패키지가 지원되어야 하는지 여부입니다. 나는 그것들이 제안서에 명시적으로 언급된 것을 보지 못합니다. 나는 그것들에 대해 별로 신경 쓰지 않지만 여전히 언어 기능입니다.

내 이해를 테스트하기 위해 ... 복사/붙여 넣기 알고리즘의이 저장소를 고려하십시오 [ 여기 ]. "int"를 사용하지 않으려면 코드를 직접 사용할 수 없습니다. 복사하여 붙여넣고 수정해야 작동합니다. 그리고 수정한다는 것은 "int"의 각 인스턴스가 실제로 필요한 유형으로 변경되어야 함을 의미합니다.

유형 별칭 접근 방식은 예를 들어 T를 한 번 수정하고 "type T int" 행을 삽입합니다. 그런 다음 컴파일러는 T를 float64와 같은 다른 것에 다시 바인딩해야 합니다.

그러므로:
a) 이 기술을 실제로 사용하지 않는 한 컴파일러 속도 저하가 없을 것이라고 주장합니다. 그래서 그것은 당신의 선택입니다.
b) 동일한 코드의 여러 버전을 사용할 수 있는 새로운 vgo 항목이 주어지면... 즉, 사용된 소스를 보이지 않게 집어넣는 방법이 있어야 함을 의미합니다. 그러면 컴파일러는 두 가지 버전을 추적할 수 있습니다. 동일한 리바인딩을 사용하고 중복을 방지합니다. 따라서 코드 팽창은 현재 복사/붙여넣기 기술과 동일할 것이라고 생각합니다.

유형 별칭과 향후 vgo 사이에 제네릭에 대한 이러한 접근 방식의 기초가 거의 완성된 것 같습니다...

제안서 [ 여기 ]에 "알 수 없는" 항목이 나열되어 있습니다. 그래서 좀 더 살을 찌우면 좋을 것 같다.

@mandolyte 일부 일반 컨테이너에 특수 유형을 래핑하여 또 다른 수준의 간접 참조를 추가할 수 있습니다. 그렇게 하면 구현이 동일하게 유지될 수 있습니다. 그러면 컴파일러가 모든 마법을 수행합니다. Ian의 유형 매개변수 제안이 그런 식으로 작동한다고 생각합니다.

유저가 타입 소거와 모노모피제이션 중 선택이 필요하다고 생각합니다.
후자는 Rust가 제로 비용 추상화를 제공하는 이유입니다. 가야합니다.

2018년 4월 9일 월요일, 오전 8:32 Antonenko Artem [email protected]
썼다:

@mandolyte https://github.com/mandolyte 다른 레벨을 추가할 수 있습니다.
일부 일반 컨테이너에 특수 유형을 래핑하여 간접 참조. 저것
구현이 동일하게 유지될 수 있는 방법입니다. 그러면 컴파일러가 모든 작업을 수행합니다.
마법. Ian의 유형 매개변수 제안이 그런 식으로 작동한다고 생각합니다.

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

모듈성과 성능 간의 균형에 대한 이 논의에서 이해할 수 있는 혼란이 있는 것 같습니다. 사용되는 모든 유형에서 일반 코드를 재유형 검사하고 인스턴스화하는 C++ 기술은 모듈화에 좋지 않고 이진 배포에 좋지 않으며 코드 팽창으로 인해 성능에 좋지 않습니다. 이 접근 방식의 좋은 부분은 생성된 코드를 사용 중인 유형에 자동으로 특화한다는 것입니다. 이는 사용 중인 유형이 int 와 같은 기본 유형일 때 특히 유용합니다. Java는 일반 코드를 동질적으로 번역하지만 특히 코드가 T[] 유형을 사용할 때 성능 면에서 대가를 치릅니다.

다행스럽게도 C++의 비모듈성 및 전체 런타임 코드 생성 없이 이 문제를 해결할 수 있는 몇 가지 방법이 있습니다.

1. 기본 유형에 대한 특수 인스턴스를 생성합니다. 이것은 자동으로 또는 프로그래머 지시에 의해 수행될 수 있습니다. 올바른 인스턴스화에 액세스하려면 일부 디스패치가 필요하지만 동종 번역에 이미 필요한 디스패치로 접힐 수 있습니다. 이것은 C#과 유사하게 작동하지만 전체 런타임 코드 생성이 필요하지 않습니다. 코드 로드로 디스패치 테이블을 설정하기 위해 런타임에서 약간의 추가 지원이 바람직할 수 있습니다.
2. T가 기본 유형으로 인스턴스화될 때 T의 배열이 실제로 기본 유형의 배열로 표현되는 단일 일반 구현을 사용하십시오. PolyJ, Genus 및 Familia에서 사용한 이 접근 방식은 완전히 전문화된 구현만큼 빠르지는 않지만 Java 접근 방식에 비해 성능을 크게 향상시킵니다.

@dc0d

다형성은 유형 별칭을 다시 바인딩할 때 호환 가능한 유형을 갖는 것으로 달성되지 않습니다. 유일한 실제 제약 조건은 일반 패키지의 본문입니다. 기계적으로 호환되어야 합니다.

유형 별칭은 상수 참조여야 하기 때문에 잘못된 방법입니다.
'T Type'을 직접 쓰는 것이 더 낫습니다. 그러면 실제로 제네릭을 사용하는 것을 볼 수 있습니다.

전체 패키지/모듈에 대해 전역 유형 변수 'T'를 사용하려는 이유는 <> 또는 []의 로컬 유형 vars가 더 모듈식입니다.

@크레커

특히 나에게 가장 친숙한 C#. 그러나 Go 팀이 완전히 배제한 런타임 코드 생성을 사용합니다.

참조 유형용이지만 값 유형용은 아닙니다.

@DemiMarie

유저가 타입 소거와 모노모피제이션 중 선택이 필요하다고 생각합니다.
후자는 Rust가 제로 비용 추상화를 제공하는 이유입니다. 가야합니다.

"Type Erasure"는 모호합니다. Java가 제공하는 Type Parameter Erasure를 의미하는 것으로 가정하지만 이는 사실이 아닙니다.
Java에는 단형화가 있지만 대부분이 Object인 일반 제약 조건의 상한으로 일정하게 단형화(반)합니다.
다른 유형의 메소드와 필드를 제공하기 위해 상한선은 내부적으로 적절한 유형으로 캐스팅되어 상당히 추악합니다.
Valhalla 프로젝트가 수락되면 값 유형은 변경되지만 참조 유형은 변경되지 않습니다.

다음과 같은 이유로 Java 방식으로 이동할 필요가 없습니다.

"컴파일된 패키지에 대한 바이너리 호환성은 릴리스 간에 보장되지 않습니다."

반면 이것은 Java에서는 불가능합니다.

모듈성과 성능 간의 균형에 대한 이 논의에서 이해할 수 있는 혼란이 있는 것 같습니다. 사용되는 모든 유형에서 일반 코드를 재유형 검사하고 인스턴스화하는 C++ 기술은 모듈화에 좋지 않고 이진 배포에 좋지 않으며 코드 팽창으로 인해 성능에 좋지 않습니다.

여기서 말하는 퍼포먼스란?

"코드 팽창" 및 "성능"이 "바이너리 크기" 및 "명령 캐시 압력"을 의미하는 경우 문제는 해결하기가 상당히 간단합니다. 각 전문화에 대한 디버그 정보를 과도하게 유지하지 않는 한 다음을 수행할 수 있습니다. 링크 타임에 동일한 본체를 가진 함수를 동일한 함수로 축소합니다(소위 "Borland 모델" ). 이는 중요하지 않은 메소드를 호출하지 않고 기본 유형 및 유형에 대한 특수화를 간단하게 처리합니다.

"코드 팽창"과 "성능"이 "링커 입력 크기"와 "연결 시간"을 의미하는 경우 빌드 시스템에 대해 특정(합리적인) 가정을 할 수만 있다면 문제도 상당히 간단합니다. 모든 컴파일 단위에서 각 전문화를 내보내는 대신 필요한 전문화 목록을 내보내고 빌드 시스템이 연결하기 전에 각 고유 전문화를 정확히 한 번 인스턴스화하도록 할 수 있습니다("Cfront 모델"). IIRC, 이것은 C++ 모듈 이 해결하려고 시도하는 문제 중 하나입니다.

따라서 내가 놓친 세 번째 종류의 "코드 팽창" 및 "성능"을 의미하지 않는 한 사양이 아니라 구현의 문제에 대해 이야기하고 있는 것 같습니다. _구현이 디버그를 과도하게 유지하지 않는 한 정보,_ 성능 문제를 해결하는 것은 매우 간단합니다.

Go의 더 큰 문제는 우리가 주의하지 않으면 런타임에 매개변수화된 유형의 새로운 인스턴스를 생성하기 위해 type-assertion이나 리플렉션을 사용하는 것이 가능해진다는 것입니다. ‐프로그램 분석 - 고칠 수 있습니다.

그것은 실제로 모듈화의 실패이지만 코드 팽창과 아무 관련이 없습니다. 대신 Go 함수(및 메서드) 유형이 인수에 대한 제약 조건의 완전한 집합을 캡처하지 않는다는 사실에서 비롯됩니다.

@시고야

참조 유형용이지만 값 유형용은 아닙니다.

내가 읽은 바에 따르면 C# JIT는 각 값 유형에 대해 런타임에 모든 참조 유형에 대해 한 번 특수화를 수행합니다. 컴파일 타임(IL-time) 전문화가 없습니다. 이것이 C# 접근 방식이 완전히 무시되는 이유입니다. Go 팀은 Go가 실행할 수 있는 플랫폼을 제한하기 때문에 런타임 코드 생성에 의존하고 싶지 않습니다. 특히 iOS에서는 런타임에 코드 생성을 수행할 수 없습니다. 그것은 작동하고 실제로 일부를 수행했지만 Apple은 AppStore에서 허용하지 않습니다.

넌 어떻게 그걸 했니?

2018년 4월 9일 월요일 오후 3:41 Antonenko Artem [email protected]
썼다:

@sighoya https://github.com/sighoya

참조 유형용이지만 값 유형용은 아닙니다.

내가 읽은 것에서 C# JIT는 각 값에 대해 런타임에 전문화를 수행합니다.
유형 및 모든 참조 유형에 대해 한 번. 컴파일 타임이 없다
전문화. 이것이 C# 접근 방식이 완전히 무시되는 이유입니다 - Go team
플랫폼을 제한하므로 런타임 코드 생성에 의존하고 싶지 않습니다. Go
실행할 수 있습니다. 특히 iOS에서는 코드 생성이 허용되지 않습니다.
런타임에. 작동하고 실제로 일부 작업을 수행했지만 Apple에서는 허용하지 않습니다.
앱스토어에서.

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

@DemiMarie 는 확실히 하기 위해 내 이전 연구 코드를 시작했습니다(연구는 다른 이유로 중단되었습니다). 다시 한 번, 디버거가 나를 오도합니다. 페이지를 할당하고 몇 가지 지침을 작성하고 PROT_EXEC로 mprotect하고 이동합니다. 디버거에서 작동합니다. 디버거가 없으면 예상대로 충돌 로그에 CODESIGN 메시지와 함께 앱이 SIGKILL됩니다. 따라서 AppStore가 없어도 작동하지 않습니다. iOS가 Go에 중요한 경우 런타임 코드 생성에 대한 더 강력한 주장.

먼저, Rob Pike의 5가지 프로그래밍 규칙을 한 번 더 숙고하는 것이 도움이 될 것입니다.

두 번째(IMHO):

느린 컴파일 및 바이너리 크기에 대해 Go를 사용하여 개발 중인 일반적인 유형의 애플리케이션에서 얼마나 많은 일반 유형이 사용됩니까(규칙 3에서 _n은 일반적으로 작음)? 문제가 구체적인 개념(많은 수의 유형)에서 높은 수준의 카디널리티를 필요로 하지 않는 한 오버헤드는 간과될 수 있습니다. 그때에도 나는 그 접근 방식이 뭔가 잘못되었다고 주장할 것입니다. 전자 상거래 시스템을 구현할 때 아무도 각 제품 종류에 대해 별도의 유형을 정의하지 않으며 변형 및 아마도 가능한 사용자 정의가 가능합니다.

Verbosity는 보다 명확하고 명확하게 만드는 단순함과 친숙함(예: 구문)의 좋은 형태입니다. Type Alias ​​Rebinding을 사용하면 코드 부풀림이 더 높아질지 의심스럽긴 하지만 친숙한 Go-ish 구문과 이에 수반되는 명백한 장황함이 마음에 듭니다. Go의 목표 중 하나는 읽기 쉬운 것입니다(개인적으로는 쓰기도 비교적 쉽고 즐겁습니다).

런타임에 컴파일 타임에 생성된 구체적인 경계 유형만 사용되기 때문에 성능이 저하될 수 있다는 것을 이해하지 못합니다. 런타임 오버헤드가 없습니다.

Type Alias ​​Rebinding과 관련된 유일한 관심사는 바이너리 배포판일 수 있습니다.

@dc0d 성능 손상은 일반적으로 클래스 템플릿의 다른 구현으로 인해 명령 캐시를 채우는 것을 의미합니다. 실제 성능과 정확히 어떻게 관련되는지는 미해결 질문이며 벤치마크는 모르지만 이론적으로는 문제입니다.

바이너리 크기에 관해서. 사람들이 일반적으로 제기하는 또 다른 이론적 문제(이전에 내가 했던 것처럼)이지만 실제 코드가 어떻게 고통을 겪을지는 다시 말하지만 미해결 질문입니다. 예를 들어 모든 포인터 및 인터페이스 유형에 대한 전문화는 동일할 수 있다고 생각합니다. 그러나 모든 값 유형에 대한 전문화는 고유합니다. 그리고 여기에는 구조체도 포함됩니다. 일반 컨테이너를 사용하여 저장하는 것은 일반적이며 일반 컨테이너 구현이 작지 않기 때문에 상당한 코드 팽창을 유발할 수 있습니다.

Type Alias ​​Rebinding과 관련된 유일한 관심사는 바이너리 배포판일 수 있습니다.

여기 아직 확실하지 않습니다. 제네릭 제안은 바이너리 전용 패키지를 지원해야 합니까 아니면 바이너리 전용 패키지는 제네릭을 지원하지 않는다고 언급할 수 있습니다. 훨씬 쉬울 것입니다. 그건 확실합니다.

앞서 언급했듯이 디버깅을 지원할 필요가 없는 경우
동일한 템플릿 인스턴스화를 결합할 수 있습니다.

2018년 4월 10일 화요일 오전 5:46 Kaveh Shahbazian [email protected]
썼다:

먼저 Rob Pike의 5가지 프로그래밍 규칙을 숙고하는 것이 도움이 될 것입니다.
https://users.ece.utexas.edu/%7Eadnan/pike.html 한 번 더.

두 번째(IMHO):

느린 컴파일과 바이너리 크기에 대해, 얼마나 많은 제네릭 유형이
Go를 사용하여 개발 중인 일반적인 유형의 애플리케이션( n은일반적으로 규칙 3에서 작음 )? 문제가 높은 수준을 필요로 하지 않는 한
오버헤드가
간과하다. 그때도 나는 그것이 뭔가 잘못되었다고 주장할 것이다.
접근하다. 전자 상거래 시스템을 구현할 때 아무도 별도로 정의하지 않습니다.
각 종류의 제품에 대한 유형 및 변형 및 아마도 가능
사용자 정의.

장황함은 단순함과 친숙함의 좋은 형태입니다(예:
구문)을 사용하면 더 명확하고 명확해집니다. 나는 그것을 의심하면서
Type Alias ​​Rebinding을 사용하면 코드 팽창이 더 높을 것입니다.
친숙한 Go-ish 구문과 그에 수반되는 명백한 장황함. 중 하나
Go의 목표는 읽기 쉬운 것입니다(개인적으로는
쓰기도 비교적 쉽고 쾌적함).

런타임 시에만 성능이 저하될 수 있다는 점을 이해하지 못합니다.
에서 생성된 구체적인 경계 유형이 사용 중입니다.
컴파일 시간. 런타임 오버헤드가 없습니다.

Type Alias ​​Rebinding과 관련된 유일한 관심사는 바이너리일 수 있습니다.
분포.

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

인스턴스화는 "동일한 인수 사용" 또는 "동일한 기본 유형의 인수 사용"이라는 의미에서 "동일"할 필요도 없습니다. 생성된 동일한 코드를 생성할 수 있을 만큼 가까이 있으면 됩니다. (Go의 경우 "동일한 포인터 마스크"도 의미합니다.)

@크레커

내가 읽은 바에 따르면 C# JIT는 각 값 유형에 대해 런타임에 모든 참조 유형에 대해 한 번 특수화를 수행합니다. 컴파일 타임(IL-time) 전문화가 없습니다.

글쎄, 이것은 코드가 실행되기 직전에 바이트 코드가 해석되기 때문에 때때로 약간 복잡합니다. 따라서 코드 생성은 프로그램을 실행하기 전에 수행되지만 컴파일 후에 수행되므로 코드 실행 중에 실행되는 vm의 의미가 옳습니다. 생성됩니다.

나는 우리가 컴파일 타임에 코드를 생성한다면 C#의 제네릭 시스템이 괜찮을 것이라고 생각한다.
go는 VM이 ​​아니기 때문에 C#의 의미에서 런타임 코드 생성은 go로 불가능합니다.

@dc0d

Type Alias ​​Rebinding과 관련된 유일한 관심사는 바이너리 배포판일 수 있습니다.

좀 자세히 설명해주실 수 있나요?

@sighoya 내 실수; 나는 바이너리 배포 가 아니라 바이너리 패키지를 의미했습니다. 개인적으로 그것이 얼마나 중요한지 모릅니다.

@creker 좋은 요약입니다! (MO) 강력한 이유가 발견되지 않는 한 Go 언어 구조에 과부하가 걸리는 형태는 피해야 합니다. Type Alias ​​Rebinding을 사용하는 한 가지 이유는 슬라이스 또는 맵과 같은 기본 제공 복합 유형의 오버로드를 방지하기 위해서입니다.

Verbosity는 보다 명확하고 명확하게 만드는 단순함과 친숙함(예: 구문)의 좋은 형태입니다. Type Alias ​​Rebinding을 사용하면 코드 부풀림이 더 높아질지 의심스럽긴 하지만 친숙한 Go-ish 구문과 이에 수반되는 명백한 장황함이 마음에 듭니다. Go의 목표 중 하나는 읽기 쉬운 것입니다(개인적으로는 쓰기도 비교적 쉽고 즐겁습니다).

나는 이 개념에 동의하지 않습니다. 당신의 제안은 사용자가 모든 프로그래머에게 알려진 가장 어려운 일, 즉 이름 지정을 하도록 강요할 것입니다. 그래서 우리는 헝가리 표기법으로 가득 찬 코드로 끝날 것입니다. 이것은 보기에 좋지 않을 뿐만 아니라 불필요하게 장황하고 말더듬을 유발합니다. 게다가, 다른 제안도 go-ish 구문을 가져오면서 동시에 이러한 문제가 없습니다.

우리가 매일 고안해야 하는 이름에는 세 가지 범주가 있습니다.

• 도메인 엔티티/로직의 경우
• 프로그램 워크플로 데이터 유형/로직
• 서비스/인터페이스 데이터 유형/로직

프로그래머가 자신의 코드에서 이름을 짓는 것을 피하는 데 성공한 적이 몇 번이나 될까요?

어렵든 아니든 매일 해야 합니다. 그리고 대부분의 장애물은 이름 지정 프로세스 자체의 어려움이 아니라 코드 기반 구조화의 무능력에서 비롯됩니다. 그 인용문은 적어도 현재 형태에서는 지금까지 프로그래밍 세계에 큰 피해를 입혔습니다. 그것은 단순히 네이밍의 중요성을 강조하려고 합니다. 우리는 코드의 이름을 통해 통신하기 때문입니다.

그리고 이름은 코드 구조화 연습을 동반할 때 훨씬 더 강력해집니다. 코드 레이아웃(파일, 디렉터리 구조, 패키지/모듈) 및 사례(디자인 패턴, REST와 같은 서비스 추상화, 리소스 관리 - 동시 프로그래밍, 하드 드라이브 액세스, 처리량/대기 시간) 측면에서 모두.

구문과 장황함에 관해서는 나는 영리한 간결함보다 장황함을 선호합니다(적어도 Go의 맥락에서). 다시 말하지만, Go는 읽기 쉬우며 반드시 쓰기가 쉽지는 않습니다(이상하게도 나는 그것이 좋다고 생각합니다) .

@jba 참조 https://github.com/golang/go/issues/8303 및 https://github.com/golang/go/issues/8082

Go에서 제네릭을 구현하는 이유와 방법에 대한 많은 경험 보고서와 제안을 읽었습니다.

Go 인터프리터 gomacro 에서 실제로 구현하려고 해도 괜찮습니까?

나는 과거에 두 언어에 제네릭을 추가한 경험이 있습니다.

1. 내가 순진했을 때 다시 만든 지금은 버려진 언어 :) C 소스 코드로 변환
2. 내 라이브러리 cl-parametric-types 가 있는 Common Lisp - 일반 유형 및 함수의 부분 및 전체 전문화도 지원합니다.

@cosmos72 형식 안전성을 유지한 기술의 프로토타입을 보는 것은 좋은 경험 보고서가 될 것입니다.

방금 작업을 시작했습니다. 진행 상황은 https://github.com/cosmos72/gomacro/tree/generics-v1 에서 확인할 수 있습니다.

현재 https://github.com/golang/proposal/blob/master/design/15292-generics.md#Proposal 에 나열된 세 번째 및 네 번째 Ian의 제안을 (약간 수정된) 혼합하여 시작하고 있습니다.

@cosmos72 아래 링크에 제안 요약이 있습니다. 당신의 블렌드는 그 중 하나입니까?
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

나는 그 문서를 읽었는데, 그것은 다양한 프로그래밍 언어에 의한 제네릭에 대한 다양한 접근 방식을 요약하고 있습니다.

현재 저는 C++, Rust 및 기타에서 사용하는 "유형 특수화" 기술로 가고 있습니다. Go 새 유형에 대한 가장 일반적인 구문은 type ( Foo ...; Bar ...) 이고 저는 확장하고 있기 때문에 "매개변수화된 템플릿 범위"가 약간 있을 수 있습니다. template[T1,T2...] type ( Foo ...; Bar ...) .
또한 "제약적 전문화"의 문을 열어두고 있습니다.

나는 또한 "다형성 함수 특수화"를 구현하고 싶습니다. 즉, 프로그래머가 지정하지 않은 경우 호출 사이트의 언어에 의해 특수화가 자동으로 유추되도록 정렬하지만 구현하기가 다소 복잡할 수 있습니다. 우리는 볼 것이다.

내가 언급한 블렌드는 https://github.com/golang/proposal/blob/master/design/15292/2013-10-gen.md 와 https://github.com/golang/proposal/blob/ 사이입니다.

업데이트: 초기 발표 이후에 이 공식 Go 문제의 스팸을 피하려면 gomacro 문제 #24: 일반 추가 에서 gomacro 관련 토론을 계속하는 것이 좋습니다.

업데이트 2: 첫 번째 템플릿 함수가 성공적으로 컴파일되고 실행되었습니다. https://github.com/cosmos72/gomacro/tree/generics-v1 참조

기록을 위해 내 의견을 다시 말할 수 있습니다(제네릭 및 유형 별칭 리바인딩에 대해).

제네릭은 언어 기능(모든 수준에서 Go의 유형 시스템 간섭)이 아닌 컴파일러 기능(코드 생성, 템플릿 등)으로 추가되어야 합니다.

@dc0d
그러나 C++ 템플릿은 컴파일러 및 언어 기능이 아닙니까?

@sighoya 제가 C++을 전문적으로 마지막으로 작성한 것은 2001년 쯤이었습니다. 그래서 제가 틀릴 수도 있습니다. 그러나 명명의 의미가 정확하다고 가정하면 - "템플릿" 부분 - 예(또는 오히려 아니오)입니다. 일부 언어 구성과 함께 컴파일러 기능(언어 기능 아님)일 수 있으며, 이는 유형 시스템과 관련된 언어 구성을 오버로드하지 않을 가능성이 큽니다.

@dc0d를 지지합니다. 생각해보면 이 기능은 통합 코드 생성기에 불과합니다.

예: 바이너리 크기는 증가할 수 있고 증가할 것입니다. 하지만 지금은 외부 기능으로 거의 동일하지만 코드 생성기를 사용합니다. 내 템플릿을 다음과 같이 만들어야 하는 경우:

type BinaryTreeOfStrings struct {
    left, right *BinaryTreeOfStrings;
    string content;
}

// Its methods here

type BinaryTreeOfBigInts struct {
    left, right *BinaryTreeOfBigInts;
    uint64 content;
}

// AGAIN the same methods but different type

... 복사 붙여넣기나 외부 도구를 사용하는 것보다 이 기능이 컴파일러 자체의 일부가 되기를 진심으로 바랍니다.

참고:

• 예, 종료 코드가 중복됩니다. 발전기를 사용하는 것처럼 맞습니다. 그리고 바이너리는 더 커질 것입니다.
• 예, 아이디어는 독창적이지 않지만 C++에서 차용했습니다.
• 예, MyType의 기능T 유형의 항목을 포함하지 않는 것(직접 또는 간접적으로)도 반복됩니다. 이는 최적화될 수 있습니다(예: 메시지 수신 객체에 대한 포인터 가 아닌 T 유형을 참조하는 메소드는 각 T 에 대해 생성됩니다. T 각 T 에 대해 생성되고 재귀적으로 생성됩니다. 반면 T 에 대한 유일한 참조가 수신자에서 *T 인 메서드, 그리고 그 안전한 메소드만 호출하고 동일한 기준을 만족하는 다른 메소드는 한 번만 만들 수 있습니다. 어쨌든, IMO 이 지점은 크고 요점은 적습니다. 이 최적화가 존재하지 않더라도 매우 기쁠 것입니다.
• 내 의견으로는 형식 인수가 명시적이어야 합니다. 특히 개체가 잠재적으로 무한 인터페이스를 충족하는 경우. 다시: 코드 생성기.

지금까지 내 의견에서 내 제안은 외부 도구 대신 컴파일러 지원 코드 생성기 로 구현하는 것입니다.

Go가 C++ 경로를 따르는 것은 불행한 일입니다. 많은 사람들은 C++ 접근 방식을 프로그래머가 디버깅의 어려움, 모듈성 부족, 코드 팽창과 같은 제네릭의 전체 아이디어에 반대하게 만든 혼란으로 봅니다. 모든 "코드 생성기" 솔루션은 실제로 매크로 대체에 불과합니다. 이것이 코드를 작성하려는 방식이라면 컴파일러 지원이 필요한 이유는 무엇입니까?

@andrewcmyers 저는 일반 패키지만 작성하고 interface{} 를 명시적으로 사용하는 대신 type T = interface{} 를 패키지 수준의 일반 매개변수로 사용하는 Type Alias ​​Rebinding 제안을 받았습니다. 그리고 그게 다야.

• 우리는 그것을 일반 패키지처럼 디버그합니다. 이것은 중간 반감기가 아닌 실제 코드입니다.
• 모든 수준에서 Go 유형 시스템에 간섭할 필요가 없습니다. 할당 가능성만 생각하십시오.
• 명시적입니다. 숨겨진 모조가 없습니다. 물론 일반 호출을 매끄럽게 연결할 수 없다는 단점이 있습니다. 나는 그것을 무승부로 본다! 두 번의 연속 호출에서 유형을 변경하는 것은 하나의 명령문에서 Goish(IMO)가 아닙니다.
• 그리고 무엇보다도 Go 1.x(x >= 8) 시리즈와 하위 호환됩니다.

아이디어가 새로운 것은 아니지만 Go에서 구현하는 방식은 실용적이고 명확합니다.

추가 보너스: Go에는 연산자 오버로딩이 없습니다. 그러나 유형 별칭의 기본값을 (예를 들어) type T = int 로 정의하면 이 일반 패키지를 사용자 정의하는 데 사용할 수 있는 유일한 유효한 유형이 아니라 + 에 대한 내부 구현이 있는 숫자 유형입니다.

또한 별칭 유형 매개변수는 일부 유효성 검사기 유형 및 명령문을 추가하는 것만으로 둘 이상의 인터페이스를 수행하도록 강제할 수 있습니다.

이제 Error 및 Stringer 인터페이스를 구현하는 매개변수가 있고 + 연산자를 지원하는 숫자 유형인 일반 유형에 대한 명시적 표기법을 사용하는 것은 매우 추악합니다. !

지금 우리는 코드 생성기를 사용합니다. 이것은 거의 동일하지만 외부 기능입니다.

차이점은 코드 생성을 수행하는 널리 허용되는 방법( go generate 을 통해)이 컴파일 시간이 아니라 커밋/개발 시간에 발생한다는 것입니다. 컴파일 시간에 수행한다는 것은 컴파일러에서 임의의 코드 실행을 허용해야 함을 의미합니다. 라이브러리는 컴파일 시간을 몇 배나 증가시킬 수 있으며 별도의 빌드 종속성을 갖게 됩니다(즉, 더 이상 Go로 코드를 빌드 할 수 없습니다. 도구). 나는 메타 프로그래밍 호출을 업스트림 개발자에게 푸시하기 위해 Go를 좋아합니다.

즉, 이러한 문제를 해결하기 위한 모든 접근 방식이 그렇듯이 이 접근 방식에도 단점이 있고 절충안이 포함됩니다. 개인적으로 나는 유형 시스템에서 지원하는 실제 제네릭이 더 나을 뿐만 아니라(즉, 더 강력한 기능 세트를 가짐) 예측 가능하고 안전한 컴파일의 이점을 유지할 수 있다고 주장합니다.

위의 내용을 모두 읽을 것이라고 약속하지만 약간 추가할 것 입니다. Apache Beam용 GoLang SDK는 라이브러리 디자이너가 높은 수준의 모든 것을 _적절하게_ 해내기 위해 견뎌야 하는 문제에 대한 다소 밝은 예/쇼케이스인 것 같습니다.

Go 제네릭에는 최소한 두 가지 실험적 구현이 있습니다. 이번 주 초에 나는 (1)과 함께 시간을 보냈습니다. 코드의 가독성에 미치는 영향이 최소화되어 기뻤습니다. 그리고 평등 테스트를 제공하기 위해 익명 함수를 사용하는 것이 잘 작동한다는 것을 발견했습니다. 그래서 나는 연산자 오버로딩이 필요하지 않다고 확신합니다. 내가 찾은 한 가지 문제는 오류 처리에 있었습니다. 유형이 정수 또는 문자열인 경우 "return nil,err"의 일반적인 관용구는 작동하지 않습니다. 이 문제를 해결하는 방법에는 여러 가지가 있으며 모두 복잡성 비용이 있습니다. 조금 이상할 수도 있지만 Go의 오류 처리가 마음에 듭니다. 그래서 이것은 Go 제네릭 솔루션이 유형의 0 값에 대한 범용 키워드를 가져야 한다는 것을 관찰하게 합니다. 컴파일러는 단순히 숫자 유형의 경우 0, 문자열 유형의 경우 빈 문자열, 구조체의 경우 nil로 대체합니다.

이 구현은 패키지 수준 접근 방식을 시행하지 않았지만 그렇게 하는 것은 확실히 자연스럽습니다. 그리고 물론 이 구현은 컴파일러 인스턴스화된 코드가 어디로 가야 하는지(어디에 있다면), 코드 디버거가 작동하는 방식 등에 대한 모든 기술적 세부 사항을 다루지 않았습니다.

정수에 대해 동일한 알고리즘 코드를 사용하고 Point와 같은 것을 사용하는 것은 매우 좋았습니다.

type Point struct {
    x,y int
}

내 테스트 및 관찰에 대해서는 (2)를 참조하십시오.

(1) https://github.com/albrow/fo; 다른 하나는 앞서 언급한 https://github.com/cosmos72/gomacro#generics 입니다.
(2) https://github.com/mandolyte/fo-experiments

@mandolyte *new(T) 를 사용하여 모든 유형의 0 값을 얻을 수 있습니다.

default(T) 또는 zero(T)와 같은 언어 구성(첫 번째 것은
C# IIRC에서는 명확하지만 OTOH는 *new(T)보다 더 길지만
성능).

2018-07-06 9:15 GMT-05:00 Tom Thorogood 알림 @github.com :

@mandolyte https://github.com/mandolyte *new(T)를 사용하여
모든 유형의 0 값.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/15292#issuecomment-403046735 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AlhWhQ5cQwnc3x_XUldyJXCHYzmr6aN3ks5uD3ETgaJpZM4IG-xv
.

--
TripleMint에서 사용할 메일 서명 테스트입니다.

19642는 일반적인 0 값을 논의하기 위한 것입니다.

@tmthrgd 어쩐지 그 소소한 정보가 그리웠어요. 감사 해요!

전주곡

제네릭은 사용자 정의 가능한 구성을 전문화하는 것입니다. 전문화의 세 가지 범주는 다음과 같습니다.

• 전문화 유형, Type<T> - _array_;
• 전문화 계산, F<T>(T) 또는 F<T>(Type<T>) - _정렬 가능한 배열_;
• 전문 표기법, 예를 들어 _LINQ_ - Go의 select 또는 for 문;

물론 훨씬 더 일반적인 구조를 제공하는 프로그래밍 언어가 있습니다. 그러나 _C++_, _C#_ 또는 _Java_와 같은 기존 프로그래밍 언어는 이 목록으로 제한된 언어 구성을 다소 제공합니다.

생각

제네릭 유형/구성의 첫 번째 범주는 유형에 구애받지 않아야 합니다.

제네릭 유형/구성의 두 번째 범주는 유형 매개변수의 _property_에 대해 _act_해야 합니다. 예를 들어 _sortable array_는 항목의 _comparable 속성_을 _compare_할 수 있어야 합니다. T.(P) 가 T 의 속성이고 A(T.(P)) 가 해당 속성에 작용하는 계산/액션이라고 가정하면 (A, .(P)) 는 각 개별 항목에 적용될 수 있습니다. 또는 원래의 사용자 정의 가능한 계산에 전달된 특수 계산으로 선언됩니다. Go에서 후자의 경우의 예로는 sort.Interface 인터페이스가 있으며 여기에는 별도의 함수 sort.Reverse 도 있습니다.

제네릭 유형/구성의 세 번째 범주는 _type-specialized_ 언어 표기법입니다. _일반적으로_ Go가 아닌 것 같습니다.

질문

계속 ...

이모티콘보다 더 설명적인 피드백은 무엇이든 환영합니다!

@dc0d 제네릭을 정의하기 전에 Sepanov의 "프로그래밍 요소"를 공부하는 것이 좋습니다. TL;DR은 배열을 정렬하는 알고리즘과 같이 시작하는 구체적인 코드를 작성하는 것입니다. 나중에 우리는 Btree 등과 같은 다른 컬렉션 유형을 추가합니다. 우리는 본질적으로 동일한 정렬 알고리즘의 많은 복사본을 작성하고 있다는 것을 알아차리고 '정렬 가능'과 같은 몇 가지 개념을 정의합니다. 이제 우리는 정렬 알고리즘을 필요한 액세스 패턴별로 분류하려고 합니다. 예를 들어 순방향 전용, 단일 패스(스트림), 다중 패스만 전달(단일 연결 목록), 양방향(이중 연결 목록), 정렬). 새로운 컬렉션 유형을 추가할 때 모든 관련 정렬 알고리즘에 액세스하려면 해당 컬렉션이 속하는 "좌표" 범주만 표시하면 됩니다. 이러한 알고리즘 범주는 'Go' 인터페이스와 매우 유사합니다. 여러 유형 매개변수와 추상/연관 유형을 지원하기 위해 Go에서 인터페이스를 확장하려고 합니다. 함수에 임시 유형 매개변수화가 필요하지 않다고 생각합니다.

@dc0d 제네릭을 구성 요소 부분으로 나누려는 시도로 이전에는 "표기법 전문화"를 별도의 부분으로 간주하지 않았습니다. 아마도 유형 제약 조건을 활용하여 DSL을 정의하는 것으로 특징지을 수 있습니다.

나는 당신의 1과 2가 각각 "데이터 구조"와 "알고리즘"이라고 주장할 수 있습니다. 이 용어를 사용하면 서로에 대한 의존도가 높은 경우가 많기 때문에 명확하게 구분하기 어려운 이유가 조금 더 명확해집니다. 그러나 sort.Interface는 Indexable 및 Comparable 요구 사항을 정렬 알고리즘을 구현하는 데 필요한 최소 동작 으로 인코딩하기 때문에 스토리지 와 동작 사이에 선을 그릴 수 있는 위치에 대한 꽤 좋은 예입니다. "swap" 및 "less"(및 len). 그러나 이것은 트리 또는 힙과 같은 더 복잡한 데이터 구조에서 분해되는 것 같습니다. 둘 다 현재 Go 인터페이스로 순수한 동작으로 매핑하기 위해 약간의 비틀림이 필요합니다.

대부분의 교과서 데이터 구조와 알고리즘을 왜곡 없이 비교적 깔끔하게 구현할 수 있지만 DSL을 설계할 만큼 강력하지 않은 인터페이스(또는 그렇지 않은 경우)에 상대적으로 작은 제네릭 추가를 상상할 수 있습니다. 제네릭을 추가하는 모든 문제를 겪을 때 제한된 제네릭 구현으로 자신을 제한하고 싶은지 는 다른 질문입니다.

이진 트리에 대한 @infogulch 좌표 구조는 "분기 좌표"이며, 다른 트리에 대한 등가물이 존재합니다. 그러나 세 가지 주문, 즉 사전 주문, 주문 중 및 사후 주문 중 하나를 통해 트리의 순서를 예측할 수도 있습니다. 이들 중 하나를 결정하면 트리는 양방향 좌표로 처리될 수 있으며 양방향 좌표에 정의된 정렬 알고리즘 제품군은 최적으로 효율적입니다.

요점은 정렬 알고리즘을 액세스 패턴별로 분류한다는 것입니다. 각 액세스 패턴에 대해 유한한 수의 최적 정렬 알고리즘만 있습니다. 이 시점에서 데이터 구조에 대해서는 신경 쓰지 않습니다. 더 복잡한 구조에 대해 이야기하는 것은 요점을 놓치므로 데이터 구조가 아닌 정렬 알고리즘 계열을 분류하고 싶습니다. 당신이 가지고 있는 데이터가 무엇이든 그것을 정렬하기 위해 존재하는 알고리즘 중 하나를 사용해야 할 것입니다. 따라서 문제는 정렬 알고리즘의 사용 가능한 데이터 액세스 패턴 분류 중 어떤 것이 당신이 가지고 있는 데이터 구조에 최적인지가 됩니다.

(임호)

@infogulch

아마도 유형 제약 조건을 활용하여 DSL을 정의하는 것으로 특징지을 수 있습니다.

당신이 맞습니다. 그러나 그것들은 일련의 언어 구조의 일부이기 때문에 IMO에서 이를 DSL이라고 부르는 것은 약간 부정확할 것입니다.

1과 2 ... 종종 매우 의존적입니다.

다시 사실입니다. 그러나 실제 사용이 아직 결정되지 않은 상태에서 컨테이너 유형을 전달해야 하는 경우가 많습니다. 그렇기 때문에 1은 스스로 공부해야 합니다.

sort.Interface 는 _storage_와 _behavior_ 사이에 선을 그릴 수 있는 곳의 꽤 좋은 예입니다.

잘했다;

이것은 더 복잡한 데이터 구조에서 분해되는 것 같습니다

그것은 내 질문 중 하나입니다. 유형 매개 변수를 일반화하고 제한 사항(예 List<T> where T:new, IDisposable )으로 설명하거나 모든 항목(특정 유형의 집합)에 적용할 수 있는 일반화된 _프로토콜_을 제공하는 것입니다.

@keean

문제는 정렬 알고리즘의 사용 가능한 데이터 액세스 패턴 분류 중 사용자가 보유한 데이터 구조에 가장 적합한 분류가 됩니다.

진실. 인덱스로 액세스하는 것은 슬라이스(또는 배열)의 _속성_입니다. 따라서 정렬 가능한 컨테이너(또는 _tree_ 알고리즘이 무엇이든 _tree_ 가능한 컨테이너)에 대한 첫 번째 요구 사항은 _access & mutate(swap)_ 유틸리티를 제공하는 것입니다. 두 번째 요구 사항은 항목이 비교 가능해야 한다는 것입니다. 그것은 당신이 알고리즘이라고 부르는 것에 대해 (저에게) 혼란스러운 부분입니다. 요구 사항은 양쪽(컨테이너 및 유형 매개변수)에서 모두 충족되어야 합니다. 이것이 바로 Go에서 제네릭을 실용적으로 구현하는 것을 상상할 수 없다는 점입니다. 문제의 각 측면은 인터페이스 측면에서 완벽하게 설명될 수 있습니다. 그러나 효과적인 표기법으로 이 두 가지를 결합하는 방법은 무엇입니까?

@dc0d 알고리즘에는 인터페이스가 필요하고 데이터 구조가 제공합니다. 인터페이스가 충분히 강력하다면 이것은 완전한 일반성에 충분합니다. 인터페이스는 유형별로 매개변수화되지만 유형 변수가 필요합니다.

'sort'를 예로 들면 'Ord'는 컨테이너 자체가 아니라 컨테이너에 저장된 유형의 속성입니다. 액세스 패턴은 컨테이너의 속성입니다. 단순 액세스 패턴은 '반복자'이지만 그 이름은 C++에서 유래했으며 Stepanov는 더 복잡한 다차원 컨테이너에 적용할 수 있는 '좌표'를 선호했습니다.

정렬을 정의하려고 하면 다음과 같이 됩니다.

bubble_sort : forall T U I => T U -> T U requires
   ForwardIterator<T>, Readable<T>, Writable<T>,
   Ord<U>,  ValueType(T) == U, Distance type(T) == I

참고: 이 표기법을 제안하는 것이 아니라 다른 관련 작업을 가져오려고 합니다. 요구 사항 절은 Stepanov가 선호하는 구문에 있습니다. 함수 유형은 Haskell에서 가져왔으며 유형 클래스는 이러한 개념의 좋은 구현을 나타낼 수 있습니다.

@keean
아마도 내가 당신을 오해하고 있을지 모르지만, 적어도 지금은 인터페이스가 정의되는 방식으로 알고리즘을 인터페이스로만 제한할 수는 없다고 생각합니다.
예를 들어 sort.Slice를 고려하십시오. 우리는 슬라이스 정렬에 관심이 있으며 모든 슬라이스를 나타내는 인터페이스를 구성하는 방법을 모르겠습니다.

@urandom 컬렉션이 아닌 알고리즘을 추상화합니다. 그래서 "정렬" 알고리즘에 어떤 데이터 액세스 패턴이 있는지 묻고 이를 분류합니다. 따라서 컨테이너가 "슬라이스"인지 여부는 중요하지 않습니다. 우리는 슬라이스에서 수행하려는 모든 작업을 정의하려는 것이 아니라 알고리즘의 요구 사항을 결정하고 인터페이스를 정의하는 데 사용하려고 합니다. 슬라이스는 특별하지 않으며 우리가 작업 세트를 정의할 수 있는 유형 T일 뿐입니다.

따라서 인터페이스는 알고리즘 라이브러리와 관련이 있으며 이러한 알고리즘을 사용할 수 있도록 고유한 데이터 구조에 대해 고유한 인터페이스를 정의할 수 있습니다. 라이브러리는 기본 제공 유형에 대해 미리 정의된 인터페이스와 함께 제공될 수 있습니다.

@keean
그게 당신이 의미하는 것이라고 생각했습니다. 그러나 Go의 맥락에서 이는 아마도 인터페이스가 정의할 수 있는 것에 대한 상당한 점검이 필요하다는 것을 의미할 것입니다. sort.Slice 또는 math.Max 와 같은 항목이 인터페이스를 통해 일반화되도록 하려면 반복 또는 연산자와 같은 다양한 기본 제공 작업이 메서드를 통해 노출되어야 한다고 생각합니다.

따라서 다음 인터페이스(의사 코드)를 지원해야 합니다.

type [T] OrderedIterator interface {
   Len() int
   ValueAt(i int) *T
}

...
package sort

func [T] Slice(s [T]OrderedIterator, func(i, j int) bool) {
   ...
}

그러면 모든 슬라이스에 이러한 메서드가 있습니까?

@urandom 반복자는 컬렉션의 추상화가 아니라 컬렉션에 대한 참조/포인터의 추상화입니다. 예를 들어 순방향 반복자는 단일 메서드 'successor'(때로는 'next')를 가질 수 있습니다. 반복자의 위치에 있는 데이터에 액세스할 수 있다는 것은 반복자의 속성이 아닙니다(그렇지 않으면 반복자의 읽기/쓰기/변경 가능한 특징으로 끝납니다). "참조"를 Readable, Writable 및 Mutable 인터페이스로 별도로 정의하는 것이 가장 좋습니다.

type T ForwardIterator interface {
   type DistanceType D
   successor(x T) T
}

type T Readable interface {
   type ValueType U 
   source(x T) U
}

참고: 'T' 유형은 슬라이스가 아니라 슬라이스의 반복기 유형입니다. 정렬과 같은 함수에 시작 및 끝 반복자를 전달하는 C++ 스타일을 채택하면 이것은 단순한 포인터가 될 수 있습니다.

랜덤 액세스 반복자의 경우 다음과 같이 됩니다.

type T RandomIterator interface {
   type DistanceType D
   setPosition(x DistanceType)
}

따라서 반복자/좌표는 컬렉션 자체가 아니라 컬렉션에 대한 참조의 추상화입니다. iterator를 좌표로, 컬렉션을 맵으로 생각하면 'coordinate'라는 이름이 이것을 아주 잘 표현합니다.

함수 클로저와 익명 함수를 활용하지 않음으로써 Go short를 판매하고 있지 않습니까? Go에서 첫 번째 클래스 유형으로 함수/메서드를 갖는 것이 도움이 될 수 있습니다. 예를 들어 albrow/fo 의 구문을 사용하면 버블 정렬이 다음과 같이 보일 수 있습니다.

type SortableContainer[C,T] struct {
    Less func(C,T,T) bool
    Swap func(C,int,int)
    Next func(C) (T,bool)
}

func (bs *SortableContainer[C,T]) BubbleSort(container C, e1,e2 T) {    
    swapCount := 1
    var item1, item2 T
    item1, ok1 = bs.Next()
    if !ok1 {return}
    item2, ok2 = bs.Next()
    if !ok2 {return}
    for swapCount > 0 {
        swapCount = 0
        for {
            if Less(item2, item1) { 
                bs.Swap(C,item2,item1)
                swapCount += 1
            }
        }
    }
}

모든 실수를 간과하십시오... 완전히 테스트되지 않았습니다!

@mandolyte 이것이 나에게 전달되었는지 확실하지 않습니까? 다중 매개 변수 인터페이스를 사용하고 추상/연관 유형을 사용하여 예제를 제공한다는 점을 제외하고 제가 제안한 것과 귀하의 예 사이에 차이점이 전혀 보이지 않습니다. 명확하게 말하면 다중 매개변수 인터페이스와 완전한 일반성을 위한 추상/연관 유형이 모두 필요하다고 생각합니다. 둘 다 현재 Go에서 지원하지 않습니다.

나는 당신의 인터페이스가 내가 제안한 것보다 덜 일반적이라고 제안하고 싶습니다. 왜냐하면 그들은 정렬 순서, 액세스 패턴 및 액세스 가능성을 동일한 인터페이스에 묶기 때문입니다. , 더 큼), 3가지 액세스 유형(읽기 전용, 쓰기 전용, 변경 가능)과 5가지 액세스 패턴(순방향 단일 패스, 순방향 다중 패스, 양방향, 인덱싱됨, 랜덤)은 11개에 비해 36개 인터페이스로 이어집니다. 우려 사항이 별도로 유지되는 경우.

다음과 같은 추상 유형 대신 다중 매개변수 인터페이스를 사용하여 제안하는 인터페이스를 정의할 수 있습니다.

type I ForwardIterator interface {
   successor(x I) I
}
type R V Readable interface {
   source(x R) V
}
type V Ord interface {
   less(x V, y V) : bool
}

두 개의 유형 매개변수가 필요한 유일한 매개변수는 Readable 인터페이스입니다. 그러나 반복자 객체가 반복되는 객체의 유형을 '포함'할 수 있는 능력을 잃어버렸습니다. 이는 이제 유형 시스템에서 '값' 유형을 이동해야 하고 올바르게 가져와야 하기 때문에 큰 문제입니다. . 이는 좋지 않은 유형 매개변수의 확산으로 이어지고 코딩 오류의 가능성을 높입니다. 또한 컬렉션의 요소를 계산하는 데 필요한 가장 작은 숫자 유형인 iterator에서 'DistanceType'을 정의할 수 있는 능력을 잃게 됩니다. 이는 int8, int16, int32 등에 매핑하여 필요한 유형을 제공하는 데 유용합니다. 오버플로 없이 요소를 계산합니다.

이는 '기능적 종속성' 개념과 밀접하게 관련되어 있습니다. 형식이 다른 형식에 기능적으로 종속되어 있으면 추상/연관 형식이어야 합니다. 두 유형이 독립적인 경우에만 별도의 유형 매개변수여야 합니다.

약간의 문제:

1. 다중 매개변수 인터페이스에 현재 f(x I) 구문을 사용할 수 없습니다. 나는 이 구문이 (유형에 대한 제약인) 인터페이스를 어쨌든 유형과 혼동하는 것을 좋아하지 않습니다.
2. 매개변수화된 유형을 선언하는 방법이 필요합니다.
3. 주어진 유형 매개변수 세트를 사용하여 인터페이스에 대해 연관된 유형을 선언하는 방법이 필요합니다.

@keean 인터페이스 수가 어떻게 또는 왜 그렇게 증가하는지 이해하지 못합니다. 다음은 완전한 작업 예입니다. https://play.folang.org/p/BZa6BdsfBgZ (슬라이스 기반, 일반 컨테이너가 아니므로 Next() 메서드가 필요하지 않음).

하나의 유형 구조체만 사용하고 인터페이스는 전혀 사용하지 않습니다. 나는 모든 익명의 함수와 클로저를 제공해야 합니다. 이 예제에서는 동일한 거품 정렬 알고리즘을 사용하여 정수 조각과 "(x,y)" 점 조각을 모두 정렬합니다. 여기서 원점으로부터의 거리는 Less() 함수의 기초입니다.

어쨌든 유형 시스템에 함수를 갖는 것이 어떻게 도움이 될 수 있는지 보여주고 싶었습니다.

@mandolyte 제안하신 내용을 제가 잘못 이해한 것 같습니다. 나는 당신이 말하는 "folang"이 이미 Go에 추가된 멋진 기능적 프로그래밍 기능을 가지고 있다는 것을 알았습니다. 구현한 것은 기본적으로 다중 매개변수 유형 클래스를 손으로 연결하는 것입니다. 함수 사전으로 알려진 것을 정렬 함수에 전달하고 있습니다. 이것은 인터페이스가 암시적으로 수행하는 작업을 명시적으로 수행합니다. 이러한 종류의 기능은 다중 매개변수 인터페이스 및 관련 유형 이전에 필요할 수 있지만 결국 모든 사전을 전달하는 데 문제가 발생합니다. 인터페이스가 더 깨끗하고 읽기 쉬운 코드를 제공한다고 생각합니다.

슬라이스 정렬은 해결된 문제입니다. 다음은 go-li(golang 개선) 언어 를 사용하여 구현된 슬라이스 quicksort.go 에 대한 코드입니다.

func main(){
    var data = []int{5,3,1,8,9}

    Sort(data, func(a *int, b *int) int {
        return *a - *b
    })

    fmt.Println(data)
}

놀이터 에서 이것을 실험할 수 있습니다.

전체 예제를 플레이그라운드에 붙여넣을 수 있습니다. 퀵소트 패키지 가져오기가 플레이그라운드 에서 작동하지 않기 때문입니다.

@go-li 슬라이스를 정렬할 수 있다고 확신합니다. 정렬할 수 없다면 약간 가난할 것입니다. 요점은 일반적으로 동일한 코드로 모든 선형 컨테이너를 정렬할 수 있기를 원하므로 정렬하는 컨테이너(데이터 구조)가 무엇이든 상관없이 정렬 알고리즘을 한 번만 작성하면 됩니다. 내용이다.

이렇게 할 수 있을 때 표준 라이브러리는 보편적인 정렬 기능을 제공할 수 있으며 아무도 다시 작성할 필요가 없습니다. 여기에는 두 가지 이점이 있습니다. 올바른 정렬 알고리즘을 작성하는 것이 생각보다 어렵기 때문에 실수가 적습니다. Stepanov는 대부분의 프로그래머가 '최소'와 '최대' 쌍을 올바르게 정의할 수 없다는 예를 사용하므로 우리는 어떤 희망을 가져야 할까요? 더 복잡한 알고리즘에 적합합니다. 다른 이점은 각 정렬 알고리즘에 대한 정의가 하나만 있는 경우 명확성 또는 성능을 개선하면 이를 사용하는 모든 프로그램에 이점이 있다는 것입니다. 사람들은 모든 다른 데이터 유형에 대해 자체 알고리즘을 작성하는 대신 공통 알고리즘을 개선하는 데 시간을 할애할 수 있습니다.

@keean
이전 토론과 관련된 또 다른 질문입니다. iterable에서 항목을 변경하고 항목이 원래 항목과 다른 유형일 수 있는 새로운 구체적인 iterable 유형을 반환하는 매핑 함수를 어떻게 정의할 수 있는지 알 수 없습니다.

그리고 그러한 함수의 사용자는 다른 인터페이스가 아닌 구체적인 유형이 반환되기를 원할 것이라고 상상합니다.

@urandom 안전하지 않은 '그 자리에서' 수행하려는 것이 아니라고 가정하고 원하는 것은 한 유형의 '읽기 반복기'와 다른 유형의 '쓰기 반복기'가 있는 맵 함수입니다. 다음과 같이 정의할 수 있습니다.

map<I, O, U>(first I, last I, out O, fn U) requires
   ForwardIterator<I>, Readable<I>,
   ForwardIterator<O>, Writable<O>,
   UnaryFunction<U>, Domain(U) == ValueType(I), Codomain(U) == ValueType(O)

명확성을 위해 "ValueType"은 "Readable" 및 "Writable" 인터페이스의 연관된 유형이고, "Domain" 및 "Codomain"은 "UnaryFunction" 인터페이스의 연관된 유형입니다. 컴파일러가 "UnaryFunction"과 같은 데이터 유형에 대한 인터페이스를 자동으로 파생할 수 있다면 분명히 많은 도움이 됩니다. 이러한 종류의 리플렉션은 반사처럼 보이지만 그렇지 않으며 정적 유형을 사용하여 컴파일 타임에 모두 발생합니다.

@keean 현재 Go의 인터페이스 컨텍스트에서 읽기 가능 및 쓰기 가능 제약 조건을 모델링하는 방법은 무엇입니까?

내 말은, A 유형이 있고 B 유형으로 변환하려는 경우 해당 UnaryFunction의 서명은 func (input A) B 가 됩니다. 하지만 어떻게 그럴 수 있습니까? 인터페이스만 사용하여 모델링하고 일반 map (또는 filter , reduce 등)을 모델링하여 유형의 파이프라인을 유지하는 방법은 무엇입니까?

@geovanisouza92 "Type Families"는 유형 시스템에서 직교 메커니즘으로 구현된 다음 Haskell에서 수행되는 것처럼 인터페이스 구문에 통합될 수 있으므로 잘 작동할 것이라고 생각합니다.

유형 패밀리는 유형에 대한 제한된 기능(매핑)과 같습니다. 인터페이스 구현이 유형별로 선택되므로 각 구현에 대한 유형 매핑을 제공할 수 있습니다.

따라서 다음을 정의하면:

ValueType MyIntArrayIterator -> Int

함수는 조금 더 까다롭지만 함수에는 유형이 있습니다. 예를 들면 다음과 같습니다.

fn(x : Int) Float

우리는 이 유형을 쓸 것입니다:

Int -> Float

-> 는 단지 중위 유형 생성자일 뿐이라는 것을 깨닫는 것이 중요합니다. 예를 들어 Array에 대한 '[]'는 유형 생성자이므로 이것을 쉽게 작성할 수 있습니다.

Fn Int Float
Or
Fn<Int, Float>

유형 구문에 대한 선호도에 따라 다릅니다. 이제 다음을 정의하는 방법을 명확하게 알 수 있습니다.

Domain  Fn<Int, Float> -> Int
Codomain Fn<Int, Float> -> Float

이제 이러한 모든 정의를 손으로 제공할 수 있지만 컴파일러에서 쉽게 파생할 수 있습니다.

이러한 유형 패밀리가 주어지면 위에서 제공한 맵의 정의는 제네릭을 인스턴스화하기 위해 유형 IO 및 U만 필요하다는 것을 알 수 있습니다. 다른 모든 유형은 기능적으로 이들 유형에 종속되기 때문입니다. 이러한 유형이 인수에 의해 직접 제공되는 것을 볼 수 있습니다.

@keean님, 감사합니다.

이것은 내장/사전 정의된 함수에 대해 잘 작동합니다. 사용자 정의 함수나 사용자 영역 라이브러리에도 동일한 개념이 적용된다는 말씀이신가요?

일부 오류 컨텍스트의 경우 해당 "유형 제품군"이 런타임에 수행됩니까?

빈 인터페이스, 유형 스위치 및 반사는 어떻습니까?

편집: 나는 단지 궁금해서 불평하지 않습니다.

@giovanisouza92 글쎄, 아무도 Go가 제네릭을 갖도록 약속하지 않았으므로 회의론이 예상됩니다. 제 접근 방식은 제네릭을 수행하려는 경우 올바르게 수행해야 한다는 것입니다.

내 예에서 '지도'는 사용자 정의입니다. 특별한 것은 없으며 함수 내에서 바로 지금 Go에서 하는 것처럼 해당 유형에 필요한 인터페이스의 메서드를 사용하기만 하면 됩니다. 유일한 차이점은 여러 인터페이스를 충족하기 위해 유형을 요구할 수 있고 인터페이스에는 여러 유형 매개변수가 있을 수 있으며(지도 예제에서는 이것을 사용하지 않지만) 연관된 유형도 있다는 것입니다(유형 동일성 '=='과 같은 유형에 대한 제약 조건도 있음) 그러나 이것은 Prolog 동등성과 유사하며 유형을 통합합니다). 이것이 함수에 필요한 인터페이스를 지정하기 위한 다른 구문이 있는 이유입니다. 또 다른 중요한 차이점이 있습니다.

f(x I, y I) requires ForwardIterator<I>

대

f(x ForwardIterator, y ForwardIterator)

후자의 'x'와 'y'는 ForwardIterator 인터페이스를 만족하는 다른 유형일 수 있다는 점에 유의하십시오. 반면 전자의 구문에서는 'x'와 'y'가 모두 동일한 유형이어야 합니다(순방향 반복자를 만족함). 이것은 함수가 과소제약되지 않도록 하고 컴파일 중에 구체 유형이 훨씬 더 많이 전파되도록 하는 데 중요합니다.

우리는 단지 인터페이스의 개념을 확장하고 있기 때문에 유형 스위치와 리플렉션과 관련하여 아무 것도 변경되지 않는다고 생각합니다. go에는 런타임 유형 정보가 있으므로 Haskell과 같은 문제에 빠지지 않고 존재 유형이 필요합니다.

Go, 런타임 다형성 및 유형 패밀리에 대해 생각할 때, 연관된 모든 유형을 런타임 시 느린 인터페이스로 처리해야 하는 것을 피하기 위해 유형 패밀리 자체를 인터페이스로 제한하고 싶을 것입니다.

따라서 이러한 생각에 비추어 위의 제안을 수정하여 인터페이스를 선언할 때 해당 인터페이스의 모든 구현이 해당 인터페이스를 충족하는 관련 유형을 제공해야 하는 각 관련 유형에 대한 인터페이스/유형을 선언하도록 하겠습니다. 그런 식으로 우리는 빈 인터페이스에서 유형 전환하지 않고도 런타임에 관련 유형에서 해당 인터페이스의 모든 메소드를 호출하는 것이 안전하다는 것을 알 수 있습니다.

@keean
토론을 진행하기 위해 내가 여기에서 발명되지 않은 증후군이 진행 중인 것과 유사하다고 느끼는 오해를 분명히 하겠습니다.

양방향 반복자( T 구문 func (*T) *[2]*T )의 유형은 go-li 구문에서 func (*) *[2]* 입니다. 즉, 어떤 유형에 대한 포인터를 취하고 동일한 유형의 다음 및 이전 요소에 대한 두 포인터에 대한 포인터를 반환합니다. 이중 연결 목록 에서 사용하는 기본적인 구체적인 기본 유형입니다.

이제 내가 foreach 일반 함수라고 부르는 map이라고 부르는 것을 작성할 수 있습니다. 이것은 연결 목록뿐만 아니라 양방향 반복자를 노출하는 모든 것에 대해 작동한다는 것을 실수하지 마십시오!

func Foreach(link func(*) *[2]*, list **, direction byte, f func(*)) {

    if nil == *list {
        return
    }

    var end *
    end = *list

    var e *
    e = (*link(*list))[direction]
    f(end)

    for (e != end) && ((*link(e))[direction] != nil) {
        var newe = (*link(e))[direction]
        f(e)
        e = newe
    }
    return
}

Foreach는 두 가지 방법으로 사용할 수 있습니다. 목록 또는 컬렉션 요소에 대한 for 루프와 같은 반복에서 람다와 함께 사용합니다.

const forward = 1
const backwards = 0
Foreach(iterator, collection, forward, func(element *element_type){
    // do something with every element
})

또는 함수를 모든 컬렉션 요소에 기능적으로 매핑하는 데 사용할 수 있습니다.

Foreach(iterator, collection, backwards, function_to_be_mapped_on_elements)

양방향 반복자는 물론 go 1의 인터페이스를 사용하여 모델링할 수도 있습니다.
interface Iterator { Iter() [2]Iterator } 기본 유형을 래핑("박스")하려면 인터페이스를 사용하여 모델링해야 합니다. 반복자 사용자는 특정 컬렉션 요소를 찾고 방문하기를 원하면 알려진 유형을 주장합니다. 이것은 잠재적으로 컴파일 시간이 안전하지 않습니다.

다음에 설명하는 것은 레거시 접근 방식과 제네릭 기반 접근 방식의 차이점입니다.

func modern(x func  (*) *[2]*, y func  (*) *[2]*){}

이 접근 방식은 컴파일 시간 유형이 두 컬렉션의 기본 유형이 동일한지, 즉 반복자가 실제로 동일한 구체적인 유형을 반환하는지 여부를 확인합니다.

func modern_T_syntax<T>(x func  (*T) *[2]*T, y func  (*T) *[2]*T){}

위와 같지만 친숙한 T를 사용하는 것은 유형 자리 표시자 구문을 의미합니다.

func legacy(x Iterator, y Iterator){}

이 경우 사용자는 예를 들어 정수 연결 목록을 x로, 부동 연결 목록을 y로 전달할 수 있습니다. 이로 인해 잠재적인 런타임 오류, 패닉 또는 기타 내부 결맞음이 발생할 수 있지만 이는 모두 레거시가 두 반복자로 수행할 작업에 따라 다릅니다.

이제 오해. 반복자를 수행하고 해당 반복자를 정렬하기 위해 일반 정렬을 수행하는 것이 올바른 방법이라고 주장합니다. 그렇게 하는 것은 정말 나쁜 일이 될 것입니다. 여기에 이유가 있습니다.

Iterator와 Linked List는 동전의 양면입니다. 증명: 반복자를 노출하는 모든 컬렉션은 단순히 자신을 연결 목록으로 광고합니다. 정렬해야 한다고 가정해 보겠습니다. 무엇을 합니까?

분명히 코드베이스에서 연결 목록을 삭제하고 이진 트리로 대체합니다. 또는 제안한 대로 avl, red-black과 같은 균형 잡힌 검색 트리를 사용하고 싶다면 Ian et al이 몇 년 전에 제안했는지 모르겠습니다. 여전히 이것은 golang에서 일반적으로 수행되지 않았습니다. 이제 가야 할 길입니다.

또 다른 해결책은 반복자를 통한 O(N) 시간 루프에서 요소에 대한 포인터를 []*T 로 표시된 일반 포인터 조각으로 수집 하고 잘못된 조각 정렬을 사용하여 해당 일반 포인터를 정렬하는 것입니다.

다른 사람들의 아이디어에 기회를 주세요

@go-li 발명되지 않은 증후군을 피하려면 Alex Stepanov가 제네릭 프로그래밍을 거의 발명했기 때문에 정의에 대해 살펴봐야 합니다. 다음은 Stepanov의 "프로그래밍 요소" 페이지 111에서 가져온 정의 방법입니다.

Bidirectional iterator<T> =
    ForwardIterator<T>
/\ predecessor : T -> T
/\ predecessor takes constant time
/\ (forall i in T) successor(i) is defined =>
        predecessor(successor(i)) is defined and equals i
/\ (forall i in T) predecessor(i) is defined =>
        successor(predecessor(i)) is defined and equals i

이것은 ForwardIterator의 정의에 따라 다릅니다.

ForwardIterator<T> =
    Iterator<T>
/\ regular_unary_function(successor)

따라서 본질적으로 우리는 successor 함수와 predecessor 함수를 선언하는 인터페이스와 함께 그들이 유효하기 위해 준수해야 하는 몇 가지 공리를 가지고 있습니다.

legacy 에 관해서는 레거시가 잘못될 것이 아니라 현재 Go에서는 분명히 잘못되지 않지만 컴파일러는 최적화 기회를 놓치고 있으며 유형 시스템은 구체적인 유형을 더 전파할 기회를 놓치고 있습니다. 또한 프로그래머가 의도를 정확하게 지정하는 데 제한이 있습니다. 예를 들면 전달된 유형을 정확히 반환하는 ID 함수가 있습니다.

id(x T) T

아마도 매개변수 유형과 보편적으로 수량화된 유형의 차이점을 언급할 가치가 있을 것입니다. 매개변수 유형은 id<T>(x T) T 인 반면 보편적으로 수량화된 유형은 id(x T) T 입니다(일반적으로 이 경우 forall T ). 매개변수 유형을 사용하면 유형 시스템에 id 에 대한 호출 사이트에서 제공되는 T 유형이 있어야 하며, 컴파일이 완료되기 전에 T가 구체적인 유형과 통합되는 한 보편적 수량화는 필요하지 않습니다. 이를 이해하는 또 다른 방법은 매개변수 함수는 유형이 아니라 유형에 대한 템플릿이며 T가 구체적인 유형으로 대체된 후에만 유효한 유형이라는 것입니다. 보편적으로 수량화된 함수 id 에는 실제로 Int 처럼 컴파일러에 의해 전달될 수 있는 forall T . T -> T 유형이 있습니다.

@고리

분명히 코드베이스에서 연결 목록을 삭제하고 이진 트리로 대체합니다. 또는 제안한 대로 avl, red-black과 같은 균형 잡힌 검색 트리를 사용하고 싶다면 Ian et al이 몇 년 전에 제안했는지 모르겠습니다. 여전히 이것은 golang에서 일반적으로 수행되지 않았습니다. 이제 가야 할 길입니다.

데이터 구조를 정렬한다고 해서 데이터를 정렬할 필요가 전혀 없는 것은 아닙니다.

여기에서 발명되지 않은 증후군을 피하려면 Alex Stepanov가 제네릭 프로그래밍을 거의 발명했기 때문에 정의에 대해 살펴보아야 합니다.

나는 제네릭 프로그래밍이 C++에 의해 발명되었다는 주장에 이의를 제기할 것입니다. Liskov 등을 읽으십시오. 실제로 작동하는 일반 프로그래밍의 초기 모델(유형 안전, 모듈식, 코드 팽창 없음)을 보려면 1977 CACM 논문: https://dl.acm.org/citation.cfm?id=359789 (섹션 4 참조) )

이 토론을 중단하고 golang 팀(russ)이 일부 블로그 게시물을 작성한 다음 솔루션을 구현하기를 기다려야 한다고 생각합니다 👍(vgo 참조) 그들은 그냥 할 것입니다 🎉

https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html

이 이야기가 다른 사람들에게 경고가 되기를 바랍니다. Go 프로젝트에 상당한 기여를 하는 데 관심이 있다면 독립적인 실사가 아무리 많아도 핵심 팀에서 시작하지 않은 디자인을 보상할 수 없습니다.

이 스레드는 핵심 팀이 커뮤니티와 함께 ​​솔루션을 찾는 데 적극적으로 참여하는 데 관심이 없는 방법을 보여줍니다.

하지만 결국 또 스스로 해결을 할 수 있다면 난 그걸로 괜찮아 👍

@andrewcmyers 아마도 "발명"은 약간의 확장이었으며, 나중에 Ada의 일부 일반 라이브러리에서 Stepanov와 함께 작업한 1971년 David Musser와 비슷할 것입니다.

Elements of Programming은 C++에 대한 책이 아닙니다. 예제는 C++에 있을 수 있지만 이는 매우 다른 것입니다. 나는 이 책이 어떤 언어로든 제네릭을 구현하고자 하는 모든 사람들에게 꼭 필요한 책이라고 생각한다. 스테파노프를 무시하기 전에 그 책이 실제로 무엇에 관한 것인지 알아보기 위해 책을 읽어야 합니다.

이 문제는 이미 GitHub 확장성의 한계 아래에서 긴장하고 있습니다. Go 제안에 대한 구체적인 문제에 초점을 맞춘 토론을 여기에서 유지하십시오.

Go가 C++ 경로를 따르는 것은 불행한 일입니다.

@andrewcmyers 예, 전적으로 동의합니다. 구문 제안이나 작업을 제대로 수행하기 위한 벤치마크로 C++를 사용하지 마십시오. 대신 영감을 얻으려면 D를 살펴보십시오 .

@nomad-software

나는 D를 매우 좋아하지만 D가 제공하는 강력한 컴파일 타임 메타 프로그래밍 기능이 go에 필요합니까?

석기 시대에서 비롯된 C++의 템플릿 구문도 마음에 들지 않습니다.

하지만 일반적인 ParametricType은 어떻습니까?Java 또는 C#에서 찾은 표준, 필요한 경우 ParametricType으로 이를 오버로드할 수도 있습니다.

그리고 더 나아가, 저는 뱅 기호가 있는 D의 템플릿 호출 구문이 마음에 들지 않습니다. 뱅 기호는 오늘날 함수의 매개변수에 대한 변경 가능하거나 변경할 수 없는 액세스를 나타내는 데 사용됩니다.

@nomad-software 나는 C++ 구문이나 템플릿 메커니즘이 제네릭을 수행하는 올바른 방법이라고 제안한 것이 아닙니다. Stepanov가 정의한 "개념"은 유형을 대수학으로 취급하며, 이는 제네릭을 수행하는 매우 올바른 방법입니다. 이것이 어떻게 보이는지 보려면 Haskell 유형 클래스를 살펴보십시오. 무슨 일이 일어나고 있는지 이해한다면 Haskell 유형 클래스는 의미적으로 C++ 템플릿 및 개념에 매우 가깝습니다.

따라서 C++ 구문을 따르지 않는 경우 +1, 안전하지 않은 형식의 템플릿 시스템을 구현하지 않는 경우 +1 :-)

@keean D 구문을 사용하는 이유는 <,> 를 완전히 피하고 컨텍스트 없는 문법을 준수하기 위함입니다. 이것은 D를 영감으로 사용하는 내 요점의 일부입니다. <,> 는 제네릭 매개변수의 구문에 대해 정말 나쁜 선택입니다.

@nomad-software 위에서 지적했듯이(현재 숨겨진 주석에서) 매개변수 유형에 대한 유형 매개변수를 지정해야 하지만 보편적으로 수량화된 유형에는 지정하지 않아야 합니다(따라서 Rust와 Haskell의 차이점은 유형을 처리하는 방식이 실제로 다릅니다. 유형 시스템에서). 또한 C++ 개념 == Haskell 유형 클래스 == 최소한 개념적 수준에서 인터페이스를 이동합니다.

D 구문이 정말 바람직합니까?

auto add(T)(T lhs, T rhs) {
    return lhs + rhs;

이것이 C++/Java/Rust 스타일보다 나은 이유:

T add<T>(T lhs, T rhs) {
    return lhs + rhs;
}

또는 스칼라 스타일:

T add[T](T lhs, T rhs) {
    return lhs + rhs;
}

유형 매개변수의 구문에 대해 몇 가지 생각을 했습니다. 나는 구문 분석을 매우 까다롭게 만들고 도구 개발을 방해하기 때문에 C++ 및 Java에서 "꺾쇠 괄호"의 팬이 된 적이 없습니다. 대괄호는 실제로 고전적인 선택입니다(CLU, System F 및 기타 매개변수 다형성이 있는 초기 언어에서).

그러나 Go의 구문은 이미 너무 간결하기 때문에 상당히 까다롭습니다. 대괄호 또는 괄호를 기반으로 하는 가능한 구문은 꺾쇠 괄호로 인해 도입된 것보다 문법적 모호성을 더욱 악화시킵니다. 그래서 내 성향에도 불구하고 꺾쇠 괄호가 실제로 Go에 가장 적합한 선택인 것 같습니다. (물론 모호함을 생성하지 않는 실제 꺾쇠괄호(⟨⟩)도 있지만 유니코드 문자를 사용해야 합니다).

물론 유형 매개변수에 사용되는 정확한 구문은 의미 체계 를 올바르게 이해하는 것보다 덜 중요합니다. 그런 점에서 C++ 언어는 나쁜 모델입니다. Genus (PLDI 2015) 및 Familia (OOPSLA 2017)의 제네릭에 대한 내 연구 그룹의 작업은 유형 클래스를 확장하고 인터페이스와 통합하는 또 다른 접근 방식을 제공합니다.

@andrewcmyers 나는 두 논문 모두 흥미롭다고 생각하지만, Genus는 객체 지향이고 Go는 그렇지 않으며 Familia는 하위 유형 지정과 매개변수 다형성을 통합하고 Go는 둘 다 가지고 있지 않기 때문에 Go에 대한 좋은 방향이 아니라고 말하고 싶습니다. Go는 단순히 매개변수적 다형성이나 보편적인 수량화를 채택해야 하며 하위 유형 지정이 필요하지 않으며 내 생각에는 하위 유형이 없는 것이 더 나은 언어라고 생각합니다.

Go는 객체 지향이 필요하지 않고 하위 유형이 필요하지 않은 제네릭을 찾아야 한다고 생각합니다. Go는 이미 인터페이스를 가지고 있는데 제네릭을 위한 훌륭한 메커니즘이라고 생각합니다. Go 인터페이스 == C++ 개념 == Haskell 유형 클래스라는 것을 알 수 있다면 'Go'의 풍미를 유지하면서 제네릭을 추가하는 방법은 여러 유형 매개변수를 사용하도록 인터페이스를 확장하는 것입니다. 인터페이스의 관련 유형과 비슷하지만 별도의 확장이 될 수 있으므로 여러 유형 매개 변수를 수락하는 데 도움이 됩니다. 이것이 핵심 변경 사항이지만 이를 가능하게 하려면 함수 시그니처의 인터페이스에 대한 '대체' 구문이 필요하므로 전체 꺾쇠 괄호 구문이 들어오는 인터페이스에 여러 유형 매개변수를 가져올 수 있습니다. .

Go 인터페이스는 유형 클래스가 아니라 유형일 뿐이지만 인터페이스를 유형 클래스와 통합하는 것이 Familia가 보여주는 방법입니다. Genus와 Familia의 메커니즘은 완전히 객체 지향적인 언어에 묶여 있지 않습니다. Go 인터페이스는 이미 Go를 중요한 방식으로 "객체 지향"으로 만들고 있으므로 아이디어를 약간 단순화된 형태로 적용할 수 있다고 생각합니다.

@andrewcmyers

Go 인터페이스는 유형 클래스가 아니라 유형일 뿐입니다.

그것들은 다형성을 허용하기 때문에 나에게 유형처럼 행동하지 않습니다. Addable[]과 같은 다형성 배열의 객체는 여전히 실제 유형(런타임 리플렉션으로 볼 수 있음)을 가지므로 단일 매개변수 유형 클래스와 똑같이 동작합니다. 유형 서명에서 유형 대신에 배치된다는 사실은 단순히 유형 변수를 생략한 약식 표기법입니다. 표기법과 의미를 혼동하지 마십시오.

f(x : Addable) == f<T>(x : T) requires Addable<T>

이 ID는 물론 단일 매개변수 인터페이스에만 유효합니다.

인터페이스와 단일 매개변수 유형 클래스 간의 유일한 중요한 차이점은 인터페이스가 로컬로 정의된다는 것입니다. 그러나 이는 Haskell이 해당 유형 클래스에 대해 가지고 있는 전역 일관성 문제를 피하기 때문에 유용합니다. 이것이 디자인 스페이스의 흥미로운 포인트라고 생각합니다. 다중 매개변수 인터페이스는 로컬이라는 이점과 함께 다중 매개변수 유형 클래스의 모든 기능을 제공합니다. Go 언어에 상속이나 하위 유형 지정을 추가할 필요가 없습니다(이것이 OO를 정의하는 두 가지 핵심 기능이라고 생각합니다).

임호:

여전히 기본 유형을 사용하는 것이 유형 제한을 표현하는 전용 DSL보다 선호됩니다. fmt.Stringer 인터페이스를 만족시키는 모든 유형을 허용하는 일반 함수인 f(s T fmt.Stringer) 함수를 갖는 것과 같습니다.

이렇게 하면 다음과 같은 일반 기능을 가질 수 있습니다.

func add(a, b T int) T int {
    return a + b
}

이제 add() 함수는 $ int + 연산자를 지원하는 모든 유형의 T $에서 작동합니다.

@dc0d 현재 Go 구문을 보면 매력적으로 보인다는 데 동의합니다. 그러나 제네릭에 필요한 모든 제약 조건을 나타낼 수 없다는 점에서 '완벽'하지 않으며, 이를 더 확장하려는 노력이 계속될 것입니다. 이는 단순성의 목표와 상충되는 것으로 생각되는 다양한 구문의 확산을 초래할 것입니다. 제 생각에는 단순함이 단순하지 않고 가장 단순하면서도 필요한 표현력을 제공해야 한다는 것입니다. 현재 Go의 일반적인 표현력의 주요 한계는 다중 매개변수 인터페이스의 부족입니다. 예를 들어 Collection 인터페이스는 다음과 같이 정의할 수 있습니다.

type T U Collection interface {
   member(c T, v U) Bool
   insert(c T, v U) T
}

이게 말이 됩니까? 우리는 컬렉션과 같은 것에 대한 인터페이스를 작성하고 싶습니다. 따라서 문제는 함수에서 이 인터페이스를 어떻게 사용하느냐 하는 것입니다. 내 제안은 다음과 같습니다.

func[T, U] f(c T, e U) (Bool, T) requires Collection[T, U] {
   a := member(c, e)
   d := insert(c, e)
   return a, d
}

구문은 단지 제안일 뿐입니다. 하지만 이러한 개념을 언어로 표현할 수 있는 한 구문이 무엇인지는 그다지 신경 쓰지 않습니다.

@keean 구문에 전혀 신경 쓰지 않는다고 말하면 정확하지 않습니다. 그러나 요점은 모든 일반 매개변수에 대해 기본 유형을 갖는 것을 강조하는 것이었습니다. 그런 의미에서 인터페이스에 대해 제공된 예제는 다음과 같습니다.

type Collection interface (T interface{}, U interface{}) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

이제 (T interface{}, U interface{}) 부분은 제약 조건을 정의하는 데 도움이 됩니다. 예를 들어 멤버가 fmt.Stringer 를 충족하도록 되어 있는 경우 정의는 다음과 같습니다.

type Collection interface (T fmt.Stringer, U fmt.Stringer) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

@dc0d 이것은 둘 이상의 유형 매개 변수로 제한하려는 의미에서 다시 제한적입니다. 다음을 고려하십시오.

type OrderedCollection[T, U] interface
   requires Collection[T, U], Ord[U] {...}

나는 당신이 매개변수 배치와 함께 어디에서 왔는지 알 수 있다고 생각합니다. 당신은 다음을 가질 수 있습니다:

type OrderedCollection interface(T, U)
   requires Collection(T, U), Ord(U) {...}

내가 말했듯이, 나는 대부분의 구문에 익숙해질 수 있으므로 구문에 너무 집착하지 않습니다. 위에서 나는 다중 매개변수 인터페이스에 대해 괄호 '()'를 선호한다고 생각합니다.

@keean heap.Interface 인터페이스를 생각해 봅시다. 표준 라이브러리의 현재 정의는 다음과 같습니다.

type Interface interface {
    sort.Interface
    Push(x interface{}) // add x as element Len()
    Pop() interface{}   // remove and return element Len() - 1.
}

이제 기본 유형을 사용하여 일반 인터페이스로 다시 작성해 보겠습니다.

type Interface interface (T interface{}) {
    sort.Interface
    Push(x T) // add x as element Len()
    Pop() T   // remove and return element Len() - 1.
}

이것은 Go 1.x 코드 시리즈를 중단시키지 않습니다. 한 가지 구현은 Type Alias ​​Rebinding에 대한 제 제안입니다. 그러나 더 나은 구현이 있을 수 있다고 확신합니다.

기본 유형을 사용하면 Go 1.x 스타일 코드와 함께 사용할 수 있는 일반 코드를 작성할 수 있습니다. 그리고 표준 라이브러리는 아무 것도 손상시키지 않고 일반 라이브러리가 될 수 있습니다. 그것은 큰 승리 IMO입니다.

@dc0d 그래서 점진적인 개선을 제안하고 있습니까? 당신이 제안하는 것은 점진적인 개선으로 나에게 괜찮아 보이지만 여전히 일반적인 표현력이 제한적입니다. "Collection" 및 "OrderedCollection" 인터페이스를 어떻게 구현하시겠습니까?

여러 부분 언어 확장이 가능한 가장 간단한 방법으로 완전한 솔루션을 구현하는 것보다 더 복잡한 최종 제품(여러 대체 구문 포함)으로 이어질 수 있다는 점을 고려하십시오.

@keean requires Collection[T, U], Ord[U] 부분이 이해가 되지 않습니다. 유형 매개변수 T 및 U 를 어떻게 제한합니까?

@dc0d 함수에서와 같은 방식으로 작동하지만 모든 것에 적용됩니다. 따라서 OrderedCollection인 TU 유형의 쌍에 대해 TU도 Collection의 인스턴스이고 U가 Ord여야 합니다. 따라서 OrderedCollection을 사용하는 모든 곳에서 Collection 및 Ord의 메서드를 적절하게 사용할 수 있습니다.

우리가 미니멀리스트라면 이것들은 필요하지 않습니다. 예를 들어 다음과 같이 필요한 함수 유형에 추가 인터페이스를 포함할 수 있기 때문입니다.

type OrderedCollection interface(T, U)
{
   first(c T) U
}

func[T] first(c T[]) T requires Collection(T[], T), Ord T
{...}

func[T] f(c T[]) requires OrderedCollection(T[], T), Collection(T[], T), Ord(T)
{...}

그러나 이것은 더 읽기 쉽습니다:

type OrderedCollection interface(T, U) 
   requires Collection(T, U), Ord(U)
{
   first(c T) U
}

func[T] first(c T[]) T
{...}

func[T] f(c T[]) requires OrderedCollection(T[], T)
{...}

@keean (IMO) 유형 매개변수에 대한 필수 기본값이 있는 한 행복합니다. 그렇게 하면 Go 1.x 코드 시리즈와 하위 호환성을 유지할 수 있습니다. 그것이 내가 만들려고 했던 요점이다.

@keean

Go 인터페이스는 유형 클래스가 아니라 유형일 뿐입니다.

그것들은 다형성을 허용하기 때문에 나에게 유형처럼 행동하지 않습니다.

예, 하위 유형 다형성 을 허용합니다. Go에는 인터페이스 유형을 통한 하위 유형이 있습니다. 명시적으로 선언된 하위 유형 계층은 없지만 대체로 직교합니다. Go가 완전히 객체 지향적이지 않은 이유는 상속이 없기 때문입니다.

또는 인터페이스를 유형 클래스의 실존적으로 수량화된 응용 프로그램으로 볼 수 있습니다. 나는 그것이 당신이 염두에두고 있다고 믿습니다. 그것이 Genus와 Familia에서 우리가 한 일입니다.

@andrewcmyers

예, 하위 유형 다형성을 허용합니다.

내가 아는 한 공분산이나 반공변은 없습니다. 이것은 이것이 하위 유형이 아니라는 것을 강력하게 말합니다. 다형성 유형 시스템은 불변하므로 Go가 이 모델에 더 가깝고 인터페이스를 단일 매개변수 유형 클래스로 취급하는 것이 Go의 단순성에 더 가깝습니다. 공분산과 반공변이 없다는 것은 제네릭에 큰 이점입니다. C#과 같은 언어에서 이러한 것들이 만들어내는 혼란을 보세요.

https://docs.microsoft.com/en-us/dotnet/standard/generics/covariance-and-contravariance

나는 Go가 이런 종류의 복잡성을 완전히 피해야 한다고 생각합니다. 나에게 이것은 우리가 동일한 유형 시스템에서 제네릭과 서브타이핑을 원하지 않는다는 것을 의미합니다.

또는 인터페이스를 유형 클래스의 실존적으로 수량화된 응용 프로그램으로 볼 수 있습니다. 나는 그것이 당신이 염두에두고 있다고 믿습니다. 그것이 Genus와 Familia에서 우리가 한 일입니다.

Go는 런타임에 유형 정보를 가지고 있기 때문에 실존적 수량화가 필요하지 않습니다. Haskell에서 유형은 (네이티브 'C' 유형과 같이) 박싱되지 않습니다. 즉, 존재 컬렉션에 무언가를 넣으면 내용 유형을 (쉽게) 복구할 수 없으며, 우리가 할 수 있는 일은 제공된 인터페이스(유형 클래스 ). 이것은 원시 데이터와 함께 인터페이스에 대한 포인터를 저장하여 구현됩니다. Go에서는 데이터 유형이 대신 저장되며 데이터는 'Boxed'입니다(C# boxed 및 unboxed 데이터에서와 같이). 이와 같이 Go는 데이터와 함께 저장된 인터페이스에만 국한되지 않습니다. 왜냐하면 'Reflection'을 구현함으로써 Haskell에서만 가능한 컬렉션의 데이터 유형을 복구할 수 있기 때문입니다. typeclass (데이터를 꺼내는 것이 어색하지만 문자열과 같이 유형과 데이터를 직렬화한 다음 존재 상자 외부에서 역직렬화하는 것이 가능합니다). 그래서 내가 가지고 있는 결론은 Haskell이 'Reflection' 유형 클래스를 내장으로 제공했다면 Go 인터페이스가 유형 클래스와 똑같이 동작한다는 것입니다. 따라서 존재 상자가 없으며 컬렉션의 내용에 대해 여전히 대소문자를 구분할 수 있지만 인터페이스는 유형 클래스와 정확히 동일하게 작동합니다. Haskell과 Go의 차이점은 boxed와 unboxed 데이터의 의미에 있으며 인터페이스는 단일 매개변수 유형 클래스입니다. 실제로 'Go'가 인터페이스를 유형으로 취급할 때 실제로 수행하는 작업은 다음과 같습니다.

Addable[] == exists T . T[] requires Addable[T], Reflection[T]

이것이 Rust에서 "Trait Objects"가 작동하는 것과 같은 방식이라는 점은 주목할 가치가 있습니다.

Go는 (프로그래머에게 보이는) 실존적 요소, 공분산 및 반공변성을 완전히 피할 수 있습니다. 이는 좋은 일이며 제 생각에는 제네릭을 훨씬 간단하고 강력하게 만들 것입니다.

내가 아는 한 공분산이나 반공변은 없습니다. 이것은 이것이 하위 유형이 아니라는 것을 강력하게 말합니다.

다형성 유형 시스템은 불변하므로 이 모델에 더 가깝고 인터페이스를 단일 매개변수 유형 클래스로 취급하는 것이 Go의 단순성에 더 가깝습니다.

둘 다 옳다고 제안해도 될까요? 인터페이스는 유형 클래스와 동일하지만 유형 클래스는 하위 유형 지정의 한 형태입니다. 지금까지 내가 찾은 하위 유형의 정의는 모두 매우 모호하고 부정확하며 "A는 B의 하위 유형이며, 하나가 다른 것으로 대체될 수 있다면"로 요약됩니다. IMO 는 유형 클래스로 만족한다고 쉽게 주장할 수 있습니다 .

Variance-argument 자체는 실제로 IMO에서 작동하지 않습니다. Variance는 언어가 아니라 형식 생성자의 속성입니다. 그리고 언어의 모든 유형 생성자가 변형인 것은 아닙니다(예를 들어, 하위 유형이 있는 많은 언어에는 가변 배열이 있으며 유형이 안전하려면 불변이어야 함). 그래서 왜 당신이 변형 유형 생성자 없이 하위 유형을 가질 수 없는지 알 수 없습니다.

또한 나는 이 논의가 Go 저장소의 문제에 대해 너무 광범위하다고 생각합니다. 이것은 유형 이론의 복잡성을 논의하는 것이 아니라 Go에 제네릭을 추가하는 경우와 방법에 관한 것입니다.

@Merovius Variance는 서브타이핑과 관련된 속성입니다. 하위 입력이 없는 언어에서는 차이가 없습니다. 분산이 존재하려면 먼저 유형 생성자에 공분산/반공분산 문제를 도입하는 하위 유형이 있어야 합니다. 그러나 하위 유형이 있는 언어에서는 모든 유형 생성자를 불변하게 할 수 있다는 말이 옳습니다.

유형 클래스는 유형이 아니기 때문에 유형 클래스는 하위 유형 지정이 아닙니다. 그러나 우리는 Go에서 '인터페이스 유형'을 러스트가 유형 클래스에서 파생된 유형으로 효과적으로 '특성 객체'라고 부르는 것으로 볼 수 있습니다.

Go의 의미는 분산이 없고 암시적인 '특성 개체'가 있기 때문에 현재 두 모델에 모두 맞는 것 같습니다. 따라서 Go는 전환점에 있으며 하위 유형 지정 라인을 따라 제네릭 및 유형 시스템을 개발하여 C#의 제네릭과 같은 변형을 도입하고 끝낼 수 있습니다. 또는 Go에서 다중 매개변수 인터페이스를 도입하여 Collections에 대한 인터페이스를 허용할 수 있으며 이는 인터페이스와 '인터페이스 유형' 간의 즉각적인 연결을 끊을 수 있습니다. 예를 들어 다음이 있는 경우:

type (T, U) Collection interface {
    member : (c T, e U) Bool
    insert: (c T, e U) T
}

member(c int32[], e int32) Bool {...}
insert(c int32[], e int32) int32[] {...}

member(c float32[], e float32) Bool {...}
insert(c float32[], e float32) float32[] {...}

T, U 유형과 Collection 인터페이스 사이에 더 이상 명백한 하위 유형 관계가 없습니다. 따라서 인스턴스 유형과 인터페이스 유형 간의 관계는 단일 매개변수 인터페이스의 특수한 경우에 대한 하위 유형으로만 볼 수 있으며 단일 매개변수 인터페이스로 컬렉션과 같은 추상화를 표현할 수 없습니다.

제네릭의 경우 컬렉션과 같은 것을 모델링할 수 있어야 하므로 다중 매개변수 인터페이스는 저에게 필수품입니다. 그러나 제네릭에서 공분산과 반공변 간의 상호 작용은 지나치게 복잡한 유형 시스템을 생성하므로 하위 유형 지정을 피하고 싶습니다.

@keean 인터페이스는 유형으로 사용될 수 있고 유형 클래스는 유형이 아니기 때문에 Go 의미론에 대한 가장 자연스러운 설명은 인터페이스가 유형 클래스가 아니라는 것입니다. 인터페이스를 유형 클래스로 일반화하려는 주장을 이해합니다. 나는 그것이 언어를 취하는 것이 합리적인 방향이라고 생각하고, 사실 우리는 이미 출판된 작업에서 그 접근 방식을 광범위하게 탐구했습니다.

Go에 하위 유형이 있는지 여부와 관련하여 다음 코드를 고려하십시오.

package main

type Cloneable interface {
    Clone() Cloneable
}

type CloneableZ interface {
    Clone() Cloneable
    zero() int
}

type S struct {}

func (t S) Clone() Cloneable {
    c := t
    return c
}

func (t S) zero() int {
    return 0
}

var x CloneableZ = S{}
var y Cloneable = x

func main() {
    print("ok\n")
}

x 에서 y $로의 할당은 $# x 유형이 예상되는 곳에 y 유형이 사용될 수 있음을 보여줍니다. 이것은 CloneableZ <: Cloneable 및 S <: CloneableZ 하위 유형 관계입니다. 유형 클래스의 관점에서 인터페이스를 설명하더라도 S <: ∃T.CloneableZ[T] <: ∃T.Cloneable[T] 와 같은 하위 유형 지정 관계가 여전히 존재합니다.

Go에서 Clone S 반환하도록 허용하는 것은 완벽하게 안전하지만 Go는 인터페이스 준수를 위해 불필요하게 제한적인 규칙을 적용합니다. 사실, Java와 동일한 규칙입니다. 원래 시행. @Merovius 가 관찰한 것처럼 하위 유형 지정에는 비불변 유형 생성자가 필요하지 않습니다.

@andrewcmyers 컬렉션을 추상화하는 데 필요한 것과 같은 다중 매개변수 인터페이스는 어떻게 됩니까?

더 나아가 x에서 y로의 할당은 하위 유형이 전혀 없는 인터페이스 상속을 보여주는 것으로 볼 수 있습니다. Haskell(분명히 하위 유형이 없음)에서는 다음과 같이 작성합니다.

class Cloneable t => CloneableZ t where...

x 가 있는 곳은 CloneableZ 를 구현하는 유형이며 정의에 따라 Cloneable 도 구현하므로 분명히 y 에 할당할 수 있습니다.

요약하자면 인터페이스를 유형으로 보고 공변 또는 반공변 유형 생성자가 없는 제한된 하위 유형을 갖도록 Go를 사용하거나 "특성 개체"로 볼 수 있습니다. 또는 Go에서는 이를 " "typeclass" 인터페이스에 의해 제한된 다형성 컨테이너인 "인터페이스 개체"입니다. typeclass 모델에는 하위 유형이 없으므로 공분산과 반공분산에 대해 생각할 이유가 없습니다.

하위 유형 지정 모델을 고수하면 컬렉션 유형을 가질 수 없습니다. 이것이 C++에서 템플릿을 도입해야 하는 이유입니다. 객체 지향 하위 유형화는 컨테이너와 같은 개념을 일반적으로 정의하기에 충분하지 않기 때문입니다. 추상화, 객체 및 하위 유형 지정, 템플릿/특성 및 제네릭을 위한 두 가지 메커니즘으로 끝납니다. 둘 사이의 상호 작용은 복잡해집니다. 예를 들어 C++, C# 및 Scala를 살펴보세요. 다른 언어와 함께 제네릭의 성능을 높이기 위해 공변 및 반공 생성자를 도입하라는 요청이 계속 있을 것입니다.

별도의 제네릭 시스템을 도입하지 않고 제네릭 컬렉션을 원하면 유형 클래스와 같은 인터페이스를 생각해야 합니다. 다중 매개변수 인터페이스는 더 이상 하위 유형 지정에 대해 생각하지 않고 대신 인터페이스 상속에 대해 생각하는 것을 의미합니다. Go에서 제네릭을 개선하고 컬렉션과 같은 추상화를 허용하고 C++, C#, Scala 등과 같은 언어 유형 시스템의 복잡성을 원하지 않는 경우 다중 매개변수 인터페이스 및 인터페이스 상속이 방법입니다. 토고.

@keean

컬렉션을 추상화하는 데 필요한 것과 같은 다중 매개변수 인터페이스는 어떻게 됩니까?

다중 매개변수 유형 제약 조건을 지원하는 Genus 및 Familia에 대한 문서를 참조하십시오. Familia는 이러한 제약 조건을 인터페이스로 통합하고 인터페이스가 여러 유형을 제약할 수 있도록 합니다.

하위 유형 모델을 고수하면 컬렉션 유형을 가질 수 없습니다.

"서브타이핑 모델"이 무엇을 의미하는지 완전히 확신할 수 없지만 Java와 C#에 컬렉션 유형이 있다는 것은 분명하므로 이 주장은 나에게 별로 의미가 없습니다.

x가 있는 곳에서 정의에 따라 Cloneable도 구현하는 CloneableZ를 구현하는 유형이므로 분명히 y에 할당할 수 있습니다.

아니요, 제 예에서 x는 변수 이고 y는 다른 변수입니다. y가 CloneableZ 유형이고 x가 Cloneable 유형이라는 것을 알고 있다고 해서 y에서 x로 할당할 수 있다는 의미는 아닙니다. 그것이 나의 모범이 하는 일이다.

Go를 모델링하기 위해 서브타이핑이 필요하다는 것을 명확히 하기 위해, 아래는 Haskell에서 도덕적으로 동등한 유형 검사를 하지 않는 예의 예리한 버전입니다. 이 예에서는 하위 유형 지정을 통해 다른 요소가 서로 다른 구현을 갖는 이기종 컬렉션을 생성할 수 있음을 보여줍니다. 또한 가능한 구현 세트는 개방형입니다.

type Cloneable interface {
    Clone() Cloneable
}

type CloneableZ interface {
    Clone() Cloneable
    zero() int
}

type S struct {}

func (t S) Clone() Cloneable {
    c := t
    return c
}

type T struct { x int }

func (t T) Clone() Cloneable {
    c := t
    return c
}

func (t S) zero() int {
    return 0
}

var x CloneableZ = S{}
var y Cloneable = T{}
var a [2]Cloneable = [2]Cloneable{x, y}

@andrewcmyers

"서브타이핑 모델"이 무엇을 의미하는지 완전히 확신할 수 없지만 Java와 C#에 컬렉션 유형이 있다는 것은 분명하므로 이 주장은 나에게 별로 의미가 없습니다.

C++에서 템플릿을 개발한 이유를 살펴보십시오. OO 하위 유형 모델은 컬렉션과 같은 것을 일반화하는 데 필요한 일반 개념을 표현할 수 없었습니다. C#과 Java는 또한 개체, 하위 유형 지정 및 상속과 분리된 완전한 제네릭 시스템을 도입해야 했으며 공변 및 반공변 유형 생성자와 같은 두 시스템의 복잡한 상호 작용을 정리해야 했습니다. 뒤늦게 알게 된 이점으로 우리는 OO 하위 유형 지정을 피할 수 있으며 대신 단순 유형 언어에 인터페이스(유형 클래스)를 추가하면 어떤 일이 발생하는지 살펴볼 수 있습니다. 이것은 Rust가 한 일이므로 살펴볼 가치가 있지만 물론 평생 동안 복잡합니다. Go에는 GC가 있으므로 복잡성이 없습니다. 제 제안은 Go가 다중 매개변수 인터페이스를 허용하고 이러한 복잡성을 피하기 위해 확장될 수 있다는 것입니다.

Haskell에서 이 예제를 수행할 수 없다는 귀하의 주장에 대한 코드는 다음과 같습니다.

{-# LANGUAGE ExistentialQuantification #-}

class ICloneable t where
    clone :: t -> t

class ICloneable t => ICloneableZ t where
    zero :: t

data S = S deriving Show

instance ICloneable S where
    clone x = x

data T = T Int deriving Show

instance ICloneable T where
    clone x = x

instance ICloneableZ T where
    zero = T 0

data Cloneable = forall a . (ICloneable a, Show a) => ToCloneable a

instance Show Cloneable where
    show (ToCloneable x) = show x

main = do
    x <- return S
    y <- return (T 27)
    a <- return [ToCloneable x, ToCloneable y]
    putStrLn (show a)

몇 가지 흥미로운 차이점이 있습니다. Go는 자동으로 이 유형을 data Cloneable = forall a . (ICloneable a, Show a) => ToCloneable a 로 유도합니다. 이것이 인터페이스(저장소가 없는)를 유형(저장소가 있는)으로 바꾸는 방법이기 때문입니다. Rust도 이러한 유형을 유도하고 "특성 개체"라고 부릅니다. . Java, C# 및 Scala와 같은 다른 언어에서는 실제로 "올바른" 인터페이스를 인스턴스화할 수 없으며 인터페이스는 유형이 아니며 스토리지가 없습니다. 인터페이스는 유형과 비슷하며 Go는 존재하는 컨테이너에 파생된 인터페이스와 동일한 이름을 지정하여 이를 숨깁니다. 주의해야 할 또 다른 사항은 이 [2]Cloneable{x, y} 는 모든 구성원을 Cloneable 로 강제하는 반면 Haskell에는 이러한 암시적 강제가 없으므로 ToCloneable 로 구성원을 명시적으로 강제해야 한다는 것입니다. .

또한 S 및 T 는 Cloneable 의 S 및 T 하위 유형을 고려하지 않아야 한다고 지적했습니다. 구조적으로 호환됩니다. 우리는 문자 그대로 모든 유형의 Cloneable 인스턴스를 선언할 수 있으며(Go에서 clone 함수의 관련 정의를 선언함으로써) 이러한 유형은 서로 관련이 전혀 필요하지 않습니다.

Generics에 대한 대부분의 제안은 가독성과 Go의 단순한 느낌을 해치는 추가 토큰을 포함하는 것 같습니다. Go의 기존 문법과 잘 작동할 수 있다고 생각하는 다른 구문을 제안하고 싶습니다(Github Markdown에서 구문 강조 표시도 꽤 잘 발생함).

제안의 요점:

• Go의 문법은 우리가 찾고 있는 특정 토큰이나 키워드가 있기 때문에 언제 유형 선언이 끝났는지 쉽게 결정할 수 있는 것 같습니다. 모든 경우에 이것이 사실이라면 유형 이름 자체 다음에 유형 인수를 추가하기만 하면 됩니다.
• 대부분의 제안과 마찬가지로 동일한 식별자는 모든 함수 선언에서 동일한 유형을 의미합니다. 이러한 식별자는 선언을 이스케이프하지 않습니다.
• 대부분의 제안에서 제네릭 형식 인수를 선언해야 하지만 이 제안에서는 암시적입니다. 어떤 사람들은 이것이 가독성이나 명료성을 해치거나(암묵성은 나쁘다) 유형 이름 지정 능력을 제한한다고 주장하지만, 반론은 다음과 같습니다.
  
  
  
  • 가독성을 해치는 것에 관해서는 어느 쪽이든 논쟁할 수 있다고 생각합니다.또는 [T]는 구문상의 노이즈를 많이 만들어 가독성을 떨어뜨립니다.
  
  
  • 적절하게 사용될 때 함축성은 언어의 장황함을 줄이는 데 도움이 될 수 있습니다. :=에 의해 숨겨진 정보는 매번 철자법을 설명할 만큼 중요하지 않기 때문에 우리는 항상 := 유형 선언을 생략합니다.
  
  
  • 구체적인(일반이 아닌) 유형의 이름을 a 또는 t 로 지정하는 것은 아마도 나쁜 습관일 수 있으므로 이 제안은 이러한 식별자를 일반 유형 인수로 작동하도록 예약하는 것이 안전하다고 가정합니다. 이것은 아마도 이동 수정 마이그레이션이 필요하지만?
  
  

package main

import "fmt"

type LinkedList a struct {
  Head *Node a
  Tail *Node a
}

type Node a {
  Next *Node a
  Prev *Node a

  Value a
}

func main() {
  // Not sure about how recursive we could get with the inference
  ll := LinkedList string {
    // The string bit could be inferred
    Head: Node string { Value: "hello world" },
  }
}

func (l *LinkedList a) Append(value a) {
  newNode := &Node{Value: value}

  if l.Tail == nil {
    l.Head = newNode
    l.Tail = l.Head
    return
  }

  l.Tail.Next = newNode
  l.Tail = l.Tail.Next
}

이것은 https://gist.github.com/aarondl/9b950373642fcf5072942cf0fca2c3a2 에 제안된 합계 유형뿐만 아니라 조금 더 세부적인 Gist에서 가져옵니다

이것은 완전히 플러시된 Generics 제안이 아니며 의도된 것도 아닙니다. Go에 Generics를 추가할 수 있으려면 해결해야 할 많은 문제가 있습니다. 이것은 구문만을 다루며 제안된 내용이 실현 가능한지/바람직한지 여부에 대해 대화를 나눌 수 있기를 바랍니다.

@아론들
이 구문을 사용하면 다음과 같이 보입니다.

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

@keean Collection 유형을 조금 설명해 주시겠습니까? 나는 그것을 이해하지 못한다:

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

@dc0d Collection은 _all_ 컬렉션을 추상화하는 인터페이스이므로 트리, 목록, 조각 등을 추상화하므로 member 및 insert $와 같은 일반 작업이 모든 데이터 유형을 포함하는 모든 컬렉션에서 작동할 수 있습니다. 위의 예에서는 이전 예제에서 LinkedList 유형에 대해 '삽입'을 정의하는 예제를 제공했습니다.

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

슬라이스에 대해 정의할 수도 있습니다.

func insert(c []a, e a) []a {
   return append(c, e)
}

그러나 다형성 유형이 a 인 @aarondl 에서 설명한 것처럼 유형 변수가 있는 매개변수 함수는 필요하지 않습니다. 구체적인 유형에 대해 정의할 수 있기 때문입니다.

func insert(c *LinkedList int, e int) *LinkedList int {
   c.Append(e)
   return c
}

func insert(c *LinkedList float, e float) *LinkedList float {
   c.Append(e)
   return c
}

func insert(c int[], e int) int[] {
   return append(c, e)
}

func insert(c float[], e float) float[] {
   return append(c, e)
}

따라서 Collection 는 컨테이너 유형과 내용 유형 모두를 일반화하기 위한 인터페이스로, 컨테이너와 내용의 모든 조합에서 작동하는 일반 기능을 작성할 수 있습니다.

member 및 insert 가 각 조합에 대해 정의된 경우 콘텐츠가 다른 값 유형을 가진 다른 컬렉션 유형인 []Collection 컬렉션 조각을 가질 수도 없습니다. .

@aarondl type LinkedList a 이 이미 유효한 유형 선언임을 감안할 때 이를 명확하게 구문 분석할 수 있는 두 가지 방법만 볼 수 있습니다. 실패 사례의 잘못된 오류 메시지 때문에 go 문법이 피하는 경향이 있습니다. 내가 뭔가를 오해하고 있을지도 모르지만 IMO는 토큰 없는 접근 방식에 반대합니다.

Go의 @keean 인터페이스는 함수가 아닌 메서드를 사용합니다. 제안한 특정 구문에는 컴파일러에 대해 insert 를 *LinkedList 에 첨부하는 것이 없습니다(Haskell에서는 instance 선언을 통해 수행됨). 메소드가 작동 중인 값을 변경하는 것도 정상입니다. 이것은 당신이 제안하는 구문이 Go에서 잘 작동하지 않는다는 것을 지적한 것뿐입니다. 아마 더 비슷한

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

또한 유형 매개변수의 범위와 구문 분석 방법에 대한 몇 가지 추가 질문을 보여줍니다.

@aarondl 당신의 제안에 대해 더 많은 질문이 있습니다. 예를 들어 제약 조건을 허용하지 않으므로 제약 없는 다형성만 얻을 수 있습니다. 이것은 일반적으로 얻는 값으로 아무 것도 할 수 없기 때문에 그다지 유용하지 않습니다(예: 모든 유형이 유효한 맵 키가 아니기 때문에 맵으로 Collection을 구현할 수 없음). 누군가가 그런 일을 하려고 하면 어떻게 해야 합니까? 컴파일 타임 오류인 경우 인스턴스화(C++ 오류 메시지 앞) 또는 정의(모든 유형에서 작동하는 것이 없기 때문에 기본적으로 아무 것도 할 수 없음)에 대해 불평합니까?

@keean 그래도 a 가 목록(또는 슬라이스 또는 기타 컬렉션)으로 제한되는 방법을 이해하지 못합니다. 컬렉션에 대한 컨텍스트 종속 특수 문법입니까? 그렇다면 그 가치는 무엇입니까? 이 방법으로 사용자 정의 유형을 선언하는 것은 불가능합니다.

@Merovius 그것은 Go가 다중 디스패치를 ​​할 수 없다는 것을 의미하고 '함수'의 첫 번째 인수를 특별하게 만드나요? 이것은 연관된 유형이 다중 매개변수 인터페이스보다 더 적합할 것임을 시사합니다. 이 같은:

type Collection interface {
   type Element
   Member(e Element) Bool
   Insert(e Element) Collection
}

type IntSlice struct {
    value []Int,
}

type IntSlice.Element = Int

func (IntSlice) Member(e Int) Bool {...}
func (IntSlice) Insert(e Int) IntSlice {...}

func useIt(c Collection, e Collection.Element) {...}

그러나 두 컬렉션을 동일한 유형으로 제한하는 것이 없기 때문에 여전히 문제가 있습니다. 결국 다음과 같은 것이 필요합니다.

func[A] useIt(c A, e A.Element) requires A:Collection

차이점을 설명하기 위해 다중 매개변수 인터페이스에는 인스턴스 선택에 참여하는 추가 _input_ 유형이 있는 반면(따라서 다중 디스패치 연결) 연결된 유형은 _output_ 유형이고 수신기 유형만 인스턴스 선택에 참여하고 그런 다음 연결된 유형은 수신기 유형에 따라 다릅니다.

@dc0d a 및 b 는 Haskell 유형 클래스와 마찬가지로 인터페이스의 유형 매개변수입니다. Collection 로 간주되려면 a 및 b 가 모든 유형일 수 있는 인터페이스의 유형과 일치하는 메소드를 정의해야 합니다. 그러나 @Merovius 가 지적했듯이 Go 인터페이스는 메서드 기반이며 다중 디스패치를 ​​지원하지 않으므로 다중 매개변수 인터페이스는 적합하지 않을 수 있습니다. Go의 단일 디스패치 메소드 모델을 사용하면 다중 매개변수 대신 인터페이스에 연관된 유형을 갖는 것이 더 적합해 보입니다. 그러나 다중 디스패치의 부재는 unify(x, y) 와 같은 기능을 구현하는 것을 어렵게 만들고 그다지 좋지 않은 이중 디스패치 패턴을 사용해야 합니다.

다중 매개 변수를 조금 더 설명하려면 다음을 수행하십시오.

type Cloneable[A] interface {
   clone(x A) A
}

여기서 a 는 모든 유형을 나타냅니다. 올바른 함수가 정의되어 있는 한 그것이 무엇인지 상관하지 않습니다. Cloneable 로 간주합니다. 우리는 인터페이스를 유형 자체가 아니라 유형에 대한 제약으로 간주할 것입니다.

func clone(x int) int {...}

그래서 'clone'의 경우 인터페이스 정의에서 int 를 $ a 로 대체하고 대체가 성공하면 clone을 호출할 수 있습니다. 이것은 다음 표기법과 잘 맞습니다.

func[A] test(x A) A requires Cloneable[A] {...}

이것은 다음과 같습니다.

type Cloneable interface {
   clone() Cloneable
}

그러나 메소드가 아닌 함수를 선언하고 여러 매개변수로 확장할 수 있습니다. 다중 디스패치가 있는 언어가 있는 경우 함수/메서드의 첫 번째 인수에 대해 특별한 것이 없으므로 다른 위치에 작성해야 합니다.

Go에는 다중 디스패치가 없기 때문에 이 모든 것이 한 번에 변경하기에는 너무 많은 것처럼 느껴지기 시작합니다. 더 제한적이긴 하지만 연결된 유형이 더 적합할 것 같습니다. 이것은 추상 컬렉션을 허용하지만 통일과 같은 것에 대한 우아한 솔루션은 아닙니다.

@Merovius 제안을 검토해 주셔서 감사합니다. 귀하의 우려 사항을 해결하도록 노력하겠습니다. 더 많은 논의를 하기 전에 제안을 거절하셨다니 안타깝습니다. 제가 마음을 바꿀 수 있기를 바랍니다. 아니면 제 생각을 바꿀 수도 있습니다. :)

무한한 전망:
따라서 제안서에서 언급했듯이 현재 Go 문법은 구문적으로 거의 모든 것의 "끝"을 감지하는 좋은 방법을 가지고 있는 것 같습니다. 그리고 우리는 여전히 암묵적인 일반 인수 때문에 그렇게 할 것입니다. 단일 문자 소문자는 해당 일반 인수를 생성하는 구문 구조입니다. 또는 인라인 토큰을 만들기로 결정한 것이 무엇이든, 구문이 충분히 마음에 들지만 그렇지 않은 경우 제안에서 @a 와 같은 토큰화된 것으로 대체할 수도 있습니다. 토큰 없이 컴파일러의 어려움을 감안할 때 가능하지만 제안은 그렇게 하자마자 많은 매력을 잃습니다.

a 가 제네릭 유형 인수이고 type LinkedList 과 동일한 컴파일러 오류로 실패할 것이라는 것을 알고 있기 때문에 이 제안에서 type LinkedList a 의 문제는 그렇게 어렵지 않습니다. type LinkedList 는 prog.go:3:16: expected type, found newline (and 1 more errors) 로 오늘 실패합니다. 원래 게시물은 실제로 나오지 않았고 말했지만 더 이상 구체적인 유형의 이름을 [a-z]{1} 로 지정할 수 없습니다. 제 생각에는 이 문제를 해결하고 우리 모두가 괜찮다고 생각하는 희생입니다. 만들기(오늘날 Go 코드에서 단일 문자 이름으로 실제 유형을 생성할 때의 단점만 볼 수 있습니다).

제약 없는 다형성일 뿐이야
어떤 종류의 특성이나 일반 인수 제약 조건을 생략한 이유는 그것이 Go에서 인터페이스의 역할이라고 생각하기 때문입니다. 값으로 무언가를 하고 싶다면 그 값은 완전한 일반 유형이 아니라 인터페이스 유형이어야 합니다. 나는 이 제안이 인터페이스와도 잘 어울린다고 생각한다.

이 제안에 따르면 + 와 같은 연산자를 사용할 때와 같은 문제가 계속 발생하므로 모든 숫자 유형에 대한 일반 추가 기능을 만들 수 없지만 일반 추가 기능을 인수로 받아들일 수 있습니다. 다음을 고려하세요:

func Sort(slice []a, compare func (a, a) bool) { ... }

범위 지정에 대한 질문

당신은 여기에 예를 주었습니다:

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

일반적으로 이러한 식별자의 범위는 해당 식별자가 속한 특정 선언/정의에 바인딩됩니다. 그들은 어디에도 공유되지 않으며 그럴 이유가 없습니다.

@keean 다른 사람들이 지적했듯이 실제로 인터페이스를 구현할 수 있도록 거기에 표시된 것을 변경해야 한다고 지적했지만 매우 흥미롭습니다(현재 귀하의 예제에는 수신기가 있는 메서드가 없고 기능만 있음). 이것이 내 원래 제안에 어떤 영향을 미치는지 더 생각하려고 합니다.

단일 문자 소문자는 해당 일반 인수를 생성하는 구문 구조입니다.

나는 그것에 대해 기분이 좋지 않다. 컨텍스트에 따라 식별자가 무엇인지에 대해 별도의 생성이 필요하고 유형에 대한 특정 식별자를 임의로 금지한다는 의미이기도 합니다. 그러나 이러한 세부 사항에 대해 이야기할 때가 아닙니다.

이 제안에 따라 +와 같은 연산자에 대해 지금과 같은 문제가 여전히 발생합니다.

나는 이 문장을 이해하지 못한다. 현재, + 연산자는 피연산자의 유형이 로컬로 알려져 있고 오류 메시지가 명확하고 모호하지 않으며 문제의 원인을 가리키기 때문에 이러한 문제가 없습니다. 가능한 모든 유형에 대해 허용되지 않는 제네릭 값의 사용을 허용하지 않으려고 한다고 가정하는 것이 맞습니까(이러한 작업은 많이 생각할 수 없습니다)? 그리고 제네릭 함수에서 문제가 되는 표현식에 대해 컴파일러 오류를 생성하시겠습니까? 제네릭의 가치를 너무 많이 제한하는 IMO.

값으로 무언가를 하고 싶다면 그 값은 완전한 제네릭 유형이 아니라 인터페이스 유형이어야 합니다.

사람들이 제네릭을 원하는 두 가지 주요 이유는 성능(인터페이스 래핑 방지)과 유형 안전성(같은 유형이 어느 위치에 있는지 신경 쓰지 않고 다른 위치에서 사용되는지 확인)입니다. 이것은 그러한 이유를 무시하는 것 같습니다.

일반 추가 기능을 인수로 받아들일 수 있습니다.

진실. 그러나 꽤 인체 공학적이지 않습니다. sort API에 대한 불만이 얼마나 많은지 생각해 보십시오. 많은 일반 컨테이너의 경우 호출자가 구현하고 전달해야 하는 함수의 양이 엄청나게 많은 것 같습니다. container/heap 구현이 이 제안에 따라 어떻게 보이고 인체 공학 측면에서 현재 구현보다 더 나은지 고려하십시오. 여기에서 승률은 기껏해야 무시할 수 있는 수준인 것 같습니다. 더 적은 기능이 아니라 더 많은 사소한 기능을 구현해야 합니다(그리고 각 사용 사이트에서 복제/참조).

@메로비우스

@aarondl 의 이 점에 대해 생각하기

일반 추가 기능을 인수로 받아들일 수 있습니다.

중위 연산자를 정의하기 위한 몇 가지 구문이 주어지면 덧셈 오버로딩을 허용하는 Addable 인터페이스를 갖는 것이 좋습니다.

type Addable interface {
   + (x Addable, y Addable) Addable
}

불행히도 이것은 모든 유형이 동일할 것으로 예상하지 않기 때문에 작동하지 않습니다. 추가 가능을 정의하려면 다중 매개변수 인터페이스와 같은 것이 필요합니다.

type Addable[A] interface {
   + (x A, y A) A
}

그런 다음 Go에서 다중 디스패치를 ​​수행해야 합니다. 즉, 함수의 모든 인수가 인터페이스 일치를 위한 수신기처럼 처리됩니다. 따라서 위의 예에서 인터페이스 정의의 함수 정의를 충족하는 + 함수가 정의되어 있으면 모든 유형은 Addable 입니다.

그러나 이러한 변경 사항을 감안할 때 이제 다음과 같이 작성할 수 있습니다.

type S struct {
   value: int
}

func (+) (x S, y S) S {
   return S {
      value: x.value + y.value
   }
}

func main() {
    println(S {value: 27} + S {value: 5})
}

물론 함수 오버로딩과 다중 디스패치는 사람들이 Go에서 결코 원하지 않는 것일 수 있지만 벡터, 행렬, 복소수 등과 같은 사용자 정의 유형에 대한 기본 산술을 정의하는 것과 같은 일은 항상 불가능합니다. 위에서 말했듯이 인터페이스의 '연관 유형'은 일반 프로그래밍 기능을 어느 정도 향상시킬 수 있지만 완전한 일반성은 아닙니다. 다중 디스패치(아마도 함수 오버로딩)가 Go에서 일어날 수 있는 일입니까?

벡터, 행렬, 복소수 등과 같은 사용자 정의 유형에 대한 기본 산술을 정의하는 것과 같은 일은 항상 불가능합니다.

일부는 그 기능을 고려할 수 있습니다. :) AFAIR 있어야 하는지 여부를 논의하는 어딘가에 떠다니는 제안이나 스레드가 있습니다. FWIW, 나는 이것이 - 다시 - 주제에서 벗어나 방황한다고 생각합니다. 연산자 오버로딩(또는 일반적인 "Go를 더 많이 Haskell으로 만드는 방법" 아이디어)은 실제로 이 문제의 요점이 아닙니다. :)

다중 디스패치(아마도 함수 오버로딩)가 Go에서 일어날 수 있는 일입니까?

절대 절대 말하지 마세요. 개인적으로 기대하지는 않겠지만.

@메로비우스

어떤 사람들은 그것을 기능이라고 생각할 수도 있습니다. :)

물론, Go가 하지 않는다면 다른 언어도 그렇게 할 것입니다 :-) Go가 모든 사람에게 모든 것을 제공할 필요는 없습니다. 나는 Go에서 제네릭에 대한 일부 범위를 설정하려고 했습니다. 내 초점은 나 자신과 상용구를 반복하는 것을 싫어하기 때문에 완전히 일반적인 언어를 만드는 것입니다(매크로를 좋아하지 않습니다). 매번 1페니가 있다면 특정 데이터 유형에 대해 'C'로 연결 목록이나 트리를 작성해야 했습니다. 실제로 일부 프로젝트는 이해하기 위해 머리에 담고 있어야 하고 변경을 통해 유지해야 하는 코드의 양 때문에 소규모 팀에서는 불가능합니다. 때로는 제네릭이 필요하지 않은 사람들이 아직 충분히 큰 프로그램을 작성하지 않았다고 생각합니다. 물론 대신 큰 팀의 개발자가 작업을 수행하고 각 개발자가 전체 코드의 작은 부분만 담당하도록 할 수 있지만 저는 단일 개발자(또는 소규모 팀)를 가능한 한 효율적으로 만드는 데 관심이 있습니다.

함수 오버로딩 및 다중 디스패치가 범위를 벗어나고 @aarondl 의 제안에 대한 구문 분석 문제를 감안할 때 인터페이스에 관련 유형을 추가하고 함수에 유형 매개변수를 추가하는 것은 원하는 만큼 Go에서 제네릭을 사용하십시오.

다음과 같은 것이 올바른 종류인 것 같습니다.

type Collection interface {
   type Element
   Member(e Element) Bool
   Insert(e Element) Collection
}

type IntSlice struct {
    value []Int,
}

type IntSlice.Element = Int

func (IntSlice) Member(e Int) Bool {...}
func (IntSlice) Insert(e Int) IntSlice {...}

func useIt<T>(c T, e T.Element) requires T:Collection {...}

그런 다음 구현 시 매개변수 유형을 사용할지 또는 보편적으로 수량화된 유형을 사용할지 결정해야 합니다. Java와 같은 매개변수 유형의 경우 '일반' 함수는 실제로 함수가 아니라 일종의 유형 안전 함수 템플릿이며, 따라서 유형 매개변수가 제공되지 않는 한 인수로 전달할 수 없습니다.

f(useIt) // not okay with parametric types
f(useIt<List>) // okay with parametric types

보편적으로 수량화된 유형을 사용하면 useIt을 인수로 전달할 수 있으며 f 내부에 유형 매개변수를 제공할 수 있습니다. 매개변수 유형을 선호하는 이유는 컴파일 시간에 다형성을 단일화할 수 있기 때문에 런타임에 다형성 함수를 정교하게 만들 필요가 없기 때문입니다. Go가 이미 인터페이스에서 런타임 디스패치를 ​​수행하고 있기 때문에 이것이 Go와 관련된 문제인지 잘 모르겠습니다 useIt 정량화는 아마도 Go의 올바른 방법일 것입니다.

@bcmills만 언급한 SFINAE가 궁금합니다. 제안서에도 언급되지 않았습니다(예로 Sort가 있지만).
그러면 슬라이스 및 링크드리스트의 Sort 는 어떻게 될까요?

@keean
귀하의 제안으로 일반적인 '슬라이스' 컬렉션을 정의하는 방법을 알 수 없습니다. '컬렉션'을 구현하는 'IntSlice'를 정의하고 있는 것 같지만(Insert가 인터페이스에서 원하는 것과 다른 유형을 반환하지만) 이는 int에만 해당되는 것처럼 보이므로 일반 '슬라이스'가 아닙니다. , 메서드 구현은 int에만 해당됩니다. 유형별로 특정 구현을 정의해야 합니까?

때로는 제네릭이 필요하지 않은 사람들이 아직 충분히 큰 프로그램을 작성하지 않았다고 생각합니다.

나는 그 인상이 거짓임을 확신할 수 있다. 그리고 FWIW, ISTM은 "다른 쪽"이 "필요를 보지 않음"을 "사용을 보지 않음"과 같은 양동이에 넣는 것입니다. 나는 사용을보고 그것을 반박하지 않습니다. 나는 정말로 필요 를 느끼지 않는다. 큰 코드베이스에서도 문제 없이 잘 지내고 있습니다.

그리고 "올바른 제안을 원하고 기존 제안이 없는 부분을 지적하는 것"을 "기본적으로 바로 그 아이디어에 반대하는 것"과 착각하지 마십시오.

@aarondl 의 제안에 대한 구문 분석 문제도 제공됩니다.

내가 말했듯이, 나는 구문 분석 문제에 대해 이야기하는 것이 지금 당장은 실제로 생산적이라고 생각하지 않습니다. 구문 분석 문제를 해결할 수 있습니다. 제한된 다형성의 결함은 의미적으로 훨씬 더 심각합니다. IMO, 그것 없이 제네릭을 추가하는 것은 노력할 가치가 없습니다.

@urandom

귀하의 제안으로 일반적인 '슬라이스' 컬렉션을 정의하는 방법을 알 수 없습니다.

위에서 주어진 것처럼 각 슬라이스 유형에 대해 별도의 구현을 정의해야 하지만 여전히 일반 인터페이스 측면에서 알고리즘을 작성할 수 있다는 이점이 있습니다. 모든 슬라이스에 대한 일반 구현을 허용하려면 매개변수 관련 유형 및 메서드를 허용해야 합니다. 참고 유형 매개변수를 키워드 뒤로 이동하여 수신자 유형 이전에 발생하도록 했습니다.

type<T> []T.Element = Int

func<T> ([]T) Member(e T) Bool {...}
func<T> ([]T) Insert(e T) Collection {...}

그러나 이제는 전문화도 처리해야 합니다. 누군가가 더 전문화된 []int 에 대한 관련 유형 및 메서드를 정의할 수 있고 어느 것을 사용할지 처리해야 하기 때문입니다. 일반적으로 더 구체적인 인스턴스를 사용하지만 복잡성의 또 다른 계층이 추가됩니다.

이것이 실제로 당신에게 얼마나 이득이 되는지 잘 모르겠습니다. 위의 원래 예제를 사용하면 인터페이스를 사용하여 일반 컬렉션에 작동하는 일반 알고리즘을 작성할 수 있으며 실제로 사용하는 유형에 대한 메서드와 관련 유형만 제공하면 됩니다. 저에게 있어 가장 큰 승리는 임의의 컬렉션에 대한 정렬과 같은 알고리즘을 정의하고 해당 알고리즘을 라이브러리에 넣을 수 있다는 것입니다. 그런 다음 "모양" 목록이 있으면 모양 목록에 대한 컬렉션 인터페이스 메서드를 정의하기만 하면 됩니다. 그러면 라이브러리에 있는 알고리즘을 사용할 수 있습니다. 모든 슬라이스 유형에 대한 인터페이스 메서드를 정의할 수 있다는 것은 나에게 덜 관심이 가는데, Go에서는 너무 복잡할 수 있습니다.

@메로비우스

그러나 나는 정말로 필요성을 느끼지 못합니다. 큰 코드베이스에서도 문제 없이 잘 지내고 있습니다.

100,000줄의 프로그램을 처리할 수 있다면 100,000개의 일반 줄이 아닌 줄로 할 수 있는 것보다 100,000줄로 더 많은 작업을 수행할 수 있습니다(반복으로 인해). 따라서 당신은 매우 큰 코드베이스에 대처할 수 있는 슈퍼스타 개발자일 수 있지만 중복성을 제거하기 때문에 매우 큰 일반 코드베이스로 더 많은 것을 달성할 수 있습니다. 그 일반 프로그램은 훨씬 더 큰 일반 프로그램이 아닌 프로그램으로 확장됩니다. 아직 복잡성 한계에 도달하지 않은 것 같습니다.

그러나 나는 당신이 옳다고 생각합니다. '필요'가 너무 강합니다. 나는 행복하게 go 코드를 작성하고 있습니다. 제네릭 부족에 대한 가끔 좌절감뿐입니다. 단순히 더 많은 코드를 작성하여 이 문제를 해결할 수 있습니다. Go에서는 해당 코드가 충분히 직접적입니다. 그리고 문자 그대로.

제한된 다형성의 결여는 의미적으로 훨씬 더 심각합니다. IMO, 그것 없이 제네릭을 추가하는 것은 노력할 가치가 없습니다.

나는 이것에 동의합니다.

100,000개의 일반 라인이 아닌 라인으로 할 수 있는 것보다 100,000개의 일반 라인으로 더 많은 작업을 수행할 수 있습니다(반복으로 인해)

귀하의 가상의 예에서 그 행의 몇 %가 일반 함수가 될 것인지 궁금합니다.
내 경험에 따르면 이것은 2% 미만(115k LOC가 있는 코드베이스에서)이므로 "컬렉션"에 대한 라이브러리를 작성하지 않는 한 이것이 좋은 인수라고 생각하지 않습니다.

나는 우리가 결국 제네릭을 얻었으면 좋겠다.

@keean

Haskell에서 이 예제를 수행할 수 없다는 귀하의 주장에 대한 코드는 다음과 같습니다.

이 코드는 내가 작성한 코드와 도덕적으로 동일하지 않습니다. ICloneable 인터페이스 외에 새로운 Cloneable 래퍼 유형을 도입합니다. Go 코드에는 래퍼가 필요하지 않았습니다. 서브타이핑을 지원하는 다른 언어도 마찬가지입니다.

@andrewcmyers

이 코드는 내가 작성한 코드와 도덕적으로 동일하지 않습니다. ICloneable 인터페이스 외에 새로운 Cloneable 래퍼 유형을 도입합니다.

이것이 이 코드가 하는 일이 아닙니까?

type Cloneable interface {...}

인터페이스에서 파생된 'Cloneable' 데이터 유형을 유도합니다. 인터페이스에 대한 인스턴스 선언이 없기 때문에 'ICloneable'이 표시되지 않고 메서드만 선언하면 됩니다.

인터페이스를 구현하는 유형이 구조적으로 호환될 필요가 없는 경우 하위 유형 지정을 고려할 수 있습니까?

@keean 저는 Cloneable 를 단순히 "데이터 유형"이 아닌 유형으로 간주할 것입니다. Java와 같은 언어에서는 코드와 달리 래퍼가 없기 때문에 Cloneable 추상화에 기본적으로 추가 비용이 없습니다.

인터페이스를 구현하는 유형 간에 구조적 유사성을 요구하는 것이 제한적이고 바람직하지 않은 것 같아서 여기서 무슨 생각을 하고 있는지 혼란스럽습니다.

@andrewcmyers
유형과 데이터 유형을 서로 바꿔서 사용하고 있습니다. 데이터를 포함할 수 있는 모든 유형은 데이터 유형입니다.

코드와 달리 래퍼가 없기 때문입니다.

Go 유형은 항상 상자형이기 때문에 항상 래퍼가 있으므로 래퍼는 모든 것을 둘러싸고 있습니다. Haskell은 unboxed 유형을 가지고 있기 때문에 래퍼가 명시적이어야 합니다.

인터페이스를 구현하는 유형 간의 구조적 유사성 때문에 여기서 무슨 생각을 하는지 혼란스럽습니다.

구조적 하위 유형 지정은 유형이 '구조적으로 호환 가능'해야 합니다. 상속이 있는 OO 언어와 같이 명시적 유형 계층이 없기 때문에 하위 유형 지정은 명목적일 수 없으므로 구조적이어야 합니다.

나는 당신이 의미하는 바를 이해합니다. 인터페이스를 인터페이스가 아닌 추상 기본 클래스로 간주하고 필요한 메서드를 구현하는 모든 유형과 일종의 암시적 명목 하위 유형 관계를 갖는 것으로 설명합니다.

저는 실제로 Go가 현재 두 모델에 모두 적합하고 여기에서 어느 쪽이든 갈 수 있다고 생각하지만 클래스가 아닌 인터페이스라고 부르는 것은 하위 유형이 아닌 사고 방식을 제안한다고 제안합니다.

@keean 나는 당신의 의견을 이해하지 못합니다. 먼저 당신은 동의하지 않는다고 말했고 나는 "아직 복잡성 한계를 충족하지 못했다"고 말한 다음 동의한다고 말합니다(그 "필요"는 단어가 너무 강력합니다). 나는 또한 당신의 주장이 잘못되었다고 생각합니다(LOC가 복잡성의 주요 척도이고 모든 코드 라인이 평등하다고 가정합니다). 그러나 무엇보다도 "누가 더 복잡한 프로그램을 작성하고 있는지"가 실제로 생산적인 토론의 대상이 아니라고 생각합니다. 나는 단지 "만약 당신이 나와 동의하지 않는다면, 그것은 당신이 어렵거나 흥미로운 문제를 다루지 않고 있다는 것을 의미할 것임에 틀림없다"는 주장은 설득력이 없고 선의로 나오지 않는다는 것을 명확히 하려고 했던 것입니다. 사람들이 이 기능의 중요성에 대해 동의하지 않을 수 있다는 사실을 믿으시기 바랍니다.

@메로비우스
나는 당신이 나보다 더 유능한 프로그래머이고 따라서 더 복잡한 작업을 할 수 있다고 말한 것입니다. 나는 확실히 당신이 덜 흥미롭거나 덜 복잡한 문제에 대해 작업하고 있다고 생각하지 않으며, 그런 식으로 보게 된 것에 대해 유감입니다. 나는 어제 스캐너가 작동하도록 하는 데 시간을 보냈습니다. 이것은 매우 흥미롭지 않은 문제였습니다.

제네릭이 제한된 지력으로 더 복잡한 프로그램을 작성하는 데 도움이 된다고 생각할 수 있으며 제네릭이 "필요"하지 않다는 것도 인정합니다. 학위의 문제입니다. 나는 여전히 제네릭 없이 프로그래밍할 수 있지만 반드시 동일한 복잡성의 소프트웨어를 작성할 수는 없습니다.

내가 선의로 행동하고 있다는 확신이 있기를 바랍니다. 여기에 숨겨진 의제가 없으며 Go가 제네릭을 채택하지 않더라도 계속 사용할 것입니다. 제네릭을 하는 가장 좋은 방법에 대한 의견이 있지만 유일한 의견은 아닙니다. 제 경험을 바탕으로 이야기할 뿐입니다. 내가 돕고 있지 않다면 시간을 할애할 수 있는 다른 많은 일들이 있으므로 말씀만 하시면 다른 곳에 다시 집중할 것입니다.

@Merovius 계속되는 대화에 감사드립니다.

| 사람들이 제네릭을 원하는 두 가지 주요 이유는 성능(인터페이스 래핑 방지)과 유형 안전성(같은 유형이 어느 위치에 있는지 신경 쓰지 않고 다른 위치에서 사용되는지 확인)입니다. 이것은 그러한 이유를 무시하는 것 같습니다.

아마도 우리는 내가 말할 수 있는 한 이 두 가지를 모두 수행하기 때문에 내가 제안한 것을 매우 다르게 보고 있는 것 같습니다. 연결 목록 예제에는 인터페이스를 사용한 래핑이 없으므로 주어진 유형에 대해 손으로 쓴 것처럼 성능이 좋아야 합니다. 유형 안전 측면에서는 동일합니다. 당신이 어디에서 왔는지 이해하는 데 도움이 될 수 있는 반례가 있습니까?

| 진실. 그러나 꽤 인체 공학적이지 않습니다. 정렬 API에 대한 불만이 얼마나 많은지 고려하십시오. 많은 일반 컨테이너의 경우 호출자가 구현하고 전달해야 하는 함수의 양이 엄청나게 많은 것 같습니다. 이 제안에서 컨테이너/힙 구현이 어떻게 보이고 인체 공학 측면에서 현재 구현보다 더 나은지 고려하십시오. 여기에서 승률은 기껏해야 무시할 수 있는 수준인 것 같습니다. 더 적은 기능이 아니라 더 많은 사소한 기능을 구현해야 합니다(그리고 각 사용 사이트에서 복제/참조).

나는 사실 이것에 대해 전혀 걱정하지 않는다. 기능의 양이 엄청나게 많을 것이라고는 생각하지 않지만 몇 가지 반례를 볼 수 있다는 것은 확실합니다. 사람들이 불평하는 API는 함수를 제공해야 하는 API가 아니라 여기에 있는 원래 API였습니다. https://golang.org/pkg/sort/#Interface 당신의 슬라이스 + 유형, 그리고 그것에 3가지 방법을 구현하십시오. 이 인터페이스와 관련된 불만과 고통을 고려하여 다음이 생성되었습니다. https://golang.org/pkg/sort/#Slice , 저는 이 API에 문제가 없으며 이에 대한 성능 저하를 복구할 것입니다. 제안에 따라 정의를 func Slice(slice []a, less func(a, a) bool) 로 간단히 변경하여 논의하고 있습니다.

container/heap 데이터 구조와 관련하여 전체 재작성이 필요한 일반 제안이 무엇이든 수락합니다. container/heap sort 와 마찬가지로 자신의 데이터 구조 위에 알고리즘을 제공하지만 두 패키지 모두 데이터 구조를 소유하지 않습니다. 그렇지 않으면 []interface{} 가 있고 그와 관련된 비용. 아마도 제네릭 덕분에 구체적인 유형의 슬라이스를 소유하는 Heap 를 가질 수 있기 때문에 우리는 그것들을 변경할 것입니다. .

나는 내가 제안한 것에 대한 우리의 관점의 차이점을 설명하려고 노력하고 있습니다. 그리고 의견 불일치의 뿌리(구문학적으로 개인의 선호도를 넘어서)는 Generic 유형에 대한 제약이 없다는 것입니다. 그러나 나는 여전히 그것이 우리에게 무엇을 얻는지 알아 내려고 노력하고 있습니다. 대답이 성능과 관련된 어떤 것도 인터페이스를 사용할 수 없다는 것이라면 여기서 말할 수 있는 것이 많지 않습니다.

다음 해시 테이블 정의를 고려하십시오.

// Hasher turns a key into a hash
type Hasher interface {
  func Hash() []byte
}

type HashTable v struct {
   Keys   []Hasher
   Values []v
}

// Note that the generic arguments must be repeated here and immediately
// understood without reading another line of code, which to me
// is a readability win over the sudden appearance of the K and V which are
// defined elsewhere in the code in the example below. This is of course because
// the tokenized type declarations with constraints are fairly painful in general
// and repeating them everywhere is simply too much.
func (h (*HashTable v)) Insert(key Hasher, value v) { ... }

성능/스토리지 문제로 인해 []Hasher 가 비스타터이고 Go에서 성공적인 Generics 구현을 위해서는 다음과 같은 것이 절대적으로 있어야 한다는 말씀이신가요?

// Without selecting another proposal I have no idea how the constraint might be defined or implemented so let's just pretend
type [K: Hasher, V] HashTable a struct {
   Keys   []K
   Values []V
}

func (h *HashTable) Insert(key K, value V) { ... }

내가 어디에서 왔는지 볼 수 있기를 바랍니다. 그러나 특정 코드에 부과하려는 제약 조건을 이해하지 못할 수도 있습니다. 내가 고려하지 않은 사용 사례가 있을 수 있습니다. 요구 사항이 무엇이며 제안이 어떻게 실패하는지에 대한 완전한 이해에 도달하기를 바랍니다.

아마도 우리는 내가 말할 수 있는 한 이 두 가지를 모두 수행하기 때문에 내가 제안한 것을 매우 다르게 보고 있는 것 같습니다.

인용하고 있는 섹션의 "이것"은 인터페이스 사용을 의미합니다. 문제는 당신의 제안이 그렇게 하지 않는다는 것이 아니라 당신의 제안이 대부분의 사용을 배제하는 제한된 다형성을 허용하지 않는다는 것입니다. 그리고 제네릭의 핵심 사용 사례를 실제로 다루지 않는 인터페이스에 대해 제안한 대안(내가 언급한 두 가지 때문에).

예를 들어, 귀하의 제안(원래 작성된 대로)은 실제로 모든 종류의 일반 맵 작성을 허용하지 않았습니다. 왜냐하면 == 를 사용하여 최소한 키를 비교할 수 있어야 하기 때문입니다. 지도에는 제한된 다형성이 필요합니다).

이 인터페이스와 관련된 불만과 고통에 비추어 다음이 생성되었습니다. https://golang.org/pkg/sort/#Slice

이 인터페이스는 길이와 스와핑에 대한 리플렉션에 의존하기 때문에 제네릭 제안에서 여전히 가능하지 않습니다(따라서 다시 슬라이스 작업에 제약이 있음). 그 API를 제네릭이 달성할 수 있어야 하는 것의 하한선으로 받아들인다 해도(많은 사람들은 그렇지 않을 것입니다. 해당 API의 형식 안전성 부족에 대한 불만이 여전히 많습니다), 귀하의 제안은 통과하지 못할 것입니다. 그 바.

그러나 또한, 다시 말하지만, 당신은 당신이 만든 특정 요점에 대한 응답을 인용하고 있습니다. 즉, API에서 함수 리터럴을 전달하여 제한된 다형성을 얻을 수 있다는 것입니다. 그리고 제약된 다형성이 없는 문제를 해결하기 위해 제안한 구체적인 방법은 다소 오래된 API를 구현해야 합니다. 즉, 당신은 이 주장에 대한 내 대답을 인용하고 있습니다.

우리는 정의를 func Slice(slice []a, less func(a, a) bool)로 변경하여 논의 중인 제안에서 이에 대한 성능 저하를 복구할 것입니다.

그러나 그것은 오래된 API입니다. 당신은 "제 제안은 제한된 다형성을 허용하지 않지만 문제가 되지 않습니다. 왜냐하면 우리는 제네릭을 사용할 수 없고 대신 기존 솔루션(반사/인터페이스)을 사용할 수 있기 때문입니다"라고 말합니다. 글쎄, "당신의 제안은 사람들이 제네릭을 원하는 가장 기본적인 사용 사례를 허용하지 않습니다"에 "우리는 사람들이 이미 가장 기본적인 사용 사례에 대한 제네릭 없이 하고 있는 일을 할 수 있습니다"에 응답하는 것 같지 않습니다. 어디든지, TBH. 기본적인 컨테이너 유형, sort, max… 작성에도 도움이 되지 않는 제네릭 제안은 가치가 없어 보입니다.

이것은 내가 여기에서 본 모든 제안(내 제안 포함)에서 사실입니다.

대부분의 제네릭 제안에는 유형 매개변수를 제한하는 몇 가지 방법이 포함되어 있습니다. 즉, "유형 매개변수에는 Less 메소드가 있어야 함" 또는 "유형 매개변수는 비교 가능해야 함"을 표현하는 것입니다. 당신의 AFAICT는 그렇지 않습니다.

다음 해시 테이블 정의를 고려하십시오.

귀하의 정의가 불완전합니다. a) 키 유형도 동일해야 하고 b) 다른 키 유형을 사용하는 것을 방지하지 않습니다. 즉, 이것은 합법적입니다.

type hasherA uint64

func (a hasherA) Hash() []byte {
    b := make([]byte, 8)
    binary.BigEndian.PutUint64(b, uint64(a))
    return b
}

type hasherB string

func (b hasherB) Hash() []byte {
    return []byte(b)
}

h := new(HashTable int)
h.Insert(hasherA(42), 1)
h.Insert(hasherB("Hello world"), 2)

다른 키 유형을 사용하므로 합법적이지 않아야 합니다. 즉, 컨테이너는 사람들이 원하는 정도로 유형 검사되지 않습니다. 키 유형과 값 유형 모두 에 대해 해시 테이블을 매개변수화해야 합니다.

type HashTable k v struct {
    Keys []k
    Values []v
}

func (h *(HashTable k v)) Insert(key k, value v) {
    // You can't actually do anything with k, as it's unconstrained. i.e. you can't hash it, compare it…
    // Implementing this is impossible in your proposal.
}

// If it weren't impossible, you'd get this:
h := new(HashTable hasherA int)
h[hasherA(42)] = 1
h[hasherB("Hello world")] = 2 // compile error - can't use hasherB as hasherA

또는 도움이 된다면 해시 세트를 구현하려고 한다고 상상해 보십시오. 동일한 문제가 발생하지만 이제 결과 컨테이너에는 interface{} 이상의 추가 유형 검사가 없습니다 .

이것이 바로 귀하의 제안이 가장 기본적인 사용 사례를 다루지 않는 이유입니다. 다형성을 제한하기 위해 인터페이스에 의존하지만 실제로 이러한 인터페이스의 일관성을 확인할 방법을 제공하지 않습니다. 일관된 유형 검사를 가지 거나 다형성을 제한할 수 있지만 둘 다 가질 수는 없습니다. 하지만 둘 다 필요합니다.

Go에서 성공적인 Generics 구현을 위해서는 다음과 같은 것이 절대적으로 있어야 합니다.

적어도 나는 그것에 대해 어떻게 느끼는지, 예, 거의 그렇습니다. 제안서가 유형이 안전한 컨테이너를 작성하거나 정렬하는 것을 허용하지 않으면 기존 언어에 비용을 정당화할 만큼 충분히 의미 있는 내용을 추가하지 않습니다.

@메로비우스 알겠습니다. 나는 당신 이 원하는 것을 이해했다고 생각합니다. 당신의 사용 사례는 내가 원하는 것과는 거리가 멀다는 것을 명심하십시오. 당신이 말했듯이 나는 그것이 소수의 의견일 수 있다고 생각하지만 나는 유형 안전 용기에 대해 정말로 가려워하지 않습니다. 내가 보고 싶은 가장 큰 것 중 몇 가지는 오류 대신 결과 유형과 내 제안이 처리하는 합리적인 작업을 수행하는 모든 곳에서 복제 또는 반영 없이 쉬운 슬라이스 조작입니다. 그러나 기본 사용 사례가 인터페이스를 사용하지 않고 일반 컨테이너를 작성하는 경우 "가장 기본적인 사용 사례를 다루지 않는" 관점에서 볼 수 있습니다.

이 인터페이스는 길이와 스와핑에 대한 리플렉션에 의존하기 때문에 제네릭 제안에서 여전히 가능하지 않습니다(따라서 다시 슬라이스 작업에 제약이 있음). 그 API를 제네릭이 달성할 수 있어야 하는 것의 하한선으로 받아들인다 해도(많은 사람들은 그렇지 않을 것입니다. 해당 API의 형식 안전성 부족에 대한 불만이 여전히 많습니다), 귀하의 제안은 통과하지 못할 것입니다. 그 바.

이것을 읽으면 일반 슬라이스가 이 제안에 따라 작동하는 방식을 완전히 오해했다는 것이 분명합니다. 이러한 오해를 통해 "이 인터페이스는 여전히 귀하의 제안에서 가능하지 않습니다"라는 잘못된 결론에 도달했습니다. 어떤 제안에서도 일반적인 슬라이스가 가능 해야 하며 이것이 제 생각입니다. 그리고 len() 는 다음과 같이 정의됩니다. func len(slice []a) 이것은 모든 슬라이스에 대해 비반사 방식으로 길이를 계산할 수 있음을 의미하는 일반 슬라이스 인수입니다. 이것은 위에서 말했듯이 이 제안의 많은 요점입니다(쉬운 슬라이스 조작). 그리고 제가 제시한 예제와 제가 만든 요점을 통해 잘 전달하지 못해서 죄송합니다. 일반 슬라이스는 오늘날 []int 만큼 쉽게 사용할 수 있어야 합니다. 이 문제를 해결하지 않는 모든 제안(슬라이스/배열 교환, 할당, len, cap 등)에 대해 다시 말씀드리겠습니다. ) 제 생각에는 부족합니다.

이제 우리는 서로의 목표가 무엇인지 정말 명확해졌습니다. 내가 한 일을 제안했을 때 나는 그것이 단순히 구문론적인 제안이고 세부 사항이 매우 모호하다고 말했습니다. 하지만 어쨌든 세부 사항에 대해 알아보았고 그 세부 사항 중 하나는 제약 조건의 부족으로 끝났습니다. 내가 그것을 작성할 때 나는 그것을 염두에 두지 않았습니다. 왜냐하면 그것들은 제가 하고 싶은 일에 중요하지 않기 때문입니다 , 추가할 수 없거나 바람직하지 않다는 것은 아닙니다. 제안된 구문을 계속 사용하고 제약 조건을 구부리려고 할 때의 주요 문제는 일반 인수의 정의가 현재 (의도적으로) 반복되므로 제약 조건 등을 결정하기 위해 다른 곳에서 코드를 참조하지 않는다는 것입니다. 제약 조건을 도입한다면 I 우리가 이것을 어떻게 유지할 수 있는지 보지 마십시오.

가장 좋은 반례는 앞서 논의한 정렬 기능입니다.

type Sort(slice []a:Lesser, less func(a:Lesser, a:Lesser)) { ... }

보시다시피 이것을 가능하게 하는 좋은 방법은 없으며 Generics에 대한 토큰 스팸 접근 방식이 다시 좋아지기 시작합니다. 이에 대한 제약을 정의하려면 원래 제안에서 두 가지를 변경해야 합니다.

• 형식 인수를 가리키고 제약 조건을 제공하는 방법이 필요합니다.
• 제약 조건은 단일 정의보다 더 오래 지속되어야 합니다. 아마도 해당 범위는 유형이고, 해당 범위는 파일일 수 있습니다(파일은 실제로 꽤 합리적으로 들립니다).

면책 조항: 다음은 제안에 대한 실제 수정 사항이 아닙니다. 왜냐하면 저는 그냥 무작위 기호를 던지고 있기 때문입니다. 이 구문을 예제로 사용하여 원래 그대로의 제안을 수정하기 위해 우리가 할 수 있는 일을 설명할 뿐입니다.

// Decorator style, follows the definition of the type thorugh all
// of it's methods.
<strong i="14">@a</strong>: Lesser, Hasher, Equaler
func Sort(slice []a) { ... }
<strong i="15">@k</strong>: Equaler, Hasher
type HashTable k v struct

// Inline, follows the definition of the type through
// all of it's methods.
func [a: Hasher, Equaler] Sort(slice []a) { ... }
type [k: Hasher, Equaler] HashTable k v struct

// File-scope global style, if k appears as a generic argument
// it's constrained by this that appears at the top of the file underneath
// the imports but before any other code.
<strong i="16">@k</strong>: Equaler, Hasher

다시 말하지만 위의 어느 것도 실제로 제안에 실제로 추가하고 싶지 않습니다. 나는 단지 우리가 문제를 해결하기 위해 어떤 종류의 구성을 사용할 수 있는지 보여주고 있으며, 그것들이 어떻게 보이는지는 지금 당장은 다소 부적절합니다.

그런 다음 우리가 대답해야 하는 질문은 다음과 같습니다. 암시적 일반 인수에서 여전히 가치를 얻을 수 있습니까? 제안의 요점은 언어의 깨끗한 Go-like 느낌을 유지하고, 단순하게 유지하고, 과도한 토큰을 제거하여 충분히 낮은 소음을 유지하는 것이었습니다. 예를 들어 map 함수나 Result 유형의 정의와 같이 제약 조건이 필요하지 않은 많은 경우에 보기에 좋고 Go처럼 느껴지나요? 유용한가요? 제약 조건이 어떤 형태로든 사용할 수 있다고 가정합니다.

func map(slice []a, mapper func(a) b) {
  for i := range slice {
    slice[i] = mapper(slice[i])
  }
}

type Result a b struct {
  Ok  a
  Err b
}

@aarondl 설명을 드리겠습니다. 형식 제약 조건이 필요한 이유는 형식에 대한 함수 또는 메서드를 호출할 수 있는 유일한 방법이기 때문입니다. 제약이 없는 유형 a 이것이 어떤 유형이 될 수 있는지 고려하십시오. 문자열이나 Int 또는 무엇이든 될 수 있습니다. 따라서 유형을 모르기 때문에 함수나 메서드를 호출할 수 없습니다. 유형 전환 및 런타임 리플렉션을 사용하여 유형을 가져온 다음 해당 유형에 대해 일부 함수 또는 메서드를 호출할 수 있지만 이것은 제네릭에서 피하고 싶은 것입니다. 예를 들어 a is an Animal 과 같은 유형을 제한하면 a 에서 동물에 대해 정의된 모든 메서드를 호출할 수 있습니다.

귀하의 예에서는 매퍼 함수를 ​​전달할 수 있지만 이는 함수가 많은 인수를 취하는 결과를 낳고 기본적으로 인터페이스가 없고 일급 함수만 있는 언어와 같습니다. a 유형에 사용할 모든 함수를 전달하려면 실제 프로그램에서 매우 긴 함수 목록을 얻게 됩니다. 특히 종속성 주입을 위한 일반 코드를 주로 작성하는 경우, 커플링을 최소화합니다.

예를 들어 map을 호출하는 함수도 제네릭이라면 어떻게 될까요? 를 호출하는 함수가 제네릭이면 어떻습니까? a 유형을 아직 모르는 경우 매퍼를 어떻게 정의합니까?

func m(slice []a) []b {
   mapper := func(x a) b {...}
   return map(slice, mapper)
}

mapper 를 정의하려고 할 때 x 에서 어떤 함수를 호출할 수 있습니까?

@keean 제약 조건의 목적과 기능을 이해합니다. 나는 그것들을 일반 컨테이너 구조체(말하자면 일반 컨테이너가 아님) 및 일반 슬라이스와 같은 단순한 것만큼 높이 평가하지 않으므로 원래 제안에 포함하지도 않았습니다.

나는 여전히 인터페이스가 의존성 주입을 수행하는 위치에 대해 이야기하는 것과 같은 문제에 대한 올바른 답이라고 믿습니다. 그것은 단순히 제네릭에 적합한 장소가 아닌 것 같지만 제가 누구를 말해야 할까요? 내 눈에는 그들의 책임 간의 중첩이 상당히 커서 @Merovius 와 내가 그들 없이 살 수 있는지 여부에 대해 논의해야 했던 이유는 그가 일부 사용 사례에서 유용할 것이라고 확신하게 했기 때문입니다. 내가 원래 만든 제안에 기능을 추가하기 위해 우리가 할 수 있는 일을 조금 탐구했습니다.

귀하의 예와 같이 x에서 함수를 호출할 수 없습니다. 그러나 그 자체로 매우 유용한 다른 슬라이스와 마찬가지로 슬라이스에서 작업할 수 있습니다. 또한 func 내부의 func가 무엇인지 확실하지 않습니다... 아마도 var에 할당하려고 했습니까?

@아론들
덕분에 구문을 수정했지만 의미는 여전히 명확한 것 같습니다.

내가 위에서 제시한 예제는 매개변수 다형성과 인터페이스를 모두 사용하여 어느 정도의 일반 프로그래밍 수준을 달성했지만 다중 디스패치의 부족은 항상 달성 가능한 일반성 수준에 상한선을 둡니다. 따라서 Go는 내가 원하는 언어로 기능을 제공하지 않을 것으로 보입니다. 그렇다고 해서 일부 작업에 Go를 사용할 수 없다는 의미는 아닙니다. 사실 저는 이미 사용 중이며 잘 작동합니다. 실제로 하나의 정의만 필요한 코드를 잘라내어 붙여넣습니다. 앞으로 해당 코드를 변경해야 하는 경우 개발자가 붙여넣은 모든 인스턴스를 찾을 수 있기를 바랍니다.

그러면 언어에 큰 변화 없이 가능한 제한된 보편성이 추가될 복잡성을 고려할 때 좋은 생각인지 여부에 대해 두 가지 생각을 하고 있습니다. 아마도 Go는 단순하게 유지하는 것이 더 낫습니다. 사람들은 이러한 기능을 제공하기 위해 사전 처리 또는 Go로 컴파일되는 다른 언어와 같은 매크로를 추가할 수 있습니까? 반면에 매개변수 다형성을 추가하는 것은 좋은 첫 번째 단계가 될 것입니다. 이러한 유형 매개변수를 제한하는 것은 좋은 다음 단계가 될 것입니다. 그런 다음 관련 유형 매개변수를 인터페이스에 추가할 수 있고 합리적으로 일반적인 것을 가질 수 있지만 다중 디스패치 없이 얻을 수 있는 범위일 것입니다. 별도의 더 작은 기능으로 분할하면 해당 기능이 승인될 가능성이 높아집니다.

@keean
다중 디스패치가 꼭 필요한가요? 기본적으로 지원하는 언어는 거의 없습니다. C++에서도 지원하지 않습니다. C#은 dynamic 를 통해 그것을 지원하지만 실제로 사용한 적이 없으며 일반적으로 키워드는 실제 코드에서 매우 드뭅니다. 내가 기억하는 예는 제네릭을 작성하지 않고 JSON 구문 분석과 같은 것을 처리합니다.

다중 디스패치가 꼭 필요한가요?

IMHO, @keean은 typeclasses /인터페이스가 제공하는 정적 다중 디스패치에 대해 이야기한다고 생각합니다.
이것은 메서드 오버로딩을 통해 C++에서도 제공됩니다(C#은 모르겠습니다).

당신이 의미하는 것은 공용체 유형이 없는 정적 언어에서 상당히 번거로운 동적 다중 디스패치입니다. 동적 언어는 정적 유형 검사(동적 언어에 대한 부분 유형 추론, C#의 "동적" 유형에 대해 동일)를 생략하여 이 문제를 우회합니다.

유형을 "단지" 매개변수로 제공할 수 있습니까?

func Append(t, t2 type, arr []t, value t2) []t {
    v := t(value) // conversion
    return append(arr, v)
}

var arr []float64
v := 0

arr = Append(float64, int, arr, v)

@Inuart 는 다음과 같이 썼습니다.

유형을 "단지" 매개변수로 제공할 수 있습니까?

어느 정도 이것이 가능하거나 원하는지 의문입니다.

일반 제약 조건이 지원되는 경우 원하는 것을 대신 달성할 수 있습니다.

func Append(arr []t, value s) []t  requires Convertible<s,t>{
    v := t(value) // conversion
    return append(arr, v)
}

var arr []int64
v := 0.5

arr = Append(arr, v)

또한 이것은 제약 조건에서도 가능해야 합니다.

func convert(value s) t requires Convertible<s,t>{
    return t(value);
}

f:float64:=2.0

i:int64=convert(f)

그만한 가치가 있기 때문에 Genus 언어는 다중 발송을 지원합니다. 제약 조건에 대한 모델은 디스패치되는 여러 구현을 제공할 수 있습니다.

컴파일 시간 안전을 위해 Convertible<s,t> 표기법이 필요하지만 런타임 검사로 저하될 수 있음을 이해합니다.

func Append(t, t2 type, arr []t, value t2) []t {
    v, ok := t(value) // conversion
    if !ok {
        panic(...) // or return an err
    }
    return append(arr, v)
}

var arr []float64
v := 0

arr = Append(float64, int, arr, v)

그러나 이것은 reflect 에 대한 구문 설탕처럼 보입니다.

@Inuart 요점은 컴파일러가 컴파일 타임에 유형 클래스를 구현하는 유형을 확인할 수 있으므로 런타임 검사가 필요하지 않다는 것입니다. 이점은 더 나은 성능(이른바 제로 비용 추상화)입니다. 런타임 검사인 경우 reflect 사용할 수도 있습니다.

@크레커

다중 디스패치가 꼭 필요한가요?

나는 이것에 대해 너무 마음에 든다. 한편으로 다중 디스패치(다중 매개변수 유형 클래스 포함)는 'Go'가 '인터페이스 값'이라고 부르는 실존 항목과 잘 작동하지 않습니다.

type Equals<T> interface {eq(right T) bool}
(left I) eq(right I) bool {return left == right}
(left I) eq(right F) bool {return false}
(left F) eq(right I) bool {return false}
(left F) eq(right F) bool {return left == right}

func main() {
    x := []Equals<?>{I{2}, F{4.0}, I{2}, F{4.0}}
}

오른쪽 매개변수가 동일한 컬렉션에 있음을 나타낼 방법이 없기 때문에 Equals 조각을 정의할 수 없습니다. Haskell에서는 이 작업조차 할 수 없습니다.

data Equals = forall a . IEquals a a => Equals a

이것은 유형이 자신과만 비교될 수 ​​있도록 하기 때문에 좋지 않습니다.

data Equals = forall a b . IEquals a b => Equals a

b 가 a 와 같은 컬렉션의 또 다른 존재가 되도록 제한할 방법이 없기 때문에 이것은 좋지 않습니다( a 가 컬렉션에 있는 경우).

그러나 새로운 유형으로 확장하기가 매우 쉽습니다.

(left K) eq(right I) bool {return false}
(left K) eq(right F) bool {return false}
(left I) eq(right K) bool {return false}
(left F) eq(right K) bool {return false}
(left K) eq(right K) bool {return left == right}

그리고 이것은 기본 인스턴스나 전문화를 사용하면 훨씬 더 간결해질 것입니다.

반면에 우리는 이것을 바로 지금 작동하는 'Go'로 다시 작성할 수 있습니다.

package main

type I struct {v int}
type F struct {v float32}

type EqualsInt interface {eqInt(left I) bool}
func (right I) eqInt (left I) bool {return left == right}
func (right F) eqInt (left I) bool {return false}

type EqualsFloat interface {eqFloat(left F) bool}
func (right I) eqFloat (left F) bool {return false}
func (right F) eqFloat (left F) bool {return left == right}

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

type EqualsLeft interface {eq(right EqualsRight) bool}
func (left I) eq (right EqualsRight) bool {return right.eqInt(left)}
func (left F) eq (right EqualsRight) bool {return right.eqFloat(left)}

type Equals interface {
    EqualsLeft
    EqualsRight
}

func main() {
    x := []Equals{I{2}, F{4.0}, I{2}, F{4.0}}
    println(x[0].eq(x[1]))
    println(x[1].eq(x[0]))
    println(x[0].eq(x[2]))
    println(x[1].eq(x[3]))
}

이것은 실존적(인터페이스 값)과 잘 작동하지만, 훨씬 더 복잡하고 진행 상황과 작동 방식을 보기가 더 어렵습니다. 유형당 하나의 인터페이스가 필요하고 허용 가능한 하드 코딩을 해야 한다는 큰 제한이 있습니다. 다음과 같은 오른쪽 유형:

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

즉, EqualsRight 인터페이스는 확장할 수 없기 때문에 새 유형을 추가하려면 라이브러리 소스를 수정해야 합니다.

따라서 다중 매개변수 인터페이스가 없으면 같음과 같은 확장 가능한 일반 연산자를 정의할 수 없습니다. 다중 매개변수 인터페이스를 사용하면 존재(인터페이스 값)가 문제가 됩니다.

제안된 많은 구문(구문?) Blah[E] 에 대한 나의 주요 문제는 기본 유형이 제네릭을 포함하는 것에 대한 정보를 표시하지 않는다는 것입니다.

예를 들어:

type Comparer[C] interface {
    Compare(other C) bool
}
// or
type Comparer c interface {
    Compare(other c) bool
}
...

이것은 우리가 기본 유형에 더 많은 정보를 추가하는 새로운 유형을 선언한다는 것을 의미합니다. type 선언의 요지는 다른 유형에 따라 이름을 정의하는 것 아닌가요?

나는 더 많은 라인을 따라 구문을 제안 할 것입니다

type Comparer interface[C] {
    Compare(other C) bool
}

즉, 실제로 Comparer 는 interface[C] { ... } 기반의 유형이고 interface[C] { ... } 는 물론 interface { ... } 과 별개의 유형입니다. 이렇게 하면 원하는 경우 이름을 지정하지 않고 일반 인터페이스를 사용할 수 있습니다(일반 인터페이스에서 허용됨). 이 솔루션이 좀 더 직관적이고 Go의 유형 시스템에서 잘 작동한다고 생각합니다.

참고: 제네릭 유형 선언은 다음 구문을 사용하는 인터페이스, 구조체 및 함수에서만 허용됩니다.
interface[G] { ... }
struct[G] { ... }
func[G] (vars...) { ... }

그런 다음 제네릭을 "구현"하면 다음 구문이 됩니다.
interface[G] { ... }[string]
struct[G] { ... }[string]
func[G] (vars...) { ... }[int](args...)

좀 더 명확하게 하기 위해 몇 가지 예를 들면 다음과 같습니다.

인터페이스

package add

type Adder interface[E] {
    // Adds the element and returns the size
    Add(elem E) int
}

// Adds the integer 5 to any implementation of Adder[int].
func AddFiveTo(a Adder[int]) int {
    return a.Add(5)
}

구조체

package heap

type List struct[T] {
    slice []T
}

func (l *List) Add(elem T) { // T is a type defined by the receiver
    l.slice = append(l.slice, elem)
}

기능

func[A] AddManyTo(a Adder[A], many ...A) {
    for _, each := range a {
        a.Add(each)
    }
}

이것은 Go2 계약 초안에 대한 응답이며 해당 구문을 사용하지만 매개변수 다형성에 대한 모든 제안에 적용되므로 여기에 게시합니다.

유형 매개변수를 포함하면 안 됩니다.

고려하다

type X(type T C) struct {
  R // A regular type with method Foo()
  T // Some type parameter
}
// X defines some methods other than Foo(),
// some of which invoke Foo.

일부 임의 유형 R 및 Foo() 를 포함하지 않는 임의의 계약 C Foo() .

T 에는 C 에 필요한 모든 선택기가 있지만 T Foo 를 포함하여 임의의 다른 선택기가 있을 수도 있습니다.

Bar 가 C 에서 허용되는 구조체이고 Foo 라는 필드가 있다고 가정해 보겠습니다.

X(Bar) 는 불법 인스턴스화일 수 있습니다. 형식에 선택기가 없는 계약을 지정하는 방법이 없으면 이것은 유추된 속성이어야 합니다.

X(Bar) Foo X(Bar).R.Foo 로 계속 확인할 수 있습니다. 이것은 제네릭 유형을 작성하는 것을 가능하게 하지만 해결 규칙의 nitpickery에 익숙하지 않은 독자에게 혼동을 줄 수 있습니다. X 의 메소드 외부에서 선택자는 모호한 상태로 유지되지만 interface { Foo() } 는 X 의 매개변수에 의존하지 않고 X 의 일부 인스턴스화는 만족하지 마십시오.

유형 매개변수의 포함을 허용하지 않는 것이 더 간단합니다.

(그러나 이것이 허용된다면 type S = io.Reader 로 정의된 임베디드 S 의 필드 이름이 T S 인 것과 같은 이유로 필드 이름은 T가 됩니다. Reader 가 아니라 T 를 인스턴스화하는 유형이 반드시 이름을 가질 필요는 없기 때문입니다.)

@jimmyfrasche 제네릭 타입의 임베디드 필드는 약간의 어색함이 있더라도 허용하는 것이 좋을 만큼 충분히 유용하다고 생각합니다. 내 제안은 모든 일반 코드에서 임베디드 유형 이 가능한 모든 수준에서 가능한 모든 필드와 메소드를 정의하여 일반 코드 내에서 비제네릭 유형의 모든 임베디드 메소드와 필드가 지워진다고 가정하는 것입니다.

그래서 주어진:

type R struct(type T) {
    io.Reader
    T
}

R의 메서드는 Reader를 통한 간접 지정 없이 R에서 읽기를 호출할 수 없습니다. 예를 들어:

func (r R) Do() {
     r.Read(buf)     // Illegal
     r.Reader.Read(buf)  // ok
}

내가 볼 수 있는 유일한 단점은 동적 유형이 정적 유형보다 더 많은 멤버를 포함할 수 있다는 것입니다. 예를 들어:

func (r R) Do() {
    var x interface{} = r
    x.(io.Reader)    // Succeeds
}

@rogpeppe

내가 볼 수 있는 유일한 단점은 동적 유형이 정적 유형보다 더 많은 멤버를 포함할 수 있다는 것입니다.

이것은 유형 매개변수를 직접 사용하는 경우이므로 매개변수 유형에서도 괜찮을 것이라고 생각합니다. @jimmyfrasche 가 제시한 문제에 대한 해결책은 매개변수화된 유형의 원하는 메소드 세트를 계약에 넣는 것일 수 있다고 생각합니다.

contract C(t T) {
  interface { Foo() } (X(T){})
  // ...
}

type X(type T C) struct {
  R // A regular type with method Foo()
  T // Some type parameter
}
// X defines some methods other than Foo(),
// some of which invoke Foo.

이렇게 하면 Foo X 를 직접 호출할 수 있습니다. 물론 이것은 "계약에 로컬 이름 없음" 규칙에 위배됩니다...

@stevenblenkinsop 흠, 어색하면 X 를 언급하지 않고 할 수 있습니다.

contract C(t T) {
  struct{ R; T }{}.Foo
}

C 는 약간 더 느슨하지만 X 의 구현에 여전히 바인딩되어 있습니다.

그렇게 하지 않고 글을 쓴다면

func (x X(T)) Fooer() interface { Foo() } {
  return x
}

컴파일합니까? @rogpeppe 의 규칙에 따르지 않을 것이므로 계약에서 보증을 하지 않을 때도 채택해야 할 것 같습니다. 그러나 충분한 계약 없이 또는 모든 임베딩에 대해 형식 인수를 포함할 때만 적용됩니까?

그냥 허용하지 않는 것이 더 쉬울 것입니다.

나는 Go2 초안이 발표되기 전에 이 제안에 대한 작업을 시작했습니다.

공고를 보았을 때 기꺼이 내 것을 스크랩할 준비가 되었지만 여전히 초안의 복잡성이 불안해져서 내 작업을 완료했습니다. 덜 강력하지만 더 간단합니다. 다른 것이 아니라면 훔칠 가치가 있는 비트가 있을 수 있습니다.

@ianlancetaylor 의 초기 제안 구문을 확장합니다. 내가 시작할 때 사용할 수 있었던 것이기 때문입니다. 그것은 근본적인 것이 아닙니다. (type T 등의 구문이나 이에 상응하는 것으로 대체될 수 있습니다. 의미론에 대한 표기법으로 일부 구문이 필요했습니다.

위치: https://gist.github.com/jimmyfrasche/656f3f47f2496e6b49e041cd8ac716e4

규칙은 (1) 형식 인수의 ID가 알려져 있지 않거나 (2) 메서드가 외부에서 호출할 수 있다고 주장되지 않는 한 포함된 형식 매개변수의 것보다 더 깊은 깊이에서 승격된 메서드를 호출할 수 없다는 것입니다. 유형 매개변수를 제한하는 계약에 따라 유형을 입력합니다. 컴파일러는 또한 외부 유형 O 내에서 승격된 메소드가 가져야 하는 깊이의 상한 및 하한을 결정할 수 있으며, 이를 사용하여 O 를 포함하는 유형에서 메소드를 호출할 수 있는지 여부를 결정할 수 있습니다. 즉, 다른 홍보 방법과 충돌 가능성이 있는지 여부. 호출 가능한 메서드가 있다고 주장되는 모든 형식 매개 변수에도 유사한 것이 적용됩니다. 여기서 형식 매개 변수 내 메서드의 깊이 범위는 [0, inf)입니다.

유형 매개변수를 포함하는 것은 완전히 금지하기에는 너무 유용해 보입니다. 우선, 임베딩 인터페이스의 패턴이 허용하지 않는 투명한 구성을 허용합니다.

또한 계약을 정의할 때 잠재적인 용도를 찾았습니다. *T 에 정의된 메서드가 있는 T 유형의 값(포인터 유형일 수 있음)을 허용하고 해당 값을 인터페이스에서 메소드가 *T 에 있을 수 있기 때문에 인터페이스에 T 를 반드시 넣을 수는 없으며 *T T 인터페이스에 넣을 수는 없습니다. *T 에는 빈 메소드 세트가 있을 수 있음). 그러나 다음과 같은 래퍼가 있는 경우

type Wrapper(type T) { T }

계약에 인터페이스가 만족한다고 명시되어 있으면 모든 경우에 인터페이스에 *Wrapper(T) 를 넣을 수 있습니다.

그냥 하면 안되나요

type Interface interface {
  SomeMethod(int) error
}

contract MightBeAPointer(t T) {
  Interface(t)
}

func Example(type T MightBeAPointer)(v T) {
  var i Interface = v
  // ...
}

누군가가 전화하는 경우를 처리하려고합니다

type S struct{}
func (s *S) SomeMethod(int) error { ... }
...
var s S
Example(S)(s)

S 는 Interface 로 변환할 수 없고 *S 만 변환할 수 있기 때문에 작동하지 않습니다.

물론 대답은 "하지 마십시오"일 수 있습니다. 그러나 계약 제안서에는 다음과 같은 계약이 설명되어 있습니다.

contract Contract(t T) {
    var _ error = t.SomeMethod(int(0))
}

S 는 *S 와 마찬가지로 자동 주소 지정으로 인해 이 계약을 충족합니다. 내가 해결하려고 하는 것은 계약에서 메서드 호출과 인터페이스 변환 사이의 기능 격차입니다.

어쨌든 이것은 임베딩 유형 매개변수에 대한 한 가지 잠재적인 용도를 보여주는 약간의 접선입니다.

다시 임베딩, "구조체에 임베드 가능"은 허용되는 경우 계약이 캡처해야 하는 또 다른 제한 사항이라고 생각합니다.

고려하다:

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
}

type Embedded(type First, Second Embeddable) struct {
        First
        Second
}

// Error: First and Second both provide method Read.
// That must be diagnosed to the Embeddable contract, not the definition of Embedded itself.
type Boom = Embedded(*bytes.Buffer, *strings.Reader)

모호한 선택기가 있는 @bcmills 임베딩 유형이 허용되므로 해당 계약이 어떻게 해석되어야 하는지 잘 모르겠습니다.

어쨌든 알려진 유형만 포함한다면 괜찮습니다. 유형 매개변수만 포함하는 경우 괜찮습니다. 이상해지는 유일한 경우는 하나 이상의 알려진 유형과 하나 이상의 유형 매개변수를 포함한 다음 알려진 유형의 선택자와 유형 인수가 분리되지 않은 경우입니다.

모호한 선택기가 있는 @bcmills 임베딩 유형이 허용되므로 해당 계약이 어떻게 해석되어야 하는지 잘 모르겠습니다.

흠, 좋은 지적입니다. 오류를 유발하는 제약 조건이 하나 더 없습니다.¹

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
    var _ io.Reader = S{}
}

¹ https://play.golang.org/p/3wSg5aRjcQc

X 또는 Y 중 하나가 필요하지만 둘 다 io.Reader 필요는 없습니다. 계약 시스템이 그것을 허용할 만큼 충분히 표현력이 있다는 것이 흥미롭습니다. 그런 짐승에 대한 형식 유추 규칙을 알아낼 필요가 없어 기쁩니다.

그러나 그것은 정말로 문제가 아닙니다.

당신이 할 때입니다

type S (type T C) struct {
  io.Reader
  T
}
func (s *S(T)) X() io.Reader {
  return s
}

C T 에 Read 선택기가 있을 수 있기 때문에 컴파일에 실패해야 합니다.

struct{ io.Reader; T }.Read

그러나 C 가 선택기 세트가 분리되어 있는지 확인하지 않고 S 가 선택기를 참조하지 않는 경우 규칙은 무엇입니까? 모호한 선택기를 생성하는 유형을 제외하고 모든 인스턴스화 S 가 인터페이스를 만족시킬 수 있습니까?

모호한 선택기를 생성하는 유형을 제외하고 모든 인스턴스화 S 가 인터페이스를 만족시킬 수 있습니까?

네, 그런 것 같습니다. 더 깊은 뜻이 있는 건 아닐까... 🤔

나는 회복할 수 없을 정도로 불쾌한 것을 구성할 수 없었지만 비대칭은 상당히 불쾌하고 나를 불안하게 만듭니다.

type I interface { /* ... */ }
a := G(A) // ok, A satisfies contract
var _ I = a // ok, no selector overlap
b := G(B) // ok, B satisfies contract
var _ = b // error, selector overlap

G0(B) 가 G1(B) 를 사용할 때 오류 메시지가 걱정됩니다. . . Gn(B) 를 사용하고 Gn 는 오류를 일으키는 것입니다. . . .

FTR을 사용하면 포함 시 유형 오류를 트리거하기 위해 모호한 선택기의 문제를 겪을 필요가 없습니다.

// Error: Duplicate field name Reader
type Boom = Embedded(*bytes.Reader, *strings.Reader)

포함된 필드 이름은 인수 유형을 기반으로 하지만 포함된 유형 매개변수의 이름일 가능성이 더 높다고 가정합니다. 이는 유형 별칭을 포함하고 필드 이름이 별칭을 지정하는 유형의 이름이 아니라 별칭인 경우와 같습니다.

이것은 실제로 매개변수화된 유형 에 대한 섹션의 초안 디자인에 지정되어 있습니다.

매개 변수화된 형식이 구조체이고 형식 매개 변수가 구조체의 필드로 포함된 경우 필드 이름은 형식 인수의 이름이 아니라 형식 매개 변수의 이름입니다.

type Lockable(type T) struct {
    T
    mu sync.Mutex
}

func (l *Lockable(T)) Get() T {
    l.mu.Lock()
    defer l.mu.Unlock()
    return l.T
}

(참고: 메서드 선언에 Lockable(X)을 작성하면 제대로 작동하지 않습니다. 메서드가 lT 또는 lX를 반환해야 하나요? 구조체에 형식 매개변수를 포함하는 것을 단순히 금지해야 합니다.)

나는 그저 옆자리에 앉아서 관찰하고 있을 뿐입니다. 그러나 또한 약간 걱정됩니다.

내가 말하기 부끄럽지 않은 한 가지는 이 토론의 90%가 내 머리 위에 있다는 것입니다.

제네릭 또는 매개변수 다형성이 무엇인지도 모르는 상태에서 소프트웨어를 작성하여 20년 동안 생계를 유지했지만 작업을 완료하는 데 방해가 되지 않았습니다.

슬프게도 나는 바둑을 배우기 위해 약 1년 전에 시간을 냈습니다. 나는 그것이 가파른 학습 곡선이고 생산적이 되기까지 너무 오래 걸릴 것이라는 잘못된 가정을 했습니다.

내가 더 틀릴 수 없었다.

나는 주말도 안되어 성능 문제를 겪고 있던 node.js 서비스를 완전히 파괴하는 마이크로 서비스를 구축하기에 충분한 Go를 배울 수 있었습니다.

아이러니하게도 나는 그저 놀고만 있었다. 나는 바둑으로 세계를 정복하는 것에 대해 특별히 진지하지 않았다.

그러나 두어 시간 만에 나는 마치 액션 스릴러를 보고 있는 것처럼 구부정한 패배자세로 자리에서 일어났다. 내가 만들고 있던 API가 너무 빨리 모였습니다. 나는 이것이 디자인 면에서 분명히 매우 실용적이기 때문에 이것이 정말로 나의 소중한 시간을 투자할 가치가 있는 언어라는 것을 깨달았습니다.

그리고 그것이 내가 Go에 대해 좋아하는 것입니다. 그것은 매우 빠릅니다 ..... 배우기 위해. 우리 모두는 성능 기능을 알고 있습니다. 그러나 배울 수 있는 속도는 제가 수년 동안 배운 다른 8개 언어와 비교할 수 없습니다.

그 이후로 나는 바둑을 찬양하며 4명의 Devs를 더 사랑하게 되었습니다. 나는 단지 몇 시간 동안 그들과 함께 앉아서 무언가를 만듭니다. 결과가 말해줍니다.

단순함과 학습 속도. 이것이 언어의 진정한 킬러 ​​기능입니다.

수개월 동안 열심히 학습해야 하는 프로그래밍 언어는 유치하려는 개발자를 유지하지 못하는 경우가 많습니다. 우리는 해야 할 일이 있고 매일 진행 상황을 보고 싶어하는 고용주가 있습니다(Agile 감사합니다, 감사합니다).

따라서 Go 팀이 고려할 수 있는 두 가지 사항이 있습니다.

1) 우리가 해결하고자 하는 일상적인 문제는 무엇입니까?

제네릭에 의해 해결되는 쇼 스토퍼 또는 호출되는 모든 것이 포함된 실제 사례를 찾을 수 없는 것 같습니다.

이러한 언어 변경 제안으로 개선할 수 있는 방법의 예와 함께 문제가 있는 일상 작업의 요리책 스타일 예.

2) Go의 다른 모든 훌륭한 기능과 마찬가지로 단순하게 유지하십시오.

여기에 믿을 수 없을 정도로 지적인 댓글이 있습니다. 하지만 저와 같은 일반 프로그래밍을 위해 매일 Go를 사용하는 대부분의 개발자는 있는 그대로의 작업에 완벽하게 만족하고 생산적이라고 확신합니다.

아마도 그러한 고급 기능을 활성화하기 위한 컴파일러 인수가 있습니까? '--하드코어'

컴파일러 성능에 부정적인 영향을 미친다면 정말 슬플 것입니다. 그냥 말해

그리고 그것이 내가 Go에 대해 좋아하는 것입니다. 그것은 매우 빠릅니다 ..... 배우기 위해. 우리 모두는 성능 기능을 알고 있습니다. 그러나 배울 수 있는 속도는 제가 수년 동안 배운 다른 8개 언어와 비교할 수 없습니다.

완전히 동의 해. 완전히 컴파일된 언어에서 강력함과 단순함의 조합은 완전히 고유한 것입니다. 나는 확실히 Go가 그것을 잃는 것을 원하지 않으며 제네릭을 원하는 만큼 그 비용으로 가치가 있다고 생각하지 않습니다. 그렇다고 잃어버릴 필요는 없다고 생각합니다.

제네릭에 의해 해결되는 쇼 스토퍼 또는 호출되는 모든 것이 포함된 실제 사례를 찾을 수 없는 것 같습니다.

제네릭에 대한 두 가지 주요 사용 사례가 있습니다. 이진 트리, 집합 및 sync.Map 와 같은 복잡한 데이터 구조의 유형 안전 상용구 제거 및 기반으로 작동하는 _compile-time_ 유형 안전 함수를 작성하는 기능입니다. 메모리의 레이아웃이 아니라 순전히 인수의 기능에 관한 것입니다. 내가 할 수 있는 것보다 더 멋진 것들이 있지만 언어의 단순함을 완전히 깨뜨리지 않고 지원을 추가하는 것이 불가능하다면 그것을 할 수 _없게_ 신경쓰지 않을 것입니다.

솔직히 말해서, 언어에는 이미 상당히 남용되는 기능이 있습니다. 그들이 그렇게 자주 남용되지 _않은_ 주된 이유는 대부분의 경우 깨끗하고 찾기 쉬운 이러한 코드의 예를 제공하는 표준 라이브러리와 결합된 '관용적' 코드를 작성하는 Go 문화 때문이라고 생각합니다. 표준 라이브러리에 제네릭을 잘 사용하는 것은 구현될 때 확실히 우선순위가 되어야 합니다.

@camstuart

제네릭에 의해 해결되는 쇼 스토퍼 또는 호출되는 모든 것이 포함된 실제 사례를 찾을 수 없는 것 같습니다.

제네릭은 코드를 직접 작성할 필요가 없습니다. 따라서 다른 연결 목록, 이진 트리, 데크 또는 우선 순위 대기열을 다시 구현할 필요가 없습니다. 정렬 알고리즘, 분할 알고리즘 또는 회전 알고리즘 등을 구현할 필요가 없습니다. 데이터 구조는 표준 컬렉션(예: 목록의 맵)을 구성하고 처리는 표준 알고리즘을 구성합니다(데이터, 파티션, 그리고 회전). 이러한 구성 요소를 재사용할 수 있다면 오류율이 낮아집니다. 왜냐하면 우선 순위 대기열 또는 분할 알고리즘을 다시 구현할 때마다 오류가 발생하여 버그가 발생할 가능성이 있기 때문입니다.

제네릭이란 적은 코드를 작성하고 더 많이 재사용한다는 것을 의미합니다. 즉, 잘 유지 관리되는 표준 라이브러리 기능과 추상 데이터 유형을 더 많은 상황에서 사용할 수 있으므로 직접 작성할 필요가 없습니다.

더 나은 점은 이 모든 것이 지금 당장 Go에서 기술적으로 수행될 수 있지만 일부 잠재적으로 주요 런타임 오버헤드와 함께 컴파일 시간 형식 안전성이 거의 완전히 손실된다는 것입니다. 제네릭을 사용하면 이러한 단점 없이 수행할 수 있습니다.

일반 함수 구현:

/*

* "generic" is a KIND of types, just like "struct", "map", "interface", etc...
* "T" is a generic type (a type of kind generic).
* var t = T{int} is a value of type T, values of generic types looks like a "normal" type

*/

type T generic {
    int
    float64
    string
}

func Sum(a, b T{}) T{} {
    return a + b
}

함수 호출자:

Sum(1, 1) // 2
// same as:
Sum(T{int}(1), T{int}(1)) // 2

일반 구조체 구현:

type ItemT generic {
    interface{}
}

type List struct {
    l []ItemT{}
}

func NewList(t ItemT) *List {
    l := make([]t)
    return &List{l}
}

func (p *List) Push(item ItemT{}) {
    p.l = append(p.l, item)
}

방문객:

list := NewList(ItemT{int})
list.Push(42)

누군가 Swift를 배우고 좋아하지는 않지만 Go, C, Java 등과 같은 다른 언어에 대한 풍부한 경험을 가지고 있습니다. 저는 제네릭(또는 템플릿 또는 무엇이라고 부르고 싶은지)이 Go 언어에 추가하는 것이 좋지 않다고 믿습니다.

아마도 나는 현재 버전의 Go에 더 익숙하지만 다른 사람들이 작성한 코드를 이해하는 것이 더 어렵다는 점에서 이것은 C++로의 회귀처럼 느껴집니다. 유형에 대한 고전적인 T 자리 표시자는 함수가 수행하려는 작업을 이해하기 어렵게 만듭니다.

나는 이것이 인기있는 기능 요청이라는 것을 알고 있으므로 도착하면 처리할 수 있지만 2센트(의견)를 추가하고 싶었습니다.

@jlubawy
연결 목록이나 퀵소트 알고리즘을 구현하지 않아도 되는 다른 방법을 알고 있습니까? Alexander Stepanov가 지적했듯이 대부분의 프로그래머는 "최소" 및 "최대" 기능을 올바르게 정의할 수 없으므로 많은 디버깅 시간 없이 더 복잡한 알고리즘을 올바르게 구현해야 합니다. 라이브러리에서 이러한 알고리즘의 표준 버전을 가져오고 내가 가진 유형에 적용하는 것이 훨씬 낫습니다. 어떤 대안이 있습니까?

@jlubawy

또는 템플릿, 또는 당신이 그것을 부르고 싶은 무엇이든

모든 것은 구현에 달려 있습니다. 우리가 C++ 템플릿에 대해 이야기하고 있다면 그렇습니다. 일반적으로 이해하기 어렵습니다. 그것들을 쓰는 것조차 어렵습니다. 반면에 C# 제네릭을 사용하면 완전히 다른 문제입니다. 여기서 개념 자체는 문제가 되지 않습니다.

당신이 모른다면, Go 팀은 Go 2.0의 초안을 발표했습니다:
https://golang.org/s/go2designs

Go 2.0(계약)의 Generics 디자인에 대한 초안이 있습니다. Wiki 를 살펴보고 피드백 을 제공할 수 있습니다.

관련 섹션:

제네릭

• 개요
• 초안 디자인
• 위키 피드백 페이지

초안을 읽은 후 다음과 같이 질문합니다.

왜

T: 추가 가능

"추가 가능한 계약을 구현하는 유형 T"를 의미합니까? 새로 추가하는 이유
우리가 이미 인터페이스를 가지고 있을 때 개념은 무엇입니까? 인터페이스 할당은
빌드 시간에 체크인 했으므로 이미 필요하지 않은 수단이 있습니다.
여기에 추가 개념. 이 용어를 사용하여 다음과 같이 말할 수 있습니다.
인터페이스 Addable을 구현하는 유형 T. 또한 T:_ 또는 T:Any
(Any 특수 키워드 또는 인터페이스{}의 기본 제공 별칭)은
트릭.

왜 그런 것들을 대부분 다시 구현해야 하는지 모르겠습니다. 아니오
감지 및 중복됩니다(중복은 오류 wrt의 새로운 처리이므로
공황 처리).

2018-09-14 6:15 GMT-05:00 Koala Yeung [email protected] :

당신이 모른다면, Go 팀은 Go 2.0의 초안을 발표했습니다:
https://golang.org/s/go2designs

Go 2.0(계약)의 Generics 디자인에 대한 초안이 있습니다. 당신은 원할 수도 있습니다
살펴보고 피드백을 주기 위해
Wiki의 https://github.com/golang/go/wiki/Go2GenericsFeedback
https://github.com/golang/go/wiki/Go2GenericsFeedback .

관련 섹션:

제네릭

• 개요
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [초안 디자인] (https://go.googlesource.com/proposal/+/master/design/
  go2draft-contracts.md)
• 위키 피드백 페이지
  https://github.com/golang/go/wiki/Go2Generics피드백

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/15292#issuecomment-421326634 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
TripleMint에서 사용할 메일 서명 테스트입니다.

편집: "[...] 특정 요구 사항이 필요하지 않으면 트릭을 수행합니다.
유형 인수".

2018-09-17 11:10 GMT-05:00 루이스 마수 엘리 [email protected] :

초안을 읽은 후 다음과 같이 질문합니다.

왜

T: 추가 가능

"추가 가능한 계약을 구현하는 유형 T"를 의미합니까? 새로 추가하는 이유
우리가 이미 인터페이스를 가지고 있을 때 개념은 무엇입니까? 인터페이스 할당은
빌드 시간에 체크인 했으므로 이미 필요하지 않은 수단이 있습니다.
여기에 추가 개념. 이 용어를 사용하여 다음과 같이 말할 수 있습니다.
인터페이스 Addable을 구현하는 유형 T. 또한 T:_ 또는 T:Any
(Any 특수 키워드 또는 인터페이스{}의 기본 제공 별칭)은
트릭.

왜 그런 것들을 대부분 다시 구현해야 하는지 모르겠습니다. 아니오
감지 및 중복됩니다(중복은 오류 wrt의 새로운 처리이므로
공황 처리).

2018-09-14 6:15 GMT-05:00 Koala Yeung [email protected] :

당신이 모른다면, Go 팀은 Go 2.0의 초안을 발표했습니다:
https://golang.org/s/go2designs

Go 2.0(계약)의 Generics 디자인에 대한 초안이 있습니다. 당신은 할 수있다
살펴보고 피드백을 하고 싶습니다
Wiki의 https://github.com/golang/go/wiki/Go2GenericsFeedback
https://github.com/golang/go/wiki/Go2GenericsFeedback .

관련 섹션:

제네릭

• 개요
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [초안 디자인] (https://go.googlesource.com/p
  roposal/+/master/design/go2draft-contracts.md
  https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
  )
• 위키 피드백 페이지
  https://github.com/golang/go/wiki/Go2Generics피드백

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/15292#issuecomment-421326634 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
TripleMint에서 사용할 메일 서명 테스트입니다.

--
TripleMint에서 사용할 메일 서명 테스트입니다.

@luismasuelli-jobsity Go의 제네릭 구현 이력을 제대로 읽어보면, Contract를 도입한 이유는 Interface에서 연산자 오버로딩을 원하지 않았기 때문인 것 같습니다.

결국 거부된 이전 제안은 매개변수 다형성을 제한하기 위해 인터페이스를 사용했지만 인터페이스에서 정의할 수 없기 때문에 이러한 함수에서 '+'와 같은 일반 연산자를 사용할 수 없기 때문에 거부된 것으로 보입니다. 계약을 사용하면 t == t 또는 t + t 를 작성할 수 있으므로 유형이 같음 또는 덧셈 등을 지원해야 함을 나타낼 수 있습니다.

편집: 또한 Go는 여러 유형 매개변수 인터페이스를 지원하지 않으므로 Go는 유형 클래스를 두 개의 개별 항목, 즉 함수 유형 매개변수를 서로 관련시키는 계약과 메소드를 제공하는 인터페이스로 분리했습니다. 그것이 잃는 것은 여러 유형을 기반으로 유형 클래스 구현을 선택하는 기능입니다. 인터페이스나 계약만 사용해야 하는 경우에는 더 간단하지만 둘을 함께 사용해야 하는 경우에는 더 복잡합니다.

T:Addable 가 "Addable 계약을 구현하는 유형 T"를 의미하는 이유는 무엇입니까?

그것은 실제로 그것이 의미하는 바가 아닙니다. 그것은 단지 하나의 유형 인수에 대해 그렇게 보입니다. 초안의 다른 곳에서는 기능당 하나의 계약만 가질 수 있다는 주석을 달았고, 여기서 주요 차이점이 발생합니다. 계약은 실제로 유형이 독립적인 것이 아니라 기능 유형에 대한 설명입니다. 예를 들어

func Example(type K, V someContract)(k K, v V) V

당신은 같은 것을 할 수 있습니다

contract someContract(k K, v V) {
  k.someMethod(v)
}

이것은 함수 서명에서 유형을 중복 지정하지 않고도 여러 유형을 조정하는 것을 크게 단순화합니다. 그들은 '기묘하게 반복되는 일반적인 패턴'을 피하려고 노력하고 있음을 기억하십시오. 예를 들어 유형을 제한하는 데 사용되는 매개변수화된 인터페이스가 있는 동일한 함수는 다음과 같습니다.

type someMethoder(V) interface {
  someMethod(V)
}

func Example(type K: someMethoder(V), V)(k K, v V) V

다소 어색합니다. 계약 구문을 사용하면 필요한 경우 이 작업을 계속 수행할 수 있습니다. 계약의 '인수'가 함수가 유형 매개변수를 수행하는 것과 동일한 수의 계약이 있는 경우 컴파일러에 의해 자동으로 채워지기 때문입니다. 원하는 경우 수동으로 지정할 수 있습니다. 즉, 실제로 원하면 func Example(type K, V someContract(K, V))(k K, v V) V _할 수 있음을 의미하지만 이 상황에서는 특히 유용하지 않습니다.

계약이 개별 인수가 아니라 전체 기능에 관한 것임을 더 명확하게 하는 한 가지 방법은 단순히 이름을 기반으로 계약을 연결하는 것입니다. 예를 들어,

contract Example(k K, v V) {
  k.someMethod(v)
}

func Example(type K, V)(k K, v V) V

위와 같을 것입니다. 그러나 단점은 계약을 재사용할 수 없고 계약의 인수를 수동으로 지정할 수 있는 능력을 상실한다는 것입니다.

편집: 흥미롭게 반복되는 패턴을 해결하려는 이유를 추가로 보여주기 위해 계속 언급한 최단 경로 문제를 고려하십시오. 매개변수화된 인터페이스를 사용하면 정의가 다음과 같이 표시됩니다.

type E(Node) interface {
  Nodes() []Node
}

type N(Edge) interface {
  Edges() (from, to Edge)
}

type Graph(type Node: N(Edge), Edge: E(Node)) struct { ... }
func New(type Node: N(Edge), Edge: E(Node))(nodes []Node) *Graph(Node, Edge) { ... }
func (*Graph(Node, Edge)) ShortestPath(from, to Node) []Edge { ... }

개인적으로 기능에 대해 계약이 지정되는 방식을 선호합니다. 저는 '정상적인' 기능 본문을 실제 계약 사양으로 사용하는 데 그다지 관심이 없지만, 계약을 자동으로 단순화하는 일종의 gofmt와 유사한 단순화기를 도입하여 잠재적인 많은 문제를 해결할 수 있다고 생각합니다. 외부 부품. 그러면 _할 수 있는__ 함수 본문을 거기에 복사하고 단순화하고 거기에서 수정할 수 있습니다. 불행히도 이것이 구현될 가능성이 얼마나 될지는 모르겠습니다.

그러나 일부 사항은 여전히 ​​지정하기가 다소 어색할 수 있으며 계약과 인터페이스 간의 명백한 중복은 여전히 ​​약간 이상해 보입니다.

"CRTP" 버전이 훨씬 더 명확하고 명시적이며 작업하기 쉽습니다(변수 집합에 대한 기존 계약 간의 관계를 정의하기 위해서만 존재하는 계약을 만들 필요가 없음). 분명히, 그것은 아이디어에 대해 몇 년 동안 친숙했을 수 있습니다.

설명. 드래프트 디자인 에 의해 계약은 기능과 유형 모두에 적용될 수 있습니다.

""
인터페이스나 계약만 사용해야 하는 경우에는 더 간단하지만 둘을 함께 사용해야 하는 경우에는 더 복잡합니다.
""

계약 내에서 하나 이상의 인터페이스를 참조하도록 허용하는 한(연산자와 함수만 사용하여 DRY를 허용하는 대신) 이 문제(및 제 주장)는 해결될 것입니다. 내가 잘못 읽거나 계약 내용을 완전히 읽지 않았을 가능성이 있으며, 해당 기능이 지원되지만 내가 눈치채지 못한 경우도 있습니다. 그렇지 않은 경우 있어야 합니다.

다음을 할 수 없습니까?

contract Example(t T, v V) {
  t.(interface{
    SomeMethod() V
  })
}

계약이 선언된 것과 동일한 패키지의 식별자를 참조할 수 없다는 제한 때문에 다른 곳에서 선언된 인터페이스를 사용할 수 없지만, 그렇게 할 수 있습니다. 또는 해당 제한을 제거할 수 있습니다. 그것은 약간 임의적 인 것 같습니다.

@DeedleFake 아니요. 모든 인터페이스 유형이 유형 어설션될 수 있기 때문입니다(그런 다음 런타임에 잠재적으로 패닉 상태이지만 계약은 실행되지 않음). 그러나 대신 할당을 사용할 수 있습니다.