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

[Steven Schveighoffer]

On Mon, 07 May 2012 12:10:20 -0400, Mehrdad <wfunction at hotmail.com> wrote:

> On Monday, 7 May 2012 at 12:18:36 UTC, Steven Schveighoffer wrote:
>> No, they are the same function.  size_t is aliased to uint.  What *you*  
>> want size_t to mean is not what it is, it's an alias to the word-sized  
>> unsigned integer on a platform.  Get used to it, use another type if  
>> you don't want it to be that.
>
> No kidding! I use a different language altogether when I don't like D.
> That doesn't tell me anything useful though...

Nothing in this whole thread seems to be very useful.  I don't know how  
else to answer your post except -- sorry, we're not going to change it.

>
>> It's the same in C/C++ BTW.  D's alias === C's typedef, and C's size_t  
>> is a typedef.
>
> Did you read my own response to someone else? You're telling me  
> something I already mentioned myself...
> My response: "C++ doesn't even _have_ reflection, and it treats typedefs  
> pretty
> much the same as D does right now..."

It's hard to see where you are coming from.  You have mentioned that doing  
Windows low-level programming is hard on most platforms except for C.   
Well, if C made it easy, why not duplicate what they did?

>>> (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.
>>
>> Wait, you have to modify one type definition, right?  Is that really  
>> not satisfactory?  I don't understand this line of reasoning.
>
> No, it's not satisfactory, because I'm not always in control of the type  
> definition.

1) pull request.  I'm sure a pull request that makes more correct semantic  
decisions on implicit casting of HANDLEs would be accepted.
2) Make your own types.  You are free to not use standard/existing  
libraries.

Given that you want to write an *entire toolkit*, I doubt anyone gives a  
shit whether your low-level code works with standard phobos-defined HANDLE  
types.

>> I can't say I ever used typedef when it was allowed.
>
> That doesn't make it useless. :P

This was not my reason for saying it.  I was qualifying what I was about  
to say by saying "I don't have a lot of experience with typedefs".

>> I can see how it can be useful in certain situations, but I think the  
>> path is available to make an equivalent library solution work (it seems  
>> several people have said it doesn't, why not spend time trying to fix  
>> it rather than complaining about features that aren't coming back?)
>
> Um... if people don't agree that size_t should be a different type, why  
> would I spend time 'fixing' something that won't be used anyway?

I meant fixing the library solution so it *does* work how you want.  In  
other words, "bringing back typedefs" isn't going to happen.  It's not a  
solution that is practical, or likely.

But making std.typecons.TypeDef work *is* a valid path to get what you  
want (typedefs that work like they used to).  If that isn't possible,  
let's fix the language constructs that are blocking it!

>>> (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".)
>>
>> I think they didn't realize it because it's completely false ;)
>>  You saying it's not false doesn't make it any more true.
>
> It might have been false, but if so, that falsehood definitely wasn't  
> communicated. So from my perspective, it's true. (I don't have ESP to  
> figure out what people *really* think of, sorry... and no pun intended  
> :P)

No I mean it's completely false that fixing HWND means we have to fix  
size_t.  size_t is not broken in any way, HWND is, and I agree we need a  
solution that works.

-Steve