Unexpected compile for paren-free method chaining

[ryanflorence]

request
  foo: 'bar'
.then doStuff

request foo: 'bar'
.then doStuff

request 'foo'
.then doStuff

compiles to

request({
  foo: 'bar'
}).then(doStuff);

request({
  foo: 'bar'.then(doStuff)
});

request('foo'.then(doStuff));

But I'd expect example 2 to compile to the same thing as example 1, and example 3 to be

request('foo').then(doStuff));

Is my assumption wrong?

[michaelficarra]

See #1407, #1495

[ryanflorence]

This ticket is slightly different in that it shows the behavior is inconsistent when different arguments are passed to the first function, rather than proposing some chaining syntax. Whatever coffeescript does with chaining, it should act the same regardless of the type of arguments used.

[TrevorBurnham]

You're right that this is odd, but there is an explanation: The syntax

func
  key1: val1
  key2: val2

is special-cased to be an acceptable way of passing a hash to func. By contrast,

func
  arg

is unacceptable. This necessarily leads to some quirks... I certainly agree that the inconsistency between your first two examples should be rectified, preferably by making the second one equivalent to the first. The excellent proposal at #1407 would accomplish that feat by making the . on line 2 close the implicit parens on line 1.

[satyr]

func
  key1: val1
  key2: val2

is special-cased to be an acceptable way of passing a hash to func.

Related, but not an actual cause.

OP's first case works because dots right after OUTDENT is special-cased to close implicit calls. Observe:

$ coffee -bcs
  f ->
    x
  .y

  f -> x
  .y

// Generated by CoffeeScript 1.2.1-pre

f(function() {
  return x;
}).y;

f(function() {
  return x.y;
});

[TrevorBurnham]

Ah, good explanation, satyr.

[vendethiel]

closing in favor of #1495