Jump to page: 1 2
Thread overview
Which operators cannot be overloaded and why not?
Sep 13
NonNull
Sep 13
user1234
Sep 13
jfondren
Sep 13
user1234
Sep 13
Basile B.
Sep 13
user1234
Sep 13
user1234
Sep 13
NonNull
Sep 13
user1234
Sep 13
user1234
Sep 13
NonNull
September 13

Which operators cannot be overloaded and why not?

September 13

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

>

Which operators cannot be overloaded and why not?

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 ?

September 13

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

>
  • condition al expression cond ? exp : exp

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.

September 13

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

>

what else ?

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

September 13

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

>

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

>
  • condition al expression cond ? exp : exp

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.

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

September 13

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

>

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

>

what else ?

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

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

September 13

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

>

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

>
  • condition al expression cond ? exp : exp

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.

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.

September 13

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

>

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

>
  • condition al expression cond ? exp : exp

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

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.

September 13

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

>

[...]
so this is a bit like the postincr case.

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

September 13

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

>

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

>

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

>
  • condition al expression cond ? exp : exp

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.

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

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

« First   ‹ Prev
1 2