opCast using in template struct

Timon Gehr timon.gehr at gmx.ch
Thu Oct 18 16:51:43 PDT 2012


On 10/19/2012 01:05 AM, Era Scarecrow wrote:
> On Thursday, 18 October 2012 at 22:07:55 UTC, Timon Gehr wrote:
>> On 10/18/2012 11:45 PM, bearophile wrote:
>>> There are other cases. Generally the D compiler should add some
>>> warnings that help against operator overloading mistakes.
>>
>> I don't think that operator overloading gives rise to distinct
>> mistakes. For example, better error messages that just specify the
>> expected name, as in other cases of undefined identifiers, would
>> already fix this.
>
>   Inside a function a badly named identifier becomes obvious since it
> outright tells you. But with regards to opOpAssign and other operator
> overloading I see the error message and I see the call but I don't see
> why it fails.

My suggestion was something like:

error: expression 'e' of type 'S' is not of arithmetic type and it does 
not define opOpAssign!"+".

The compiler should indicate exactly why it fails. If this is not
enough, then the programmer certainly deserves the headache.

> Then I'll try adjusting the signature on my function, not
> realizing it never sees it in the first place due to misspelling.
>

If the issue _is_ with the signature, then the compiler should tell you.
That is the (secondary) job of the compiler.

>   Maybe.. A general warning when something starts with 'op(Op)?[A-Z]'

'op[A-Z]'

> but doesn't actually qualify as any of the override-able operators? That
> seems sensible...

That is a lot better, but what if the typo is within the first 3
characters? :o)


More information about the Digitalmars-d-learn mailing list