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

Implement default type parameters #10483

Closed
Simn opened this issue Nov 15, 2021 · 6 comments
Closed

Implement default type parameters #10483

Simn opened this issue Nov 15, 2021 · 6 comments

Comments

@Simn
Copy link
Member

Simn commented Nov 15, 2021

See HaxeFoundation/haxe-evolution#50

@Simn
Copy link
Member Author

Simn commented Nov 24, 2021

The proposal says that this shouldn't work:

This shouldn't: class A<B = C, C>

Unfortunately, the only reason given is this TypeScript discussion: microsoft/TypeScript#2175

We'll have to figure out if this is actually a special case because we don't have any ordering constraints on, well, constraints, and I'm not sure why defaults would be different.

@RealyUniqueName
Copy link
Member

I don't see why that should not be allowed in Haxe.
OTOH anything optional usually goes to the end of the list. Otherwise one would have to type in some placeholder for skipped params and that reduces the benefit of the feature.

@kLabz
Copy link
Contributor

kLabz commented Nov 24, 2021

That reminds me about the class ReactComponent<TProps = {}, TState = {}> {} case with ReactComponent<_, MyState> syntax to use default type parameter for first while defining second. Would that one be acceptable? (it's already how we skip arguments when binding a function for example).

@Simn
Copy link
Member Author

Simn commented Nov 24, 2021

Good question... seems like that would make sense and be consistent, so we probably won't do it.

@benmerckx
Copy link
Contributor

Unfortunately, the only reason given is this TypeScript discussion: microsoft/TypeScript#2175

I have no clue what I was thinking linking there, sorry.

Reading this back some years later I think the reasoning for disallowing here was to avoid circular references.

@RealyUniqueName RealyUniqueName added this to the Backlog milestone Nov 29, 2021
@Simn
Copy link
Member Author

Simn commented Jan 4, 2022

This has been implemented in #10518. We can track further issues separately.

@Simn Simn closed this as completed Jan 4, 2022
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

4 participants