String after implicit object

Shouldn't this:

Hm.label(for: 'username', 'Username')

get compiled into:

      Hm.label({
        "for": 'username'
        },
        'Username'
      );

instead of:

      Hm.label({
        "for": 'username',
        'Username': 'Username'
      });

??

[hen-x]

Perhaps it would be a good idea if compact literal expansions (like {a, b, c} → {a:a, b:b, c:c}) only worked inside of explicit braces, and not inside of implicit object literals. Otherwise, there is no way to "break out" of an implicit literal on a single line; individual values in an argument list, like in this example, will just be interpreted as keys.

[TrevorBurnham]

Actually, while this is baffling behavior at first glance, I think it's OK.

Consider that in Ruby, implicit hashes are allowed only for the last argument precisely because humans would have a hard time seeing that y is the third argument in the function call

foo(x, :a => b, :c => d, y)

So, if you use a hash as an earlier argument, you need to use curly braces. It seems wise to me, as a stylistic matter, to use curly braces for a hash that isn't the last argument to a function. Given the stylistic convention, scenarios like the above would be unlikely for two reasons: First, the caller would use curly braces around the hash; and second, the person who wrote the function would have made the hash the second argument rather than the first.

Also consider syntax highlighting. If for: 'username', 'Username' were all in the "hash" color, or if for: and 'Username' were both in the "key" color, a programmer trying to pass 'Username' as an argument would immediately realize their mistake and add curly braces.

So, I don't strenuously object to sethaurus' proposal, but I don't think it's necessary, either.

TrevorBurnham: That makes sense. Thank you.

[jashkenas]

Thanks for reporting this ... it's not too hard of a fix -- just one more check to make, while searching for the end of the implicit object. Here's the patch:

http://github.com/jashkenas/coffee-script/commit/474c372b17cd6ebd5eb6c26ef7f6cb5769c881bf

Closing the ticket.

Cool. Thank you, jashkenas!

[jashkenas]

Sorry, devtime, had to revert this commit for the following reason:

http://github.com/jashkenas/coffee-script/issues/#issue/631

Ok, jashkenas. No biggie. Thanks for letting me know.

[satyr]

To prevent this, how about making object shorthand syntax a little more explicit:
{:a, :b} # {a:a, b:b}
Then we can omit braces in these cases as well:
f :k1, :k2, o # f({k1:k1, k2:k2}, o)
:puts = require 'sys' # {puts:puts} = require('sys')

satyr: I like it!

jashkenas: will you consider reopening this issue? or should we create a new one for satyr's proposal? Thanks.

[michaelficarra]

I like it as well. Nice suggestion.

[danielribeiro]

I like the way it is now. TrevorBurnham's comment on how ruby does it, also applying for pythons **kwargs, is tried and true, and makes perfect sense.

To solve it, you can already be expicit:
Hm.label({for: 'username'}, 'Username')
Compiles to:
Hm.label({
"for": 'username'
}, 'Username');
As expected. You can even leave out the parenthesis:
Hm.label {for: 'username'}, 'Username'

[StanAngeloff]

I like satyr's proposal. How often would you really want to do fn key: value, 'key2' ? What's the point of having a string key with the same string value?

On a side note, why is fn key: value, a + b not valid but fn key: value, (a + b) is compiling. There is too much magic happening around implicit objects.

How often would you really want to do fn key: value, 'key2' ?

StanAngeloff: I agree with you -- it's much more common for me to need a string after a hash than needing a "string key with the same string value".

func(xx: zz, 'yy')

Also, the current behavior is counterintuitive. Most developers who'll come by the sort of code above for the first time will think that the second parameter is a string.

[danielribeiro]

If it can be done, wtihout requring explicit brackets great.