Multiple alias this and alias this in classes

[H. S. Teoh]

On Tue, Jan 17, 2023 at 12:16:25PM -0800, Walter Bright via Digitalmars-d wrote:
[...]
> 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. [...]
[...]
> 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.

In some areas, D already feels like this.

Errors in function literals are an especially egregious instance of this
problem. When you have a long UFCS chain inside a template function, an
error inside one of the lambdas can cause the entire template to fail to
instantiate; but no thanks to error gagging/SFINAE, the compiler just
moves on to the next overload to try. That overload may (partially)
succeed, but since it wasn't the intended recipient it will also
inevitably fail. By the time the compiler has exhausted the list of
overloads, it has already gone far beyond the actual location of the
error, and any error messages that it may try to give will be mostly
irrelevant except perhaps for that one needle buried in pages and pages
of haystack.

When the error is a syntax error, there's still a way (albeit tedious
and frustrating) to track it down; when the problem is a wrong parameter
type, attribute, or overload that got unexpectedly matched instead of
the intended one, it quickly devolves into a game of "let me try to
stick random attributes on the lambda until it works, and call it a
day".

D's integer promotion rules are especially bad for this: an overload
that takes char will happily accept an integer literal argument; and an
overload that takes int will happily accept (in some cases, even prefer)
a bool rather than the bool overload.  In isolation, this isn't a big
deal; you just learn the integer promotion rules and design your API
around the issue to avoid it.  But when this happens deep inside generic
code within several nested layers of templates in 3rd party library
code, the actual cause of the problem is just about impossible to
locate.


[...]
> (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.)

That's arguable when it comes to integer promotion rules. When calling a
f(true) prefers a char overload over an int overload, when a char
literal implicit converts to an int whereas arithmetic involving ubytes
require an explicit cast to be assigned back to a ubyte, that's not
intuitive at all; that's counterintuitive and capricious.  It only
(barely) makes sense when you're the one who wrote the rules and
therefore take them for granted; to anyone else, it's completely
backwards and nonsensical.


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

At least on this we agree. :-D


T

-- 
Your inconsistency is the only consistent thing about you! -- KD