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

Error when a sumtype has variants with the same names with abstract parameters and concrete parameters at the same time #106

Open
Tortar opened this issue Aug 20, 2024 · 3 comments

Comments

@Tortar
Copy link
Member

Tortar commented Aug 20, 2024

The problematic cases are e.g.:

julia> using DynamicSumTypes

julia> struct B{T}
           x::T
       end

julia> @sumtype A{T}(B{T}, B{Int})
A

julia> @sumtype A2(B{T} where T, B{Int})
A2
@Tortar
Copy link
Member Author

Tortar commented Aug 20, 2024

they are not good because one variant is not reacheable because of the presence of the more general one. Actually this would be fine:

julia> @sumtype A{T}(B{Int}, B{T})

because here B{Int} will be searched first. So, maybe allow something like this and error only in the other case?

@jlapeyre
Copy link

jlapeyre commented Aug 20, 2024

EDIT: Looks like you have added parameters in the meantime. I'll check it out.

This gives me an invalid syntax error.

@sumtype A{T}(B{T}, B{Int})

And it's clear your code does not support parameterized sumtypes. I commented on the discourse post about this. Do you have another branch that supports this? If not, it shouldn't be hard to add it.

It would be good to detect the possible collision when T == Int and insert a check in the constructor.

Unfortunatley, all of this starts to add lines to your slim 150 line code.

@Tortar
Copy link
Member Author

Tortar commented Aug 20, 2024

yes, I added the support for parametrized types. Actually I think that

@sumtype` A{T}(B{T}, B{Int})

could be supported but we need to reorder internally the types so that concrete version precedes the abstract one. But actually there are other cases that I think we should anyway handle by throwing some errors

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

2 participants