On Sunday, 6 May 2012 at 12:04:52 UTC, Chris Cain wrote:
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.
Well, it's not *quite* like I was saying "I shouldn't have to
give a reason".
Rather, I was saying that, when you're doing reflection, you
should have access to all information, even if it looks useless.
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).
I *wasn't* saying my issue was above the bug fixes... I'm not
sure where you got that impression. I was just saying it needs to
be somewhere in the queue.
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"?
Again, I wasn't saying it's /more/ important than anything...
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.
Not for the built-in types though.
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.
Yeah that *is* my point, lol.
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?
I'm giving *multiple* reasons for getting 'typedef' back:
1. Type safety.
2. Reflection should be able to get alias information. Asking
"why" is silly... it's reflection.
3. The current suggested use of alias as an "alternative" to
typedef makes things worse due to all the implicit assignments
that they allow in your code.
- IMHO using 'alias' instead of 'typedef' is a *BUG* (no, I'm
not just referring to HANDLE; yes, that includes size_t), since
it allows assignments that shouldn't be able to take place on ANY
platform (without a cast).
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.
I'm not sure where you got the idea of C++ from.
C++ doesn't even _have_ reflection, and it treats typedefs pretty
much the same as D does right now...
Especially if people keep giving reasonable approaches for how
you can do what you want in current D.
You're missing the problem:
(1) I'm saying function(size_t) and function(uint) are different
functions, and people are telling me that's silly, who cares
about the type anyway. That's not an 'alternative'.
(2) I'm saying function(void*) and function(HANDLE) are different
functions, and people are telling me to use TypeDef. Which is of
course an alternative, except that it requires me to modify the
source code of my library. (Which, by the way, goes against the
concept of dynamic linking, which IMHO is another problem. But I
guess that'll only be an issue when D supports dynamic linking
correctly...)
I would be more inclined to agree with those reasons (1) and (2)
were the same reason, but they aren't!
So what that tells me is that people are just giving random
reasons for not adding back typedef, without actually thinking
about the implications.
(I'm pretty sure none of the people who suggested using TypeDef
for HWND realized that we'd have to do the same thing for size_t
and such. Otherwise, when I'd have asked about that, the response
wouldn't have been "who cares".)
