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.
