RFC: Explicit type parameter instantiation #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).
There was a problem hiding this comment.
Yeah I'm not sure the right way to say what I want to say--what I want to say is that : is inherently more "interesting" than .
|
|
||
| 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 |
|
Intentionally adding an ambiguous syntax for the sake of potentially adding something that has been denied in the past makes me really uneasy 😕 |
Given the cultural opposition to significant whitespace in our community, I think we have to categorically rule out this possibility, even if it's unlikely to actually affect anyone. I also think the long-standing arguments against bitshift operators are quite strong. We do not have integers, they are not useful without integers, and the identity of the language would have to change pretty dramatically for us to add separate integers, I'd say. |
Kampfkarren
changed the title
|
I talked with @aatxe and @vegorov-rbx about this offline. I'm convinced. Let's go forward with the syntax |
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.