Thinking outloud, exploring ideas that might compete with # or -> as function shorthands. Recreating examples form http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax

ideas.js

( ( <argument-list> ) <expression> | <block> )

var identity = (( x ) {
  x; // with tail calls
});

var f = (( a, b, c ) {
  // a, b, c
});

f( a, b, c );


var obj = {
  f: () {
    // who needs a label?  
  }
};

obj.f();


otherFunction( "arg", ( /.../ ) {
  // used as a callback
});


// The following adapted from `strawman:arrow_function_syntax`

// Primary expression body [...]
let identity = ( (x) { x } ); 
// ...or...?
let identity = ( (x) x ); // bad

// Lower-precedence expression with body. curly braces?
let square = ( (x) { x * x } );
// ...or...?
let square = ( (x) x * x  ); // bad

// In cases where a function expression is expected, outer parens are omitted
setTimeout( () {
  // do stuff
}, 1000 );

// returning, nesting & closures (narcissus parser testing)


(function( global ) {

  global.Module = (() {

    var identity = ((x) { x }), 
        square = ((x) { x * x }), 
        hasFoo = (( obj ) {
          
          var ret = "no foo";
          
          if ( obj.foo ) {
            ret = "has foo"; 
          } 
          
          ret;
          
        });

    return {
      hasFoo: hasFoo,
      identity: identity, 
      square: square
    };
    
  })();
  
})( this );

Are you sure this can be parsed unambiguously?

To be honest, I'm not sure. I'm actually trying to work it into a local branch of Narcissus to see if I can show it in action

let identity = (x) { x };

Doesn't work due to ASI after the parenthesized expression.

let identity = ( (x) x );

Doesn't work due to UnaryExpression, e.g. consider ((x) +x). Parenthesizing won't help here, because that'd turn the expression into a CallExpression, e.g. ((x) (+x)).

( (arglist) { body } )

Should work for FunctionDeclaration/FunctionExpression, but requires a lookahead. That means the parser needs to tokenize the complete input until it reaches the "{" token to decide whether to parse the input as a FunctionDeclaration/FunctionExpression or a PrimaryExpression.

Thanks! That's very helpful, as I'm working on implementing these ideas in Narcissus and this feedback is incredibly useful