Только вот делать никто не хочет) А потеоретизировать это с удовольствием

у меня в принципе есть время на линтер сейчас, учитывая что я не женат ?

однако не так чтоб прям 8 часов в день

Ну вот два разработчика уже есть) в принципе можно начинать)

А там люди потянутся

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

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

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

ну сработает же только в одну сторону.

типичный пример апи которое никак не дружит - Unmarshal в json.

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

кстати этот вопрос до сих пор открыт. стоит ли implicitly конвертировать non-const в const

типичный пример апи которое никак не дружит - Unmarshal в json.

поясни

оно не идиоматично. оно вынуждает меня иметь мутабельный объект

оно не идиоматично. оно вынуждает меня иметь мутабельный объект

всё-равно не понял о чём ты

Невозможно иметь только иммутабельные структуры и сделать Unmarshall. Сейчас он принимает ссылку на структуру и изменяет ее содержимое. Это не дает вызывающей стороне иметь только иммутабельные структуры. Идиоматичным было бы вернуть новый объект (как передать при этом тип этого объекта остается вопросом)

оно не идиоматично. оно вынуждает меня иметь мутабельный объект

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

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

Почти, в java в таких случаях передают Class, а не инстанц.

иногда - инстанс.

Почти, в java в таких случаях передают Class, а не инстанц.

С инстансом тоже есть.

но мы же не собираемся превращать go в язык с чистыми функциями

иногда - инстанс.

я уверен где-то такая конечно есть

но мы же не собираемся превращать go в язык с чистыми функциями

от нас слава богу в этом плане мало что зависит

поэтому - линтер будет предупреждать о передаче указателя на const объект кудато, где мы не имеем контроля.

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

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

да, было бы приколаьно, но это уже тема про дженерики мол result, _ := Unmarshal<MyType>() если я не ошибаюсь))

не, это все еще можно делать без генериков

просто result := MyType{} был бы внутри Unmarshal, а не снаружи

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

проблема только то что он будет реально вербозным. Нужно будет reference типы обарачивать в alias типы, уфф..

поэтому - линтер будет предупреждать о передаче указателя на const объект кудато, где мы не имеем контроля.

Так тоже не сработает. Можно почитать про опыт котлин и их построения интеропа с джавой. Они отказались от явных проверок на границе в пользу оптимистичного сценария. Можно почитать тут - https://kotlinlang.org/docs/reference/java-interop.html#null-safety-and-platform-types

просто result := MyType{} был бы внутри Unmarshal, а не снаружи

ну это уже тогда на тему runtime cost (extra memory + CPU time) vs compile-time cost (of generics)

проблема только то что он будет реально вербозным. Нужно будет reference типы обарачивать в alias типы, уфф..

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

просто result := MyType{} был бы внутри Unmarshal, а не снаружи

сейчас таким-же образом устроен assert.IsType(t, ExpectedType{}, actual) в testify, но в тестах конечно пофиг лишний инстанс зафигарить

идея с комментом нравится мне больше

идея с комментом нравится мне больше

а идея с коментом возможно окажется очень некрасивой... хотя..

ну вот да, надо таки написать пропозал

идея с комментом нравится мне больше

func(ref /*const*/ * /*const*/ Object) уфф... тогда уж лучше так: type ObjectConst Object type ObjectPtrConst *ObjectConst func(refConst ObjectPtrConst)

"шо то хня, шо это хня"))))

func(ref /*const*/ * /*const*/ Object) уфф... тогда уж лучше так: type ObjectConst Object type ObjectPtrConst *ObjectConst func(refConst ObjectPtrConst)

вот что ты прицепился к этому const ref const *Obj

не надо такого никому

const ref - это вообще непонятно, зачем. это же по любому копия, навнешний мир не повлияет, хоть объизменяйся

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

большой плюс - их можно сделать уже сейчас

не надо такого никому

это мы ещё не выяснили на самом деле: https://github.com/romshark/Go-2-Proposal---Immutability#38-whats-the-difference-between-immutable-references-and-references-to-immutables Я пишу абзац "Discussion", там упомяну про облегчённый но ограниченный const pointer но увы, так просто взять и отрезать возможность создания мутабельного слайса немутабельных объектов и наоборот - просто не могу

а зачем может быть нужен мутабельный слайс иммутабельных объектов?

const ref - это вообще непонятно, зачем. это же по любому копия, навнешний мир не повлияет, хоть объизменяйся

constRef не позволит саму переменную аргумента в данном контексте мутировать

а зачем может быть нужен мутабельный слайс иммутабельных объектов?

ну как же. производительность

а зачем может быть нужен мутабельный слайс иммутабельных объектов?

ну блин, я не могу решать за всех, это эгоистично))

а зачем это нам? какой смысл переменую аргумента защищать?

ну блин, я не могу решать за всех, это эгоистично))

реши за себя. это вполне go way, как мы знаем

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

почему не можешь?

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

это В ПРИНЦИПЕ проблема иммутабельности засчёт линтера. Линтер не компилятор, у него нет прав по рукам бить, лицензию не выдали.

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

или даже и параметры, и переменные :)

вот будет счастие :)

а зачем это нам? какой смысл переменую аргумента защищать?

такой же какой и в иммутабельных переменных по сути. Аргумент тоже переменная из scope'а функции

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

