Альфа-версия Rust 1.0

А вот кстати вопрос - как дела с каррингом в rust?

Лямбдами.

А сколько примерно можно пользоваться nightly сборкой, чтобы не «отстать» от новых фич?

Ты про то, когда код может перестать собираться? До альфы 1.0 - хоть каждый день (хотя, в среднем, у меня чего-то ломалось раз в 3-5 дней).

После выхода альфы ничего крупного не успели поломать, вроде)

Ну, для крайних случаев «нужно выпутаться из кучи уровней вложенности» вполне подходит.

Разве что, для очень крайних.

Таких же крайних, как в приведенном тобой случае с Go.

«монадический сахар нас спасёт»

...но даже без него, с наличием pattern matching ситуация уже не такая унылая, как в Си.

Да, именно это я и имел в виду. Можешь глянуть тему, куда я тебя скастовал?

Есть примеры?

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

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

Ну а в расте сейчас плохо с синтаксическим сахаром для удобной обработки «кодов возврата» плюс отсутствие исключений.

Ну дык и не релиз же.

Ну а в расте сейчас плохо с синтаксическим сахаром для удобной обработки «кодов возврата» плюс отсутствие исключений.

Ну дык и не релиз же.

Официального сахара в релизе 1.0 не будет.

А в планах есть или всех устраивает и так?

В планах есть.

left = 0.0;
right = win_size.w as ZFloat;
bottom = 0.0;
top = win_size.h as ZFloat;
near = -1.0;
far = 1.0;
ortho(left, right, bottom, top, near, far)

Чистейшее извращение. Непонятно только нафига?
Просто вызвать ortho уже не канает?

Чистейшее извращение. Непонятно только нафига?

Ээээм, ну, в данном случае вот.

Просто вызвать ortho уже не канает?

ortho(0.0, win_size.w as ZFloat, 0.0, win_size.h as ZFloat, -1.0, 1.0);

Эм, так? Кому-то удобнее прочитать этот вариант? Ладно бы еще у функции была парочка аргументов разного типа, но эта же жрет шесть чисел с плавающей точкой. Я вот на этот вызов смотрю и уже не уверен, какое из чисел что значит.

Ээээм, ну, в данном случае вот.

Что вот? Где там магические числа?

Эм, так? Кому-то удобнее прочитать этот вариант?

Не вижу проблем в прочтении.
99.99(9)% программ написаны таким образом и только укушенные питоном почему-то в этом видят проблему.

К хорошему быстро привыкаешь.

left = 0.0;
right = win_size.w as ZFloat;
bottom = 0.0;
top = win_size.h as ZFloat;
near = -1.0;
far = 1.0;
ortho(left, right, bottom, top, near, far)

логично писать так:

ortho( win_size, -1.0, 1.0)

Где первый параметр - прямоугольник, который можно автоматом получить из size. Если параметры сходу непонятны - любое IDE сразу их покажет тултипом вместе с описанием.

К хорошему быстро привыкаешь.

ХЗ. Как по мне так даже на синтаксический сахар не тянет.

Ээээм, ну, в данном случае вот.

Ну до абсурда то доводить не стоит.

Что вот? Где там магические числа?

0.0, 0.0, -1.0, 1.0 - вот же. Это голые числа, которые хрен знает что значат, пока не грепнешь сигнатуру ortho. win_size.{w,h} as ZFloat - так же.

Не вижу проблем в прочтении.

О.о

99.99(9)% программ написаны таким образом ...

Каким «таким»? Если ты о том, что почти весь реально полезный код - плохоподдерживаемое дерьмо, то согласен) Но я надеюсь, таких дурацких функций, как эта ortho, из вызова которых вообще нифга не понятно, не 99% )

... и только укушенные питоном почему-то в этом видят проблему.

Я не помню, что бы хоть кто-то из моих знакомых был с этим несогласен, даже пистононенавистники. Если у функции кривой интерфейс, и его нельзя изменить, то в промежуточных документирующих переменных зла еще никто не видел, вроде. При смотре PR может быть небольшой срач, конечно, нужно ли оно в каком-то конкретном случае было, но, в целом, в моей реальности это всегда считалось хорошей практикой.

