Hola, I’m Hieu, a Software Engineer

Before records, returning two values from a function meant one of three unappealing options: a class you use once, a List<Object> you index into, or two out-parameters via a wrapper. Records make it one line. ({ int width, int height}) measure ( String text) { // ... return (width : 120 , height : 40 ); } final size = measure ( 'hello' ); print (size.width); That is the headline feature, and it is the smallest part of what records and patterns changed. Records: structural, not nominal A record’s type is its shape. (int, String) and (int, String) are the same type regardless of where they were created, which is what distinguishes a record from a class. // Positional ( String , int ) parseEntry ( String line) { final parts = line. split ( ':' ); return (parts[ 0 ], int . parse (parts[ 1 ])); } // Named — clearer at the call site ({ String name, int score}) parseNamed ( String line) { final parts = line. split ( ':...

Every codebase past a certain size has this bug at least once: void transfer ( String fromUserId, String toAccountId, int cents) { ... } transfer (accountId, userId, 500 ); // compiles fine, wrong at runtime Both are String , so the type system has nothing to say. The usual fix is a wrapper class, which costs an allocation on every ID you touch. Extension types are the same fix without the allocation. extension type UserId ( String value) {} extension type AccountId ( String value) {} void transfer ( UserId from, AccountId to, int cents) { ... } transfer (accountId, userId, 500 ); // compile error At runtime, UserId is a String . There is no wrapper object, no field access indirection, nothing allocated. The distinction exists only in the static type system, and is erased before the program runs. What “erased” actually means This is the part that decides whether extension types fit your problem. The compiler replaces the extension type with its representation...