Мне нравится, насколько это визуально однородно.

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

Итак, во-первых, я просто хотел поблагодарить вас за эту прекрасную рецензию. Я думаю, что лучшим решением является введение псевдонимов типов с помощью оператора присваивания. Это не требует новых ключевых слов / операторов, использует знакомый синтаксис и должно решить проблему рефакторинга для больших баз кода.

Как указано в статье Русса, любое решение, подобное псевдониму, должно корректно решать https://github.com/golang/go/issues/17746 и https://github.com/golang/go/issues/17784.

Спасибо за описание этой статьи.

Я считаю, что псевдонимы только для типов, использующие оператор присваивания, являются лучшими:

type OldAPI = NewPackage.API

Мои причины:

• Так проще.
  Альтернативное решение => имеющее несколько иное значение, основанное на его операнде, кажется неуместным для Go.
• Он целенаправлен и консервативен.
  Проблема с типами решена, и вам не нужно беспокоиться о сложностях обобщенного решения.
• Это эстетично.
  Думаю, это выглядит приятнее.

Все вышеперечисленное: простой, сфокусированный, консервативный и эстетичный результат позволяет мне легко представить себе, что это часть 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
)

Как обсуждалось ранее, недостатком является то, что вводится новое ключевое слово только верхнего уровня, что, по общему признанию, неудобно, хотя технически осуществимо и полностью обратно совместимо. Мне нравится этот синтаксис, потому что он отражает схему импорта. Мне казалось бы естественным, что экспорт будет разрешен только в том же разделе, где разрешен импорт, т.е. между предложением о пакете и любым TLD типа, типа, константы или функции.

Идентификаторы переименования будут объявлены в области пакета, однако новые имена не видны в объявляющем их пакете (newfmt в приведенном выше примере) в отношении повторного объявления, которое, как обычно, запрещено. В предыдущем примере 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 только для типа.

Если требуется более общее решение, я согласен с @cznic в том, что выделенное ключевое слово лучше, чем новый оператор (особенно асимметричный оператор с запутанной направленностью [1]). При этом я не думаю, что ключевое слово export передает правильное значение. Ни синтаксис, ни семантика не отражают import . А как насчет alias ?

Я понимаю, почему @cznic не хочет, чтобы новые имена были доступны в пакете, объявляющем их, но, по крайней мере, для меня это ограничение кажется неожиданным и искусственным (хотя я прекрасно понимаю причину этого).

[1] Я использую Unix почти 20 лет и до сих пор не могу создать символическую ссылку с первой попытки. И я обычно терплю неудачу даже со второй попытки, после прочтения инструкции.

Я хотел бы предложить дополнительное ограничение: псевдонимы типов для стандартных библиотечных типов могут быть объявлены только в стандартной библиотеке.

Мое рассуждение состоит в том, что я не хочу работать с кодом, в котором были переименованы концепции стандартных библиотек, чтобы соответствовать пользовательскому соглашению об именах. Я также не хочу иметь дело с длинными спагетти-цепочками псевдонимов в нескольких пакетах, которые в конечном итоге возвращаются в стандартную библиотеку.

@iand : это ограничение заблокировало бы использование этой функции для переноса чего-либо в стандартную библиотеку. Речь идет о текущей миграции Context в стандартную библиотеку. Старый дом Context должен стать псевдонимом для Context в стандартной библиотеке.

@quentinmit , к сожалению, это правда. Это также ограничивает вариант использования golang.org/x/image/draw в этом CL https://go-review.googlesource.com/#/c/32145/

Меня больше всего беспокоит, что люди используют псевдонимы вроде interface{} и error

Если будет принято решение о введении нового оператора, предлагаю ~ . В английском языке это обычно означает «похожий на», «приблизительно», «примерно» или «примерно». Как указано выше в => - это асимметричный оператор с запутанной направленностью.

Например:

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

@i, и если мы ограничим правую часть идентификатором, квалифицированным для пакета, то это избавит вас от конкретной озабоченности.

Это также означало бы, что у вас не может быть псевдонимов для любых типов в текущем пакете или для длинных выражений типа, таких как map[string]map[int]interface{} . Но такое использование не имеет ничего общего с основной целью постепенного восстановления кода, так что, возможно, это не большая потеря.

@cznic , @iand , другие: обратите внимание, что _restrictions добавляют сложность_. Они усложняют объяснение функции и добавляют когнитивную нагрузку для любого пользователя функции: если вы забудете об ограничении, вам придется ломать голову, почему то, что, по вашему мнению, должно работать, не работает.

Часто ошибочно вводить ограничения на пробную версию дизайна исключительно из-за гипотетического неправильного использования. Это произошло при обсуждении предложения псевдонима, и из-за этого псевдонимы в пробной версии не смогли обработать преобразование io.ByteBuffer => bytes.Buffer из статьи. Частично цель написания статьи состоит в том, чтобы определить некоторые случаи, которые, как мы знаем, мы хотим иметь возможность обрабатывать, чтобы мы случайно не ограничили их.

В качестве другого примера, было бы легко сделать аргумент неправильного использования, чтобы запретить приемники без указателя или запретить методы для неструктурных типов. Если бы мы сделали одно из этих действий, вы не смогли бы создавать перечисления с методами String () для печати самих себя, и у вас не могло бы быть http.Headers одновременно являясь простой картой и предоставляя вспомогательные методы. Часто легко представить себе злоупотребления; Для появления убедительных положительных примеров использования может потребоваться больше времени, и важно создать пространство для экспериментов.

В качестве еще одного примера, исходный дизайн и реализация для методов указателя и значения не различали наборы методов на T и * T: если бы у вас был * T, вы могли бы вызвать методы значения (получатель T), и если бы у вас был a T, вы можете вызвать методы указателя (получатель * T). Это было просто, без каких-либо ограничений. Но затем фактический опыт показал нам, что разрешение вызова методов указателя на значения приводит к определенному классу сбивающих с толку, неожиданных ошибок. Например, вы можете написать:

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

и io.Copy будет успешным, но в buf ничего не будет. Нам приходилось выбирать между объяснением, почему эта программа работала неправильно, или объяснением, почему эта программа не компилировалась. В любом случае вопросы возникнут, но мы остановились на том, чтобы избежать неправильного исполнения. Тем не менее, нам все равно пришлось написать раздел часто задаваемых вопросов о том, почему в конструкции вырезано отверстие.

Опять же, помните, что ограничения добавляют сложности. Как и всякая сложность, ограничения нуждаются в значительном обосновании. На этом этапе процесса проектирования хорошо подумать об ограничениях, которые могут быть подходящими для конкретного дизайна, но мы, вероятно, должны внедрять эти ограничения только после того, как фактический опыт с неограниченным, более простым дизайном поможет нам понять, принесет ли ограничение достаточную пользу. оплатить его стоимость.

Кроме того, я надеюсь, что мы сможем принять предварительное решение о том, что попробовать, а затем подготовить что-то для экспериментов в начале цикла Go 1.9 (в идеале - в день открытия цикла). Если у вас будет больше времени для экспериментов, это даст много преимуществ, в том числе возможность узнать, является ли конкретное ограничение убедительным. Одна ошибка с псевдонимом заключалась в том, что полная реализация не была завершена почти до конца цикла Go 1.8.

Одна вещь об исходном предложении псевдонима заключается в том, что в предполагаемом варианте использования (включение рефакторинга) фактическое использование типа псевдонима должно быть только временным. В примере с протобуфером заглушка io.BytesBuffer была удалена после завершения постепенного восстановления.

Если механизм псевдонима должен быть виден только временно, действительно ли он требует смены языка? Возможно, вместо этого можно было бы создать механизм для предоставления gc со списком «псевдонимов». gc может временно произвести замены, а автор нижестоящей кодовой базы может постепенно удалять элементы в этом файле по мере объединения исправлений. Я понимаю, что это предложение также имеет непростые последствия, но, по крайней мере, поощряет временный механизм.

Я не буду участвовать в обсуждении синтаксиса (меня в основном не волнует), за одним исключением: если принято решение о добавлении псевдонимов и если было решено ограничить их типами, пожалуйста, используйте синтаксис, который последовательно расширяется как минимум до var , если не func и const (все предложенные синтаксические конструкции допускают все, кроме type Foo = pkg.Bar ). Причина в том, что, хотя я согласен с тем, что случаи, когда псевдонимы для var имеют значение, могут быть редкими, я не думаю, что они не существуют, и поэтому считаю, что в какой-то момент мы могли бы решить добавить их тоже. На этом этапе мы определенно захотим, чтобы все объявления псевдонимов были согласованными, было бы плохо, если бы это были type Foo = pkg.Bar и var Foo => pkg.Bar .

Я также немного поспорил бы за то, чтобы иметь все четыре. Причины

1) существует различие в var и я иногда использую его. Например, я часто выставляю глобальный var Debug *log.Logger или переназначаю глобальные синглтоны, такие как http.DefaultServeMux для перехвата / удаления регистраций пакетов, которые добавляют к нему обработчики.

2) Я также думаю, что, хотя func Foo() { pkg.Bar() } делает то же самое, что и func Foo => pkg.Bar , намерение последнего гораздо яснее (особенно если вы уже знаете о псевдонимах). В нем ясно сказано, что «на самом деле это не должно быть здесь». Таким образом, хотя синтаксис псевдонима технически идентичен, он может служить документацией.

Но это не тот холм, на котором я умру; Одни только псевдонимы типов сейчас меня устраивают, если есть возможность расширить их позже.

Я также очень рад, что это было написано так, как было. Он суммирует кучу мнений, которые у меня были по поводу дизайна и стабильности API в течение некоторого времени, и в будущем он будет служить простым справочником, чтобы связывать людей тоже :)

Тем не менее, я также хочу подчеркнуть, что существуют дополнительные варианты использования, охватываемые псевдонимами, которые отличаются от документа (и AIUI является более общим намерением этой проблемы, которое состоит в том, чтобы найти какое-то решение для решения постепенного восстановления). Я очень рад, если сообщество сможет согласиться с концепцией включения постепенного восстановления, но если для его достижения будет принято другое решение, а не псевдонимы, я бы также подумал, что в этом случае следует одновременно говорить о том, следует ли и как поддерживать такие вещи, как общедоступный импорт protobuf или вариант использования заменяющих пакетов x/image/draw (оба в некоторой степени близки моему сердцу) с другим решением. Предложение @btracey о флаге go-tool / gc для псевдонимов является примером, в котором я считаю, что, хотя он относительно хорошо описывает постепенное восстановление, он на самом деле неприемлем для других вариантов использования. Вы не можете ожидать, что каждый, кто хочет скомпилировать что-то, что использует x/image/draw для передачи этих флагов, просто должен иметь возможность go get .

@jba

@i, и если мы ограничим правую часть идентификатором, квалифицированным для пакета, то это избавит вас от конкретной озабоченности.

Это также означало бы, что у вас не может быть псевдонимов для любых типов в текущем пакете […]. Но такое использование не имеет ничего общего с основной целью постепенного восстановления кода, так что, возможно, это не большая потеря.

Переименование внутри пакета (например, на более идиоматическое или последовательное имя), безусловно, является типом рефакторинга, который можно было бы разумно провести, и если пакет широко используется, это требует постепенного исправления.

Я думаю, что ограничение только именами, указанными в пакете, было бы ошибкой. (Ограничение только экспортированными именами может быть более терпимым.)

@btracey

Возможно, вместо этого можно было бы создать механизм для предоставления gc списка «псевдонимов». gc может временно произвести замены, а автор нижестоящей кодовой базы может постепенно удалять элементы в этом файле по мере объединения исправлений.

Механизм для gc будет либо означать, что код можно построить только с помощью gc во время процесса восстановления, либо что механизм должен поддерживаться другими компиляторами (например, gccgo и llgo ) тоже. Механизм «без смены языка», который должен поддерживаться всеми реализациями, де-факто является изменением языка - это всего лишь один с худшей документацией.

@btracey и @bcmills , а не только компиляторы: любой инструмент, который анализирует исходный код, например guru или что-то еще, созданное людьми. Это, безусловно, изменение языка, как бы вы это ни нарезали.

Хорошо спасибо.

Другая возможность - это псевдонимы для всего, кроме const (и @rsc, простите меня за предложение ограничения!)

Для констант => - это просто более длинный способ написать = . Нет новой семантики, как в случае с типами и варами. Нет сохраненных нажатий клавиш, как с функциями.

По крайней мере, это решило бы # 17784.

Контраргументом было бы то, что инструменты могут рассматривать дела по-разному и что они могут быть индикатором намерений. Это хороший контраргумент, но я не думаю, что он перевешивает тот факт, что это два основных способа сделать одно и то же.

Тем не менее, меня пока устраивают только псевдонимы типов, они, безусловно, самые важные. Я определенно согласен с @Merovius, что мы должны серьезно подумать о том, чтобы сохранить возможность добавления псевдонимов var и func в будущем, даже если этого не произойдет в течение некоторого времени.

Как насчет того, чтобы скрыть псевдонимы за импортом, как для «C» и «небезопасно», чтобы еще больше препятствовать его использованию? В том же духе я хотел бы, чтобы синтаксис псевдонимов был подробным и выделялся в качестве основы для продолжающегося рефакторинга.

В качестве попытки немного расширить пространство дизайна, вот несколько идей. Они не конкретизированы. Они, вероятно, плохие и / или невозможные; надежда в основном состоит в том, чтобы вызвать у других новые / лучшие идеи. И если есть какой-то интерес, мы можем исследовать дальше.

Мотивирующая идея для (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 объявляет новый тип T, который "выглядит как S". Точнее, T - это «преобразование любого типа в тип S и обратно». (Как всегда, синтаксис можно обсудить позже.) Подобно интерфейсным типам, T не может иметь методов; чтобы делать что-либо с T, вам нужно преобразовать его в S (или преобразовать тип в / из S). В отличие от типов интерфейса, здесь нет «конкретного типа», преобразование между S в T и T в S не влечет за собой изменений представления. Для постепенного рефакторинга эти типы «похожего» позволили бы авторам писать API, принимающие как старые, так и новые типы. (Типы «Похоже» - это, по сути, строго ограниченный упрощенный тип объединения.)

1. Теги типа

Бонус супер-отвратительная идея. (Пожалуйста, не говорите мне, что это ужасно - я знаю это. Я только пытаюсь стимулировать новые идеи в других.) Что, если бы мы ввели теги типов (например, структурные теги) и использовали специальные теги типов для настройки и управляйте псевдонимами, например type T S "alias:\"T\"" . Теги типа будут иметь и другое применение, и это дает возможность автору пакета более подробно описывать псевдонимы, чем просто «этот тип является псевдонимом»; например, автор кода может указать поведение встраивания.

Если мы снова попробуем псевдонимы, возможно, стоит подумать о том, «что делает 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 может появиться сообщение «Устарело: используйте X».

Однако, возможно, это не имеет значения для большинства случаев использования. Это то, что может пойти не так, а не то, что может пойти не так. И некоторые из них могут быть обнаружены с помощью линтинга, например, переименованные псевдонимы и случайное копирование предупреждений об устаревании.

Я не уверен, публиковалась ли следующая идея раньше, но как насчет подхода, основанного на инструментах "gofix" / "gorename"? Чтобы уточнить:

• любой пакет может содержать набор правил перезаписи (например, отображение pkg.Ident => otherpkg.Ident )
• эти правила перезаписи могут быть указаны с помощью тегов //+rewrite ... внутри произвольных файлов go
• эти правила перезаписи не ограничиваются изменениями, совместимыми с ABI, также можно делать другие вещи (например, pkg.MyFunc(a) => pkg.MyFunc(context.Contex(), a) )
• инструмент, подобный gofix, можно использовать для применения всех преобразований к текущему репозиторию. Это позволяет пользователям пакета легко обновлять свой код.
• нет необходимости вызывать инструмент gofix для успешной компиляции. Библиотека, которая все еще хочет использовать старый API зависимости X (чтобы оставаться совместимой со старой и новой версиями X), все еще может это делать. Команда go build должна применять преобразования (указанные в тегах перезаписи пакета X) на лету без изменения файлов на диске.

Последние шаги могут немного усложнить / замедлить компилятор, но в основном это всего лишь препроцессор, и количество правил перезаписи в любом случае должно быть небольшим. Итак, хватит мозгового штурма на сегодня :)

Использование псевдонимов для избежания накладных расходов на вызов функций кажется уловкой, позволяющей обойти неспособность компилятора встроить нелистовые функции. Я не думаю, что недостатки реализации должны влиять на спецификацию языка.

@josharian Хотя вы не планировали их как полные предложения, позвольте мне

1. На самом деле это не решает проблему, потому что проблема не в конверсии. x/net/context.Context присваивается / конвертируется / может быть присвоено context.Context . Проблема в типах высшего порядка; а именно типы func (ctx x/net/context.Context) и func (ctx context.Context) не совпадают, даже если аргументы присваиваются. Итак, для решения задачи 1 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 .

Таким образом, вам придется во множестве мест в спецификации заменить или изменить «идентичные типы» на «тот же базовый тип», чтобы сделать эту работу, что кажется громоздким и, вероятно, будет иметь непредвиденные последствия для безопасности типов. ИМХО, у "похожих" типов есть еще больший потенциал злоупотреблений и путаницы, чем у псевдонимов, которые, по-видимому, являются основными аргументами против псевдонимов.

Если кто-то может придумать для этого простое правило, у которого нет этих проблем, его определенно следует рассматривать как альтернативу :)

Следуя идеям @josharian , вот вариант его номера 2:

Разрешить указание «заменяемых типов». Это список типов, которые могут быть заменены именованным типом в аргументах функции, возвращаемых значениях и т. Д. Компилятор разрешит вызов функции с аргументом именованного типа или любой из его замен. Замещающие типы должны иметь определение, совместимое с именованным типом. Совместимость здесь означает идентичные представления в памяти и идентичные объявления после включения в объявление других замещающих типов.

Одна непосредственная проблема заключается в том, что направленность этой связи противоположна предложению псевдонима, которое инвертирует граф зависимостей. Одно это может сделать его неработоспособным, но я предлагаю его здесь, потому что другие могут придумать способ обойти это. Одним из способов может быть объявление замен как комментариев // go, а не через граф импорта. Таким образом они, возможно, станут больше похожи на макросы.

И наоборот, у этого изменения направленности есть некоторые преимущества:

• набор заменяемых типов контролируется автором нового пакета, который может лучше гарантировать семантику
• в исходном пакете не требуется изменений кода, поэтому клиентам не нужно обновлять, пока они не начнут использовать новый пакет

Применение этого к рефакторингу контекста: пакет контекста стандартной библиотеки объявляет, что context.Context может быть заменено на golang.org/x/net/context.Context . Это означает, что любое использование, которое принимает контекст. Контекст также может принимать вместо него golang.org/x/net/context.Context . Однако функции в пакете контекста, возвращающие Context, всегда будут возвращать context.Context .

Это предложение позволяет обойти проблему внедрения (# 17746), поскольку имя встроенного типа никогда не меняется. Однако встроенный тип можно инициализировать, используя значение замещающего типа.

@iand @josharian вы запрашиваете определенный вариант ковариантных типов.

@josharian , спасибо за предложения.

Re 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 и interface {} не имеют одинакового представления памяти. Интерфейс {} - это [2] unsafe.Pointer, а не [2] uintptr. Uintptr и указатель - это разные представления. Но я думаю, что ваша общая точка зрения верна, что мы не хотим обязательно допускать прямое преобразование такого рода вещей. Я имею в виду, вы тоже можете преобразовать из интерфейса {} в [2] * байт? Здесь намного больше, чем нужно.

@jimmyfrasche и @nigeltao , re godoc: Я согласен с тем, что нам тоже нужно это пораньше. Я согласен с тем, что мы не должны жестко закодировать предположение, что «новая функция - какой бы она ни была - будет использоваться только для рефакторинга кодовой базы». У него могут быть другие важные применения, как, например, Найджел, который нашел для помощи в написании пакета расширения отрисовки с псевдонимами. Я ожидаю, что устаревшие вещи будут явно отмечены как устаревшие в их комментариях к документам, как сказал Джимми. Я действительно думал об автоматической генерации комментария к документу, если его нет, но нет ничего очевидного, чтобы сказать, что уже не должно быть ясно из синтаксиса (говоря в целом). В качестве конкретного примера рассмотрим старые псевдонимы Go 1.8. Данный

type ByteBuffer => bytes.Buffer

мы могли бы синтезировать комментарий документа, в котором говорится, что «ByteBuffer - это псевдоним для bytes.Buffer», но это кажется излишним при отображении определения. Если сегодня кто-то напишет «type X struct {}», мы не синтезируем «X - именованный тип для struct {}».

@iand , спасибо. Похоже, ваше предложение требует, чтобы автор нового пакета написал точное определение из старого пакета, а затем также объявление, связывающее два, например (составляя синтаксис):

package old
type T { x int }

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

Я согласен с тем, что реверсирование импорта проблематично и само по себе может стать препятствием, но давайте пропустим это. На данный момент кодовая база кажется хрупкой: теперь новый пакет может быть нарушен путем добавления поля структуры в старый пакет. Учитывая заменяемую строку, есть только одно возможное определение для T1: точно такое же, как и old.T. Если два типа по-прежнему имеют разные определения, вам также нужно беспокоиться о методах: должны ли реализации методов также совпадать? Если нет, что произойдет, если вы поместите T в интерфейс {}, а затем вытащите его, используя утверждение типа как T1, и вызовите M ()? Вы получаете T1.M? Что, если вы извлечете его как интерфейс {M ()}, не называя напрямую T1, и вызовете M ()? Вы получаете ТМ? Много сложностей вызвано неоднозначностью наличия обоих определений в дереве исходных текстов.

Конечно, можно сказать, что заменяемая строка делает остальное избыточным и не требует определения типа T1 или каких-либо методов. Но тогда это в основном то же самое, что писать (в старом синтаксисе псевдонима) type T1 => old.T .

Возвращаясь к проблеме с графиком импорта, хотя все примеры в статье сделали старый код определенным в терминах нового кода, если граф пакета был таков, что новый должен был импортировать старый вместо этого, одинаково эффективно поместить перенаправление в новый пакет во время перехода.

Я думаю, это показывает, что в любом подобном переходе, вероятно, нет полезного различия между автором нового пакета и автором старого пакета. В конце концов, цель состоит в том, чтобы код был добавлен в новый и удален из старого, поэтому в этом случае должны быть задействованы оба автора (если они разные). И этим двум также нужна какая-то скоординированная совместимость в середине, будь то явная (своего рода перенаправление) или неявная (определения типов должны точно совпадать, как в требовании заменяемости).

@rsc этот сценарий поломки предполагает, что псевдонимы любого типа должны быть двунаправленными. Даже в соответствии с предыдущим предложением псевдонима любое изменение в новом пакете потенциально может привести к поломке любого количества пакетов, которые имеют псевдоним типа.

@iand Если есть только одно определение (потому что другое говорит «то же самое, что и _that_ one»), то не стоит беспокоиться о том, что они не синхронизированы.

В # 13467 @joegrasse указывает, что было бы неплохо, если бы это предложение предоставило механизм, позволяющий одинаковым типам C становиться идентичными типами Go при использовании cgo в нескольких пакетах. Это совсем не та проблема, для которой предназначена эта проблема, но обе проблемы связаны с псевдонимом типов.

Есть ли краткое изложение предложенных / принятых / отклоненных ограничений / ограничений на псевдонимы? На ум приходят следующие вопросы:

• Всегда ли RHS полностью квалифицирован?
• Если псевдонимы для псевдонимов разрешены, как мы обрабатываем циклы псевдонимов?
• Должны ли псевдонимы иметь возможность экспортировать неэкспортированные идентификаторы?
• Что происходит, когда вы вставляете псевдоним? (как получить доступ к встроенному полю)
• Доступны ли псевдонимы в виде символов во встроенной программе?
• Внедрение строки ldflags: что, если мы обратимся к псевдониму?

@rsc Я не хочу слишком отвлекать разговор, но в предложении псевдонима, если «новый» удаляет поле, на которое «старый» полагался, это означает, что клиенты «старого» теперь не могут компилироваться.

Однако в рамках предложения о замене, я думаю, можно было бы договориться, что только клиенты, которые используют и старые, и новые вместе, сломаются. Для того, чтобы это было возможно, директива замены должна проверяться только тогда, когда компилятор обнаруживает использование «старых» типов в «новом» пакете.

@thwd Я не думаю, что есть хорошая рецензия. Мои заметки:

• Циклы псевдонимов не являются проблемой. В случае псевдонимов, пересекающих пакеты, цикл уже запрещен из-за цикла импорта. В случае псевдонимов без пересечения пакетов их, очевидно, нужно запретить, что очень похоже на циклы в порядке инициализации. Лично я хотел бы иметь псевдонимы для псевдонимов, потому что я не думаю, что они должны быть ограничены вариантами использования постепенного восстановления (см. Мой комментарий выше), и было бы грустно, если бы пакет A мог сломаться из-за того, что кто-то переместил тип в пакет B с псевдонимом (представьте, что x/image/draw.Image псевдоним draw.Image а затем кто-то решает переместить draw.Image в image.Draw через псевдоним, считая его безопасным. Внезапно x/image/draw ломается, потому что псевдонимы для псевдонимов недопустимы).
• Я думаю, что ранее сторонники псевдонимов соглашались с тем, что экспорт псевдонимов неэкспортированных идентификаторов, вероятно, является плохой идеей из-за странностей, которые это может вызвать. Фактически это означает, что псевдонимы для неэкспортированных идентификаторов бесполезны и могут быть полностью запрещены.
• Вопрос о внедрении, AFAIK, пока не решен. В # 17746 есть целое обсуждение, я ожидаю, что это обсуждение будет продолжено, если / когда / до того, как будет решено продолжить работу с псевдонимами (но все еще есть возможность альтернативного решения или решения не делать постепенный ремонт целью вообще)

@iand , re "

Есть еще кое-что, о чем я еще не упоминал в другом месте:

Поскольку явной целью здесь является обеспечение масштабного постепенного рефакторинга в больших децентрализованных базах кода, могут возникать ситуации, когда владелец библиотеки захочет выполнить некоторую очистку, которая потребует неизвестного количества клиентов для изменения своего кода (в конечном итоге " удалите старый "шаг API"). Обычный способ сделать это - добавить предупреждение об устаревании, но компилятор Go не имеет никаких предупреждений.

Без предупреждения компилятора, как владелец библиотеки может быть уверен в безопасности выполнения рефакторинга?

Одним из ответов может быть какая-то схема управления версиями - это новый выпуск библиотеки с новым несовместимым API. В этом случае, возможно, весь ответ - это управление версиями, а не псевдонимы типов.

В качестве альтернативы, как насчет того, чтобы разрешить автору библиотеки добавить «предупреждение об устаревании», которое фактически вызывает ошибку компиляции для клиентов, но с явным алгоритмом рефакторинга, который им необходимо выполнить? Я представляю себе что-то вроде:

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 , сводится к требованию взаимозаменяемости двух типов (поскольку существуют обходные пути для переменных переменных, функций и констант).

Для этого нужен инструмент или изменение языка.

Поскольку создание взаимозаменяемых двух типов по определению меняет способ работы языка, любой инструмент мог бы быть механизмом для имитации эквивалентности вне компилятора, вероятно, путем перезаписи всех экземпляров старого типа на новый тип. Но это означает, что такой инструмент должен будет переписать код, которым вы не владеете, например, поставляемый пакет, который использует golang.org/x/net/context вместо пакета контекста stdlib. Спецификация изменения должна быть либо в отдельном файле манифеста, либо в машиночитаемом комментарии. Если вы не запустите инструмент, вы получите ошибки сборки. Со всем этим становится сложно иметь дело. Кажется, что инструмент может создать столько же проблем, сколько и решить. Это все равно будет проблемой, с которой придется иметь дело каждому, кто использует эти пакеты, хотя и несколько приятнее, поскольку часть автоматизирована.

Если язык изменен, код должны быть изменены только его сопровождающими, и для большинства людей все просто работает. Инструменты, помогающие сопровождающим, по-прежнему возможны, но это было бы намного проще, поскольку источником является спецификация, и только сопровождающим пакета нужно будет вызывать его.

Как отметил @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

Например, вот пример скелета, обращающегося к случаю io.ByteBuffer , с временным ключевым словом "adapts" на данный момент:

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.Error

Та же самая логика, вероятно, будет работать и с интерфейсом, хотя ее реализация компилятором немного сложнее. Вот пример для 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. Семантика ссылок на типы зависит от поддерживаемого варианта использования рефакторинга.

Предложение Густаво показывает, что необходимо больше поработать над вариантом использования для ссылок на типы и полученной семантикой.

Новое предложение Росс включает новый синтаксис type OldAPI = newpkg.newAPI . Но какова семантика? Невозможно расширить OldAPI с помощью устаревших общедоступных методов или полей? Предположим, что да, как ответ, который требует, чтобы newAPI поддерживал все общедоступные методы и поля OldAPI для обеспечения совместимости. Обратите внимание, что любой код в пакете с OldAPI, который полагается на закрытые поля и методы, должен быть переписан, чтобы использовать только общедоступный newAPI, предполагая, что изменение ограничений видимости пакетов вне таблицы.

Альтернативный путь - разрешить определение дополнительных методов для OldAPI. Это могло бы облегчить бремя NewAPI по предоставлению всех общедоступных старых методов. Но это сделало бы OldAPI другим типом, чем NewAPI. Некоторая форма присваивания между значениями двух типов должна быть сохранена, но правила могут стать сложными. Разрешение добавления полей приведет к большей сложности.

2. Пакет с NewAPI не может импортировать пакет с OldAPI.

Для переопределения OldAPI требуется, чтобы пакет O, содержащий определение OldAPI, импортировал пакет N с NewAPI. Это означает, что пакет N не может импортировать O. Возможно, это настолько очевидно, что об этом не упоминалось, но мне кажется, что это важное ограничение для варианта использования рефакторинга.

Обновление: пакет N не может зависеть от пакета O. Например, он не может импортировать пакет, который импортирует O.

@niemeyer Изменения, такие как переименование метода, уже постепенно возможны: а) добавить новый метод, вызвать старый под капотом (или наоборот), б) постепенно изменить всех пользователей на новый метод, в) удалить старый метод. Вы можете комбинировать это с псевдонимом типа. Причина, по которой это сосредоточено на перемещении шрифтов, заключается в том, что это единственное, что идентифицировано, что еще невозможно. Все другие идентифицированные изменения возможны, даже если они могут включать несколько шагов (например, изменение набора аргументов метода без его переименования). Я считаю, что предпочтительнее выбирать исправление с меньшей площадью поверхности (меньше вещей для понимания).

@rakyll Лично, если бы я считал псевдонимы полезными для чего-то нерефакторингового (например, пакетов-оберток, которые я считаю отличным вариантом использования), я бы просто использовал их, к черту предупреждения об устаревании. Я был бы зол на тех, кто искусственно искалечил их и сбил с толку моих пользователей, но я бы не отчаивался.

Я думаю, что в какой-то момент необходимо обсудить, действительно ли мы считаем пакеты-оболочки, общедоступный импорт protobuf или раскрытие внутренних API-интерфейсов пакетов такой плохой вещью (и я не знаю, как лучше всего обсудить что-то такое субъективное, если одна сторона просто не повторяет снова и снова, что они нечитабельны, а другие говорят: «Нет, это не так». Мне кажется, здесь не так много объективных аргументов).

Я по крайней мере (очевидно) считаю, что это хорошо, и я также считаю, что добавление языковой функции и искусственное ограничение ее только одним вариантом использования - это плохо; Ортогональный, хорошо разработанный язык позволяет вам делать как можно больше с минимальным количеством функций. Вы хотите, чтобы ваши функции максимально расширяли «охватываемое векторное пространство возможных программ», поэтому добавление функции, которая добавляет к пространству только одну точку, кажется мне странным.

Я бы хотел иметь в виду еще один, немного другой вариант использования, когда разрабатывается любое предложение псевдонима типа.

Хотя основным вариантом использования, который мы обсуждаем в этом выпуске, является тип _replacement_, псевдонимы типов также были бы очень полезны для отделения тела кода от зависимости от типа.

Например, предположим, что тип оказался «нестабильным» (т.е. он продолжает изменяться, возможно, несовместимым образом). Затем некоторые пользователи могут захотеть перейти на «стабильную» замену. Я думаю о разработке на github и т. Д., Где владельцы типа и его пользователи не обязательно работают в тесном сотрудничестве или соглашаются с целью обеспечения стабильности.

Другими примерами могут быть случаи, когда один тип - единственное, что предотвращает удаление зависимости от большого или проблемного пакета, например, когда была обнаружена несовместимость лицензий.

Итак, процесс здесь будет следующим:

1. Определите псевдоним типа
2. Измените соответствующий текст кода, чтобы использовать псевдоним типа
3. Замените псевдоним типа определением типа.

В конце этого процесса появятся два независимых типа, которые смогут свободно развиваться в своих собственных направлениях.

Обратите внимание, что в этом случае использования:

• нет возможности изменить пакет, содержащий определение исходного типа, чтобы добавить туда псевдоним типа (поскольку владельцы вряд ли согласятся с этим)
• исходный тип не является устаревшим (хотя он может рассматриваться как таковой в теле кода в процессе «отлучения» от типа).

@Merovius В тот момент, когда вы удаляете или переименовываете старый метод, вы сразу убиваете всех клиентов, которые его использовали. Если вы готовы это сделать, то все нетривиальное упражнение по добавлению языковой функции для предотвращения одновременной поломки будет спорным. С таким же успехом мы могли бы сказать то же самое о перемещении кода: просто переименуйте тип сразу на каждом сайте вызова. Выполнено. Оба действия представляют собой простое атомарное переименование, которое объединяет тот факт, что они предполагают полный доступ к каждой строке кода на сайтах вызовов. Это может быть так и в случае с Google, но как специалист по сопровождению больших приложений и библиотек с открытым исходным кодом, это не тот мир, в котором я живу.

В большинстве случаев я нахожу эту критику несправедливой, поскольку команда Go делает все возможное, чтобы сделать проект доступным для внешних сторон, но в тот момент, когда вы предполагаете, что у вас есть доступ к каждой отдельной строке кода, вызывающей данный пакет, это ограничивается стеной. сад, который не соответствует контексту сообщества открытого исходного кода. Добавление функции рефакторинга на уровне языка, которая работает только внутри огороженных садов, было бы, мягко говоря, нетипично.

@niemeyer Я, видимо, не ясно

1. Добавить новый API, взаимозаменяемый со старым API
2. Постепенно переводите потребителей на новый API
   3а. Как только все будет перенесено или истечет период устаревания, удалите старый API.
   3b. Обеспечьте неопределенную стабильность, навсегда сохранив оба API (см., Например, эту часть статьи )

Кажется, вы спорите о выборе 3а против 3b. Но на что я указывал, что 1. уже возможно для имен методов, но невозможно для типов, о чем идет речь.

Хотя теперь я понимаю, что, по-моему, неправильно вас понял :) Возможно, вы уже указывали, что os.Error - это разные определения интерфейса, поэтому этот шаг на самом деле не срабатывает. Я думаю, это правда; если вы запретите удаление API, псевдонимы типов не позволят переименовывать методы типов интерфейсов.

Может быть, вы можете кое-что прояснить для меня в отношении идеи вашего адаптера: разве это не позволит использовать (например, в случае os.Error) любой fmt.Stringer в качестве os.Error?

В любом случае идея адаптера кажется заслуживающей дальнейшего развития, даже если я к ней немного скептически отношусь. Но хорошая цель - иметь способ постепенного рефакторинга интерфейсов без нарушения работы возможных разработчиков и / или потребителей.

@niemeyer Да, вы

Я согласен с тем, что было бы замечательно, если бы было какое-то общее исправление, которое обрабатывало бы оба типа изменений. Я не понимаю, что это за исправление. В частности, я не понимаю, как переключатели типов работают с описанными вами адаптерами: значение каким-то образом автоматически преобразуется во время переключения типа? А как насчет отражения? Наличие только одного типа с двумя именами позволяет избежать многих проблем, возникающих при наличии двух типов, которые автоматически преобразуются туда и обратно.

@rsc Да, адаптер будет последовательно автоматически преобразовывать в каждой ситуации, поэтому переключатели типов не будут исключением. Мы бы запретили переключатели типов, содержащие как адаптер, так и его базовый тип, поскольку это было бы неоднозначно. Возможно, я что-то упускаю, но пока не вижу проблемы с отражением, поскольку каждый контекст кода обязательно должен явно использовать либо адаптированный тип, либо его базовый тип. Как и сегодня, мы не можем войти в interface{} не зная, как мы туда попали, если это имеет смысл.

@Merovius Мои два комментария выше касаются именно того, о чем вы все еще говорите. Если вы переместите шрифт сегодня, вы нарушите код, который нужно исправить. Если вы переименуете метод, вы нарушите код, который нужно исправить. Если вы удалите метод, измените его аргументы, вы нарушите код, который нужно исправить. При рефакторинге кода в любом из этих случаев исправления должны выполняться атомарно с поломкой на каждом сайте вызова, чтобы все продолжало работать. Разрешение перемещать тип, но полностью нетронутым - это очень ограниченный случай рефакторинга, который IMO не оправдывает языковой функции.

@niemeyer Это будет обрабатывать конкретные типы. А как насчет утверждения типа для .(interface{String() string}) vs .(interface{Error() string}) или любых других измененных частей интерфейса? Должна ли проверка как-то учитывать оба возможных базовых типа?

@niemeyer Нет. Переименование метода возможно неатомарно. например, чтобы переместить метод из A.Foo в A.Bar , выполните

1. Добавить метод A.Bar в качестве оболочки вокруг A.Foo
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 / image / draw) также зависит от способности ссылаться на старую вещь по новому имени и наоборот.

Разница между перемещением типов сегодня и переименованием функции сегодня заключается в том, что в первом случае вам действительно нужно атомарное изменение, тогда как во втором вы можете вносить изменения постепенно, через независимые репозитории и коммиты. Не как «Я сделаю коммит, который делает s / Foo / Bar /», но есть процесс, чтобы это сделать.

В любом случае. Я не знаю, где мы, видимо, говорим мимо друг друга. Я нахожу документ @rsc довольно ясным, чтобы передать мою

@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 Я не согласен с тем, что интерфейсы (даже ковариантные) - хорошее решение любой из этих проблем (только для очень конкретных случаев). Чтобы сделать их одним, вам нужно сделать все в вашем API интерфейсом (потому что вы никогда не знаете, что вы можете захотеть переместить / изменить в какой-то момент), включая vars / consts / funcs /… и я не думаю, что все, что это хороший дизайн (я видел это в java. Меня это раздражает). Если что-то является структурой, просто сделайте это структурой. Все остальное просто добавляет странные синтаксические издержки в ваш пакет и каждую обратную зависимость практически без пользы. Это также единственный способ оставаться в здравом уме, когда вы начинаете; начните с простого, а позже переходите к чему-то более общему. Множество сложностей в API, которые я видел до сих пор, исходит от людей, чрезмерно задумывающихся о дизайне API и планирующих сделать его более универсальным, чем когда-либо понадобится. А потом, в 80% (это очевидная ложь) случаев вообще ничего не происходит, потому что нет «чистого дизайна API».

(для ясности: я не говорю, что ковариантные интерфейсы - плохая идея. Я просто говорю, что они не являются хорошим решением этих проблем)

Чтобы добавить к мнению @Merovius , многие постепенные

package foo

type Authority struct {
  Host string
  Port int
}

Со временем пакет foo разрастается, и в конечном итоге он получает больше ответственности (и размер кода), чем действительно хочет тот, кому просто нужен тип Authority . Таким образом, желательным вариантом использования является способ создания пакета fooauthority , который просто содержит Authority а существующие пользователи foo.Authority все еще работают. Обратите внимание, что любое решение, учитывающее только типы интерфейсов, здесь не поможет.

@Merovius Ваш последний комментарий был полностью субъективным и адресован мне лично, а не моему предложению. Это плохо закончится, поэтому я остановлю эту линию обсуждения здесь.

@griesemer @Merovius Я согласен с вами обоими. Итак, чтобы замкнуть цикл, мы можем согласиться с тем, что обсуждение до сих пор привело нас к некоторому понятию подтипов / ковариации. Кроме того, любая его реализация не должна повлечь за собой косвенное обращение во время выполнения. Это вроде того, что предлагал @niemeyer (если я правильно его понял). Но я бы хотел прочитать больше идей. Я тоже подумаю о проблеме.

@niemeyer Существовал ничего _AD hominem_ в комментариях @Merovius «s. Его заявление о том, что «ваша позиция по поводу стабильности абсолютна», является наблюдением о вашей позиции, а не о вас, и является разумным выводом из некоторых ваших утверждений, например

В тот момент, когда вы удаляете или переименовываете старый метод, вы сразу убиваете всех клиентов, которые его использовали.

а также

Конечно, переименование метода возможно, если вы на самом деле не переименовываете его и не заставляете сайты вызовов использовать вместо этого новый API. Точно так же перемещение типа возможно до тех пор, пока вы фактически не перемещаете его, а вместо этого заставляете сайты вызовов использовать новый API. Мы все годами делаем и то, и другое, чтобы старый код работал.

Из этих заявлений у меня сложилось такое же впечатление, что и у Меровиуса - что вы не сочувствуете, если какое-то время осуждаете что-то, а затем, в конце концов, удаляете это; что вы стремитесь к тому, чтобы код работал бесконечно; что «ваша позиция по поводу стабильности абсолютна». (И чтобы предотвратить дальнейшее недопонимание, я использую слово «вы» для обозначения ваших идей, а не вашей личности.)

@niemeyer Предлагаемое adapts кажется тесно связанным с instance из классов типов Haskell. Примерно переводя это на Go, это может выглядеть примерно так:

package os

type Error interface {
  String() string
}

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

К сожалению (как отмечает @zombiezen ), неясно, как это поможет для

Мне также не очевидно, как он будет взаимодействовать с типами функций (аргументами и возвращаемыми значениями); например, как семантика adapts поможет при переносе Context в стандартную библиотеку?

Из этих заявлений у меня сложилось такое же впечатление, что и у Меровиуса - что вы некоторое время не сочувствуете осуждению чего-либо.

@jba Это абсолютные факты, а не абсолютные мнения. Если вы удаляете метод или тип, код Go, использующий его, ломается, поэтому эти изменения нужно вносить атомарно. Мое предложение, тем не менее, касается постепенного рефакторинга кода, который является предметом здесь и подразумевает устаревание. Однако этот процесс осуждения - не вопрос сочувствия. У меня есть несколько общедоступных пакетов Go с тысячами реальных зависимостей каждый и несколько независимых API-интерфейсов из-за этой постепенной эволюции. Когда мы ломаем API, лучше делать такие поломки партиями, а не передавать их в потоковом режиме, если мы не надеемся, что люди не сойдут с ума. Если, конечно, вы не живете в обнесенном стеной саду и не можете связаться с каждым местом звонка, чтобы исправить это. Но я повторяюсь ... все это можно более четко прочесть в исходном предложении выше.

@Merovius

Лично, если бы я считал псевдонимы полезными для чего-то нерефакторингового (например, пакетов-оберток, которые я считаю отличным вариантом использования), я бы просто использовал их, к черту предупреждения об устаревании.

Мы поддерживаем пакеты с чрезвычайно большим количеством новых и устаревших API, и наличие псевдонимов без четкого объяснения состояния старого (с псевдонимом) типа не поможет постепенному восстановлению кода, а только будет способствовать подавляющему количеству увеличенной поверхности API. Я согласен с @niemeyer, что наше решение должно

Я хотел бы обсудить псевдонимы типов в другой теме, например, о расширении типа или частичных пакетов, но не в этой теме. Сама по себе эта тема имеет различные проблемы, связанные с инкапсуляцией, которые необходимо решить перед любым рассмотрением.

Определенный оператор или подразумевающий, что введенный псевдонимом несколько заменен, может быть полезным, чтобы сообщить пользователям, что им нужно переключиться. Такая дифференцируемость позволит инструментам автоматически сообщать о замененных API.

Чтобы было ясно, политика устаревания технически невозможна для типов, не входящих в стандартную библиотеку. Тип является старым только с точки зрения пакета псевдонимов. Учитывая, что мы никогда не сможем обеспечить это в экосистеме, я все же хотел бы, чтобы псевдонимы стандартных библиотек строго подразумевали устаревание (на что указывают соответствующие уведомления об устаревании).

Я также предлагаю стандартизировать понятие устаревания в параллельном обсуждении и обеспечить их поддержку в наших основных инструментах (golint, godoc и т. Д.). Отсутствие уведомлений об устаревании - самая большая проблема в экосистеме Go и более распространенная, чем проблема постепенного восстановления кода.

@rakyll Мне симпатичен вариант использования компьютерно-читаемых уведомлений об устаревании; Я просто возражаю против того, чтобы а) псевдонимы были таковыми и б) выдавали их как предупреждения компилятора.

Для а), помимо того факта, что я хотел бы продуктивно использовать псевдонимы для других вещей, кроме ходов, это также применимо только для очень небольшого набора устаревших рекомендаций. Например, скажем, я хочу удалить некоторые параметры из функции в нескольких выпусках; На самом деле я не могу использовать псевдонимы, потому что сигнатура нового API будет отличаться, но я все равно хочу это объявить. Для б) предупреждения компилятора IMHO повсеместно плохие. Я думаю, что это в основном соответствует тому, что Go уже делает, поэтому не думаю, что это требует оправдания.

Я согласен со всем, что вы говорите об уведомлениях об отказе от поддержки. По-видимому, для этого уже есть синтаксис: # 10909, поэтому следующим шагом, чтобы сделать его более полезным, было бы улучшить поддержку инструментов, выделив их в godoc и получив проверку, предупреждающую об их использовании (скажем, go vet, golint или отдельный инструмент вообще).

@rakyll Я согласен с тем, что stdlib следует начинать с консервативного использования псевдонимов типов, если они будут введены.

Боковая панель:

Справочная информация для тех, кто не знает о статусе комментариев об устаревании в Go и связанных инструментах, поскольку они довольно распространены:

Как упоминает @Merovius выше, существует стандартное соглашение для маркировки элементов как устаревших, # 10909, см. Https://blog.golang.org/godoc-documenting-go-code

TL; DR: сделайте абзац в документации устаревшего элемента, который начинается с «Устарело:» и объясняет, что такое замена.

Для godoc принято предложение о более удобном отображении устаревших элементов: # 17056.

@rakyll предложил, чтобы golint предупреждал об использовании устаревших элементов: golang / lint # 238.

Даже если stdlib занимает консервативную позицию в отношении использования псевдонимов в stdlib, я не думаю, что существование псевдонима типа должно подразумевать (любым способом, который определяется механически или визуально), что старый тип устарел, даже если это всегда означает, что на практике.

Это будет означать одно из:

• сканирование других пакетов stdlib, чтобы увидеть, есть ли псевдоним какого-либо типа, явно не отмеченного как устаревший, в другом месте
• жесткое кодирование всех псевдонимов stdlib в автоматизированные инструменты
• сообщение только о том, что старый тип устарел, когда вы уже рассматриваете его замену, что не помогает обнаружению

Когда псевдоним типа вводится из-за того, что старый тип объявлен устаревшим, его необходимо обрабатывать, помечая старый тип как устаревший со ссылкой на новый тип, независимо от того.

Это позволяет использовать лучший инструментарий, делая его более простым и универсальным: ему не нужно ничего делать в особом регистре или даже знать о псевдонимах типов: ему просто нужно сопоставить «Устаревший:» в комментариях к документу.

Официальная, если возможно временная, политика, согласно которой псевдоним в stdlib предназначен только для устаревания, хороша, но ее следует применять только со стандартными комментариями об устаревании и путем запрета других применений, чтобы избежать проверки кода.

@niemeyer Мой предыдущий ответ был потерян из-за потери питания :( Не в порядке:

Но я повторяюсь ..

FWIW, я нашел ваш последний ответ очень полезным. Это убедило меня в том, что мы больше согласны, чем казалось ранее (и чем вам может показаться). Хотя, похоже, что-то все еще есть недопонимание.

Мое предложение, тем не менее, касается постепенного рефакторинга кода.

Думаю, здесь нет споров. :) Я с самого начала согласился, что ваше предложение - интересная альтернатива для рассмотрения для решения проблемы. Меня смущают такие утверждения:

Если вы удаляете метод или тип, код Go, использующий его, ломается, поэтому эти изменения нужно вносить атомарно.

Мне все еще интересно, что вы здесь рассуждаете. Я понимаю, что единицей атомарности является единичный коммит. Исходя из этого предположения, я просто не понимаю, почему вы убеждены, что удаление метода или типа не может сначала произойти отдельными произвольно многочисленными коммитами в зависимых репозиториях, а затем, как только очевидного пользователя больше нет (и достаточное устаревание интервал пройден) метод или тип удаляется в восходящем коммите (ничего не нарушая, так как никто больше не зависит). Я согласен с тем, что существует определенный фактор нечеткости в отношении обратных зависимостей, которые не соответствуют устаревшим или которые вы не можете найти (или разумно исправить), но это, как мне кажется, в значительной степени не зависит от рассматриваемого вопроса; у вас будет эта проблема всякий раз, когда вы применяете критическое изменение, и как бы вы ни пытались его организовать.

И, честно говоря: путанице на самом деле не помогают такие предложения, как

Если, конечно, вы не живете в обнесенном стеной саду и не можете связаться с каждым местом звонка, чтобы исправить это.

Если что-то из того, что я сказал, создало у вас впечатление, что это та точка, из которой я спорю, я надеюсь, что вы сможете сделать шаг назад и, возможно, перечитать это, исходя из предположения, что я полностью аргументирую с позиции открытого исходного кода. сообщество (если вы мне не верите, не стесняйтесь искать мои предыдущие статьи по этой теме; я всегда первый, кто указывает, что это скорее проблема сообщества, чем проблема монорепозитория. У монорепозиториев есть способы обойти это , как вы указали).

В любом случае. Я нахожу это таким же утомительным, как и вы. Я надеюсь, что когда-нибудь пойму вашу позицию.

одновременно поговорим о том, можно ли и как поддерживать такие вещи, как публичный импорт protobuf ...
Я думаю, что в какой-то момент необходимо обсудить, действительно ли мы рассматриваем пакеты-оболочки, публичный импорт protobuf или раскрытие внутренних API-интерфейсов пакетов такой плохой вещью.

nit: Я не думаю, что публичный импорт protobuf следует упоминать как особый вторичный вариант использования. Они были разработаны для постепенного восстановления кода, как явно указано как во внутренней документации по дизайну, так и даже в общедоступной документации , поэтому они уже подпадают под действие проблем, описанных в этом выпуске. Кроме того, я считаю, что псевдонимов типов было бы достаточно для реализации общедоступного импорта protobuf. (Протокомпилятор генерирует переменные, но они логически являются константными, поэтому "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.
    }
 }

Одна из текущих аксиом пакета отражений состоит в том, что если два типа одинаковы, их значения отражают.тип равны. Это одна из основ эффективности преобразования типов среды выполнения Go. Насколько я понимаю, невозможно реализовать ключевое слово «adapts», не нарушая его.

@rogpeppe См. беседу с @rsc об отражении выше. Эти два типа не одно и то же, поэтому «Рефлекс» просто скажет правду и предоставит подробную информацию об адаптере, когда его спросят об этом.

@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)

но, поскольку он утверждает тип против * image.RGBA, а не * newimage.RGBA,
он потерпит неудачу AFAICS, потому что типы разные.

Скажем, мы успешно завершили приведенный выше тип assert, независимо от того, является ли тип * image.RGBA
или не. Это нарушит текущий инвариант, который:

