From 2596fd12bec3ac9fe49f833a1b940a833f24f906 Mon Sep 17 00:00:00 2001
From: Vyacheslav Egorov <vegorov@roblox.com>
Date: Tue, 1 Mar 2022 20:47:17 +0200
Subject: [PATCH] Fixed Markdown linter warnings, converted tabs to spaces and
 added a note on 'select' optimization

---
 .../2022-02-28-luau-recap-february-2022.md    | 25 +++++++++++++++----
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/docs/_posts/2022-02-28-luau-recap-february-2022.md b/docs/_posts/2022-02-28-luau-recap-february-2022.md
index 777437dd..fda7d333 100644
--- a/docs/_posts/2022-02-28-luau-recap-february-2022.md
+++ b/docs/_posts/2022-02-28-luau-recap-february-2022.md
@@ -14,6 +14,7 @@ We have introduced a syntax to provide default type values inside the type alias
 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
@@ -23,6 +24,7 @@ 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
@@ -32,6 +34,7 @@ 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...
@@ -41,6 +44,7 @@ local b: Process<number, (boolean, string)> = ... -- (number) -> (boolean, strin
 ```
 
 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
@@ -56,6 +60,7 @@ For more details, you can read the original [RFC proposal](https://github.com/Ro
 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?'
@@ -63,6 +68,7 @@ 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}
@@ -73,28 +79,32 @@ 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
+    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"
+    return 2, "a", "b"
 end
 
 local g: () -> (number, ...boolean) = f -- error
@@ -112,17 +122,19 @@ We have also fixed:
 ## 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
+    -- 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
+    return if x < 0.5 then false else 42
 end
 ```
 
@@ -131,6 +143,9 @@ end
 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.
 
+Another optimization was made for `select(_, ...)` call.  
+It is now using a special fast path that has constant-time complexity in number of arguments (~3x faster with 10 arguments).
+
 ## Thanks
 
 A special thanks to all the fine folks who contributed PRs this month!