Выперд на Rust v0.1: Критика implicit return и точки с запятой

!ДИСКЛЕЙМЕР! синтаксис – дело вкуса и к любому можно привыкнуть, этими постами я хочу не пожаловаться, а хочу чтобы мне объяснили "нахуя?"

Нахуя implicit return?

Можно не объявлять return, тогда вернется последняя строчка логической ветки функции.

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

Но Rust не чисто функциональный язык, он намного более процедурный, чем Haskell, поэтому там будет куча if ... else ... , while и т.д. и разобраться что все-таки ретерниться пиздец как тяжело

Нахуя implicit return ломается на ; ?

А вот от этого я вообще выпал... Если в конце последней строчки поставить ";" она не будет считаться как hidden return....

То есть, блять, вы даете возможность возвращать последнюю строчку без слова return, но если поставить ;, то тогда нельзя??? И чтобы это исправить нужно или добавить return или убрать ;???

Это что за бред, какое вообще может быть кейс, при котором это полезно? Зачем эта фича в языке?

Почему бы просто не сделать обязательный return и не создавать 1000 вариантов возврата? Никто не треснет пополам, если придется писать return

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

Я НАДЕЮСЬ что это просто я только начал и не вижу пользы от этого, но на первый взгляд это чисто выдумка Rust во имя пока хер пойми чего

И не дай бог вам сказать, что для этого есть линтер, где это можно запретить, потому что это чисто дорожка Node.js, которая приведет в очень нехорошее будущее

Супер фича! Явные return — зло! 😁

Не не не, сириусли, это не тоже самое, что в функциональщине (потому что там это оправдано и нужно), а в Rust у тебя будет куча процедурного кода (if ... else ..., loop, присвоения переменных и так далее) и чтобы найти в каких местах возврат тебе надо найти строчку, которая (1) последняя в логической цепочке, (2) так еще блять и без ;

Найти такое глазами в процедурном коде это очень жестко

АХАХАХАХАХА это код (чисто для визуализации примера), который скомпилируется, во скажите где и что будет возвращаться?

Разве не нужно объявить переменную и туда записать конечное значение, и её в конце вернуть?

Делать много точек выхода ведь плохо?

Причем, я уже описал выше как это работает и понять это будет проблемой, а если не знать то, что я написал выше и знать ЛЮБОЙ другой язык программирования, в жизни не поймешь что это за гавно

Такое может хорошо работать только с монадами и путями (не помню как это называется, но я имею ввиду функциональное ветвление, которое вызовет функцию только если у тебя вышел Left / Ok и пропустит все до ветки, где есть обработка Right / Err)

Когда ты явно пишешь if ... else ... люди будут использовать много точек выхода иначе код привратиться в гигантский boilerplate

Вот я сейчас в pattern matching нашел пример, который неплохо отвечает на вопрос \"нахуя\", но разве не проще было сделать вариант синтаксиса (например : после предиката), которое дает возможность вернуть единственную строчку без использования return?

Вроде, в расте есть аналог монад.

В любом случае, я считаю, что много точек выхода тоже так себе идея.

А Rail-way самое оно.

Да, там подобие монад реализованы на enum (Ok / Err например)

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

Так тут как раз монада. 😁

Так да, оно и есть, но ты посмотри во что она обернута: if ... else ...

Несомненно человек мог и match сделать, но это еще один пример, где в функциональщину начнают добавлять процедурщину

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

А на выходе из этой функции может оказаться еще один скоп if ... else ... и мы опять пытаемся осознать: \"А где тут выход?\"

Ты не прав.

Это как раз тренд про \"монада в обычном коде\", без специального синтаксиса.

Сейчас все к этому стремятся.

Ок, тогда вот так поставим вопрос: какие еще НЕ чисто функциональные языки реализуют такой implicit return?

Так я не просто \"не против\", я наоборот ЗА, меня напрягает что появляется миллиард неочевидных способов вернуть что-то из функции, когда код при этом насыщен процедурщиной

Так это язык для масс, как php. 😂

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

Ага, язык для перекидывания байтиков. 🙈

Только людям нужны абстракции, а не байтики.

implicit return выгодно, так как тогда определение функции становится синтаксически похоже на блок возвращающий значение

rust
// Здесь неизменяемое значение
let obj = {
// В этом небольшом куске кода существует имя b
let mut b = ObjBuilder::new();
// ...
b.build()
};

А вот я постоянно топлю как раз таки против абстракций и язык прокидывания байтиков в итоге доказал всему миру, что они не нужны (generic смогли выбить, это полезно, еще добавят union type и pattern matching и я с него не слезу пока не нужен будет memory management)

О, спасибо за пример!

А вот тоже самое даже на TS:

let obj: SomeType
{
// В этом небольшом куске кода существует имя b
let mut b = ObjBuilder::new();
// ...
obj = b.build()
}

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

Да, придется обозначить заранее тип и сделать переменную пустой, НО компилятор спокойно спокобен проверить будет или не будет заполнена переменная чтобы дальше не столкнуться с nil-pointer

Это я к тому, что: насколько вариант rust более удобный, чем более очевидный (засчет явного присвоения) пример на TS, который еще будет безопасен в компиляции?

еще так можно

ни один язык не застрахует от говнокода

Не спорю, мой код намеренно \"ублюдский\" и его можно зарефакторить более красиво, но в этом и суть: тебе придется работать с уставшим / junio / плохим разработчиком, который будет способен написать такой код

+ этот рефакторинг, на мой вкус, больше про тернарные операторы, нежели implicit return

То есть на 1 фото псевдокод, а на 2 аналог на Go, в котором больше boilerplate, но и больше очевидности ИМХО

Вот это симпатичнее выглядит

100% , но он может снижать вероятность говнокода и для этого нужны четкие границы

Наример (протите, что часто его использую, но я правда считаю что там это сделано отлично) Go, который убрал всю магию, оставил самый жесткий минимум и тем самым у тебя в 90% случаев нет вариант \"решить тоже самое разными путями\" есть конкретно один путь

Извиняюсь, конечно, надо написать вот так на Go и стало еще читабельнее

я бы сказал это офигенно выглядит

Да, но насколько сложно в сравнении с тем, что в реальности надо сделать

Когда ты поработаешь с реально большими кодовыми базами ты поймешь насколько тебе надоест каждый раз осознавать \"а что хотел написать этот кретин?\" – и смешнее всего то, что часто им в итоге будешь чоказываться ты сам, говорю по опыту))

А вот здесь ничего не надо осознавать, все на порвехности, прочитай строчки и делай что должен

всю магию убрал zig, рекомендую попробовать, да и путь там только один - тот, что указал товарищ Эндрю

А я в первом посте как раз и говорю что люблю Zig, но он сырой))