ох ёшкин... это прям отличная антиреклама пропосала будет

а зачем это нам? какой смысл переменую аргумента защищать?

тут смысл не том, что ты что-то сломаешь, а в том, что если ты ее меняешь, то скорее всего, ты ожидаешь чего-то другого

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

например - изобрели ошибку, от которой такая конструкция защитит

например - изобрели ошибку, от которой такая конструкция защитит

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

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

я могу порекомендовать почитать вот это - http://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbout.html И эту часть в частности. http://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbout.html#preventing-errors-with-functional-programming

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

https://github.com/qbeon/webwire-go/blob/master/serveHttp.go вот например конкретно мой случай: меня все кодоанализаторы уже своим варнингом о том, что функция превышает макс. уровень когнитивной сложности (branching) и размер (LOC) но когда я пытался её рефакторнуть дабы разбить на более малые функции возникали проблемы и я психовал и просто бросал её оставив как есть. В таких случаях иметь иммутабельные переменные довольно удобно, потому-что со временем можешь поменять то что менять изначально не стоитло.. а так тебя компилятор/линтер за лапу цап! Ап, низзя X в этом контексте менять и ты начинаешь вспоминать "а зачем я тогда делал её иммутабельной..... ааа!"

https://github.com/qbeon/webwire-go/blob/master/serveHttp.go вот например конкретно мой случай: меня все кодоанализаторы уже своим варнингом о том, что функция превышает макс. уровень когнитивной сложности (branching) и размер (LOC) но когда я пытался её рефакторнуть дабы разбить на более малые функции возникали проблемы и я психовал и просто бросал её оставив как есть. В таких случаях иметь иммутабельные переменные довольно удобно, потому-что со временем можешь поменять то что менять изначально не стоитло.. а так тебя компилятор/линтер за лапу цап! Ап, низзя X в этом контексте менять и ты начинаешь вспоминать "а зачем я тогда делал её иммутабельной..... ааа!"

Это хороший пример, да. По сути иммутабельность это часть referential transparency, которая позволяет читать и изменять программы значительно проще. Ссылка банальна - https://en.wikipedia.org/wiki/Referential_transparency

Это хороший пример, да. По сути иммутабельность это часть referential transparency, которая позволяет читать и изменять программы значительно проще. Ссылка банальна - https://en.wikipedia.org/wiki/Referential_transparency

в яблочко

хорошо

func(ref /*const*/ * /*const*/ Object) уфф... тогда уж лучше так: type ObjectConst Object type ObjectPtrConst *ObjectConst func(refConst ObjectPtrConst)

поэтому собственно и иммутабельные переменные и иммутабельные аргументы

а теперь изобретите, зачем нужна иммутабельная ссылка на мутабельный объект

ERROR: S client not available

а теперь изобретите, зачем нужна иммутабельная ссылка на мутабельный объект

я это буквально сегодня добавил в документ: When we need a pointer to be immutable to prevent it from pointing to anything other than a certain object, which should be mutable though т.е. сама по себе сущность может меняться внутри, а вот другой объект заместо неё вставить уже нельзя

а теперь изобретите, зачем нужна иммутабельная ссылка на мутабельный объект

чтобы описать глобальный мутабельный стейт? Например, кеш

чтобы описать глобальный мутабельный стейт? Например, кеш

не с этим ли мы боремся?!

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

не с этим ли мы боремся?!

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

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

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

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

в языке как-то принято что говорят как жить сверху

в языке как-то принято что говорят как жить сверху

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

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

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

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

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

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

I mean.... "who needs 4 billion IP addresses anyway?..."

Опять же позиция авторов языка проста. Дав что-то забрать это нельзя. Можно посмотреть во что превратился с++. Их задача это предотвратить.

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

Да я только за. И за консты и за тайпклассы. :)

а с моим предложением правило без исключений распространяется на все типы. иммут и мут типы это как Материя и Антиматерия.. они практически одинаковы, за исключением заряда Object это тип []Object это тоже тип const []Object же это исключение тогда, потому-что на самом деле это const [] const Object ибо не понятно кто иммено имутабелен, слайс? или тип в слайсе? я лично против таких исключений из правила, даже ради упрощённого синтаксиса, больше неясности вносит чем символов экономит

Я думаю авторы языка как раз не против. Посмотри на map.

Я думаю авторы языка как раз не против. Посмотри на map.

всмсл?)

всмсл?)

всмысле генерики можно, но не всем.

всмысле генерики можно, но не всем.

у это таки немного другая тема

Есть в c# такой keyword как readonly. Оставлю это здесь)

Есть в c# такой keyword как readonly. Оставлю это здесь)

в Go его не будет, никогда либо const, либо mut с иммутабельностью по умолчанию в Go2 через лет эдак 10

в Go его не будет, никогда либо const, либо mut с иммутабельностью по умолчанию в Go2 через лет эдак 10

ronly, ro.

Просто пища умам.

ronly, ro.

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

Парни, а что гугл за DI выпустил? Кто-нибудь использовал?

мы тут решили как то

что самописный на структуре - the best

?

Мы используем fx, но только не прикольно в runtime ловить null pointer. У di гугловского он упадет во время компиляции, если мне изменяет память..)

хм