даже у Go был больше промежуток вроде как.

не следил подробно, но Go?

го хайпится только последний год

А, это в блоке вторая строка?

чё?

го хайпится только последний год

чуть раньше все же.

Но Go больше лет.

ну ок, пусть 2 года

и он проще.

чё?

Ну, вторая строка — типа в блоке?

а ему 7 лет

Ну, вторая строка — типа в блоке?

нет

а еще он проще.

просто создаётся новая переменная

с таким же именем

wtf? =)

это и называется затенение

wtf? =)

у тебя в блоке есть переменная x, и снаружи есть переменная x.

у тебя в блоке есть переменная x, и снаружи есть переменная x.

неееет

что нет?

Я думал, такое можно делать только в блоке, если есть переменная снаружи.

что нет?

я же ему говорю, в моём примере нет никакого блока

а, ну в твоем нету да.

Охохо

я кстати к приведению типов через затенение сам пришел, просто попробовал можно ли так делать или нет. Оказалось можно.

И толку тогда от иммутабельности, если переменную можно затенить в том же блоке, где она объявлена? о.0

Обычно в расте если задаешь вопрос "можно ли так делать" то чаще ответ нет чем да.

И толку тогда от иммутабельности, если переменную можно затенить в том же блоке, где она объявлена? о.0

иммутабельность-то не нарушается

И толку тогда от иммутабельности, если переменную можно затенить в том же блоке, где она объявлена? о.0

У тебя две разные переменные с одинаковым именем

старая то не мутировалась

старую переменную никто не мутировал

Чёрт. =)))

Ну это понятно.

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

Но высокоуровневый смысл в том, что ты пишешь мутабельный эээ код. =)

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

Но высокоуровневый смысл в том, что ты пишешь мутабельный эээ код. =)

нет

но тут лучше спросить тех кто получше шарит.

Но высокоуровневый смысл в том, что ты пишешь мутабельный эээ код. =)

щито

попробуй на таком мутабельном коде цикл организовать

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

Ну, я не парился над формулировкой.

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

Ну, я не парился над формулировкой.

а зря.

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

А... Ну это уже лучше.

и нельзя изнутри блока менять/затенять/... то что снаружи

т.е.

менять вроде можно, не?

ток оно перемещается

и нельзя изнутри блока менять/затенять/... то что снаружи

Ну, это было бы тогда уж совсем...

let mut x = 0; for i in 0..10 { x += 1; // всё норм } против let x = 0; for i in 0..10 { let x = x + 1; // затенённое значение остаётся внутри блока }

менять вроде можно, не?

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

в первом варианте мутабельность, во втором - затенение

let mut x = 0; for i in 0..10 { x += 1; // всё норм } против let x = 0; for i in 0..10 { let x = x + 1; // затенённое значение остаётся внутри блока }

10 аллокаций

или скок там

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

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

что значит сайд эффект?

поменял - владение передал

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

а чего тут смиряться, если это нормально

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

поменял - владение передал

Вот с пониманием этого проблемы пока.

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

приведение типа это хороший юзкейс на мой взгляд

Вот с пониманием этого проблемы пока.

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

https://github.com/Fedcomp/rconcmd/blob/master/src/srcds/rcon/packet.rs#L52 Вот пример

осторожно, нубокод

@bigslycat понимаешь, разницы между следующими кусками кода семантически нет, только во втором случае ты уже не можешь использовать старые значения после затенения: let x0 = foo(); let x1 = x0.bar(); let x2 = x1.baz(); и let x = foo(); let x = x.bar(); let x = x.bax();

опасно для жизни.

в общем я тоже думал что затенение вредно, пока сам не столкнулся.

Теперь я обожаю эту штуку, ОСОБЕННО в статически типизированных языках.

иначе был бы геморой вроде net_type = , net_type1 =

Ну, если говорить о JS, то у меня там линтер запрещает: 1) Юзать мутабельные переменные, если значение никем не меняется. Да и кейс мутабельности просто почти отсутствует. 2) Затенять переменные. Создавай переменную с другим именем. Иначе потом запутаешься. 3) Если, не дай Бог, затеняешь, делай это вначале блока, чтобы было видно. И только в том случае, если нигде не используешь значения затеняемых переменных. В жс термина "затенение" нет, но он очень удобный. =)

По 1 пункту компилятор warning выдает.

Это типа агрегированный опыт, полученный от кривой архитектуры языка.

если говорить о js, то это другой язык

И тогда можно жить.

если говорить о js, то это другой язык

Ну, да. Никто не спорит.

И, т.е. let x = foo(); let x = x.bar(); let x = x.bax(); Это безопасный код?

Ой.

что значит безопасный?

Чисто гипотетически.

в расте все что не unsafe - безопасно )