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

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

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


> I can't say I ever used typedef when it was allowed.

That doesn't make it useless. :P

> 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'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)

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

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.

On Mon, 07 May 2012 14:08:33 -0400, Mehrdad <wfunction@hotmail.com> wrote:

> 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 think it was more that the whole concept was flawed -- typedef int myint never really did exactly what you wanted it to.

For example:

myint m = 1; // ok
m += 5; // ok
m = m + 5; // error?

Things got even worse when you weren't typedef'ing a basic type.  I think the advents in type construction in D2 have made typedef almost completely implementable as a library type, and we can do it the way it was intended!  Don't forget, typedef was there when we had no "alias this" and no blanket operator overloading.

When all you want is an opaque type that just can't be implicitly cast from something else (such as HANDLE) typedef is a crude and inaccurate method to do that.

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

Maybe it wasn't you, let me check...

http://forum.dlang.org/post/jnueti$1opd$1@digitalmars.com

OK, it was you, but under a different context, and I actually don't see you mentioning C there.  Sorry for the confusion/accusation.  I have a hard time keeping track of all these different threads in my head :(

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

If it's better than phobos, then maybe we can use it!

Seriously though, I get what you are saying.  Fortunately, we have a very significant team working on phobos (I think more than a dozen people have commit rights), so the situation for "grr... phobos really should do *this*, but I can't get phobos changed" can be pretty readily resolved.  Github and pull requests have made this incredibly easy.  I've looked at some pull requests that were dead simple, verified it in a matter of minutes, and click one button to pull it.  Even when I have no experience in the related modules.  Brad Roberts (and I think Daniel Murphy?) have set up an awesome testing system that automatically verifies pull requests on all the supported platforms using the latest from git.  See here:

http://d.puremagic.com/test-results/pulls.ghtml

The chances of your pull request being validated and pulled -- if it makes a good improvement to phobos -- are much much higher than they used to be.

-Steve

On Monday, 7 May 2012 at 19:29:26 UTC, Steven Schveighoffer wrote:
> I think it was more that the whole concept was flawed -- typedef int myint never really did exactly what you wanted it to.
>
> For example:
>
> myint m = 1; // ok
> m += 5; // ok
> m = m + 5; // error?

It's definitely an error, because 5 isn't myint.
Of course, it wouldn't be an error in C code, but keeping source compatibility isn't a goal either.

Wouldn't a global search-and-replace that replaced "typedef" with "alias" when porting C code have fixed 99% of this issue, practically speaking?

> Things got even worse when you weren't typedef'ing a basic type.

It sounds so trivial to fix though (especially since it's not silent breakage)...
Would you mind giving another (actual) example (perhaps with a custom type?) that came up, and which shows the extent of the problem and why it was difficult to solve without disallowing typedef entirely?
I'm having a hard time seeing why the problem was so difficult (or tedious) to fix... a search/replace for typedef/alias would've fixed all (or almost) all the cases when porting C code, right?

> I think the advents in type construction in D2 have made typedef almost completely implementable as a library type, and we can do it the way it was intended!  Don't forget, typedef was there when we had no "alias this" and no blanket operator overloading.

Well, I'll have to try it and see -- I neither agree nor disagree.
Right now I'm just trying to understand the problems it was causing, though.

> When all you want is an opaque type that just can't be implicitly cast from something else (such as HANDLE) typedef is a crude and inaccurate method to do that.

I don't really agree with that (though an example as I asked for above^ could definitely make me agree)

> Maybe it wasn't you, let me check...
>
> http://forum.dlang.org/post/jnueti$1opd$1@digitalmars.com
>
> OK, it was you, but under a different context, and I actually don't see you mentioning C there.  Sorry for the confusion/accusation.  I have a hard time keeping track of all these different threads in my head :(

Haha no worries. :)

> Seriously though, I get what you are saying. [...] The chances of your pull request being validated and pulled -- if it makes a good improvement to phobos -- are much much higher than they used to be.

Awesome, I'll probably try my hand at it (probably around next week). :)

