Rust Alpha

Мне кажется, в 1 у тебя конструкции разного назначения. Может:

fn test(f: &Fn(i32) -> i32) -> i32

?

Ссылки в тему: https://github.com/rust-lang/rfcs/blob/master/text/0114-closures.md https://github.com/rust-lang/rfcs/pull/114

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

Да.

А на уровне отдельных переменных можно?

Думаю, нет. Да и зачем?

Кстати: http://cosmic.mearie.org/2014/01/periodic-table-of-rust-types/

AFAIK, перегрузки не будет, переменное число параметров - может быть, named arguments - очень вероятно. Точно не знаю - после убиения rust-dev@ следить за разработкой очень неудобно.

мда, а так все хорошо начиналось :-/

о замыканиях

Есть два принципиально разных вида замыканий: boxed и unboxed. И для каждого из них свой синтаксис. Те, что boxed, сейчас Box<Fn(i32) -> i32> или &Fn(i32) -> i32 и передаются как аргумент.
Кроме того, есть контроль над тем, как будет использоваться замыкание: лишь один раз, много раз, с изменяемым окружением или неизменяемым.
unboxed замыкания нужны, чтобы избежать косвенной адресации.

В книге этот момент не поясняется, но всюду используется вариант |&:|

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

В Rust функции высшего порядка = замыкания, отсюда все нюансы описания прототипов функций.

в этом языке термин «синтаксический сахар» заменен на «синтаксический кал»

Лет через N все будут удивляться, мол, всё же было продумано, а получилось гогно.

Анонимные эксперты, как всегда, на высоте!

Деградировавшие плюсики.

Мне кажется, в 1 у тебя конструкции разного назначения. Может:

Почему разного? Проверил - твой вариант тоже работает, но в книге предлагают именно «мой» вариант.

Думаю, нет. Да и зачем?

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

переменное число параметров - может быть, named arguments - очень вероятно.

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

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

Лет через N все будут удивляться, мол, всё же было продумано, а получилось гогно.

Это не совсем справедливо. Я хоть и был настроен изначально весьма скептически, но часто, со временем, понимаешь, что сделали в итоге правильно, пусть и пришлось чем-то пожертвовать.

Кстати, ещё один момент. Раньше, если ничего не путаю, для «числовых констант» надо было указывать тип (если он, конечно, не мог быть выведен):

let a = 10; // нельзя, непонятный тип
let b = 10i; // ок - int

В Rust функции высшего порядка = замыкания, отсюда все нюансы описания прототипов функций.

Это ничего не объясняет. Как раз в старом варианте было точно как ты говоришь: объявление замыканий и «параметров функций» выглядело одинаково. Теперь нет.

Есть два принципиально разных вида замыканий: boxed и unboxed.

Много раз встречал упоминание этого, но прочитанные мануалы как-то не раскрывали тему. Вот сейчас нагуглил:

Short version: current closures in Rust are «boxed» in that they consist of a function pointer, and a pointer to the closure environment (which contains captured variables). LLVM has trouble inlining and optimising around these indirections.

Unboxed closures work by having each closure expand to an anonymous type which is effectively a struct that contains the captured variables, and implements one of the three kinds of «call» operator. Because there's no indirection involved, LLVM can much more easily inline and optimise these calls.

Eventually, it won't be unboxed vs. boxed closures, there will just be unboxed closures and everything will be puppies and unicorns.

Если всё так и осталось, а не устарело, то это просто детали реализации? И непонятно зачем они торчат наружу, если от них потом всё равно собираются избавиться. Смысл тогда придумывать новые синтаксисы?..

как будет использоваться замыкание: лишь один раз, много раз

Про это в курсе. Раньше было proc(), теперь стало move перед обьявлением замыкания.

с изменяемым окружением или неизменяемым.

Это в смысле, |&:| и |&mut:| или как-то иначе?

Думаю, нет. Да и зачем?

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

Если всё так и осталось, а не устарело, то это просто детали реализации?

Не просто. Прочти внимательно вот это: http://smallcultfollowing.com/babysteps/blog/2014/11/26/purging-proc/
Так как размер замыкания заранее неизвестен (так как неизвестен размер окружения), для статической диспечеризации нужна мономорфизация. Но в то же время это позволяет функциям вроде map обходиться без косвенной адресации и не уступать циклам в производительности.
Если же требуется большая гибкость, используются boxed замыкания. Они подразумевают косвенную адресацию, но мономорфизации не требуют.

Про это в курсе. Раньше было proc(), теперь стало move перед обьявлением замыкания.

Неверно. move задаёт то, как захватывается окружение, а не то, как его потом используют.

Это в смысле, |&:| и |&mut:| или как-то иначе?

FnOnce, Fn и FnMut. Им соответствуют |:|, |&:| и |&mut:|.

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

Вот простой пример: http://is.gd/dscH76. Замыкание используется несколько раз, но строка `s` перемещена из `main` в замыкание.

