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
--
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at
it. -- Pete Bleackley
