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

Check default values are available from within sum derivations #8

Closed
propensive opened this issue Jan 10, 2024 · 3 comments
Closed
Assignees
Labels
bug Describes something not working as intended question Looking for an answer

Comments

@propensive
Copy link
Owner

It seems like a default value can be accessed when deriving a product type, but not if that product type is being derived as part of a sum type.

@propensive propensive self-assigned this Jan 10, 2024
@propensive propensive added bug Describes something not working as intended question Looking for an answer labels Jan 10, 2024
@NPCRUS
Copy link
Contributor

NPCRUS commented May 27, 2024

What I found is following(within Wisteria.default() macro), when trying to run some derivation for sum:

TypeRepr.of[ProductType] == wisteria.DefaultTest.First & wisteria.DefaultTest

it seems like the original DefaultTest.First type is being enchanced somewhere through wisteria derivation process with it's parent DefaultTest
in this case somehow there's no access to usual product methods you would expect, but if you refine it to First by:

val productSymbol = TypeRepr.of[ProductType].classSymbol.get

now all default values are accessible as for case classes

@propensive
Copy link
Owner Author

propensive commented May 27, 2024

If I understand correctly, First is a subtype of DefaultTest, so we should have that First & DefaultTest =:= First by subsumption of types. But if that's not happening automatically, and we end up getting the symbol for DefaultTest rather than First (because of the ordering of the types in the intersection, maybe?) then we would be looking at the parent type's companion object rather than the variant's companion when we look for the default values.

I've joined up some dots in this, but does it sound like I've misunderstood anywhere?

@NPCRUS
Copy link
Contributor

NPCRUS commented May 28, 2024

@propensive You've joined it correctly. I'm not sure how the type subsumption should work exactly, but I think compiler doesn't understand that there's a subsumption because of this (SumDerivationMethods.scala, line 106):

type VariantType = variantType & DerivationType

where you manually intersect the current's variant variantType with DerivationType to make compiler happy on returning. I wasn't able to mitigate this intersection, it seems like we need it, but I adjusted code in macro, so that we can kinda access the class Symbol, which works for both case classes and sum variants:
#16

@propensive propensive assigned NPCRUS and unassigned propensive May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Describes something not working as intended question Looking for an answer
Projects
Archived in project
Development

No branches or pull requests

2 participants