Arbitrary upper bounds for type parameters #1081
Assignees
Labels
Milestone
Comments
lars-reimann
added a commit
that referenced
this issue
Apr 25, 2024
Closes #1081 ### Summary of Changes * Literal types can now be used as upper bounds of type parameters * Don't show an extra error if callable types or union types are used as upper bounds of type parameters. This is already checked elsewhere.
lars-reimann
added a commit
that referenced
this issue
Apr 25, 2024
Related to #1081 ### Summary of Changes Also update the type computer to handle literal types as upper bounds of type parameters.
lars-reimann
pushed a commit
that referenced
this issue
May 2, 2024
## [0.14.0](v0.13.0...v0.14.0) (2024-05-02) ### Features * `this` expression ([#1111](#1111)) ([c7bd0fa](c7bd0fa)), closes [#1107](#1107) [#1110](#1110) * allow literal types as upper bounds of type parameters ([#1102](#1102)) ([c14159b](c14159b)), closes [#1081](#1081) * Check truthiness of value ([#1131](#1131)) ([0b059a1](0b059a1)) * check usages of `@PythonName` and `@PythonCall` on overriding methods ([#1100](#1100)) ([3021166](3021166)) * partial code generation for multiple targets ([#1114](#1114)) ([5461a1b](5461a1b)), closes [#1079](#1079) * Stubs for `safe-ds` version 0.22.1 ([#1130](#1130)) ([6f7100d](6f7100d)) * various methods to work with strings ([#1112](#1112)) ([b6d4f16](b6d4f16)), closes [#1108](#1108) * visibility modifiers for any module member ([#1104](#1104)) ([3d43d38](3d43d38)), closes [#1083](#1083) ### Bug Fixes * also handle literal types when computing upper bound ([#1103](#1103)) ([3f1ab6f](3f1ab6f)), closes [#1081](#1081)
|
🎉 This issue has been resolved in version 0.14.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem?
Currently, upper bounds of type parameters must be named types. Literal types would be useful to track whether a model has been fitted, for example. Generally, our implementation should be able to handle any upper bound, so there's no need for this restriction.
Desired solution
Remove the check.
Possible alternatives (optional)
No response
Screenshots (optional)
No response
Additional Context (optional)
No response
The text was updated successfully, but these errors were encountered: