Operator declaration

[Meta]

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.