Опубликован почти окончательный драфт генериков в Go

Каким боком операторы относятся к ООП?

Таким, что для разных классов один и тот же оператор имеет разный смысл. Например сложение строк и сложение векторов(не std::vector, а векторов из математики).

когда иксперты походя называют Go «примитивным»

Так он и есть примитивный. Привет из прошлого века.

перегрузки тоже завезут?

В целом мне нравится. Нет этих мерзких угловых скобок :).

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

Генерики семантически будут наподобие шаблонов C++, т.е. не boxed (как в Java), а value: компилятор будет генерировать копии с конкретными типами.

Шёл 2019 год~

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

Надеюсь, несколько лет всё же продержимся. А потом есть план Б.

Переход на Оберон?

Чтобы человеку проще читать было.

Таким, что для разных классов один и тот же оператор имеет разный смысл.

Для этого ООП не нужен, перегрузка операторов есть и в haskell и в OCaml (не затрагивая объекты) и в rust.

И, конечно, самим интересно, можно ли так расширить язык, не разрушив его (как произошло с C++)

Как бы шаблоны создали С++, а не разурушили.

Тем не менее в рамках ООП перегрузка операторов удобная и полезная возможность.

в Го вообще не нужны дженерики. Зачем они там, писать всякие обобщенные алгоритмы? Так для алгоритмов уже есть C++, раст и прочие с мощными системами типов, зеро кост и прочими векторизациями.

А во всех остальных случаях - объявить тип как interface{} и сконвертировать его в рантайме во что надо ну вообще не проблема.

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

А разве не всегда можно определить на этапе компиляции что тип реализует нужный интерфейс?

Нет. Интерфейсы предназначены для рантайма. Скажем, io.Writer во время компиляции не знает, какой конкретный объект ему передадут.

Еще мне не понятно зачем при вызове параметризированной функции указывать явно тип

Это как раз опционально. Можно указать, можно не указывать (компилятор выведет типы). Всё как в C++.

Как бы шаблоны создали С++, а не разрушили.

Если бы они не оказались тьюринг-полным языком сами по себе, это было бы ещё полбеды. С открытиями Александреску в C++ стало возможным творить невообразимые вещи. А если что-то в языке возможно сделать — это непременно будет делаться. И это придётся сопровождать.

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

Очень верно. Тем не менее развиваться и меняться языку нужно, как и всему живому в нашем мире.

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

Да вроде всё хорошо, просто к типу ресивера добавился в скобках шаблонный параметр. Остально как было.

func (t *Tree(E)) Contains(v E) bool {
    return *t.find(e) != nil
}

С открытиями Александреску в C++ стало возможным творить невообразимые вещи

И это позволило решать на С++ задачи, которые в «си с классами» были немыслимы

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

И это позволило решать на С++ задачи, которые в «си с классами» были немыслимы

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

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

Тут как раз без проблем. Рефлексия в рантайме, она имеет дело с уже инстанцированными типами. Единственно, reflect.Type.String() от шаблонного типа вернёт что-то вроде «Tree(float64)».

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

нечеловеческий нечитаемый код

Полегче с городскими легендами.

Tree - generic тип с параметром E?

Т.е. в нормальном синтаксисе что-то вроде:

fun Contains<E>(t: Tree<E>, v: E): bool

func (t *Tree(E)) Contains(v E) bool {
    return *t.find(e) != nil
}

Почему это говно на 50% состоит из синтаксического мусора даже в таком примитивном примере?

func (t *Tree(E))

Зачем нужен этот мусор. Что это за нахрен? Зачем оно? Что это за нелепое t - это что? Название функции? Аргумент?

Contains(v E)

Это что?

*t.find(e) != nil

Это что? Нахрена тут звёзды? nil? Что за херня?

перегрузка операторов есть и в haskell и в OCaml (не затрагивая объекты) и в rust.

Адепт врёт. Ничего там нету.

Нет этих мерзких угловых скобок

из-за дженериков код всегда превращается в нечитаемое говно

V

Так вот кто лулзы для /r/pcj генерит.

