Enhancement: Allow first function parameter to be indented

[m1sta]

Currently this is allowed...

functionName firstParam, secondParam, thirdParam

... and this is allowed ...

functionName firstParam,
    secondParam
    thirdParam

but this is not...

functionName 
   firstParam
   secondParam
   thirdParam

It would be nice if they were all allowed.

[epidemian]

Hmmm. Only considering function application and given your first two examples, yes, i'd expect the third one to work too.

But considering other language constructs, i think this whitespace-overloaded syntax becomes a nightmare of corner cases.

For instance, if...

foo
  bar
  baz

...was interpreted as a function call, how should this be interpreted?:

if foo
  bar
  baz

Well, an if statement, obviously (even though they look pretty similar...). But what about?:

if foo
  bar 
  baz
 qux
 quxx

Or, better yet:

qux if foo
  bar
  baz

(the last is already a valid construct and is pretty tricky IMO)

I personally think an unfortunate misstep of CoffeeScript was to assign too many different meanings to whitespace. It complicates the syntax and its corresponding parser implementation, requiring many disambiguation tricks and generating a plethora of corner-cases. It even makes it difficult for us, programmers, to tell WTF is going on some cases (i consider it a bad smell that i spend too much time trying out code snippets at coffeescript.org to see what they compile too).

Instead of adding yet another use-case for whitespace, i'd rather see a reduction of them.

Sorry for the rant. My intention was to provide some constructive criticism 😅

[davidchambers]

Instead of adding yet another use-case for whitespace, i'd rather see a reduction of them.

I agree. Python gets it right: indentation for blocks, and one can do as one pleases between ( and ).

[m1sta]

@epidemian Good point.

I feel like there is a single solution to both this and #3115 through some kind of language feature which marks that what follows should be considered as a list. I don't know what this looks like yet.

[epidemian]

I know that function-call parens hurt[1], but they seem to get the job done in this case:

foo(
  bar
  baz
  qux
)

[1]: I don't know why they hurt though. I find it quite ironic that i use the opposite convention regarding function-call parens when coding in Ruby than when coding in CoffeeScript (in ruby: obj.method and obj.method(param), and in Coffee: obj.method() and obj.method param 😝).

[vendethiel]

I think @satyr's choice to use do removes a lot of ambiguities (if then BLOCK is also a good construct, since coffee's whitespace-sensitivity is too forgiving)

[m1sta]

Thanks for the discussion all. My core challenge here was readability. Given the alternatives and the challenges of what was proposed I've decided I'll either deal with it or use something like...

apply
  function: sayHello
  firstname: 'John'
  surname: 'Smith'

and the helper function...

apply = (obj) -> 
   fn = obj['function']
   th = obj['this'] or fn
   delete obj['function']
   delete obj['this']
   fn.apply th, (obj[key] for key of obj)

at least for the instances where I can't control the definition of the function I'm calling.

[xixixao]

Thinking (I can't find the original issue):

Consider that

if fn a,
    b
  c

doesn't compile, which I think is good, we can take the same approach:

if fn
  a
# if (fn) {a}

if fn
    a
  b
# SyntaxError: unexpected dedent

So if wouldn't be a problem.

Worse edge case:

a b
  c
# a(b)(c) or a(b(c))

I'd choose the second, but wrong indentation would become a nightmare to debug :/. I really wish CoffeeScript could do this for better DSLs, but it's most likely not feasible.