Лайфхак для эмиграции.
#kosmonozhka

#meme про мат

#лингво #meme

Уже больше трёх лет!

Ну, не, такими темпами мы нормального нормального распределения не получим.

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

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

— Есть пиццу с помощью ножа и вилки? Я что, по вашему, похож на какого-то варвара?

Не могут никак определиться, видимо, есть у меня трафик или нет 🌝

😏 Проказа детей
💀 Проказа у детей

Я: прошу принести два кусочка хлеба

Хлеб:

Инверсия копипасты про тян #2: Эх, как же хочется массивную, загорелую, высокую, опытную в с*ксе, целованную, с накачанными руками, большими ступнями, бритую налысо альфу, успешную, с кучей друзей и подруг, открытую экстровертку, дабы вместе с ней участвовать в приятном социуме.

I don't use Arch BTW

#prog #go

Тем временем в Go предложили сделать цикл по функциям (и по числам, но сегодня речь не об этом). Если конкретно — по функциям вида func(yield func(T1, T2) bool) bool (а также func(yield func(T) bool) bool и func(yield func() bool) bool). Эти функции принимают тело цикла в виде функции, которая принимает на вход очередную переменную итерации и возвращает, нужно ли продолжать итерирование. Реализовывать это предлагают в виде синтаксической трансформации: код вида

for k, v := range iterfunc {
    // body
}

преобразовывать в

iterfunc(func (k K, v V) bool {
// body
return true
})

То есть реализовывать push-итератор (или, иначе, внутренняя итерация). Ввиду того, что в Go синтаксис вызова метода без скобок генерирует замыкание, захватывающее значение перед точкой, это делает возможным использование циклов для итераторов коллекций:

for elem := range collection.Iter {
    // ...
}

Выглядит вроде просто, но такой подход порождает кучу дизайн-вопросов. Окей, break транслируется в return false, а continue — в return true. Но вот что делать с return в теле цикла? С goto (да, он есть в Go)? С defer (особенно, если там внутри recover)? Последнее, кстати, вызвало больше всего вопросов в обсуждении. Да, это возможно всё проделать (более того, тестовая реализация, покрывающая всё это, уже есть), но семантика в этом случае вызывает вопросы. В частности:

* а как вообще отличается возврат из yield за счёт достижения конца итерации и за счёт return из функции, в которой цикл?
* что делать, если функция-итератор игнорирует возвращаемое значение yield?
* нормально ли это вообще, что при исполнении break может исполниться некий произвольный код, то есть итерация не обязательно будет немедленно завершена?
* что делать, если yield (который, я напомню, может включать в себя нелокальный control flow) утекает и вызывается вне цикла?
* можно ли сделать генерируемые компилятором проверки на подобное поведение без того, чтобы угробить перформанс из-за убогости Go-шного инлайнера?
* должны ли средства для инспектирования стека из пакета runtime показывать фреймы функции-итератора?

Всех этих проблем лишены pull-итераторы (aka внешняя итерация) — функции вида func () (T, bool). Они реализуемы на Go уже сейчас, они не требуют изменения языка¹, без проблем позволяют использовать весь control flow. А ещё — хотя я упоминания этого в обсуждении предложения не видел — позволяют сделать zip на итераторах (что на pull-итераторах, кажется, вообще не реализуемо (хммммм)). Наверное, можно подумать, что подобные итераторы уже предлагали к реализации. И вы абсолютно правы!

Но то обсуждение застопорилось по ряду причин.

Первая проблема — итерация с возможными ошибками. Честно, вот это как раз меньшая из проблем — можно было бы просто сделать стандартный обобщённый тип для пары (значение, ошибка), что и так используется в коде на Go (а ещё лучше, чтобы можно было использовать деструктуризацию — добавить наконец в язык настоящие кортежи вместо недоразумения под названием multiple function return values).

Вторая проблема — освобождение ресурсов после итерации — скажем, для итератора по содержимому файла или по результату SQL-запроса (для push-итераторов это не проблема, поскольку они могут исполнять произвольный код после вызова yield). Это вызвало кучу обсуждения на тему того, как это реализовать. В частности: нужен ли метод Stop() в интерфейсе итератора или вынести в отдельный интерфейс, кто и как должен этот метод вызывать, можно ли просто использовать io.Closer для семантики очистки ресурсов...

В конечном счёте это обсуждение просто закрыли.

Для сравнения, в языках без GC (читай, C++ и Rust) для очистки используется RAII, а в языках с GC есть средства для явного автоматического закрытия по выходу из области видимости: try-with-resources и AutoCloseable в Java, using и IDisposable в C#, with и context manager в Python. В Go есть... Финализаторы. Которые не без своих проблем (1, 2), главная из которых — они не дают никаких гарантий по тому, когда будут выполнены.

И да, я кое о чём умалчивал до этого момента. Было обсуждение, которое рассматривало и pull-, и push-итераторы. Но реализовать Russ Cox в итоге решил push-итераторы.

Воистину, проклятый язык.

¹: хотя без языковой интеграции их использование выглядит немного неловко:

for e, _ok := it.Next(); _ok; e, _ok = it.Next() {
// statements
}