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.
