Implicit Conversions
Unfortunately they don’t have parity with existing implicit defs yet. There are at least three differences:
- Conversions do not support path-dependency currently - [1]
- Combining them with macros aka inlines is very odd now because they’re “values”. They can be upcast and they can lose their “inline” status through upcasting. Because of that the compiler will emit an error on straightforward definition of a macro
Conversion, you’ll have to define two traits and override a runtime method with an inline method. example: [2] - Given and conversion names cannot be overloaded, because they are not methods – even when they take parameters [3]. This gets in the way of
implicit punningtechnique – replacing a typeclass’s companion with a slew ofimplicit defs to ensure that whenever a typeclass is imported, its syntax is ALWAYS available with it. examples: [usage] [implementation with overloading]. Dotty’s extension methods and the fact that they’re available whenever an implicit is in lexical scope, which happens in strictly more cases than when a type name is imported make this trick unnecessary in most cases, except when extension methods are insufficient like in @morgen-peschke’s example.