You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Without type aliasing, we'll have to do this, which is somewhat verbose:
function sum(aasIntegerorLongIntegerorFloatorDouble, basIntegerorLongIntegerorFloatorDouble) asIntegerorLongIntegerorFloatorDouble
A question also remains: should the definition be restricted in scope to the file/namespace like typecast and alias, or should it be project-wide like const and interface? The latter makes more sense to me.
Footnotes
typealias is probably not a great name... I'd name it type but then it'll clash with the built-in type() function. And alias is already taken. Suggestions welcome. ↩
The text was updated successfully, but these errors were encountered:
should it be project-wide like const and interface? The latter makes more sense to me.
Actually, consts and interfaces are scoped the same way as namespaces, functions, classes, etc. So I would think these types should follow the same scoping rules as everything else.
I think the type keyword will work just fine. This keyword will only ever appear to the left of an identifier. So type number = Integer or Float wouldn't have any problems from a parsing perspective because it's a brand new syntax.
One thing left to resolve is the transpile result of the alias, specifically for type unions:
type Number = Integer or LongInteger or Float or Double
The compiler doesn't know how to output this. It could output dynamic, but all of the types above have implications on the actual numeric values at runtime...
So for this to be implemented, we'd need to figure out how to specify what the transpiled types should be. Or we could just let others know that this will always produce dynamic. What do you think?
Similar to what typescript already offers (docs), it would be useful to have a way of naming new types.
Imagine the following use-case:
If we want to give it types but make it generic enough for all value types, a type alias would be great here1:
Without type aliasing, we'll have to do this, which is somewhat verbose:
A question also remains: should the definition be restricted in scope to the file/namespace like
typecast
andalias
, or should it be project-wide likeconst
andinterface
? The latter makes more sense to me.Footnotes
typealias
is probably not a great name... I'd name ittype
but then it'll clash with the built-in type() function. Andalias
is already taken. Suggestions welcome. ↩The text was updated successfully, but these errors were encountered: