나는 이것이 시각적으로 얼마나 균일하게 보이는지 좋아합니다.

const OldAPI => NewPackage.API
func  OldAPI => NewPackage.API
var   OldAPI => NewPackage.API
type  OldAPI => NewPackage.API

그러나 대부분의 요소를 거의 점진적으로 이동할 수 있으므로 가장 간단한
솔루션은 _is_ 유형에 대해 = 를 허용하는 것입니다.

const OldAPI = NewPackage.API
func  OldAPI() { NewPackage.API() }
var   OldAPI = NewPackage.API
type  OldAPI = NewPackage.API

그래서 먼저, 나는 그 훌륭한 글에 대해 감사하고 싶었습니다. 가장 좋은 해결책은 할당 연산자와 함께 유형 별칭을 도입하는 것입니다. 이것은 새로운 키워드/연산자가 필요하지 않으며 친숙한 구문을 사용하며 대규모 코드 기반에 대한 리팩토링 문제를 해결해야 합니다.

Russ의 기사가 지적했듯이 모든 별칭과 같은 솔루션은 https://github.com/golang/go/issues/17746 및 https://github.com/golang/go/issues/17784 를 정상적으로 해결해야 합니다.

그 기사를 써주셔서 감사합니다.

할당 연산자를 사용하는 유형 전용 별칭이 가장 좋습니다.

type OldAPI = NewPackage.API

내 이유:

• 더 간단합니다.
  대체 솔루션 => 피연산자에 따라 미묘하게 다른 의미를 갖는 것은 Go에 적합하지 않습니다.
• 집중적이고 보수적입니다.
  유형과 관련된 문제가 해결되었으며 일반화된 솔루션의 복잡성을 상상하는 것에 대해 걱정할 필요가 없습니다.
• 미학적입니다.
  더 뿌듯해 보이는 것 같아요.

위의 모든 것: 결과는 단순하고 집중적이며 보수적이며 미학적이므로 바둑의 일부인 것으로 쉽게 상상할 수 있습니다.

솔루션이 유형으로만 제한되는 경우 구문

type NewFoo = old.Foo

@rsc 의 기사에서 논의된 것처럼 이미 이전에 고려한 것이 나에게 매우 좋아 보입니다.

상수, 변수 및 함수에 대해 동일한 작업을 수행할 수 있도록 하려면 내가 선호하는 구문은 (이전에 제안된 대로)

package newfmt

import (
    "fmt"
)

// No renaming.
export fmt.Printf // Note: Same as `export Printf fmt.Printf`.

export (
        fmt.Sprintf
        fmt.Formatter
)

// Renaming.
export Foo fmt.Errorf // Foo must be exported, ie. `export foo fmt.Errorf` would be invalid.

export (
    Bar fmt.Fprintf
    Qux fmt.State
)

앞에서 논의한 바와 같이 단점은 새로운 최상위 전용 키워드가 도입된다는 것입니다. 이는 기술적으로 실현 가능하고 이전 버전과 완전히 호환 가능함에도 불구하고 분명히 좋지 않습니다. 가져오기 패턴을 반영하기 때문에 이 구문이 마음에 듭니다. 수입이 허용되는 동일한 섹션, 즉, 수출이 허용되는 것이 나에게는 자연스러운 것처럼 보일 것입니다. 패키지 절과 모든 var, 유형, 상수 또는 함수 TLD 사이.

이름 변경 식별자는 패키지 범위에서 선언되지만 새 이름 은 일반적으로 허용되지 않는 재선언과 관련하여 위에서 선언한 패키지에서

var v = Printf // undefined: Printf.
var Printf int // Printf redeclared, previous declaration at newfmt.go:8.

가져오기 패키지에서 이름 변경 식별자는 일반적으로 (newftm의) 패키지 블록의 다른 내보낸 식별자로 볼 수 있습니다.

package foo

import "newfmt"

type bar interface {
    baz(qux newfmt.Qux) // qux type is identical to fmt.State.
}

결론적으로, 이 접근 방식은 newfmt에 새로운 로컬 이름 바인딩을 도입하지 않습니다. 이것은 #17746에서 논의된 문제 중 적어도 일부를 피하고 #17784를 완전히 해결한다고 믿습니다.

내 첫 번째 기본 설정은 유형 전용 type NewFoo = old.Foo 입니다.

보다 일반적인 솔루션이 필요한 경우 전용 키워드가 새로운 연산자(특히 혼란스러운 방향성을 가진 비대칭 연산자[1])보다 낫다는 @cznic의 의견에 동의합니다. 즉, export 키워드가 올바른 의미를 전달한다고 생각하지 않습니다. 구문도 의미도 import 반영하지 않습니다. alias 어떻습니까?

@cznic 이 새 이름을 선언하는 패키지에서 새 이름에 액세스할 수 있기를 원하지 않는 이유를 이해하지만, 적어도 저에게는 그 제한이 예상치 못한 인위적인 것처럼 느껴집니다(비록 이유를 완벽하게 이해하지만).

[1] 저는 유닉스를 거의 20년 동안 사용해 왔지만 여전히 첫 번째 시도에서 심볼릭 링크를 만들 수 없습니다. 그리고 매뉴얼을 읽고 나서 두 번째 시도에도 실패하는 경우가 많습니다.

추가 제약 조건을 제안하고 싶습니다. 표준 라이브러리 유형에 대한 유형 별칭은 표준 라이브러리에서만 선언될 수 있습니다.

내 추론은 사용자 지정 명명 규칙에 맞게 표준 라이브러리 개념의 이름을 바꾼 코드로 작업하고 싶지 않다는 것입니다. 또한 표준 라이브러리로 되돌아가는 여러 패키지에 걸친 긴 스파게티 별칭 체인을 처리하고 싶지 않습니다.

@iand : 이 제약 조건은 이 기능을 사용하여 표준 라이브러리로 무엇이든 마이그레이션하는 것을 차단합니다. 예를 들어 현재 Context 를 표준 라이브러리로 마이그레이션합니다. Context 의 이전 홈은 표준 라이브러리에서 Context 의 별칭이 되어야 합니다.

@quentinmit 불행히도 사실입니다. 또한 이 CL https://go-review.googlesource.com/#/c/32145/ 에서 golang.org/x/image/draw의 사용 사례를 제한합니다.

내 진짜 관심사는 interface{} 및 error 와 같은 별칭을 사용하는 사람들과 관련이 있습니다.

새로운 오퍼레이터를 도입하게 된다면 ~ 를 제안하고 싶습니다. 영어에서는 일반적으로 "~와 비슷한", "대략", "약" 또는 "주변"을 의미하는 것으로 이해됩니다. 위에서 @4ad가 언급했듯이 => 는 방향성이 혼동되는 비대칭 연산자입니다.

예를 들어:

const OldAPI ~ NewPackage.API
func  OldAPI ~ NewPackage.API
var   OldAPI ~ NewPackage.API
type  OldAPI ~ NewPackage.API

@and 오른쪽을 패키지 한정 식별자로 제한하면 특정 문제를 해결할 수 있습니다.

또한 현재 패키지의 모든 유형 또는 map[string]map[int]interface{} 와 같은 긴 유형 표현식에 대한 별칭을 가질 수 없음을 의미합니다. 그러나 이러한 용도는 점진적 코드 복구의 주요 목표와 관련이 없으므로 큰 손실은 아닐 수 있습니다.

@cznic , @iand , 기타: _제한은 복잡성을 추가합니다_. 그것들은 기능에 대한 설명을 복잡하게 만들고 기능의 모든 사용자에게 인지 부하를 추가합니다. 제한 사항을 잊어버린 경우 작동해야 한다고 생각했던 것이 왜 작동하지 않는지 의아해해야 합니다.

단지 가상의 오용으로 인해 디자인 시험에 대한 제한을 구현하는 것은 종종 실수입니다. 그것은 별칭 제안 토론에서 일어났고, 그것은 시도의 별칭이 기사에서 io.ByteBuffer => bytes.Buffer 변환을 처리할 수 없게 만들었습니다. 이 기사를 작성하는 목적의 일부는 우리가 처리할 수 있기를 원하는 몇 가지 사례를 정의하여 부주의로 제한하지 않도록 하는 것입니다.

또 다른 예로, 포인터가 아닌 수신기를 허용하지 않거나 구조체가 아닌 유형의 메서드를 허용하지 않는 오용 인수를 만드는 것이 쉽습니다. 둘 중 하나를 수행했다면 스스로 인쇄하기 위해 String() 메서드로 열거형을 만들 수 없었고 http.Headers 모두 일반 맵이 되고 도우미 메서드를 제공할 수 없었습니다. 오용을 상상하기 쉬운 경우가 많습니다. 설득력 있는 긍정적인 사용은 표시되는 데 시간이 더 오래 걸릴 수 있으며 실험을 위한 공간을 만드는 것이 중요합니다.

또 다른 예로서, 포인터 대 값 메소드에 대한 원래 설계 및 구현은 T와 *T의 메소드 세트를 구분하지 않았습니다. *T가 있으면 값 메소드(수신기 T)를 호출할 수 있고, T, 포인터 메서드(수신기 *T)를 호출할 수 있습니다. 이것은 설명할 제한 없이 간단했습니다. 그러나 실제 경험에 따르면 값에 대한 포인터 메서드 호출을 허용하면 특정 클래스의 혼란스럽고 놀라운 버그가 발생했습니다. 예를 들어 다음과 같이 작성할 수 있습니다.

var buf bytes.Buffer
io.Copy(buf, reader)

io.Copy는 성공하지만 buf에는 아무 것도 포함되지 않습니다. 우리는 그 프로그램이 잘못 실행된 이유를 설명하거나 그 프로그램이 컴파일되지 않은 이유를 설명하는 것 중에서 선택해야 했습니다. 어느 쪽이든 질문이있을 것이지만 우리는 잘못된 실행을 피하는 편에 왔습니다. 그럼에도 불구하고 디자인에 구멍이 잘린 이유에 대한 FAQ 항목 을

다시 말하지만, 제한은 복잡성을 추가한다는 것을 기억하십시오. 모든 복잡성과 마찬가지로 제한에는 상당한 정당성이 필요합니다. 디자인 프로세스의 이 단계에서 특정 디자인에 적절할 수 있는 제한 사항에 대해 생각하는 것이 좋지만 제한이 없는 단순한 디자인을 실제로 경험한 후에만 이러한 제한을 구현해야 합니다. 비용을 지불하기 위해.

또한 Go 1.9 주기가 시작될 때(이상적으로는 주기가 열리는 날) 무엇을 시도할지에 대한 잠정적인 결정에 도달한 다음 실험을 위한 준비를 할 수 있기를 바랍니다. 실험에 더 많은 시간을 할애하면 많은 이점이 있을 것이며, 그 중 특정 제한이 매력적인지 여부를 알 수 있는 기회가 있습니다. 별칭에 대한 한 가지 실수는 Go 1.8 주기가 끝날 때까지 완전한 구현을 커밋하지 않은 것입니다.

원래 별칭 제안에 대한 한 가지는 의도된 사용 사례(리팩토링 활성화)에서 별칭 유형의 실제 사용이 일시적이어야 한다는 것입니다. protobuffer 예제에서 io.BytesBuffer 스텁은 점진적 복구가 완료되면 삭제되었습니다.

별칭 메커니즘이 일시적으로만 표시되어야 하는 경우 실제로 언어 변경이 필요합니까? 아마도 대신 gc 에 "별칭" 목록을 제공하는 메커니즘이 있을 수 있습니다. gc는 일시적으로 대체할 수 있으며 다운스트림 코드베이스의 작성자는 수정 사항이 병합됨에 따라 이 파일의 항목을 점차적으로 제거할 수 있습니다. 나는 이 제안이 까다로운 결과를 초래한다는 것을 알고 있지만 적어도 일시적인 메커니즘을 장려합니다.

나는 한 가지 예외를 제외하고는 구문에 대한 바이크쉐딩에 참여하지 않을 것입니다(기본적으로 신경 쓰지 않습니다). 별칭을 추가하기로 결정하고 별칭을 유형으로 제한하기로 결정한 경우 적어도 var 까지 일관되게 확장 가능한 구문을 사용하십시오 func 및 const (제안된 모든 구문 구조는 type Foo = pkg.Bar 제외하고 모두 허용). 그 이유는 var 대한 별칭이 차이를 만드는 경우가 드물다는 점에는 동의하지만, 이러한 별칭이 존재하지 않는다고 생각하지 않기 때문에 언젠가는 추가하기로 결정할 수도 있습니다. 그들도. 그 시점에서 우리는 모든 별칭 선언이 일관되게 유지되기를 원할 것입니다. type Foo = pkg.Bar 및 var Foo => pkg.Bar 이면 좋지 않을 것입니다.

나는 또한 4가지 모두를 갖는 것에 대해 약간 논쟁할 것이다. 이유는

1) 거기에 대한 구분이다 var 나는 그것을 사용 때로는 않습니다. 예를 들어 나는 종종 글로벌 var Debug *log.Logger 노출하거나 http.DefaultServeMux 와 같은 글로벌 싱글톤을 재할당하여 핸들러를 추가하는 패키지의 등록을 가로채거나 제거합니다.

2) 나는 또한 func Foo() { pkg.Bar() } 가 func Foo => pkg.Bar 와 같은 일을 하지만 후자의 의도가 훨씬 더 명확하다고 생각합니다(특히 이미 별칭에 대해 알고 있는 경우). "이것은 정말로 여기에서 의도된 것이 아닙니다"라고 분명히 명시되어 있습니다. 따라서 기술적으로 동일하지만 별칭 구문이 문서 역할을 할 수 있습니다.

하지만 내가 죽을 언덕은 아닙니다. 나중에 확장할 수 있는 옵션이 있는 한 지금은 type-alias만 사용하는 것이 좋습니다.

이대로 쓰여진 것 같아 저도 기쁩니다. API 디자인과 안정성에 대해 한동안 가졌던 여러 의견을 요약하고 있으며, 앞으로 사람들을 연결하는 간단한 참고 자료로도 활용될 것입니다. :)

그러나 문서와 다른 별칭이 포함된 추가 사용 사례가 있는 경우도 강조하고 싶습니다(그리고 AIUI는 이 문제의 보다 일반적인 의도로, 점진적인 복구를 해결할 수 있는 몇 가지 솔루션을 찾는 매우 기쁘지만, 가명과 다른 결정이 도달하기로 결정된다면 그 경우에도 지원 여부와 지원 방법에 대해 동시에 논의해야 한다고 생각합니다. protobuf public imports 또는 x/image/draw 드롭인 교체 패키지의 사용 사례(둘 다 제 마음에 조금 더 가깝습니다)와 같은 다른 솔루션이 있습니다. @btracey 의 별칭에 대한 go-tool/gc 플래그 제안은 점진적 복구를 비교적 잘 다루지만 다른 사용 사례에서는 실제로 허용되지 않는다고 생각하는 예입니다. 당신은 정말 사용 뭔가 컴파일하고자하는 모든 기대할 수 없다 x/image/draw 그 플래그를 전달하기 위해, 그들은 단지 할 수 있어야 go get .

@jba

@and 오른쪽을 패키지 한정 식별자로 제한하면 특정 문제를 해결할 수 있습니다.

또한 현재 패키지의 어떤 유형에도 별칭을 가질 수 없음을 의미합니다. [...]. 그러나 이러한 용도는 점진적 코드 복구의 주요 목표와 관련이 없으므로 큰 손실은 아닐 수 있습니다.

패키지 내에서 이름을 바꾸는 것(예: 보다 관용적이거나 일관된 이름으로)은 확실히 리팩토링의 한 유형이며 패키지가 널리 사용되는 경우 점진적인 복구가 필요합니다.

패키지 수식 이름으로만 제한하는 것은 실수라고 생각합니다. (내보낸 이름에만 제한을 두는 것이 더 견딜 수 있습니다.)

@btracey

아마도 대신 gc에 "별칭" 목록을 제공하는 메커니즘이 있을 수 있습니다. gc는 일시적으로 대체할 수 있으며 다운스트림 코드베이스의 작성자는 수정 사항이 병합됨에 따라 이 파일의 항목을 점차적으로 제거할 수 있습니다.

gc 에 대한 메커니즘은 복구 프로세스 동안 gc 로만 코드를 빌드할 수 있거나 다른 컴파일러(예: gccgo 에서 메커니즘을 지원해야 함을 의미합니다 llgo )도 있습니다. 모든 구현에서 지원해야 하는 "비언어 변경" 메커니즘은 사실상의 언어 변경입니다. 이는 문서가 열악한 경우일 뿐입니다.

@btracey 및 @bcmills , 그리고 컴파일러뿐만 아니라: 전문가 또는 사람들이 구축한 다른 모든 것과 같이 소스 코드를 분석하는 모든 도구. 그것은 당신이 그것을 어떻게 슬라이스하든간에 확실히 언어 변경입니다.

괜찮 감사.

또 다른 가능성은 const 를 제외한 모든 것에 대한 별칭입니다(

const의 경우 => 는 실제로 = 를 쓰는 더 긴 방법일 뿐입니다. 유형 및 var와 같이 새로운 의미 체계는 없습니다. funcs와 같이 저장된 키 입력이 없습니다.

그것은 적어도 # 17784를 해결할 것입니다.

반론은 도구가 사례를 다르게 취급할 수 있고 의도의 지표가 될 수 있다는 것입니다. 그것은 좋은 반론이지만 정확히 같은 일을 하는 기본적으로 두 가지 방법이라는 사실보다 중요하다고 생각하지 않습니다.

즉, 지금은 유형 별칭만 사용하는 것이 좋습니다. 별칭이 가장 중요합니다. 나는 @Merovius의 의견에 확실히 동의합니다. 우리가 var 및 func 별칭 추가 옵션을

"C" 및 "unsafe"와 같이 가져오기 뒤에 별칭을 숨겨 사용을 더욱 억제하는 것은 어떻습니까? 같은 맥락에서 나는 aliases 구문이 장황하고 리팩토링을 계속하기 위한 발판으로 눈에 띄기를 바랍니다.

디자인 공간을 조금 더 넓히기 위한 시도로 몇 가지 아이디어가 있습니다. 그들은 살을 뺀 것이 아닙니다. 그것들은 아마도 나쁘거나 불가능할 것입니다. 희망은 주로 다른 사람들에게 새롭고 더 나은 아이디어를 불러일으키는 것입니다. 관심이 있는 경우 추가로 탐색할 수 있습니다.

(1)과 (2)에 대한 동기 부여 아이디어는 별칭 대신 변환을 사용하는 것입니다. #17746에서 별칭은 같은 유형에 대해 여러 이름을 갖는 것과 관련된 문제에 부딪쳤습니다(또는 별칭을 #define 또는 하드 링크와 같이 생각하는지 여부에 따라 동일한 이름의 철자가 여러 가지). 변환을 사용하면 유형을 구별함으로써 피할 수 있습니다.

1. 더 많은 자동 변환을 추가합니다.

fmt.Println("abc") 를 호출하거나 var e interface{} = "abc" 하면 "abc" 가 자동으로 interface{} 로 변환됩니다. type T struct { S } 선언하고 T에 승격되지 않은 메서드가 없는 경우 컴파일러는 다른 구조체 내부에서 재귀적으로 포함하여 필요에 따라 S와 T 간에 자동으로 변환하도록 언어를 변경할 수 있습니다. 그런 다음 T는 점진적 리팩토링 목적을 위해 S의 사실상 별칭(또는 그 반대)의 역할을 할 수 있습니다.

1. 새로운 "모양" 유형을 추가합니다.

type T ~S 가 "S처럼 보이는" 유형인 새로운 유형 T를 선언하도록 하십시오. 보다 정확하게는 T는 "유형 S로 및 유형 S에서 변환할 수 있는 모든 유형"입니다. (항상 그렇듯이 구문은 나중에 논의할 수 있습니다.) 인터페이스 유형과 마찬가지로 T는 메서드를 가질 수 없습니다. 기본적으로 T로 무엇이든 하려면 T를 S(또는 S로/에서 변환 가능한 유형)로 변환해야 합니다. 인터페이스 유형과 달리 "구체적인 유형"이 없으며 S에서 T로, T에서 S로의 변환에는 표현 변경이 포함되지 않습니다. 점진적 리팩토링의 경우 이러한 "모양" 유형을 사용하면 작성자가 이전 유형과 새 유형을 모두 허용하는 API를 작성할 수 있습니다. ("look like" 유형은 기본적으로 고도로 제한되고 단순화된 공용체 유형입니다.)

1. 유형 태그

보너스 슈퍼 끔찍한 아이디어. (나에게 이것이 끔찍하다고 말하지 마십시오. 알고 있습니다. 다른 사람들에게 새로운 아이디어를 제공하려고 할 뿐입니다.) 유형 태그(구조체 태그와 같은)를 도입하고 특수 유형 태그를 사용하여 설정하면 어떻게 될까요? type T S "alias:\"T\"" 와 같이 별칭을 제어합니다. 유형 태그는 다른 용도로도 사용되며 단순히 "이 유형은 별칭입니다"보다 패키지 작성자가 더 많은 별칭을 지정할 수 있는 범위를 제공합니다. 예를 들어 코드 작성자는 포함 동작을 지정할 수 있습니다.

별칭을 다시 시도하면 "iota가 하는 일" 및 "임베딩이 하는 일" 문제와 유사한 "godoc이 하는 일"에 대해 생각해 볼 가치가 있습니다.

특히, 우리가 가지고 있는 경우

type  OldAPI => NewPackage.API

NewPackage.API에 문서 주석이 있는 경우 "Type OldAPI" 옆에 해당 주석을 복사/붙여넣기해야 합니까, 주석을 제거해야 합니까(godoc이 자동으로 링크를 제공하거나 자동으로 복사/붙여넣기 사용), 아니면 다른 협약이 있습니까?

다소 접할 수 있지만 주요 동기는 점진적인 코드 복구를 지원하는 것이고 지원해야 하지만, 사소한 사용 사례(구체적인 제안이므로 별칭 제안으로 돌아가기)는 단일 함수를 표시할 때 이중 함수 호출 오버헤드를 방지하는 것일 수 있습니다. 여러 빌드 태그 종속 구현으로 뒷받침됩니다. 지금은 손을 흔들고 있지만 최근 https://groups.google.com/d/topic/golang-nuts/wb5I2tjrwoc/discussion "패키지에서 함수 호출 오버헤드 방지 go+asm 구현" 토론.

@nigeltao re godoc, 제 생각에는 다음과 같습니다.

관계없이 항상 원본에 연결되어야 합니다.

별칭에 문서가 있으면 상관없이 표시되어야 합니다.

별칭에 문서가 없는 경우 godoc에 원래 문서를 표시하도록 하고 싶지만 별칭도 이름을 변경하면 유형 이름이 잘못되고 문서가 현재 패키지에 없는 항목을 참조할 수 있고, 점진적 리팩토링에 사용되는 경우 X를 볼 때 "Deprecated: use X"라는 메시지가 표시될 수 있습니다.

그러나 대부분의 사용 사례에서는 중요하지 않을 수 있습니다. 잘못될 일이 아니라 잘못될 수 있는 일입니다. 그리고 그 중 일부는 이름이 바뀐 별칭과 실수로 지원 중단 경고를 복사하는 것과 같이 린트를 통해 감지될 수 있습니다.

다음 아이디어가 이전에 게시되었는지 확실하지 않지만 대부분 도구 기반의 "gofix" / "gorename"과 같은 접근 방식은 무엇입니까? 자세히 설명하려면:

• 모든 패키지에는 재작성 규칙 세트가 포함될 수 있습니다(예: pkg.Ident => otherpkg.Ident 매핑).
• 이러한 재작성 규칙은 임의의 go 파일 내부에 //+rewrite ... 태그로 지정할 수 있습니다.
• 이러한 재작성 규칙은 ABI 호환 변경에 국한되지 않고 다른 작업도 수행할 수 있습니다(예: pkg.MyFunc(a) => pkg.MyFunc(context.Contex(), a) ).
• gofix와 같은 도구를 사용하여 현재 저장소에 모든 변환을 적용할 수 있습니다. 이렇게 하면 패키지 사용자가 코드를 쉽게 업데이트할 수 있습니다.
• 성공적으로 컴파일하기 위해 gofix 도구를 호출할 필요는 없습니다. 종속성 X의 이전 API를 계속 사용하려는 라이브러리(X의 이전 및 새 버전과의 호환성을 유지하기 위해)는 여전히 그렇게 할 수 있습니다. go build 명령은 디스크의 파일을 변경하지 않고 즉석에서 변환(패키지 X의 다시 쓰기 태그에 지정됨)을 적용해야 합니다.

마지막 단계는 컴파일러를 약간 복잡하게 만들거나 속도를 늦출 수 있지만 기본적으로는 전처리기일 뿐이므로 재작성 규칙의 양은 어쨌든 작게 유지되어야 합니다. 자, 오늘의 브레인스토밍은 충분합니다 :)

함수 호출 오버헤드를 피하기 위해 별칭을 사용하는 것은 컴파일러가 리프가 아닌 함수를 인라인할 수 없는 문제를 해결하기 위한 해킹처럼 보입니다. 구현 결함이 언어 사양에 영향을 미쳐서는 안 된다고 생각합니다.

@josharian 완전한 제안으로 의도한 것은 아니지만 답변을 드리겠습니다.

1. 전환이 실제로 문제가 아니기 때문에 실제로 문제를 해결하지 못합니다. x/net/context.Context 에 할당 / convertable / whateverable입니다 context.Context . 문제는 고차 유형입니다. 즉 func (ctx x/net/context.Context) 및 func (ctx context.Context) 은 인수가 할당 가능하더라도 동일하지 않습니다. 따라서 문제를 해결하려면 type T struct { S } 가 T 와 S 가 동일한 유형임을 의미해야 합니다. 즉, 별칭에 대해 다른 구문을 사용하고 있다는 뜻입니다(이 구문에는 이미 다른 의미가 있음).

2. 할당 가능/변환 가능 유형이 반드시 동일한 메모리 표현을 가질 필요는 없기 때문에 고차 유형에 문제가 있습니다(그렇다면 해석이 크게 변경될 수 있음). 예를 들어, uint8 는 uint64 또는 그 반대로 변환할 수 있습니다. 그러나 이는 예를 들어 type T ~uint8 의 경우 컴파일러가 func(T) 를 호출하는 방법을 알 수 없음을 의미합니다. 스택에서 1, 2,4 또는 8바이트를 푸시해야 합니까? 이 문제를 해결하는 방법이 있을 수 있지만 나에게는 꽤 복잡하게 들립니다(별칭보다 이해하기 더 어렵습니다).

@Merovius님 감사합니다.

1. 예, 여기서 인터페이스 만족도를 놓쳤습니다. 당신 말이 맞아, 이것은 일을하지 않습니다.

2. 나는 "동일한 메모리 표현을 가지고"를 염두에 두었습니다. 컨버터블 왕복은 분명히 그것에 대한 올바른 설명이 아닙니다. 감사합니다.

@uluyol 예, 컴파일러가 잎이 아닌 함수를 인라인할 수 없다는 것이 대부분이지만, 잎이 아닌 함수에 대한 인라인 호출이 스택 추적, runtime.Callers 등에 표시되어야 하는지 여부와 관련하여 명시적 앨리어싱은 그다지 놀랍지 않을 수 있습니다.

어쨌든, 내가 말했듯이, 그것은 사소한 접선입니다.

@josharian 비슷한 문제: [2]uintptr 및 interface{} 는 동일한 메모리 표현을 갖습니다. 따라서 메모리 표현에만 의존하면 형식 안전성을 우회할 수 있습니다. uint64 및 float64 같은 메모리 표현을 모두 가지고 컨버터블 앞뒤로,하지만 당신은 어느 것이 어느 모르는 경우 여전히 적어도 정말 이상한 결과가 발생할 것입니다.

그러나 "동일한 기본 유형"으로 벗어날 수 있습니다. 그것이 어떤 영향을 미칠지 확실하지 않습니다. 예를 들어 유형이 필드에서 사용되는 경우 잘못될 수 있습니다. type S1 struct { T1 } 및 type S2 struct { T2 } ( T1 및 T2 가 동일한 기본 유형 포함)가 있는 경우 type L1 ~T1 둘 다 다음과 같이 작동할 수 있습니다. type S struct { L1 } , 하지만 T1 및 T2 여전히 다른(비슷해 보이지만) 기본 유형이 있으므로 type L2 ~S1 를 사용하면 S2 가 없습니다. S1 아닌로 사용할 수 L2 .

따라서 이 작업을 수행하려면 사양의 여러 위치에서 "동일한 유형"을 "동일한 기본 유형"으로 바꾸거나 수정해야 합니다. 이는 다루기 힘들고 유형 안전에 예상치 못한 결과를 초래할 것입니다. "유사한" 유형은 또한 별칭에 대한 주요 주장인 것처럼 보이는 별칭인 IMHO보다 남용과 혼동 가능성이 훨씬 더 큰 것으로 보입니다.

누구나 간단한 규칙을 생각해 낼 수 있지만 이러한 문제가 없다면 분명히 대안으로 고려해야합니다. :)

@josharian 의 아이디어에 따라 다음은 그의 숫자 2의 변형입니다.

"대체 가능한 유형"의 지정을 허용합니다. 이것은 함수 인수, 반환 값 등에서 명명된 유형을 대체할 수 있는 유형 목록입니다. 컴파일러는 명명된 유형 또는 그 대체물의 인수로 함수 호출을 허용합니다. 대체 유형에는 명명된 유형과 호환되는 정의가 있어야 합니다. 여기서 호환 가능하다는 것은 선언에서 다른 대체 유형을 허용한 후 동일한 메모리 표현과 동일한 선언을 의미합니다.

한 가지 즉각적인 문제는 이 관계의 방향성이 종속성 그래프를 반전시키는 별칭 제안과 반대라는 것입니다. 이것만으로는 작동하지 않을 수 있지만 다른 사람들이 이 문제를 해결할 수 있는 방법을 생각할 수 있기 때문에 여기에서 제안합니다. 한 가지 방법은 가져오기 그래프를 통하지 않고 //go 주석으로 대체를 선언하는 것일 수 있습니다. 이런 식으로 매크로처럼 될 수 있습니다.

이와 반대로 방향성의 반전에는 다음과 같은 몇 가지 이점이 있습니다.

• 대체 가능한 유형의 집합은 의미 체계를 보장하기 위해 더 잘 배치된 새 패키지 작성자가 제어합니다.
• 원래 패키지에는 코드 변경이 필요하지 않으므로 클라이언트는 새 패키지를 사용하기 시작할 때까지 업데이트할 필요가 없습니다.

이것을 컨텍스트 리팩토링에 적용하면 표준 라이브러리 컨텍스트 패키지는 context.Context 가 golang.org/x/net/context.Context 로 대체될 수 있다고 선언합니다. 이것은 context.Context를 허용하는 모든 사용법이 그 자리에 golang.org/x/net/context.Context 도 허용할 수 있음을 의미합니다. 그러나 Context를 반환하는 컨텍스트 패키지의 함수는 항상 context.Context 반환합니다.

