Add support for destructuring parameters + default values

[TylerEich]

I'm using ES6's new destructuring parameters with default values per the reminder from Brendan Eich (via 2ality.com).

So I would like to do this:

function rgba({ r, g, b, a = 1 }) {
    return [ r, g, b, a ];
}

Flow is throwing an Unexpected token = error at a = 1. Interestingly, JSHint has an issue with this pattern too.

[rauchg]

+1

[ghost]

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[cesarandreu]

I have a question related to this issue: What's would be the expected behavior for typing params with default values?

My usage of default params tends to enforce strict types, e.g. this field is either 1 or some user-defined number, but it is always a number.

Considering the following:

/* @flow */
type params = { a: number }
function fn ({ a = 1 }: params): params {
  return { a }
}
fn({})

Would I get an error for not passing in an object that has a set to a number? It's optional, so I'm guessing it should probably be annotated as { a?: number } or { a: ?number }?

[rauchg]

It could also infer the type from the default value? Making a?: number unnecessary to write (perhaps more obscure).

[samwgoldman]

@cesarandreu It would be { a?: number }, which is the same as { a: void | number }. ?number is the same as void | null | number. null is not a real type annotation in Flow (edit: it is now), but the point remains.

[cesarandreu]

Thanks!

[samwgoldman]

@eyyub You have some work on this. I looked over your branch and I think it makes sense to try to land the parsing support first, then the type checking support separately. If you don't have bandwidth to do this, would you mind if I tried to put a bow on what you have so far?

[eyyub]

@samwgoldman Np I agree ! And yes sorry I don't have 'a bandwith' (nice expression :p) to do this actually, so do as you want and do not hesitate to ask me if something is weird on my branch !

[Arilas]

Any updates for this issue?

[AlexGalays]

I need diz !

Having to refactor

const { a, b = false } = obj

into

let { a, b } = obj;
if (b === undefined) b = false;

Just to please flow is very annoying :(

[trobertsonsf]

Would love to get a fix for this. Lack of support for such a nice language feature makes it feel like I'm getting handcuffed by flow =/

[samwgoldman]

[Accidentally placed this comment in the wrong thread. Putting it here for posterity.]

I had a fair amount of WIP on this, but I tossed it out and haven't revisited.

My take is that this commit is too hacky and we shouldn't merge it. We need to separate parsing of objects and parsing of destructuring. Right now we do this weird thing where we parse an object, then transform it. Object syntax doesn't have defaults, so that method no longer works.

Ultimately this just confuses parsing support for assignment expressions ({ foo = bar } = obj). It's actually significantly simpler to just handle the case for params and variable declarations, which happens to be where destructuring+default is most often found.

I can still loop back on this in the coming weeks, but if someone is looking for something to do, please take it. If you do, I heartily recommend starting with the params/declaration cases and punting on assignment exprs. That's just me, though.

[0xR]

This is currently the biggest missing es2015 feature. Not being able to write the full es2015 spec makes it difficult to consider moving to flowtype. Therefore I hope this is a high priority missing feature.

[bakape]

Considering ES2015 parameter syntax is already implemented by all 3 major browsers, this is a sever limitation of Flow.

[samwgoldman]

Yup, this has been on my plate for too long. I've been blocking this because I started working on it, then joined Facebook where I'm still getting used to things. Thanks for your patience. This feature is really high on my list of things to get out the door.

[lleaff]

Flow fails to parse this valid ES2015 code:

var href = 'https://github.com/facebook/flow/issues/183'
var HREF_REGEXP = /^([^#?]*)(\?([^#]*))?(#(.+))?$/;
var [, path='', , query='', , hash=''] = HREF_REGEXP.exec(href) || [];
//                ^ Unexpected token ,

(flow.org/try)

The parsing error is suppressed if we put some dummy variables in the holes or if we remove the default assignments.

[goldhand]

Shouldn't types from destructured params with default values be inferred from the default value as mentioned in @rauchg comment? It seems really redundant and verbose to do:

const flex = ({x = 'center', y = 'center'}: {x: string, y: string} = {}) => ({
  display: 'flex',
  justifyContent: x,
  alignItems: y,
});

seems like this should be enough:

const flex = ({x = 'center', y = 'center'} = {}) => ({
  display: 'flex',
  justifyContent: x,
  alignItems: y,
});

Sorry if there is already support for this already by my flow linter is lighting up

[Leksat]

Same as reported by @alexfedoseev, but with optional type: http://bit.ly/2rYnuYg

type params = { a?: ?number }
function fn ({ a = null }: params): params {
  return { a }
}
fn({})

[Jacse]

It's been more than two years since this issue was opened and it still doesn't work properly. What's the state of the issue? @samwgoldman did you improve on the partial fix?

[pascalduez]

Hi,

wondering whether this is related to an issue I'm having with default rest parameters and union types:

https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVAXAngBwKZgAqAFngLZ4ByAhhWALxgDkAlgHZRxNgA+zAzgFcAxsLz9+3PkwTUATm3YBzKcwAm1NkrxymAbnTZ8RUnUYBvVGDAthcNgC4w-DHOUAaK2Dvw5Tl25angC+Bpi4BCTkeAAKcnA4DCbRvMkUNBRhRgRxCfxJltYYpngA-E5RFLk4IWFQgmzCGCz2YABicHAAFOZgxSmMrBxcYMFO1fwAlGCFYKjBQA

[lukemartin]

Flow fails with this very simple example of specifying a maybe type with a default null value:

const foo = ({name = null}:{name: ?string}) => {
	console.log(name);
}

1: const foo = ({name = null}:{name: ?string}) => {
             ^ null or undefined. This type is incompatible with
1: const foo = ({name = null}:{name: ?string}) => {
				^ string
1: const foo = ({name = null}:{name: ?string}) => {
						^ null. This type is incompatible with
1: const foo = ({name = null}:{name: ?string}) => {
				^ string

https://flow.org/try/#0MYewdgzgLgBAZiEMC8MAUBvMBDAtgUxRjAFcAbMgXwC4s99qYB+aAJwEswBzSgShQB8MDACgAkKEggy+AHRkQXNDgK8A3CMpA

[Rohit-L]

Is anybody from the flow team going to comment on this?

[simlu]

We are running into the exact problem that @lukemartin describes. Would be great to get this fixed or at least have someone from the team comment on it.

[sibelius]

what is still failing?

[simlu]

@sibelius lukemartin has provided a good example. Do you have problems understanding it?

[lukemartin]

hey @sibelius - this throws errors in 0.76.0:

const foo = ({name = null}:{name: ?string}) => {
	console.log(name);
}

https://flow.org/try/#0MYewdgzgLgBAZiEMC8MAUBvMBDAtgUxRjAFcAbMgXwC4s99qYB+aAJwEswBzSgShQB8MDACgAkKEggy+AHRkQXNDgK8A3CMpA

[Naddiseo]

Using $Subtype around the annotation seems to work, but I'm not sure if that's the right way to go in all situations.

const foo = ({name = null}: $Subtype<{name: ?string}>) => {
	console.log(name);
}

https://flow.org/try/#0MYewdgzgLgBAZiEMC8MAUBvMBDAtgUxRjAFcAbMgXwC4YASAZRICMoBPAB3wB4s99aAfmgAnAJZgA5pQB8AShQyYGAFABIUJBBl8AOjIhJaHATkBuFZRVA

[Buggytheclown]

const foo = ({name = true}: $Subtype<{name: ?string}>) => {
  //                 ^ flow does not check this
  console.log(name);
}

As proposed in SO

function foo(arg: {name: ?number}) {
  const { name = 42 } = arg;
  // the default value is only used for undefined values.
  console.log((name: (number | null)));
}

[simlu]

@Buggytheclown Not a big fan of changing code to accommodate flow. In our scenario (jetbrains) this would cause us to lose introspection as well.

[tomscallon]

Perhaps a separate issue, but I'm having a very similar problem with non-maybe types. I'm trying:

/* @flow */

type P = string | Array<string>;

function p(p: P = []) {}

type O = {p: P};

function o({p = []}: O) {}

And I get the following errors:

9: function o({p = []}: O) {}
               ^ array type [1] is incompatible with string [1].
References:
7: type O = {p: P};
                ^ [1]
9: function o({p = []}: O) {}
                   ^ empty array literal [1] is incompatible with string [2].
References:
9: function o({p = []}: O) {}
                   ^ [1]
7: type O = {p: P};
                ^ [2]

Interestingly, the errors go away if I simplify the type P to Array<string>. It's almost like Flow is expecting my default value to be all of the unioned types, rather than just one of them.