Autofold

[nomisRev]

Code generation that implements extension fold functions for sealed classes. Given following snippet.

@autofold sealed class Maybe<A> {
    data class Just<A>(val value: A): Maybe<A>()
    object Empty: Maybe<kotlin.Nothing>()
}

It will generate following code

inline fun <A, B> Maybe<A>.fold(
        crossinline just: (Maybe.Just<A>) -> B,
        crossinline empty: (Maybe.Empty) -> B
): B = when (this) {
    is Maybe.Just -> `just`(this)
    is Maybe.Empty -> `empty`(this)
}

It does not unwrap Just to (A) -> B because if there would be another subtype data class Another<A>(val value: A): Maybe<A>() you would lose type safety over function parameters but on the other hand I might make the code gen smart enough to check that... Thoughts?

[pakoito]

I'd change the name to @fold, as we don't have names like @autoderive. The name of the functions could use a prefix like ifLeft & ifRight.

As for the implementation, what happens when a child class has more generic parameters than the parent class? i.e. sealed class Wrap<A>; data class W1<A, B>(val b: B): Wrap<A>?

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@185cf36). Click here to learn what that means.
The diff coverage is 0%.

@@            Coverage Diff            @@
##             master     #448   +/-   ##
=========================================
  Coverage          ?   35.62%           
  Complexity        ?      327           
=========================================
  Files             ?      182           
  Lines             ?     4968           
  Branches          ?      532           
=========================================
  Hits              ?     1770           
  Misses            ?     3049           
  Partials          ?      149

Impacted Files	Coverage Δ	Complexity Δ
...ssor/src/main/java/kategory/fold/AnnotationInfo.kt	0% <0%> (ø)	0 <0> (?)
...c/main/java/kategory/fold/AutoFoldFileGenerator.kt	0% <0%> (ø)	0 <0> (?)
...r/src/main/java/kategory/fold/AutoFoldProcessor.kt	0% <0%> (ø)	0 <0> (?)
...r/src/main/java/kategory/fold/AnnotatedAutoFold.kt	0% <0%> (ø)	0 <0> (?)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 185cf36...345b7a4. Read the comment docs.

[nomisRev]

@pakoito @fold is conflicts with kategory.optics.Fold if you have both optics and core imported.

[nomisRev]

@pakoito well damn :D 2 type arguments expected. Use 'W1<*, *>' if you don't want to pass type arguments

inline fun <A, B> `kategory`.`optics`.`Wrap`<A>.fold(
        crossinline w1: (`kategory`.`optics`.`W1`<A, B>) -> B
): B = when (this) {
    is `kategory`.`optics`.`W1` -> `w1`(this)
}

[nomisRev]

@pakoito what would you suggest here? Currently code gen bails with following message, since it impossible to write a fold method in this situation.

autofold.wrap.kt: (6, 8): 2 type arguments expected. Use 'W1<*, *>' if you don't want to pass type arguments
autofold.wrap.kt: (6, 41): Type mismatch: inferred type is Wrap<A> but W1<A, B> was expected

[pakoito]

@nomisRev Add <*, *> to the when clause, but IIRC that means that the caller can assume the type of B and get a runtime error.

[raulraja]

We don't support derivation at the moment anywhere else for kinds of arity higher than 1 so I think this is good as is until we want to support those across the board which we can tackle at once.

[nomisRev]

@pakoito I wouldn't add something that will lead to unsafe code.

[pakoito]

@raulraja Doesn't this cause the same kind of conflict PartialFunction had? That's what I mean with unsafe.

[pakoito]

@nomisRev @raulraja My suggestion going forward: fail the processor for those cases where child classes have more generic parameters than the sealed class.

[nomisRev]

@pakoito it currently fails for all cases where generics cannot be figured out and not just

where child classes have more generic parameters than the sealed class.

So no runtime errors can occur from using the generated fold methods. Currently it fails with the message of the invalid code but I will update it proper compile time error message before we merge.

[raulraja]

@pakoito I think #448 (comment) addressed your concern. Can we merge this?

[pakoito]

Green with NIT: improve the error message.