Stop enforcing parameter name uniqueness

[bcherny]

Currently enforced on this line -

coffeescript/src/nodes.coffee

Line 1431 in 769f02e

node.error "multiple parameters named #{name}" if name in uniqs

This is already enforced by linters (eg. http://eslint.org/docs/rules/no-dupe-args), and is not CoffeeScript's responsibility. Instead, we should have a smarter variable naming scheme that doesn't rely on uniqueness of param names.

A side effect of enforcing this from within CoffeeScript is that pattern matching syntax doesn't work. Eg. I can't do:

foo = (_, _, count) -> count + 1
foo(1,2,3)

But the above does work in JS.

[vendethiel]

Nope, the above isn't allowed in strict mode, and that's why it was disallowed in CoffeeScript.

[vendethiel]

See #1002 and #1547.

[lydell]

You might also be interested in #3972 and the following syntax:

foo = ({}, {}, count) -> count + 1
foo = ([], [], count) -> count + 1

[vendethiel]

(that syntax is also mentioned in #1002)

[bcherny]

thanks for the links, i didn't realize it's not allowed in strict mode!

it would be nice to make an exception for pattern matching style (transpiling _ to non-repeated names), like what this commenter said. this style is idiomatic in many functional languages, and it would be nice to get support for it in cs.

[jashkenas]

The Party Line™ on this is that it's better to name your variables, even if you aren't going to use them. You might want to use them later, and it's better to document what they are, instead of being mystery meat free variables floating around.

[bcherny]

@jashkenas many functional languages (scala, haskell, f#, ...) disagree. param names don't tell you much about what the variable is anyway. you need docs (jsdoc/jsig/flow), type annotations, or to look at context and consumers to get a good idea of what a param is for. the name by itself is not enough to conclude much, unless it's an idiomatic param name (like event, or error).

[vendethiel]

@bcherny just as you said – you don't have those annotations in coffee.

[bcherny]

exactly. i'm arguing that param names are not usually useful otherwise.

# useful:
# (bar: number) => number
fn = (_, bar) ->
  bar + 1

# useful:
# (foo: number, bar: number) => number
fn = (foo, bar) ->
  bar + 1

# less useful:
fn = (foo, bar) ->
  bar + 2

# equally less useful:
fn = (_, bar) ->
  bar + 1

it's annotations that are useful, not param names. not only that but _ actually provides some more information (compared to foo): it indicates that the variable is unused in the function body, so you don't have to read through the body for usage sites.

[michaelficarra]

If you have so many positional parameters that you need to omit their names, it's time to use named parameters (passing an object and using destructuring).