отражать.Типеоф (х) == отражать.Типеоф (х. (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.

Мне это все еще кажется противоречивым. Текущая модель очень проста: значение интерфейса имеет четко определенный базовый статический тип. В приведенном выше коде мы что-то делаем об этом базовом типе, но когда мы заглядываем в значение, оно не похоже на то, что мы сделали. На мой взгляд, это серьезное (и трудно объяснимое) изменение языка.

Обсуждение здесь, кажется, подходит к концу. Основываясь на предложении @egonelbre в https://github.com/golang/go/issues/16339#issuecomment -247536289, я обновил исходный комментарий к проблеме (вверху), чтобы включить связанное резюме обсуждения, чтобы далеко. Я буду публиковать новый комментарий, подобный этому, каждый раз, когда обновляю сводку.

В целом, похоже, что здесь больше внимания уделяется псевдонимам типов, чем обобщенным псевдонимам. Возможно, идея адаптера Густаво заменит псевдонимы типов, но, возможно, нет. На данный момент это кажется немного сложным, хотя, возможно, к концу обсуждения будет достигнута более простая форма. Предлагаю продолжить обсуждение еще немного.

Я до сих пор не уверен, что изменяемые глобальные переменные являются «обычно ошибкой» (и в тех случаях, когда они являются ошибкой, детектор гонки является лучшим инструментом для поиска такого рода ошибок). Я бы попросил, чтобы, если этот аргумент используется для оправдания отсутствия расширяемого синтаксиса, реализована ветеринарная проверка, которая, скажем, проверяет присвоения глобальным переменным в коде, не доступном исключительно для init () или их объявлений. Я наивно думал, что это не особенно сложно реализовать, и не должно быть много работы, чтобы запустить это, скажем, все зарегистрированные на godoc.org пакеты, чтобы узнать, каковы варианты использования изменяемых глобальных переменных и делаем ли мы считайте все их ошибками.

(Я также хотел бы верить, что если go вырастет неизменяемыми глобальными переменными, они должны быть частью объявлений const, потому что это то, что они концептуально и потому что это будет обратно совместимо, но я признаю, что это, вероятно, приведет к сложности, связанные с тем, какие выражения могут использоваться, например, в типах массивов и потребуют дополнительных размышлений)

Re «Ограничение? Псевдонимы стандартных библиотечных типов могут быть объявлены только в стандартной библиотеке». - в частности, это предотвратит случайное использование x/image/draw , существующего пакета, который проявил интерес к использованию псевдонимов. Я мог бы также очень хорошо представить себе, например, пакеты маршрутизатора или тому подобное, использующие псевдонимы в net/http аналогичным образом ( машет руками ).

Я также согласен с контраргументами относительно всех ограничений, т.е. я за то, чтобы их не вводить.

@Merovius , а как насчет изменяемых _exported_ глобальных варов? Верно, что неэкспортированный глобал может быть прекрасен, поскольку весь код в пакете знает, как правильно с ним обращаться. Менее очевидно, что экспортированные изменяемые глобальные объекты когда-либо имеют смысл. Мы сами неоднократно допускали эту ошибку в стандартной библиотеке. Например, не существует полностью безопасного способа обновления runtime.MemProfileRate. Лучшее, что вы можете сделать, это установить его в начале своей программы и надеяться, что ни один импортированный вами пакет не запустил горутину инициализации, которая могла бы выделять память. Возможно, вы правы насчет var vs const, но мы можем оставить это на другой день.

Хорошее замечание о x / image / draw. Добавлю в сводку при следующем обновлении.

Я очень хотел бы собрать репрезентативный корпус кода Go, который мы могли бы проанализировать, чтобы ответить на вопросы, подобные тем, которые вы задаете. Я начал пытаться это сделать несколько недель назад и столкнулся с некоторыми проблемами. Это немного больше работы, чем кажется, но очень важно иметь этот набор данных, и я надеюсь, что мы до него доберемся.

@rsc, ваша презентация GothamGo по этой теме была размещена на YouTube https://www.youtube.com/watch?v=h6Cw9iCDVcU и станет хорошим дополнением к первому посту.

В разделе «Какие еще проблемы необходимо решить в предложении по псевдонимам типов?» Было бы полезно указать, что ответ на вопрос «Можно ли определять методы для типов, названных псевдонимом?» трудный нет. Я понимаю, что это противоречит установленному духу раздела, но я заметил, что во многих разговорах о псевдонимах, здесь и в других местах, есть люди, которые сразу же отвергают эту концепцию, потому что они считают, что псевдонимы обязательно позволят это и, таким образом, вызовут проблемы, чем решает. Это подразумевается в определении, но явное упоминание об этом приведет к короткому замыканию множества ненужных взад и вперед. Хотя, возможно, это относится к часто задаваемым вопросам о псевдонимах в новом предложении по псевдонимам, если это будет результатом этой темы.

@Merovius - любую экспортируемую глобальную изменяемую переменную пакета можно смоделировать с помощью функций получения и установки на уровне пакета.

Для данной версии n пакета p ,

package p
var Global = 0

в версии n + 1 могут быть добавлены геттеры и сеттеры, а переменная устарела

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 и отказаться от GetGlobal() в пользу более идиоматичного Global() .)

Это не быстрое решение, но оно уменьшает проблему, так что только псевдонимы функций (или их нынешний обходной путь) строго необходимы для постепенного восстановления кода.

@rsc Одно тривиальное использование псевдонимов, которые вы не

@jimmyfrasche Вы правы. Мне не нравится идея использования геттеров и сеттеров (точно так же, как я не люблю использовать их для полей структуры), но ваш анализ, конечно, верен.

Следует отметить использование псевдонимов без восстановления (например, создание заменяющих пакетов), но я признаю, что это ослабляет аргументы в пользу var-aliases.

@Merovius согласился по всем пунктам. Я тоже не в восторге от этого, но должен следовать логике v☹v

@niemeyer, можете ли вы пояснить, как адаптеры могут помочь в переносе типов, в которых и у старого, и у нового есть метод с тем же именем, но с разными сигнатурами. Добавление аргумента к методу или изменение типа аргумента кажется обычным развитием кодовой базы.

@rogpeppe Обратите внимание, что именно так это и происходит сегодня:

type two one

Это делает one и two независимыми типами, и независимо от того, отражают ли они interface{} или под ним, вы видите именно это. Вы также можете конвертировать между one и two . Приведенное выше предложение адаптера просто делает этот последний шаг автоматическим для адаптеров. Вам может не понравиться это предложение по нескольким причинам, но в этом нет ничего противоречащего.

@iand Как и в случае с type two one , эти два типа имеют полностью независимые наборы методов, поэтому в сопоставлении имен нет ничего особенного. До того, как будут перенесены старые базы кода, они по-прежнему будут использовать старую подпись предыдущего типа (теперь адаптер). Новый код, использующий новый тип, будет использовать новую подпись. Передача значения нового типа в старый код автоматически адаптирует его, поскольку компилятор знает, что последний является адаптером первого, и поэтому использует соответствующий набор методов.

@niemeyer Похоже, что за этими адаптерами скрывается много сложностей, которые не определены полностью. На данный момент я думаю, что простота псевдонимов типов имеет решающее значение в их пользу. Я сел, чтобы перечислить все, что нужно обновить, только для псевдонимов типов, и это очень длинный список. Список адаптеров, безусловно, был бы длиннее, и я до сих пор не совсем понимаю все детали. Я хотел бы предложить нам сделать псевдонимы типов на данный момент и оставить решение об относительно более тяжелых адаптерах на потом, если вы хотите разработать полное предложение (но опять же, я скептически отношусь к тому, что там не прячутся драконы) .

@jimmyfrasche Что касается методов на псевдонимах, конечно, псевдонимы не позволяют обойти обычные ограничения определения методов: если пакет определяет тип T1 = otherpkg.T2, он не может определять методы на T1, так же как он не может определять методы непосредственно на otherpkg.T2. Однако, если пакет определяет тип T1 = T2 (оба в одном пакете), то ответ менее ясен. Мы могли бы ввести ограничение, но (пока) в этом нет очевидной необходимости.

Обновлено резюме обсуждения верхнего уровня . Изменения:

• Добавлена ​​ссылка на видео GothamGo
• В качестве возможного использования добавлено «сокращение длинных имен» для @jba.
• Добавлен x / image / draw в качестве аргумента против ограничения стандартной библиотеки для @Merovius.
• Добавлен дополнительный текст о методах псевдонимов для @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 не может обновить имя до p1.T1 без нарушения текущего p2 .

Выходом из этого может быть: а) в целом ограничить любое обещание периода совместимости / устаревания кодом, который не ссылается на встроенные поля по имени, или б) добавить отдельный этап устаревания, поэтому p1 добавляет type T1 = T2 и отменяет поддержку T2 , затем p2 отменяет ссылку на (скажем) s2.T2 по имени, все импортеры p2 будут исправлены чтобы не делать этого, p2 выполняет переключение.

Теоретически проблема может повторяться бесконечно; p4 может импортировать p3 , который сам встраивает тип из p2 ; мне кажется, что p3 тоже должен иметь период устаревания, чтобы ссылаться на дважды встроенное поле по имени? В этом случае самый внутренний период устаревания становится бесконечно малым или самый внешний становится бесконечным. Но даже не рассматривая проблему как рекурсивную, мне могло бы показаться, что b) было бы довольно сложно определить по времени (период устаревания p2 должен полностью содержаться в периоде устаревания p1 . Таким образом, если T - это «стандартный период устаревания», вам нужно будет выбрать не менее 2T при переименовании типов, чтобы выпуски совпадали).

а) мне тоже кажется непрактичным; например, если тип включает *byte.Buffer и я хочу установить это поле (или передать этот буфер какой-либо другой функции), просто нет способа сделать это, не обращаясь к нему по имени (кроме использования инициализаторов структуры без имен, что тоже теряет гарантии совместимости :)).

Я понимаю привлекательность совместимости с псевдонимами byte и rune . Но лично я бы поставил это второстепенным по отношению к сохранению полезности псевдонимов типов для постепенного восстановления. (Вероятно, плохой) пример идеи получить и то, и другое: для экспортируемых имен можно использовать любой псевдоним для ссылки на встроенное поле и для неэкспортированных имен (по сути ограниченных одним и тем же пакетом, таким образом, под большим контролем автора. ) сохранить предложенную на данный момент семантику? Да, мне тоже не нравится это различие. Может у кого-то есть идея получше.

@rsc re методы на псевдониме

Если у вас есть тип S, который является псевдонимом для типа T, оба определены в одном пакете, и вы разрешаете определять методы на S, что, если T является псевдонимом для pF, определенным в другом пакете? Хотя это, очевидно, также должно потерпеть неудачу, есть тонкости в обеспечении соблюдения, реализации и удобочитаемости источника, которые следует учитывать (если T находится в файле, отличном от S, не сразу понятно, можете ли вы определить метод на T, посмотрев на определение T).

Правило - если у вас есть type T = S , то вы не можете объявлять методы в T - является абсолютным, и из этой единственной строчки в источнике ясно, что оно применяется, без необходимости исследования источника S, как и в случае псевдонима псевдонима.

Кроме того, разрешение методов на псевдониме локального типа размывает различие между псевдонимом типа и определением типа. Поскольку методы в любом случае будут определены как для S, так и для T, ограничение, что они могут быть записаны только на одном, не ограничивает то, что может быть выражено. Он просто делает вещи более простыми и единообразными.

@jimmyfrasche Если мы пишем type T1 = T2 и T2 находится в одном пакете, то мы, вероятно, отказываемся от имени T2. В этом случае нам нужно как можно меньше вхождений 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 чтобы убедиться, что это не псевдоним, который является псевдонимом типа в другом пакете. Единственное преимущество - сложность.

Всегда запрещать методы в псевдониме проще и легче читать, и вы ничего не потеряете. Я не думаю, что очень часто будет возникать сбивающий с толку случай, но нет необходимости вводить возможность, когда вы не получаете ничего, с чем нельзя было бы лучше справиться в другом месте или с помощью другого, но эквивалентного подхода.

@Merovius

если p1 хочет переименовать тип типа T1 = T2, а пакет p2 встраивает p1.T2 в структуру, они никогда не смогут обновить это определение до p1.T1, потому что импортер p3 может ссылаться на встроенную структуру по имени.

Сегодня во многих случаях можно обойти эту проблему, заменив анонимное поле именованным полем и явно перенаправив методы. Однако это не сработает для неэкспортированных методов.

Другой вариант - добавить вторую функцию для компенсации. Если бы вы могли принять набор методов поля, не делая его анонимным (или с явным переименованием), это позволило бы имени поля оставаться неизменным даже при изменении базового типа.

Учитывая объявление из вашего примера:

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 Чем больше я об этом думаю, тем больше мне нравится идея псевдонимов полей.

Явная пересылка методов утомительна, даже если они экспортированы, и нарушает другие виды рефакторинга (например, добавление методов к встроенному типу и ожидание того, что тип, который встраивает его, будет продолжать удовлетворять тому же интерфейсу). И переименование полей структуры также подпадает под общий принцип постепенного восстановления кода.

@Merovius

если p1 хочет переименовать тип типа T1 = T2, а пакет p2 встраивает p1.T2 в структуру, они никогда не смогут обновить это определение до p1.T1, потому что импортер p3 может ссылаться на встроенную структуру по имени. p2 тогда не может переключиться на p1.T1, не нарушив p3; p3 не может обновить имя до p1.T1 без разрыва с текущим p2.

Если я понимаю ваш пример, у нас есть:

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.

В этом конкретном случае мы можем обновить пакет p2, чтобы использовать новый API p1 с псевдонимом локального типа:

package p2

import "p1"

type T2 = p1.T1

type S struct {
  T2
}

Это, конечно, не лучшее решение в долгосрочной перспективе. Я не думаю, что есть какой-то способ обойти тот факт, что p2 нужно будет изменить свой экспортированный API, чтобы исключить имя T2, однако это будет происходить так же, как любое переименование поля.

Замечание о «перемещении типов между пакетами». Разве эта формулировка не вызывает проблем?

Насколько я понимаю, предложение позволяет «ссылаться» на определение объекта, которое находится в другом пакете, через новое имя.

Он не перемещает определение объекта, не так ли? (если только кто-то не пишет код, используя в первую очередь псевдонимы, и в этом случае пользователь может изменить место, на которое ссылается псевдоним, точно так же, как в пакете draw pkg).

@atdiar Ссылка на тип в другом пакете может использоваться как шаг при перемещении типа. Да, псевдоним не перемещает тип, но его можно использовать как инструмент для этого.

