What did you think about an implicitConversionOp ?

[sighoya]

On Sunday, 27 December 2020 at 14:39:52 UTC, Mike wrote:
> There have been a number of proposals that have attempted to 
> address the niche that implicit conversion operators fill, 
> including...
>
> 1.  Implicit conversion operators

It seems that DIP52(https://wiki.dlang.org/DIP52) wants to enable 
the complement behavior through `alias from` in addition to 
`alias to` which does reflect the `alias this` of today.
`alias from` is akin to `alias this` coupled to its type.
As I said, I don't appreciate this that much. Decoupling both 
source and target type from the implicit operator adds much more 
power and would subsume alias this.
The point of decoupling is this: you can extend implicit 
conversions by importing  `implicitConversionOps` from other 
modules s.t. method overloading of `implicitConversionOp` 
naturally extend the power of implicit conversions without to 
change the type signature of target or source type which is sadly 
the case with `alias this`.

In the thread you linked here 
(https://forum.dlang.org/post/vggskphkqxtriqnavmnf@forum.dlang.org), you even recommend deprecating alias this in favor of implicit operators. I like the idea, but deprecation isn't really that required, I think.

> 2.  Implicit constructors

Was this DIP1004 
(https://github.com/dlang/DIPs/blob/48f1e88f9740ec30558eff2fc7a18735ceb64352/DIPs/other/DIP1004.md)?

It is interesting but doesn't directly relate to general implicit 
conversion as it is more focused on class constructors.

> 3.  Multiple alias this

I don't appreciate it that much, because it isn't that 
extendable, i.e. enumerating all possible target types is 
impossible and adding them later might break your semver.

> As I recall, the only one that has not been outright rejected 
> is multiple alias this (https://wiki.dlang.org/DIP66).  In 
> fact, it has been officially approved!

Interesting, I wasn't aware of this.


> Walter's primary objection, as I understood it, was the 
> complexity it introduced for classes and its interplay with the 
> inheritance hierarchy.

Okay, true I must admit the overlap of structuralism with 
nominalism isn't easy, it isn't impossible to resolve the 
problem, it just needs to find a good convention, but it may end 
to more confusion than necessary.

I can live with the restriction that classes are out of scope. 
Instead we could emphasize just to use `classObject.to` for 
explicit conversion.

>  Structs don't have an inheritance hierarchy, so I proposed a 
> very simple solution:  Multiple alias this for structs only.

It kinda a solution, but what about interfaces. Nominal 
interface-relationships are too restrictive for me. Is it the 
same fuzz with interfaces as with classes? Or maybe we just 
should allow implicit conversion of classes and interfaces only 
if they don't inherit from any other class or interface excluding 
Object here.
Also, I want pointers of structs to be implicit convertible to 
interfaces as otherwise we have a disparity between the concrete 
case where struct is passed by reference and wrapped into an 
interface and the generic case where struct does conform to one 
or more interfaces but are copied by value.

>
> Multiple alias this is already an approved DIP, so perhaps by 
> reducing its scope to just structs, it may just need a champion 
> willing to see an implementation through to completion.
>
> With multiple alias this for structs, implicit conversion may 
> not be needed.
It is implicit conversion, but a more restricted one leading to 
the creation of more types than necessary.