Это голые числа, которые хрен знает что значат, пока не грепнешь сигнатуру ortho

«Магическая» строка:

printf( "%d", n );

Хрен знает что значит, стоит ли из-за этого выписать ее отдельно?

.. логично писать так ...

Я согласен, что у этой функции кривой интерфейс и что для большинства функций это не нужно. ortho - наследство старого opengl - https://www.opengl.org/sdk/docs/man2/xhtml/glOrtho.xml. Для примера привел же, не конкретно в ней суть.

Если параметры сходу непонятны - любое IDE сразу их покажет тултипом вместе с описанием.

А вот это уже вопрос отношения к IDE, лично я их стараюсь избегать. Да и стандартный аргумент - код читают не только в уютной ide: например, в git diff или патче на гитхабе никто всплывающих подсказок не покажет. И вообще, ide для ржавчины пока нет и нормальной еще очень долго, думаю, не будет.

«Магическая» строка: printf("%d", n); Хрен знает что значит, стоит ли из-за этого выписать ее отдельно?

Понятно, что форматная строка - распространненное явление, так что вызов функции print* создает достаточно контекста, что бы у хоть немного программировавших людей тут затыка не возникло.

Или ты что хотел этим сказать?

Да и стандартный аргумент - код читают не только в уютной ide

Имена параметров - далеко не все, что нужно знать о «незнакомой» функции. Нужны и типы, и описание самой функции. Последнее куда важнее выноса «магических чисел», но не копипастить же это описание каждый раз в месте вызова.

Это голые числа, которые хрен знает что значат, пока не грепнешь сигнатуру ortho.

Внезапно, без чтения документации по ortho эти ваши left, right, bottom, top, near и far так же ни о чём не говорят.

win_size.{w,h} as ZFloat - так же.

Да здесть-то что не понятно? размер окна, ширина и высота?
Кстати, первые два 0.0 вполне понятны из контекста.

Каким «таким»?

Простым и лаконичным.

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

Комментарии уже что, отменили?

ortho(
    0.0, //left
    win_size.w as ZFloat, //right
    0.0, //bottom
    // было top: win_size.w as ZFloat,
    win_size.w as ZFloat, //top <= внезапно ошибка! аффтара расстрелять! т.к. его именнованные переменные не спасли от такой жёппы!
    -1.0, //near:
    1.0 //far:
);

Внезапно, без чтения документации по ortho эти ваши left, right, bottom, top, near и far так же ни о чём не говорят.

Зато говорят компилятору.

Тут проблема в рефакторинге. Если меняешь синтаксис функции, легче всего менять вызов везде перекомпиляцией показывающей ошибку.

Но если какой-то вызов не приводит к ошибке(типы позиционных параметров совпали), то про его переделку могут забыть.

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

Тут проблема в рефакторинге. Если меняешь синтаксис функции, легче всего менять вызов везде перекомпиляцией показывающей ошибку.

Самый глупый способ. Вернее всего сделать поиск по всем файлам. А проще всего использовать нормальные инструменты, например, netbeans умеет менять и переставлять параметры.

Имена параметров - далеко не все, что нужно знать о «незнакомой» функции. Нужны и типы, и описание самой функции. Последнее куда важнее выноса «магических чисел», но не копипастить же это описание каждый раз в месте вызова.

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

Зато говорят компилятору.

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

left = 0.0;
right = win_size.w as ZFloat;
bottom = 0.0;
top = win_size.h as ZFloat;
near = -1.0;
far = 1.0;
ortho(left, right, bottom, top, near, far)

Внезапно, без чтения документации по ortho эти ваши left, right, bottom, top, near и far так же ни о чём не говорят.

Если человек вообще никогда не видел этого ortho и понятия не имеет, как 3д работает, то да, может не догадаться. А если примерно представляет, что это все такое, то служат хорошей подсказкой о параметрах и позволяют не заглядывать в документацию лишний раз.

Да здесть-то что не понятно? размер окна, ширина и высота?

Не, в самом win_size.h все понятно, конечно. Я о том, что не слишком ясно, в каком значении оно передается в ortho (если честно, после нашего глуповатого обсуждения, я уже наизусть запомнил параметры ortho, но суть не в этом :) ).

Комментарии уже что, отменили?

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

