Почему автоматическое закрытие над строковым литералом?

Question

У меня вопрос к автоматическому закрытию. Например, у нас может быть функция с автоматическим закрытием, подобная этой

func logHello(ifFalse condition: Bool,
         message: @autoclosure () -> String
    ) {
    guard condition else {
        return
    }
    print("Assertion failed: \(message())")
}

причина, по которой автоматическое закрытие используется чаще, заключается в том, что мы хотим отложить выполнение замыкания для тела функции, но какой в ​​этом смысл?

У меня может быть что-то вроде этого

func logHello1(ifFalse condition: Bool,
              message: String
    ) {
    guard condition else {
        return
    }
    print("Assertion failed: \(message)")
}

вообще не использует замыкание, а только конечный результат, который может дать замыкание. Разве это не лучше?

Я видел, как aotuclosures использовались в утверждении и других реализациях быстрой нативной функциональности, но меня просто озадачивает, почему мы не можем просто передать literal вместо замыкания?

В чем преимущество использования автоматического закрытия в этом случае?

Answer 1

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

Рассмотрим в качестве конкретного примера:

logHello(ifFalse: true, message: expensiveString())

С автозаполнением, expensiveString() никогда не будет вызван. Без него он будет вызываться всегда, даже если результат никогда не используется.

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

Вы правы, что нет преимущества в производительности над строкой литерал , но если вы это имеете в виду, параметр message должен иметь значение StaticString, а не String.