LINUX.ORG.RU

Rust 0.10

 ,


2

8

Вышла новая версия Rust, языка программирования разрабатываемого Mozilla. Релиз несет в себе около 1500 изменений и исправлений ошибок.

Основные изменения:

  • Язык:
    • новый процесс RFC для изменения языка;
    • паттерны с '@'-указателями удалены из языка;
    • паттерны с '~[T]'-векторами удалены из языка;
    • паттерны с '~str'-строками удалены из языка;
    • '@str' удален;
    • '@[T]' удален;
    • '@self' удален;
    • '@Trait' удален;
    • заголовки, содержащие '@'-boxes для подсчета ссылок внутри типа, при '~'-аллокациях удалены;
    • семантика времени жизни временных выражений (temporary expressions) изменена. Подробнее в #3511, #11585;
    • добавлен новый cross-crate синтаксис расширений (доступен через feature gates). Подробнее в #11151. Эта возможность включает в себя макросы 'macro_rules!' и 'format!' как синтаксические расширения;
    • добавлены новые режимы lint, использование старых по умолчанию выдает предупреждения:
      • лишние скобки;
      • static в верхнем регистре;
      • Camel Case типы;
      • переменные в верхнем регистре;
      • приватные типы с публичной видимостью;
      • '#[deriving]' с raw-указателями.
    • unsafe-функции больше не преобразуются к замыканиям;
    • некоторые макросы с неясными названиями, например 'log_syntax!', теперь доступны через feature gates;
    • атрибут '#[simd]' теперь доступен через feature gates;
    • запрещены инструкции 'extern crate' в настройках видимости, модификатор 'priv' запрещен к использованию вместе с 'use' инструкциями;
    • замыкающие запятые запрещены в списках аргументов и шаблонах кортежей;
    • ключевое слово 'do' теперь является резервированным ключевым словом;
    • добавлены параметры типов по умолчанию, доступно через feature gates;
    • изменен механизм захвата borrowed-переменных в замыкания;
    • 'extern mod' изменен на 'extern crate';
    • удален 'Freeze' trait;
    • добавлен 'Share' trait для типов которые могут разделяться между потоками;
    • labels в макросах теперь гигиенические;
    • вызовы макросов теперь могут ограничиваться через '{}';
    • добавлен возможность перегрузки операторов '*' и '.' через 'Deref' и 'DerefMut' traits;
    • '~Trait' и 'proc' больше не реализуют 'Send' по умолчанию;
    • добавлена поддержка partial type hints через маркер типа '_';
    • введен тип 'Unsafe' для внутренней мутабельности. Преобразование '&T' в '&mut T' без использования 'Unsafe' является неопределенным;
    • реализован атрибут '#[linkage]' для внешних функций;
    • внутренний синтаксис атрибутов изменен с '#[foo];' на '#![foo]';
    • 'Pod' переименован в 'Copy'.
  • Библиотеки:
    • 'libextra' более недоступна. Она была разделена на более мелкие компоненты. Подробности в документации;
    • 'std::condition' удален. Все ошибки I/O передаются через тип 'Result'. Изменена работа макроса 'try!', подробности в #12039;
    • std: модуль 'vec' переименован в 'slice';
    • std: добавлен новый тип 'Vec<T>' для DST. В будущем это будет единственный вектор с изменяемым размером;
    • std: увеличено число публичных reexports 'std::io'. Типы, такие как 'BufferedReader' доступны через 'std::io::BufferedReader' вместо 'std::io::buffered::BufferedReader';
    • std: 'print' и 'println' более не доступны в prelude, используйте вместо них макрос 'println!';
    • std: 'Rc' теперь имеет 'Weak' указатель для прерываемых циклов и больше не пытается статически предотвращать циклы;
    • std: в стандартной поставке используется политика обработки ошибок пользователем вместо падения в библиотеках. Многие функции, такие как 'slice::last()' теперь возвращают 'Option<T>';
    • std: 'fmt::Default' переименован в 'fmt::Show', добавлен новый deriving mode: '#[deriving(Show)]';
    • std: 'ToStr' реализован для всех типов, реализующих 'Show';
    • std: trait для форматированного вывода принимает '&self' вместо '&T';
    • std: метод итераторов 'invert()' был переименован в 'rev()';
    • std: добавлена возможности вывода backtrace при падении task'a, если выставлено значение переменной 'RUST_BACKTRACE';
    • std: стандартизованы соглашения по наименованию для итераторов. Подробнее в wiki;
    • std: 'eof()' удален из 'Reader';
    • std: сетевые типы (networking types) теперь cloneable, разрешено одновременное чтение/запись;
    • std: 'assert_approx_eq!' удален;
    • std: добавлены спецификаторы форматирования 'e' и 'E' для вывода чисел с плавающей точкой в экспоненциальном формате;
    • std: удален 'Times';
    • std: добавлен тип 'std::kinds::marker' для выборочного вывода встроенных привязок (bounds);
    • std: 'hash' был переписан, 'IterBytes' удален, доступен '#[deriving(Hash)]';
    • std: 'SharedChan' был удален, 'Sender' теперь cloneable;
    • std: 'Chan' и 'Port' были переименованы в 'Sender' и 'Receiver';
    • std: 'Chan::new' заменен на 'channel()';
    • std: реализован новый тип синхронных каналов;
    • std: макрос 'select!' доступен для выбора 'Receiver'-ов;
    • std: 'hashmap' и 'trie' были перемещены в 'libcollections';
    • std: 'run' перемещен в 'io::process';
    • std: 'assert_eq!' теперь использует '{}' вместо '{:?}';
    • std: реорганизованы механизмы сравнения и проверки на равенство trait-ов;
    • std: 'rand' перемещен в 'librand';
    • std: 'to_{lower,upper}case' реализован для 'char';
    • std: функциональность логгирования перенесена в 'liblog';
    • collections: 'HashMap' переписана для увеличения производительности и уменьшения потребления памяти;
    • native: в качестве рантайма по умолчанию используется 'libnative'. 'libgreen' доступен для загрузки вручную, подробнее в документации;
    • native: реализована весь I/O функционал, за исключением сигналов;
    • green: оптимизировано создание task-ов в 'libgreen';
    • green: task-и, создаваемые через 'libgreen' используют unmapped guard page;
    • sync: модуль 'extra::sunc' был обновлен на современный rust, перемещен в библиотеку 'sync';
    • sync: добавлен новый тип 'Barrier';
    • sync: реализованы эффективные мьютексы для нативных и зеленых task-ов;
    • serialize: улучшен модуль 'base64';
    • fourcc: добавлен макрос 'fourcc!';
    • hexfloat: реализован макрос 'hexfloat!';
  • Инструментарий
    • 'rustpkg' объявлен устаревшим и удален из основного репозитория. Его замена ('cargo') в разработке;
    • доступны ночные сборки;
    • значительно улучшено использование памяти 'rustc';
    • отключена поддержка rpath для rustc в процессе сборки;
    • улучшен механизм кодогенерации;
    • восстановлена совместимость debuginfo с lldb на OSX;
    • флаги вывода централизованы в один флаг '--emit';
    • флаги crate типов централизованы в один флаг '--crate-type';
    • флаги кодогенерации объединены через флаг '-C';
    • улучшены сообщения об ошибках возникающих при линковке с устаревшими crates;
    • сообщения об ошибках с временем жизни теперь часто показывают как объявить функцию чтобы исправить ошибки;
    • значительно расширена документация;
    • улучшения в 'rustdoc':
      • подсветка синтаксиса и блоки кода;
      • генерация standalone markdown файлов;
      • флаг '--test' проверяет все блоки кода по умолчанию;
      • отображение экспортированных макросов;
      • reexported типы имеют встроенную документацию в месте первого reexport;
      • результаты работы по поиску в crate-ах теперь генерируется в выходную директорию.