внезапно ошибка! аффтара расстрелять! т.к. его именнованные переменные не спасли от такой жёппы!

Злой ты) Они и не должны от всего спасать, просто немного повысить чиаемость в данном случае. Лучше бы у параметров функции еще и тип отличался, да, это бы помогло тут.

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

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

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

(кстати, я тут let забыл написать перед переменными, кхм).

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

Самый глупый способ. Вернее всего сделать поиск по всем файлам. А проще всего использовать нормальные инструменты, например, netbeans умеет менять и переставлять параметры.

Единственный гарантирующий результат. netbeans - не компилятор в разборе сложных синтаксисов налажает. Поиск - вообще ни о чем. Ибо методы разных типов могут называться одинаково. Так что глупо полагаться на что-то из ваших вариантов.

netbeans - не компилятор в разборе сложных синтаксисов налажает.

В последней версии он просто замечательно разбирает код, что особенно приятно в случае как раз сложных иерархий классов, которые руками пришлось бы разбирать очень долго. При этом и шаблоны и новые фишки С++11 он тоже понимает на ура.

Поиск - вообще ни о чем. Ибо методы разных типов могут называться одинаково.

Значит надо будет просмотреть больше строк. Но это будет гарантия, что ты реально не пропустишь ничего. Я так и поступаю.

Так что глупо полагаться на что-то из ваших вариантов.

Любой из моих вариантов включает твой - т.к. после него делается ребилд. А значит они лучше просто по определению.

В последней версии он просто замечательно разбирает код, что особенно приятно в случае как раз сложных иерархий классов, которые руками пришлось бы разбирать очень долго. При этом и шаблоны и новые фишки С++11 он тоже понимает на ура.

Шаблоны с переменным числом аргументов нормально разворачивает? А C++14? Фишки вычисления в момент компиляции - замечательная вещь.

Любой из моих вариантов включает твой - т.к. после него делается ребилд. А значит они лучше просто по определению.

Переименовываешь метод, что бы точно все вызовы найти? Без этого, поменяв код по поиску или через netbeans нет никаких гарантий. Ты собираешь неизвестно что.

Если же меняешь имя функции, то находишь все места вызовов. Но тогда твои действия только пустая трата времени.

Фишки вычисления в момент компиляции - замечательная вещь.

Не пиши на лиспе, никогда.

Таких же крайних, как в приведенном тобой случае с Go.

Разве в Gо «перехват исключения» аналогичен порождению отдельного процесса?

Или речь о том, что и то и другое никому не нужная экзотика?

После выхода альфы ничего крупного не успели поломать, вроде)

Кстати, я тут недавно наткнулся на следующее: была у меня либа core. А теперь, я так понимаю, есть была у меня либа?

Я просто переименовал, но как-то умнее можно было конфликт имён разрулить?

...но даже без него, с наличием pattern matching ситуация уже не такая унылая, как в Си.

Паттерн матчин - это, разумеется, здорово. Хотя если функция у нас возвращает или ошибку или ничего и нам нужно просто пробросить ошибку дальше, то получается не лучше, чем в С. Впрочем, не буду утверждать, что именно такой код часто нужен:

if(ERROR == f1()) {
    return ERROR;
}

if(ERROR == f2()) {
    return ERROR;
}

...

match f1() {
    Err(e) => return Err(e),
    _ => ()
}

match f2() {
    Err(e) => return Err(e),
    _ => ()
}

...

Вложенные матчи мне нравятся ещё меньше.

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

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

Хотя библиотеки - это, пожалуй, как раз неплохой пример когда коды возврата лучше. Ещё лучше, конечно, двойной интерфейс, но это и затрат больше.

99.99(9)% программ написаны таким образом и только укушенные питоном почему-то в этом видят проблему.

У меня есть вполне реальный пример когда это помогло бы. Есть код который генерится по схемам, ну и генератор сам по алфавиту не сортирует. В итоге после изменений, параметры перепутались местами. Тесты упали, но причина так сразу не была очевидной. А вот с именованными параметрами всё бы работало, даже изменений не потребовалось бы.

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

Или речь о том, что и то и другое никому не нужная экзотика?

Да.

Хотя если функция у нас возвращает или ошибку или ничего

