It seems more consistent and unambiguous if we mark RFCs as being
implemented when the implementation lands instead of expecting to
cross-reference documentation. That also makes it easier for us to flag
stale RFCs.
(this analysis should have been done before the RFC but the thought never crossed my mind)
There's 63K assertions in all luarocks repositories combined. Out of this, around ~600 assertions would be broken as a result of this change. This is ~1% which is pretty uncomfortable (I was hoping for a couple of odd unit tests) - as such this RFC is going to get closed. We will maintain the current behavior of assert and try to adapt type checker to be reasonably useful instead.
The common thread between all of these cases (many of them target custom APIs although some target core APIs like string.match) is that assert is used together with a function that either returns nil (for errors), or multiple arguments. Under these conditions multi-arg assert is useful.
A couple examples:
```
out_r, out_w = assert(unix.pipe())
local header, body = assert(data:match "(.-\r\n)\r\n(.*)")
local z85_secret_key, z85_public_key = assert(zmq.curve_keypair())
local _, r = assert(coroutine.resume(co, msg))
```
This finishes the set of fully baked/accepted RFCs; 3 more proposals have been accepted but not implemented yet and will be submitted separately as actual RFCs.
