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

Do we really need ==:==? #934

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

DmytroMitin
Copy link

@DmytroMitin DmytroMitin commented Apr 5, 2023

==:== seems not to be needed.

SingleGeneric seems not to need Repr and Aux. Repr is always Store.

It's important to define instances of macro-based type classes like

// whitebox
def materialize[In, Out]: TC.Aux[In, Out] = macro materializeImpl[In]

rather than

// whitebox
def materialize[In]: TC[In] = macro materializeImpl[In]

Otherwise val tc = the[TC[A]]; implicitly[tc.Out =:= B] compiles but implicitly[TC.Aux[A, B]] doesn't. Similarly, otherwise db.users.store(user) compiles https://scastie.scala-lang.org/DmytroMitin/wEXiRryiSMaC1AiTYZVYZQ but db.users.store[User, User :: HNil, UUID :: String :: String :: HNil, User :: HNil](user) doesn't https://scastie.scala-lang.org/DmytroMitin/wEXiRryiSMaC1AiTYZVYZQ/5 . Ability to specify type parameters can be useful for example for debugging implicits.

It's a little weird that constraint implicit gen: Generic[T] is put for the type class SingleGeneric on method level rather than type-class instance level.

Maybe SingleGeneric can be ordinary type class (not macro-based)?

@DmytroMitin DmytroMitin changed the title [WIP] Do we really need ==:==? Do we really need ==:==? Apr 5, 2023
@DmytroMitin DmytroMitin marked this pull request as ready for review April 5, 2023 09:16
@alexflav23
Copy link
Member

@DmytroMitin Long follow up, I am no longer actively managing the project and haven't been for quite a while. This makes a lot of sense, and it looks like it's working.

I am not even remembering the context, I recall there was some kind of special equality necessary to compare HLists, but not the specifics. Entirely possible I got something wrong.

Any way I can help integrate and publish these changes?

@DmytroMitin
Copy link
Author

@alexflav23 Feel free to publish any changes you consider relevant. Although I'm not sure whether those changes are binary compatible (MiMa). CI seems to be broken.

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 this pull request may close these issues.

None yet

2 participants