On Fri, Jul 12, 2013 at 11:07 AM, Claus Reinke <claus.reinke at talk21.com>wrote:

> A slightly less ambitious suggestion:
>
>    consider f() as syntax for the implicit arguments array
>    (which, as of ES6, can be considered deprecated), then
>    make the parens in this syntax optional
>

snip


>
> In other words, you could write
>    f 1 // single parameter
>    f(1,2)    // single parameter, implicit arguments pseudo-array


This breaks CallExpression Arguments...

Given:

  function f(a, b) {
    return [a, b];
  }

Currently:

  f(1, 2); // [1, 2]

Whereas...

  // single parameter, implicit arguments pseudo-array:
  f(1, 2);

 |a| would be magically be treated like a ...rest param that wasn't really
an array, but instead a implicit arguments pseudo-array?

  // [[1, 2], undefined]



>    f [1,2]    // single parameter, explicit array
>
snip

>
> For your nested call example, you'd have the choice between
>
>    foo(1, 2, bar("a", "b"))    //uncurried, implicit pseudo-arrays
>    foo[1, 2, bar["a", "b"]]    // uncurried, explicit arrays
>


Optional parens for CallExpression Arguments or MemberExpression
Arguments results in convoluted argument lists. The solutions shown above
using [] also create ambiguity with:

- MemberExpression[ Expression ]
- CallExpression[ Expression ]

Given:

  function foo(value) {
    return value;
  }
  foo.prop = "Some data";

Currently:

  foo("prop"); // "prop"

  foo["prop"]; // "Some data"

Whereas...

  "foo[1, 2, bar["a", "b"]]    // uncurried, explicit arrays"

  foo["prop"] // What does this return?



Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130712/152f8a60/attachment.html>

On Fri, Jul 12, 2013 at 11:07 AM, Claus Reinke <claus.reinke at talk21.com>wrote:

> A slightly less ambitious suggestion:
>
>     consider f() as syntax for the implicit arguments array
>     (which, as of ES6, can be considered deprecated), then
>     make the parens in this syntax optional
>
> (snip)
>
> In other words, you could write
> ```
> f 1 // single parameter
> f(1,2)    // single parameter, implicit arguments pseudo-array
> ```

This breaks CallExpression Arguments...

Given:

```js
function f(a, b) {
  return [a, b];
}
```

Currently:

```js
f(1, 2); // [1, 2]
```

Whereas...

```
// single parameter, implicit arguments pseudo-array:
f(1, 2);
```

`a` would be magically be treated like a ...rest param that wasn't really
an array, but instead a implicit arguments pseudo-array?

```
// [[1, 2], undefined]
```

> ```
> f [1,2]    // single parameter, explicit array
> ```
>
> (snip)
>
> For your nested call example, you'd have the choice between
>
> ```
> foo(1, 2, bar("a", "b"))    //uncurried, implicit pseudo-arrays
> foo[1, 2, bar["a", "b"]]    // uncurried, explicit arrays
> ```


Optional parens for CallExpression Arguments or MemberExpression
Arguments results in convoluted argument lists. The solutions shown above
using [] also create ambiguity with:

- MemberExpression[ Expression ]
- CallExpression[ Expression ]

Given:

```js
function foo(value) {
  return value;
}
foo.prop = "Some data";
```

Currently:

```js
foo("prop"); // "prop"

foo["prop"]; // "Some data"
```

Whereas...

```
foo[1, 2, bar["a", "b"]]    // uncurried, explicit arrays

foo["prop"] // What does this return?
```