@Merovius Это может

@atdiar Мне очень жаль, но я не понимаю, что вы пытаетесь сказать. Вы читали оригинальный комментарий этой ветки, статью о постепенном ремонте, связанную с ней, и обсуждение до сих пор? Если вы пытаетесь добавить к обсуждению еще не рассмотренный аргумент, я считаю, что вам нужно внести ясность.

Наконец, полезное и хорошо написанное предложение. Нам нужен псевдоним типа, у меня большие проблемы с созданием единого API без псевдонима типа, до сих пор мне приходится писать свой код так, как мне не очень нравится это делать. Это должно быть включено в версию 1.8, но никогда не поздно, так что вперед 1.9.

@Merovius
Я прямо говорю о «перемещении типов» между пакетами. Это меняет определение объекта. Например, в pkg duplicate некоторая информация привязана к пакету, в котором был определен объект.
Если переместить определение, оно может сломаться.

@kataras это не совсем хорошая документация и комментарии, просто определения типов не следует перемещать. Насколько я ценю предложение псевдонима, я опасаюсь, что люди думают, что они могут просто это сделать.

@atdiar еще раз, пожалуйста, прочтите статью из исходного комментария и обсуждения. Перемещение типов и способы решения ваших проблем - основная задача этой темы. Если вы не чувствуете, что статья Расса адекватно решает ваши проблемы, просьба уточнить, почему его объяснение вас не устраивает. :)

@kataras Хотя я лично согласен, я не думаю, что это особенно полезно, просто утверждать, насколько важной мы считаем эту функцию. Необходим конструктивный аргумент, чтобы снять озабоченность людей. :)

@Merovius Я прочитал документ. Это не отвечает на мой вопрос. Думаю, я был достаточно откровенен. Это связано с той же проблемой, которая помешала нам реализовать прежнее предложение псевдонима.

@atdiar Я, по крайней мере, не понимаю. Вы говорите, что перемещение шрифта сломает вещи; предложение заключается в том, как избежать таких поломок путем постепенного восстановления, используя псевдоним, затем обновлять каждую обратную зависимость до тех пор, пока ни один код не будет использовать старый тип, а затем удалить старый тип. Я не понимаю, как ваше утверждение о том, что "отражение и плагины" не работают при этих предположениях. Если вы хотите подвергнуть сомнению предположения, это уже обсуждалось.

Я также не понимаю, как какие-либо проблемы, препятствующие вводу псевдонимов в 1.8, связаны с тем, что вы сказали. Соответствующие выпуски, насколько мне известно, - это # ​​17746 и # 17784. Если вы имеете в виду проблему встраивания (которая может быть истолкована как относящаяся к поломкам или отражению, хотя я не согласен), то она рассматривается в формальном предложении (хотя, см. Выше, я считаю, что предлагаемое решение заслуживает более подробного обсуждения) и вы должны конкретно объяснить, почему вы не верите в это.

Итак, извините, но нет, вы не были достаточно конкретны. У вас есть номер проблемы для «той же проблемы, которая помешала нам реализовать предыдущее предложение по псевдониму», о которой вы говорите, которая относится к тому, что вы упомянули до сих пор, чтобы помочь понять? Можете ли вы привести конкретный пример сбоев, о которых вы говорите (см. Примеры для этого восходящего потока; дайте последовательность пакетов, определений типов и некоторого кода и опишите, как он ломается при преобразовании, как предлагается)? Если вы хотите, чтобы ваши проблемы были решены, вам действительно нужно сначала помочь другим понять их.

@Merovius Итак, что происходит в случае транзитивных зависимостей, когда одна из этих зависимостей смотрит на reflection.Type.PkgPath ()?
Это та же проблема, что и при встраивании.

@atdiar Мне очень жаль, но я не понимаю, насколько это понятное беспокойство в свете обсуждения в этой ветке и о чем это предложение. Сейчас я выйду из этой конкретной подтяжки и дам другим, кто может лучше понять ваше возражение, возможность обратиться к нему.

Позвольте мне перефразировать это кратко:

Проблема заключается в равенстве типов, учитывая тот факт, что определение типа жестко кодирует свое собственное местоположение.
Поскольку равенство типов может быть проверено и проверяется во время выполнения, я не понимаю, как легко перемещать типы.

Я просто предупреждаю, что этот вариант использования «движущихся типов» потенциально может нарушить работу множества пакетов на расстоянии. Аналогичная проблема с плагинами.

(точно так же изменение типа указателя в пакете сломало бы множество других пакетов, если эта параллель может прояснить ситуацию.)

@atdiar Опять же, эта проблема

@niemeyer

Это делает один и два независимых типа, и независимо от того, отражают ли они или под интерфейсом {}, вот что
Понимаете. Вы также можете преобразовать от одного до двух. Предложение адаптера, приведенное выше, как раз и делает это последним.
ступенчатый автоматический для переходников. Предложение может вам не понравиться по нескольким причинам, но в нем нет ничего
противоречиво об этом.

Вы не можете конвертировать между

 func() one

а также

func() two

@Merovius Вы не можете подумать об изменении всех импортеров пакета с исправленным кодом, которые существуют в дикой природе. И я не очень хочу начинать здесь углубляться в вопросы управления версиями пакетов.

Чтобы быть ясным, я не против предложения псевдонима, а против формулировки «перемещение типов между пакетами», которая подразумевает вариант использования, который еще не доказал свою безопасность.

@jimmyfrasche о предсказуемости валидности метода по псевдониму:

Это уже тот случай, когда func (t T) M() иногда действителен, иногда недействителен. Это не так уж и важно, потому что люди не слишком часто выходят за эти границы. То есть хорошо работает на практике. https://play.golang.org/p/bci2qnldej. В любом случае это входит в список _ возможных_ ограничений. Как и все возможные ограничения, это добавляет сложности, и мы хотим увидеть конкретные доказательства из реального мира, прежде чем добавлять эту сложность.

@Merovius , повторное встраивание имен:

Я согласен с тем, что ситуация не идеальна. Однако, если у меня есть кодовая база, полная ссылок на io.ByteBuffer, и я хочу переместить ее в bytes.Buffer, тогда я хочу иметь возможность представить

package io
type ByteBuffer = bytes.Buffer

_без обновления каких-либо существующих ссылок на io.ByteBuffer. Если все места, в которые встроен io.ByteBuffer, автоматически меняют имя поля на Buffer в результате замены определения типа псевдонимом, значит, я сломал мир и постепенного восстановления нет. Напротив, если имя встроенного io.ByteBuffer по-прежнему является ByteBuffer, то использование может обновляться по одному в ходе их собственного постепенного восстановления (возможно, придется выполнять несколько шагов; опять же, не идеально).

Мы подробно обсуждали это в # 17746. Изначально я был сторонником того, чтобы псевдоним встроенного io.ByteBuffer был Buffer, но приведенный выше аргумент убедил меня, что я ошибался. @jimmyfrasche, в частности,

Обратите внимание, что в вашем примере есть обходной путь в p2. Если p2 действительно хочет встроенное поле с именем ByteBuffer без ссылки на io.ByteBuffer, он может определить:

type ByteBuffer = bytes.Buffer

а затем вставьте ByteBuffer (то есть p2.ByteBuffer) вместо io.ByteBuffer. Это тоже не идеально, но значит, ремонт можно продолжать.

Это определенно тот случай, когда это не идеально, и что переименование полей в целом в этом предложении не рассматривается. Может случиться так, что встраивание не должно быть чувствительным к базовому имени, что должен быть какой-то синтаксис для «встроить X как имя N». Также может быть, что мы должны добавить псевдонимы полей позже. Обе идеи априори кажутся разумными, и обе, вероятно, должны быть отдельными, более поздние предложения оцениваются на основе реальных доказательств необходимости. Если псевдонимы типов помогут нам добраться до точки, когда отсутствие псевдонимов полей станет следующим большим препятствием для крупномасштабного рефакторинга, это будет прогресс!

(/ cc @neild и @bcmills)

@atdiar , да, это правда, что рефлексия будет видеть насквозь подобные изменения, и если код зависит от результатов рефлексии, он сломается. Как и в случае с встраиванием, он не идеален. В отличие от ситуации со встраиванием, у меня нет никаких ответов, кроме, может быть, код не следует писать с использованием отражения, чтобы он был настолько чувствителен к этим деталям.

@rsc Я имел в виду: а) запретить встраивание как псевдонима, так и его определяющего типа в одну структуру (для предотвращения двусмысленности от b), b) разрешить ссылаться на поле по любому имени в исходном коде, c) выбрать одно или другой в сгенерированной информации о типе / отражении и т.п. (неважно какой).

Я бы сказал, махнув рукой, что это помогает избежать поломок, которые я пытался описать, а также сделать четкий выбор для случая, когда выбор необходим; и лично меня меньше заботит то, чтобы не нарушить код, который полагается на отражение, чем код, который этого не делает.

Я не уверен прямо сейчас, понимаю ли я ваш аргумент ByteBuffer, но я также нахожусь в конце долгого рабочего дня, поэтому не нужно объяснять дальше, если я нахожу это неубедительным, я в конце концов отвечу :)

@Merovius Я думаю, имеет смысл попробовать простые правила и посмотреть, как далеко мы

Я согласен с тем, что, возможно, вариант (б) является хорошей идеей в определенных обстоятельствах, но, возможно, не в других. Если вы используете псевдонимы типов для упомянутого ранее варианта использования «структурировать API из одного пакета в несколько пакетов реализации», то, возможно, вы не хотите встраивать псевдоним, чтобы отображать другое имя (которое может быть во внутреннем пакете и в противном случае недоступен для большинства пользователей). Надеюсь, мы накопим больше опыта.

@rsc

Возможно, может помочь добавление информации о псевдонимах на уровне пакета к объектным файлам.
(Принимая во внимание, должны ли плагины go работать должным образом или нет.)

@Merovius @rsc

а) запретить встраивание как псевдонима, так и его определяющего типа в одну структуру

