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

type can only be part of one type enum, second is silently ignored #1492

Closed
matt2e opened this issue May 15, 2024 · 2 comments · Fixed by #1493
Closed

type can only be part of one type enum, second is silently ignored #1492

matt2e opened this issue May 15, 2024 · 2 comments · Fixed by #1493
Assignees

Comments

@matt2e
Copy link
Contributor

matt2e commented May 15, 2024

Steps:

  • define a type enum
  • define a second type enum
  • define a type that conforms to both
  • Expected, it is a case in both.

Use case:

  • I can imagine wanting to define a User type and a Group type, and have them both conform to Owner and Beneficiary or something.
//ftl:enum
type EnumType interface{ enumType() }

//ftl:enum
type EnumType2 interface{ enumType2() }

type Example string

func (Example) enumType()  {}
func (Example) enumType2() {}

Current we end up with:

enum EnumType {
    Example String
}

enum EnumType2 {
}

With nothing no errors

@matt2e matt2e self-assigned this May 15, 2024
@alecthomas
Copy link
Collaborator

I don't know if this would be possible to support in other languages. Typically each variant is unique to its containing sum type.

@matt2e
Copy link
Contributor Author

matt2e commented May 16, 2024

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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants