O continuare Swift cu utilizare unică cere o regulă pentru lipsa reluării

O continuare folosită pentru a adapta un API bazat pe callback are două obligații: să nu reia execuția de două ori și să ofere operației suspendate un rezultat definit dacă finalizarea nu mai sosește. Proprietatea verificată static poate rezolva prima obligație fără să o dovedească pe a doua. O valoare cu utilizare unică face responsabilitatea mai ușor de atribuit; nu poate determina o operație externă să apeleze funcția de finalizare.

Această distincție ar trebui să modeleze API-ul adaptorului înainte de alegerea tipului de continuare. Succesul, eșecul și anularea trebuie să se potrivească regulilor de proprietate. La fel și posibilitatea ca sursa callbackului să nu răspundă. Un adaptor este incomplet dacă explică doar ce cale reia execuția la succes și lasă toate celelalte căi în seama presupunerilor despre componenta externă.

Acceptarea și livrarea sunt evenimente separate

Sinteza Swift despre mai, publicată la 3 iunie 2026, discută SE-0528 printre propunerile acceptate recent pentru o versiune viitoare. Ea descrie un tip Continuation care nu poate fi copiat, prin care reluarea dublă devine eroare la compilare, iar lipsa reluării provoacă o oprire la execuție. Aceasta este o dovadă despre o proiectare acceptată, nu o afirmație despre instrumentele instalate într-un anumit proiect.

Anunțul de acceptare a fost publicat la 6 mai, după încheierea evaluării la 28 aprilie. Sinteza din iunie discută ulterior acea decizie. Separarea evenimentelor împiedică transformarea unei etape de proiectare a limbajului într-o dată de lansare inventată. Răspunsurile din noiembrie despre versiunile minime ale platformelor nu fac parte din argumentul despre iunie.

Analiza practică rămâne utilă fără a prescrie o migrare imediată. O echipă poate examina proprietatea și regulile pentru eșec într-un adaptor existent chiar dacă adoptarea unui API propus nu face încă parte din planul de livrare. Întrebarea de proiectare rămâne valabilă indiferent de schimbările de nume sau de disponibilitate: cine răspunde de încheierea acestei suspendări?

Un singur proprietar oferă o garanție de siguranță

Dacă o continuare poate fi copiată liber, mai multe căi pot deține ceea ce pare o permisiune independentă de a încheia aceeași operație suspendată. Căile pot reprezenta rezultate concurente. De exemplu, un gestionar al anulării și un callback de succes pot considera fiecare că deține finalizarea. Împiedicarea duplicării elimină un mod de a exprima această eroare.

Proiectarea acceptată, care interzice copierea, dă sens transferului de proprietate. Transmiterea responsabilității consumă posibilitatea proprietarului anterior de a mai folosi aceeași valoare. Astfel se poate explica cine are dreptul să reia execuția, iar compilatorul poate respinge folosirea dublă. Garanția privește tratarea valorii de continuare, nu comportamentul sursei callbackului.

Un adaptor de rețea ipotetic arată ce rămâne nerezolvat. El poate transfera corect responsabilitatea finalizării către un obiect care așteaptă un răspuns. Dacă operația externă nu produce niciodată răspunsul și obiectul rămâne păstrat în memorie, regulile de proprietate pot rămâne coerente în timp ce sarcina rămâne suspendată. Unicitatea nu obligă mediul extern să avanseze.

Aceasta este diferența dintre împiedicarea unei acțiuni invalide și dovedirea faptului că o acțiune necesară se va produce cândva. Un API poate avea exact un proprietar și poate avea totuși nevoie de un termen-limită sau de o regulă de anulare. Aceste mecanisme trebuie proiectate după contractul extern real. Garanția de unicitate oferită de limbaj nu poate furniza acel contract în locul componentei.

Abandonarea cere o regulă explicită

Discuția de acceptare păstrează explicit oprirea la execuție când o continuare este distrusă fără să fi reluat execuția. Aceasta detectează abandonarea la distrugere. Nu stabilește o durată maximă de așteptare pentru o continuare care rămâne în viață. Folosirea acelei opriri drept mecanism de expirare ar confunda detectarea unei utilizări greșite cu o garanție de finalizare.

Adaptorul are, așadar, nevoie de o regulă pentru fiecare rezultat terminal. Dacă permite anularea, stabiliți cum încheie aceasta operația suspendată și cum este tratat un callback ulterior. Dacă API-ul extern promite un apel de finalizare, stabiliți dacă anularea schimbă promisiunea. Dacă poate să nu răspundă, identificați evenimentul care încheie așteptarea și cine poartă responsabilitatea.

Acestea sunt condiții prealabile pentru afirmația că adaptorul are un rezultat definit pe căile respective. Nu reprezintă o prescripție de a adăuga temporizatoare fiecărui callback. Unele integrări au deja un contract potrivit pentru durata operației. Altele nu pot impune un termen util fără să schimbe comportamentul produsului. Cerința este să faceți vizibilă regula aleasă, fără a presupune că interdicția copierii o stabilește.

Aceeași atenție se aplică diagnosticării. O oprire la execuție poate face vizibilă o eroare de programare, dar produsul trebuie să o deosebească în continuare de un eșec obișnuit al sistemului extern. Lipsa callbackului poate fi un defect al adaptorului, o promisiune încălcată de componenta externă sau o condiție permisă intenționat de API. Fiecare interpretare are alte consecințe pentru apelant.

CheckedContinuation poate rămâne alegerea practică

Contraargumentul cel mai puternic împotriva adoptării imediate este dificultatea integrării. Anunțul de acceptare permite explicit folosirea în continuare a CheckedContinuation acolo unde noul tip este dificil de utilizat. Aceasta delimitează practic recomandarea. Un model de proprietate mai exigent poate avea valoare fără să fie cel mai ușor de integrat în fiecare abstracție existentă bazată pe callback.

Alegerea CheckedContinuation nu elimină obligația de a analiza finalizarea. Nici alegerea unei continuări care nu poate fi copiată nu o elimină. Compromisul privește prevenirea sau detectarea folosirii greșite și modul în care codul din jur poate reprezenta responsabilitatea. El ar trebui evaluat împreună cu compatibilitatea, fără a transforma tipurile într-un clasament desprins de adaptor.

În dezvoltarea software la comandă, cereți un contract de finalizare care acoperă fiecare ieșire permisă din operația externă. Identificați proprietarul după fiecare transfer și rezultatul când finalizarea nu sosește. Alegeți apoi o reprezentare a continuării care susține acel contract și limitele verificate ale instrumentelor proiectului.