Обратите внимание, что во многих случаях это уже запрещено из-за способа взаимодействия внедрения с наборами методов. (Если для встроенного типа установлен непустой метод и вызывается один из этих методов, программа не сможет скомпилировать: https://play.golang.org/p/XkaB2a0_RK.)

Таким образом, добавление явного правила, запрещающего двойное встраивание, кажется, будет иметь значение только в небольшом подмножестве случаев; мне кажется, не стоит сложностей.

Почему бы вместо этого не подойти к псевдонимам типов как к алгебраическим типам и не поддержать псевдонимы для набора типов, чтобы мы также получили эквивалент пустого интерфейса с проверкой типов во время компиляции в качестве бонуса, а-ля

type Stringeroonie = {string,fmt.Stringer}

@ j7b

Почему бы вместо этого не рассматривать псевдонимы типов как алгебраические типы и не поддерживать псевдонимы для набора типов

Псевдонимы семантически и структурно эквивалентны исходному типу. Алгебраические типы данных не являются: в общем случае они требуют дополнительного хранилища для тегов типов. (Типы интерфейсов Go уже несут эту информацию о типе, но структуры и другие неинтерфейсные типы - нет.)

@bcmills

Это могло быть ошибочным рассуждением, но я думал, что к проблеме можно подойти, поскольку псевдоним A типа T эквивалентен объявлению A как interface {} и разрешению компилятору прозрачно преобразовывать переменные типа A в T в областях, где объявлены переменные типа A. , который, как я думал, будет в основном линейным, однозначным во время компиляции и создаст основу для управляемых компилятором псевдотипов, включая алгебраику, с использованием синтаксиса type T = , и, возможно, также позволит реализовать такие типы, как неизменяемые ссылки, во время компиляции, которые как что касается пользовательского кода, это был бы просто интерфейс {} "под капотом".

Недостатки в этом образе мыслей, вероятно, были бы результатом невежества, и, поскольку я не в состоянии предложить практическое доказательство концепции, я счастлив принять это несовершенное и отложить.

@ j7b Даже если ADT является решением одной проблемы постепенного ремонта, они создают свои собственные; невозможно добавить или удалить какие-либо члены ADT без нарушения зависимостей. Таким образом, вы, по сути, создадите больше проблем, чем решите.

Ваша идея прозрачного перевода в интерфейс {} и из него также не работает для типов более высокого порядка, таких как []interface{} . И в конечном итоге вы потеряете одну из сильных сторон go, которая заключается в том, чтобы дать пользователям контроль над компоновкой данных и вместо этого выполнять java-функцию, заключающуюся в упаковке всего.

ADT здесь не решение.

@Merovius Я почти уверен, что если конструкция алгебраического типа включает переименование (которое согласовывалось бы с разумным определением того же самого), это решение, этот интерфейс {} может служить прокси для формы проекции и выбора, управляемой компилятором. описан, и я не уверен, насколько релевантен макет данных и как вы определяете типы «высшего порядка», тип - это просто тип, если он может быть объявлен, а [] interface {} - это просто тип.

Помимо всего этого, я уверен, что type T = потенциально может быть перегружен интуитивно понятными и полезными способами, помимо переименования, алгебраические типы и общедоступные неизменяемые ссылки кажутся наиболее очевидными приложениями, поэтому я надеюсь, что в спецификации будет указан этот синтаксис. указывает на мета или псевдотип, управляемый компилятором, и рассматриваются все способы использования управляемого компилятором типа, а также синтаксис, который лучше всего выражает это использование. Поскольку новый синтаксис не должен заботиться о наборе глобально зарезервированных слов при использовании в качестве квалификаторов, что-то вроде type A = alias Type будет ясным и расширяемым.

@ j7b

Помимо всего прочего, я уверен, что тип T = потенциально может быть перегружен интуитивно понятными и полезными способами, помимо переименования,

Я очень надеюсь, что нет. Go сегодня (в основном) хорошо ортогонален, и поддержание этой ортогональности - это хорошо.

Сегодня в Go объявляют новый тип T как type T def , где def - это определение нового типа. Если бы нужно было реализовать алгебраические типы данных (также известные как помеченные объединения), я бы ожидал, что они будут следовать этому синтаксису, а не синтаксису для псевдонимов типов.

Мне нравится использовать другую точку зрения (в поддержку) псевдонимов типов, которая может дать некоторое представление об альтернативных вариантах использования, помимо рефакторинга:

Давайте вернемся на мгновение назад и предположим, что у нас не было обычных объявлений старых типов Go в форме type T <a type> , а только объявления псевдонимов типов type A = <a type> .

(Для полноты картины давайте также предположим, что методы каким-то образом объявлены по-другому - не через ассоциацию с именованным типом, используемым в качестве получателя, потому что мы не можем. Например, можно представить себе понятие типа класса с методами буквально внутри, и поэтому нам не нужно полагаться на именованный тип для объявления методов. Два таких типа, которые структурно идентичны, но имеют разные методы, будут разными типами. Детали здесь не важны для этого мысленного эксперимента.)

Я утверждаю, что в таком мире мы могли бы написать почти тот же код, который мы пишем сейчас: мы используем имена типов (псевдонимов), поэтому нам не нужно повторяться, а сами типы гарантируют, что мы используем данные в типе -безопасный способ.

Другими словами, если бы Go был спроектирован таким образом, мы, вероятно, тоже были бы в порядке в целом.

Более того, в таком мире, поскольку типы идентичны, если они структурно идентичны (независимо от названия), проблемы, которые у нас сейчас возникают с рефакторингом, не проявились бы в первую очередь, и не было бы необходимости в каком-либо изменения языка.

Но у нас не было бы механизма безопасности, который есть в текущем Go: мы не сможем ввести имя для типа и заявить, что теперь это должен быть новый, другой тип. (Тем не менее, важно помнить, что это, по сути, предохранительный механизм.)

В других языках программирования идея создания нового типа, отличного от существующего, называется «брендингом»: к типу присваивается бренд, который отличает его от всех других типов. Например, в Modula-3 было специальное ключевое слово BRANDED чтобы это произошло (например, TYPE T = BRANDED REF T0 создаст новую, другую ссылку на T0). В Haskell слово new перед типом имеет аналогичный эффект.

Возвращаясь к нашему альтернативному миру Go, мы можем найти себя в положении, когда у нас нет проблем с рефакторингом, но мы хотели повысить безопасность нашего кода, чтобы type MyBuffer = []byte и type YourBuffer = []byte обозначали разные типы, чтобы мы случайно не использовали неправильный. Мы могли бы предложить ввести форму брендирования шрифтов именно для этой цели. Например, мы могли бы захотеть написать type MyBuffer = new []byte или даже type MyBuffer = new YourBuffer с эффектом, что MyBuffer теперь отличается от YourBuffer.

По сути, это двойная проблема того, что мы имеем сейчас. Так получилось, что в Go с первого дня мы всегда работали с «фирменными» типами, как только они получали название. Другими словами, type T <a type> фактически означает type T = new <a type> .

Подводя итог: в существующем Go именованные типы всегда являются «фирменными» типами, и нам не хватает понятия просто имени для типа (которое мы теперь называем псевдонимами типов). В некоторых других языках псевдонимы типов являются нормой, и для создания явно нового, другого типа необходимо использовать механизм «брендинга».

Дело в том, что оба механизма полезны по своей сути, и с псевдонимами типов мы наконец-то нашли возможность поддерживать их оба.

@griesemer Расширением этой возможности является первоначальное предложение псевдонима, которое в идеале должно очистить рефакторинг. Боюсь, что только псевдонимы типов могут создать сложные крайние случаи рефакторинга из-за их ограниченной области действия.

В обоих предложениях меня не интересует, не требуется ли сотрудничество компоновщика, потому что имя является частью определения типа в Go, как вы объяснили.

Я совсем не знаком с объектным кодом, так что это просто идея, но кажется, что можно добавлять пользовательские разделы в объектные файлы. Если бы случайно можно было сохранить своего рода развернутый связанный список, заполненный во время связывания именами типов и их псевдонимами, возможно, это могло бы помочь. Среда выполнения будет иметь всю необходимую информацию без ущерба для отдельной компиляции.

Идея состоит в том, что среда выполнения должна иметь возможность динамически возвращать различные псевдонимы для данного типа, чтобы сообщения об ошибках оставались четкими (поскольку псевдонимы вводят несоответствие имен между выполняющимся кодом и написанным кодом).

Альтернативой отслеживанию использования псевдонимов может быть конкретная история управления версиями в целом, чтобы иметь возможность «перемещать» определения объектов между пакетами, как это было сделано для пакета контекста. Но это совсем другой вопрос.

В конце концов, все же неплохо было бы оставить структурную эквивалентность интерфейсам и назвать эквивалентность типам.
Учитывая тот факт, что тип может считаться интерфейсом с большим количеством ограничений, кажется, что объявление псевдонима должно / могло быть реализовано путем сохранения среза строк для каждого пакета срезов.

@atdiar Я не уверен, что вы имеете в виду то, что я делаю, когда говорите «отдельная компиляция». Если пакет P импортирует io и байты, тогда все три могут быть скомпилированы как отдельные шаги. Однако, если изменяется io или байты, то P необходимо перекомпилировать. Это _не_ тот случай, когда вы можете внести изменения в io или байты, а затем просто использовать старую компиляцию P. Даже в режиме плагина это правда. Из-за таких эффектов, как встраивание между пакетами, даже невидимые API изменения в реализации io или байтов изменяют эффективный ABI, поэтому P необходимо перекомпилировать. Псевдонимы типов не усугубляют эту проблему.

@ j7d , на уровне системы типов, типы суммы или любой вид подтипов (как было предложено другими ранее в обсуждении) помогают только в определенных случаях использования. Это правда, что мы можем рассматривать bytes.Buffer как подтип io.Reader («буфер - это читатель» или в вашем примере «строка - это Stringeroonie»). Проблемы возникают при построении более сложных типов с их использованием. Остальная часть этого комментария говорит о типах Go, но говорит об их фундаментальных отношениях на уровне подтипов, а не о том, что Go на самом деле реализует. Однако в Go должны быть реализованы правила, соответствующие фундаментальным отношениям.

Конструктор типа (причудливый способ сказать «способ использования типа») ковариантен, если он сохраняет отношение подтипов, и контравариантен, если он инвертирует отношение.

Использование типа в результате функции ковариантно. Func () Buffer "- это" Func () Reader ", потому что возврат Buffer означает, что вы вернули Reader. Использование типа в аргументе функции _не_ ковариантно. Func (Buffer) не является func (Reader), потому что func нуждается в Buffer, а некоторые Readers не являются буферами.

Использование типа в аргументе функции контравариантно. Func (Reader) - это func (Buffer), потому что func требует только Reader, а Buffer - это Reader. Использование типа в результате функции _не_ контравариантно. Считыватель func () не является буфером func (), потому что функция возвращает Reader, а некоторые считыватели не являются буферами.

Комбинируя их, func (Reader) Reader не является func (Buffer) Buffer, или наоборот, потому что либо аргументы не работают, либо результаты не работают. (Единственная комбинация в этих строках, которая работает, - это то, что func (Reader) Buffer является func (Buffer) Reader.)

В общем, если func (X1) X2 является (подтипом) func (X3) X4, то должно быть, что X3 является (подтипом) X1, и аналогично X2 является (подтипом) X4. В случае использования псевдонима, когда мы хотим, чтобы T1 и T2 были взаимозаменяемыми, func (T1) T1 является подтипом func (T2) T2, только если T1 является подтипом T2 _ и T2 является подтипом T1. Это в основном означает, что 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}, или переменная типа Т). Фактически, наиболее распространенный случай в Go, как вы можете видеть из примеров, - это ввод + вывод.

Конкретно, буфер [] не является [] читателем (потому что вы можете хранить файл в [] ридере, но не в [] буфере), ни [] ридер не является [] буфером (потому что выборка из [] Читатель может вернуть файл, в то время как выборка из буфера [] должна возвращать буфер).

Вывод из всего этого состоит в том, что если вы хотите решить общую проблему восстановления кода, чтобы код мог использовать либо T1, либо T2, вы не можете сделать это с какой-либо схемой, которая делает T1 только подтипом T2 (или наоборот). Каждый должен быть подтипом другого, то есть они должны быть одного и того же типа, иначе некоторые из перечисленных вариантов использования будут недопустимыми.

То есть подтипа недостаточно для решения проблемы постепенного восстановления кода. Вот почему псевдонимы типов вводят новое имя для того же типа, так что T1 = T2, вместо попытки подтипа.

Этот комментарий также относится к предложению @iand две недели назад неких «заменяемых типов» и, по сути, к расширению ответа @griesemer с тех пор.

Обновлено резюме обсуждения верхнего уровня. Изменения:

• Удалено TODO, чтобы обновить сводку обсуждения адаптера, которое, похоже, исчезло.
• Добавлена ​​сводка обсуждения встраивания и переименования полей.
• Краткое изложение «методов на псевдонимах» перемещено в отдельный раздел из списка вопросов по дизайну, расширенное за счет включения последних комментариев.
• Добавлена ​​сводка обсуждения влияния на программы, использующие отражение.
• Добавлена ​​аннотация обсуждения отдельной компиляции.
• Добавлена ​​сводка обсуждения различных подходов, основанных на подтипах.

@rsc относительно отдельной компиляции, мой комментарий касается того, нужно ли определениям типов хранить список своих псевдонимов (который не поддается обработке в больших масштабах из-за требований отдельной компиляции), или каждый псевдоним включает итеративное построение списка имен псевдонимов, следующих за граф импорта, все связано с заданным начальным именем типа, указанным в определении типа. (и как и где хранить эту информацию, чтобы среда выполнения имела к ней доступ).

@atdiar В системе нет такого списка псевдонимов. Среда выполнения не имеет к нему доступа. Псевдонимы не существуют во время выполнения.

@rsc Ага , извини. Я застрял с первоначальным предложением псевдонима в голове и думал о псевдониме для func (при обсуждении псевдонима для типов). В этом случае будет несоответствие между именами в коде и именами во время выполнения.
В этом случае использование информации в runtime.Frame для ведения журнала потребует некоторого переосмысления.
Забудь обо мне.

@rsc спасибо за повторное обобщение. Имя встроенного поля все еще раздражает меня; все предлагаемые обходные пути полагаются на постоянные кладжи, чтобы сохранить старые имена. Хотя основная мысль в этом комментарии , а именно то, что это частный случай переименования полей, что тоже невозможно, убеждает меня в том, что это действительно следует рассматривать (и решать) как отдельную проблему. Имеет ли смысл открыть отдельный вопрос для запроса / предложения / обсуждения для поддержки переименования полей для постепенного восстановления (возможно, адресованного в том же выпуске go)?

@Merovius , я согласен с тем, что постепенное исправление кода для переименования полей выглядит как следующая проблема в последовательности. Я думаю, чтобы начать это обсуждение, кому-то нужно собрать набор реальных примеров, чтобы иметь некоторые доказательства того, что это широко распространенная проблема, а также проверять возможные решения. На самом деле, я не думаю, что это произойдет с одним и тем же релизом.

Вернулся через две недели. Дискуссия вроде бы сошлась. Даже обновление обсуждения две недели назад было довольно незначительным.

Предлагаю:

• принять предложение псевдонима типа как предварительное решение проблемы, изложенной выше,
  при условии, что реализация может быть готова для тестирования в начале Go 1.9 (1 февраля).
• создайте ветку dev.typealias, чтобы CL можно было просмотреть сейчас (январь) и объединить с master в начале Go 1.9.
• принять окончательное решение о сохранении псевдонимов типов в начале «заморозки» Go 1.9 (как мы это делали для обобщенных псевдонимов в цикле Go 1.8).

+1

Я ценю историю обсуждения этого изменения. Допустим, это реализовано. Без сомнения, это станет скорее второстепенной деталью языка, чем основной функцией. Таким образом, он добавляет сложности языку и инструментам, непропорционально их фактической частоте использования. Это также увеличивает площадь поверхности, на которой язык может быть ненамеренно злоупотреблен. По этой причине излишняя осторожность - это хорошо, и я рад, что до сих пор было много дискуссий.

@Merovius : Извините за редактирование моего сообщения! Я думал, что никто не читает. Первоначально в этом комментарии я выразил некоторый скептицизм по поводу того, что это изменение языка необходимо, когда уже существуют инструменты, такие как инструмент gorename .

@ jcao219 Об этом уже говорилось ранее, но, что удивительно, я не могу быстро найти это здесь. Это подробно обсуждается в исходной ветке для общих псевдонимов # 16339 и связанных нитей golang-nut. Вкратце: этот вид инструментов касается только того, как подготовить исправляющие коммиты, а не как упорядочить изменения, чтобы предотвратить поломки. Независимо от того, вносятся ли изменения инструментом или человеком, не имеет значения для проблемы, поскольку в настоящее время не существует последовательности коммитов, которые не нарушили бы тот или иной код (исходный комментарий этой проблемы и связанный с ним документ более обосновывают это утверждение в -глубина).

