Алексей
mutable key для мапы я бы вообще запретил
Алексей
совсем
Алексей
это вообще не имеет никакого смысла
Savely
Хер знает, меня эти пробелы напрягают, тип читается не цельно, разбивая себя на ненужные блоки. В Go2 такое точно не нужно, нужно искать другие решения.
Алексей
ну тогда лучше mut в Go2
Алексей
чтоб иммутабельность было проще писать, чем мутабельность
Алексей
ну ещё у Pawel от этого неслабо бомбанёт, тоже плюс
Savely
ну тогда лучше mut в Go2
Не лучше, а это единственное решение. У людей могут быть переменные с название mut, это поломает совместимость. Роман же не просто так const выбрал.
Roman
mutable key для мапы я бы вообще запретил
это ты бы запретил, а я не имею права решать за всех несколько миллионов программистов пишущих на Go.
Roman
это вообще не имеет никакого смысла
если сможешь это научно обосновать то может быть я внесу изменения в proposal, но пока не вижу смысла.
Алексей
Не лучше, а это единственное решение. У людей могут быть переменные с название mut, это поломает совместимость. Роман же не просто так const выбрал.
само включение иммутабельности по умолчанию уже ломает обратную совместимость неслабо
Roman
Хер знает, меня эти пробелы напрягают, тип читается не цельно, разбивая себя на ненужные блоки. В Go2 такое точно не нужно, нужно искать другие решения.
другое решение только мануальное копирование. А оно громоздкое, опасное и ещё менее читабельное.
нет других вариантов кроме как ходить по лезвию.
Savely
если сможешь это научно обосновать то может быть я внесу изменения в proposal, но пока не вижу смысла.
Разве сейчас ключи мутабельны?
Алексей
если сможешь это научно обосновать то может быть я внесу изменения в proposal, но пока не вижу смысла.
я честно говоря не знаю как там мапа устроена в Go, но вообще если это всё таки хэш мапа, то там мутабельность ключей приводит к некорректной работе мапы
Savely
другое решение только мануальное копирование. А оно громоздкое, опасное и ещё менее читабельное.
нет других вариантов кроме как ходить по лезвию.
Я про то, как это синтаксически оформить.
Savely
Дефолтная иммутабельность поломает даже примитивный пример уровня хелло ворлд
Roman
Не лучше, а это единственное решение. У людей могут быть переменные с название mut, это поломает совместимость. Роман же не просто так const выбрал.
я пишу как о предложение для Go 1 так и для Go 2
Daniel
а?!
Roman
А как я могу мутировать существующий ключ?
ключём может быть указатель на структуру, и она окажется мутабельной.
good old pointer aliasing
Алексей
тогда сам указатель будет ключом или структура?
Savely
ключём может быть указатель на структуру, и она окажется мутабельной.
good old pointer aliasing
Блет, ну в теории да. Я просто даже не видел примеров когда ключами бывают сложные структуры.
Алексей
но сам указатель не получится мутировать
Алексей
то есть ключ фактически иммутабельный (ну в самой мэпе)
Roman
но сам указатель не получится мутировать
сам то указатель нет, а вот то что за ним к сожалению да
Алексей
но мапа же по указателю будет сравнивать?
Roman
то есть ключ фактически иммутабельный (ну в самой мэпе)
это называется shallow immutability, и не решает shared mutable state through pointer aliasing
Daniel
ключ иммутабельный, потому, что он копия оригинала
Roman
но мапа же по указателю будет сравнивать?
дело в том что у нас есть range over map, и там можно мутировать ключ
Илья
Roman
ключ иммутабельный, потому, что он копия оригинала
копия указателя это 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
Daniel
тем не менее, ключ у мапы иммутабельный
Roman
тем не менее, ключ у мапы иммутабельный
сам ключ да, но если ключ это указатель то... хьюстом, у нас проблемы.
Илья
https://play.golang.org/p/3E4MZhZFzyy
Илья
давайте с примерами
Илья
что, где, какие ключи, где у вас там что
L
сам то указатель нет, а вот то что за ним к сожалению да
не всегда к сожалению.. Делал я счетчики с множемством параметров, где в качестве ключа мапы был указатель на объект (условно юзера). Этот объект мог в процессе рассчетов меняться/дополняться.
Aleksandr
не всегда к сожалению.. Делал я счетчики с множемством параметров, где в качестве ключа мапы был указатель на объект (условно юзера). Этот объект мог в процессе рассчетов меняться/дополняться.
так он и пишет - указатель не мутирует, объект за ним мутирует
L
так он и пишет - указатель не мутирует, объект за ним мутирует
я про "к сожалению", котороый не к сожалению)
Илья
ну так для этого и кладут указатель, сожаления я не понимаю
Roman
L
ии...? что ты хочешь этим сказать? 🙂
как я понял, вы преподносите это как проблему, но это же не проблема
Roman
как я понял, вы преподносите это как проблему, но это же не проблема
это может быть проблемой, но не обязательно, зависит от кейса.
если ты хочешь защититься от мутабельности ключа наверняка, то данный концепт даёт тебе такую возможность. Кому нужна иммутабельность которая работает везде заисключением ключей map'ы?
immutability это про типы. Типы могут быть иммутабельными, будь то переменная, поле структуры, возвратный значение функции, ресивер или ключ мапы
Anonymous
это может быть проблемой, но не обязательно, зависит от кейса.
если ты хочешь защититься от мутабельности ключа наверняка, то данный концепт даёт тебе такую возможность. Кому нужна иммутабельность которая работает везде заисключением ключей map'ы?
immutability это про типы. Типы могут быть иммутабельными, будь то переменная, поле структуры, возвратный значение функции, ресивер или ключ мапы
Ключи мапы как раз таки должны быть иммутабельны, ты перепутал
Anonymous
Да и значения тоже
Anonymous
Хорошо бы
Anonymous
Ну или я не так понял мысль
Daniel
а и значения мапы иммутабельны
Roman
Ключи мапы как раз таки должны быть иммутабельны, ты перепутал
ключи могут быть reference типами и в этом вся проблема
Daniel
нет способв его модифицировать, иначе как вынуть и положить
Daniel
ключ мапы - *Person
Daniel
то, на что он указывает - вообще не участвует никак в работе с мапой
Daniel
ключ - иммутабельный
Igor
ребята, подскажите, как сделать так, чтобы я мог результат sql запроса сосканить в собственную структуру?
Roman
ключ - иммутабельный
давайте выясним что мы имеем ввиду под ключём?
ясное дело что значение ключа в данном случае это указатель, 8 байт. Однако указатель это reference type. Reference type предоставляет интерфейс к иному значению. Следственно ключ мапы в моём понимани это как сам указатель так и то, на что он указывает.
Есть случаи, когда тебе пофиг меняется ли то на что указывает указатель или нет. Но иногда, тебе нужно это предотвратить. И то и то возможно в нынешнем proposal'е
Илья
если ты кладешь указатель в мап, то ты получаешь ровно то, что хочешь, мап с указателями
Daniel
> Следственно ключ мапы в моём понимани это как сам указатель так и то, на что он указывает.
а ключ мапы - это то, из чего посчитан хеш, и что используется в операторе == при работе с ячейками, для которых произошла коллизия хеша
не надо изобретать собственную терминологию...
Roman
Эт не проблема
если из условной билиотеки packagex тебе возвращают иммутабельную reference на объект: * const packagex.Person и ты хочешь использовать его в качестве ключа, тогда map[*packagex.Person]bool не сойдёт, потому-что компилятор будет ругаться что типы не совместимы и правильно сделает.
автор packagex не зря запретил тебе мутировать packagex.Person, на то есть причины, и убирать эту защиту в for range мапы это нонсенс, это ломает всю концепцию иммутабельности.
Stanislav
Savely
> Следственно ключ мапы в моём понимани это как сам указатель так и то, на что он указывает.
а ключ мапы - это то, из чего посчитан хеш, и что используется в операторе == при работе с ячейками, для которых произошла коллизия хеша
не надо изобретать собственную терминологию...
Коллизии такое частое явление?
Igor
я думал может какой-то интерфейс структуре применить и всё
Roman
если из условной билиотеки packagex тебе возвращают иммутабельную reference на объект: * const packagex.Person и ты хочешь использовать его в качестве ключа, тогда map[*packagex.Person]bool не сойдёт, потому-что компилятор будет ругаться что типы не совместимы и правильно сделает.
автор packagex не зря запретил тебе мутировать packagex.Person, на то есть причины, и убирать эту защиту в for range мапы это нонсенс, это ломает всю концепцию иммутабельности.
👆🏻@onokonem собственно вот причина почему это надо
Roman
> Следственно ключ мапы в моём понимани это как сам указатель так и то, на что он указывает.
а ключ мапы - это то, из чего посчитан хеш, и что используется в операторе == при работе с ячейками, для которых произошла коллизия хеша
не надо изобретать собственную терминологию...
т.е. я согласен с тем что map[const *Person]bool это не особо нужно, указатель и так немутабельный, единственный эффект будет в том, что при проходе for range по мапе key нельзя будет изменить, в него нельзя будет ничего присвоить в теле for.
однако что действительно важно это map[* const Person]bool, пояснение сверху
Igor
