Historia sięga języków programowania funkcyjnego, takich jak Haskell (call-by-need) i Scala (call-by-name), gdzie leniwa ewaluacja zapobiega niepotrzebnym obliczeniom. Swift przyjął ten wzorzec, aby umożliwić czystą składnię dla asercji i operatorów kontrolujących przepływ (&&, ||) bez utraty wydajności. Problem pojawia się, gdy argumenty są kosztowne do obliczenia lub mają efekty uboczne, a chętna ewaluacja wymusza wykonanie, niezależnie od potrzeb.
Kompilator przekształca miejsce wywołania, implicitnie opakowując wyrażenie argumentu wewnątrz zamknięcia bezargumentowego { wyrażenie }. To zamknięcie (thunk) jest następnie przekazywane do funkcji zamiast obliczonego wyniku. Gdy ciało funkcji uzyskuje dostęp do parametru, wywołuje zamknięcie, wyzwalając ewaluację w danym momencie. Jeśli chodzi o ARC, wygenerowane zamknięcie przechwytuje zmienne z zewnętrznego zakresu przez referencję; jeśli autoclosure jest oznaczone jako @escaping, alokuje kontekst zamknięcia na heapie, utrzymując wszelkie przechwycone typy referencyjne i potencjalnie wydłużając ich czas życia poza oryginalny zakres.
Weźmy pod uwagę rozwój pulpitu analitycznego dla handlu wysokoczęstotliwościowego, gdzie ciągi logowania debugowania wymagają kosztownej serializacji JSON obiektów danych rynkowych. Problem polegał na tym, że produkcyjne wersje wyłączały debugowanie, a interpolacja ciągu log("Dane: \(heavyObject.serialize())") wykonywała się przy każdym takim ticku rynkowym, niepotrzebnie konsumując 30% CPU.
Jedno z rozwiązań polegało na przekazaniu wyraźnego zamknięcia końcowego: log { "Dane: \(heavyObject.serialize())" }. To opóźnienie ewaluacji działało idealnie, ale składnia zaśmiecała kod bazowy setkami klamer, obniżając czytelność i utrudniając wyszukiwanie z użyciem grep. Programiści także od czasu do czasu zapominali o składni zamknięcia, przypadkowo wracając do chętnej ewaluacji.
Inne podejście używało makr preprocesora lub konfiguracji budowy do całkowitego usunięcia kodu logowania. Chociaż to wyeliminowało narzut czasowy w czasie wykonania, uniemożliwiało debugowanie w nagłych wypadkach produkcyjnych i wymagało osobnych wersji binarnych, co skomplikowało proces CI/CD.
Wybrane rozwiązanie zaimplementowało @autoclosure w połączeniu z @escaping dla parametru wiadomości: func log(_ message: @autoclosure @escaping () -> String). To zachowało naturalną składnię wywołania — dokładnie jak w oryginalnej chętnej wersji — gwarantując opóźnione wykonanie. @escaping pozwalał na asynchroniczne przekazywanie do tła kolejki logowania, chociaż wymagało to starannego zarządzania listą przechwycenia, aby uniknąć trzymania kontrolerów widoków dłużej niż to konieczne podczas aktualizacji grafu.
W rezultacie redukcja użycia CPU w produkcji wyniosła 28%, skutecznie obsługując 50 000 ticków na sekundę. Jednak zespół odkrył cykl zachowania, gdy zamknięcie wiadomości przechwyciło self implicitnie przez self.marketData, utrzymując kontrolery widoków przy życiu w przejściach nawigacyjnych. Jawne listy przechwycenia [weak self] rozwiązały to, ale wymagały zasad lintera, aby zapobiec regresji.
Dlaczego @autoclosure przechwytuje zmienne przez referencję, a nie przez wartość domyślnie, i jak to może prowadzić do nieoczekiwanych mutacji, jeśli zamknięcie wykonuje się asynchronicznie?
Domyślnie zamknięcia w Swift przechwytują zmienne przez referencję, aby zachować spójność ze standardową semantyką zamknięcia. Kiedy parametr @autoclosure @escaping przechwytuje var z zewnętrznego zakresu, a funkcja wykonuje zamknięcie później (np. w tle), mutacje tej zmiennej między miejscem wywołania a czasem wykonania stają się widoczne wewnątrz zamknięcia. Różni się to od chętnej ewaluacji, gdzie wartość jest ustalona w miejscu wywołania. Aby wymusić przechwycenie wartości, należy jawnie zasłonić zmienną w liście przechwycenia, jak [val = variable], chociaż ta składnia rzadko jest używana z autoclosure ze względu na jej implicitny charakter.
Jak kompilator optymalizuje nie-escape’ujące parametry @autoclosure na poziomie SIL w porównaniu do wariantów escape’ujących oraz jakie ograniczenia istnieją na te optymalizacje?
Kompilator Swift traktuje nie-escape’ujące autoclosure jako bezpośredni wskaźnik funkcji z kontekstem alokowanym na stosie, potencjalnie wstawiając ciało zamknięcia całkowicie przez specjalizację funkcji, jeśli wywoływana funkcja natychmiast to robi. Eliminuję to alokację na heapie oraz narzut związany z liczeniem referencji. Jednak, gdy oznaczone jako @escaping, zamknięcie musi alokować swój kontekst na heapie, aby przetrwać zakres funkcji, co generuje ruch retain/release w ARC. Kandydaci często przeoczają, że nawet nie-escape’ujące autoclosure mogą uniemożliwić pewne optymalizacje, jeśli zamknięcie jest przekazywane do innej nie-escape'ującej funkcji, tworząc zagnieżdżone łańcuchy thunk, które blokują wstawianie.
Jakie konkretne interakcje występują między @autoclosure a słowem kluczowym rethrows, gdy ciało autoclosure zawiera wyrażenie rzucające wyjątek, i dlaczego ma to znaczenie dla projektowania API?
Gdy funkcja jest oznaczona jako rethrows i przyjmuje rzucający @autoclosure, kompilator weryfikuje, że jedyny wyjątek pochodzi z wywołania autoclosure. To pozwala funkcji przekazywać błędy, nie będąc oznaczoną jako throws, co utrzymuje czysty interfejs dla miejsc wywołania, które nie rzucają wyjątków. To ma znaczenie, ponieważ umożliwia operatory skracające, takie jak try lhs || expensiveFailableRhs(), gdzie prawa strona jest oceniana i rzuca wyjątek tylko wtedy, gdy lewa jest fałszywa. Kandydaci często przegapiają, że rethrows z autoclosure wymaga, aby zamknięcie było jedynym elementem rzucającym wyjątek; jeśli ciało funkcji wykonuje inne operacje rzucające wyjątki bezpośrednio, kompilator odrzuca adnotację rethrows.