Typed parameter destructuring

[gustavopch]

What?

Civet:

Component := ({
  foo: string
  bar: number = 3
  baz as qux?: boolean = false
} & React.HTMLProps<HTMLElement>) =>
  // ...

Output:

const Component = ({
  foo,
  bar = 3,
  baz: qux = false
}: {
  foo: string
  bar: number
  baz?: boolean
} & React.HTMLProps<HTMLElement>) => {
  // ...
}

Why?

• Typing hurts.

[edemaine]

To clarify, you're proposing that JS object literal/destructuring baz: qux be replaced by baz as qux, to free up : for type annotation within object literals?

I'm not a fan of redefining JS syntax. It'd be nice to find another way...

[orenelbaum]

we could use ~

Component := ({
  foo ~ string
  bar ~ number = 3
  baz: qux? ~ boolean = false
} & React.HTMLProps<HTMLElement>) =>
  // ...

which could potentially also be used for object literals

x :=
  a ~ number: 1
  b ~ string: 'b'
  c? ~ number
//  ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ 
x := {
  a: 1
  b: 'b'
} as
  a: number
  b: string
  c?: string

[gustavopch]

I'm trying to come up with alternatives to the ~, but it's hard. I'd just change the 4th line to baz: qux ~ boolean? = false and then maybe we can open another proposal to convert something: string? to something?: string | null | undefined.

For objects, I think the output should be const x: { a; number; b: string; c?: string } = { a: 1, b: 'b' } so it's a declaration instead of an assertion.

[gustavopch]

Hum, thinking further, even if my idea of baz: qux ~ boolean? = false is made possible, there must still be some way to declare the parameter as optional without making it nullable, so baz: qux? ~boolean = false may still be needed.

[edemaine]

I'm coming around to @orenelbaum's ~ proposals but with ~ replaced by ::. For example:

Component := ({
  foo:: string
  bar:: number = 3
  baz: qux?:: boolean = false
} & React.HTMLProps<HTMLElement>) =>
  // ...

x :=
  a:: number: 1
  b:: string: 'b'
  c?:: number

:: is the typing operator in many functional languages (e.g. Haskell).

Separately, I think we should remove :: as shortcut for .prototype. outside coffeeCompat mode. I don't think people use prototype much anymore. The above should work unambiguously even with :: still enabled though, as I don't think you could use .prototype. in these contexts.

[sultan99]

I'm coming around to @orenelbaum's ~ proposals but with ~ replaced by ::. For example:

Component := ({
  foo:: string
  bar:: number = 3
  baz: qux?:: boolean = false
} & React.HTMLProps<HTMLElement>) =>
  // ...

x :=
  a:: number: 1
  b:: string: 'b'
  c?:: number

:: is the typing operator in many functional languages (e.g. Haskell).

Separately, I think we should remove :: as shortcut for .prototype. outside coffeeCompat mode. I don't think people use prototype much anymore. The above should work unambiguously even with :: still enabled though, as I don't think you could use .prototype. in these contexts.

I love this syntax, it is easy to understand where is typing and where is an object.
May be this I would like to improve:

x :=
  a:: number: 1
  b:: string: 'b'
  c?: number // 👉 ?:

[STRd6]

For the more complex situation maybe:

Component := ({
  baz? ~ boolean: qux = false
})

Another possibility:

Component := ({
  baz? as boolean: qux = false
})

Just throwing some ideas out there.

[gustavopch]

More alternatives:

Component := ({
  (baz: qux)?: boolean = false
})

Component := ({
  baz?: boolean: qux = false // The type is always needed, only the alias is optional, so the order is guaranteed
})

[esthedebeste]

In this context i think

Component := ({
  baz: qux?: boolean = false
}) =>

would look best. though i believe it could also automatically come up with the ?: in the emitted TS, because of the = false default. So:

Component := ({
  baz: qux: boolean = false
}) =>
  if qux then "Yes" else "No"

[edemaine]

~ is interesting if we can find other uses for it as a type specifier. Originally it was introduced for type annotation when we thought we couldn't use colon. Object destructuring is of course a place where we have trouble using colon, but it's the only one, so feels like a bit much...

Would it be crazy to consider different symbols than {/} for "object with inline types"? For example, maybe {: ... :} indicates that, within the object literal, all :s are type specifiers instead of renamings? So:

({x: y}) => y            // reassignment as in JS
({: x: number :}) => x   // typing