Мне кажется, в 1 у тебя конструкции разного назначения. Может:

Почему разного?

Первая конструкция, со старой формой замыкания - функция; вторая, из книги - дженерик. Почему так - не знаю.

Вроде же move убрали давно, нет?

Я неправильно выразился, все лямбды = замыкания.

С чего бы? Вот пример его использования: http://doc.rust-lang.org/std/thread/index.html
Да, перемещение переменных в замыкание нужно не всегда, но всё же иногда требуется.

https://github.com/rust-lang/rust/issues/4339

Ты откопал что-то ОЧЕНЬ древнее, где move имеет совсем другое значение.

Не перестаю охреневать от синтаксиса. Он по набору магических символов и нечитаемости скоро перл перегонит.

по набору магических символов

Например?

Например?

Старое-доброе:

и привычнее и читается проще.

fn test(f: |int| -> int) -> int

опять же:

int test( function<int(int)> f )

не требует дополнительных || и ->, а <> в rust и так есть

Гребаный лоркод:

(x: i32, f: F, g: G)

vs

(i32 x, F f, G g)

int test( function<int(int)> f )

И как в этой парадигме выразить ещё три трайта для замыканий?

обозначение типов как в си

Чтобы читать их можно было только по спирали? Нет уж, спасибо.

Старое-доброе

Запись типов через двоеточие есть во многих не С-подобных языках (например, в ML).

function<int(int)>

Хорошо, теперь пусть эта функция возвращает другую функцию.

не требует дополнительных ||

|| — довольно удобный синтаксис для замыканий. А fn(i32, i32) -> i32 уже используется для типа-функции (да, функции и замыкания — разные вещи).

О, Rust-тред. Чтоб два раза не создавать, как в ржавчине принято хранить данные с циклическими ссылками? Хотя бы простой случай: дерево, в котором у каждого узла есть ссылка на родителя.

http://www.reddit.com/r/rust/comments/2uv0rj/what_data_structures_are_possibl...

... То теперь сделали «int» (isize) по умолчанию. ...

Эээ, вроде нет.

Чтобы читать их можно было только по спирали? Нет уж, спасибо.

Порядок никак не связан с ':'. Просто перенеси то, что справа от ':' в начало.

int[5] xs = { 1, 2, 3, 4, 5 };

явно лучше наркоманского:

let xs: [i32; 5] = [1, 2, 3, 4, 5];

Хорошо, теперь пусть эта функция возвращает другую функцию.

alias спасет отца русской демократии:

function<foo(int)>

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

|| — довольно удобный синтаксис для замыканий

Внезапно авторы rust в данном конкретном случае с тобой не согласны:

error: obsolete syntax note: use unboxed closures instead

int[5] xs = { 1, 2, 3, 4, 5 };

Ну или [int 5], если уж хочется читать код как машина, а не человек. Для кого-то и лисповый синтаксис самый удобный и правильный.

явно лучше

«Как в С» ≠ явно лучше. Может ты ещё и говоришь в стиле «целых массивом с длинной пять является переменная xs, и равна она...»?
Даже в том же Go отошли от традиции С, и сделали по-человечески: http://blog.golang.org/gos-declaration-syntax

alias спасет

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

Внезапно авторы rust в данном конкретном случае с тобой не согласны

Он был удобен, но был недостаточно общим. Но для замыканий всё ещё используется, пример: http://goo.gl/qWdVRk

«Как в С» ≠ явно лучше

Там не как в С.

Может ты ещё и говоришь в стиле «целых массивом с длинной пять является переменная xs, и равна она...»?

Человеческий (русский в частности) язык в качестве языка программирования был бы крайне ужасен.

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

fn<fn<int(int)> (int, string, foo)>

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

Но для замыканий всё ещё используется

Не в том случае, который мы обсуждаем.

Прочти внимательно вот это

Спасибо, почитаю.

Если же требуется большая гибкость, используются boxed замыкания.

Возможно, когда прочитаю, то вопросы отпадут, но смущает, что мы в сигнатуре должны задавать какое замыкание ожидается. В С++ как-то удобнее - функция может понятия не иметь, что ей передали: лямбду или другую функцию. Или я опять не так понял?

Ну и то, что для дженериков замыкания с одинаковыми сигнатурами будут иметь разные типы. Это даёт какой-то выигрыш? Удобство точно страдает ведь.

FnOnce, Fn и FnMut. Им соответствуют |:|, |&:| и |&mut:|.

А «||» - это, судя по ссылке, «|&mut:|»?

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

Да я как бы на С++ пишу.

Замыкание используется несколько раз, но строка `s` перемещена из `main` в замыкание.

Понял, невнимательно прочёл мануал.

Эээ, вроде нет.

Хм... по моему, раньше такой код давал ошибку:

let a = 10;
println!("{}", a);

Прочти внимательно вот это: http://smallcultfollowing.com/babysteps/blog/2014/11/26/purging-proc/

