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

[Chris Cain]

On Saturday, 5 May 2012 at 23:41:52 UTC, Mehrdad wrote:
> Even if I _couldn't_ tell you a reason, that'd still be a lame
> question, because the *entire point* of reflection is to access
> type information information about the program... if for nothing
> other than printing it out for the user.

Also, just as a heads up: If you want language features to be 
added (or re-added in this case), saying "I shouldn't have to 
give a reason" is an extremely bad way to start. You should look 
through a lot of old threads. Even when people sometimes give 
some relatively incredible reasons (at least, IMO) for why 
something should be done, Walter Bright and Andrei Alexandrescu 
will disagree with adding it to the language.

There's at least two good reasons why:
1. D is already pretty complex (and can do almost way too much 
stuff). In fact most of what you want could easily added via 
Phobos ("type safety" of types OTHER than size_t) because of that 
power.
2. You're not actually arguing whether a language feature should 
be added. You're arguing why your language feature should be 
prioritized above all the other things in the queue (such as bug 
fixes). When it comes down to it, which do you think is more 
important? A bug which prevents valid code from compiling (or, 
worse, silently producing the wrong result) ... or a language 
feature that, for the most part, can be implemented in Phobos in 
three to five lines of code whose reason for existing is "I 
shouldn't have to give a reason"?

> But it's more than that: it's the same darn reason why you need
> to distinguish between
> void* and HWND -- it's an ERROR!

I'd agree, but you have a solution for that now.

> In other words, this must NOT compile!
>
> auto call(F, T...)(F func, T args) { return func(args); }
> void test(uint) { }
> void main() { call!(typeof(&test), size_t)(&test, 1); }
>
> If you're still asking "why shouldn't it compile" then you 
> should
> look up what "type safety" means.

Please don't put words into my mouth :)

In this case, the definition of size_t is made with an alias, so 
via alias semantics, this will compile on x86 but not on x86-64. 
It's rather surprising the first few times you do this if you're 
being careless. In terms of type safety, I can see your point.

I'd be holding back if I didn't say that when I started learning 
D a couple of months ago I got in the habit of compiling in both 
32-bit and 64-bit Linux to figure out if I was using size_t in 
the right places. At this point, I don't make the mistake 
anymore, but I wouldn't be surprised that it doesn't make things 
more difficult in the long run as more people start using D.

However, ultimately, I have to ask if this is what you're doing 
(trying to make your code size_t "type safe"), or are you just 
trying to get typedef back so you can use that instead of 
learning how to do what you want the current D-way? Because it's 
going to take much longer and take a lot more effort for you to 
change D into C++ rather than just learning the way D is right 
now. Especially if people keep giving reasonable approaches for 
how you can do what you want in current D.