Default values for destructuring parameters

[timoxley]

What I'm proposing is the ability to supply default values for parameter lists (note the {}):

# this works:
constructor: (name, description = 'no description') ->

# so does this:
constructor: (@name, @description = 'no description') ->

# this does not works:
constructor: ({name, description = 'not described'}) ->

# nor this:
constructor: ({@name, @description = 'not described'}) ->

I was surprised when this didn't compile, considering you can set defaults for regular named arguments, and also destructuring arguments (i.e. all types of named arguments except parameter lists).

It'd also be nice to be able to describe parameter lists over multiple lines, but I couldn't think of a way to do it without making it rather ({ugly}), eg:

constructor: ({
    @name
    @description 
}) ->

edit: the above actually works.

Additionally, the destructuring parameter lists syntax isn't mentioned in the docs anywhere, and the syntax is really neat:

class Man
    constructor: ({@name, @description }) ->

dave = new Man
    name: 'Dave'
    description: 'a dude'
console.log "#{dave.name} is #{dave.description}"

edit: rewritten to use the term 'destructuring parameter lists' instead of 'unknown auto-assigned option things huh?'.
edit 2: clarified the ticket, as I didn't actually understand what I had written myself.

[timoxley]

Is this a silly request?

[michaelficarra]

Not at all. It's certainly consistent. I think it may be a little "too much", but I can't really define that term. At the very least, you've notified us that destructuring parameter lists are undocumented.

[timoxley]

thanks. I guess what I'm trying to say is:
It would be nice to be able to transparently refactor between unnamed and named parameter lists without having to hand-write default parameter handing logic.

Sometimes we end up adding many new parameters to functions, when they should probably be promoted to named parameter lists (ever seen a function that takes 5+ unnamed arguments??). Some people may hold off on making the switch to named parameters if they have to sacrifice the succinctness of being able to supply default params within the function signature.

Though in saying that, it's not going to look so succinct unless the parameter list can be specified over multiple lines, in which we'd have to agree on some new syntax which doesn't look gross, and in that case perhaps handwriting defaults for parameter lists isn't really so bad afterall. :/

[michaelficarra]

unless the parameter list can be specified over multiple lines. :/

which it can be

[timoxley]

whoa, how did I miss that? It can too, just isn't picked up by the textmate syntax highlighter, and is a bit bracey, well… my bad.

[timoxley]

Given that, I'm back on the 'ability to provide defaults would be good' bandwagon.

[michaelficarra]

I almost forgot: the main proposal in this issue is very closely related to #1162 (which expresses my above-referenced complexity concerns pretty well) and #810. I want to make sure we don't forget about documenting destructuring parameters if we decide to close this, so can you open a separate issue for that?

[timoxley]

Separate issue created for undocumented destructuring parameters

I'd agree with the conclusion in other thread, all of the proposed solutions in that other thread are ridiculous and complex, this is coffeescript, not regex/perl.

The idea here is to keep the simple syntax and functionality consistent between named and unnamed params. I'd argue that this proposal in fact reduces complexity; you have a single syntax with the same rules for both approaches to parameters.

Perhaps there are aspects that complicate things I am not aware of though.

[goatslacker]

+1

It's a commonly used pattern and having default values will make it much sweeter than writing your own mixin function.

[gampleman]

So how should that compile? Would it allow nesting? Would it work elsewhere then in function declarations? If not, then what about consistency?

[codelahoma]

Hacky workaround that currently works:

constructor: ({name, description}, description = "not described") ->

[michaelficarra]

@codelahoma: that code is discouraged. See #1002, #1547. Identical parameter names will be a syntax error soon.

[s4y]

+1

[vendethiel]

Please don't bump after a year. I remember this syntax worked great in Coffee 1.3 but got broken/removed in Coffee 1.4