>>> Подробности

★★★★★

Проверено: JB ()
Последнее исправление: encyrtid (всего исправлений: 1)

улучшены сообщения об ошибках возникающих при линковке с устаревшими crates

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

А теперь вот все цивилизованно и понятно, круто:

$ make
rustc -L deps main.rs -o marauder
main.rs:13:1: 13:21 error: found possibly newer version of crate `std` which `cgmath` depends on
main.rs:13 extern crate cgmath;
           ^~~~~~~~~~~~~~~~~~~~
main.rs:13:1: 13:21 note: perhaps this crate needs to be recompiled?
main.rs:13 extern crate cgmath;
           ^~~~~~~~~~~~~~~~~~~~
main.rs:13:21: 13:21 note: crate `std` path #1: /usr/lib/rust/rust-nightly/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-aad93cea-0.11-pre.rlib
main.rs:13:21: 13:21 note: crate `std` path #2: /usr/lib/rust/rust-nightly/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-aad93cea-0.11-pre.so
main.rs:13:21: 13:21 note: crate `cgmath` path #1: /home/ozkriff/marauder/main/deps/libcgmath-13b4a6e6-0.1.so
main.rs:13:21: 13:21 note: crate `cgmath` path #2: /home/ozkriff/marauder/main/deps/libcgmath-13b4a6e6-0.1.rlib
error: aborting due to previous error
make: *** [marauder] Error 101
ozkriff
()
Ответ на: комментарий от ozkriff

