Why typedef's shouldn't have been removed :(

[Christophe]

"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 
>> <wfunction at hotmail.com> 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