Hi, thanks for the response!
I would like just to simplify defining functions anywhere in app e.g. in global scope without annoying function keyword and that's it. Arrow functions are not an option since it has awkward defintion = () =>
instead of just simple function name, also they have limitations you already mentioned. Even C# has better function defintion e.g. void myFunctionName() { ... }
but javascript can go futher and make it more concise myFunctionName() { ... }.
Some people like to have scope brackets on a separate line
function sayHello()
{
let text = 'hello';
console.log(text);
}
If the function keyword is removed this style wouldn't work, because it is already valid syntax:
getData()
{
let text = 'hello';
console.log(text);
}
is the same as:
/* function call: */
getData();
/* code block: */
{
let text = 'hello';
console.log(text);
}
It would work if it had syntax similar to Rust:
fn getData()
{
...
}
That all said, adding a new way of writing functions that has the same behaviour but is shorter could serve only to split the JS community stylistically. Some teams would want to keep the 'traditional style' of writing function other teams would go for the new fn style and others may always use =>, or a codebase could have a mix of all three adding cognitive load when reading.
@aclaymore, Thanks for insight! Yeah I agree with the issue of { being placed on separate line denoting code block. Looks like there nothing can be done unfortunately. fn is looking almost the same as function, so I don't see the huge reason to ditch function in favor of fn, both versions are ugly :).
I like the idea. We already have something pretty similar. See the es6features GitHub repository. However, it is only for object and class initializers.
The above works out great because we are already inside a specialized expression when we are in an initializer list, so there is no ambiguity about whether method() calls a function or begins the declaration of one. At this point in the expression, there is no way to call a function without a key: value pair, so it must be the beginning of a declaration.
With your proposed idea, the only way to avoid ambiguity would be to assign a meaning to the presently errorful behavior of putting brackets after parentheses on the same line. A syntax error is currently being thrown in this case because expressions need to be deliminated either by line-breaks or by semicolons, so the brackets after the parentheses are considered part of the expression. Thus, the brackets can only be interpreted as an object initializer, which yields a syntax error due to the parentheses. Another flaw is that statements in JavaScript are generally line-ending-agnostic such that break-points in the statement can contain line-endings without affecting the functionality of the statement. Your proposed idea would only work when the whole thing is on a single line, as putting a new-line between the parentheses and the bracket would conflict with pre-established JavaScript syntax. Therefore, your proposed syntax would conflict with the present harmony of JavaScript syntax and require a redesign/overhaul of some JavaScript parsers. Again, I like your idea. However, in its present state, it does not seem very reasonable/rational.