On Thursday, 23 April 2026 at 15:25:35 UTC, H. S. Teoh wrote:
On Thu, Apr 23, 2026 at 03:04:59PM +0000, Dom Disc via
Digitalmars-d-learn wrote:
```d
struct MyType
{
ubyte val;
MyType opOpAssign(string op)(const MyType x) if(op =="^^")
{
val ^^= x.val;
}
}
MyType m;
m ^^= m;
```
==> cannot implicitly convert expression
`pow(cast(int)__powtmp1234,
cast(int)x.val)` of type `int` to `ubyte`
This is one of the bugs that we bought with the strange policy
that
operators do NOT return same type as their operands.
"convert everything to int but not back" :-(
I hate D's policy on integer conversions. That's why I wrote
nopromote.d which I posted somewhere in these forums, that lets
you attach `.np` (for "no promote") to a short integer
somewhere in an expression to "poison" it so that all
arithmetic is done without promotion and assignable back to the
original variable.
But in this special case I cannot see how to avoid this. Where
do I need to put the cast to make this conversion explicit?!?
Apparently you need to write it out explicitly:
```
val = cast(ubyte)(val ^^ x.val);
```
It's *really* b0rken IMO that you cannot even use `^^=` on a
short integer! I'd file a bug, but Walter has said that he's
not going change his stance on this.
T
Now that we have ImportC, maybe he he can be convinced to soften
his stance a bit. His argument is that people will paste C code
into a .d file and expect it to work the same as in C. However,
now they can just take that C code and compile it directly with
DMD, and use it seemlessly from D. So IMO his reasoning doesn't
hold that much weight anymore.
