LINUX.ORG.RU

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

 


0

10

За подробностями в Go-блог (blog.golang.org/why-generics), там есть ссылка на собственно драфт.

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

Синтаксически удалось обойтись введением всего одного нового ключевого слова contract для описания ограничений типа-значения (то есть для создания чего-то вроде метатипов).

В релизе появится всё это не скоро, в Go 2, срок выхода которого неизвестен. Go 1.13 появится на днях, 1.14 — в ноябре, к десятилетию первого публичного бета-релиза.

★★★

Пример функции для любого типа:

func Reverse (type T) (s []T) {
    first := 0
    last := len(s) - 1
    for first < last {
        s[first], s[last] = s[last], s[first]
        first++
        last--
    }
}
hbee ★★★ ()
Ответ на: комментарий от hbee

Вызвать можно с явным указанием типа, а можно предоставить выведение типа компилятору:

s := []string{"a","b","c"}
Reverse(int)(s)
Reverse(s)
hbee ★★★ ()
Ответ на: комментарий от hbee

Если тип-значение подходит не любой, в объявлении указывается имя контракта:

func IndexOf (type T Sequence) (s T, b byte) int {
    for i := 0; i < len(s); i++ {
        if s[i] == b {
            return i
        }
    }
    return -1
}
hbee ★★★ ()
Ответ на: комментарий от RazrFalcon

Так это шаблоны или дженерики?

Шаблоны в терминах C++.

hbee ★★★ ()
Ответ на: комментарий от hbee

Контракты можно объявлять двумя способами.

Первый — просто перечислить допустимые конкретные типы:

contract Sequence(T) {
    T string, []byte
}

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

hbee ★★★ ()
Ответ на: комментарий от hbee

Второй способ — объявить интерфейс (наподобие будущих концептов в C++):

contract Stringer(T) {
    T String() string
}

Здесь тип этого метатипа может применяться везде, где принимается интерфейс Stringer.

hbee ★★★ ()
Ответ на: комментарий от hbee

Вот так забавно объявляется контракт для всех типов, которые можно сравнивать:

contract Ordered(T) {
    T int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64, uintptr, float32, float64, string
}
hbee ★★★ ()

Дерьмо. Пойду напьюсь. Я им в твитор писал, что родовые типы не нужны, но они там видать говна поели.

kostyarin_ ()
Ответ на: комментарий от hbee

Структуры тоже могут быть обобщёнными:

type Tree (type E) struct {
    root *node(E)
}
type node (type E) struct {
    val         E
    left, right *node(E)
}
hbee ★★★ ()
Ответ на: комментарий от kostyarin_

они там видать говна поели

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

hbee ★★★ ()

Когда читал пару дней назад ― понял «что они хотят сделать», но не понял «почему именно так, а не иначе».

Deleted ()
Ответ на: комментарий от hbee

Даже определение методов удалось сделать не слишком перегруженным скобочками:

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

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

hbee ★★★ ()
Ответ на: комментарий от Deleted

почему именно так, а не иначе

Первый вариант (2016) был намного хуже. Сообщество подкинуло немало идей, и вот что-то получается.

hbee ★★★ ()
Ответ на: комментарий от hbee

Испытывают сильное давление сообщества.

Скорее всего все тривиально.
Разработчикам платят, а они «выдают на гора» /а то платит не будут/.

anonymous ()
Ответ на: комментарий от hbee

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

Задолбали. Каждый считает своим священным долгом кинуть свой авторитетный камень в C++. А несмотря на ваши прогнозы он живее всех живых.

rumgot ★★★★★ ()
Ответ на: комментарий от rumgot

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

Begemoth ★★★★★ ()
Последнее исправление: Begemoth (всего исправлений: 1)
Ответ на: комментарий от Begemoth

С++ очень сложный язык, но тут основной вклад внесло его раннее развитие в духе «а давайте запилим клевую фичу»

Да и другие языки развиваются также - «а давайте впердолим клевую фичу».

anonymous ()
Ответ на: комментарий от Begemoth

Сложный - да. Но выпады в стиле «разрушив язык, как c++» - субъективная хрень.

rumgot ★★★★★ ()
Ответ на: комментарий от rumgot

Задолбали

Ну, трольнул немного. Тема на лоре без упоминания C++ и Rust — деньги на ветер :). Мне тоже не нравится, когда иксперты походя называют Go «примитивным» (язык с развитыми возможностями ООП, CSP, рефлексией и unsafe, ага).

