Verificați ramura returnată înainte ca any să ascundă problema

O funcție care promite un anumit rezultat ar trebui să respecte promisiunea atât când găsește valoarea în memoria cache, cât și când aceasta lipsește. TypeScript 5.8 a făcut obligația mai ușor de verificat în situațiile în care o ramură cu tipul any ascundea incompatibilitatea celeilalte ramuri. Răspunsul util la noul diagnostic este repararea căii care încalcă tipul de retur declarat, nu afirmarea printr-o aserțiune de tip că întreaga expresie îl respectă deja.

Retrospectiva de față, scrisă în noiembrie 2026, privește lansarea din 28 februarie 2025. Verificările mai restrânse ale ramurilor apăruseră și în anunțul versiunii candidate din 13 februarie. Lucrările mai ample asupra tipurilor de retur condiționale au fost retrase din acea lansare. Prezentarea tuturor îmbunătățirilor discutate în jurul versiunii beta drept funcționalități livrate în 5.8 ar exagera schimbarea istorică.

Combinarea ramurilor poate pierde informație

Notele de lansare prezintă o funcție declarată să returneze URL. O ramură condițională citește dintr-o memorie cache fără tipuri precise; cealaltă returnează șirul inițial în loc să construiască obiectul lipsă. Prima ramură are tipul any, iar a doua are tipul string. Când reuniunea tipurilor expresiei devine any, șirul incompatibil nu mai este vizibil pentru verificarea obișnuită a compatibilității cu URL.

Mecanismul este mai precis decât afirmația că verificarea compilatorului a devenit mai strictă. Implementarea conținea deja o ramură al cărei tip cunoscut contrazicea rezultatul declarat. O altă ramură, permisivă, făcea dovada să dispară înainte de compararea expresiei complete cu acel contract. Verificarea din 5.8 examinează mai detaliat ramurile față de tipul de retur așteptat, astfel încât contradicția poate fi raportată.

Distincția contează deoarece calea care găsește valoarea în cache poate induce în eroare la inspecție. Un evaluator poate vedea că funcția obține de obicei un obiect și poate rata calea care trebuie să îl creeze. Adnotarea rezultatului consemnează ce are dreptul să aștepte fiecare apelant. Fiecare cale din implementare ar trebui să susțină acea așteptare, inclusiv cea urmată când datele stocate lipsesc.

Îmbunătățirea compilatorului are totuși o limită. Faptul că ramura cunoscută ca string primește acum un diagnostic nu dovedește că valoarea cu tipul any este un obiect URL valid. Repararea unei ramuri incompatibile nu validează conținutul memoriei cache. Noua verificare este utilă tocmai când domeniul ei rămâne clar.

Reparați implementarea înainte să schimbați promisiunea

Dacă funcția trebuie să construiască un obiect când valoarea lipsește, construiți acel obiect. Dacă produsul permite cu adevărat mai multe forme ale rezultatului, descrieți-le în tipul de retur și actualizați apelanții pentru a trata alternativele. Sunt decizii de proiectare diferite. Lărgirea adnotării doar pentru a elimina eroarea poate muta un detaliu accidental al implementării în interfața publică.

O aserțiune de tip aplicată întregii expresii returnate oferă altă ieșire. Poate face codul să pară compatibil, păstrând ramura care încalcă promisiunea. Astfel se schimbă dovezile disponibile următorului evaluator: codul conține acum o instrucțiune explicită de a avea încredere în autor chiar în locul unde compilatorul a găsit o contradicție.

Costul practic este descoperirea întârziată. Un apelant poate încerca o operație potrivită pentru obiectul promis și poate primi în schimb un șir. Într-o aplicație de firmă, eroarea poate apărea astfel mai departe de absența din cache care a provocat-o. Este un traseu ilustrativ al unei defecțiuni, nu relatarea unui incident sau a unei reduceri măsurate a muncii de suport după actualizarea TypeScript.

La analiză, identificați mai întâi contractul real al rezultatului. Examinați apoi cum obține sau construiește fiecare ramură valoarea. Restrângeți tipurile intrărilor incerte prin verificări care stabilesc proprietățile cerute de operația următoare. Adnotarea rezultatului este mai utilă când concentrează o promisiune stabilă decât când doar repetă valorile produse întâmplător de implementarea actuală.

Aserțiunile pot avea loc după validarea unei intrări externe

Cel mai puternic contraargument este că datele externe și tipurile bibliotecilor nu vin întotdeauna cu declarații care exprimă ce a stabilit aplicația. O aserțiune justificată poate lega validarea din timpul execuției de o interfață statică atunci când compilatorul nu poate reprezenta adecvat relația. Interzicerea tuturor aserțiunilor ar confunda instrumentul cu dovezile care îi susțin folosirea.

Limita trebuie să rămână ușor de examinat. Precizați ce validare a avut loc, ce proprietate stabilește și ce afirmă aserțiunea. Dacă validarea arată doar că un câmp există, o aserțiune care declară un obiect complex complet depășește dovezile. Aserțiunea poate consemna o limită justificată a sistemului de tipuri; nu ar trebui să înlocuiască însăși validarea lipsă.

Distincția păstrează analiza proporțională. O aserțiune la o intrare externă verificată atent merită altă discuție decât una adăugată în fluxul obișnuit al funcției pentru a suprima incompatibilitatea unei ramuri returnate. Prima poate exprima cunoaștere stabilită în altă parte. A doua poate doar ascunde o greșeală pe care implementarea o poate corecta direct.

Separați funcționalitățile vecine ale compilatorului

Aceste verificări ale rezultatului nu stabilesc dacă sintaxa TypeScript poate fi ștearsă pentru execuție. Opțiunea erasableSyntaxOnly privește acea limită separată a instrumentelor. Verificările diferă și de diagnosticele pentru expresii evaluate mereu ca adevărate. O condiție validă poate alege între rezultate incompatibile; condiția însăși nu trebuie să fie suspectă pentru ca promisiunea rezultatului să fie încălcată.

O analiză utilă a actualizării grupează deci noile diagnostice după promisiunea protejată. Pentru acesta, examinați o funcție afectată și apelanții ei, reparați calea cunoscută ca incompatibilă și analizați separat orice intrare rămasă fără tip precis. Nu prezentați o compilare fără erori ca dovadă a validității în execuție a intrărilor nevalidate.

Pentru dezvoltare software la comandă, cereți urmărirea unui contract important al rezultatului atât pe calea obișnuită, cât și pe cea alternativă. Întrebarea de acceptare este concretă: produce fiecare cale ceea ce li s-a promis apelanților? TypeScript 5.8 ajută la găsirea răspunsului pe care any îl ascundea. Implementarea trebuie în continuare să furnizeze rezultatul corect.