I like the idea of an `implicitConversionOp` or `implicitCoercionOp` more than multiple alias this since the operator is separated from the source type.

It was already proposed here: https://forum.dlang.org/post/qdwiajtugvqpdlyvbvda@forum.dlang.org

But I think to mitigate Walther's main concerns about multiple inheritance, we need to adapt D's overload resolution to support specialization on concrete types:

1.) Best match
2.) Inferring an order of methods regarding implicit conversions if possible

What is your opinion regarding this?

On Saturday, 26 December 2020 at 15:48:49 UTC, sighoya wrote:
> I like the idea of an `implicitConversionOp` or `implicitCoercionOp` more than multiple alias this since the operator is separated from the source type.

User-defined implicit conversions have been proposed many, many times, and Walter has always rejected them. For example, here's a reply of his to a post from 2004:

> Implicit casting is a great idea. It's problems don't become apparent for years, when battle-weary programmers eventually conclude that it just causes more problems than it is worth. I know that it is difficult to be convincing in a few lines about this, but when the complexity of the classes goes beyond the trivial, the interactions between them and other classes with implicit casting becomes remarkably impenetrable.

https://forum.dlang.org/post/cqoj59$sle$1@digitaldaemon.com

On Sat, Dec 26, 2020 at 04:26:14PM +0000, Paul Backus via Digitalmars-d wrote:
> On Saturday, 26 December 2020 at 15:48:49 UTC, sighoya wrote:
> > I like the idea of an `implicitConversionOp` or `implicitCoercionOp` more than multiple alias this since the operator is separated from the source type.
> 
> User-defined implicit conversions have been proposed many, many times, and Walter has always rejected them. For example, here's a reply of his to a post from 2004:
> 
> > Implicit casting is a great idea. It's problems don't become apparent for years, when battle-weary programmers eventually conclude that it just causes more problems than it is worth. I know that it is difficult to be convincing in a few lines about this, but when the complexity of the classes goes beyond the trivial, the interactions between them and other classes with implicit casting becomes remarkably impenetrable.
> 
> https://forum.dlang.org/post/cqoj59$sle$1@digitaldaemon.com

I also used to be a fan of implicit conversions.  Over time, though, I've come to agree with Walter.  Implicit conversions are admittedly very convenient in the short term, but in the long term they tend to make code obtuse and hard to maintain.  Over time I've come to regret deeply-ingrained implicit conversions I've done in my code with alias this.


T

-- 
People tell me I'm stubborn, but I refuse to accept it!

On Saturday, 26 December 2020 at 16:26:14 UTC, Paul Backus wrote:
>User-defined implicit conversions have been proposed many, many times, and Walter has always rejected them.

But have they ever considered adapting overload resolution?

On Saturday, 26 December 2020 at 18:12:02 UTC, H. S. Teoh wrote:
>Implicit conversions are admittedly very convenient in the short term, but in the long term they tend to make code obtuse and hard to maintain.

Could you elaborate a bit more?

Did you have to many times pain with ambiguity errors or did your program run unexpectedly by resolving to the wrong method?

On Sat, Dec 26, 2020 at 06:42:43PM +0000, sighoya via Digitalmars-d wrote:
> On Saturday, 26 December 2020 at 18:12:02 UTC, H. S. Teoh wrote:
> > Implicit conversions are admittedly very convenient in the short term, but in the long term they tend to make code obtuse and hard to maintain.
> 
> Could you elaborate a bit more?
> 
> Did you have to many times pain with ambiguity errors or did your program run unexpectedly by resolving to the wrong method?

It wasn't compile errors necessarily, but it was difficulty understanding what exactly the code is trying to do.  And also painful when you thought one function was returning one type, but it actually returns a different type, so you can't pass it to the next function, but have to insert an extraneous conversion back to the original type. Or worse, you need to store a value in a struct somewhere, but due to implicit conversion the type you get out of a function does not match the type in the struct, and changing the struct's field type will lead to a huge amount of changes.  There have also been occasions of actual bugs introduced by implicit conversions -- because some value implicitly converted earlier than expected, or got to the end via a different chain of conversions than you expected -- though this is relatively rare.

Of course, you can always work around all of this somehow, perhaps by adding even more implicit conversions.  Eventually, the code just accumulates all sorts of weird hacks and you're spending more time working around implicit conversions (or trying to understand them!) than actually making progress in the problem domain.  It becomes a constant source of frustration and waste of time.

Writing code without implicit conversions is tedious and annoying in the short term, but in the long term actually saves time by making the code clearer and more explicit, and more maintainable.


T

-- 
"I'm not childish; I'm just in touch with the child within!" - RL

I'm speaking here from C++'s experience.

Implicit conversion operator overloading is in the category of ideas whose evil nature only becomes apparent after several years:

1. implicit declaration of variables

2. macros

3. operator overloading for non-arithmetic purposes

4. implicit conversion operator overloads

It's like burying your dead cat in Pet Sematary. Sure, it's cool when it comes back to life, but you'll be sssss-ooooo-rrrrr-eeeee !

Thanks a lot for your insights.

Some questions:

>And also painful when you thought one function was returning one type,
> but it actually returns a different type,

You speak about the mix of templates and implicit conversion.

I may be too limited to see that, but I thought once the template parameter is bound it can't change anymore, hence implicit conversion occurs without to rebind the template parameter.
Am I wrong?

>Or worse, you need to
> store a value in a struct somewhere, but due to implicit conversion the type you get out of a function does not match the type in the struct, and changing the struct's field type will lead to a huge amount of changes

This could be true, but it relates to `alias this` which isn't either `implicitConversionOp` nor `implicitCoercionOp`.

>There have also been
> occasions of actual bugs introduced by implicit conversions -- because some value implicitly converted earlier than expected

Okay, maybe I need just a delightful example about this.

On Sunday, 27 December 2020 at 09:27:05 UTC, Walter Bright wrote:
> It's like burying your dead cat in Pet Sematary. Sure, it's cool when it comes back to life, but you'll be sssss-ooooo-rrrrr-eeeee !

Hmm, I wasn't aware that Walter is also a poet :).

> I'm speaking here from C++'s experience.

When talking about the merits of certain features and at the same time referring to their use in C++ inevitably biases the balance of pro and cons to the contra site.

The point is, however, could we do it better than C++?

Regarding templates, we already did.

> 1. implicit declaration of variables

Did you the mention `auto` in conjunction with implicit conversion?


> 2. macros

What has implicit conversion to do with macros, did you mean templates?
As a counterargument, we already have classes and interfaces leading to the same characteristics regarding template overload resolution.

> 3. operator overloading for non-arithmetic purposes
> 4. implicit conversion operator overloads

Well I admit the evolving problem of ambiguity of implicit conversions in overload resolution.
But what is harder for operator overloading than for normal method overloading?
Overusing operators for nonsensical operations is already a code smell.

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. Does C++ support this implicit declaration?