Which operators cannot be overloaded and why not?

On Monday, 13 September 2021 at 14:12:36 UTC, NonNull wrote:

Let's start the list.

• new and delete

Because operators are overloaded in aggregates
new was supported but not anymore, the idea is
that a an aggregate should not be tied a specific allocator.

• post incr/decr

See https://dlang.org/spec/operatoroverloading.html#postincrement_postdecrement_operators. This is an arbitrary limitation imho but the current way enfore that the side effect is not apllied to the expression result.

• condition al expression cond ? exp : exp

No idea why it is not supported... nobody has never complained tho ;)

• typeid

Same... the result of typeid has to be a TypeInfoClass, so there's not much to do... exactness is expected

• is (identity)

could be but I suppose that this stuff needs to be correct to keep code consistent

what else ?

On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote:

And many other boolean operators, unary !, binary && and ||

https://dlang.org/spec/operatoroverloading.html lists all the overloadable operators, and https://dlang.org/spec/expression.html has all the operators, so "which operators" is a matter of close comparison. "why not" is much harder to answer.

On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote:

when you have

alias AA1 = int[int];
alias AA2 = AA1[int];

then you can write

AA2 aa;
aa[0] = [0 : 0];
aa[0][0] = 0;

The [0][0] cannot be expressed using operator overloads (and a custom map type that implements opIndexAssign).But this case is rather due to the fact that druntime seems to do something a bit unusal here (according to an old discussion that happend once on irc).

On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote:

I think the intent is for the boolean operators to be handled via opCast!bool.

On 9/13/21 10:47 AM, user1234 wrote:

alias AA1 = int[int];
alias AA2 = AA1[int];

AA2 aa;
aa[0] = [0 : 0];
aa[0][0] = 0;

This is because the compiler calls a different hook depending on the usage of the expression aa[0]. Which one it calls is not consistent.

There isn't an analog for indexing overloads.

A further example:

int[int] aa;
aa[0]++; // ok
void foo(ref int x) {x++;}
foo(aa[1]); // range violation

-Steve

On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote:

Oh! I have never noticed that && and ||, despite of being quite "ordinary" binary ops are not overloadable.

In styx that works because, although inspired by the D way, in the sense that overloads are implemented in custom types, the selection is done using an expression template

struct S {
    @operator(a && b) function andAnd(T other): auto {return false}
}

So as long as the expression in the attribute argument looks like a valid expression the stuff is found (and the supprot code in the compiler is super simple), e.g with code in a body:

e1 && e2; // look if e1 is an aggregate and if it contains @operator(a && b)
e1 + e2;  // look if e1 is an aggregate and if it contains @operator(a && b)

While D uses specific identifier + templates value param for strings.
(note that only the equivalent of D opBinaryRight works...)

anyway. zorry for this off-topic.

On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote:

They are all indirectly supported if opCast is overloaded:

unittest
{
    struct S
    {
        bool opCast(T = bool)(){return true;}
    }
    S s;
    assert(s && s);
}

so this is a bit like the postincr case.

On Monday, 13 September 2021 at 15:29:05 UTC, user1234 wrote:

i.e "prevent the semantics to be hijacked".

On Monday, 13 September 2021 at 14:59:38 UTC, Paul Backus wrote:

I didn't see it was already suggested and answered the same... but yet that's exactly the case.