Для более автоматизированных инструментов (например, интегрированных в инструмент go и т.п.) исходный комментарий обращается к этому под заголовком «Может ли это быть изменение только инструментария или компилятора вместо изменения языка?».

В заключение скажем, что изменение реализовано. Без сомнения, это станет скорее второстепенной деталью языка, чем основной функцией.

Выражаю сомнение. :) Не считаю это предрешенным.

@Merovius

Выражаю сомнение. :) Не считаю это предрешенным.

Думаю, я имел в виду, что люди, которые будут использовать эту функцию, в основном будут сопровождать важные пакеты Go с большим количеством зависимых клиентов. Другими словами, это приносит пользу тем, кто уже является экспертом по Go. В то же время он представляет соблазнительный способ сделать код менее читаемым для начинающих программистов Go. Исключение составляет случай переименования длинных имен, но естественные имена типов Go обычно не слишком длинные или сложные.

Как и в случае с функцией импорта точек, для учебных пособий и документов было бы разумно сопровождать свои упоминания об этой функции заявлением о правилах использования.

Например, скажем, я хотел использовать "github.com/gonum/graph/simple".DirectedGraph" , и я хотел присвоить ему псевдоним digraph чтобы не вводить simple.DirectedGraph , это было бы хорошо вариант использования? Или следует ограничить такое переименование необоснованно длинными именами, созданными такими вещами, как 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. Как только это произойдет, мы сможем увидеть, нужна ли дополнительная поддержка. Может быть, а может и нет.
2. Можно ли определять методы для типов, названных псевдонимом? да. Проектный документ: «Поскольку T1 - это просто еще один способ написать T2, у него нет собственного набора объявлений методов. Вместо этого набор методов T1 такой же, как и T2. По крайней мере, для первоначального испытания нет ограничений на объявления методов. использование T1 в качестве типа получателя, при условии использования T2 в том же объявлении, было бы допустимым ".
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 явным: да, T1 экспортируется из пакета a (потому что это T1, а не 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{} . Какой дополнительный вред приносят в этом случае псевдонимы?

Люди уже сегодня могут написать тип Any interface {}. Какой дополнительный вред приносят в этом случае псевдонимы?

Я назвал это антипаттерном, потому что это именно то, что есть. type Any interface{} , потому что если человек, пишущий_ код, набирает что-то немного короче, это имеет для него немного больше смысла.

С другой стороны, _все_ читатели, которые имеют опыт чтения кода Go и инстинктивно распознают interface{} как свое лицо в зеркале, должны изучить и заново изучить каждый вариант Any , Object , T и сопоставьте их с такими вещами, как type Any interface{} , type Any map[interface{}]interface{} , type Any struct{} для каждого пакета.

Конечно, вы согласны с тем, что специфические для пакета имена для банальных идиом Go отрицательно сказываются на удобочитаемости?

Конечно, вы согласны с тем, что специфические для пакета имена для банальных идиом Go отрицательно сказываются на удобочитаемости?

Я согласен, но поскольку рассматриваемый пример (безусловно, наиболее частое возникновение этого antipatterrn, с которым я столкнулся) может быть выполнен без псевдонимов, я не понимаю, как этот пример относится к предложению для псевдонимов типов.

Тот факт, что анти-шаблон возможен без псевдонимов типов, означает, что мы уже должны научить программистов Go избегать его, независимо от того, могут ли существовать псевдонимы для безымянных типов.

И, фактически, псевдонимы типов позволяют постепенное удаление этого антипаттерна из кодовых баз, в которых он уже существует.

Рассмотреть возможность:

package antipattern

type Any interface{}  // not an alias

type Widget interface{
  Frozzle(Any) error
}

func Bozzle(w Widget) error {
  …
}

Сегодня пользователи antipattern.Bozzle застряли бы при использовании antipattern.Any в своих реализациях Widget , и нет способа удалить antipattern.Any с постепенным восстановлением. Но с псевдонимами типов владелец пакета antipattern может переопределить его следующим образом:

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

И теперь вызывающие абоненты могут постепенно переходить с Any на interface{} , позволяя сопровождающему antipattern в конечном итоге удалить его.

Я хочу сказать, что нет никакого оправдания псевдониму безымянных типов, поэтому
запрет на этот вариант будет по-прежнему указывать на непригодность
практика.

Напротив, разрешение псевдонима безымянных типов позволяет не один, а два
формы этого анти-паттерна.

В четверг, 2 февраля 2017 г., 16:34 Брайан Миллс [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 ). Наличие этого явного литерала типа может быть полезной документацией. Но в то же время может быть довольно неприятно повторять литерал одного и того же типа повсюду; и фактически будет препятствием для удобочитаемости. Возможность удобно говорить о IntSet а не о map[int]struct{} без привязки к этому и только IntSet определению, на мой взгляд, является плюсом. Вот где type IntSet = map[int]struct{} совершенно правильно.

Наконец, я хотел бы вернуться к https://github.com/golang/go/issues/18130#issuecomment -268411811, если вы его пропустили. Объявления неограниченного типа с использованием = на самом деле являются объявлением "элементарного" типа, и я рад, что они наконец-то появились в Go.

Возможно, type intSet = map[int]struct{} (не экспортируется) было бы лучшим способом использовать псевдонимы безымянного типа, но это похоже на область CodeReviewComments и рекомендуемых практик программирования, а не на ограничение функции.

Тем не менее, %T - удобный инструмент для просмотра типов при отладке или исследовании системы типов. Интересно, должен ли существовать подобный форматный глагол, включающий псевдоним? q.B = []int в примере @davecheney .

@nathany Как вы реализуете этот глагол? Информация о псевдониме отсутствует во время выполнения. (Что касается пакета reflect , псевдоним _ того же типа_, что и объект, которому он назначен.)

@bcmills Я подумал, что может быть так ... 😞

Я полагаю, что инструменты статического анализа и плагины редактора все еще присутствуют, чтобы помочь работать с псевдонимами, так что это нормально.

2 февраля 2017 г. в 17:01 «Натан Янгман» [email protected] написал:

Тем не менее,% T - удобный инструмент для просмотра типов при отладке или изучении
система типов. Интересно, должен ли существовать глагол подобного формата,
включает псевдоним? qB = [] int в @davecheney
https://github.com/davecheney , пример.

Я думаю, что лучшим решением будет добавить режим запроса к гуру, чтобы ответить на этот вопрос.
вопрос:

которые являются объявленными псевдонимами во всем GOPATH (или в данном пакете) для
этот данный тип в командной строке?

Меня не беспокоит злоупотребление псевдонимами безымянных типов, но потенциальные
дублированные псевдонимы одного и того же безымянного типа.

@davecheney Я добавил ваше предложение в раздел «Ограничения» резюме обсуждения вверху. Как и все ограничения, наша общая позиция заключается в том, что ограничения добавляют сложности (см. Примечания выше), и нам, вероятно, потребуется увидеть фактические доказательства широко распространенного вреда, чтобы ввести ограничение. Недостаточно изменить способ обучения го: любые изменения, которые мы вносим в язык, потребуют изменения способа обучения го.

Как отмечено в проектной документации и в списке рассылки, мы работаем над улучшенной терминологией, чтобы облегчить объяснения.

@minux , как указал @bcmills , информация о псевдонимах не существует во время выполнения (полностью фундаментально для дизайна). Невозможно реализовать «% T, включающий псевдоним».

2 февраля 2017 г., 20: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, довольно информативна. Спасибо за это.

Объясняя типы и преобразования типов, суслики сначала думают, что я говорю о псевдониме типа, вероятно, из-за знакомства с другими языками.

Какой бы ни была окончательная терминология, я мог бы представить себе введение псевдонимов типов перед именованными (брендированными) типами, тем более что объявление новых именованных типов, вероятно, произойдет после введения byte и rune в любую книгу или учебную программу. Однако я хочу помнить о стремлении @davecheney не поощрять

Для type intSet map[int]struct{} мы говорим, что map[int]struct{} - это _ нижележащий_ тип. Как мы называем обе стороны от type intSet = map[int]struct{} ? Псевдоним и тип с псевдонимом?

Что касается %T , мне уже нужно объяснить, что byte и rune приводят к uint8 и int32 , так что это не другой.

Во всяком случае, я думаю, что псевдонимы типов облегчат объяснение byte и rune . ИМО, проблема будет в том, чтобы знать, когда использовать именованные типы по сравнению с псевдонимами типов, а затем иметь возможность сообщить об этом.

@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, я подозреваю, что мы увидим 2-е издания нескольких книг по Go. 😉

Я регулярно обращаюсь к спецификации Go за принятой терминологией, поэтому мне очень любопытно, какие термины выбраны в итоге.

Нам действительно нужен новый термин для этих вновь созданных типов, потому что теперь у любого типа может быть имя.

Некоторые идеи:

• "выделенный" или "отличный" (например, можно отличить от других типов)
• "уникальный" (например, это тип, отличный от всех других типов)
• "бетон" (например, это сущность, существующая во время выполнения)
• "идентифицируемый" (например, тип имеет идентификатор)

@bcmills Мы думали о выделенных, уникальных, отличных, фирменных, цветных, определенных, не псевдонимах и т. д. типах. «Конкретный» вводит в заблуждение, потому что интерфейс также может быть раскрашен, а интерфейс является воплощением абстрактного типа. «Идентифицируемый» также кажется вводящим в заблуждение, потому что «struct {int}» идентифицируется так же, как и любой явно (не псевдоним) именованный тип.

Я бы не рекомендовал:

• «цветные» (в контексте, не связанном с программированием, фраза «цветные типы» несет в себе сильные коннотации расовых предубеждений)
• «без псевдонима» (это сбивает с толку, поскольку целью псевдонима может быть или не быть то, что раньше называлось «именованный тип»)
• "определенные" (псевдонимы тоже определены, они просто определены как псевдонимы)

«Фирменный» может сработать: он несет в себе коннотацию «типы как скот», но это не кажется мне изначально плохим.

Уникальные и уникальные варианты пока кажутся выдающимися.

Они просты и понятны без особого дополнительного контекста или знаний. Если бы я не знал различий, я бы, по крайней мере, имел общее представление о том, что они подразумевают. Я не могу сказать этого о других вариантах.

Как только вы выучите термин, это не имеет значения, но коннотативное имя позволяет избежать ненужных препятствий для усвоения различия.

Это определение аргумента о велосипеде. У Роберта есть ожидающий CL на https://go-review.googlesource.com/#/c/36213/, который кажется совершенно нормальным.

CL https://golang.org/cl/36213 упоминает об этой проблеме.

Я хочу снова поднять вопрос go fix .

Чтобы было ясно, что я не предлагаю «удалить» псевдоним. Может быть, это что-то полезное и подходящее для другой работы, это отдельная история.

ИМО очень важно, что заголовок посвящен движущемуся шрифту. Не хочу усложнять этот вопрос. Наша цель - иметь дело с своего рода изменениями интерфейса в проекте. Когда мы подходим к изменению интерфейса, неверно, что мы надеемся, что все пользователи будут использовать эти два интерфейса (старый и новый) как один и тот же в конечном итоге , и поэтому мы говорим «постепенное восстановление кода». Мы надеемся, что пользователи удалят / изменят использование старого.

Я до сих пор считаю инструмент лучшим методом для исправления кода, что-то вроде идеи, предложенной @ 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.Pointer без прямого импорта unsafe :

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 в пакет, который импортирует unsafe. Это может немного усложнить проверку программ на предмет небезопасности.

@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 -to- Pointer включает вызов функции, поэтому оно не соответствует ограничению пакета unsafe , которое " оба преобразования должны появляться в одном и том же выражении, и между ними должна быть только промежуточная арифметика ". Однако я подозреваю, что можно было бы построить эквивалентную действительную программу без импорта unsafe из main , сделав использование таких вещей, как reflect.SliceHeader .)

Похоже, что экспорт скрытого небезопасного типа - это еще одно правило, которое нужно добавить к аудиту.

Да, я хотел указать, что использование прямого псевдонима небезопасно. Указатель усложняет аудит кода, и этого достаточно, чтобы, надеюсь, этого никто не делал.

@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)
}

То есть в главном пакете я могу выполнять небезопасные арифметические операции, используя a.P даже если нет пакета unsafe и a.P не является псевдонимом. Это всегда было возможно.

Вы имеете в виду что-то еще?

Виноват. Я думал, что это не сработало. (У меня создалось впечатление, что специальные правила, применяемые к unsafe.Pointer, не будут распространяться на новые типы, определенные на его основе.)

Спецификация на самом деле не совсем ясна по этому поводу. Глядя на реализацию go / types, оказывается, что моя первоначальная реализация требовала именно unsafe.Pointer , а не только некоторый тип, который имел базовый тип unsafe.Pointer . Я только что нашел # 6326, когда я изменил go / types на совместимость с gc.

Возможно, нам следует запретить это для определений обычных типов, а также запретить псевдонимы unsafe.Pointer . Я не вижу веской причины для разрешения этого, и это ставит под угрозу явность импорта unsafe для небезопасного кода.

Я создал https://github.com/golang/go/issues/19306.

Это произошло. Я не думаю, что здесь что-то осталось.