Multiple alias this and alias this in classes

[Walter Bright]

On 1/17/2023 10:16 AM, 12345swordy wrote:
> We don't need alias this for classes, we just need custom implicit conversion 
> for structs and classes. Other OOP languages have them, yet it from the cpp 
> world that I keep hearing complaints regarding implicit conversions.

Implicit conversion is fine by itself. But consider the combinations of:

1. inheritance
2. alias this
3. overloading
4. implicit conversion
5. multiple inheritance
6. multiple alias this
7. integer promotion

(which all can be considered forms of implicit conversion) and it becomes 
incomprehensible.

It's not a question of "can we come up with a set of rules to make it all work". 
We certainly can. Whether the rules are predictable and intuitive rather than 
arbitrary and capricious is another matter entirely.

Case in point - C++ overloading rules. Last time I checked, they are two rather 
dense pages in the C++ Standard. I don't know anyone who can keep those rules in 
their head. I know I can't, and I implemented them correctly.

So how do people deal with it? This is what they tell me - they try random 
things until it works. They don't know why it works, and don't really care, they 
just move on.

This was one of the things that motivated me to move away from C++. D shouldn't 
be another C++. The overloading rules in D are much less complicated in C++ 
(because D uses the "least as specialized" rule), but still more complex than 
I'm comfortable with.

(The "least as specialized" rule is what C++ uses for template overloading, the 
C++ developers found a better way than the rats' nest of function overloading 
rules. I thought that would work better for function overloading, and indeed it 
does.)

If we go down the road of C++ complexity, we can't come back from it. We'll be 
stuck like C++ is stuck with function overloading.

Deciding what to leave out of a language is just as important as deciding what 
to put in. In fact, maybe it's *more* important.