Tbh, I wonder why modern languages still have a function keyword at all, e.g.:
const add = (a: i32, b: i32): i32 => a + b;
Tbh, I wonder why modern languages still have a function keyword at all, e.g.:
const add = (a: i32, b: i32): i32 => a + b;
It's the other way around. Modern languages and grammars use explicit leading keywords to clearly indicate what sort of context they're about to parse, rather than blindly forging ahead in a superposition while waiting for some future sequence of tokens to clarify what the context is.
It's hard for a naive parser (one-token lookahead, for example), to tell after parsing `const add = (` if this defines a function or a variable.
A "function" keyword often exists just to help the parser. C3, for example, to simply the parser of its language that's a superset of C, adds a "fn" keyword for this very purpose of disambiguation.
That looks like a variable that points to an anonymous function. For simple small functions here and there it may not matter, but if the entire call stack in a debugger is full of anonymous functions then it could be a problem.
IMO it is far easier to read this:
Than the example you provided and it is approximately the same length. I used to arrow functions everywhere in TS/JS and it made it difficult to read IME, and there was zero benefit. They are find for things like event handlers, promises chains etc. But I'd rather just use function when I don't have to worry about the value of this.You're assuming that named lambda is the same thing as a function, which often isn't true. Unless you mean that `=>` should be ambiguous depending on scope (lambda inside a function, a function in global scope)? That would also be a bit problematic, wouldn't it?