hbee ★★★ ()

В Go завезли generics, в Rust завезли async/await. Намечается коллизия

vertexua ★★★☆☆ ()
Ответ на: комментарий от hbee

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

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от hbee

Тема на лоре без упоминания C++ и Rust — деньги на ветер

Ставьте класс, кто помнит Qt vs Gtk+ или KDE vs Gnome. Сейчас все срать, всё в браузере

vertexua ★★★☆☆ ()
Ответ на: комментарий от vertexua

то волосы на спине шевелятся

1) Не у всех. 2) У кого где. 3) ?

anonymous ()

Специализация (как в C++) будет?

NeXTSTEP ★★ ()
Ответ на: комментарий от anonymous

Согласен, вон кто-то манку с комочками любит

vertexua ★★★☆☆ ()
Ответ на: комментарий от vertexua

Если что, то sorry /надеюсь ничего за «чистую монету» не приняли/.
Замолкаю - чтобы тему «не спугнуть».

anonymous ()
Ответ на: комментарий от hbee

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

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

На кой чёрт параметр в объявлении контрактов я так и не понял, зачем контракт с интефейсом когда есть обычный интерфейс, я тоже не понял.

WitcherGeralt ★★ ()
Ответ на: комментарий от hbee

язык с развитыми возможностями ООП

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

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

Ну и перегрузка операторов — очень важная штука, без которой ООП — мусор.

Она и без ООП хороша и с ООП.

anonymous ()
Ответ на: комментарий от NeXTSTEP

Специализация (как в C++) будет?

Нет (и перекрестился). Не дай Бог :).

hbee ★★★ ()
Ответ на: комментарий от WitcherGeralt

зачем контракт с интефейсом когда есть обычный интерфейс

Обычный интерфейс — рантайм. Контракт — компайлтайм.

hbee ★★★ ()
Ответ на: комментарий от hbee

Это хорошо. Одна из причин почему C++ такой переусложнённый.

NeXTSTEP ★★ ()
Ответ на: комментарий от WitcherGeralt

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

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

hbee ★★★ ()
Ответ на: комментарий от hbee

Да всё там будет с таким курсом. Утята продолжат верещать, а мудак Грисемер и иже с ним будут им потакать. Ждём исключения, классы, async / await и генераторы (каналы и горутины же нипанатяна). В итоге всё скатится в говно, а говно и так уже есть в виде джавы. Ну, короче, в итоге придётся всё выбросить и писать на плюсах, ибо хрен редьки не слаще.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

в итоге придётся всё выбросить

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

hbee ★★★ ()
Ответ на: комментарий от hbee

А потом есть план Б.

А я знаю какой.
https://www.youtube.com/watch?v=e6iSIG7yh5k Силы у меня не те, что прежде, но за 10 минут я вам ручаюсь. -Успеем добежать до канадской границы.

anonymous ()

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

anonymous ()
Ответ на: комментарий от WitcherGeralt

Единственный плюс.

С угловыми скобками читаемость лучше.

Ну и перегрузка операторов — очень важная штука, без которой ООП — мусор.

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

ox55ff ★★★ ()
Ответ на: комментарий от WitcherGeralt

Что же ты так уныло сливаешься? Ладно, пусть так.

ox55ff ★★★ ()
Ответ на: комментарий от ox55ff

Ну, я высказал мнение. Мне не нравится чейнинг, тебе нравится. О чём здесь спорить?

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

Ну, я высказал мнение. Мне не нравится чейнинг, тебе нравится. О чём здесь спорить?

Кстати хорошое суждение.
В магазине много прилавков с разными товарами ...
И в этот магазин ни кто бы не ходил если бы в нем было всего три нужных мне вида товара.

anonymous ()
Ответ на: комментарий от hbee

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

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

От перегрузки операторов вообще вреда больше, чем пользы: она бьёт по читаемости.

Опять... Читаемость определяется не фактом наличия перегрузки операторов. Читаемость или ее отсутствие - это комплексный результат. Например если мы имеем проверку на равенство двух объектов, то ты оспоришь, что вариант с перегрузкой оператора == проще?:


if (someObjeckFirst.isEqual(someObjectSecond))

if (someObjectFirst == someObjectSecond)

rumgot ★★★★★ ()
Последнее исправление: rumgot (всего исправлений: 1)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)