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

[Mehrdad]

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".)