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

[Mehrdad]

On Sunday, 6 May 2012 at 03:15:01 UTC, Matt Peterson wrote:
> I understand you're frustrated, but you don't need to be so 
> hostile.

You're completely right... I apologize about that, it was 
completely my fault.
I've indeed been pretty frustrated at this typedef nonsense (and 
the like), since it's made something otherwise elegant become 
something very annoying and
time-wasting.

To @Chris Cain as well, my response there was rather hostile too 
-- my apologies about that as well.


> I agree with most of what you've said on this thread. And just 
> because I made a short comment doesn't mean I don't know about 
> std.stdint, sizediff_t, etc. My point was to say that size_t is 
> supposed to be the size of the architecture's word. I said 
> nothing about it being the "fastest" type or even whether it 
> was useful . I would be very interested if you have a better 
> solution for the integer typing/naming problem.

Right, but what I was saying was that that *isn't* what it's 
meant to be! It's just a *size* type, not a *word* of any kind... 
(think about systems with interleaving pointers, for example, x86 
with segmentation -- the notion of a "word" isn't so obvious 
anymore, when denoting sizes)


> There definitely needs to be way to define a type that can't 
> implicitly cast to its base type. The problem is that the 
> original typedef did do implicit casting away, and that has 
> potential to cause confusion when porting from C or D1. I don't 
> see that as much of a problem, but others might.

Yeah, I still don't understand what the "potential to cause 
confusion" was.
Was it *actually* causing a significant problem, or was it just a 
"potential" problem?