Чем Rust лучше D? Пока я вижу одни недостатки и слабую инфраструктуру. Тот же D хотя бы позволяет использовать уже готовый код на Си, а тут что? Тысячи библиотек с нуля предлагается писать?

Xroft ★★
()
Ответ на: комментарий от Xroft

Тот же D хотя бы позволяет использовать уже готовый код на Си, а тут что? Тысячи библиотек с нуля предлагается писать?

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

wota ★★
()
Ответ на: комментарий от Xroft

Тот же D хотя бы позволяет использовать уже готовый код на С

С Rust ровно то же самое.

tailgunner ★★★★★
()
Ответ на: комментарий от Xroft

одни недостатки

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

Про инфраструктуру уже написали, привязки к сишным библиотекам на Ржавчине генерируются-пишутся очень легко.

Как минимум это:

  • в Ржавчине нет исключений;
  • Ржавчина не полагается во всем и вся на сборщик мусора, но при этом она безопаснее (я не уверен, но это должно упростить встраивание модулей на Hжавчине в существующие системы на Си);
  • Ржавчина испытала некоторое влияние ML-языков. Например, сопоставление с образцом и константность переменных по-умолчанию.

Но я в D мало что понимаю, так что чего-то хорошее и плохое упустил скорее всего.

ozkriff
()

Почему тут никто про Nimrod ничего не сказал? Его обычно тоже вспоминают вместе с Go и D.

ozkriff
()
Ответ на: комментарий от ozkriff

в Ржавчине нет исключений;

А что вместо них и чем оно удобнее?

В Rust нет инфраструктуры совершенно. В D есть:

- крайне удобный пакетный менеджер

- интеграция во в VS и Mono Developer

- поддержка LLVM

- GDC для GCC

- возможность писать под iOS (пока экспериментальная)

- понятный любому Си программисту синтаксис

- мощный веб сервер

- серьезное сообщество (там куча людей с мировым именем)

- возможность писать код не использующий сборщик мусора

- легкость портирования Си кода. Фактически почти весь Си код валиден в Ди.

И это из того, что приходит в голову в первую очередь.

Xroft ★★
()
Последнее исправление: Xroft (всего исправлений: 1)
Ответ на: комментарий от Xroft

Зачем ты это пишешь, если _вообще_ ничего про Ржавчину не знаешь?

В Rust нет инфраструктуры совершенно

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

крайне удобный пакетный менеджер

В Ржавчине пока нету, скоро будет.

интеграция во в VS и Mono Developer

студия, моно, ... - фууэээ. Вообще, IDE, как и вся остальная инфраструктура, дело времени.

поддержка LLVM

Основная реализация Ржавчины использует llvm.

GDC для GCC

Есть https://github.com/redbrain/gccrs , но я не уверен, что это вообще нужно, раз есть llvm.

возможность писать под iOS

А чем ios такой особенный, что это выносится в отдельный пункт?

понятный любому Си программисту синтаксис
легкость портирования Си кода. Фактически почти весь Си код валиден в Ди.

Совсем не факт, что это плюс D. Си - опасная и падучая штука, если хоть на секунду потерять осторожность.

мощный веб сервер

Не вижу, почему таковой не может быть написан на Ржавчине.

серьезное сообщество (там куча людей с мировым именем)

У Ржавчины дико открытое и дружелюбное сообщество. А от «людей с мировым именем» не факт, что много пользы.

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

