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

[Matt Peterson]

On Sunday, 6 May 2012 at 03:28:32 UTC, Mehrdad wrote:
>
> 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)
>

Yeah, figuring out what to name something is always a challenge, 
and the huge variety and complexity of modern, and even 
not-so-modern processors doesn't help at all.

>
>> 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?

The issue is if someone new to D2 is porting code from C or D1, 
they would get all kinds of weird errors caused by using typedef 
instead of D2's alias and trying to do math or expecting implicit 
casting to work. But D2 is a different language, with different 
syntax and semantics. Anyone expecting copied C to "just work" in 
D2 is expecting a miracle, but that's not to say we can't try to 
make it as easy as possible.

IMO, alias is a much better name than typedef, which is quite 
generic because technically any struct, class, or even function 
declaration is defining a new type. But adding a new keyword is 
ugly, assuming you can think of a good one, so typedef is 
probably the best choice. The only other alternative is reusing 
existing keywords, but I can't even think of a good choice. Does 
any of static/const/immutable/etc. alias sound good to anyone?