а, я думал и mut и const вместе

mut как mutability qualifier const для констант

ну тогда лучше mut в Go2

чтоб иммутабельность было проще писать, чем мутабельность

ну ещё у Pawel от этого неслабо бомбанёт, тоже плюс

ну тогда лучше mut в Go2

Не лучше, а это единственное решение. У людей могут быть переменные с название mut, это поломает совместимость. Роман же не просто так const выбрал.

mutable key для мапы я бы вообще запретил

это ты бы запретил, а я не имею права решать за всех несколько миллионов программистов пишущих на Go.

это вообще не имеет никакого смысла

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

Не лучше, а это единственное решение. У людей могут быть переменные с название mut, это поломает совместимость. Роман же не просто так const выбрал.

само включение иммутабельности по умолчанию уже ломает обратную совместимость неслабо

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

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

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

Разве сейчас ключи мутабельны?

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

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

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

Я про то, как это синтаксически оформить.

Дефолтная иммутабельность поломает даже примитивный пример уровня хелло ворлд

Не лучше, а это единственное решение. У людей могут быть переменные с название mut, это поломает совместимость. Роман же не просто так const выбрал.

я пишу как о предложение для Go 1 так и для Go 2

Разве сейчас ключи мутабельны?

конечно

конечно

А как я могу мутировать существующий ключ?

а?!

А как я могу мутировать существующий ключ?

ключём может быть указатель на структуру, и она окажется мутабельной. good old pointer aliasing

тогда сам указатель будет ключом или структура?

ключём может быть указатель на структуру, и она окажется мутабельной. good old pointer aliasing

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

тогда сам указатель будет ключом или структура?

указатель в качестве ключа мапы

но сам указатель не получится мутировать

то есть ключ фактически иммутабельный (ну в самой мэпе)

но сам указатель не получится мутировать

сам то указатель нет, а вот то что за ним к сожалению да

но мапа же по указателю будет сравнивать?

сам то указатель нет, а вот то что за ним к сожалению да

а мапа не по содержимому.

то есть ключ фактически иммутабельный (ну в самой мэпе)

это называется shallow immutability, и не решает shared mutable state through pointer aliasing

ключ иммутабельный, потому, что он копия оригинала

но мапа же по указателю будет сравнивать?

дело в том что у нас есть range over map, и там можно мутировать ключ

ключ иммутабельный, потому, что он копия оригинала

копия указателя это pointer aliasing и по прежнему mutable shared state... я писал о похожем gotcha вот здесь: https://github.com/romshark/Go-2-Proposal---Immutability#46-why-do-we-need-immutable-receivers-if-we-already-have-copy-receivers

тем не менее, ключ у мапы иммутабельный

тем не менее, ключ у мапы иммутабельный

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

https://play.golang.org/p/3E4MZhZFzyy

давайте с примерами

что, где, какие ключи, где у вас там что

сам то указатель нет, а вот то что за ним к сожалению да

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

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

так он и пишет - указатель не мутирует, объект за ним мутирует

так он и пишет - указатель не мутирует, объект за ним мутирует

я про "к сожалению", котороый не к сожалению)

ну так для этого и кладут указатель, сожаления я не понимаю

давайте с примерами

https://play.golang.org/p/gjRRW25Jbmf

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

ии...? что ты хочешь этим сказать? ?

ии...? что ты хочешь этим сказать? ?

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

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

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

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

Ключи мапы как раз таки должны быть иммутабельны, ты перепутал

Да и значения тоже

Хорошо бы

Ну или я не так понял мысль

а и значения мапы иммутабельны

Ключи мапы как раз таки должны быть иммутабельны, ты перепутал

ключи могут быть reference типами и в этом вся проблема

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

ключи могут быть reference типами и в этом вся проблема

нет, не могут.

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

есть, пройтись по мапе

https://play.golang.org/p/gjRRW25Jbmf

??@onokonem

нет, не могут.

ну не будешь же ты отрицать компилирующийся работающий код сверху)

