Наконец-то запилили новость.

Цикл for: внутренний итератор (как в Ruby) заменен внешним (как в Python)

Это как?

Цикл for: внутренний итератор (как в Ruby) заменен внешним (как в Python)

Не совсем как в Python - в Rust приходится писать

for elt in cont.iter()

Шекспир

O happy dagger,

This is thy sheath.

There rust and let me die.

Рантайм теперь полностью переписан с C++ на Rust. Пока он еще не вполне готов, и можно ожидать сегфолты и странное поведение программ на глубоких уровнях рекурсии.

Успех.

* Arithmetic operations have been implemented on the SIMD types in `std::unstable::simd`.

Ого

* extra: Performance of JSON parsing greatly improved.

Готов для продакшена!

А вообще, это пока язык для дизайнеров языка:

cdshines@v3700:~|⇒  wget -qO- https://mail.mozilla.org/pipermail/rust-dev/2013-September/005804.html | egrep -i "remove|changed|rename" | wc -l
24

зачем он нужен? где применим? в чём преимущество перед тучами других языков? это замена xul?

в гугле забанили

Вот если в Firefox новая JavaScript-VM будет называться Pede, будет очень весело...

Тихо и незаметно вышла новая версия Rust — языка программирования...

Тихо и незаметно пополнен список ненужных языков программирования. Расходимся поцоны.

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

Не знаешь, почему так сделали?

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

Ну почему?

Потому что лишнее это.

Так удобнее в дальнейшем прикручивать разные итераторы

Для этого не обязательно делать именно так. Нужно было делать как в Python:

for a in b:

Если b - итератор, то по нему делается итерация; если нет, проверяется, есть ли у него метод __iter__, и, если есть, он вызывается и по его результату делается итерация. Если тебе нужен хитрый порядок итерации, нет проблем:

for a in b.tricky_traversal():

Без понятия. В списке рассылки говорили «как в Python».

Помоему

* The `for` loop syntax has changed to work with the `Iterator` trait.

переводится иначе чем

«Цикл for: внутренний итератор (как в Ruby) заменен внешним (как в Python).»

Там написано, что for теперь работает с итератором ^_^.

В модных забугорных бложиках про это пишут со словами architecture inconsistency. Хотя, может, это и вкусовщина.
А что в случае с деревом, кстати? Определять __iter__ через какой-то дефолтный inorder/preorder/etc? Не определять вообще?

Полагаю, дело в обратной совместимости. Новый итератор уже сделали, а iter() остался от старого. Через пару релизов, наверное, сделают интерфейс Iter, которому будут наследовать все коллекции.

В модных забугорных бложиках про это пишут со словами architecture inconsistency.

Про что «это» и в каких бложиках?

А что в случае с деревом, кстати?

Любой из предложенных тобой способов подойдет.

Полагаю, дело в обратной совместимости

Полагаю, что нет.

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

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

Снова кто-то изобретает велосипед. или велосипедный навес?..

Велосипедный насос.

тем лучше! (спасибо за идею, велосипедный насос надо записать...)

нужно делать подход погибче

Что не так с гибкостью подхода Python?

мне нравиться как выглядит синтаксис, и tutorial хорошо написан, вот бы сразу с и с++ такой сделали.

И еще более 2200 изменений.

Вот это я понимаю, круто.

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

При чем здесь вообще питон?

https://mail.mozilla.org/pipermail/rust-dev/2013-August/005115.html

как-то ты с питоном выскочил непонятно к чему.

Я думал, ты читаешь rust-dev@ и в курсе.

Нет, просто казуально слежу за проектом.

Обсуждаемый нами сабж суть сахар и вкусовщина, и срача не стоит, по-моему. Лишь бы работало шустро.

Собственно, в питоне на уровне соглашений принято, что __iter__() возвращает итератор, то есть, какой-то объект [класса] с сигнатурой next() и raise StopIteration. Каким этот объект будет в случае сложных структур, ну, например, того же дерева - это, в общем случае, решать программисту. Хотя, разумеется, для каких-то стандартных случаев есть общепринятые умолчания.

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

велосипедисты...

И еще более 2000 изменений.

И при этом номер версии увеличился с 0.7 до 0.8, а не как у мозилловского же Firefox. Радует, что хоть кто-то у них остался непокусанным переносчиками погони за циферками.

FF вначале тоже прошел те же версии, и даже больше - у них был 0.7.1, например, а не сразу 0.8

Это ты покусан переносчиками погони в обратную сторону.

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

Цикл for: внутренний итератор (как в Ruby) заменен внешним (как в Python).

Это как? Я не знаю ни Ruby ни Python.

не понятно чем их freepascal не устраивает... "->" для указания возвращаемого типа имхо не удобно

И опять какой-то свой синтаксис. Но зачем? Что мешает реализовать новомодные фичи ЯП в рамках сиподобного синтаксиса?

"->" для указания возвращаемого типа имхо не удобно

За то наглядно.. для всякого, кому в ПТУ преподали хоть капельку матана.

И опять какой-то свой синтаксис. Но зачем? Что мешает реализовать новомодные фичи ЯП в рамках сиподобного синтаксиса?

В случае Rust и Си, отличия в синтаксисе это сущая ерунда на фоне отличий в семантике.

И опять какой-то свой синтаксис.

Почему свой? Basic

Экспериментальная фича — новая подсистема ввода/вывода.

то планировщики, то подсистемы ввода, что это, язык общего предназначения? Ждём RustOS

int func(); не наглядно? Каждый раз при определении функции будешь набирать два доп знака

int func(); не наглядно?

Нет. Наглядно - это вот так: http://upload.wikimedia.org/math/e/5/4/e54d1b1b812183f9045540811024fe6d.png (общепринятая нотация для обозначения функции, действующей из множества X во множество Y)

Каждый раз при определении функции будешь набирать два доп знака

Точка-с-запятой в конце каждой строки должна удручать гораздо больше ;)

в гугле забанили

ССЗБ

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

опять какой-то свой синтаксис.

Почему свой? Basic

Где ты там Basic увидел?

Да математикам вобще по барабану, они руками пишут все свои странные символы.

Напомню, что речь шла о наглядности. Использование общепринятый нотаций повышает наглядность.

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

Может, ты еще и против имен переменных длиннее 3 символов? Ну, чтобы сэкономить при печатании? :D

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

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

google:«APL keyboard»