One point against `implicitConversionOp` is to which degree we work on copies after conversion.

What means actually conversion?
Did we create a whole new value not sharing any parts to its original value or is it more a mix of creation and sharing?
Example: create a new List and deep copy the elements out of the original list vs copy only the pointer of the elements out of the original list.

Because of this reason, I would favor for `implicitCoercionOp` and making `implicitConversionOp` explicit over `to!T` à la `into` in Rust.

On Sunday, 27 December 2020 at 09:27:05 UTC, Walter Bright wrote:
> I'm speaking here from C++'s experience.
> [..]
> 3. operator overloading for non-arithmetic purposes

I'd say, <, > and == aren't arithmetic operators, &, ^, and |, too, but one could disagree. Same for array dereferencing, indexing or getting an address. However, array concatenation with ~ for sure isn't arithmetic.

On Sunday, 27 December 2020 at 09:27:05 UTC, Walter Bright wrote:

> 3. operator overloading for non-arithmetic purposes

I guess you intended to say it was a bad idea to redefine the well-established meaning of some operators defined by mathematics or the language itself (like '+' for concatenation or '<<' for IO)?

Otherwise, operators are just functions with infix syntax and non-alpha-numeric names. I haven't heard any (reasonable) complaints about ">>=" or "<*>" in Haskell, for example.

On Saturday, 26 December 2020 at 15:48:49 UTC, sighoya wrote:

> What is your opinion regarding this?

There have been a number of proposals that have attempted to address the niche that implicit conversion operators fill, including...

1.  Implicit conversion operators
2.  Implicit constructors
3.  Multiple alias this

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! But, the implementation (https://github.com/dlang/dmd/pull/8378) was never thoroughly reviewed let alone accepted, so it's unclear where things stand.

Walter's primary objection, as I understood it, was the complexity it introduced for classes and its interplay with the inheritance hierarchy.  Structs don't have an inheritance hierarchy, so I proposed a very simple solution:  Multiple alias this for structs only.  Classes already have what they need with D's kick-ass meta programming and multiple interface inheritance.  It's only structs that really need such a feature.  I wrote a slightly more detailed brain dump at https://forum.dlang.org/post/vggskphkqxtriqnavmnf@forum.dlang.org, so I refer the reader there.

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.

On Sunday, 27 December 2020 at 09:27:05 UTC, Walter Bright wrote:
> I'm speaking here from C++'s experience.

That's the thing isn't it? We don't have to do it the c++ way! Other languages done implicit conversions differently than c++, which requires further examination.

> Implicit conversion operator overloading is in the category of ideas whose evil nature only becomes apparent after several years:
>
> 1. implicit declaration of variables

That's not a bug, but a good feature. Just have a "one and only one implicit conversion" for variables, then problem solved.
>
> 2. macros

I think we agree that c macros is a bad idea. Templates on the other hand just needed type restrictions, to prevent nonsense if desired. Type functions are very promising on this.


> 3. operator overloading for non-arithmetic purposes

Can this be said regarding arithmetic operator overloading in general?

> 4. implicit conversion operator overloads

Which should have been opt-in not opt-out. The overload handing should be left up to the programmer not to the compiler.

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.

On Sunday, 27 December 2020 at 16:50:06 UTC, sighoya wrote:

> 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.

I did not recommend it; I only mentioned it as an alternative. Indeed, deprecating `alias this` is not required; it was mentioned to emphasize that with the addition of the feature, the benefit `alias this` provides could be achieved in other ways.

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

No, I meant this C++ feature: https://en.cppreference.com/w/cpp/language/converting_constructor
I suppose I may have used the wrong term.

> It is implicit conversion, but a more restricted one leading to the creation of more types than necessary.

Only the types being converted from and converted to should be necessary.

On 12/27/2020 5:09 AM, IGotD- wrote:
> On Sunday, 27 December 2020 at 09:27:05 UTC, Walter Bright wrote:
>>
>> 1. implicit declaration of variables
>>
> 
> Can you give an example of an implicit declaration of a variable.
> 

int x1 = 0;
xl = 3;  // Oops!

> Does C++ support this implicit declaration?

No.