> Как видим мы можем брать адрес константы и с его помощью её использовать, но думаю лучше так не делать, т.к. «ссылки на одну и ту же постоянную не обязаны указывать на один и тот же адрес в памяти»
Многие функции одалживают значения, почему бы не передавать туда константы? Пускай себе в ссылки в разные места на стеке будут, я тут плохого не вижу.
«ценой дополнительной нагрузки на программиста» — очень спорная формулировка :). Я бы скорее говорил в направлении перенеса какой-то части нагрузки на программиста со стадии отладки на стадию написания кода.
but to keep the design space as unconstrained as possible, we do not currently want to support IndexMut, in case some other strategy will eventually be needed.
Code currently using mutating index notation can use get_mut instead.
Это не для индексов же. Я хочу возможность нормально писать `&mut map[key]` (по аналогии со сто лет как работающим `&map[key]`), а не `map.get_mut(key).expect(«TODO: добавить обработку ошибок по вкусу»)`. :(
В ржавчине переборщили с сахаром? О.о Обычно на обратное ругаются, что «очевидные компилятору вещи» нужно явно выписывать и «синтаксической соли» (типа `let mut`) слишком много)
А что именно мешает воспринимать код? Мне в голову в первую очередь локальный вывод типов приходит, но он во все языки сейчас потихоньку просачивается, вроде как уже норма (`auto auto(auto) auto` :) ).
Сейчас есть накостыленый на макросах mdo! — https://github.com/TeXitoi/rust-mdo — лучше без HTK особо не сделаешь. С ним как-то так выходит:
fn write_to_file_using_try() -> io::Result<()> {
let mut file = try!(File::create("my_best_friends.txt"));
try!(file.write_all(b"This is a list of my best friends."));
println!("I wrote to the file");
Ok(())
}
fn write_to_file_using_mdo() -> io::Result<()> {
mdo! {
mut file =<< File::create("my_best_friends.txt");
ign file.write_all(b"This is a list of my best friends.");
ign Ok(println!("I wrote to the file"));
ret Ok(())
}
}
Если интегрировать в язык, то, наверное, можно и немного покороче/покрасивей синтаксис придумать.
> Не получится ли слишком громоздко?
Может, от конкретного кода зависит. Функции, возвращающие чего-то левое (как println! в примере), которые не выходит вынести за рамки do, конечно, придется «втягивать».
Если что, я на знатока функциональных буррито не претендую, но идея кажется заслуживающей проработки)
Ну как, я относительно давно на ржавчине пытаюсь писать, так что дело не просто в непривычности.
С одной стороны, я считаю что хороший макрос являет собой цельную абстракцию, действие которой не выходит за скобки вызова, вроде как и в официальных доках чего-то такое было. А тут она берет и влияет на код вокруг.
С другой, к макросам я отношусь как к средству, к которому прибегают когда у самого языка не хватает выразительности, а тут у нас оочень частая операция. Тоже странно.
Повторюсь, каких-то жутких практических недостатков в данном конкретном случае я не вижу — согласен с Михаилом, что ситуацию спасает одиночество `try!`. Но мне было бы комфортнее, если бы вышеуказанный RFC довели до ума и реализовали, пускай оно даже один в один как `try!` работало бы. Или даже что бы таки реализовали HKT и ввели в язык do-нотацию :).
Таки-меня коробит, что для такой важной и распространенной вещи как обработка ошибок по всему коду используется макрос, который еще и меняет поток выполнения. Не то что бы я видел в этом какой-то вот прямо практический вред, нооо как-то криво это. Ожидаю рано или поздно какого-то обобщенного решения интегрированного в сам язык, вроде же были какие-то rfc.
Многие функции одалживают значения, почему бы не передавать туда константы? Пускай себе в ссылки в разные места на стеке будут, я тут плохого не вижу.
> Но так делать не рекомендуется, т.к. может возникнуть конфликт имён.
Не припомню таких официальных рекомендаций. Вот что делать `use foo::*;` в большинстве ситуаций не стоит — это да)
Не только плагины же, а любые приложения с crates.io (где в cargo.toml есть bin-секция).
https://github.com/rust-lang/rust/pull/23559
Да и большой объем информации (как rustbook) многим проще на русском осилить, даже если они вполне терпимо читают на английском.
А что именно мешает воспринимать код? Мне в голову в первую очередь локальный вывод типов приходит, но он во все языки сейчас потихоньку просачивается, вроде как уже норма (`auto auto(auto) auto` :) ).
Сейчас есть накостыленый на макросах mdo! — https://github.com/TeXitoi/rust-mdo — лучше без HTK особо не сделаешь. С ним как-то так выходит:
Если интегрировать в язык, то, наверное, можно и немного покороче/покрасивей синтаксис придумать.
> Не получится ли слишком громоздко?
Может, от конкретного кода зависит. Функции, возвращающие чего-то левое (как println! в примере), которые не выходит вынести за рамки do, конечно, придется «втягивать».
Если что, я на знатока функциональных буррито не претендую, но идея кажется заслуживающей проработки)
И это печально.
С одной стороны, я считаю что хороший макрос являет собой цельную абстракцию, действие которой не выходит за скобки вызова, вроде как и в официальных доках чего-то такое было. А тут она берет и влияет на код вокруг.
С другой, к макросам я отношусь как к средству, к которому прибегают когда у самого языка не хватает выразительности, а тут у нас оочень частая операция. Тоже странно.
Повторюсь, каких-то жутких практических недостатков в данном конкретном случае я не вижу — согласен с Михаилом, что ситуацию спасает одиночество `try!`. Но мне было бы комфортнее, если бы вышеуказанный RFC довели до ума и реализовали, пускай оно даже один в один как `try!` работало бы. Или даже что бы таки реализовали HKT и ввели в язык do-нотацию :).