У D с этим хуже, чем у Ржавчины. Причем очень сильно.

ozkriff
()
Ответ на: комментарий от tailgunner

сборка мусора не нужна

Сборка мусора нужна.

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

anonymous
()
Ответ на: комментарий от anonymous

Сборка мусора (хоть через RC) нужна, как минимум, когда нельзя определить одного владельца объекта. Грамотность архитектуры программы тут не всегда поможет.

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

Почему?

ozkriff
()
Ответ на: комментарий от ozkriff

Зачем ты это пишешь, если _вообще_ ничего про Ржавчину не знаешь?

Ну вестимо чтобы понять как дела с этим у Ржавчины.

У Ржавчины дико открытое и дружелюбное сообщество.

А где на него посмотреть-то хоть можно? Просто на forum.dlang.org я движуху постоянную вижу и могу по ней оценивать темпы и направление развития, а у ржавчины?

Если честно я вообще ничерта не понял из написанного в changelog. Это к слову о простоте освоения языка.

Ты кстати так и не ответил, что у ржавчины вместо исключений.

Xroft ★★
()
Ответ на: комментарий от Xroft

Ну вестимо чтобы понять как дела с этим у Ржавчины.

5-10 минут в гугле убрали бы половину вопросов. Это как-то не очень вежливо.

А где на него посмотреть-то хоть можно?

Например:

Если честно я вообще ничерта не понял ...

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

ozkriff
()
Ответ на: комментарий от Xroft

Ты кстати так и не ответил, что у ржавчины вместо исключений.

Option: http://static.rust-lang.org/doc/master/std/option/index.html

Result: http://static.rust-lang.org/doc/master/std/result/enum.Result.html

Потому что от исключений, как они сделаны в С++, больше вреда, чем пользы.

ozkriff
()
Ответ на: комментарий от ozkriff

Потому что от исключений, как они сделаны в С++, больше вреда, чем пользы.

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

А почтовые листы по сравнению с Дишными какие-то тухловатые...

Xroft ★★
()
Последнее исправление: Xroft (всего исправлений: 1)
Ответ на: комментарий от Xroft

А почтовые листы по сравнению с Дишными какие-то тухловатые...

Писем не так много, да. Большая часть обсуждений-срачей происходит в irc, комментариях к запросам на включение в https://github.com/mozilla/rust и в реддите. Не вижу ничего плохого.

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

Чего? Это очень хорошо. Как ты собираешься ловить то, что никто не бросит?

И в чем же в них вред?

Ты издеваешься? Это же громадный вековой срач с кучей всяких нюасансов, а ты никогда, типа, не натыкался на его обсуждение и не помышлял, что с С++-исключениями может быть что-то не так? Хочешь, что бы я тебе в двух словах суть пересказал что ли? Или ссылок накидал?

ozkriff
()
Ответ на: комментарий от mix_mix

А, еще это сделано потому, что без терминатора утверждений (т.е. с использование перевода строки этом смысле в зависимости от контекста) у тебя не выйдет языка, семантика в котором не зависит от форматирования. А это принципиальная позиция разработчиков, если я не ошибаюсь.

ozkriff
()
Ответ на: комментарий от ozkriff

Как ты собираешься ловить то, что никто не бросит?

Поясни.

Ты издеваешься? Это же громадный вековой срач с кучей всяких нюасансов

Ты не поверишь, но я ни разу не натыкался на него. Пересказывать не надо — дай ссылки на самые жирные дискуссии. Коли это такая популярная тема, то думаю труда тебе это не составит.

Xroft ★★
()
Ответ на: комментарий от mix_mix

И мне кажется, что без 'return' и ';' визуально было бы намного сложнее понять, где точка выхода из функции и когда возвращается значение.

ozkriff
()
Ответ на: комментарий от Xroft

Поясни
И отсюда другой вопрос - разве это хорошо, если я не могу исключение в коде поймать?

Если в языке нет исключений то и ловить нечего, о чем вопрос-то?

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

дай ссылки

Допустим, вот парочка первых попавшихся статей:

