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

Ну так сравнивать надо эквивалентный код. В коде на расте сознательно игнорируют любые ошибки. Идея мне не нравится, но твой код делает другое.

Замени unwrap_or на unwrap будет ругаться.

Тебе уже несколько раз сказали, что код не эквивалентен коду на Rust.

А он и не должен. Есть задача - есть решение. Ваш ЯП «из коробки» не умеет в короткие решения для частной задачи - не надо требовать от всех решать ее так же, как пришлось сделать вам.

Замени unwrap_or на unwrap будет ругаться.

но не будет дефолтного значения

Тебе уже несколько раз сказали, что код не эквивалентен коду на Rust.

А он и не должен

БггОкай.

Согласен, в с++ макрос, а в rust функция.

БггОкай.

Т.е. короткого и читабельного рещения на rust не будет? А ведь это всего-лишь вычитка параметра и уже rust так слился...

Согласен, в с++ макрос, а в rust функция.

В С++ универсальный макрос для всех случаев, а в rust - частная функция.

В С++ универсальный макрос для всех случаев

Правда, этого классного макроса почему-то нет в стандартной библиотеке.

а в rust - частная функция.

Куда уж функции против макроса!

В С++ универсальный макрос для всех случаев, а в rust - частная функция.

fn unwrap_or(self, def: T) -> T

А вот и нет. Универсальная функция!

Правда, этого классного макроса почему-то нет в стандартной библиотеке.

Там очень много чего нет. Зато есть хорошие сторонние библиотеки, как на С++, так и на С. Жить можно.

Куда уж функции против макроса!

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

А вот и нет. Универсальная функция!

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

Прямой аналог приведённого макроса.

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

http://doc.rust-lang.org/core/option/enum.Option.html http://doc.rust-lang.org/core/result/enum.Result.html

Прямой аналог приведённого макроса.

И я еще раз повторюсь, макрос один, таких функций - тонны.

И я еще раз повторюсь, макрос один, таких функций - тонны.

Тонны говоришь? Я вижу всего две, Option::unwrap_or и Result::unwrap_or.

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

[code-rust] let x: Result<int, &str> = Ok(-3); assert_eq!(x.is_ok(), true);

Так будет еще длиннее и нечитабельнее чем с _or.

Макрос позволяет не писать на каждую функцию по *_or варианту

or-вариант для типа Result уже написан.

ловить вложенные ошибки внутри функций, чего просто *_or тебе не даст.

Вау. Какой крутой макрос. Немедленно включить его в стандартную либу!

Тонны говоришь? Я вижу всего две, Option::unwrap_or и Result::unwrap_or.

Конкретный случай, добавляем функцию foo, если ей передали отрицательное число - ошибка. В С++ нужно всего-лишь добавить throw. Макрос уже написан - просто его используем.

int foo( int p ) {
  return p < 0 ? throw p : p;
}

int main() {
   cout << rust_useless( foo( -1 ), 100 ) << '\n';
}

Покажи вариант на rust.

fn foo() -> Result<i32, MyError> {
    Ok(-3)
}

Option и Result для функций!

or-вариант для типа Result уже написан.

Можешь тоже написать пример. Если вдруг сильно занят, ничего страшного.

Вау. Какой крутой макрос. Немедленно включить его в стандартную либу!

Для rust может и крутой, для С++ - так себе, ерунда.

Option и Result для функций!

Я просил полный и налогичный пример, ес-но.

Можешь тоже написать пример

Не вопрос:

println!("Hello, world\n")

Для rust может и крутой

Для Rust он ненужный.

Не вопрос:

Т.е. неспособие и клоун. numas13 намного умнее тебя, он понимает о чем речь.

ведь очевидно

Не очевидно.

Т.е. неспособие и клоун

Что за батхерт, малыш? Ты ведь сам сказал, что код не должен быть эквивалентен.

не надо требовать от всех решать ее так же, как пришлось сделать вам.

Издеваешься? Именно ты (ну или другой анонимус, различить-то нельзя) прибежал с дурацким (и синтетичным, имхо) примером кода. Потом привёл совсем другой код на С++ и пытаешься что-то доказать.

Если решать задачу нормально, то кода будет побольше на обоих языках. Ну да, раст не раскрывается на этой задаче. И что?

Спасибо. Два вопроса:

1) получается постоянно надо вызывать unwrap? т.е. как в С++ foo( 1) + foo( 2 ) не прокатит? И полчуется и более многословная функция и ее использование? 2) аргумент unwrap_or вычисляется лениво или нет?

Ты ведь сам сказал, что код не должен быть эквивалентен.

Но при этом должен решать определенную задачу. Твой код показывает лишь твои навыки, а не решение.

Но при этом должен решать определенную задачу

Задача тоже не должна быть эквивалентной.

Ну да, раст не раскрывается на этой задаче. И что?

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

т.е. как в С++ foo( 1) + foo( 2 ) не прокатит?

Нет. Но в Расте нет исключений и таким образом они «заставляют» обрабатывать ошибки.

2) аргумент unwrap_or вычисляется лениво или нет?

В смысле?

Задача тоже не должна быть эквивалентной.

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

Нет. Но в Расте нет исключений и таким образом они «заставляют» обрабатывать ошибки.

Ну т.е. либо добавляем новые функции, либо заставляет писать больше кода «клиентов». Это не обязательно плохо, но хуже чем макрос.

В смысле?

unwrap_or( boo( 1 ) ) - вызовет функцию boo или нет? макрос сделать это вычисление ленивым.