이 제안은 포함된 유형의 이름이 절대 변경되지 않기 때문에 포함 문제(#17746)를 우회합니다. 그러나 포함된 유형은 대체 유형의 값을 사용하여 초기화될 수 있습니다.

@ian과 @josharian 은 공변 유형의 특정 변형을 요구하고 있습니다.

@josharian , 제안에 감사드립니다.

type T struct { S } , 별칭에 대한 다른 구문처럼 보이지만 반드시 더 명확한 구문은 아닙니다.

Re type T ~S , 별칭과 어떻게 다른지 잘 모르거나 리팩토링에 어떻게 도움이 되는지 잘 모르겠습니다. 리팩토링(예: io.ByteBuffer -> bytes.Buffer)에서 다음과 같이 작성할 것입니다.

package io
type ByteBuffer ~bytes.Buffer

그러나 "기본적으로 T로 모든 작업을 수행하려면 S로 변환해야 합니다"라고 말하면 io.ByteBuffer로 작업을 수행하는 모든 코드가 여전히 중단됩니다.

Re type T S "alias" : 위에서 작성한 @bcmills의 요점은 유형에 대해 동일한 이름을 여러 개 갖는 것은 철자가 어떻게 되든 언어 변경이라는 것입니다. 모든 컴파일러는 예를 들어 io.ByteBuffer 및 bytes.Buffer가 코드를 분석하거나 유형 검사하는 도구와 마찬가지로 동일하다는 것을 알아야 합니다. 귀하의 제안의 핵심 부분은 "아마도 우리는 다른 추가 사항에 대해 미리 계획해야 할 것"과 같은 것 같습니다. 아마도, 하지만 문자열이 그것들을 설명하는 가장 좋은 방법인지는 분명하지 않으며, 우리가 명확한 필요 없이 구문(Java 일반화 주석과 같은)을 설계하고 싶은지도 불명확합니다. 일반적인 형식을 가지고 있더라도 우리는 여전히 우리가 도입한 새로운 의미론의 모든 의미를 신중하게 고려해야 하며 대부분은 여전히 ​​모든 도구를 업데이트해야 하는 언어 변경일 것입니다(물론 gofmt 제외). 이런저런 메타 언어를 만드는 대신 필요한 양식을 하나씩 작성하는 가장 명확한 방법을 계속 찾는 것이 더 간단해 보입니다.

@Merovius FWIW, [2]uintptr과 인터페이스{}의 메모리 표현이 동일하지 않습니다. 인터페이스{}는 [2]uintptr이 아니라 [2]unsafe.Pointer입니다. uintptr과 포인터는 다른 표현입니다. 그러나 우리는 그러한 종류의 직접적인 변환을 반드시 허용하고 싶지는 않다는 당신의 일반적인 요점이 옳다고 생각합니다. 내 말은, 인터페이스{}에서 [2]*byte로도 변환할 수 있나요? 여기에 필요한 것보다 훨씬 많습니다.

@jimmyfrasche 및 @nigeltao , re godoc: 저도 일찍 작업해야 한다는 데 동의합니다. 나는 우리가 "새로운 기능이 무엇이든 간에 - 코드베이스 리팩토링에만 사용될 것"이라는 가정을 하드 코딩해서는 안 된다는 데 동의합니다. Nigel이 별칭으로 그리기 확장 패키지를 작성하는 데 도움을 준 것과 같은 다른 중요한 용도가 있을 수 있습니다. Jimmy가 말했듯이 더 이상 사용되지 않는 항목은 문서 주석에 명시적으로 사용되지 않는 것으로 표시될 것으로 예상합니다. 문서 주석이 없는 경우 자동으로 문서 주석을 생성하는 방법에 대해 생각했지만 구문(일반적으로 말함)에서 이미 명확하지 않아야 하는 것은 말할 것도 없습니다. 구체적인 예를 보려면 이전 Go 1.8 별칭을 고려하십시오. 주어진

type ByteBuffer => bytes.Buffer

"ByteBuffer는 bytes.Buffer의 별칭입니다"라는 문서 주석을 합성할 수 있지만 정의를 표시하는 데 중복되는 것 같습니다. 누군가 오늘 "유형 X struct{}"를 쓴다면 우리는 "X는 struct{}의 명명된 유형입니다"라고 합성하지 않습니다.

@and , 감사합니다. 귀하의 제안은 새 패키지의 작성자가 이전 패키지의 정확한 정의를 작성한 다음 (구문 구성)과 같이 둘을 연결하는 선언을 작성하도록 요구하는 것 같습니다.

package old
type T { x int }

package new
import "old"
type T1 { x int }
substitutable T1 <- old.T

가져오기 반전이 문제가 있고 그 자체로 쇼 스토퍼가 될 수 있다는 데 동의하지만 건너뛰도록 합시다. 이 시점에서 코드베이스는 취약한 상태에 있는 것처럼 보입니다. 이제 패키지 new는 패키지 old에 struct 필드를 추가하는 변경으로 인해 손상될 수 있습니다. 대체 가능한 라인이 주어지면 T1에 대해 가능한 정의는 하나뿐입니다. 바로 old.T와 동일합니다. 두 유형이 여전히 별개의 정의를 가지고 있다면 메소드에 대해서도 걱정해야 합니다. 메소드 구현도 일치해야 합니까? 그렇지 않은 경우, T를 인터페이스에 넣은 다음{} 유형 어설션을 T1으로 사용하여 빼내고 M()을 호출하면 어떻게 됩니까? 당신은 T1.M을 얻을? T1의 이름을 직접 지정하지 않고 인터페이스 { M() }로 꺼내서 M()을 호출하면 어떻게 될까요? 당신은 TM을 얻을? 소스 트리에 두 정의가 모두 있다는 모호성으로 인해 복잡성이 많이 발생합니다.

물론, 대체 가능한 라인은 나머지를 중복으로 만들고 T1 유형이나 어떤 메소드에 대한 정의를 필요로 하지 않는다고 말할 수 있습니다. 하지만 기본적으로 (이전 별칭 구문에서) type T1 => old.T 를 쓰는 것과 동일합니다.

가져오기 그래프 문제로 돌아가서 기사의 모든 예제가 새 코드의 관점에서 이전 코드를 정의했지만 패키지 그래프가 새 항목을 대신 이전 항목으로 가져와야 하는 경우 리디렉션을 삽입하는 것도 똑같이 효과적입니다. 전환 중 새 패키지.

이것은 이와 같은 전환에서 새 패키지의 작성자와 이전 패키지의 작성자 사이에 유용한 구분이 없을 수 있음을 보여줍니다. 결국 목표는 새 코드에 코드를 추가하고 이전 코드에서 삭제하는 것이므로 두 작성자(다른 경우)가 모두 참여해야 합니다. 그리고 이 둘은 명시적(일종의 리디렉션)이든 암시적이든(대체 가능성 요구 사항에서와 같이 유형 정의가 정확히 일치해야 함) 중간에도 일종의 조정된 호환성이 필요합니다.

@rsc 그 파손 시나리오는 모든 유형 앨리어싱이 양방향이어야 한다고 제안합니다. 이전 별칭 제안에서도 새 패키지를 변경하면 유형에 별칭이 지정된 패키지가 몇 개라도 손상될 수 있습니다.

@iand 정의가

#13467에서 @joegrasse 는 이 제안이 여러 패키지에서 cgo를 사용할 때 동일한 C 유형이 동일한 Go 유형이 되도록 허용하는 메커니즘을 제공하면 좋을 것이라고 지적했습니다. 그것은 이 문제와 전혀 같은 문제가 아니지만 두 문제 모두 유형 앨리어싱과 관련이 있습니다.

별칭에 대한 제안/수락/거부 제한/제한에 대한 요약이 있습니까? 떠오르는 질문은 다음과 같습니다.

• RHS는 항상 완전한 자격을 갖추고 있습니까?
• 별칭에 대한 별칭이 허용되는 경우 별칭 주기를 어떻게 처리합니까?
• 별칭이 내보내지 않은 식별자를 내보낼 수 있어야 합니까?
• 별칭을 포함하면 어떻게 됩니까? (포함된 필드에 액세스하는 방법)
• 빌드된 프로그램에서 별칭을 기호로 사용할 수 있습니까?
• ldflags 문자열 주입: 별칭을 참조하면 어떻게 될까요?

@rsc 대화를 너무 많이 돌리고 싶지는 않지만 별칭 제안에서 "new"가 "old"가 의존하는 필드를 제거하면 "old"의 클라이언트가 이제 컴파일할 수 없음을 의미합니다.

그러나 대체 제안에서는 구형과 신형을 함께 사용하는 클라이언트만 중단되도록 조정할 수 있다고 생각합니다. 이것이 가능하려면 컴파일러가 "새" 패키지에서 "이전" 유형의 사용을 감지한 경우에만 대체 지시문을 검증해야 합니다.

@thwd 아직 좋은 글이 없는 것 같아요. 내 메모:

• 별칭 주기는 문제가 되지 않습니다. 패키지 교차 별칭의 경우 가져오기 주기로 인해 주기가 이미 허용되지 않습니다. 패키지 교차가 아닌 별칭의 경우 분명히 허용되지 않아야 하며 이는 초기화 순서의 주기와 매우 유사합니다. 개인적으로, 나는 별칭에 대한 별칭을 갖고 싶습니다. 왜냐하면 점진적인 복구 사용 사례로 제한되어서는 안 된다고 생각하고(위의 내 설명 참조) 패키지 A가 유형을 옮기는 사람에 의해 손상될 수 있다면 슬플 것입니다. 별칭이 있는 패키지 B( x/image/draw.Image 앨리어싱 draw.Image 다음 누군가가 안전하다고 가정하고 별칭을 통해 draw.Image 를 image.Draw 로 이동하기로 결정했다고 상상해 보세요. 갑자기 x/image/draw 는 별칭에 대한 별칭이 허용되지 않기 때문에 중단됩니다.
• 이전에 별칭을 지지하는 사람들은 내보내지 않은 식별자를 별칭으로 내보내는 것이 이상함 때문에 나쁜 생각일 수 있다는 데 동의했다고 생각합니다. 사실상 이는 내보내지 않은 식별자에 대한 별칭이 쓸모가 없으며 완전히 허용되지 않을 수 있음을 의미합니다.
• 임베딩 문제인 AFAIK는 아직 해결되지 않은 문제입니다. #17746에 전체 토론이 있습니다. 별칭으로 진행하기로 결정된 경우/언제/전에 이 토론이 계속될 것으로 예상합니다(그러나 여전히 대체 솔루션의 가능성이 있거나 점진적인 수리를 목표로 하지 않기로 결정할 가능성이 있습니다. 조금도)

@iand , "이전 클라이언트와 새 클라이언트를 함께 사용하는 클라이언트만 중단될 수 있습니다."가 유일한 흥미로운 경우입니다. 점진적인 코드 복구를 만드는 것은 혼합 클라이언트입니다. 새 코드만 사용하거나 이전 코드만 사용하는 클라이언트는 오늘 작동합니다.

아직 다른 곳에서 언급하지 않은 다른 고려해야 할 사항이 있습니다.

여기서 명시적인 목표는 대규모 분산 코드베이스에서 크고 점진적인 리팩토링을 허용하는 것이므로 라이브러리 소유자가 코드를 변경하는 데 알 수 없는 수의 클라이언트가 필요한 일종의 정리 작업을 수행하려는 상황이 있습니다(최종 " 이전 API 사용 중지" 단계). 이를 수행하는 일반적인 방법은 사용 중단 경고를 추가하는 것이지만 Go 컴파일러에는 경고가 없습니다.

컴파일러 경고가 없는데 어떻게 라이브러리 소유자가 리팩토링을 완료하는 것이 안전하다고 확신할 수 있습니까?

한 가지 대답은 일종의 버전 관리 체계일 수 있습니다. 호환되지 않는 새로운 API가 포함된 라이브러리의 새 릴리스입니다. 이 경우 유형 별칭이 아니라 버전 관리가 전체 답일 수 있습니다.

또는 라이브러리 작성자가 실제로 클라이언트에 대해 컴파일 _error_를 일으키는 "사용 중단 경고"를 추가하도록 허용하지만 수행해야 하는 리팩토링에 대한 명시적 알고리즘을 사용하는 것은 어떻습니까? 나는 다음과 같은 것을 상상하고 있습니다.

Error: os.time is obsolete, use time.time instead. Run "go upgrade" to fix this.

유형 별칭의 경우 리팩토링 알고리즘이 "OldType의 모든 인스턴스를 NewType으로 바꾸기"라고 생각하지만 미묘한 부분이 있을 수 있지만 확실하지 않습니다.

어쨌든 그렇게 하면 라이브러리 작성자가 모든 클라이언트에게 코드가 중단될 것임을 경고하고 이전 API를 완전히 삭제하기 전에 쉽게 수정할 수 있는 방법을 제공하기 위해 최선을 다할 수 있습니다.

@iainmerrick golang/lint#238 및 golang/gddo#456에 대한 버그가 열려 있습니다.

@rsc 의 기사에 설명된 대로 점진적 코드 복구 문제를 해결하면 두 가지 유형을 교환할 수 있는 방법이 필요합니다(vars, funcs 및 consts에 대한 해결 방법이 존재함).

이를 위해서는 도구나 언어 변경이 필요합니다.

두 유형을 상호 교환 가능하게 만드는 것은 정의에 따라 언어 작동 방식을 변경하는 것이기 때문에 모든 도구는 이전 유형의 모든 인스턴스를 새 유형으로 다시 작성하여 컴파일러 외부에서 동등성을 시뮬레이션하는 메커니즘이 될 것입니다. 그러나 이것은 이러한 도구가 stdlib 컨텍스트 패키지 대신 golang.org/x/net/context를 사용하는 공급업체 패키지와 같이 소유하지 않은 코드를 다시 작성해야 함을 의미합니다. 변경 사항에 대한 사양은 별도의 매니페스트 파일이나 기계가 읽을 수 있는 주석에 있어야 합니다. 도구를 실행하지 않으면 빌드 오류가 발생합니다. 그 모든 것이 처리하기가 복잡해집니다. 도구는 해결하는 만큼 많은 문제를 생성할 것 같습니다. 이 패키지를 사용하는 모든 사람이 처리해야 하는 문제는 여전히 일부가 자동화되어 있기 때문에 다소 낫습니다.

언어가 변경되면 코드는 유지 관리자만 수정하면 되며 대부분의 사람들은 정상적으로 작동합니다. 유지 관리자를 지원하는 도구는 여전히 옵션이지만 소스가 사양이고 패키지의 유지 관리자만 이를 호출하면 되기 때문에 훨씬 간단합니다.

@griesemer가 지적했듯이 (어디서 이것에 대한 많은 스레드가 있었는지 기억이 나지 않습니다) Go에는 byte ↔ uint8 와 같은 항목에 대해 이미 앨리어싱이 있으며 패키지를 가져올 때 다른 로컬 이름을 사용하여 동일한 소스 파일에 두 번.

언어에서 유형에 명시적으로 별칭을 지정하는 방법을 추가하면 이미 존재하는 의미 체계를 사용할 수 있습니다. 그렇게 하면 관리 가능한 방식으로 실제 문제를 해결할 수 있습니다.

언어 변경은 여전히 ​​큰 일이고 해결해야 할 일도 많지만 결국 여기에서 하는 것이 옳다고 생각합니다.

내가 아는 한 "방 안의 코끼리" 중 하나는 유형 별칭의 경우 이를 도입하면 비일시적 (즉, "비리팩토링") 사용이 가능하다는 사실입니다. 나는 전달에서 언급된 것을 보았습니다(예: "API를 단순화하기 위해 다른 패키지의 유형 식별자 다시 내보내기"). 이전 제안의 좋은 전통을 유지하기 위해 "영향" 하위 섹션에 알려진 유형 별칭의 모든 대체 사용법을 나열하십시오 . 이것은 또한 추가 가능한 대안적 용도를 발명하고 현재 논의에서 이를 조명하기 위해 사람들의 상상력을 자극하는 이점을 가져와야 합니다. 현재와 ​​같이 이 제안은 작성자가 유형 별칭의 다른 가능한 사용을 완전히 모르는 척하는 것으로 보입니다. 또한 재수출과 관련하여 Rust/OCaml은 이것이 어떻게 작동하는지에 대한 경험이 있을 수 있습니다.

추가 질문: 유형 별칭이 새 패키지의 유형에 메소드를 추가할 수 있는지(아마도 캡슐화 해제) 여부를 명확히 해주십시오. 또한 새 패키지가 이전 구조체의 개인 필드에 액세스할 수 있습니까?

추가 질문: 유형 별칭이 새 패키지의 유형에 메소드를 추가할 수 있는지(아마도 캡슐화 해제) 여부를 명확히 해주십시오. 또한 새 패키지가 이전 구조체의 개인 필드에 액세스할 수 있습니까?

별칭은 유형의 또 다른 이름입니다. 유형의 패키지를 변경하지 않습니다. 따라서 두 질문에 모두 아니오입니다(새 패키지 == 이전 패키지가 아닌 경우).

@akavel 현재로서는 제안이 전혀 없습니다. 그러나 우리는 Go 1.8 별칭 시험 중에 나타난 두 가지 흥미로운 가능성을 알고 있습니다.

1. 별칭(또는 별칭만 입력)을 사용하면 다른 패키지를 확장하는 드롭인 교체를 만들 수 있습니다. 예를 들어 https://go-review.googlesource.com/#/c/32145/ , 특히 커밋 메시지의 설명을 참조

2. 별칭(또는 그냥 유형 별칭)을 사용하면 작은 API 표면으로 패키지를 구조화할 수 있지만 더 나은 내부 구조를 위해 패키지 컬렉션으로 대규모 구현을 구성할 수 있지만 여전히 클라이언트에서 가져오고 사용할 패키지는 하나만 제공합니다. https://github.com/golang/go/issues/16339#issuecomment -232813695에 설명된 다소 추상적인 예가 있습니다.

별칭의 기본 목표는 훌륭하지만 기능에 대한 최고의 동기부여임에도 불구하고 코드 리팩토링의 목표에 대해 정직하지 않은 것처럼 들립니다. 일부 제안은 이름을 잠그는 것을 제안하며 유형이 일반적으로 이러한 리팩토링으로 표면을 변경한다는 언급을 아직 보지 못했습니다. 심지어 예를 들어 os.Error => error 종종 별칭 주위 언급은 사실 무시 os.Error 했다 String 방법이 아닌 Error . 유형을 이동하고 이름을 바꾸면 모든 오류 처리 코드가 손상됩니다. 그것은 리팩토링 중에 흔한 일입니다. 오래된 메서드는 이름이 바뀌고, 이동되고, 삭제되며, 새 코드와의 비호환성을 유지하기 때문에 새 유형에서는 이러한 메서드를 원하지 않습니다.

도움을 주기 위해 여기에 씨앗 아이디어가 있습니다. 별칭 대신 어댑터 측면에서 문제를 보면 어떨까요? 어댑터는 기존 유형에 대체 이름 _및 인터페이스_를 제공하며 이전에 원래 유형이 보였던 곳에서 꾸미지 않고 사용할 수 있습니다. 어댑터는 기본 적응 유형의 동일한 인터페이스가 있다고 가정하기보다는 지원하는 메소드를 명시적으로 정의해야 합니다. 이는 기존 type foo bar 동작과 매우 유사하지만 몇 가지 추가 의미가 있습니다.

io.ByteBuffer

예를 들어, 다음은 당분간 임시 "adapts" 키워드를 사용하여 io.ByteBuffer 사례를 처리하는 예제 스켈레톤입니다.

type ByteBuffer adapts bytes.Buffer

func (old *ByteBuffer) Write(b []byte) (n int, err error) {
        buf := (*bytes.Buffer)(old)
        return buf.Write(b)
}

(... etc ...)

따라서 해당 어댑터가 있으면 이 코드가 모두 유효합니다.

func newfunc(b *bytes.Buffer) { ... }
func oldfunc(b *io.ByteBuffer) { ... }

func main() {
        var newvar bytes.Buffer
        var oldvar io.BytesBuffer

        // New code using the new type obviously just works.
        newfunc(&newvar)

        // New code using the old type receive the underlying value that was adapted.
        newfunc(&oldvar)

        // Old code using the old type receive the adapted value unchanged.
        oldfunc(&oldvar)

        // Old code gets new variable adapted on the way in. 
        oldfunc(&newvar)
}

newfunc 및 oldfunc 의 인터페이스는 호환됩니다. 둘 다 실제로 *bytes.Buffer 수락하고 oldfunc 들어오는 도중에 *io.BytesBuffer 에 적용합니다. 할당, 결과 등에 동일한 개념이 적용됩니다.

os.오류

인터페이스의 컴파일러 구현이 조금 더 까다롭지만 동일한 논리가 인터페이스에서도 작동하도록 만들어집니다. 다음은 메서드 이름이 변경된 사실을 처리하는 os.Error => error 의 예입니다.

package os

type Error adapts error

func (e Error) String() string { return error(e).Error() }

그러나 이 경우는 다음과 같은 방법 때문에 더 생각해 볼 필요가 있습니다.

func (v *T) Read(b []byte) (int, os.Error) { ... }`

String 메서드가 있는 유형을 반환하므로 일반적으로 코드를 점진적으로 수정할 수 있도록 반대 방향으로 조정하려고 합니다.

_업데이트됨: 더 많은 생각이 필요합니다._

임베딩 문제

1.8에서 기능을 끌어낸 임베딩 버그와 관련하여 어댑터를 사용하면 결과가 조금 더 명확해집니다. 어댑터가 동일한 것에 대한 새로운 이름이 아니기 때문입니다. 어댑터가 포함된 경우 사용되는 필드 이름은 다음과 같습니다. 어댑터의 오래된 논리는 계속 작동하고 필드에 액세스하면 기본 유형을 사용하는 컨텍스트에 명시적으로 전달되지 않는 한 어댑터 인터페이스를 사용합니다. 적응되지 않은 유형이 포함된 경우 일반적인 일이 발생합니다.

쿠버네티스, 도커

게시물에 언급된 문제는 위 문제의 변형으로 보이며 제안으로 해결되었습니다.

변수, 상수

메서드를 직접 연결할 수 없기 때문에 해당 시나리오에서 변수나 상수를 적용하는 것은 의미가 없습니다. 적응할 것인지 아닌지는 그들의 유형입니다.

고독

우리는 그것이 어댑터라는 사실에 대해 명시하고, 적응된 것과 독립적인 인터페이스를 포함하고 있기 때문에 평소와 같이 이에 대한 문서를 보여줄 것입니다.

통사론

좋은거 골라주세요. ;)

@iainmerrick @zombiezen

또한 별칭 유형이 레거시이고 새 유형으로 대체되어야 한다고 자동으로 추론해야 합니까? golint, godoc 및 유사한 도구를 사용하여 이전 유형을 더 이상 사용되지 않는 것으로 시각화하면 유형 앨리어싱의 남용을 매우 크게 제한할 수 있습니다. 그리고 마지막으로 앨리어싱 기능이 남용되는 문제가 해결될 것입니다.

두 가지 관찰:

1. 유형 참조의 의미는 지원되는 리팩토링 사용 사례에 따라 다릅니다.

Gustavo의 제안은 유형 참조 및 결과 의미론에 대한 사용 사례에 대해 더 많은 작업이 필요함을 보여줍니다.

Ross의 새로운 제안에는 새로운 구문 type OldAPI = newpkg.newAPI 됩니다. 그러나 의미론은 무엇입니까? 레거시 공개 메서드 또는 필드로 OldAPI를 확장하는 것이 불가능합니까? newAPI가 호환성을 유지하기 위해 OldAPI의 모든 공개 메서드와 필드를 지원해야 하는 대답으로 예라고 가정합니다. 비공개 필드와 메서드에 의존하는 OldAPI가 있는 패키지의 모든 코드는 패키지의 가시성 제약 조건을 수정하는 것이 테이블을 벗어난다는 가정 하에 공개 newAPI만 사용하도록 다시 작성해야 합니다.

대체 경로는 OldAPI에 대해 추가 메서드를 정의할 수 있도록 하는 것입니다. 그러면 모든 공개 이전 메서드를 제공해야 하는 NewAPI의 부담을 줄일 수 있습니다. 그러나 이것은 OldAPI를 NewAPI와 다른 유형으로 만들 것입니다. 두 유형의 값 사이에 어떤 형태의 할당 가능성을 유지해야 하지만 규칙이 복잡해집니다. 필드 추가를 허용하면 더 복잡해집니다.

2. NewAPI가 포함된 패키지는 OldAPI가 포함된 패키지를 가져올 수 없습니다.

OldAPI를 재정의하려면 OldAPI의 정의를 포함하는 패키지 O가 NewAPI와 함께 패키지 N을 가져와야 합니다. 이는 패키지 N이 O를 가져올 수 없음을 의미합니다. 어쩌면 너무 명백해서 언급되지 않은 것일 수도 있지만 리팩토링 사용 사례에 대한 중요한 제약으로 보입니다.

업데이트: 패키지 N은 패키지 O에 대한 종속성을 가질 수 없습니다. 예를 들어 O를 가져오는 패키지를 가져올 수 없습니다.

@niemeyer 메서드 이름 변경과 같은 변경은 이미 점진적으로 가능합니다. a) 새 메서드를 추가하고, 내부에서 이전 메서드를 호출하고(또는 그 반대로), b) 모든 사용자를 새 메서드로 점진적으로 변경하고, c) 이전 메서드를 삭제합니다. 이를 유형 별칭과 결합할 수 있습니다. 이것이 type-moving에 초점을 맞춘 이유는 이것이 확인된 유일한 것이며 아직 가능하지 않기 때문입니다. 식별된 다른 모든 변경은 여러 단계를 사용하더라도 가능합니다(예: 메서드의 이름을 바꾸지 않고 인수 집합 변경). 표면적이 더 적은(이해할 사항이 적은) 수정 사항을 선택하는 것이 바람직하다고 생각합니다.

@rakyll 개인적으로 별칭이 리팩토링이 아닌 것에 유용하다고 생각한다면(예: 훌륭한 사용 사례를 찾은 래퍼 패키지) 사용하지 않을 것입니다. 인위적으로 장애를 일으켜 사용자를 혼란스럽게 만든 사람에게 화가 났지만 낙담하지는 않았습니다.

언젠가는 우리가 실제로 래퍼 패키지, protobuf 공개 가져오기 또는 내부 패키지 API 노출을 그렇게 나쁜 것으로 간주하는지 여부에 대해 토론할 필요가 있다고 생각합니다. 그것들은 읽을 수 없고 다른 하나는 "아니요"라고 반복해서 말합니다. 여기에 있어야 할 객관적인 논거가 많지 않은 것 같습니다.

나는 적어도 (분명히) 좋은 일이라고 생각하고 언어 기능을 추가하고 인위적으로 하나의 사용 사례에만 제한하는 것은 나쁜 일이라고 생각합니다. 잘 설계된 직교 언어를 사용하면 가능한 한 적은 기능으로 최대한 많은 작업을 수행할 수 있습니다. 기능이 "가능한 프로그램의 스팬 벡터 공간"을 최대한 확장하기를 원하므로 공간에 단일 점만 추가하는 기능을 추가하는 것이 이상하게 보입니다.

모든 유형의 별칭 제안이 개발될 때마다 약간 다른 사용 사례를 염두에 두고 싶습니다.

이 문제에서 논의하는 주요 사용 사례는 _replacement_ 유형이지만 유형 별칭은 유형에 대한 종속성에서 코드 본문을 제거하는 데에도 매우 유용합니다.

예를 들어, 유형이 "불안정한" 것으로 판명되었다고 가정합니다(즉, 호환되지 않는 방식으로 계속 변경됨). 그런 다음 일부 사용자는 "안정적인" 대체 유형으로 마이그레이션하기를 원할 수 있습니다. 유형의 소유자와 사용자가 반드시 긴밀하게 협력하거나 안정성 목표에 동의하지 않는 github 등에서 개발을 생각하고 있습니다.

다른 예는 단일 유형이 크거나 문제가 있는 패키지에 대한 종속성이 삭제되는 것을 막는 유일한 경우입니다(예: 라이센스 비호환성이 발견된 경우).

따라서 여기의 프로세스는 다음과 같습니다.

1. 유형 별칭 정의
2. 유형 별칭을 사용하도록 관련 코드 본문을 변경합니다.
3. 유형 별칭을 유형 정의로 바꿉니다.

이 과정이 끝나면 자신의 방향으로 자유롭게 발전할 수 있는 두 가지 독립적인 유형이 있습니다.

이 사용 사례의 경우:

• 원래 유형 정의가 포함된 패키지를 변경하여 거기에 유형 별칭을 추가하는 옵션이 없습니다(소유자가 이에 동의하지 않을 것이므로).
• 원래 유형은 더 이상 사용되지 않습니다(유형을 "축소"하는 과정에서 코드 본문에서 그렇게 간주될 수 있음).

@Merovius 이전 방법을 삭제하거나 이름을 바꾸는 순간 그것을 사용하는 모든 클라이언트를 한 번에 죽입니다. 당신이 그렇게 할 의향이 있다면, 한꺼번에 중단되는 것을 방지하기 위해 언어 기능을 추가하는 전체 사소하지 않은 연습은 무의미합니다. 코드 이동에 대해 정확히 같은 것을 말할 수도 있습니다. 모든 호출 사이트에서 한 번에 유형의 이름을 바꾸면 됩니다. 완료. 두 작업 모두 단순히 원자적 이름 바꾸기이며, 공통적으로 호출 사이트의 모든 코드 라인에 대한 완전한 액세스를 가정한다는 사실을 가지고 있습니다. 이것은 Google의 경우일 수 있지만 대규모 오픈 소스 응용 프로그램 및 라이브러리의 유지 관리자로서 내가 살고 있는 세상은 아닙니다.

대부분의 경우 Go 팀이 외부 당사자를 포함하는 프로젝트를 만들기 위해 많은 시간을 들이기 때문에 비판이 불공평하다고 생각합니다. 그러나 주어진 패키지를 호출하는 모든 단일 코드 라인에 액세스할 수 있다고 가정하는 순간 오픈 소스 커뮤니티의 맥락과 일치하지 않는 정원. 벽으로 둘러싸인 정원 내에서만 작동하는 언어 수준의 리팩토링 기능을 추가하는 것은 최소한 비정형적일 것입니다.

@niemeyer 나는 분명히 나 자신을 명확히하지 않았습니다. 어떤 경우에도 이전 API를 삭제하는 것을 옹호하는 것이 아니라 유형 별칭으로 활성화하려는 모든 워크플로가 이름 바꾸기 메서드(동시에 여부에 관계없이)로 이미 가능하다는 점을 지적한 것입니다. 따라서 무엇을 하고 싶은지 상관없이

1. 새 API 추가, 이전 API와 교환 가능
2. 점차적으로 소비자를 새로운 API로 변경
   3a. 모든 것이 마이그레이션되거나 지원 중단 기간이 끝나면 이전 API를 삭제하십시오.
   3b. 두 API를 영구적으로 유지하여 무기한 안정성을 제공합니다(예: 기사의 이 부분 참조 ).

당신은 3a 대 3b를 하는 것에 대해 논쟁하는 것 같습니다. 그러나 내가 지적한 것은 1. 이미 메소드 이름에 대해 가능하지만 유형에 대해서는 불가능하다는 것입니다. 이것이 바로 이것에 관한 것입니다.

하지만, 지금은 내가 당신을 오해하고 있다고 생각한다는 것을 깨달았습니다. :) os.Error가 다른 인터페이스 정의이므로 이동이 실제로 팬아웃되지 않는다는 점을 지적하셨을 수도 있습니다. 나는 그것이 사실이라고 생각한다. API 제거를 금지하면 유형 별칭으로 인해 인터페이스 유형의 메소드 이름을 변경할 수 없습니다.

당신의 어댑터 아이디어에 대해 저를 위해 명확히 해 주실 수 있을 것입니다. (예를 들어, os.Error의 경우) fmt.Stringer를 os.Error로 사용할 수도 있지 않습니까?

어쨌든 어댑터 아이디어는 내가 그것에 대해 약간 회의적이지만 더 발전할 가치가 있는 것 같습니다. 그러나 가능한 구현자 및/또는 소비자를 손상시키지 않고 인터페이스를 점진적으로 리팩토링하는 방법을 갖는 것은 좋은 목표입니다.

@niemeyer 예, 오류로 인해 메소드 이름이 변경되는 것에 대해서도 좋은 지적을

두 종류의 변경 사항을 모두 처리하는 일반적인 수정 사항이 있다면 훌륭할 것이라는 데 동의합니다. 나는 그 수정이 무엇인지 볼 수 없습니다. 특히 유형 스위치가 설명된 어댑터와 어떻게 작동하는지 이해하지 못합니다. 유형 전환 중에 값이 어떻게든 자동으로 변환됩니까? 반사는 어떻습니까? 이름이 두 개인 유형이 하나만 있으면 앞뒤로 자동 변환되는 두 유형이 있을 때 발생하는 많은 문제를 피할 수 있습니다.

@rsc 예, 어댑터는 모든 상황에서 일관되게 자동으로 변환되므로 유형 스위치도 다르지 않습니다. 모호할 수 있으므로 어댑터와 기본 유형을 모두 포함하는 유형 스위치를 금지합니다. 누락된 것이 있을 수 있지만 아직 리플렉션 문제를 볼 수 없습니다. 모든 코드 컨텍스트는 반드시 적응된 유형 또는 기본 유형을 명시적으로 사용해야 하기 때문입니다. 오늘날과 마찬가지로, 우리가 어떻게 거기에 도달했는지 알지 못하면 interface{} 들어갈 수 없습니다.

@Merovius 위의 두 가지 의견은 귀하가 여전히 만들고 있는 요점을 정확하게 설명합니다. 오늘 유형을 이동하면 수정해야 하는 코드가 손상됩니다. 메서드의 이름을 바꾸면 수정이 필요한 코드가 손상됩니다. 메소드를 삭제하고 인수를 변경하면 수정이 필요한 코드가 손상됩니다. 이러한 경우에 코드를 리팩토링할 때 작업을 계속하려면 모든 호출 사이트의 손상과 함께 원자적으로 수정을 수행해야 합니다. 유형을 이동하지만 완전히 건드리지 않는 것은 IMO가 언어 기능을 정당화하지 않는 매우 제한된 리팩토링 사례입니다.

@niemeyer 그것은 구체적인 유형을 처리합니다. .(interface{String() string}) 대 .(interface{Error() string}) 또는 변경된 인터페이스의 특정 부분에 대한 형식 주장은 어떻습니까? 검사에서 두 가지 가능한 기본 유형을 어떻게든 모두 고려해야 합니까?

@niemeyer 아니요. 메서드 이름을 바꾸는 것은 A.Foo 에서 A.Bar 로 메소드를 이동하려면 다음을 수행하십시오.

1. A.Foo 주위에 래퍼로 A.Bar 메서드 추가
2. 임의의 많은 커밋을 통해 A.Bar 만 호출하도록 사용자 마이그레이션
3. 지원 중단을 시행할 의향이 있는지에 따라 A.Foo 삭제하거나 삭제하지 마십시오.

함수 인수 변경은 비원자적으로 가능합니다. 예를 들어 x int 매개변수를 func Foo() 에 추가하려면 다음을 수행하십시오.

1. func FooWithInt(x int) { Foo(); // use x somehow; }
2. 임의의 많은 커밋을 통해 매개변수를 추가하도록 사용자 마이그레이션
3. 지원 중단을 시행할 의사가 없다면(또는 WithInt를 사용하는 것이 귀찮지 않다면) 끝입니다. 그렇지 않으면 Foo 를 func Foo(x int) { FooWithInt(x) } .
4. 임의의 많은 커밋을 통해 s/FooWithInt/Foo/g 사용자를 마이그레이션합니다.
5. FooWithInt 삭제

유형 이동 (엄격히 말해서 vars)을 이동 을 수행하려면 지원 중단을 시행할 의지가 있어야 합니다(따라서 잠재적으로 알려지지 않은 코드 빌드를 깨는 것은 광범위하고 시기적절한 발표가 필요함을 의미함). 당신이없는 경우에도하지만, 더 편리한 이름이나 기타 유용한 배치와 기능 보강 API에 대한 능력 또한 새로운 이름과 그 반대하여 오래된 물건을 참조 할 수있는 능력에 달려있다 (X / 이미지 / 그릴 참조).

오늘날 유형을 이동하는 것과 오늘날 함수 이름을 바꾸는 것의 차이점은 전자의 경우 실제로 원자적 변경이 필요하지만 후자의 경우 독립적인 저장소 및 커밋을 통해 점진적으로 변경할 수 있다는 것입니다. "I'll make commit that do s/Foo/Bar/"가 아니라 수행하는 프로세스가 있습니다.

어쨌든. 우리가 어디 있는지 모르겠어, 분명히 서로를 지나쳐 이야기하고 있어. 나는 @rsc 의 문서가 내 POV를 전달하는 데 꽤 명확하지만 실제로 당신의 것을 얻지 못한다는 것을

@rsc 두 가지 합리적인 답변을 볼 수 있습니다. 인터페이스가 어댑터 또는 기타로 들어간 유형을 전달하는 간단한 인터페이스와 인터페이스 어설션 시 일반적인 의미 체계가 적용됩니다. 다른 하나는 값이 인터페이스를 충족하지 않지만 기본 값이 충족하는 경우 값이 조정되지 않을 수 있다는 것입니다. 전자는 우리가 염두에 두고 있는 리팩토링 사용 사례에 대해 더 간단하고 아마도 충분하지만 후자는 기본 유형에도 유형 어설션할 수 있다는 아이디어와 더 일치할 것입니다.

@Merovius 물론, _실제로 이름을 바꾸지 않고_ 호출 사이트에서 새 API를 대신 사용하도록 강제하는 한 메서드 이름을 바꾸는 것이 가능합니다. 마찬가지로 유형을 이동하는 것은 _실제로 이동하지 않고_ 호출 사이트에서 새 API를 대신 사용하도록 강제하는 한 가능합니다. 우리 모두는 오래된 코드 작업을 보존하기 위해 수년 동안 이 두 가지를 모두 해왔습니다.

@niemeyer 하지만 다시: 유형의 경우 적절한 방식으로 항목을 추가할 수도 없습니다. x/image/draw를 참조하십시오. 그리고 모든 사람이 안정성에 대해 그렇게 절대적인 견해를 갖고 있는 것은 아닙니다. 나 자신은 "6,12,... 몇 개월 후 $function,$type,...이(가) 사라지고 있습니다. 그 시점에서 다른 곳으로 마이그레이션되었는지 확인하십시오"라고 말한 다음 유지 관리되지 않는 코드를 중단합니다. 해당 지원 중단 통지를 따르도록 관리합니다(누군가 API에 대한 장기 지원이 필요하다고 생각하는 경우 이를 제공하기 위해 비용을 지불할 누군가를 찾을 수 있습니다). 나는 대부분의 사람들이 안정성에 대한 절대적인 견해를 갖고 있지 않다고 주장합니다. 의미론적 버전에 대한 최근 푸시를 참조하십시오. 호환성을 깨는 옵션을 원하는 경우에만 정말 의미가 있습니다. 그리고 그 의사는 그러한 경우에도 점진적인 수리를 통해 여전히 이익을 얻을 수 있는 방법과 본질적으로 다이아몬드 의존성 문제를 해결하지 않더라도 완화할 수 있는 방법에 대해 매우 잘 주장합니다.

안정성에 대한 당신의 입장이 절대적이기 때문에 점진적 수리를 위한 별칭의 사용 사례 대부분을 무시할 수 있습니다. 그러나 대부분의 바둑 커뮤니티에서는 파손에 대한 욕구가 있고 발생했을 때 가능한 한 원활하게 만드는 데 사용하고 있다고 주장합니다.

@niemeyer @rsc @Merovius 저는 귀하의 토론(및 전체 토론)을

문제를 더 많이 반복할수록 확장된 공분산 의미 체계에 더 가까워집니다. 그래서, 여기에서 생각합니다: 우리는 이미 구체적인 유형에서 인터페이스로, 그리고 인터페이스 사이에서 정의된 하위 유형 의미론("is-a")을 가지고 있습니다. 내 제안은 인터페이스를 메서드 인수까지 재귀적으로 공변하도록 만드는 것입니다(현재 분산 규칙에 따라).

이것은 모든 현재 패키지의 문제를 해결하지 않습니다. 그러나 API의 "이동 가능한 부분"이 인터페이스가 될 수 있다는 점에서 아직 작성되지 않은 모든 향후 패키지의 문제를 해결할 수 있습니다(좋은 디자인도 권장함).

이러한 방식으로 인터페이스를 (ab) 사용하여 모든 요구 사항을 해결할 수 있다고 생각합니다. Go 1.0을 깨고 있습니까? 잘 모르겠지만 우리는 아닌 것 같아요.

@thwd "인터페이스를 재귀적으로 공변하게 만드는 것"이 ​​의미하는 바를 보다 정확하게 정의해야 한다고 생각합니다. 일반적으로 하위 유형 지정에서 메서드 인수는 반공변 방식으로 변경하고 결과는 공변 방식으로 변경해야 합니다. 또한 당신이 말하는 것에서 이것은 구체적인 (인터페이스가 아닌) 유형의 기존 문제를 해결하지 못할 것입니다.

@thwd 나는 인터페이스(심지어 공변인 인터페이스)가 이러한 문제에 대한 좋은 솔루션이라는 점에 동의하지 않습니다(매우 특정한 경우에만 해당). 그것들을 하나로 만들려면 vars/consts/funcs/...를 포함하여 API의 모든 것을 인터페이스로 만들어야 합니다. 모두, 그것은 좋은 디자인입니다. 어떤 것이 구조체라면 그냥 구조체로 만드십시오. 다른 모든 것은 패키지에 이상한 구문 오버헤드를 추가하고 거의 이점이 없는 모든 역 종속성을 추가합니다. 또한 시작할 때 제정신을 유지할 수 있는 유일한 방법입니다. 간단하게 시작하고 나중에 더 일반적인 것으로 이동하십시오. 내가 지금까지 본 API의 많은 복잡성은 API 디자인을 지나치게 생각하고 필요한 것보다 더 많은 일반성을 계획하는 사람들에서 비롯되었습니다. 그리고 80%의 경우(그 숫자는 명백한 거짓말)에서는 "깨끗한 API 디자인"이 없기 때문에 아무 일도 일어나지 않습니다.

(분명히: 공변 인터페이스가 좋은 생각이 아니라고 말하는 것이 아닙니다. 단지 이러한 문제에 대한 좋은 해결책이 아니라는 것을 말하는 것입니다)

@Merovius 의 요점에 추가

package foo

type Authority struct {
  Host string
  Port int
}

시간이 지남에 따라 foo 패키지가 커지고 Authority 유형이 정말로 필요한 사람보다 더 많은 책임(및 코드 크기)을 얻게 됩니다. 따라서 Authority 만 포함하는 fooauthority 패키지를 만들고 foo.Authority 의 기존 사용자가 계속 작동하도록 하는 방법이 바람직한 사용 사례입니다. 인터페이스 유형만 고려하는 솔루션은 여기에서 도움이 되지 않습니다.

@Merovius 귀하의 마지막 의견은 전적으로 주관적이며 제 제안 대신 개인적으로 저를 언급하고 있습니다. 이것은 좋게 끝나지 않을 것이므로 여기서 논의를 중단하겠습니다.

@griesemer @Merovius 둘 다 동의합니다. 루프를 닫으려면 지금까지의 논의가 하위 유형/공분산의 일부 개념을 이끌어 냈다는 데 동의할 수 있습니다. 또한 구현 시 런타임 간접 참조가 발생하지 않아야 합니다. 그것이 @niemeyer 가 제안한 것입니다(내가 그를 올바르게 이해했다면). 하지만 더 많은 아이디어를 읽고 싶습니다. 문제에 대해서도 생각하겠습니다.

@niemeyer @Merovius 님의 댓글에 아무것도 _ad의 hominem_가 있었다. "안정성에 대한 당신의 입장은 절대적"이라는 그의 주장은 당신이 아니라 당신의 입장에 대한 관찰이며, 다음과 같은 당신의 진술 중 일부에서 합리적인 추론입니다.

이전 방법을 삭제하거나 이름을 바꾸는 순간 그것을 사용하고 있던 모든 클라이언트를 한 번에 죽입니다.

그리고

물론 실제로 이름을 바꾸지 않고 호출 사이트에서 새 API를 사용하도록 강제하지 않는 한 메서드 이름을 바꾸는 것이 가능합니다. 마찬가지로 실제로 이동하지 않고 호출 사이트에서 새 API를 사용하도록 강제하는 한 유형 이동이 가능합니다. 우리 모두는 오래된 코드 작업을 보존하기 위해 수년 동안 이 두 가지를 모두 해왔습니다.

나는 그 진술에서 Merovius와 같은 인상을 받았습니다. 당신은 잠시 동안 무언가를 비추천하고 결국에는 그것을 제거하는 데 동정적이지 않습니다. 당신은 무한정 작업하는 야생에서 코드를 유지하기 위해 최선을 다하고 있습니다. "안정성에 대한 당신의 입장은 절대적"입니다. (그리고 더 많은 오해를 피하기 위해 나는 "당신"을 당신의 성격이 아니라 당신의 아이디어를 언급하는 데 사용하고 있습니다.)

@niemeyer adapts 선언은 밀접하게 관련된 것으로 보인다 제안하고 instance 하스켈 typeclasses에서. 이것을 Go로 느슨하게 번역하면 다음과 같을 수 있습니다.

package os

type Error interface {
  String() string
}

instance error Error (
  func (e error) String() string { return e.Error() }
)

불행히도 ( @zombiezen이 언급한 것처럼) 이것이 비인터페이스 유형에 어떻게 도움이 되는지 명확하지 않습니다.

또한 함수 유형(인수 및 반환 값)과 상호 작용하는 방식도 명확하지 않습니다. 예를 들어 adapts 의 의미는 Context 를 표준 라이브러리로 마이그레이션하는 데 어떻게 도움이 될까요?

나는 그 말에서 Merovius와 같은 인상을 받았습니다.

@jba 절대적인 의견이 아닌 절대적인 사실입니다. 메소드나 유형을 삭제하면 이를 사용하는 Go 코드가 중단되므로 이러한 변경을 원자적으로 수행해야 합니다. 하지만 내 제안은 코드의 점진적 리팩토링에 관한 것인데, 이는 여기서 주제이며 사용 중단을 의미합니다. 그러나 그 비추천의 과정은 동정의 문제가 아닙니다. 저는 각각 수천 개의 실제 종속성이 있는 여러 개의 공개 Go 패키지와 점진적인 발전으로 인해 여러 개의 독립적인 API를 보유하고 있습니다. API를 깨뜨릴 때 사람들을 미치게 만들지 않으려면 스트리밍하는 대신 일괄 처리하는 것이 좋습니다. 물론, 당신이 벽으로 둘러싸인 정원에 살고 있고 모든 전화 사이트에 연락하여 문제를 해결할 수 있는 경우는 제외합니다. 그러나 나는 나 자신을 되풀이하고 있습니다. 그 모든 것은 위의 원래 제안에서 더 명확한 방식으로 읽을 수 있습니다.

@메로비우스

개인적으로 별칭이 리팩토링이 아닌(예: 훌륭한 사용 사례를 찾은 래퍼 패키지)에 유용하다고 생각한다면 그냥 사용하겠습니다.

우리는 엄청나게 많은 새로운 API와 더 이상 사용되지 않는 API가 포함된 패키지를 유지 관리하고 이전(별칭) 유형의 상태에 대한 명확한 설명 없이 별칭을 사용하는 것은 점진적인 코드 복구에 도움이 되지 않으며 API 표면의 압도적인 증가에만 기여할 것입니다. 저는 우리 솔루션이 API가 "더 이상 사용되지 않음"이라는 자유 형식 godoc 텍스트 외에 다른 신호가 없는 분산 개발자 커뮤니티의 요구 사항을 해결해야 한다는 @niemeyer의 의견에 동의합니다. 이전 유형을 더 이상 사용하지 않는 데 도움이 되는 언어 기능을 추가하는 것이 이 스레드의 주제이므로 자연스럽게 이전(별칭) 유형의 상태에 대한 질문으로 이어집니다.

유형 또는 부분 패키지에 대한 확장을 제공하지만 이 스레드에서는 제공하지 않는 것과 같은 다른 주제로 유형 앨리어싱에 대해 논의하고 싶습니다. 해당 주제 자체에는 고려하기 전에 해결해야 할 다양한 캡슐화 관련 문제가 있습니다.

특정 연산자 또는 별칭이 지정된 형식이 어느 정도 대체되었음을 암시하는 것은 전환해야 하는 사용자에게 적절하게 전달할 수 있습니다. 이러한 미분성을 통해 도구는 교체된 API를 자동으로 보고할 수 있습니다.

분명히 말해서, 표준 라이브러리 외부의 유형에 대해서는 사용 중단 정책이 기술적으로 불가능합니다. 유형은 앨리어싱 패키지의 관점에서 볼 때만 오래된 것입니다. 생태계에서 이것을 결코 시행할 수 없다는 점을 감안할 때, 저는 여전히 표준 라이브러리 별칭이 사용 중단을 엄격하게 암시하는 것을 보고 싶습니다(적절한 사용 중단 통지에 의해 암시됨).

또한 병렬 토론에서 사용 중단의 개념을 표준화하고 핵심 도구(golint, godoc 등)에서 이에 대한 토지 지원을 표준화할 것을 제안합니다. 지원 중단 공지가 없는 것은 Go 생태계의 가장 큰 문제이며 점진적인 코드 복구 문제보다 더 광범위합니다.

@rakyll 컴퓨터로 읽을 수 있는 사용 중단 알림이 있는 사용 사례에 공감합니다. 나는 단지 a) 별칭이 그런 것이고 b) 그것을 컴파일러 경고로 내보낸다는 개념에 반대합니다.

a) 이동 이외의 다른 작업에 별칭을 생산적으로 사용하고 싶다는 사실을 제외하고는 매우 작은 사용 중단 세트에만 적용됩니다. 예를 들어, 몇 번의 릴리스에서 함수에서 일부 매개변수를 제거하고 싶다고 가정해 보겠습니다. 새 API의 서명이 다르기 때문에 실제로 별칭을 사용할 수 없지만 여전히 이를 알리고 싶습니다. b)의 경우 IMHO 컴파일러 경고는 일반적으로 좋지 않습니다. 나는 이것이 대부분 go가 이미 하고 있는 일과 일치한다고 생각하므로 정당화가 필요하지 않다고 생각합니다.

지원 중단 알림에 대해 말씀하신 모든 내용에 동의합니다. 분명히 #10909에 대한 구문이 있으므로 이를 보다 유용하게 만드는 다음 단계는 godoc에서 도구 지원을 강조 표시하고 사용에 대해 경고하는 검사를 받는 것입니다(예: go vet, golint 또는 별도의 도구를 통틀어).

@rakyll stdlib가 도입되는 경우 유형 별칭을 보수적으로 사용하는 것으로 시작해야 한다는 데 동의합니다.

사이드바:

Go 및 관련 도구의 비추천 주석 상태를 모르는 사람들을 위한 배경:

@Merovius가 위에서 언급했듯이 항목을 더 이상 사용되지 않는 것으로 표시하는 표준 규칙이 있습니다. #10909, https://blog.golang.org/godoc-documenting-go-code 참조

TL;DR: 사용되지 않는 항목의 문서에서 "Deprecated: "로 시작하는 단락을 만들고 대체 항목을 설명합니다.

더 유용한 방식으로 더 이상 사용되지 않는 항목을 표시하는 godoc에 대한 승인된 제안이 있습니다: #17056.

@rakyll 은 더 이상 사용되지 않는 항목이 사용될 때 golint가 경고

stdlib가 stdlib 내에서 별칭 사용에 대해 보수적인 입장을 취하더라도 유형 별칭의 존재가 (기계적으로 감지되거나 시각적으로 표시되는 방식으로) 이전 유형이 더 이상 사용되지 않음을 의미해야 한다고 생각하지 않습니다. 그것이 항상 실제로 그것을 의미한다면.

그렇게 하면 다음 중 하나를 의미합니다.

• 더 이상 사용되지 않는 것으로 명시적으로 표시되지 않은 유형이 다른 곳에서 별칭으로 지정되어 있는지 확인하기 위해 다른 stdlib 패키지를 검색합니다.
• 모든 stdlib 별칭을 자동화된 도구로 하드코딩
• 이미 대체품을 찾고 있는 경우에만 이전 유형이 더 이상 사용되지 않는다고 보고하므로 검색에 도움이 되지 않습니다.

이전 유형이 더 이상 사용되지 않아 유형 별칭이 도입된 경우, 이전 유형에 관계없이 새 유형에 대한 참조를 사용하여 이전 유형을 더 이상 사용되지 않는 것으로 표시하여 처리해야 합니다.

이렇게 하면 더 간단하고 일반화되어 더 나은 도구가 존재할 수 있습니다. 특별한 경우가 필요하지 않으며 유형 별칭에 대해서도 알 필요가 없습니다. 문서 주석에서 "Deprecated:"와 일치하기만 하면 됩니다.

stdlib의 별칭이 사용 중단을 위한 것일 수도 있다는 공식적인 정책은 임시적일 수도 있지만 표준 사용 중단 주석을 사용하고 코드 검토를 통과하기 위해 다른 사용을 허용하지 않는 경우에만 시행되어야 합니다.

@niemeyer 내 이전 답변은 정전으로 인해 손실되었습니다 :( 순서가

그런데 반복하네요..

FWIW, 귀하의 마지막 답변이 매우 유용하다는 것을 알았습니다. 그것은 우리가 이전에 생각했던 것보다 (그리고 여전히 당신이 생각하는 것보다) 더 많은 동의를 하고 있다는 확신을 주었습니다. 그래도 어딘가에 여전히 잘못된 의사 소통이있는 것 같습니다.

그러나 내 제안은 코드의 점진적인 리팩토링에 관한 것입니다.

이것은 논쟁의 여지가 없다고 생각합니다. :) 나는 처음부터 당신의 제안이 문제를 해결하기 위해 고려되어야 할 흥미로운 대안이라는 데 동의했습니다. 저를 혼란스럽게 하는 것은 다음과 같은 진술입니다.

메소드나 유형을 삭제하면 이를 사용하는 Go 코드가 중단되므로 이러한 변경을 원자적으로 수행해야 합니다.

나는 아직도 여기에서 당신의 추론이 무엇인지 궁금합니다. 원자성 단위를 단일 커밋으로 이해합니다. 그 가정으로, 나는 당신이 메소드 또는 유형의 삭제가 종속 리포지토리에서 독립적이고 임의로 많은 커밋에서 먼저 발생할 수 없다고 확신하는 이유를 이해하지 못합니다. 간격이 지났음) 메서드 또는 유형이 커밋 업스트림에서 삭제됩니다(아무도 더 이상 의존하지 않으므로 아무 것도 중단하지 않고). 사용 중단을 준수하지 않거나 찾을 수 없거나 합리적으로 고칠 수 없는(또는 합리적으로 수정할 수 없는) 역 종속성 주변에 특정 모호한 요소가 있다는 데 동의합니다. 주요 변경 사항을 적용할 때마다 그리고 어떻게 조정하려고 하든 그 문제가 발생합니다.

그리고 공평하게 말해서 다음과 같은 문장은 혼란을 크게 도와주지 않습니다.

물론, 당신이 벽으로 둘러싸인 정원에 살고 있고 모든 전화 사이트에 연락하여 문제를 해결할 수 있는 경우는 제외합니다.

내가 말한 것이 이것이 내가 주장하는 요점이라는 인상을 주었다면 한 걸음 물러서서 내가 오픈 소스의 입장에서 완전히 논쟁하고 있다는 가정 하에 다시 읽을 수 있기를 바랍니다. 커뮤니티 (저를 믿지 못하신다면 언제든지 이 주제에 대한 저의 이전 기여를 찾아보십시오. 저는 이것이 monorepo 문제보다 커뮤니티 문제에 더 가깝다는 점을 항상 처음으로 지적합니다. Monorepos에는 이 문제를 해결할 수 있는 방법이 있습니다. , 지적한 대로).

어쨌든. 나는 이것이 당신만큼 고갈되는 것을 발견합니다. 그래도 언젠가는 당신의 입장을 이해할 수 있기를 바랍니다.

protobuf public imports와 같은 것을 지원하는 경우와 방법에 대해 동시에 이야기하십시오 ...
언젠가는 우리가 실제로 래퍼 패키지, protobuf 공개 가져오기 또는 내부 패키지 API 노출을 나쁜 것으로 간주하는지 여부에 대해 토론해야 한다고 생각합니다.

nit: protobuf public imports가 특별한 보조 사용 사례로 언급될 필요가 있다고 생각하지 않습니다. 내부 설계 문서와 공개 문서 모두에서 명시적으로 언급했듯이 점진적인 코드 복구를 위해 설계되었으므로 이미 이 문제에서 설명하는 문제의 범주에 속합니다. 또한 protobuf 공개 가져오기를 구현하는 데 유형 별칭이 충분할 것이라고 생각합니다. (proto 컴파일러는 vars를 생성하지만 논리적으로 const이므로 "var Enum_name = import.Enum_name"으로 충분해야 합니다.)

@Merovius 생산적인 답변에 감사드립니다. 몇 가지 컨텍스트를 제공하려고 합니다.

나는 아직도 여기에서 당신의 추론이 무엇인지 궁금합니다. 원자성 단위를 단일 커밋으로 이해합니다. 그 가정으로, 나는 당신이 왜 메소드 또는 유형의 삭제가 먼저 개별적으로 발생할 수 없다고 확신하는지 이해하지 못합니다.

일어날 수 없다고 말한 적이 없습니다. 한 발 물러서서 좀 더 명확하게 다시 말씀드리겠습니다.

우리 모두는 최종 목표가 두 가지라는 데 동의할 것입니다. 우리는 제대로 작동하는 소프트웨어를 원하고 소프트웨어를 개선하여 정상적인 방식으로 계속 작업할 수 있기를 원합니다. 후자 중 일부는 변경 사항을 깨고 전자 목표와 상충됩니다. 그래서 긴장감이 있습니다. 즉, 스위트 스팟이 어디에 있는지에 대한 주관적인 부분이 있습니다. 우리 토론의 흥미로운 부분은 여기에 있습니다.

그 스위트 스팟을 찾는 한 가지 유용한 방법은 인간의 개입에 대해 생각하는 것입니다. 즉, 사람들이 코드를 계속 작동하도록 수동으로 수정해야 하는 작업을 수행하면 관성이 발생합니다. 모든 종속 코드 베이스의 해당 부분이 이 프로세스를 거치는 데 오랜 시간이 걸립니다. 우리는 바쁜 사람들에게 대부분의 경우 귀찮게 하지 않는 일을 하도록 요청하고 있습니다.

그 스위트 스팟을 보는 또 다른 방법은 소프트웨어가 작동할 가능성입니다. 우리가 사람들에게 더 이상 사용되지 않는 방법을 사용하지 말라고 요청하는 것은 중요하지 않습니다. 쉽게 액세스할 수 있고 지금 여기에서 문제가 해결된다면 대부분의 개발자는 그냥 사용할 것입니다. 여기에서 일반적인 반론은 다음과 같습니다. _오, 하지만 문제는 고장났을 때입니다!_ 하지만 그것은 명시된 목표에 어긋납니다. 우리는 소프트웨어가 작동하기를 원하지만 옳지 않기를 원합니다.

따라서 단순히 유형을 이동하는 것이 도움이 되지 않는 이유에 대한 통찰력을 제공하기를 바랍니다. 사람들이 새로운 집에서 그 새로운 유형을 실제로 사용하려면 인간의 개입이 필요합니다. 사람들이 자신의 코드를 수동으로 변경하는 문제를 해결할 때, 가까운 장래에 곧 다시 변경될 것 대신 _새로운 유형을 사용_하는 개입을 하는 것이 가장 좋습니다. 리팩토링에 도움이 되는 언어 기능을 추가하는 문제를 해결한다면 이상적으로는 위의 이유로 사람들이 코드를 단순히 새 집이 아닌 새로운 유형으로 점진적으로 이동할 수 있습니다.

설명 감사합니다. 나는 이제 당신의 입장을 더 잘 이해하고 당신의 가정에 동의한다고 생각합니다. FWIW, 이 문제를 다루기 위한 나의 순진한 계획(점진적인 수리를 위해 어떤 솔루션을 사용할 것인지에 상관없이)은 사용 중단 기간에 패키지별로 코드를 자동으로 마이그레이션하는 도구와 같은 고픽스이지만 나는 자유롭게 인정합니다. 나는 그것이 실제로 어떻게 작동하는지 아직 시도하지 않았습니다.

@niemeyer 귀하의 제안이 Go 유형 시스템에 심각한 지장을 주지 않고 실행 가능하다고 생각하지 않습니다.

이 코드가 제시하는 딜레마를 고려하십시오.

package old
import "new"
type A adapts new.A
func (a A) NewA() {}

package new
type A struct{}
func (a A) OldA() {}

package main
import (
    "new"
    "old"
    "reflect"
)
func main() {
    oldv := reflect.ValueOf(old.A{})
    newv := reflect.ValueOf(new.A{})
    if oldv.Type() == newv.Type() {
        // The two types are equal, therefore they must
        // have exactly the same method set, so either
        // oldv doesn't have the OldA method or newv doesn't
        // have the NewA method - both of which imply a contradiction
        // in the type system.
    } else {
         // The two types are not equal, which means that the
         // old adapted type is not fully compatible with the old
         // one. Any type that includes either new.A or new.B will
         // be incompatible as one of its components will likewise be
         // unequal, so any code that relies on dynamic type checking
         // will fail when presented with the type that's not using the
         // expected version.
    }
 }

리플렉트 패키지의 현재 공리 중 하나는 두 유형이 동일한 경우 해당 reflect.Type 값이 동일하다는 것입니다. 이것은 Go의 런타임 유형 변환 효율성의 기초 중 하나입니다. 내가 볼 수있는 한 이것을 깨뜨리지 않고 "adapts"키워드를 구현할 방법이 없습니다.

@rogpeppe 위의 반영에 대한 @rsc와의 대화를 참조하십시오. 두 유형은 동일하지 않으므로 Reflect는 진실을 말하고 어댑터에 대한 질문이 있을 때 어댑터에 대한 세부 정보를 제공합니다.

@niemeyer 두 가지 유형이 같지 않으면 패키지 간에 유형을 이동하면서 점진적인 코드 복구를 지원할 수 없다고 생각합니다. 예를 들어, 유형 호환성을 유지하는 새 이미지 패키지를 만들고 싶다고 가정해 보겠습니다.

우리는 할 수 있습니다:

package newimage
import "image"
type RGBA adapts image.RGB
func (r *RGBA) At(x, y) color.Color {
    return (*image.Buffer)(r).At(x, y)
}
etc for all the methods

점진적인 코드 복구를 목표로 한다면
새 패키지에서 생성된 이미지는 기존 기능과 호환됩니다.
이전 이미지 유형을 사용합니다.

image/png 패키지가
newimage를 사용하도록 변환되었지만 image/jpeg는 변환되지 않았습니다.

나는 우리가 이 코드가 작동하기를 기대해야 한다고 믿습니다:

img, err := png.Decode(r)
if err != nil { ... }
err = jpeg.Encode(w, img, nil)

그러나 *newimage.RGBA가 아닌 *image.RGBA에 대해 형식 어설션을 수행하기 때문에
유형이 다르기 때문에 AFAICS에 실패합니다.

유형이 *image.RGBA인지 여부에 관계없이 위의 유형 주장을 성공시켰다고 가정해 보겠습니다.
아니면. 그것은 현재 불변을 깨뜨릴 것입니다 :

반사.TypeOf(x) == 반사.TypeOf(x.(anyStaticType))

즉, 정적 유형 어설션을 사용하면
값이지만 때로는 실제로 변경합니다.

우리가 괜찮다고 결정했다면 아마도 우리도 필요할 것입니다.
적응된 유형을 호환 가능한 인터페이스로 변환하는 것을 가능하게 합니다.
적응 유형 지원, 그렇지 않으면 새 코드 또는 이전 코드가 중지됩니다.
호환되는 인터페이스 유형으로 변환할 때 작동
그들이 사용하는 유형.

이것은 또 다른 모순적인 상황으로 이어집니다.

// oldInterface is some interface with methods that
// are only supported by the old type.
type oldInterface interface {
    OldMethod()
}
var x = interface{} = newpackage.Type{}
switch x.(type) {
case oldInterface:
    // This would fail because the newpackage.Type
    // does not implement OldMethod, even though we
    // we just supposedly checked that x implements OldMethod.
    reflect.TypeOf(x).Method("OldMethod")
}

전반적으로 비슷하지만 다른 두 가지 유형이 있다고 생각합니다.
유형 시스템과 예기치 않은 비호환성을 설명하기가 매우 어렵습니다.
동적 유형을 사용하는 코드에서.

나는 "X = Y 유형" 제안을 지지합니다. 설명이 간단하고 하지 않는다.
유형 시스템을 너무 많이 방해하십시오.

@rogpeppe : @niemeyer 의 제안은 @josharian 의 이전 제안 과 유사하게 적응된 유형을 기본 유형으로 암시적으로 변환하는 것이라고 생각합니다.

점진적 리팩토링을 위해 작동하도록 하려면 적응된 유형의 인수를 사용하여 함수를 암시적으로 변환해야 합니다. 본질적으로 언어에 공분산을 추가해야 합니다. 그것은 확실히 불가능한 작업이 아닙니다. 많은 언어가 특히 동일한 기본 구조를 가진 유형에 대해 공분산을 허용하지만 특히 인터페이스 유형의 경우 유형 시스템에 많은 복잡성을 추가합니다.

그것은 당신이 언급했듯이 몇 가지 흥미로운 극단적 인 경우로 이어지지만 반드시 그 자체로 "모순적"인 것은 아닙니다.

type oldInterface interface {
    OldMethod()
}
var x = interface{} = newpackage.Type{}
switch y := x.(type) {
case oldInterface:
    reflect.TypeOf(y).Method("OldMethod")  // ok
    reflect.TypeOf(x).Method("NewMethod")  // ok

    // This would fail because y has been implicitly converted to oldInterface.
    reflect.TypeOf(y).Method("NewMethod")

    // This would fail because accessing OldMethod on newpackage.Type requires
    // a conversion to oldInterface.
    reflect.TypeOf(x).Method("OldMethod")
}

// This would fail because accessing OldMethod on newpackage.Type requires
// a conversion to oldInterface.

이것은 여전히 ​​나에게 모순되는 것처럼 보입니다. 현재 모델은 매우 간단한 모델입니다. 인터페이스 값에는 잘 정의된 기본 정적 유형이 있습니다. 위의 코드에서 우리는 기본 유형에 대해 뭔가를 추론하지만 값을 엿볼 때 우리가 추론한 것과 같지 않습니다. 이것은 내가 보기에 언어에 대한 심각한(설명하기 어려운) 변화입니다.

여기에서 논의가 마무리되는 것 같습니다. https://github.com/golang/go/issues/16339#issuecomment -247536289 에서

전반적으로 여기의 감정은 일반화된 별칭이 아닌 유형 별칭에 대한 것 같습니다. Gustavo의 어댑터 아이디어가 유형 별칭을 대체할 수 있지만 그렇지 않을 수도 있습니다. 논의가 끝나면 더 간단한 형식에 도달할 수 있지만 현재로서는 약간 복잡해 보입니다. 나는 논의가 조금 더 오래 계속될 것을 제안한다.

나는 여전히 변경 가능한 전역 변수가 "일반적으로 버그"인지 확신하지 못합니다(그리고 버그인 경우 레이스 감지기는 그러한 종류의 버그를 찾기 위한 선택 도구입니다). 해당 인수가 확장 가능한 구문의 부족을 정당화하는 데 사용되는 경우 init() 또는 해당 선언으로 독점적으로 도달할 수 없는 코드의 전역 변수에 대한 할당을 확인하는 수의사 검사가 구현되기를 요청합니다. 순진하게도 이것이 구현하기가 특별히 어렵지 않고 그것을 실행하는 데 많은 노력을 들일 필요가 없다고 순진하게 생각합니다. 예를 들어 모든 godoc.org에 등록된 패키지를 통해 변경 가능한 전역 변수의 사용 사례가 무엇인지 그리고 우리가 할 것인지 여부를 확인합니다. 그들 모두를 버그로 간주하십시오.

(저는 또한 go가 변경할 수 없는 전역 변수를 성장시키면 const 선언의 일부여야 한다고 믿고 싶습니다. 왜냐하면 그것이 개념적으로 그것이고 이전 버전과 호환되기 때문입니다. 그러나 이것이 다음으로 이어질 가능성이 있음을 인정합니다 예를 들어 배열 유형에서 어떤 종류의 표현식을 사용할 수 있는지에 대한 복잡성과 더 많은 생각이 필요함)

Re "제한? 표준 라이브러리 유형의 별칭은 표준 라이브러리에서만 선언할 수 있습니다." -- 특히, 별칭 사용에 관심을 표명한 기존 패키지 x/image/draw 대한 드롭인 사용 사례를 방지할 수 있습니다. 예를 들어 라우터 패키지 등이 비슷한 방식으로 net/http 에 별칭을 사용하는 것을 아주 잘 상상할 수 있습니다( 손을 흔드는 것 ).

나는 또한 반대 주장 Re 모든 제한에 동의합니다. 즉, 나는 그러한 제한을 갖지 않는 것에 찬성합니다.

@Merovius , 변경 가능한 _exported_ 전역 변수는 어떻습니까? 패키지의 모든 코드가 올바르게 처리하는 방법을 알고 있기 때문에 내보내지 않은 전역이 문제가 없는 것은 사실입니다. 내보낸 변경 가능한 전역이 의미가 있는지는 덜 분명합니다. 우리는 표준 라이브러리에서 이 실수를 여러 번 했습니다. 예를 들어 runtime.MemProfileRate를 업데이트하는 완전히 안전한 방법은 없습니다. 당신이 할 수 있는 최선은 그것을 프로그램 초기에 설정하고 가져온 패키지가 메모리를 할당할 수 있는 초기화 고루틴을 시작하지 않기를 바라는 것입니다. var 대 const에 대해 당신이 옳을 수도 있지만 우리는 그것을 다른 날로 남겨둘 수 있습니다.

x/image/draw에 대한 좋은 점. 다음 업데이트에서 요약에 추가됩니다.

나는 당신이 제기한 것과 같은 질문에 답하기 위해 분석할 수 있는 Go 코드의 대표적인 코퍼스를 구성하고 싶습니다. 몇 주 전에 이 작업을 시작했는데 몇 가지 문제가 발생했습니다. 생각보다 좀 더 많은 작업이 필요하지만 해당 데이터 세트를 갖는 것이 매우 중요하며 우리가 거기에 도달할 것으로 기대합니다.

@rsc 이 주제에 대한 GothamGo 프레젠테이션이 youtube https://www.youtube.com/watch?v=h6Cw9iCDVcU 에 게시되었으며 첫 번째 게시물에 추가할 수 있습니다.

"유형 별칭에 대한 제안에서 해결해야 하는 다른 문제는 무엇입니까?" 섹션에서 "별칭으로 명명된 형식에 메서드를 정의할 수 있습니까?"에 대한 대답을 지정하는 것이 도움이 될 것입니다. 어려운 아니오입니다. 나는 그것이 섹션의 규정된 정신에 어긋난다는 것을 알고 있지만, 여기저기서 별칭에 대한 많은 대화에서 별칭이 필연적으로 이것을 허용하고 따라서 문제를 해결합니다. 정의에 내포되어 있지만 명시적으로 언급하면 ​​불필요한 앞뒤로 많은 단락이 발생합니다. 그것이 별칭에 대한 새로운 제안의 별칭 FAQ에 속할 수도 있지만 이것이 이 스레드의 결과여야 합니다.

@Merovius 내보낸 모든 패키지 전역 가변 변수는 패키지 수준 getter 및 setter 함수로 시뮬레이션할 수 있습니다.

p 패키지의 버전 n이 주어지면

package p
var Global = 0

버전 n+1에서는 getter 및 setter가 도입될 수 있으며 변수는 더 이상 사용되지 않습니다.

package p
//Deprecated: use GetGlobal and SetGlobal.
var Global = 0
func GetGlobal() int {
    return Global
}
func SetGlobal(n int) {
   Global = n
}

버전 n + 2는 Global 내보내기를 취소할 수 있습니다.

package p
var global = 0
func GetGlobal() int {
    return global
}
func SetGlobal(n int) {
   global = n
}

(연습은 독자에게 맡기십시오: global 에 대한 액세스를 n + 2의 뮤텍스로 래핑하고 보다 관용적인 Global() 를 위해 GetGlobal() 를 더 이상 사용하지 않을 수도 있습니다.)

이는 빠른 수정은 아니지만 점진적 코드 복구에 func 별칭(또는 현재 해결 방법)만 필요하도록 문제를 줄입니다.

@rsc 요약에서 생략한 별칭에 대한 간단한 사용: 긴 이름을 축약하는 것입니다. (아마도 처음에는 패키지와 같은 대규모 프로그래밍 기능이 없었던 Pascal의 유일한 동기일 것입니다.) 사소하지만 내보내지 않은 별칭이 의미가 있는 유일한 사용 사례이므로 언급할 가치가 있습니다.

@jimmyfrasche 맞습니다. 나는 getter와 setter를 사용하는 아이디어를 좋아하지 않지만 (구조 필드에 대해 그것들을 갖고 싶지 않은 것처럼) 당신의 분석은 물론 정확합니다.

별칭의 비수리 사용(예: 드롭인 교체 패키지 만들기)에 대해 짚고 넘어가야 할 점이 있지만 var-aliases의 경우를 약화시킨다는 점을 인정합니다.

@Merovius 는 모든 점에 동의했습니다. 저 역시 만족스럽지는 않지만 논리를 따라야 합니다 v☹v

@niemeyer 는 이전 항목과 새 항목 모두 이름은 같지만 서명이 다른 메서드가 있는 경우 어댑터가 마이그레이션 유형을 지원하는 방법을 명확히 할 수 있습니다. 메소드에 인수를 추가하거나 인수 유형을 변경하는 것은 코드베이스의 일반적인 진화인 것처럼 보입니다.

@rogpeppe 이것이 오늘날 발생하는 방식과 정확히 일치한다는

type two one

이것은 one 및 two 독립 유형을 만들고 interface{} 반영하는지 여부에 관계없이 그것이 보이는 것입니다. one 와 two 사이에서 변환할 수도 있습니다. 위의 어댑터 제안은 어댑터에 대한 마지막 단계를 자동으로 만듭니다. 여러 가지 이유로 제안이 마음에 들지 않을 수 있지만 그것에 대해 모순되는 것은 없습니다.

@iand type two one 와 마찬가지로 두 유형은 완전히 독립적인 메서드 집합을 가지므로 이름을 일치시키는 데 특별한 것은 없습니다. 이전 코드 베이스가 마이그레이션되기 전에 이전 유형(현재 어댑터)의 이전 서명을 사용하여 유지됩니다. 새 유형을 사용하는 새 코드는 새 서명을 사용합니다. 새 유형의 값을 이전 코드에 전달하면 컴파일러는 후자가 전자의 어댑터임을 알고 있으므로 해당 메소드 세트를 사용하기 때문에 자동으로 적용합니다.

@niemeyer 완전히 지정되지 않은 이러한 어댑터 뒤에는 많은 복잡성이 숨어 있는 것 같습니다. 이 시점에서 나는 타입 별칭의 단순함이 그들에게 유리하게 작용한다고 생각합니다. 유형 별칭에 대해서만 업데이트해야 하는 모든 항목을 나열하기 위해 자리에 앉았고 매우 긴 목록입니다. 목록은 어댑터의 경우 확실히 더 길어질 것이며, 나는 여전히 모든 세부 사항을 완전히 이해하지 못합니다. 완전한 제안을 하고 싶다면 지금은 유형 별칭을 사용하고 상대적으로 무거운 어댑터에 대한 결정은 나중에 미루는 것이 좋습니다. .

@jimmyfrasche 별칭의 메서드와 관련하여 별칭은 일반적인 메서드 정의 제한을 우회하는 것을 허용하지 않습니다. 패키지가 유형 T1 = otherpkg.T2를 정의하면 otherpkg.T2에서 직접 메서드를 정의할 수 없는 것처럼 T1에서 메서드를 정의할 수 없습니다. 그러나 패키지가 유형 T1 = T2(둘 다 동일한 패키지에 있음)를 정의하는 경우 대답은 덜 명확합니다. 우리는 제한을 도입할 수 있지만 (아직) 명백한 필요는 없습니다.

최상위 토론 요약을 업데이트했습니다 . 변경 사항:

• GothamGo 비디오에 대한 링크 추가
• @jba에 따라 "긴 이름 축약"을 가능한 용도로 추가했습니다.
• @Merovius에 따라 표준 라이브러리 제한에 대한 인수로 x/image/draw를 추가했습니다.
• @jimmyfrasche에 따라 별칭의 메서드에 대한 추가 텍스트를 추가했습니다.

디자인 문서 추가: golang.org/design/18130-type-alias

일주일 전의 경우와 마찬가지로 유형 별칭에 대한 일반적인 합의가 여전히 있는 것 같습니다. 로버트와 나는 공식 디자인 문서의 초안을 작성했고 방금 체크인했습니다(위 링크).

제안 절차 에 따라 이 문제에 대한 제안에 대한 실질적인 의견을 _여기_에 게시하십시오. 맞춤법/문법/등은 Gerrit 코드 검토 페이지 https://go-review.googlesource.com/#/c/34592/ 로 이동할 수 있습니다

"임베딩에 대한 영향"을 재고하고 싶습니다. 점진적 코드 복구를 위한 유형 별칭의 사용성을 제한합니다. 즉, p1 가 type T1 = T2 유형의 이름을 바꾸고 p2 패키지가 p1.T2 를 구조체에 포함하려는 경우 해당 정의를 p1.T1 로 업데이트할 수 없습니다. p3 가 이름으로 포함된 구조체를 참조할 수 있기 때문입니다. p2 다음은 전환 할 수 없습니다 p1.T1 파괴하지 않고 p3 ; p3 는 현재 p2 하지 않고 이름을 p1.T1 업데이트할 수 없습니다.

이 문제를 해결하는 방법은 a) 일반적으로 포함된 필드를 이름으로 참조하지 않는 코드에 대한 호환성/사용 중단 기간 약속을 제한하거나 b) 별도의 사용 중단 단계를 추가하여 p1 추가 type T1 = T2 와 deprecates T2 다음을 p2 (말)를 참조 deprecates s2.T2 이름으로, 모든 수입 p2 복구됩니다 그렇게 하지 않으려면 p2 로 전환합니다.

이제 이론상 문제는 무한정 반복될 수 있습니다. p4 는 p3 가져올 수 있습니다. p2 ; 이름으로 두 번 포함된 필드를 참조하려면 p3 에도 사용 중단 기간이 있어야 한다고 생각합니다. 이 경우 가장 안쪽의 감가상각 기간이 무한대가 되거나 가장 바깥쪽이 무한대가 됩니다. 그러나 문제를 재귀적 인 것으로 고려하지 않더라도 b) 시간이 꽤 어려울 것입니다 ( p2 의 사용 중단 기간은 p1 의 사용 중단 기간에 완전히 포함되어야 합니다. 적어도 2T에서 선택해야 할 것이다.

a) 또한 나에게 비실용적 인 것 같습니다. 예를 들어 유형에 *byte.Buffer 있고 해당 필드를 설정하려는 경우(또는 해당 버퍼를 다른 함수에 전달하려는 경우), 이름으로 참조하지 않고는 이를 수행할 방법이 없습니다(구조체 이니셜라이저 사용 제외 이름이 없으면 호환성 보장도 손실됩니다. :) ).

byte 와 rune 를 별칭으로 사용할 수 있다는 장점을 이해합니다. 그러나 개인적으로는 점진적인 복구를 위한 유형 별칭의 유용성을 유지하는 데 부차적인 역할을 하고 싶습니다. 둘 다 얻는 아이디어의 (아마도 나쁜) 예는 내보낸 이름에 대해 별칭을 사용하여 포함된 필드를 참조하고 내보내지 않은 이름에 대해 허용하는 것입니다(본질적으로 동일한 패키지로 제한되므로 작성자의 더 많은 제어 하에 있음) ) 현재 제안된 의미를 유지합니까? 네, 저도 이 구분이 싫습니다. 누군가 더 나은 생각을 가지고 있을지도 모릅니다.

별칭에 대한 @rsc re 메서드

동일한 패키지에 정의된 유형 T의 별칭인 유형 S가 있고 S에 대한 메서드 정의를 허용하는 경우 T가 다른 패키지에 정의된 pF의 별칭이면 어떻게 될까요? 그것도 분명히 실패해야 하지만, 고려해야 할 소스의 시행, 구현 및 가독성에는 미묘함이 있습니다(T가 S와 다른 파일에 있는 경우, T)의 정의.

type T = S 경우 T 에서 메소드를 선언할 수 없는 규칙은 절대적이며 소스의 소스를 조사할 필요 없이 적용되는 소스의 한 줄에서 분명합니다. S, 별칭 상황에서와 같이.

또한 로컬 유형 별칭에 메서드를 허용하면 유형 별칭과 유형 정의 간의 구분이 모호해집니다. 어쨌든 메서드는 S와 T 모두에 정의되므로 하나만 쓸 수 있다는 제한이 표현될 수 있는 것을 제한하지 않습니다. 그것은 단지 일을 더 간단하고 균일하게 유지합니다..

@jimmyfrasche type T1 = T2 쓰고 있고 T2가 같은 패키지에 있다면 T2라는 이름을 더 이상 사용하지 않을 것입니다. 이 경우, 우리는 가능한 한 godoc에서 T2의 발생을 최소화하기를 원합니다. 그래서 우리는 모든 메소드를 func (T1) M() 로 선언하고 싶습니다.

@jba godoc 변화는 소스의 가독성을 변경하지 않고 그 요구 사항을 충족 것이라고 별칭에 선언 된 것으로 별칭의 방법을보고합니다. 일반적으로 앨리어싱 및/또는 임베딩이 포함될 때, 특히 유형이 다른 패키지에서 오는 경우 godoc이 유형의 전체 메소드 세트를 표시하는 것이 좋을 것입니다. 문제는 더 많은 언어 의미가 아니라 더 똑똑한 도구로 해결되어야 합니다.

@jba 그런 경우 별칭의 방향을 반대로 type T2 = T1 사용하면 이미 T1 에 동일한 패키지 구조로 메서드를 정의할 수 있습니다. 유일한 차이점은 reflect 패키지에서 보고하는 유형 이름이며 별칭을 추가하기 전에 이름을 구분하지 않는 호출 사이트를 이름에 구분하지 않도록 수정하여 마이그레이션을 시작할 수 있습니다.

@jimmyfrasche 제안 문서에서 :

"T1은 T2를 작성하는 또 다른 방법이기 때문에 자체 메서드 선언 집합이 없습니다. 대신 T1의 메서드 집합은 T2와 동일합니다. 최소한 초기 시도에서는 T1을 다음과 같이 사용하는 메서드 선언에 대한 제한이 없습니다. 동일한 선언에서 T2를 사용하여 제공된 수신기 유형

메소드 수신자 유형으로 pF를 사용하는 것은 결코 유효하지 않습니다.

@mdempsky 나는 명확하지 않았지만 그것이 유효하지 않다고 말했습니다.

제 요점은 특정 코드 줄만 보면 그것이 유효한지 아닌지가 명확하지 않다는 것입니다.

주어진 type S = T , 당신은 또한 볼 필요 T 만드는 것은 확실히 그것은 또한 별명 아닌 별명이 다른 패키지의 유형입니다. 유일한 이점은 복잡성입니다.

별칭에 대한 메서드를 항상 허용하지 않는 것이 더 간단하고 읽기 쉬우며 아무 것도 잃지 않습니다. 나는 혼란스러운 경우가 자주 발생할 것이라고 생각하지 않지만, 다른 곳에서 또는 다르지만 동등한 접근 방식으로 더 잘 처리할 수 없는 것을 얻지 못할 때 가능성을 소개할 필요는 없습니다.

@메로비우스

p1이 유형 유형 T1 = T2의 이름을 바꾸고 패키지 p2가 p1.T2를 구조체에 포함하는 경우 가져오기 p3가 포함된 구조체를 이름으로 참조할 수 있기 때문에 해당 정의를 p1.T1로 업데이트할 수 없습니다.

오늘날 대부분의 경우 익명 필드를 명명된 필드로 변경하고 메서드를 명시적으로 전달하여 이 문제를 해결할 수 있습니다. 그러나 내보내지 않은 메서드에서는 작동하지 않습니다.

또 다른 옵션은 보완하기 위해 두 번째 기능을 추가하는 것입니다. 필드를 익명으로 만들지 않고(또는 명시적으로 이름을 변경하여) 필드의 메서드 집합을 채택할 수 있다면 기본 유형이 변경되더라도 필드 이름이 변경되지 않은 상태로 유지될 수 있습니다.

귀하의 예에서 선언을 고려:

package p2

type S struct {
  p1.T2
}

하나의 보상 기능은 "필드 별칭"일 수 있으며, 이는 별칭 유형과 유사한 구문을 따릅니다.

package p2

type S struct {
  p1.T1
  T2 = T1  // field T2 is an alias for field T1.
}

var s S  // &s.T2 == &s.T1

또 다른 보상 기능은 익명 필드의 메서드 집합을 명시적으로 채택하는 "위임"일 수 있습니다.

package p2

type S struct {
  T2 p1.T1 delegated  // T2 is a field of type T1.
  // The method set of S includes the method set of T1 and forwards those calls to field T2.
}

필자는 필드 별칭을 선호한다고 생각합니다. 왜냐하면 포인터 별칭이나 일관성 버그를 도입하지 않고 구조체의 필드 이름을 바꾸는 다른 종류의 점진적 복구도 가능하기 때문입니다.

@Merovius 주요 문제는 유형이 별칭으로 이름이 바뀌었을 때입니다.

나는 이것을 완전히 고려하지 않았습니다. 간신히 지나가는 생각일뿐입니다.

패키지에 이름을 다시 지정하고 포함하는 별칭을 도입하면 어떻게 될까요?

문제가 해결되는지는 모르겠지만 루프를 깰 시간을 벌 수 있을까요?

@bcmills 그 해결 방법을 생각하지 못했습니다. 감사합니다. 내 생각에 수출되지 않은 방법에 대한 경고는 실제로 (내가 완전히 이해하지 못하는 경우를 제외하고) 실제로 거의 발생하지 않는 것처럼 보일 것입니다. 유용하다고 생각하면 자유롭게 설명하십시오. ). 더 많은 변경 사항을 쌓는 것이 정당화되거나 좋은 생각이 아니라고 생각합니다.

@Merovius 생각하면 할수록 필드 별칭에 대한 아이디어가 마음에

메서드를 명시적으로 전달하는 것은 내보낸 경우에도 지루하고 다른 종류의 리팩토링을 중단합니다(예: 포함된 유형에 메서드를 추가하고 포함하는 유형이 동일한 인터페이스를 계속 충족할 것으로 예상). 그리고 struct 필드의 이름을 바꾸는 것도 점진적인 코드 복구를 가능하게 하는 일반적인 우산에 속합니다.

@메로비우스

p1이 유형 유형 T1 = T2의 이름을 바꾸고 패키지 p2가 p1.T2를 구조체에 포함하는 경우 가져오기 p3가 포함된 구조체를 이름으로 참조할 수 있기 때문에 해당 정의를 p1.T1로 업데이트할 수 없습니다. 그러면 p2는 p3을 중단하지 않고 p1.T1으로 전환할 수 없습니다. p3는 현재 p2와 깨지지 않고 이름을 p1.T1로 업데이트할 수 없습니다.

귀하의 예를 이해하면 다음이 있습니다.

package p1

type T2 struct {}
type T1 = T2

package p2

import "p1"

type S struct {
  p1.T2
  F2 string // see below
}

나는 이것이 구조체 필드의 이름을 바꾸고자 하는 일반적인 경우의 특정한 예일 뿐이라고 생각합니다. S.F2의 이름을 S.F1로 바꾸려는 경우에도 동일한 문제가 적용됩니다.

이 특정한 경우에 우리는 p1의 새 API를 로컬 유형 별칭과 함께 사용하도록 패키지 p2를 업데이트할 수 있습니다.

package p2

import "p1"

type T2 = p1.T1

type S struct {
  T2
}

물론 이것은 장기적으로 좋은 해결책이 아닙니다. 나는 p2가 T2 이름을 제거하기 위해 내보낸 API를 변경해야 한다는 사실을 우회할 방법이 없다고 생각합니다. 이는 필드 이름 바꾸기와 동일한 방식으로 진행됩니다.

"패키지 간 유형 이동"에 관한 참고 사항입니다. 그 공식이 약간 문제가 있지 않습니까?

내가 이해하는 한, 제안은 새 이름을 통해 다른 패키지에 있는 개체 정의를 "참조"할 수 있습니다.

개체 정의를 이동하지 않습니까? (처음에 별칭을 사용하여 코드를 작성하지 않는 한 사용자는 그리기 패키지에서와 같이 별칭이 참조하는 위치를 자유롭게 변경할 수 있습니다.)

@atdiar 다른 패키지의 유형을 참조하는 것은 유형을 이동하는 단계로 사용할 수 있습니다. 예, 별칭은 유형을 이동하지 않지만 이동을 위한 도구로 사용할 수 있습니다.

@Merovius 그렇게 하면 리플렉션 및 플러그인이 중단될 수 있습니다.

@atdiar 죄송합니다만 무슨 말씀을 하시는지 이해가 되지 않습니다. 이 스레드의 원래 의견, 거기에 링크된 점진적 수리에 대한 기사 및 지금까지의 토론을 읽었습니까? 토론에 지금까지 고려되지 않은 주장을 추가하려는 경우 더 명확해야 한다고 생각합니다.

마지막으로 유용하고 잘 작성된 제안서입니다. 유형 별칭이 필요합니다. 유형 별칭 없이 단일 API를 만드는 데 큰 문제가 있습니다. 지금까지는 그렇게 하기 위해 그다지 좋아하지 않는 방식으로 코드를 작성해야 했습니다. 이것은 go v1.8에 포함되어야 하지만 결코 늦지 않았으므로 1.9로 진행하십시오.

@메로비우스
패키지 간에 "유형 이동"에 대해 명시적으로 이야기하고 있습니다. 객체 정의를 변경합니다. 예를 들어, pkg reflect에서 일부 정보는 객체가 정의된 패키지에 연결됩니다.
정의를 이동하면 깨질 수 있습니다.

@kataras 그것은 좋은 문서와 주석에 관한 것이 아니라 단지 유형 정의가 이동되어서는 안 된다는 것입니다. 별칭 제안에 감사하는 만큼 사람들이 그냥 그렇게 할 수 있다고 생각하는 것이 조심스럽습니다.

@atdiar 다시 한번, 원댓글과 지금까지의 토론글을 읽어주세요. 이동 유형과 문제를 해결하는 방법이 이 스레드의 주요 관심사입니다. Russ의 기사가 귀하의 우려 사항을 적절하게 해결하지 못한다고 생각되면 그의 설명이 만족스럽지 않은 이유를 구체적으로 설명하십시오. :)

@kataras 개인적으로 동의하지만 이 기능이 얼마나 중요한지 단순히 주장하는 것이 특별히 도움이 되지 않는다고 생각합니다. 사람들의 우려를 해결하기 위해서는 건설적인 논쟁이 필요합니다. :)

@Merovius 문서를 읽었습니다. 내 질문에 대답하지 않습니다. 충분히 명시적이라고 생각합니다. 이전 별칭 제안을 구현하지 못하게 했던 동일한 문제와 관련이 있습니다.

@atdiar 적어도 이해가 되지 않습니다. 유형을 이동하면 문제가 발생한다고 합니다. 제안은 별칭을 사용하여 점진적인 복구로 이러한 손상을 피하고 이전 유형을 사용하는 코드가 없을 때까지 각 역 종속성을 업데이트한 다음 이전 유형을 제거하는 방법에 대한 것입니다. 나는 당신의 주장, 즉 "반영과 플러그인"이 이러한 가정 하에서 어떻게 무너졌는지 알 수 없습니다. 가정에 의문을 제기하고 싶다면 이미 논의한 바 있습니다.

또한 별칭이 1.8에 들어가지 못하게 막는 문제가 귀하가 말한 것과 어떻게 연결되는지 알 수 없습니다. 내가 아는 한, 각각의 문제는 #17746 및 #17784입니다. 임베딩 문제(파손 또는 반사와 관련된 것으로 해석될 수 있지만 동의하지 않음)를 언급하는 경우 해당 문제는 공식 제안에서 해결됩니다(위 참조, 제안된 솔루션은 더 많은 논의가 필요하다고 생각합니다). 그리고 당신은 당신이 그것을 믿지 않는 이유에 대해 구체적이어야 합니다.

죄송합니다만, 아니요, 충분히 구체적이지 않으셨습니다. 지금까지 언급한 내용과 관련하여 이해를 돕기 위해 언급한 "이전 별칭 제안을 구현하지 못하게 하는 동일한 문제"에 대한 문제 번호가 있습니까? 당신이 말하는 파손에 대한 구체적인 예를 제시할 수 있습니까? 우려 사항을 해결하려면 먼저 다른 사람들이 문제를 이해하도록 도와야 합니다.

@Merovius 따라서 이러한 종속성 중 하나가 reflect.Type.PkgPath()를 보고 있는 전이 종속성의 경우 어떻게 됩니까?
그것은 임베딩 문제에서 발생하는 동일한 문제입니다.

@atdiar 죄송합니다. 지금까지 이 스레드의 논의와 이 제안이 무엇에 관한 것인지

간결하게 다시 표현하자면 다음과 같습니다.

문제는 유형 정의가 자체 위치를 하드코딩한다는 사실을 감안할 때 유형 동등성에 관한 것입니다.
유형 동일성은 런타임에 테스트될 수 있고 테스트되기 때문에 유형 이동이 얼마나 쉬운지 모르겠습니다.

나는 단순히 "이동 유형"의 사용 사례가 멀리 떨어져 있는 야생에서 잠재적으로 많은 패키지를 깨뜨릴 수 있다는 경고를 제기하고 있습니다. 플러그인에 대해서도 비슷한 걱정을 하고 있습니다.

(같은 방식으로 패키지의 포인터 유형을 변경하면 다른 패키지가 많이 손상될 수 있습니다. 병렬 처리로 상황이 더 명확해집니다.)

@atdiar 다시 말하지만, 이 문제는 먼저 이전 위치를 사용 중단하고 역 종속성을 업데이트한 다음 _그 다음_ 유형을 이동하는 두 단계로 유형을 이동하는 것에 관한 것입니다. _물론_ 유형을 이리저리 옮기면 문제가 해결되지만 이것은 이 문제에 관한 것이 아닙니다. 이는 이를 수행하기 위한 점진적이고 다단계 솔루션을 가능하게 하는 것입니다. 여기에 제안된 솔루션이 이 다단계 프로세스를 가능하게 하지 않는다는 우려가 있는 경우 점진적인 복구 커밋의 합당한 순서가 중단을 방지할 수 없는 상황을 정확하고 설명하십시오.

@niemeyer

이것은 하나와 두 개의 독립적인 유형을 만들고 인터페이스를 반영하든{}하든 그것이 바로
당신은 참조하십시오. 하나와 둘 사이를 변환할 수도 있습니다. 위의 어댑터 제안은 그것을 마지막으로 만듭니다.
어댑터에 대한 자동 단계. 여러 가지 이유로 제안이 마음에 들지 않을 수 있지만
그것에 대해 모순.

당신은 사이에서 변환할 수 없습니다

 func() one

그리고

func() two

@Merovius 야생에 존재하는 코드 수리 패키지의 모든 임포터를 변경하는 것을 고려할 수는 없습니다. 그리고 여기에서 패키지 버전 관리를 시작하고 싶지 않습니다.

분명히 말해서, 나는 별칭 제안에 반대하는 것이 아니라 아직 입증된 안전하지 않은 사용 사례를 암시하는 "패키지 간 유형 이동" 공식에 반대합니다.

@jimmyfrasche re 예측 가능성의 메소드 온 앨리어스 유효성:

func (t T) M() 가 때로는 유효하고 때로는 유효하지 않은 경우가 이미 있습니다. 사람들이 이러한 경계를 자주 넘지 않기 때문에 많이 나오지 않습니다. 즉, 실제로 잘 작동합니다. https://play.golang.org/p/bci2qnldej. 어쨌든 이것은 _가능한_ 제한 사항 목록에 있습니다. 가능한 모든 제한과 마찬가지로 복잡성이 추가되며 복잡성을 추가하기 전에 구체적인 실제 증거를 보고 싶습니다.

@Merovius , 이름을 다시 임베딩:

상황이 완벽하지 않다는 데 동의합니다. 그러나 io.ByteBuffer에 대한 참조로 가득 찬 코드베이스가 있고 이를 bytes.Buffer로 옮기고 싶다면 다음을 소개할 수 있기를 원합니다.

package io
type ByteBuffer = bytes.Buffer

_without_ io.ByteBuffer에 대한 기존 참조를 업데이트하지 않습니다. io.ByteBuffer가 포함된 모든 위치가 유형 정의를 별칭으로 대체한 결과로 필드 이름을 Buffer로 자동 변경하면 내가 세상을 망쳤고 점진적인 복구가 없습니다. 대조적으로, 내장된 io.ByteBuffer의 이름이 여전히 ByteBuffer인 경우 점진적인 복구로 용도를 한 번에 하나씩 업데이트할 수 있습니다(여러 단계를 수행해야 하며 다시 이상적이지는 않음).

우리는 #17746에서 이에 대해 어느 정도 논의했습니다. 나는 원래 내장된 io.ByteBuffer 별칭의 이름이 Buffer인 편에 속했지만 위의 주장은 내가 틀렸다고 확신했습니다. 특히 @jimmyfrasche 는 임베디드 사물의 정의에 따라 코드가 변경되지 않는다는 몇 가지 좋은 주장을 했습니다. 포함된 별칭을 완전히 허용하지 않는 것이 좋습니다.

귀하의 예에서 p2에 해결 방법이 있습니다. p2가 io.ByteBuffer를 참조하지 않고 ByteBuffer라는 이름의 포함된 필드를 정말로 원하는 경우 다음을 정의할 수 있습니다.

type ByteBuffer = bytes.Buffer

그런 다음 io.ByteBuffer 대신 ByteBuffer(즉, p2.ByteBuffer)를 포함합니다. 그것도 완벽하지는 않지만 수리를 계속할 수 있음을 의미합니다.

이것이 완벽하지 않고 일반적으로 필드 이름 바꾸기가 이 제안에서 해결되지 않는 경우입니다. 임베딩은 기본 이름에 민감하지 않아야 하며 'X를 이름 N으로 포함'에 대한 일종의 구문이 있어야 합니다. 나중에 필드 별칭을 추가해야 할 수도 있습니다. 둘 다 선험적으로 합리적인 아이디어처럼 보이며 둘 다 필요에 대한 실제 증거를 기반으로 평가된 나중에 별도의 제안이어야 합니다. 유형 별칭이 필드 별칭의 부족이 대규모 리팩토링의 다음 큰 장애물이 되는 지점에 도달하는 데 도움이 된다면 그것은 진전이 될 것입니다!

(/cc @neild 및 @bcmills)

@atdiar , 예, 리플렉션이 이러한 종류의 변경 사항을 꿰뚫어 볼 수 있고 코드가 리플렉션의 결과에 따라

@rsc 내가 염두에 둔 것은 a) 별칭과 동일한 구조체에 정의 유형을 모두 포함하는 것을 금지하고(b에서 모호성을 방지하기 위해), b) 소스 코드에서 두 이름 중 하나로 필드를 참조할 수 있도록 허용하고, c) 하나를 선택하는 것입니다. 또는 생성된 유형 정보/반사 등의 다른 하나(어느 쪽이든 상관 없음).

나는 이것이 내가 설명하려고 했던 종류의 파손을 피하는 데 도움이 되는 동시에 선택이 필요한 경우에 대해 명확한 선택을 하는 데 도움이 된다고 손을 흔들며 주장하고 싶습니다. 그리고 개인적으로 리플렉션을 사용하지 않는 코드보다 리플렉션에 의존하는 코드를 깨뜨리지 않는 것에 덜 신경을 씁니다.

나는 지금 당신의 ByteBuffer 인수를 이해하고 있는지 확실하지 않지만 긴 근무 시간이 끝나기 때문에 더 설명할 필요가 없습니다. 설득력이 없으면 결국 응답하겠습니다. :)

@Merovius 간단한 규칙을 시도하고 더 복잡한 규칙을 도입하기 전에 우리가 얼마나 멀리 있는지 확인하는 것이 합리적이라고 생각합니다. 필요한 경우 나중에 (a)와 (b)를 추가할 수 있습니다. (c)는 상관없이 주어진다.

나는 아마도 (b)가 특정 상황에서는 좋은 생각이지만 다른 상황에서는 그렇지 않을 수도 있다는 데 동의합니다. 앞에서 언급한 "하나의 패키지 API를 여러 구현 패키지로 구조화" 사용 사례에 유형 별칭을 사용하는 경우 별칭을 포함하여 다른 이름(내부 패키지에 있을 수 있고 그렇지 않으면 대부분의 사용자가 액세스할 수 없음). 더 많은 경험을 쌓을 수 있기를 바랍니다.

@rsc

개체 파일에 별칭 가능성에 대한 패키지 수준 정보를 추가하면 도움이 될 수 있습니다.
(go 플러그인이 계속 제대로 작동해야 하는지 여부를 고려하면서.)

@ 메로 비우스 @rsc

a) 별칭과 동일한 구조체에 정의 유형을 모두 포함하는 것을 금지합니다.

많은 경우 임베딩이 메소드 세트와 상호 작용하는 방식의 결과로 이미 금지되어 있습니다. (포함된 유형에 비어 있지 않은 메서드가 설정되어 있고 이러한 메서드 중 하나가 호출되면 프로그램 컴파일에 실패합니다: https://play.golang.org/p/XkaB2a0_RK.)

따라서 이중 임베딩을 금지하는 명시적 규칙을 추가하는 것은 케이스의 작은 하위 집합에서만 차이를 만드는 것처럼 보입니다. 나에게 복잡성의 가치가없는 것 같습니다.

대신에 유형 별칭을 대수적 유형으로 접근하고 유형 집합에 대한 별칭을 지원하여 컴파일 시간 유형 검사와 동등한 빈 인터페이스를 보너스로 얻습니다.

type Stringeroonie = {string,fmt.Stringer}

@j7b

대신 유형 별칭을 대수 유형으로 접근하고 유형 집합에 대한 별칭을 지원하지 않는 이유

별칭은 의미 및 구조적으로 원래 유형과 동일합니다. 대수 데이터 유형은 그렇지 않습니다. 일반적으로 유형 태그에 대한 추가 저장소가 필요합니다. (Go 인터페이스 유형은 이미 해당 유형 정보를 전달하지만 구조체 및 기타 비인터페이스 유형은 그렇지 않습니다.)

@bcmills

이것은 잘못된 추론일 수 있지만 T 유형의 별칭 A로 문제에 접근할 수 있다고 생각했습니다. 이는 A를 인터페이스{}로 선언하고 컴파일러가 A 유형의 변수가 선언된 범위에서 A 유형의 변수를 T로 투명하게 변환하도록 하는 것과 같습니다. , 나는 대부분 선형 컴파일 시간 비용이 될 것이라고 생각했고 모호하지 않으며 type T = 구문을 사용하는 대수학을 포함하여 컴파일러 관리 의사 유형에 대한 기반을 만들고 컴파일 시간에 다음과 같은 불변 참조와 같은 유형을 구현할 수도 있습니다. 사용자 코드에 관한 한, 인터페이스는{} "내부"일 뿐입니다.

그 사고 방식의 결함은 아마도 무지의 산물일 것입니다. 그리고 저는 실용적인 개념 증명을 제공할 수 있는 위치에 있지 않기 때문에 그것이 부족하다는 것을 기꺼이 받아들이고 연기합니다.

@j7b ADT가 하나의 점진적인 수리 문제에 대한 해결책

인터페이스에서{} 투명하게 번역한다는 당신의 아이디어는 []interface{} 와 같은 고차 유형에서도 작동하지 않습니다. 그리고 결국에는 사용자에게 데이터 레이아웃에 대한 제어 권한을 부여하고 대신 모든 것을 래핑하는 Java 작업을 수행하는 go의 장점 중 하나를 잃게 될 것입니다.

ADT는 여기서 해결책이 아닙니다.

@Merovius 대수 유형 구성에 이름 바꾸기가 포함되어 있으면(동일한 정의와 일치함) 이것이 솔루션이라고 확신합니다. 해당 인터페이스는{} 컴파일러 관리 프로젝션 및 선택 형식의 ​​프록시 역할을 할 수 있습니다. 설명되어 있고 데이터 레이아웃이 어떻게 관련되어 있는지, "고차" 유형을 어떻게 정의하는지 잘 모르겠습니다. 선언할 수 있고 []인터페이스{}가 유형일 경우 유형은 유형일 뿐입니다.

그 모든 것을 제쳐두고, 나는 type T = 가 이름 바꾸기를 넘어 직관적이고 유용한 방식으로 오버로드될 가능성이 있다고 확신합니다. 대수 유형과 공개적으로 변경할 수 없는 참조가 가장 명백한 응용 프로그램으로 보이므로 사양이 해당 구문을 명시하기를 바랍니다. 컴파일러 관리 메타 또는 의사 유형을 나타내며 컴파일러 관리 유형이 유용할 수 있는 모든 방법과 이러한 용도를 가장 잘 표현하는 구문을 고려합니다. 새로운 구문은 한정자로 사용될 때 전역적으로 예약된 단어 세트와 관련될 필요가 없기 때문에 type A = alias Type 와 같은 것은 명확하고 확장 가능합니다.

@j7b

그 모든 것을 제쳐두고, 나는 긍정적인 유형 T = 이름을 바꾸는 것 이상으로 직관적이고 유용한 방법으로 과부하가 걸릴 가능성이 있습니다.

나는 확실히 바랍니다. Go는 오늘날 (대부분) 훌륭하게 직교하며, 그 직교성을 유지하는 것은 좋은 일입니다.

오늘날 Go에서 새로운 유형 T를 선언하는 방법은 type T def . 여기서 def 는 새 유형의 정의입니다. 대수 데이터 유형(태그된 공용체라고도 함)을 구현하는 경우 유형 별칭에 대한 구문이 아니라 해당 구문을 따를 것으로 예상합니다.

리팩토링 외에 다른 사용 사례에 대한 통찰력을 제공할 수 있는 유형 별칭의 다른 관점(지원)을 던지고 싶습니다.

잠시 뒤로 물러나서 type T <a type> 형식의 일반 이전 Go 유형 선언이 없었지만 유형 별칭 선언 type A = <a type> 만 있다고 가정해 보겠습니다.

(그림을 완성하기 위해 메소드가 어떻게든 다르게 선언되었다고 가정합시다. 리시버로 사용되는 명명된 유형에 대한 연관을 통하지 않고 그렇게 할 수 없기 때문입니다. 예를 들어, 문자 그대로 메소드가 있는 클래스 유형의 개념을 상상할 수 있습니다. 내부에 있으므로 메서드를 선언하기 위해 명명된 형식에 의존할 필요가 없습니다. 구조적으로 동일하지만 메서드가 다른 두 가지 형식은 다른 형식일 것입니다. 이 사고 실험에서는 세부 사항이 중요하지 않습니다.)

나는 그런 세상에서 우리가 지금 작성하는 것과 거의 같은 코드를 작성할 수 있다고 주장합니다. 우리는 (별칭) 유형 이름을 사용하므로 반복할 필요가 없으며 유형 자체는 유형의 데이터를 사용하도록 합니다. -안전한 길.

다시 말해, Go가 그런 식으로 설계되었다면 우리도 대체로 괜찮았을 것입니다.

더군다나 그런 세계에서는 유형이 구조적으로 동일하면(이름에 관계없이) 유형이 동일하기 때문에 현재 리팩토링과 관련된 문제가 처음에는 나타나지 않았을 것이며 언어 변경.

그러나 우리는 현재 Go에 있는 안전 메커니즘을 갖고 있지 않을 것입니다. 우리는 유형에 대한 이름을 도입할 수 없으며 이것이 이제 새롭고 다른 유형이어야 한다고 명시할 수 없습니다. (그래도 본질적으로 안전 메커니즘이라는 점을 염두에 두는 것이 중요합니다.)

다른 프로그래밍 언어에서는 기존 유형과 다른 새로운 유형을 만드는 개념을 "브랜딩"이라고 합니다. get 유형은 다른 모든 유형과 다르게 만드는 브랜드입니다. 예를 들어, Modula-3에는 이를 가능하게 하는 특수 키워드 BRANDED 가 있었습니다(예: TYPE T = BRANDED REF T0 는 T0에 대한 새롭고 다른 참조를 생성함). Haskell에서는 유형 앞에 new 라는 단어가 비슷한 효과를 냅니다.

대체 Go 세계로 돌아가서 리팩토링에 문제가 없지만 type MyBuffer = []byte 및 type YourBuffer = []byte 실수로 잘못된 유형을 사용하지 않도록 다른 유형입니다. 우리는 정확히 그 목적을 위해 일종의 유형 브랜딩을 도입할 것을 제안할 수 있습니다. 예를 들어, MyBuffer가 이제 YourBuffer와 다른 유형이라는 효과로 type MyBuffer = new []byte 또는 type MyBuffer = new YourBuffer 를 작성할 수 있습니다.

이것은 본질적으로 우리가 현재 가지고 있는 이중적인 문제입니다. Go에서는 처음부터 "브랜드" 유형이 이름을 얻자마자 항상 작업했습니다. 즉, type T <a type> 는 사실상 type T = new <a type> 입니다.

요약하자면: 기존 Go에서 명명된 유형은 항상 "브랜드화된" 유형이며 유형의 이름(이제 유형 별칭이라고 함)에 대한 개념이 부족합니다. 다른 여러 언어에서는 유형 별칭이 표준이며 "브랜딩" 메커니즘을 사용하여 명시적으로 새롭고 다른 유형을 만들어야 합니다.

요점은 두 메커니즘 모두 본질적으로 유용하며 유형 별칭을 사용하여 마침내 두 메커니즘을 모두 지원한다는 것입니다.

@griesemer 해당 기능의 확장은 리팩토링을 이상적으로 정리해야 하는 초기 별칭 제안입니다. 제한된 범위로 인해 유형 별칭만 리팩토링하기 어려운 엣지 케이스를 만들지 않을까 걱정됩니다.

두 제안에서 나는 당신이 설명했듯이 이름이 Go의 유형 정의의 일부이기 때문에 링커의 협업이 필요하지 않아야 하는지 궁금합니다.

저는 오브젝트 코드가 전혀 익숙하지 않아서 그냥 아이디어일 뿐이지만 오브젝트 파일에 커스텀 섹션을 추가하는 것도 가능한 것 같습니다. 우연히 유형 이름과 별칭의 연결 시간에 채워진 일종의 펼쳐진 연결 목록을 유지하는 것이 가능하다면 도움이 될 것입니다. 런타임에는 별도의 컴파일을 희생하지 않고도 필요한 모든 정보가 있습니다.

오류 메시지가 명확하게 유지되도록 런타임이 주어진 유형에 대해 다른 별칭을 동적으로 반환할 수 있어야 한다는 아이디어입니다(별칭은 실행 중인 코드와 작성된 코드 사이에 이름 불일치를 유발하기 때문에).

앨리어싱 사용을 추적하는 것의 대안은 컨텍스트 패키지에 대해 수행된 것처럼 패키지 간에 개체 정의를 "이동"할 수 있도록 전체적으로 구체적인 버전 관리 스토리를 갖는 것입니다. 그러나 그것은 완전히 다른 문제입니다.

결국, 인터페이스에 대한 구조적 동등성을 유지하고 유형에 대한 이름 동등성을 유지하는 것이 여전히 좋은 생각입니다.
유형이 더 많은 제약 조건이 있는 인터페이스로 간주될 수 있다는 사실을 감안할 때 별칭 선언은 슬라이스 유형 이름 문자열의 패키지별 슬라이스를 유지함으로써 구현되어야 하거나 구현될 수 있는 것으로 보입니다.

@atdiar "분리 컴파일"이라고 말할 때 내가하는 일을 의미하는지 잘 모르겠습니다. 패키지 P가 io 및 바이트를 가져오는 경우 세 가지 모두 별도의 단계로 컴파일할 수 있습니다. 그러나 io 또는 bytes가 변경되면 P를 다시 컴파일해야 합니다. io 또는 bytes를 변경한 다음 P의 이전 컴파일을 사용할 수 있는 경우는 _아닙니다_. 플러그인 모드에서도 이것은 사실입니다. 크로스 패키지 인라이닝과 같은 효과로 인해 io 또는 바이트 구현에 대한 API가 보이지 않는 변경 사항이라도 효과적인 ABI를 변경하므로 P를 다시 컴파일해야 합니다. 유형 별칭은 이 문제를 악화시키지 않습니다.

@j7d , 유형 시스템 수준에서 합계 유형 또는 모든 종류의 하위 유형(토론의 앞부분에서 다른 사람들이 제안한 대로)은 특정 종류의 용도에만 도움이 됩니다. bytes.Buffer를 io.Reader의 하위 유형으로 생각할 수 있는 것은 사실입니다("버퍼는 판독기" 또는 귀하의 예에서 "문자열은 스트링거루니"). 문제는 그것들을 사용하여 더 복잡한 유형을 구성할 때 발생합니다. 이 주석의 나머지 부분은 Go 유형에 대해 이야기하지만 Go 언어가 실제로 구현하는 것이 아니라 하위 유형 수준에서 기본적인 관계에 대해 이야기하고 있습니다. 하지만 Go는 기본 관계와 일치하는 규칙을 구현해야 합니다.

유형 생성자("유형을 사용하는 방법"을 말하는 멋진 방법)는 하위 유형 지정 관계를 유지하는 경우 공변이고 관계를 반전하는 경우 반공입니다.

함수 결과에서 유형을 사용하는 것은 공변입니다. func() Buffer는 func() Reader입니다. 왜냐하면 Buffer를 반환한다는 것은 Reader를 반환했음을 의미하기 때문입니다. 함수 인수에서 유형을 사용하는 것은 공변이 _not_입니다. func는 버퍼가 필요하고 일부 리더는 버퍼가 아니기 때문에 func(Buffer)는 func(Reader)가 아닙니다.

함수 인수에서 유형을 사용하는 것은 반공변입니다. func(Reader)는 func(Buffer)입니다. 왜냐하면 func는 Reader만 필요하고 Buffer는 Reader이기 때문입니다. 함수 결과에서 유형을 사용하는 것은 반공변이 _아닌_입니다. func() Reader는 func() 버퍼가 아닙니다. func는 Reader를 반환하고 일부 Reader는 버퍼가 아니기 때문입니다.

둘을 결합하면 func(Reader) Reader는 func(Buffer) 버퍼가 아니며 그 반대도 마찬가지입니다. 인수가 작동하지 않거나 결과가 작동하지 않기 때문입니다. (이 라인에서 작동하는 유일한 조합은 func(Reader) Buffer가 func(Buffer) Reader라는 것입니다.)

일반적으로 func(X1) X2가 func(X3) X4의 (서브타입) X4인 경우 X3은 X1의 (서브타입) X2는 X4의 (서브타입)이어야 합니다. T1과 T2를 교환할 수 있기를 원하는 별칭 사용의 경우 T1이 T2의 하위 유형이고 T2가 T1의 하위 유형인 경우에만 func(T1) T1은 func(T2) T2의 하위 유형입니다. 이는 기본적으로 T1이 T2와 _동일한_ 유형이지 더 일반적인 유형이 아님을 의미합니다.

함수 인수와 결과를 사용한 이유는 이것이 정식 예(그리고 좋은 예)이기 때문입니다. 그러나 복잡한 결과를 빌드하는 다른 방법에서도 마찬가지입니다. 일반적으로 출력에 대한 공분산(예: func() T, <-chan T, 또는 map[...]T) 및 입력에 대한 반공(예: func(T), chan<- T 또는 map[T ]...) 입력+출력에 대한 강제 유형 동일성(예: func(T) T, chan T, *T, 또는 [10]T, []T, 또는 struct {Field T} 또는 변수 유형 T). 실제로 Go에서 가장 일반적인 경우는 예제에서 볼 수 있듯이 입력+출력입니다.

구체적으로, []Buffer는 []Reader가 아니며(파일을 []Reader에는 저장할 수 있지만 []Buffer에는 저장할 수 없기 때문에), []Reader는 []Buffer가 아닙니다([] 리더는 파일을 반환할 수 있지만 []버퍼에서 가져오는 것은 버퍼를 반환해야 함).

이 모든 것의 결론은 코드가 T1 또는 T2를 사용할 수 있도록 일반 코드 복구 문제를 해결하려는 경우 T1을 T2의 하위 유형으로만 만드는(또는 그 반대의 경우) 어떤 방식으로도 수행할 수 없다는 것입니다. 각각은 다른 것의 하위 유형이어야 합니다. 즉, 동일한 유형이어야 합니다. 그렇지 않으면 나열된 용도 중 일부가 유효하지 않습니다.

즉, 서브타이핑만으로는 점진적인 코드 복구 문제를 해결할 수 없습니다. 이것이 유형 별칭이 하위 유형을 시도하는 대신 T1 = T2가 되도록 동일한 유형에 대한 새 이름을 도입하는 이유입니다.

이 의견은 2주 전 일종의 "대체 가능한 유형"에 대한 @iand 의 제안과 기본적으로 그때부터 @griesemer 의 답변의 확장에도 적용됩니다.

최상위 토론 요약을 업데이트했습니다. 변경 사항:

• 희미해진 것처럼 보이는 어댑터 토론의 요약을 업데이트하기 위해 TODO를 제거했습니다.
• 임베딩 및 필드 이름 변경에 대한 요약이 추가되었습니다.
• '별칭에 대한 메서드' 요약을 디자인 질문 목록에서 자체 섹션으로 이동하고 최근 댓글을 포함하도록 확장했습니다.
• 리플렉션을 사용하는 프로그램에 대한 영향에 대한 요약을 추가했습니다.
• 별도의 편집에 대한 논의 요약을 추가했습니다.
• 다양한 하위 유형 기반 접근 방식에 대한 논의 요약이 추가되었습니다.

@rsc 별도의 컴파일과 관련하여 내 의견은 유형 정의가 별칭 목록을 유지해야 하는지(별도의 컴파일 요구 사항 때문에 대규모로 다루기 힘든지) 또는 각 별칭에 다음과 같은 별칭 이름 목록을 반복적으로 작성해야 하는지 여부와 관련이 있습니다. 유형 정의에 제공된 초기 유형 이름과 관련된 가져오기 그래프. (그리고 런타임이 액세스할 수 있도록 해당 정보를 보관하는 방법과 위치).

@atdiar 시스템 어디에도 그러한 별칭 이름 목록이 없습니다. 런타임에 액세스 권한이 없습니다. 별칭은 런타임에 존재하지 않습니다.

@rsc 허, 죄송합니다. 나는 머리에 초기 별칭 제안이 붙어 있고 func에 대한 별칭에 대해 생각하고 있었습니다(유형에 대한 별칭에 대해 논의하는 동안). 이 경우 코드의 이름과 런타임 시 이름 사이에 불일치가 있을 수 있습니다.
이 경우 로깅을 위해 runtime.Frame의 정보를 사용하는 데 약간의 재고가 필요합니다.
나는 신경 쓰지 마.

@rsc 다시 요약 이 의견 의 더 큰 요점은, 즉 이것이 필드 이름을 바꾸는 특별한 경우이며 불가능하다는 점은 이것이 실제로 별도의 문제로 간주되어야(및 해결)되어야 한다고 확신합니다. 점진적인 복구를 위한 필드 이름 변경을 지원하기 위해 요청/제안/토론에 대해 별도의 문제를 여는 것이 의미가 있습니까(동일한 릴리스에서 해결될 수 있음)?

@Merovius , 필드 이름 바꾸기를 위한 점진적 코드 복구가 시퀀스의 다음 문제처럼 보인다는 데 동의합니다. 그 논의를 시작하려면 누군가가 실제 사례 모음을 수집해야 할 것입니다. 그렇게 함으로써 우리는 그것이 광범위한 문제라는 증거를 확보하고 잠재적인 솔루션을 확인할 수 있습니다. 사실 같은 릴리스에서는 그런 일이 일어나지 않는 것 같습니다.

2주만에 돌아왔습니다. 논의가 수렴된 것으로 보인다. 2주 전의 토론 업데이트조차도 상당히 미미했습니다.

다음과 같이 제안합니다.

• 위에서 설명한 문제에 대한 임시 솔루션으로 유형 별칭 제안을 수락합니다.
  사람들이 Go 1.9(2월 1일)를 시작할 때 시도할 수 있도록 구현이 준비되어 있다면.
• 지금(1월) CL을 검토하고 Go 1.9 시작 시 마스터에 병합할 수 있도록 dev.typealias dev 분기를 만듭니다.
• Go 1.9 동결의 시작 부분 근처에 유형 별칭을 유지하는 것에 대한 최종 결정을 내립니다(Go 1.8 주기에서 일반화된 별칭에 대해 했던 것처럼).

+1

나는 이 변화 뒤에 숨은 논의의 역사에 감사드립니다. 시행한다고 합니다. 의심할 여지 없이, 그것은 핵심 기능이라기보다는 언어의 다소 부수적인 세부 사항이 될 것입니다. 따라서 실제 사용 빈도에 비해 언어 및 도구에 복잡성이 추가됩니다. 또한 언어가 부주의하게 남용될 수 있는 더 많은 표면적을 추가합니다. 그렇기 때문에 지나치게 조심하는 것은 좋은 일이고, 지금까지 많은 논의가 있었던 것 같아 기쁩니다.

@Merovius : 제 글을 수정해서 죄송합니다! 아무도 읽지 않는다고 생각했다. 이 의견의 처음에는 gorename 도구와 같은 도구가 이미 존재하는 경우 이 언어 변경이 필요하다는 회의론을 표시했습니다.

@jcao219 이것은 전에도 논의된 적이 있지만 놀랍게도 여기에서 빨리 찾을 수 없는 것 같습니다. 일반 별칭 #16339 및 관련 golang-nuts 스레드에 대한 원래 스레드에서 자세히 설명합니다. 간단히 말해서: 이러한 종류의 도구는 손상을 방지하기 위해 변경 순서를 지정하는 방법이 아니라 복구 커밋을 준비하는 방법만 설명합니다. 도구 또는 사람에 의해 변경이 수행되었는지 여부는 현재 문제에 중요하지 않으며 현재 일부 코드 또는 다른 코드를 손상시키지 않는 커밋 시퀀스가 ​​없습니다(이 문제의 원래 주석 및 관련 문서는 이 진술을 다음에서 더 정당화합니다. -깊이).

보다 자동화된 도구(예: go 도구 등에 통합됨)의 경우 원래 주석은 "언어 변경 대신 도구 또는 컴파일러 전용 변경이 될 수 있습니까?"라는 제목 아래 이 문제를 해결합니다.

결론적으로 변경 사항이 구현되었다고 가정해 보겠습니다. 의심할 여지 없이, 그것은 핵심 기능이라기보다는 언어의 다소 부수적인 세부 사항이 될 것입니다.

저는 의심을 표하고 싶습니다. :) 나는 이것이 예견된 결론이라고 생각하지 않습니다.

@메로비우스

저는 의심을 표하고 싶습니다. :) 나는 이것이 예견된 결론이라고 생각하지 않습니다.

내 생각에 이 기능을 사용하는 사람들은 종속 클라이언트가 많은 중요한 Go 패키지의 유지 관리자가 될 것입니다. 즉, 이미 바둑 전문가에게 이익이 됩니다. 동시에, 새로운 Go 프로그래머가 코드를 읽기 어렵게 만드는 유혹적인 방법을 제시합니다. 예외는 긴 이름의 이름을 바꾸는 사용 사례이지만 자연적인 Go 유형 이름은 일반적으로 너무 길거나 복잡하지 않습니다.

점 가져오기 기능의 경우와 마찬가지로 자습서 및 문서에서는 사용 지침에 대한 설명과 함께 이 기능에 대한 언급을 함께 하는 것이 좋습니다.

예를 들어 "github.com/gonum/graph/simple".DirectedGraph 를 사용하고 simple.DirectedGraph 입력을 피하기 위해 digraph 로 별칭을 지정하고 싶다고 가정해 보겠습니다 . 사용 사례? 아니면 이런 종류의 이름 변경이 protobuf와 같이 생성된 비합리적으로 긴 이름으로 제한되어야 합니까?

@jcao219 , 이 페이지 상단의 토론 요약이 귀하의 질문에 대한 답변입니다. 특히 다음 섹션을 참조하십시오.

• 이것이 언어 변경 대신 도구 또는 컴파일러 전용 변경일 수 있습니까?
• 별칭에는 어떤 다른 용도가 있습니까?
• 제한 사항(해당 섹션을 시작하는 일반 참고 사항)

Go 전문가와 새로운 Go 프로그래머에 대한 보다 일반적인 요점은 Go의 명시적인 목표가 대규모 코드베이스에서 더 쉽게 프로그래밍할 수 있도록 하는 것입니다. 당신이 전문가인지 여부는 작업 중인 코드베이스의 크기와 다소 관련이 없습니다. (아마도 다른 사람이 시작한 새 프로젝트에서 이제 막 시작했을 수도 있습니다. 여전히 이런 종류의 작업을 수행해야 할 수도 있습니다.)

좋아요, 여기의 만장일치/조용함을 기반으로 저는 (지난주 https://github.com/golang/go/issues/18130#issuecomment-268614964에서 제안한 대로) 이 제안을 승인된 것으로 표시하고 dev.typealias 분기를 만들 것입니다. .

훌륭한 요약에는 "유형 별칭에 대한 제안이 해결해야 하는 다른 문제는 무엇입니까?" 섹션이 있습니다. 제안이 수락된 것으로 선언된 후 이러한 문제를 해결하기 위한 계획은 무엇입니까?

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

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

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

@ulikunitz 는 문제를 해결합니다( 설계 문서 의 모든 인용문은 '유형 T1 = T2'를 가정함).

1. godoc에서 처리합니다. 디자인 문서는 godoc에 대한 최소한의 변경 사항을 명시합니다. 추가 지원이 필요한지 여부를 확인할 수 있습니다. 그럴 수도 있지만 아닐 수도 있습니다.
2. 별칭으로 명명된 형식에 메서드를 정의할 수 있습니까? 예. 디자인 문서: "T1은 T2를 작성하는 또 다른 방법이기 때문에 자체 메서드 선언 집합이 없습니다. 대신 T1의 메서드 집합은 T2와 동일합니다. 최소한 초기 시도에서는 메서드 선언에 대한 제한이 없습니다. 동일한 선언에서 T2를 사용하여 제공된 수신기 유형으로 T1을 사용하는 것이 유효합니다."
3. 별칭에 대한 별칭이 허용되는 경우 별칭 주기를 어떻게 처리합니까? 사이클이 없습니다. 설계 문서: "유형 별칭 선언에서 유형 선언과 달리 T2는 T1을 직간접적으로 참조해서는 안 됩니다."
4. 별칭이 내보내지 않은 식별자를 내보낼 수 있어야 합니까? 예. 디자인 문서: "T2의 형식에는 제한이 없습니다. 다른 패키지에서 가져온 유형을 포함하되 이에 국한되지 않는 모든 유형일 수 있습니다."
5. 별칭을 포함하면 어떻게 됩니까(포함된 ​​필드에 액세스하는 방법)? 이름은 별칭(프로그램에서 볼 수 있는 이름)에서 가져옵니다. 디자인 문서: https://golang.org/design/18130-type-alias#effect -on-embedding.
6. 빌드된 프로그램에서 별칭을 기호로 사용할 수 있습니까? 아니요. 디자인 문서: "유형 별칭은 런타임에 대부분 보이지 않습니다." (답은 이것에서 이어지지만 명시적으로 호출되지는 않습니다.)
7. Ldflags 문자열 주입: 별칭을 참조하면 어떻게 될까요? var 별칭이 없으므로 발생하지 않습니다.

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

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

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

@rsc 설명에 감사드립니다.

다음과 같이 가정해 보겠습니다.

package a

import "b"

type T1 = b.T2

내가 이해하는 한 T1은 b.T2와 본질적으로 동일하므로 로컬이 아닌 유형이며 새로운 방법을 정의할 수 없습니다. 그러나 식별자 T1은 패키지 a에서 다시 내보내집니다. 이게 맞는 해석인가요?

@ulikunitz 맞습니다

T1은 b.T2와 정확히 동일한 유형을 나타냅니다. 단순히 다른 이름입니다. 무언가를 내보내는지 여부는 이름에만 기반합니다(표시하는 유형과 관련 없음).

@griesemer 의 응답을 명시적으로 만들려면 예, 패키지 a에서 T1을 내

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

이것은 이제 Go 1.9가 열리기 전에 마스터에 있습니다. 마스터에서 자유롭게 동기화하고 시도해 보십시오. 감사 해요.

#18893에서 리디렉션됨

package main

import (
        "fmt"
        "q"
)

func main() {
        var a q.A
        var b q.B // i'm a named unnamed type !!!

        fmt.Printf("%T\t%T\n", a, b)
}

무엇을 볼 것으로 예상했습니까?

deadwood(~/src) % go run main.go
q.A     q.B

대신 무엇을 보았습니까?

deadwood(~/src) % go run main.go
q.A     []int

논의

별칭은 명명되지 않은 유형에 적용되지 않아야 합니다. 이름 없는 유형에서 다른 유형으로 이동하는 "코드 복구" 이야기가 아닙니다. 명명되지 않은 유형에 별칭을 허용한다는 것은 더 이상 단순히 명명된 유형과 명명되지 않은 유형으로 Go를 가르칠 수 없다는 것을 의미합니다. 대신 나는 말해야 한다.

오, 별칭이 아닌 경우 다른 패키지에서 로 가져올 때도 이름이 지정되지 않은 유형일 수 있음을 기억해야 합니다.

그리고 더 나쁜 것은 사람들이 다음과 같은 가독성 안티 패턴을 공표하는 것을 가능하게 할 것입니다.

type Any = interface{}

이름 없는 유형의 별칭을 허용하지 마십시오.

@davecheney

이름 없는 유형에서 다른 유형으로 이동할 때 "코드 복구" 이야기는 없습니다.

사실이 아니다. 메소드 매개변수의 유형을 명명된 유형에서 명명되지 않은 유형으로 또는 그 반대로 변경하려면 어떻게 해야 합니까? 1단계는 별칭을 추가하는 것입니다. 2단계는 새 유형을 사용하도록 해당 메소드를 구현하는 유형을 업데이트하는 것입니다. 3단계는 별칭을 제거하는 것입니다.

(메소드 이름을 두 번 변경하면 오늘 할 수 있는 것이 사실입니다. 이중 이름 바꾸기는 기껏해야 지루합니다.)

그리고 더 나쁜 것은 사람들이 다음과 같은 가독성 안티 패턴을 공표하는 것을 가능하게 할 것입니다.
type Any = interface{}

사람들은 오늘 이미 type Any interface{} 쓸 수 있습니다. 이 경우 별칭이 추가로 발생하는 피해는 무엇입니까?

오늘날 사람들은 이미 모든 인터페이스 유형을{} 작성할 수 있습니다. 이 경우 별칭이 추가로 발생하는 피해는 무엇입니까?

그것이 바로 그것이기 때문에 나는 그것을 안티 패턴이라고 불렀습니다. type Any interface{} , 코드를 작성하는 사람이 코드를 조금 더 짧게 입력하기 때문에 더 이해하기 쉽습니다.

반면에 Go 코드를 읽은 경험이 있고 interface{} 를 거울에 비친 자신의 얼굴처럼 본능적으로 인식하는 독자 _모두_는 Any 의 모든 변형을 배우고 다시 배워야 합니다. , Object , T , 패키지별로 type Any interface{} , type Any map[interface{}]interface{} , type Any struct{} 와 같은 항목에 매핑합니다.

일반적인 Go 관용구에 대한 패키지 특정 이름이 가독성에 부정적인 영향을 미친다는 데 동의하십니까?

일반적인 Go 관용구에 대한 패키지 특정 이름이 가독성에 부정적인 영향을 미친다는 데 동의하십니까?

동의하지만 문제의 예(지금까지 내가 만난 반패턴 중 가장 흔한 경우)는 별칭 없이 수행될 수 있으므로 해당 예가 유형 별칭 제안과 어떻게 관련되는지 이해하지 못합니다.

안티 패턴이 유형 별칭 없이 가능하다는 사실은 이름 없는 유형에 대한 별칭이 존재할 수 있는지 여부에 관계없이 이미 Go 프로그래머에게 이를 방지하도록 교육해야 함을 의미합니다.

그리고 실제로 유형 별칭을 사용하면 이미 존재하는 코드베이스에서 해당 반패턴을 _점진적으로 제거_할 수 있습니다.

고려하다:

package antipattern

type Any interface{}  // not an alias

type Widget interface{
  Frozzle(Any) error
}

func Bozzle(w Widget) error {
  …
}

오늘날 antipattern.Bozzle 사용자는 Widget 구현에서 antipattern.Any 사용에 갇히게 되며 점진적인 수리로 antipattern.Any 를 제거할 방법이 없습니다. 그러나 유형 별칭을 사용하면 antipattern 패키지 소유자가 다음과 같이 재정의할 수 있습니다.

// Any is deprecated; please use interface{} directly.
type Any = interface{}

이제 호출자는 Any 에서 interface{} 점진적으로 마이그레이션하여 antipattern 유지 관리자가 결국 제거할 수 있습니다.

내 요점은 명명되지 않은 유형의 별칭을 지정하는 것에 대한 정당성이 없다는 것입니다.
이 옵션을 허용하지 않으면
연습.

반대로 명명되지 않은 유형의 앨리어싱을 허용하려면 하나가 아니라 둘을 활성화합니다.
이 안티 패턴의 형태.

2017년 2월 2일 목요일 16:34 Bryan C. Mills [email protected]이 다음과 같이 썼습니다.

당신은 흔한 Go 관용구에 대한 패키지 특정 이름이 다음과 같다는 데 동의합니다.
가독성에 대한 순 네거티브?

동의하지만 문제의 예 이후(지금까지 가장 일반적인
내가 만난 반패턴의 발생) 없이 수행할 수 있습니다.
별칭, 나는 그 예가
유형 별칭.

타입 앨리어스 없이 안티패턴이 가능하다는 사실은
우리는 이미 Go 프로그래머에게 그것을 피하도록 교육해야 합니다.
명명되지 않은 유형에 대한 별칭이 존재할 수 있습니다.

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

@davecheney 아직 임의의 유형 리터럴 이름을 설계 문서 에서 자세히 설명했습니다. 이 시점에서 얼마 동안 이것을 사용하고 그것이 우리를 어디로 이끄는지 보는 것이 합리적입니다.

이에 반해 API가 클라이언트를 특정 유형으로 제한하는 것을 원하지 않기 때문에 유형 리터럴만 사용하는 공개 API가 있습니다(예: https://golang.org/pkg/go/types/#Info 참조). ). 명시적 형식 리터럴이 있으면 유용한 문서가 될 수 있습니다. 그러나 동시에 같은 유형의 리터럴을 모든 곳에서 반복해야 하는 것은 상당히 성가실 수 있습니다. 실제로 가독성에 방해가 됩니다. map[int]struct{} IntSet 정의에 얽매이지 않고 IntSet 에 대해 편리하게 이야기할 수 있다는 것은 제 생각에 플러스입니다. 여기서 type IntSet = map[int]struct{} 가 정확히 맞습니다.

마지막으로, 놓친 경우를 대비하여 https://github.com/golang/go/issues/18130#issuecomment -268411811을 다시 참조하고 싶습니다. = 사용하는 무제한 유형 선언은 실제로 "기본" 유형 선언이며, 마침내 Go에서 사용할 수 있게 되어 기쁩니다.

아마도 type intSet = map[int]struct{} (내보내지 않음)가 이름 없는 유형 별칭을 사용하는 더 나은 방법일 수 있지만 기능을 제한하기보다는 CodeReviewComments 및 권장 프로그래밍 방식의 도메인처럼 들립니다.

즉, %T 는 유형 시스템을 디버깅하거나 탐색할 때 유형을 확인하는 편리한 도구입니다. 별칭을 포함하는 유사한 형식의 동사가 있어야 하는지 궁금합니다. @davecheney 의 예에서 q.B = []int .

@nathany 그 동사를 어떻게 구현합니까? 별칭 정보는 런타임에 존재하지 않습니다. ( reflect 패키지에 관한 한 별칭은 별칭이 지정된 것과 _동일한 유형_입니다.)

@bcmills 그럴수도 있겠다 싶었는데 ... 😞

정적 분석 도구와 편집기 플러그인이 여전히 그림에 있어 별칭으로 작업하는 데 도움이 된다고 생각하므로 괜찮습니다.

2017년 2월 2일 오후 5시 1분에 "Nathan Youngman" [email protected]이 다음과 같이 썼습니다.

즉, %T는 디버깅하거나 탐색할 때 유형을 확인하는 편리한 도구입니다.
유형 시스템. 비슷한 형식의 동사가 있어야 하는지 궁금합니다.
별칭을 포함합니까? @davecheney의 qB = []int
https://github.com/davecheney 의 예.

더 나은 해결책은 이에 대한 답변을 위해 전문가에게 쿼리 모드를 추가하는 것입니다.
질문:

이것은 전체 GOPATH(또는 주어진 패키지)에서 선언된 별칭입니다.
명령줄에 이 유형이 지정되었습니까?

이름 없는 유형의 앨리어싱 남용에 대해 걱정하지 않지만 잠재적인
이름이 지정되지 않은 동일한 유형에 별칭을 복제했습니다.

@davecheney 상단에 있는 토론 요약의 "제한 사항" 섹션에 귀하의 제안을 추가했습니다. 모든 제한 사항과 마찬가지로 우리의 일반적인 입장은 제한 사항이 복잡성을 추가하고(위 참고 사항 참조) 제한 사항을 도입하기 위해 광범위한 피해의 실제 증거를 확인해야 할 가능성이 높다는 것입니다. 바둑을 가르치는 방식을 바꾸는 것만으로는 충분하지 않습니다. 언어를 변경하려면 바둑을 가르치는 방식을 바꿔야 합니다.

디자인 문서와 메일링 리스트에서 언급했듯이, 우리는 설명을 더 쉽게 하기 위해 더 나은 용어를 사용하기 위해 노력하고 있습니다.

@minux @bcmills가 지적한 것처럼 별칭 정보는 런타임에 존재하지 않습니다(완전히 디자인의 기본). "별칭을 포함하는 %T"를 구현할 방법이 없습니다.

2017년 2월 2일 오후 8시 33분에 "Russ Cox" [email protected]이 다음과 같이 썼습니다.

@minux https://github.com/minux , @bcmills처럼
https://github.com/bcmills 지적, 별칭 정보가 존재하지 않습니다
런타임 시(완전히 디자인의 기본). 방법이 없다
"별칭을 포함하는 %T"를 구현하십시오.

Go guru(https://golang.org/x/tools/cmd/guru) 쿼리 모드를 제안합니다.
정적 코드 분석을 기반으로 하는 역 별칭 매핑용입니다. 그것
런타임에 별칭 정보를 사용할 수 있는지 여부는 중요하지 않습니다.

@minux , 오, 당신은 이메일을 통해 답장을 하고 있고 Github은 인용된 텍스트를 당신이 직접 쓴 텍스트처럼 보이게 합니다. 나는 당신이 네이선 영먼에게서 인용한 텍스트에 답장을 보내고 있었는데, 그것이 당신의 것이라고 생각했습니다. 혼란을 드려 죄송합니다.

용어 및 교육과 관련하여 브랜드 유형 배경 @griesemer 가 매우 유익하게 게시 되었음을 알았 습니다. 감사합니다.

유형과 유형 변환을 설명할 때, baby gophers는 처음에 내가 다른 언어에 익숙하기 때문에 유형 별칭에 대해 이야기하고 있다고 생각합니다.

최종 용어가 무엇이든 간에 명명된(브랜드화된) 유형 앞에 유형 별칭을 도입하는 것을 상상할 수 있습니다. 특히 새 명명된 유형을 선언하는 것은 책이나 커리큘럼에서 byte 및 rune 를 도입한 후에 나올 가능성이 높기 때문입니다. 그러나 안티 패턴을 조장하지 않는 @davecheney 의 우려를 염두에 두고 싶습니다.

type intSet map[int]struct{} map[int]struct{} 가 _underlying_ 유형이라고 합니다. type intSet = map[int]struct{} 의 양쪽을 무엇이라고 합니까? 별칭 및 별칭 유형?

%T 관해서는 byte 및 rune 결과가 uint8 및 int32 된다는 것을 이미 설명해야 하므로 이것은 아닙니다. 다른.

무엇이든 유형 별칭을 사용하면 byte 및 rune 더 쉽게 설명할 수 있습니다. IMO에서 도전 과제는 명명된 유형과 유형 별칭을 사용할 때를 알고 이를 전달할 수 있어야 합니다.

@nathany 나는 "별칭 유형"을 먼저 소개하는 것이 매우 합리적이라고 생각합니다. 비록 이 용어를 반드시 사용하지는 않겠지만. 새로 도입된 "별칭" 선언은 특별한 작업을 수행하지 않는 단순히 일반 선언입니다. 왼쪽의 식별자와 오른쪽의 유형은 하나이며 동일하며 동일한 유형을 나타냅니다. 별칭 또는 별칭 유형이라는 용어가 필요한지 잘 모르겠습니다(상수 이름을 별칭이라고 부르지 않고 상수 값을 별칭 상수라고 부릅니다).

기존(비별칭) 유형 선언은 더 많은 작업을 수행합니다. 먼저 왼쪽에 있는 식별자를 바인딩하기 전에 오른쪽에 있는 유형에서 새 유형을 만듭니다. 따라서 오른쪽의 식별자와 유형은 동일하지 않습니다(동일한 기본 유형만 공유함). 이것은 분명히 더 복잡한 개념입니다.

이제 모든 유형이 이름을 가질 수 있으므로 새로 생성된 유형에 대한 새 용어가 필요합니다. 그리고 그것들을 참조하는 사양 규칙(유형 식별, 할당 가능성, 수신기 기본 유형)이 있으므로 참조할 수 있어야 합니다.

교육 환경에서 유용할 수 있는 이것을 설명하는 또 다른 방법이 있습니다. 유형은 유색이거나 유색일 수 있습니다. 모든 미리 선언된 유형과 모든 유형 리터럴은 색상이 지정되지 않습니다. 새로운 색상 유형을 만드는 유일한 방법은 오른쪽에 있는 유형을 한 번도 사용하지 않은 완전히 새로운 색상(이전 색상 제거, 있다면 왼쪽에 있는 식별자를 그것에 바인딩하기 전에 완전히 프로세스에서). 다시 말하지만, 식별자와 (암시적으로 그리고 보이지 않게 생성된) 유색 유형은 동일하지만 오른쪽에 기록된 (다른 유색 또는 무색) 유형과 다릅니다.

이 비유를 사용하여 기존의 다양한 규칙도 다시 공식화할 수 있습니다.

• 유색 유형은 항상 다른 유형과 다릅니다(각 유형 선언은 사용된 적이 없는 완전히 새로운 색상을 사용하기 때문입니다).
• 메소드는 색상이 지정된 수신기 기본 유형에만 연관될 수 있습니다.
• 유형의 기본 유형은 모든 색상을 제거한 유형입니다.
  등.

우리는 상수 이름을 별칭이라고 부르지 않고 상수 값을 별칭 상수라고 부릅니다.

좋은점 👍

유색과 무채색의 비유가 더 이해하기 쉬운지 확실하지 않지만 개념을 설명하는 방법은 여러 가지가 있음을 보여줍니다.

기존의 이름/브랜드/색상 유형은 확실히 더 많은 설명이 필요합니다. 특히 기존의 명명된 유형을 사용하여 명명된 유형을 선언할 수 있는 경우. 염두에 두어야 할 상당히 미묘한 차이가 있습니다.

type intSet map[int]struct{} // a new type with an underlying type map[int]struct{}

type myIntSet intSet // a new type with an underlying type map[int]struct{}

type otherIntSet = intSet // just another name (alias) for intSet, add methods to intSet (only in the same package)

type literalIntSet = map[int]struct{} // just another name for map[int]struct{}, no adding methods

그래도 극복할 수 없는 것은 아니다. 이것이 Go 1.9에 포함된다고 가정하면, 나는 우리가 여러 Go 책의 두 번째 판을 보게 될 것이라고 생각합니다. 😉

나는 정기적으로 Go spec에서 허용되는 용어를 참조하므로 결국 어떤 용어가 선택되는지 매우 궁금합니다.

이제 모든 유형이 이름을 가질 수 있으므로 새로 생성된 유형에 대한 새 용어가 필요합니다.

몇 가지 아이디어:

• "distinguished" 또는 "distinct"(에서와 같이, 다른 유형과 구별될 수 있음)
• "unique"(in, 그것은 다른 모든 유형과 다른 유형입니다)
• "구체적인"(런타임에 존재하는 엔터티와 같이)
• "식별 가능한"(예: 유형에 ID가 있음)

@bcmills 우리는 고유한, 고유한, 고유한, 브랜드가 있는, 색상이 지정된, 정의된, 별칭이 아닌 등의 유형에 대해 생각해 왔습니다. "콘크리트"는 인터페이스도 색상을 지정할 수 있고 인터페이스는 추상 유형의 화신이기 때문에 오해의 소지가 있습니다. "struct{int}"는 명시적으로(별칭이 아닌) 명명된 형식과 마찬가지로 식별할 수 있기 때문에 "식별 가능"도 오해의 소지가 있는 것 같습니다.

나는 반대 추천합니다:

• "색상"(비프로그래밍 컨텍스트에서 "색상 유형"이라는 문구는 인종적 편견을 강하게 함축함)
• "비별칭"(별칭의 대상이 이전에 "명명된 유형"이라고 했던 것일 수도 있고 아닐 수도 있기 때문에 혼란스럽습니다)
• "정의됨"(별칭도 정의됨, 별칭으로 정의됨)

"branded"는 효과가 있을 수 있습니다: 그것은 "소와 같은 유형"을 의미하지만 본질적으로 나쁘다고 생각하지는 않습니다.

독특하고 독특한 것은 지금까지 눈에 띄는 옵션처럼 보입니다.

추가 컨텍스트나 지식 없이도 간단하고 이해할 수 있습니다. 내가 그 구별을 모른다면, 나는 적어도 그것들이 의미하는 바에 대해 일반적인 감각을 가지고 있다고 생각합니다. 다른 선택에 대해서는 말할 수 없습니다.

일단 용어를 배우면 중요하지 않지만 함축적인 이름은 구별을 내면화하는 데 불필요한 장벽을 피합니다.

이것은 자전거 보관소 논쟁의 정의입니다. Robert는 https://go-review.googlesource.com/#/c/36213/에 보류 중인 CL이 있으며 완벽하게 괜찮은 것 같습니다.

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

go fix 다시 제기하고 싶습니다.

내가 별칭을 '삭제'할 것을 제안하지 않는다는 점을 분명히 하기 위해. 다른 직업에 유용하고 적합한 것일 수도 있습니다. 그건 또 다른 이야기입니다.

제목이 움직이는 유형에 관한 것이라는 것은 매우 중요한 IMO입니다. 나는 문제를 혼란스럽게 만들고 싶지 않습니다. 우리의 목표는 프로젝트에서 일종의 인터페이스 변경을 처리하는 것입니다. 인터페이스에 변화가 생겼을 때 모든 사용자가 이 두 인터페이스(이전 및 신규)를 결국 동일 바랍니다 .

@tux21b가 제안한 아이디어처럼 나는 여전히 도구를 코드를 복구하는 가장 좋은 방법으로 생각합니다. 예를 들어:

$ cat "$GOROOT"/RENAME
# This file could be used for `go fix`
[package]
x/net/context=context
[type]
io.ByteBuffer=bytes.Buffer

$ go fix -rename "$GOROOT"/RENAME [packages]
# -- or --
# use a standard libraries rename table as default
$ go fix -rename [packages]
# -- or --
# include this fix as default
$ go fix [packages]

@rsc 가 여기서 그러나 이 작업 흐름에서는 그렇지 않다고 생각합니다 . 오래된 패키지(예: 종속성)가 더 이상 사용되지 않는 패키지 이름/경로를 사용하는 경우(예: x/net/context ) 처음에는 코드를 수정할 수 있습니다. , 문서가 텍스트 형식의 구성 가능한 테이블을 통해 코드를 새 버전으로 마이그레이션하지만 하드 코딩하지 않는 방법을 말하는 것처럼. 그런 다음 새 버전의 Go와 동일하게 원할 때마다 도구를 사용할 수 있습니다. 부작용이 있습니다. 코드가 수정됩니다.

@LionNatsu , 당신이 옳다고 생각하지만 그것은 별개의 문제라고 생각합니다. 기계적 방식으로 API 변경에 대한 응답으로 코드를 업데이트하는 방법을 잠재 고객에게 설명하기 위해 패키지에 대한 규칙을 채택해야 합니까? 아마도, 하지만 우리는 그 규약이 무엇인지 알아내야 할 것입니다. 이 대화를 다시 가리키면서 이 주제에 대한 별도의 문제를 열 ​​수 있습니까? 감사 해요.

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

팁에 이 제안을 사용하여 이제 이 패키지를 만들 수 있습니다.

package safe

import "unsafe"

type Pointer = unsafe.Pointer

프로그램에서 unsafe 직접 가져오지 않고 unsafe.Pointer 값을 생성할 수 있습니다.

package main

import "safe"

func main() {
    x := []int{4, 9}
    y := *(*int)(safe.Pointer(uintptr(safe.Pointer(&x[0])) + 8))
    println(y)
}

원래 별칭 선언 디자인 문서에서는 이를 명시적으로 지원한다고 명시하고 있습니다. 이 새로운 유형의 별칭 제안에서는 명시적이지 않지만 작동합니다.

별칭 선언 문제에서 이에 대한 합리적 이유는 다음과 같습니다. _"unsafe.Pointer에 대한 별칭 지정을 허용하는 이유는 unsafe.Pointer가 기본 유형으로 포함된 유형을 이미 정의할 수 있기 때문입니다."_ https://github.com/ golang/go/issues/16339#issuecomment -232435361

그것이 사실이지만 unsafe.Pointer 의 별칭을 허용하면 새로운 것이 도입된다고 생각합니다. 프로그램은 이제 안전하지 않은 것을 명시적으로 가져오지 않고도 unsafe.Pointer 값을 생성할 수 있습니다.

이 제안 전에 위의 프로그램을 작성하려면 safe.Pointer 캐스트를 안전하지 않은 가져오기 패키지로 옮겨야 합니다. 이것은 프로그램이 안전하지 않은 사용에 대해 감사하는 것을 조금 더 어렵게 만들 수 있습니다.

@crawshaw , 당신은 전에 이것을 할 수 없었습니까?

package safe

import (
  "reflect"
  "unsafe"
)

func Pointer(p interface {}) unsafe.Pointer {
  switch v := reflect.ValueOf(p); v.Kind() {
  case reflect.Uintptr:
    return unsafe.Pointer(uintptr(v.Uint()))
  default:
    return unsafe.Pointer(v.Pointer())
  }
}

main 패키지에서 가져오기가 부족하여 정확히 동일한 프로그램을 컴파일할 수 있다고 생각합니다.

: (그것은 반드시 올바른 프로그램이되지 않을 것 uintptr Di의 Pointer 가 충족하지 않도록, 변환 함수 호출을 포함 unsafe 해당 패키지 제약 조건을 " 모두 변환이 "그들 사이에만 개입 산술과 같은 표현에 표시해야합니다. 그러나, 나는 그것을 가져 오지 않고 동등한 유효한 프로그램을 구축 할 수있을 것입니다 의심 unsafe 에서 main 결정에 의해 reflect.SliceHeader 와 같은 것을 사용합니다.)

숨겨진 안전하지 않은 유형을 내보내는 것은 감사에 추가해야 할 또 다른 규칙인 것 같습니다.

예, unsafe.Pointer를 직접 별칭으로 지정하면 코드를 감사하기가 더 어려워지고 아무도 그렇게 하지 않기를 바랍니다.

@crawshaw 내 의견에 따르면 이것은 유형 앨리어싱이 있기 전에도 마찬가지였습니다. 다음이 유효합니다.

package a

import "unsafe"

type P unsafe.Pointer

package main

import "./a"
import "fmt"

var x uint64 = 0xfedcba9876543210
var h = *(*uint32)(a.P(uintptr(a.P(&x)) + 4))

func main() {
    fmt.Printf("%x\n", h)
}

즉, 패키지 메인에서 unsafe 패키지가 없고 a.P 가 별칭이 아니더라도 a.P 사용하여 안전하지 않은 산술을 수행할 수 있습니다. 이것은 항상 가능했습니다.

당신이 언급하는 다른 것이 있습니까?

내 실수. 나는 그것이 효과가 없다고 생각했다. (나는 unsafe.Pointer에 적용되는 특수 규칙이 여기에서 정의된 새 유형에 전파되지 않는다는 인상을 받았습니다.)

사양은 실제로 이것에 대해 명확하지 않습니다. 이동 / 유형의 구현을 보면, 내 초기 구현이 필요한 것으로 나타났다 unsafe.Pointer 의 기본 유형이하는 일이 정확히뿐 아니라 어떤 종류의 unsafe.Pointer . go/types를 gc와 호환되도록 변경했을 때 #6326을 찾았습니다.

아마도 우리는 이것을 일반 유형 정의에 대해 허용하지 않고 unsafe.Pointer 별칭도 허용하지 않아야 합니다. 나는 그것을 허용하는 좋은 이유를 볼 수 없으며 안전하지 않은 코드에 대해 unsafe 를 가져와야 하는 명시성을 손상시킵니다.

https://github.com/golang/go/issues/19306을 만들었습니다

이런 일이 일어났습니다. 나는 여기에 아무것도 남아 있지 않다고 생각합니다.