On Monday, 7 May 2012 at 19:29:26 UTC, Steven Schveighoffer wrote:
> Seriously though, I get what you are saying.  Fortunately, we have a very significant team working on phobos (I think more than a dozen people have commit rights), so the situation for "grr... phobos really should do *this*, but I can't get phobos changed" can be pretty readily resolved.  Github and pull requests have made this incredibly easy.  I've looked at some pull requests that were dead simple, verified it in a matter of minutes, and click one button to pull it.  Even when I have no experience in the related modules.  Brad Roberts (and I think Daniel Murphy?) have set up an awesome testing system that automatically verifies pull requests on all the supported platforms using the latest from git.  See here:
>
> http://d.puremagic.com/test-results/pulls.ghtml
>
> The chances of your pull request being validated and pulled -- if it makes a good improvement to phobos -- are much much higher than they used to be.
>
> -Steve

Whoa! that auto-tester is pretty sharp!

I've actually been wondering about this. I recently ran into a bug in Phobos, quickly tacked that there was an issue for it, made an easy fix, submitted a pull request and commented on the bug. All tests in the above page are coming out green, so I guess I've got that going for it.

https://github.com/D-Programming-Language/phobos/pull/557

Is there some additional communication channel I need to notify for someone to have a look at it and at least comment on any errors/mistakes? Or am I pretty much stuck to wait for whoever is in charge of that module to run into it?

On Mon, 07 May 2012 15:48:22 -0400, Mehrdad <wfunction@hotmail.com> wrote:

> On Monday, 7 May 2012 at 19:29:26 UTC, Steven Schveighoffer wrote:
>> I think it was more that the whole concept was flawed -- typedef int myint never really did exactly what you wanted it to.
>>
>> For example:
>>
>> myint m = 1; // ok
>> m += 5; // ok
>> m = m + 5; // error?
>
> It's definitely an error, because 5 isn't myint.
> Of course, it wouldn't be an error in C code, but keeping source compatibility isn't a goal either.

I'm looking at this:

m += 5; // ok
m = m + 5; // error

And thinking, hm.. this is no good :)

C compatibility is not what we are after here, alias already handles C compatibility.

> Wouldn't a global search-and-replace that replaced "typedef" with "alias" when porting C code have fixed 99% of this issue, practically speaking?

No, it's not a portability issue.  It's a WTF issue.

>> Things got even worse when you weren't typedef'ing a basic type.
>
> It sounds so trivial to fix though (especially since it's not silent breakage)...
> Would you mind giving another (actual) example (perhaps with a custom type?) that came up, and which shows the extent of the problem and why it was difficult to solve without disallowing typedef entirely?
> I'm having a hard time seeing why the problem was so difficult (or tedious) to fix... a search/replace for typedef/alias would've fixed all (or almost) all the cases when porting C code, right?

I'm almost 100% certain that the issues had nothing to do with C compatibility.  It was all in how D typedefs behaved strangely.

Not being one to have used them much, I can only recollect that one example.  I do remember people bitching about them quite a bit, and nobody really having any good ideas on how to fix them, but I don't know circa what time period to look for those discussons.  One person who was an ardent supporter of typedefs, and still wants *something* like them is bearophile.  He might be able to list some issues/find some old posts/bugs that make more sense.

-Steve

On Monday, 7 May 2012 at 20:25:35 UTC, Steven Schveighoffer wrote:
> On Mon, 07 May 2012 15:48:22 -0400, Mehrdad <wfunction@hotmail.com> wrote:
>
> I'm looking at this:
>
> m += 5; // ok
> m = m + 5; // error
>
> And thinking, hm.. this is no good :)

Yeah, that means they were implemented poorly. :P
It should've been an error for both, because neither of them make sense.
I don't see why the first one couldn't have been an error though, so I guess I'll have to dig up old threads on why the first one wasn't disallowed, since I can't see why we couldn't just disallow it right there...


> C compatibility is not what we are after here, alias already handles C compatibility.

I see, ok.


> Not being one to have used them much, I can only recollect that one example.  I do remember people bitching about them quite a bit, and nobody really having any good ideas on how to fix them, but I don't know circa what time period to look for those discussons.  One person who was an ardent supporter of typedefs, and still wants *something* like them is bearophile. He might be able to list some issues/find some old posts/bugs that make more sense.

Ah okay thanks.

@bearophile: If you see happen this, would you mind posting examples? :)

There's an _is_ expression, which allows one to determine the underlying type of a enum:

template EnumType(T)
    if(is(T U = enum))
{
    alias U EnumType;
}

It would be awesome if the same mechanism was implemented for aliased types:

template AliasType(T)
    if(is(T U = alias))
{
    enum string AliasType = U;
}

which would return a string, containing the alias name.

Steven Schveighoffer:

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

Right.

Bye,
bearophile