Подробнее
I ЛУЧШЕ'МЕНЯ? т СЕБ я kl UIUÜ di • 1/ . ■ Xdi -к ^ \ jL_V 11
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Еще на тему
it-юмор geek
Подробнее
I ЛУЧШЕ'МЕНЯ? т СЕБ я kl UIUÜ di • 1/ . ■ Xdi -к ^ \ jL_V 11
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Подробнее
I ЛУЧШЕ'МЕНЯ? т СЕБ я kl UIUÜ di • 1/ . ■ Xdi -к ^ \ jL_V 11
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Тут, конечно, ебаные эксепшены, но можно и без них при большом желании, например, написать свой враппер над старым добрым маллоком.
Лично я чаще использую for/foreach/map/filter, чем do-while, и полностью согласен с картинкой.
continue INNER;
нахер goto
for case let object as SomethingProtocol in objects { }
или
for object in objects where object is SomethingProtocol { }
Очень удобно когда надо пройтись по фильтрованному массиву без сдвига индексов или предварительной фильтрации
Суть в том, что так с отфильтрованной коллекцией ничего нельзя сделать, кроме как пройтись по ней здесь и сейчас. Сохранить в переменную? Нет. Передать в функцию? Тоже нет. Второй раз пройти? Нет, надо снова писать такой же цикл!
Гораздо удобнее подход с filter в функциональном программировании или с generator expression in python. В этих случаях отфильтрованная коллекцию можно переиспользовать и/или сохранять в переменную/передавать как аргумент.
В любом случае Swift это опенсорс проект (на данный момент последняя версия Swift 5) и у любой фичи языка есть четкое обоснование и одобрение сообщества. Не правильно говорить что это какая-то муть.
Такая конструкция красивее простого цикла, хотя менее гибкая, чем filter+map и их аналоги на итераторах.
Результат filter можно засунуть в любое место, куда можно было засунуть массив, даже в тот же цикл с фильтрацией. Код становится более однородным, для разных обходов и преобразований коллекции используются одни и те же инструменты.
Понадобилось наложить фильтр на фильтр - filter удобнее цикла. Понадобилось отложить выполнение: сначала вычленить нужные элементы, а потом где-то стереть из них текст - filter удобнее цикла. Понадобилось применить стандартный алгоритм (например, в C++, что-нибудь из алгоритмов из STL) - filter удобнее цикла, для цикла надо реализовывать алгоритм ещё раз.
Хитрый цикл усложняет язык, а filter пишется в рамках существующего языка, в зависимости от задачи можно реализовать версию с копированием в новый список или, версию с итератором, чтобы O(1) по памяти. Если написать правильный bidirectional итератор, можно с помощью std::sort отсортировать отфильтрованные элементы прямо на их местах в коллекции. Написать несколько строк кода на обычном языке для конкретного проекта - гораздо проще и спокойнее, чем ждать месяцы заседаний комитетов, утверждений фичи, добавление в компиляторы, поддержка фичи долгие годы (из-за чего обновлённый язык выглядит уродливо), невозможность простого удаления фичи, если ей воспользовались в куче старого кода.
Чёткое обоснование можно к любой фиче написать. Формально восьми операций языка brainfuck хватает для написания любых вычислительных программ, всё остальное - мнения и оценки стоимости конкретных проектов с конкретными исполнителями :)
Сообществу не стоит доверять. Сообщества обычно плодят усреднённые компромиссные решения, рассчитанные на потребителя с усреднёнными показателями (которого не существует). А главное - полёт фантазии сообщества ограничен привычками, уже реализованными фичами и представлениями по здравом смысле.
foreach (arr.grep(...).sort(...)) ?
В третем это проход по массиву через for это конечно можно рассматривать как вызов функции для элементов массива, но этот вызов происходит для исходных элементов. Нет процесса фильтрации (создания отфильтрованного массива). Это довольно легко проверить на массиве большого размера.
GOTO