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

[Mehrdad]

On Monday, 7 May 2012 at 17:17:55 UTC, Steven Schveighoffer wrote:
> 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.

Okay.

Though you'd be a lot more convincing if you could give an 
example of how typedef was causing problems previously.

I've asked that question several times, but no one's ever given 
me an actual *example* or two of the problems. If I saw one then 
obviously I'd understand why it was removed...

> 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?

I don't understand your response or where you got that idea, but 
I don't think my response would be very interesting even if I 
did...

> 1) pull request.  I'm sure a pull request that makes more 
> correct semantic decisions on implicit casting of HANDLEs would 
> be accepted.

I'm busy right now but perhaps next week -- I'll try and see. 
(Haven't done one before so I may or may not succeed..)

> 2) Make your own types.  You are free to not use 
> standard/existing libraries.

Yes, and I can write the rest of Phobos from scratch as well...

> 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 don't either, so you're definitely right about that.
Especially because I really doubt my library's gonna turn out 
very useful anyway, even if all this was perfect.

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

Yup, I'd love to know what the problems were though. (See the 
first part of the post.)

> 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!

Okay, at least the road is clear now.

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

Lol, ok, another case of miscommunication then.