Proposed Changes and Restrictions For Implicit Conversions

As others stated above, implicit conversions have good use cases that are not reproducible in such a concise manner. What about refined types ?

In both Iron and Refined, implicit conversions are importants for automatic refinement.

Refined:

// This refines Int with the Positive predicate and checks via an
// implicit macro that the assigned value satisfies it:
 val i1: Int Refined Positive = 5

Iron 2:

//An inline implicit conversion requiring a given instance of `Constraint[Int, Positive]` is called.
val x: Int :| Positive = 5

They both you implicit conversion for a compile-time verification (using whether macro or inline).

These conversions are totally suited for this use case IMHO.

Also note that these libs do not make implicit conversions uncontrollables since they do compile-time verification and have a way to convert the refined type back to its unrefined type (Iron uses opaque type subtyping, and AFAIK Refined uses another implicit conversion).

From what I understand, the real problem with implicit conversions is that they get abused. I understand the concern of restricting this feature to discourage bad usage but given imports look enough to me.

4 Likes