(This is somewhat inspired by Flow's {| ... |} notation for exact object types.)

Separately, we can add as as an alternative for renaming object literals (by analogy to import), which would be necessary if you wanted to type and rename, as in:

({: x as y: number :}) => y

[gustavopch]

Yeah, I feel the same way about ~.

[gustavopch]

So, another alternative that may be more consistent and less prone to invalid usage:

Component := ({
  foo:: string
  ...rest:: React.HTMLProps<HTMLElement>
}) =>
  // ...

[STRd6]

This is interesting because if you wanted to rename you could slip it in between the ::.

Component := ({
  foo:: string
  bar: baz: number
}) =>

[gustavopch]

Oh! I didn’t realize it, but yeah, nice.

[orenelbaum]

This is the same syntax as declaring constants in Jai and Odin

[edemaine]

To clarify, Odin uses name :: value or name : type : value to define constant values. Daniel was actually suggesting name: value: type, which makes more sense given that we already have name: value.

[sultan99]

What do you think if:

• ::, ?: and ::= are related to types?
• : related to objects and spreading objects

Id ::= string | number
// 👇 ts
type Id = string | number

User ::=
  id:: number
  name?: string

// 👇 ts
type User = {
  id: number
  name?: string
}

Component := ({
  foo:: string
  bar:: number = 3
  baz: qux:: boolean = false
} & React.HTMLProps<HTMLElement>) =>

Unfortunately := is taken for variable assignment, otherwise, it could be family symbols related to typing:
:: :? :=

Id := string | number
// 👇 ts
type Id = string | number

User :=
  eid:: string
  age:? number

// 👇 ts
type User = {
  id: number
  name?: string
}

[STRd6]

::= for type declaration shorthand seems nice.

[gustavopch]

Alternative: just use :: in both cases:

User ::
  name:: string

Edit: never mind, seems like a bad idea.

[esthedebeste]

User ::=
  eid:: number
  birthday?: Date

feels weird,

User ::=
  eid: number
  birthday?: Date

is better i think. Aside from that, total +1 on ::= for types.

[edemaine]

Now that I finally understand #126 (reply in thread) (thanks @gustavopch for explaining!), I propose:

name: [value][: type] i.e.:

• name: value (as usual)
• name (as usual, equivalent to name: name)
• name: value: type (think of this as (name: value): type)
• name:: type
• Also ?: can be used in place of ::

So object literals look like this:

id := 5
user :=
  id:: number
  name: 'John': string
  age?: number
↓↓↓
const id = 5
const user: {
  id: number,
  name: string,
  age?: number
} = {
  id,
  name: 'John'
}

Destructuring declaration:

{id:: number, name: userName: string} := obj
↓↓↓
const {id, name: userName} = obj as {id: number, name: string}
OR
let id: number, userName: string
{id, name: userName} = obj

Destructuring non-declaration {...} = obj would ignore types specified... or maybe still add the as ... suffix to obj?

Function:

({id:: number, name: userName: string, age?: number = 18}) => ...
↓↓↓
({id, name: userName, age = 18}: {id: number, name: string, age?: number}) => ...

[gustavopch]

user :=
  id:: number
  name: 'John': string // Here, it looks like what's being typed as `string` is the value 'John', but in reality we're typing the property `name`. There's a semantic difference in those two.
  age?: number

[edemaine]

I like to think of name: 'John' as being typed as string. I agree it's not perfect.

We can think of {name: 'John': string} as {name: 'John'}: {name: string} so it does make some sense for : string to be on the right.

[gustavopch]

The type error in TS usually happens when the thing on the right doesn't conform to the thing on the left. This proposal works the opposite.

[STRd6]

• Also ?: can be used in place of ::

This might cause overlap when declaring an optional parameter that has a specified value.

person :=
  age?: 7
  name?:: string

would be unambiguous.

[esthedebeste]

I personally don't see the need for typed object literals, can't values already be as'd into their demanded types a la

user :=
  name: 'John' as 'John' | 'Esther'
// or `as const` to get a 'John' type, or `as string` if you're insistent on specifying, whatever may be needed

Optionality is the most important thing here i think, could be specified with something like

user :=
  birthday?: Date
  name: 'John'

// Later...
user.birthday = new Date()

and

user := 
  birthday:? new Date()
  name: 'John'

// Later...
delete user.birthday

[gustavopch]

I propose that we try to keep:

• Left: related to name
• Middle: related to type
• Right: related to value

I believe that's just where people expect things to be when they read the code as you can see in all these cases:

const name: Type = value

const name: Type = {
  name: value
}

const name: Type = (name: Type = defaultValue) => {}

const name = ({
  name: newName = defaultValue
}: {
  name: Type
}) => {...}

So here's how it would look:

user :=
  name:: string: 'John'
  age?: number
↓↓↓
const user: {
  name: string
  age?: number
} = {
  name: 'John',
}

createUser := ({
  id: userId:: string
  name:: string
  age:: number = 0
  ...rest:: OtherProps
}) =>
  // ...
↓↓↓
const createUser = ({
  id: userId,
  name,
  age = 0,
  ...rest
}: {
  id: string
  name: string
  age: number
} & OtherProps)

More generally:

obj :=
  name[::type]:value

fn := ({
  name[:alias][::type][=defaultValue]
}) =>
  // ...

ATM, I think this is the best if we want to optimize for readability.

[edemaine]

I'd propose that we hide the .prototype. shorthand behind a coffeePrototype flag. prototype is a pretty rare thing to use these days, and :: is valuable real estate. It should mainly be there for CoffeeScript compatibility.

[STRd6]

Sounds good, :: is shaping up to be a very type related symbol that could be useful in many places. If we want to add a .prototype. shorthand we could choose a different one if we feel a big enough need.

[edemaine]

Personally I find myself using .constructor a lot more than .prototype. LiveScript uses @@ for this which looks quite intuitive, but it sadly conflicts with our decorator syntax. Anyway, we should take this to another thread. 🙂

[gustavopch]

No problem: @@@ hehe

[esthedebeste]

Related, how would you write user := {name} where name is typed as string?

Stuff like

user := { name() }
// const user = { name: name() }

is currently possible, this syntax could be extended to as:

user := { name as string }
// const user = { name: name as string }

[edemaine]

Implemented in #1383!