Почему defer из Go не принят другими ЯП?

1) Вычисление аргументов на момент задания defer, а не выхода
2) defer + цикл = попоболь

в python`е есть with для этого.

А в java есть AutoCloseable + try-with-resources.

В Haskell есть with* и bracket. Плюс тот же defer легко на коленке запилить и вынести в библиотеку.

в плюсах есть смарт поинтеры с кастомными деструкторами

Алсо причина в том, что этот defer очень паршиво работает в языках с эксепшонами. Коих большинство сейчас.

Поэтому Go – это следующая реинкарнация C (после aleph). С улучшениями и дополнениями.

Это же так удобно

Что удобного писать это каждый раз?

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

Это же древний паттерн. И в какой-то степени костыль, поскольку гораздо лучше использовать raii, try-with-resources, context manager, using и т.д. в зависимости от языка.

Эээ, зачем?

Алсо причина в том, что этот defer очень паршиво работает в языках с эксепшонами.

А можно развернуть?

Что зачем? Цикл обработки не всем нужен, и уж точно не в любом треде. Реализации отличаются эффективностью поддержкой платформ (и новых сисколлов)

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/us...

Почему defer из Go не принят другими ЯП?

Потому что в нормальных языках штуки типа `fclose` выполняются автоматически при закрытие блока

Знаю что можно костылить такую фичу через деструкторы в крестах

defer - это гораздо более кривой костыль, чем деструктор.

А потом глаза ломай смотри сверяй что все что по пути было открыто - закрыто.

Для этого есть RAII

Мне не понятно, зачем для реализации defer нужен eventLoop. Мне кажется, что и так банально реализуется. Я не прав?

в С++ RAII, вообще никакого fclose писать не нужно...

std::ifstream f(path);

Зачем Python? (комментарий)

не наблюдал такого.

В нормальном языке операции, которые надо выполнять каждый раз, засунуты в деструктор и их не нужно явно каждый раз указывать.

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

А когда он должен вызываться? Если синхронно в момент удаления f, то для этого есть unique_ptr + лямбда

Сразу после return, но до перехода обратно в вызывающий код. Просто еще одна функция в стек адресов возврата.

я тоже не могу воспроизвести. Мои извинения, почудилось.

Такую функцию легко написать самому, только выглядеть будет как

auto t = defer([f]{ fclose(f) })

А можно развернуть?

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

Потому что для этого нужен event loop

Для defer не нужен event loop.

Пример того, как defer реализуется на расширениях gcc/clang.

В D такое есть, более проработанное. В большинстве ЯП вообще есть какая-то более удобная автоматика.

Ясно, спасибо.

В свифте аналогичный.

Тело цикла не вынести в функцию - уже большая ошибка

«недодеструктор», «протез памяти» или автоматизация управления локальным scope ?

тогда уж «принимать» всю троицу: defer, panic и recover

https://docs.python.org/3/library/contextlib.html#contextlib.ExitStack

В swift есть, не надо заливать!

с другой стороны, всегда будет актуальным вопрос «что вернёт эта функция и почему?»:

func c() (i int) {
    defer func() { i++ }()
    return 1
}

Потому что это костыль. В питоне есть ContextManager, в крестах есть ifstream, в хашкиле with.

Вряд-ли для defer нужен event loop

Ну речь о других языках. Если а них нет зелёных потоков или чего-то подобного, то все очень просто. А если есть, то есть и event loop

Это не удобно хотя бы тем что это нужно писать и можно забыть.

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

Потому что для этого нужен event loop

Конечно же нет.

Ога, особенно когда цикл использует с десяток переменных.

Ну так всю программу вообще можно в одном файле в теле main() написать, тогда можно и больше, чем десяток в цикле

Это было реализовано ещё в первой версии языка «D». Когда ещё и GO то не было.
Вариант выполнения при выходе из функции.

void locked_foo()
{
    Mutex m = new Mutex;

    lock(m);                // lock the mutex
    scope(exit) unlock(m);  // unlock on leaving the scope

    foo();                  // do processing
}

Transaction transaction()
{
    Foo f = dofoo();
    scope(failure) dofoo_undo(f);

    Bar b = dobar();
    return Transaction(f, b);
}

в С++ для этого деструкторы

Суровые мужики файлы не закрывают. Пусть ОС сама следит если ей надо!

Потому, что это такой костыль для языка без аффинных типов?

Ошибку не проверил, должно быть так:

f, err = fopen(path)
if err != nil {
    return fmt.Errorf("fopen: %s", err.Error())
}
defer fclose(f)

Те мы сразу рядом написали что файл закроем. Именно рядом а не через экран строчек в каком нибудь finally или, еще хуже, в конце функции вообще.

Экран строчек возникает из-за `if err != nil`, поэтому появился `defer`, в нормальных языках о такой проблеме вообще не в курсе.

В деструкторе не надо это писать? Или там нельзя это забыть?

если коротко, то второе