Почитал. Кое-что понял, но вопросы ещё остались:

1. Получается сейчас невозможно написать функцию, которой всё равно boxed или unboxed замыкание ей передадут? Предлагается писать врапперы и/или ждать изменений в языке?

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

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

функцию, которой всё равно boxed или unboxed замыкания

Хм. А каким функциям могут понадобиться и те, и те?

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

Потому, что каждое замыкание — отдельный тип. Хотя, наверное, синтаксис можно было немного причесать.

Да, там чего-то поменяли в выводе типов для чисел, но литералы без суффиксов не становятся isize по-умолчанию, я об этом:

fn main() {
    let _: bool = 1;
}

<anon>:2:19: 2:20 error: mismatched types:
 expected `bool`,
    found `_`
(expected bool,
    found integral variable) [E0308]
<anon>:2     let _: bool = 1;
                           ^

Оно просто некое «целое число», пока вывод типов их не подхватит:

fn n(_: &u8) {}

fn main() {
    let a = 1;
    n(&a);
    let _: bool = a;
}

<anon>:6:19: 6:20 error: mismatched types:
 expected `bool`,
    found `u8`
(expected bool,
    found u8) [E0308]
<anon>:6     let _: bool = a;
                           ^

но подумали бы уже как сразу там несколько параметров красиво описывать.

В смысле? Например?

Мы и так сначала заявляем, что вот у нас есть типы (<F, G>), потом ещё раз про них говорим (f: F, g: G) и наконец-то определяем их. Я бы ещё понял, если бы where позволяло отказаться от указания типов в угловых скобках.

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

Хм. А каким функциям могут понадобиться и те, и те?

Да ведь в статье даже говорится про возможность написания враппера. Как раз, чтобы иметь возможность передавать разные виды замыканий.

А надо это для того, чтобы писать обобщённые библиотечные функции. А уже пользователь библиотеки выберет какое ему замыкание надо. А получается наоборот - советуют всегда использовать дженерик, а внутри, если надо «конвертировать».

Есть ощущение, что я не совсем понимаю идею всё-таки. Буду разбираться...

Потому, что каждое замыкание — отдельный тип.

В С++ каждая лямбда тоже имеет отдельный тип. Тем не менее, нет никаких проблем: функция может принимать std::function, хоть шаблоны. А передать можно что угодно: хоть свободную функцию, хоть лямбду, хоть «функциональный объект», хоть результат std::bind. Главное чтобы сигнатура была совместима.

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

Да, там чего-то поменяли в выводе типов для чисел, но литералы без суффиксов не становятся isize по-умолчанию, я об этом:

Хм. Интересно как, в таком случае, println влияет и во что выводит.

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

В смысле? Например?

Ну я там понимаю, что where добавили из-за того, что если всё сразу в угловые скобки пихать, то получается некрасиво. Вот над этим и поработали бы.

Ну или пусть наличие where не требовало бы угловых скобок вообще.

Да ведь в статье даже говорится про возможность написания враппера

Он там указан как временный костыль для того, чтобы не использовать &mut, разве нет?

А уже пользователь библиотеки выберет какое ему замыкание надо.

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

В С++ каждая лямбда тоже имеет отдельный тип.

Не знаю, как там в С++ сделано. Там функции параметризируются относительно лямбд?

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

Можно пример текстом, а не ссылкой на нечто глючащее?

Можно пример текстом, а не ссылкой на нечто глючащее?

Я не виноват, что play.rust-lang.org сглючил. Кстати, сейчас всё работает. На всякий случай, дублирую:

fn test<F>(a: F, b: F) -> i32
    where F : FnMut() -> i32 {
    a() + b()
}

fn main() {
    let a = test(||{ 10 }, || { 20 });
    println!("{}", a);
}

<anon>:9:28: 9:37 error: mismatched types:
 expected `[closure <anon>:9:18: 9:26]`,
    found `[closure <anon>:9:28: 9:37]`
(expected closure,
    found a different closure) [E0308]
<anon>:9     let a = test(||{ 10 }, || { 20 });
                                    ^~~~~~~~~

У тебя аналогичный код и в C++ не скомпилится. У тебя у двух лямбд разный тип.

У тебя аналогичный код и в C++ не скомпилится. У тебя у двух лямбд разный тип.

Хм... в чём-то ты прав. Тем не менее, в С++ можно так:

template<typename T>
int test(T t1, T t2)
{
    return t1() + t2();
}

int main()
{
    test<int (*)()>([](){ return 10;}, [](){ return 20;});
}

Да, мы тут пользуемся тем, что лямбды приводятся к указателю на функцию, если ничего не захватывают. Если захватывают, то так не получится. Но вообще код не эквивалентен. В отличии от примера на расте, мы тут никаких ограничений на сигнатуру не налагаем (ну кроме вызова без параметров). Правильно будет вот так:

int test(function<int()> t1, function<int()> t2)
{
    return t1() + t2();
}

Хотя я, кажется, понял.