RFC: Parameterized function expressions #90
Conversation
|
|
||
| This is either a parameterized function call of `f(c)` with `a` and `b` as types, or a return of two values--`f << a`, and `b >> (c)`. | ||
|
|
||
| Because there would be no ability to add bitwise shifts to the language, it is unlikely that any bitwise operators would be added, as it would be a stark omission. |
There was a problem hiding this comment.
Should we see a RFC that basically puts the final nail in the coffin for bitwise ops? Time and time again, people want to see it, but bit32 is better because it guarantees better performance characteristics anyway.
|
High-level nitpick but can we call this |
| -- Saving `f<<T>>` as a variable to called later | ||
| local e = f<<T>> | ||
| ``` |
There was a problem hiding this comment.
Might want to lead with this, or something else similar to be clear that the proposal is allowing the expression prefixexp '<<' TypeList '>>' as its own expression, and not just function calls having an optional new piece of syntax.
| local moneyBinding = React.createBinding:<number>() | ||
| ``` | ||
|
|
||
| The downside of these is that they blur the lines between runtime and static, in the sense that `React.createBinding.` starts out as a runtime concept, followed by the purely static `<number>`. As for `:`, it carries the baggage of `x:y()` which will perform a runtime mutation of the function call in the form of adding on `self`. |
There was a problem hiding this comment.
I would not describe this as a runtime mutation. It's very confusing. There's no mutation happening, x:y() is just syntactic sugar for x.y(x).
|
|
||
| The downside of these is that they blur the lines between runtime and static, in the sense that `React.createBinding.` starts out as a runtime concept, followed by the purely static `<number>`. As for `:`, it carries the baggage of `x:y()` which will perform a runtime mutation of the function call in the form of adding on `self`. | ||
|
|
||
| There is also not necessarily a reason that we have to provide symmetrical operators, so something like `f!T, U()` is reasonably parseable, but is not obviously better. |
There was a problem hiding this comment.
Also asymmetrical operators have the drawback of being even more Different:tm: from other instances of type application syntax in languages. This is something where you're providing a collection of arguments, and culturally, folks have decided that collections are grouped with symmetric brackets of some sort.
|
I'm honestly inclined to go for The ambiguity issue is real, but I think this is obscure enough that we can ask people to use whitespace to differentiate between |
Rendered
TL;DR -- Adds support for calling
f<<T>>()wherefis a function that takes a type parameterT, similar to Rust's turbofish (f::<T>()) or C++'sf<T>(). This is done at the expression level, sof<<T>>is valid as a value.