ключ мапы - *Person

то, на что он указывает - вообще не участвует никак в работе с мапой

ключ - иммутабельный

ключ - иммутабельный

+

ключи могут быть reference типами и в этом вся проблема

Эт не проблема

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

ключ - иммутабельный

давайте выясним что мы имеем ввиду под ключём? ясное дело что значение ключа в данном случае это указатель, 8 байт. Однако указатель это reference type. Reference type предоставляет интерфейс к иному значению. Следственно ключ мапы в моём понимани это как сам указатель так и то, на что он указывает. Есть случаи, когда тебе пофиг меняется ли то на что указывает указатель или нет. Но иногда, тебе нужно это предотвратить. И то и то возможно в нынешнем proposal'е

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

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

ERROR: S client not available

Эт не проблема

если из условной билиотеки packagex тебе возвращают иммутабельную reference на объект: * const packagex.Person и ты хочешь использовать его в качестве ключа, тогда map[*packagex.Person]bool не сойдёт, потому-что компилятор будет ругаться что типы не совместимы и правильно сделает. автор packagex не зря запретил тебе мутировать packagex.Person, на то есть причины, и убирать эту защиту в for range мапы это нонсенс, это ломает всю концепцию иммутабельности.

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

jmoiron/sqlx

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

Коллизии такое частое явление?

jmoiron/sqlx

шо, рефлект?..

шо, рефлект?..

Есесна

я думал может какой-то интерфейс структуре применить и всё

если из условной билиотеки packagex тебе возвращают иммутабельную reference на объект: * const packagex.Person и ты хочешь использовать его в качестве ключа, тогда map[*packagex.Person]bool не сойдёт, потому-что компилятор будет ругаться что типы не совместимы и правильно сделает. автор packagex не зря запретил тебе мутировать packagex.Person, на то есть причины, и убирать эту защиту в for range мапы это нонсенс, это ломает всю концепцию иммутабельности.

??@onokonem собственно вот причина почему это надо

я думал может какой-то интерфейс структуре применить и всё

reform

reform

спасибо, погляжую

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

т.е. я согласен с тем что map[const *Person]bool это не особо нужно, указатель и так немутабельный, единственный эффект будет в том, что при проходе for range по мапе key нельзя будет изменить, в него нельзя будет ничего присвоить в теле for. однако что действительно важно это map[* const Person]bool, пояснение сверху

https://github.com/cridenour/go-postgis

да, думаю стоит переименовать proposal в "Immutable Types"

у point реализован метод Scan - https://github.com/cridenour/go-postgis/blob/master/point.go#L47, поэтому оно умеет перевариваться в Scan

у point реализован метод Scan - https://github.com/cridenour/go-postgis/blob/master/point.go#L47, поэтому оно умеет перевариваться в Scan

Вот я не понимаю как это работает. Если у типа есть метод Scan, то как это связано с тем, что над переменной этого типа производится действие Scan ?

Вот я не понимаю как это работает. Если у типа есть метод Scan, то как это связано с тем, что над переменной этого типа производится действие Scan ?

смотрите в доку https://golang.org/pkg/database/sql/#Rows.Scan, по клику на имя функции вам даже исходники откроются

https://golang.org/src/database/sql/convert.go#L209

https://golang.org/src/database/sql/convert.go#L209

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

вы передаете указатель на объект в функцию scan объекта rows, которая внутри вызывает функцию convertAssign, которая проверяет, реализует ли переданное значение интерфейс dest.(Scanner) b

и если да, то вызывает его, чего вы не понимаете?

вы передаете указатель на объект в функцию scan объекта rows, которая внутри вызывает функцию convertAssign, которая проверяет, реализует ли переданное значение интерфейс dest.(Scanner) b

Вот этого я и не понимал. Спасибо.

и если да, то вызывает его, чего вы не понимаете?

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

extends, например

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

Нет, это мне понятно.

Окей)

У нас есть стикеры группы?

Почему болгарские?

стикера сабжа есть