"Mehrdad" , dans le message (digitalmars.D:166381), a écrit : > On Monday, 7 May 2012 at 20:25:35 UTC, Steven Schveighoffer wrote: >> On Mon, 07 May 2012 15:48:22 -0400, Mehrdad >> <[email protected]> wrote: >> >> I'm looking at this: >> >> m += 5; // ok >> m = m + 5; // error >> >> And thinking, hm.. this is no good :) > > Yeah, that means they were implemented poorly. :P > It should've been an error for both, because neither of them make > sense. > I don't see why the first one couldn't have been an error though, > so I guess I'll have to dig up old threads on why the first one > wasn't disallowed, since I can't see why we couldn't just > disallow it right there...
One reason could be this : mint, just like int has an opOpAssign!"+" with takes an int, so "m += 5" is valid... Using any other rule raises a lot of questions: - Should all operators of typedef-type with its base-type parameter be rewritten to take a typedef-type ? - What about returned type? - What about methods that are not operators? - What about free functions? - If something is implicitely castable/promoted to the base type, should it be implicitely castable to the typedef ? What choice of typedef would you make? size_t is a good example of why typedef is poor. Should this compile, and if it does, what is the type of the result of the operations ? typedef uint size_t; size_t a, b; a - b; -b; a * b; a * 2; a * -2; a * 2u; I don't think typedef if a good solution to implement a type safe size_t. Solutions may be found in typesafe langages, but things are not as obvious as you would like them to be. -- Christophe
