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

Bounds on Types #49

Open
Victorious3 opened this issue Apr 16, 2024 · 0 comments
Open

Bounds on Types #49

Victorious3 opened this issue Apr 16, 2024 · 0 comments
Labels
proposal New feature or request

Comments

@Victorious3
Copy link
Contributor

Victorious3 commented Apr 16, 2024

Currently its only possible to constrain a type using this syntax:

def my_fun(a: type &T, b: type [T])

which works fine if your constraints are as simple as "I take any array" or "I take any reference"
Interfaces can be used directly to create a constraint on a type:

type Interface = interface { def fun }
def my_fun(a: Interface) {
    a.fun()
}

However, this breaks down as soon as you want multiple arguments using the same concrete type.
It is also a bit confusing to not being able to assign two different arguments using Interface because they might be completely different types.

The new syntax for creating bounds would look like this:

def my_fun(a: type T > [T], b: type U > Interface, c: U)

This can completely replace the old "Pattern style" syntax.

Another upside of this is being able to use union types for arguments and have them be compile time:

def my_fun(a: type T > int | double | float)

This would create a polymorphic function that takes either an int, double or float.

You can also combine multiple constraints:

def my_fun(a: type T > Interface & Interface2)

This would mainly be handled by being able to concat interfaces together using &.

@Victorious3 Victorious3 added the proposal New feature or request label Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant