Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for type aliasing #1315

Open
luis-soares-sky opened this issue Oct 1, 2024 · 3 comments
Open

Support for type aliasing #1315

luis-soares-sky opened this issue Oct 1, 2024 · 3 comments
Milestone

Comments

@luis-soares-sky
Copy link
Contributor

luis-soares-sky commented Oct 1, 2024

Similar to what typescript already offers (docs), it would be useful to have a way of naming new types.

Imagine the following use-case:

function sum(a, b)

If we want to give it types but make it generic enough for all value types, a type alias would be great here1:

typealias Number = Integer or LongInteger or Float or Double

function sum(a as Number, b as Number) as Number

Without type aliasing, we'll have to do this, which is somewhat verbose:

function sum(a as Integer or LongInteger or Float or Double, b as Integer or LongInteger or Float or Double) as Integer or LongInteger or Float or Double

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

  1. 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.

@luis-soares-sky luis-soares-sky changed the title Type aliasing Support for type aliasing Oct 1, 2024
@TwitchBronBron TwitchBronBron added this to the v1.1.0 milestone Oct 1, 2024
@TwitchBronBron
Copy link
Member

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.

@TwitchBronBron
Copy link
Member

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.

@luis-soares-sky
Copy link
Contributor Author

luis-soares-sky commented Oct 25, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants