Enable builder inference for optics copy

[serras]

This should help type inference and show nicer in the IDE

[nomisRev]

What does this do on the interface? I thought it was supposed to go on the functions, the documentation didn’t clarify it for me 😅
Since it’s applicable to interface, I’m wondering what it does.

Is it applied to all DSL functions that have this as a lambda receiver?

[serras]

As I understand from https://kotlinlang.org/docs/type-safe-builders.html#scope-control-dslmarker, you put the annotation in the interface which will be in scope in the builder, which in this case is Copy.

[serras]

As I understand the @DslMarker is the thing that marks the member of that interface as "keywords", whereas @BuilderInference changes how type checking works to better suit this kind of pattern.

[nomisRev]

Okay, I asked because I used @DslMarker differently in the Arrow 2.0 branch and it worked for me in IDEA 🤔

[serras]

According to the docs (emphasis mine):

To make the compiler start controlling scopes you only have to annotate the types of all receivers used in the DSL with the same marker annotation. For instance, for HTML Builders you declare an annotation @HTMLTagMarker:

@DslMarker
annotation class HtmlTagMarker

An annotation class is called a DSL marker if it is annotated with the @DslMarker annotation.

[...]

After you've added this annotation, the Kotlin compiler knows which implicit receivers are part of the same DSL and allows to call members of the nearest receivers only.

[nomisRev]

Are both these flags needed?

First one is to allow builder inference inside Arrow, or to be able to expose annotation?
Second one is to allow OptIn without a compiler warning?

I’m always confused about the OptIn, because it works fine without this flag.

[serras]

I am not sure, the docs at https://kotlinlang.org/docs/using-builders-with-builder-inference.html#writing-your-own-builders are by no means clear. But I'll delete the opt-in one.

[nomisRev]

But I'll delete the opt-in one.

I'm not sure if we need it yes, or no 😅 Just wanted to clarify, it can be that we're currently missing it.

[nomisRev]

As you said "are by no means clear" :/ I feel the same for the opt-in one.

[i-walker]

AFAIK this is not needed. Since we have BuilderInference already working with *EffectScope in core and dont have to add it

[serras]

Just pushed a commit removing it

[i-walker]

Thanks @serras 👍🏾