generated from TBD54566975/tbd-project-template
-
Notifications
You must be signed in to change notification settings - Fork 9
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
type can only be part of one type enum, second is silently ignored #1492
Comments
Open
I don't know if this would be possible to support in other languages. Typically each variant is unique to its containing sum type. |
I'll make it an error for now then and we can revisit later if we want. |
matt2e
added a commit
that referenced
this issue
May 16, 2024
#1238 Adds the ability to declare type aliases in modules ``` //ftl:typealias type UserId string ``` There is a lot of overlap between typealiases and enums. They both redefine an existing type as a new type, and therefore need to make sure our schema parsing does not skip this defined type by looking at the underlying type. There were also issues if implicit exports, enum cases (and more?) were encountered in the ast tree before we found the typealias or enum definition. This PR solves that by doing an initial pass just to find all typealias and enum declarations for the module and then doing the normal pass. Previously typealiases were allowed without any declaration but they would just fall back to the underlying type. This PR makes this an error as we do not know if this type should be an enum or a type alias. We may want to discuss this more. fixes #1475 #1476 #1477 #1492 #1449
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps:
Use case:
User
type and aGroup
type, and have them both conform toOwner
andBeneficiary
or something.Current we end up with:
With nothing no errors
The text was updated successfully, but these errors were encountered: