Pre-SIP: Allow fully implicit conversions in Scala 3 with `into`

Scala Improvement Process
41

Why can not we use soft modifier convertable which will be able to allow convertion in both directions?
It would allow to implement “boxing” and “unboxing” with standart libraries and operators for dsl types.

42

Thanks for the detailed report. Would the second alternative, i.e. into as a modifier on the boxing wrapper class, work better than into constructors in your case?

I believe not. As mentioned, < is an opaque type and the modifier proposal is limited to class types. Is there a rationale for the limitation? Here’s how it looks like today:

opaque type <[+A, -S] = A | Kyo[A, S]

object `<`:
    implicit def lift[A: WeakFlat, S](v: A): A < S =
        v match
            case kyo: Kyo[?, ?] => Nested(kyo)
            case _              => v.asInstanceOf[A < S]

// internal to the kernel
sealed abstract class Kyo[+A, -S]
case class Nested[+A](v: A) extends Kyo[A, Any]
// other subclasses

As it is now, it seems the SIP would essentially break one of Kyo’s main optimizations: unboxed monadic execution. It’s alarming since it could inviabilize the project. The alternative of adding into to all parameters of type < would be quite problematic as well given that it’d pollute the entire codebase. Users would need to do the same in their code to be able to use Kyo as it’s designed to be used.

Would exposing a type bound with into be a viable workaround? It wouldn’t be ideal to expose a type that is meant to be internal but could the compiler locate the conversion whenever an A needs to be used in a context where a < is required?

opaque type <[+A, -S] >: into[Nested[A]] = A | Kyo[A, S]
1 Like
43

I think a modifier on an opaque type would also work. I see no good reason to exclude it. Unless someone argues against, I will extend the proposal.

8 Likes
44

Thank you for considering Kyo’s usage. Supporting opaque types with the into modifier should be enough for the project’s needs.

3 Likes
45

Would it be possible to infer the into modifier on a type whose companion object contains a conversion? Designers of the target type have already made an explicit choice to support conversions so having to add the into modifier seems redundant. In a lot of cases, library authors wouldn’t need to do anything.

Are there even valid use cases of the into modifier where the companion object does not contain the conversion? In those cases the author of the target type isn’t providing the conversion and so that seems bad for the same reason that adding it to IterableOnce would be bad.

46

all of the java standard library types that integrate with collections library

1 Like
47

I could see this also being the case when writing shims or integration libraries like the various *-scalatest or *-munit libraries.

48

AsScala could have a companion object that extends DecorateAsScala which would then make it eligible.

49

How so? If you control the target type you have just as much control over adding the into modifier as adding a companion object with a conversion. If you aren’t defining the conversions in the same library as the target type then you aren’t following the warnings and probably shouldn’t be adding the into modifier anyway.

50

In those libraries, it’s usually a third party providing the glue code that allows quality of life benefits like being able to write async tests using IO instead of Future.

This removes the maintenance burden of integrating with other libraries from the authors of frameworks like Scalatest and MUnit, and requiring the library that controls the types to add these conversionn means we likely won’t have these additional integrations at all.

Categorically dismissing these glue libraries as something that probably shouldn’t exist is, at least in my opinion, extremely short-sighted.

3 Likes
51

SIP 71 has been accepted for implementation at the SIP meeting of May 23rd. A draft implementation is in the Scala 3 PR 23014.

5 Likes
52

If into will be a keyword as a modifier for classes, why not let it be a modifier keyword for types as well? In what sense is into[T] actually a type in a way that’s useful?

One thing that was mentioned was being able to alias it: type A = into[B]. But if it can be a modifier on a class wouldn’t into type A = B make more sense?

1 Like
53

Like, would type A = Either[B, into[C]] make any sense?

What should “into-ness” really be a property of?

1 Like