Luau Recap: February 2022

docs/_posts/2022-02-28-luau-recap-february-2022.md

@@ -0,0 +1,140 @@
+---
+layout: single
+title:  "Luau Recap: February 2022"
+---
+
+Luau is our new language that you can read more about at [https://luau-lang.org](https://luau-lang.org).
+
+[Cross-posted to the [Roblox Developer Forum](https://devforum.roblox.com/t/luau-recap-february-2022/).]
+
+## Default type alias type parameters
+
+We have introduced a syntax to provide default type values inside the type alias type parameter list.
+
+It is now possible to have type functions where the instantiation can omit some of the parameters.
+
+You can provide concrete types:
+```lua
+--!strict
+type FieldResolver<T, Data = {[string]: any}> = (T, Data) -> number
+
+local a: FieldResolver<number> = ...
+local b: FieldResolver<number, {name: string}> = ...
+```
+
+Or reference parameters defined earlier in the list:
+```lua
+--!strict
+type EqComp<T, U = T> = (l: T, r: U) -> boolean
+
+local a: EqComp<number> = ... -- (l: number, r: number) -> boolean
+local b: EqComp<number, string> = ... -- (l: number, r: string) -> boolean
+```
+
+Type pack parameters can also have a default value:
+```lua
+--!strict
+type Process<T, U... = ...string> = (T) -> U...
+
+local a: Process<number> = ... -- (number) -> ...string
+local b: Process<number, (boolean, string)> = ... -- (number) -> (boolean, string)
+```
+
+If all type parameters have a default type value, it is now possible to reference that without providing a type parameter list:
+```lua
+--!strict
+type All<T = string, U = number> = (T) -> U
+
+local a: All -- ok
+local b: All<> -- ok as well
+```
+
+For more details, you can read the original [RFC proposal](https://github.com/Roblox/luau/blob/master/rfcs/syntax-default-type-alias-type-parameters.md).
+
+## Typechecking improvements
+
+This month we had many fixes to improve our type inference and reduce false positive errors.
+
+if-then-else expression can now have different types in each branch:
+```lua
+--!strict
+local a = if x then 5 else nil -- 'a' will have type 'number?'
+local b = if x then 1 else '2' -- 'b' will have type 'number | string'
+```
+
+And if the expected result type is known, you will not get an error in cases like these:
+```lua
+--!strict
+type T = {number | string}
+-- different array element types don't give an error if that is expected
+local c: T = if x then {1, "x", 2, "y"} else {0}
+```
+
+---
+
+`assert` result is now known to not be 'falsy' (`false` or `nil`):
+```lua
+--!strict
+local function f(x: number?): number
+	return assert(x) -- no longer an error
+end
+```
+
+---
+
+We fixed cases where length operator `#` reported an error when used on a compatible type:
+```lua
+--!strict
+local union: {number} | {string}
+local a = #union -- no longer an error
+```
+---
+
+Functions with different variadic argument/return types are no longer compatible:
+```lua
+--!strict
+local function f(): (number, ...string)
+	return 2, "a", "b"
+end
+
+local g: () -> (number, ...boolean) = f -- error
+```
+
+---
+
+We have also fixed:
+
+* false positive errors caused by incorrect reuse of generic types across different function declarations
+* issues with forward-declared intersection types
+* wrong return type annotation for table.move
+* various crashes reported by developers
+
+## Linter improvements
+
+A new static analysis warning was introduced to mark incorrect use of a '`a and b or c`' pattern. When 'b' is 'falsy' (`false` or `nil`), result will always be 'c', even if the expression 'a' was true:
+```lua
+local function f(x: number)
+	-- The and-or expression always evaluates to the second alternative because the first alternative is false; consider using if-then-else expression instead
+	return x < 0.5 and false or 42
+end
+```
+
+Like we say in the warning, new if-then-else expression doesn't have this pitfall:
+```lua
+local function g(x: number)
+	return if x < 0.5 then false else 42
+end
+```
+
+## Performance improvements
+
+For performance, we have changed how our Garbage Collector collects unreachable memory.  
+This rework makes it possible to free memory 2.5x faster and also comes with a small change to how we store Luau objects in memory. For example, each table now uses 16 fewer bytes on 64-bit platforms.
+
+## Thanks
+
+A special thanks to all the fine folks who contributed PRs this month!
+
+* [mikejsavage](https://github.com/mikejsavage)
+* [TheGreatSageEqualToHeaven](https://github.com/TheGreatSageEqualToHeaven)
+* [petrihakkinen](https://github.com/petrihakkinen)