Closed
Description
- Walkthrough of JSX SFCs and
IntrinsicAttributes
- Walkthrough of Salsa JS Class inference
- Type inference for intersection/union types
- π
- Grand unified theory of enums
- Clear your mind and let's go on a journey of imagination π β
- Imagine a "string enum"
enum Direction { North = 'north', South = 'south', ...}
type NS = Direction.North|Direction.South
- What does this declaration actually mean?
- It produces the following declarations
namespace Direction {
const North = "north"
<-const North: North
orconst North: Direction
?type North = "north"
}
type Direction = Direction.North | Direction.South | ...
- It's not just contextual typing that needs to apply here
- But we could tweak the rules
- What should the assignability of strings to string literal types be?
- It produces the following declarations
- This logic applies equally well to numbers!
- How would we enforce enum branding in this scheme for numeric enums?
- Add the ability to create 'fresh' types
- A general solution for many problems
- We could also enforce structural matching of the names
- What about
symbol
s?- Still no clear approach to handling symbol identity
- Other primitive types are coming
- Mostly numbers (
UInt64
,rational
,bignum
,struct
,vector
, etc...)
- Mostly numbers (
- What should we inline?
- Maybe
const x = 10
? With an opt-in
- Maybe
- Mutable vs immutable widening, e.g.
let x = Direction.North; // x: Direction
const x = Direction.North; // x: Direction.North
- What are the effects in e.g.
function f() { let/const x = Direction.North; return x; }
?