Моя личная нелюбовь к исключениям в С++, в основном, в том, что сопровождение большого количества настоящего exception-safe кода я нахожу неоправданно сложным и компилятор или lint`ы всякие с этим делом почти не помогают. А в недо-exception-safe коде вероятно возникновение множество очень хорошо скрытых и трудновоспроизводимых ошибок.

ozkriff
()
Ответ на: комментарий от ozkriff

Если в языке нет исключений то и ловить нечего, о чем вопрос-то?

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

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

Looking at a block of code, including functions which may or may not throw exceptions, there is no way to see which exceptions might be thrown and from where

А это вообще не понял. Экссепшены для того и нужны, чтобы можно было написать словами что и где не получилось.

Xroft ★★
()
Последнее исправление: Xroft (всего исправлений: 2)
Ответ на: комментарий от Xroft

A better alternative is to have your functions return error values when things go wrong, and to deal with these explicitly, no matter how verbose it might be. It is true that what should be a simple 3 line program often blossoms to 48 lines when you put in good error checking

Ну и? В обоих случаях придется писать кучу проверок. Только во втором случае внутри функции.

Xroft ★★
()
Ответ на: комментарий от Xroft

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

Как вариант, явно проверять возвращаемое функцией открытия значение. Например, так:

use std::io::{File, Open, ReadWrite};
let p = Path::new("/some/file/path.txt");
let file = match File::open_mode(&p, Open, ReadWrite) {
    Ok(f) => f,
    Err(e) => fail!("file error: {}", e), // грохаем задачу
};
// сделать чего-то полезное с файлом
// файл будет закрыт, когда кончится жизнь переменной 'file'
ozkriff
()
Ответ на: комментарий от Xroft

нет ли на русском срачей

https://duckduckgo.com/?q=исключения vs коды возврата

и первая ссылка оттуда (не читал, но комментов много и срач явно наличествует):

http://habrahabr.ru/post/130611

А это вообще не понял. Экссепшены для того и нужны, чтобы можно было написать словами что и где не получилось.

void f() {
    // какая из этих прекрасных подпрограмм может все
    // тебе поломать внезапно выброшенным исключением,
    // а какая - нет?
    // А если это библиотечные функции и у тебя нет исходников?
    // А если реализация библиотеки изменилась и
    // теперь кидаются другие исключения?
    a();
    b();
    c();
}

Может тебе про это создать отдельную тему? Это не только Ржавчины касается же.

ozkriff
()
Ответ на: комментарий от Xroft

ни разу не натыкался на него

Например: http://250bpm.com/blog:4

дай ссылки на самые жирные дискуссии

Думаю, тебе не жирная дискуссия нужна, а материал для самообразования. Вот, например: http://bartoszmilewski.com/2011/01/09/monads-for-the-curious-programmer-part-1 (читай все 3 части или просто пользуйся D).

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

category theory

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

quantum-troll ★★★★★
()
Ответ на: комментарий от quantum-troll

Не надо отпугивать практиков.

Трусы, которые пугаются с первого абзаца, не имеют права называться практиками.

tailgunner ★★★★★
()
Ответ на: комментарий от ozkriff

Может тебе про это создать отдельную тему? Это не только Ржавчины касается же.

Создай плиз. Интересно очень почитать аргументы с двух сторон.

void f() {
    // какая из этих прекрасных подпрограмм может все
    // тебе поломать внезапно выброшенным исключением,
    // а какая - нет?
    // А если это библиотечные функции и у тебя нет исходников?
    // А если реализация библиотеки изменилась и
    // теперь кидаются другие исключения?
    a();
    b();
    c();
}

А что мешает каждую функцию в try catch обернуть?

Например: http://250bpm.com/blog:4

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

Xroft ★★
()
Ответ на: комментарий от Xroft

что мешает каждую функцию в try catch обернуть?

А чем это лучше оборачивания в match ret { Err(x) => /* чонибудь*/ }?

на том же Ди можно точно так же писать

Как «так» - с постоянной проверкой кодов возврата? Нахрена так жить. А с pattern matching в D писать нельзя - нет ADT.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от Safort

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

ozkriff
()
Ответ на: комментарий от tailgunner

Ничем не лучше, только оборачивать все не всегда удобно и нужно. Вообще достали неосиляторы. Вместо того, чтобы сделать нормальный полноценный новый языкс плюшками, создают всякое goвно. И rust туда же идёт. Куда не плюнь, все не нужно, одни вон даже дженерики отказываются делать, эти на исключения плюются. ООП тоже через жопу делать нужно. Вот только скалка радует из относительно новых. Но уж с C++ на неё полностью перейти не удаётся.

anonymous
()
Ответ на: комментарий от anonymous

одни вон даже дженерики отказываются делать

Go штоле? Так он говно, устаревшее еще до рождения.

эти на исключения плюются

На исключения плюется много кто по разным причинам.

ООП тоже через жопу делать нужно

Дискуссионный вопрос.

tailgunner ★★★★★
()
Ответ на: комментарий от northerner

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

В низкоуровневом языке вполне может быть нормальная модульность, сборка мусора и много чего ещё. Это доказал пример Оберона, на котором вполне себе написали ОС, современную и производительную для своего времени.

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

Vudod ★★★★★
()
Ответ на: комментарий от ozkriff

И мне кажется, что без 'return' и ';' визуально было бы намного сложнее понять, где точка выхода из функции и когда возвращается значение.

Это результат вашей привычки. В Фортране, например, нет ни return, ни обязательного ";". Тем не менее, там сразу понятно, где происходит вход из функции и какого типа возвращается значение. Потому что тип и имя переменной-результата объявляется в заголовке, а несколько return'ов всегда считались плохим стилем. Следовательно, последний оператор и есть место выхода. Всегда.

Vudod ★★★★★
()
Ответ на: комментарий от Vudod

Возможно, что это просто дело привычки, с этим я не спорю.

имя переменной-результата объявляется в заголовке

Хм, это в Ржавчине нет.

а несколько return'ов всегда считались плохим стилем. Следовательно, последний оператор и есть место выхода. Всегда.

Это уже немного спорно. Хотя бы для раннего возврата из функции, если что-то пошло не так:

fn x(n: int) -> int {
    if n < 0 {
        None
    }
    // 10 строк вычислений
    let a = n + 1;
    Some(a)
}
ozkriff
()
Ответ на: комментарий от ozkriff
fn x(n: int) -> Option<int> ...

Неудобно, когда не можешь редактировать свои сообщения :(

ozkriff
()
Ответ на: комментарий от tailgunner

Плюешься на исключения - не используй их. У gcc/clang даже ключик есть на это. Зачем выаиливать полезную и правильную, в общем случае, фичу? В ряде проектов исключения действительно неудобны, но это не повод.

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

anonymous
()
Ответ на: комментарий от ozkriff

В вашем примере логика нарушена. Если n по смыслу не может быть отрицательным, нужно ставить assert, либо, если падение программы не предусмотрено, создавать и ловить исключение. Второй старинный вариант --- лучше тогда писать:

if n >= 0 {
    // 10 строк вычислений
    let a = n + 1;
    Some(a);
}

Vudod ★★★★★
()
Последнее исправление: Vudod (всего исправлений: 2)
Ответ на: комментарий от anonymous

чтобы писать в ОО-стиле приходиться подпрыгивать

В Ржавчине не нужно подпрыгивать. Что тебе вообще с местным ООП не нравится?

Зачем выаиливать полезную и правильную

Очевидно, затем, что разработчики не считают ее такой.

И бросаться «неосиляторами» налево и направо без толковых аргументов не очень здорово. Отказываться делать что-то можно по многим причинам.

ozkriff
()
Ответ на: комментарий от Vudod

Операции с int просто пример, это же не код какой-то полезной функции, которая где-то используется на практике.

Исключений нет, возврат None или Err когда «падение программы не предусмотрено» - стандартный подход.

старинный вариант

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

И не всегда (хотя и часто) такая ситуация с несколькими ранними возвратами значит, что с кодом что-то не так и его надо срочно переписать.

ozkriff
()
Ответ на: комментарий от ozkriff

Отказываться от исключений или нет - должен решать технический руководитель проекта, а не авторы языка. Ни один язык, который не оставляет за программистами выбора, не заменит C++.

anonymous
()
Ответ на: комментарий от anonymous

Что еще авторы языка не могут решать? Может, например, реализацию ООП тоже навязвать нелья? Ой, а С++ же так делает, какой кошмар.

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

ozkriff
()
Ответ на: комментарий от anonymous

И почему это не подходит под твое понимание ООП? Тебе нужны заголовочные файлы, конструкторы и ключевое слово 'class', что бы спать спокойно?

ozkriff
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.