On Mon, 07 May 2012 12:10:20 -0400, Mehrdad <wfunct...@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