Плюсую этого оратора. Сам в Go с первых стабильных версий. Но вот эта вот реализация дженериков - это обосрамс какой-то. Если пилят вторую версию, нужно, наверное, делать нормально и волноваться больше о consistency, а не backward compatibility (который всё равно ломают).

Как будто бы с угловыми скобками он становится читаемым. Больше, меньше. Вот, например, генерик-фигерик

Т<ВоюМать>
Т(ВоюМать)

Первое похоже на сравнение. Второе на вызов функции. Оба варианта так себе. Есть нормальны, поцанский, вариант

Тэ из рода Серых Псов.

Вот тут сразу всё видно и понятно.

Когда в Rust завезут нормальный синтаксис?

Вот тут сразу всё видно и понятно.

А покажи определение функции примерно с таким синтаксисом. Наверняка будет многословное жиденькое.

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

Это стукач-тред, братан, здесь бесполезно что-то писать.

будут наподобие шаблонов C++

Всё, приплыли! Теперь и в голанге начнётся «ехал шаблон, через шаблон в шаблон». Коготок увяз — всей птичке пропасть!

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

Чёт не душевные какие-то черновичёчки. Страшно смотреть. Может всё-таки не надо.

Вот что за манера, из двух миров брать худшее.

Шаблоны могут частичную специализацию, но ломаются на рекурсии, упираясь в бесконечное развёртывание. Дженерики могут рекурсию, но не могут частичную специализацию. А тут — ни нашим, ни вашим. Раста обкурились?

В какую рекурсию ты там собрался мочь? Показывай. Для генериков.

Вообще-то специализация/частичная специализация — это крутые фичи. Как и переопределение операторов.
Если всего этого не будет. Голанг опять будет неидеален и критикуем.
Ну зато может будет повод разрабам пилить бюджет гугла и выпускать версии 3.0, 4.0 и т.д. где постепенно будут эти фичи вводить.

Ну что, уже решили? Годнота или как обычно? Избавиться ли го от печати примитивизма 70х годов?

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

Generic с использованием шаблонов ...?
Излюбленная тема программистов, находящихся в третьей палате психдиспансера г.Дураковка.

Владимир

Годнота или как обычно?

В сочетании с CPUQuota

А разве не всегда можно определить на этапе компиляции что тип реализует нужный интерфейс?

Нет. Интерфейсы предназначены для рантайма. Скажем, io.Writer во время компиляции не знает, какой конкретный объект ему передадут.

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

func foo(type T io.Writer)(t T, b []byte) (int, error) {
    return t.Write(b)
}

foo(os.Stdout, []byte("Hello, World.")) // ok
var a int
foo(a, []byte("Hello, World.")) // compilation error: variable of int type does not satisfy io.Writer interface

Это как раз опционально. Можно указать, можно не указывать (компилятор выведет типы). Всё как в C++.

Ну тогда нормально.

пока что исследование проводится

«Исследование», ЛМАО. С 1970го недостаточно «исследований» провели, либо это были неправильные «исследования». А с 2009го недостаточно реализаций применимо к Go наобсуждали. Такими темпами нужно ещё 50 лет на «исследования» и 10 на обсуждения.

Ну тебе виднее.

func (t *Tree(E))

Это ресивер, делает обычную функцию «методом». Это как self/this, только в явном виде и с именем t

Contains(v E)

Название метода

*t.find(e) != nil

Это звезда - операция разыменования. Очевидно что кто-то сделал метод find у которого value receiver, а возвращает этот метод указатель на году, или nil, если нет такого значения.

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

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

Потому что нет встроенного механизма, позволяющего назначить операторы +, -, * и т.д. для произвольных типов. Соответственно невозможно определить интерфейс для какого-нибудь int, uint и пр., они так и остаются builtin special cases. Отсюда (в драфте) костыль с контрактом и простынёй из int, int32, int8, int16, uint, uint32, uint8, uint16… Если навесить это на интерфейсы, тогда непонятно как те должны себя вести в ряде случаев (например, когда простыня контрактная, а интерфейс рантаймный).

Тут ты прав.

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

Нужно было отсюда начинать https://github.com/golang/go/wiki/Go2GenericsFeedback

Заголовок темы не много «сбил с толку».