Я неудачно выразился - рулит не столько pattern matching, сколько ADT. С ними функция может возвращать результат работы или ошибку (в Си это будет выглядеть в лучшем случае очень коряво), и мы гарантированно не перепутаем одно с другим.

и мы гарантированно не перепутаем одно с другим.

Это да.

Да.

Не хочу на ещё один круг идти, так что лучше подскажи - при импорте крейтов можно как-то одноимённые отличать?

Шаблоны с переменным числом аргументов нормально разворачивает? А C++14

Отлично разворачиваются.

Фишки вычисления в момент компиляции - замечательная вещь.

constexpr

Переименовываешь метод, что бы точно все вызовы найти? Без этого, поменяв код по поиску или через netbeans нет никаких гарантий. Ты собираешь неизвестно что.
Если же меняешь имя функции, то находишь все места вызовов. Но тогда твои действия только пустая трата времени.

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

... умнее можно было конфликт имён разрулить?

Хм, не, не знаю умнее способа. Если у меня какие-то конфликты имен случаются, то я тупо добавляю префикс проекта («z» или «zoc», в случае своего «Zone of Control»).

Вообще, может и можно как-то через cargo, хз. Как минимум, у компилятора есть --extern <crate-name>=<path>.

Этот rfc - самое вразумительное, что я нагуглил по теме сейчас. Вот pr к нему.

Если у меня какие-то конфликты имен случаются, то я тупо добавляю префикс проекта

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

Как минимум, у компилятора есть --extern <crate-name>=<path>.

Это именно как флаг передаётся? Тогда сомневаюсь, что поможет.

Отлично разворачиваются.

Что и такое срабатывает?

TEST_P(ExampleTest)

{

auto data = GetParam(); EXPECT_EQ(data.mObject->method(data.mParam1, data.mParam2), data.mResult):

}

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

Я про методы с переменным числом аргументов. В результате рефакторинга которых аргументы могут оказаться не на своих местах. И именно такое решается только переименованием метода. Компиляцией. Правкой всех вызовов и возвращением названия метода. Все остальное - не дает никаких гарантий.

Что и такое срабатывает?

А где тут шаблон? Распиши плз, что ты хочешь.

Я про методы с переменным числом аргументов. В результате рефакторинга которых аргументы могут оказаться не на своих местах. И именно такое решается только переименованием метода. Компиляцией. Правкой всех вызовов и возвращением названия метода. Все остальное - не дает никаких гарантий.

Чепуха. Если метод перегружен, просто его переименовав в одном месте, ты упустишь те места, где компилятор свяжет вызов с другим методом.

А где тут шаблон? Распиши плз, что ты хочешь.

Это пример теста на gtest.

netbeans такое и без шаблонов не тянет.

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

Чепуха. Если метод перегружен, просто его переименовав в одном месте, ты упустишь те места, где компилятор свяжет вызов с другим методом.

А кто сказал, что перегруженные не приходиться то же переименовывать? Приходиться называть их подругому.

Еще хуже с виртуальными. Там приходиться и классы переименовывать, что бы все что нужно найти. Вообще - жуткий геморой.

Вот по этому я бы и хотел именованных аргументов.

C++ не подходит, потомучто течет.

Что?

А изобрази это на Си++

let n = std::os::args().get(1).and_then(|n| n.parse()).unwrap_or(100);

Можно нагородить огородов в духе std::os::* и написать так:

auto n = std::os::args().get(1).and_then(stoi).value_or(100);

Можно нагородить огородов

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

auto n = std::os::args().get(1).and_then(stoi).value_or(100);

Каков тип возвращаемого значения get? Тип аргумента and_then? Тип возвращаемого значения and_then?

Особой разницы не вижу.

Посмотри на размер нужного огорода.

Каков тип возвращаемого значения get? Тип аргумента and_then? Тип возвращаемого значения and_then?

Ну некий optional(из boost или std, хотя в 14ом его не взяли). and_then там нет правда, но можно сделать. Тип аргумента метода and_then - функция, которая принимает значение типа с которым работает данный optional и возвращает значение какого-то другого типа(ошибки или через optional или через исключения - как сделаем), and_then или возвращает пустой optional(нового типа уже) или результат функции.