1) получается постоянно надо вызывать unwrap? т.е. как в С++ foo( 1) + foo( 2 ) не прокатит? И полчуется и более многословная функция и ее использование?

Ага, это не чистая функция. Надо обработать результат, удостовериться, что там точно число, а не None.

2) аргумент unwrap_or вычисляется лениво или нет?

Нет.

Ты прикинь, в расте тоже можно макрос написать.
Внезапно, да?
И будет у тебя тоже что-то подобное твоему «rust_useless»

Ты прикинь, в расте тоже можно макрос написать.
Внезапно, да?

нет

И будет у тебя тоже что-то подобное твоему «rust_useless»

не будет, выше написано почему

Когда один идиот возмущается, что другие решают по другому, и начинает решать другую задачу

Клиника - это когда на вопрос «приведи аналог этого кода» начинаются увертки и ужимки на тему «я решаю задачу».

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

Но письками друг перед другом помахать это не мешает, конечно.

Вот ленивое unwrap_or с помощью макроса.

macro_rules! lazy_unwrap_or {
    ($o:expr, $or:expr) => (
        match $o {
            Some(v) => v,
            None => $or,
        }
    )
} 

fn foo(p: isize) -> Option<isize> {
    if p < 0 { None } else { Some(p) }
}

fn bar() -> isize {
    println!("bar");
    100
}

fn main() {
    println!("{}", foo(1).unwrap_or(bar()));
    println!("{}", lazy_unwrap_or!(foo(1), bar()));
}

http://is.gd/KmWl6q

Клиника - это когда на вопрос «приведи аналог этого кода» начинаются увертки и ужимки на тему «я решаю задачу».

Вопрос ставил я - в rust даже простую задачу решают вот так вот коряво. Все остальное - твое желание оправдать эту корявость.

Вопрос ставил я - в rust даже простую задачу решают вот так вот коряво

Все вы на одно лицо. Какой-то анон сказал, что в Си++ не более коряво - так вот, гораздо более.

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

Небольшой вброс - и получается дискуссия с примерами кода. Что таки весьма полезно. Без вброса все слишком тихо. Впрочем почти все топики на ЛОР на этом основаны.

не будет

Схера не будет?
Такой же ленивый вызов.
А то что там вместо try{}catch(){} используется Option и match, то тебе какая разница?

выше написано почему

Где написано?

Вот ленивое unwrap_or с помощью макроса.

Спасибо, хотя примерно я представлял как это сделать. Исключениям это конечно проигрывает в плане того, что таки надо постоянно делать unwrap, нельзя «пробросить ошибку», да и быстродействие пострадает - добавляется постоянный оверхед. Но и исключения имеют большие недостатки, так что я вполне возможно до rust 2.0 попробую добавить Option и Result себе в С++, чтоб привыкнуть и заодно проверить - насколько удобно будет на практике.

Для этот шум не нужен и не используется. А так, наверное, чтобы не было неоднозначностей. Да, не очень изящно, но лучше, чем в С++ с его особыми костылями когда компилятору надо подсказывать, что это шаблонный параметр.

Плохо, если не используется - как раз и возникают странности вида from_str. Сам факт кодирования типа в _название_ функции дурно пахнет в языке с поддержкой шаблонов. А если нужно будет распарсить поток данных, то заводить новую функцию from_byte_stream и делать что-то вроде static if? Чем это лучше StringList?

«лучше, чем в С++» это не слишком большое достижение :)

Мне нравится, когда можно писать типобезопасные обёртки вида castFrom!long.to!int(var) и это читается естественно и без ужаса. Мне нравится, когда для простые и часто используемые случаев есть специальный облегчённый синтаксис. Rust пока что не уделяет этому аспекту вообще никакого внимания.

Кстати, на эту же тему : #[cfg(not(test))] это ещё один синтаксический ужас.

да и быстродействие пострадает

По сравнению с обработкой исключений?
Ну-ну.

Отлично! Ждем беты.

По сравнению с обработкой исключений?
Ну-ну.

try/catch вообще не дает оверхеда, можно хоть обмазаться ими, оверхед дает только throw и собс-но обработка исключения. Если в твоем коде постоянно происходит что-то непредвиденное и некорректное - то код на С++ действительно тоже будет иметь большой оверхед.

Плохо, если не используется - как раз и возникают странности вида from_str.

Я немного криво написал: для from_str не нужен дополнительный шум в виде ::<>.

Сам факт кодирования типа в _название_

Не согласен с аргументацией. Тут дело не в типе, а в логике функции. Можно сравнить с to_string из плюсов или других языков. Мы просто явно говорим, что преобразуем тип из строки. Конечно, это не просто «from» ведь мы не можем (этой функцией) выполнять преобразования типов: инты в даблы, инты в строки и т.д.

В языке нет перегрузки функций. Мне это совсем не нравится, но что поделать. Да и не смертельно это. Так что да, будет (если понадобится) и from_byte_stream т.д.

Обобшённость в языке достигается немного иначе. Можно ввести трейт с нужным интерфейсом. Дальше реализовывать его для нужных типов.

castFrom!long.to!int(var) и это читается естественно и без ужаса.

Субъективно.

Ещё раз повторюсь - мне не нравится выкидывание скобок для макросов с одним аргументом. Экономия мизерная, зато однообразие нарушается.

#[cfg(not(test))]

По моему, не смертельно. Выглядит как цепочка вызовов функций, то есть привычно. Не очень элегантно, да. С другой стороны, это сильнее отличается от обычных конструкций языке, чем в D. Возможно, это сочли преимуществом... Кстати, в D вообще есть условная компиляция по произвольному условию? Или только жестко-заданные debug и version?