Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever...

this should really be fixed...

On Saturday, 5 May 2012 at 05:02:48 UTC, Mehrdad wrote:
> Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever...
>
> this should really be fixed...

Features like this:

typedef int type = 5;
type var;
var.init; // is 5

AFAIK are also lost.

And for those who couldn't care less about Windows, I should also note that it's impossible to distinguish between size_t and uint, etc.

On Saturday, 5 May 2012 at 05:25:29 UTC, Maxim Fomin wrote:
> On Saturday, 5 May 2012 at 05:02:48 UTC, Mehrdad wrote:
>> Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever...
>>
>> this should really be fixed...
>
> Features like this:
>
> typedef int type = 5;
> type var;
> var.init; // is 5
>
> AFAIK are also lost.

(Sorry that wasn't meant to be directed at you, I just happened
to click reply on your post)

On Saturday, 5 May 2012 at 05:25:29 UTC, Maxim Fomin wrote:
> On Saturday, 5 May 2012 at 05:02:48 UTC, Mehrdad wrote:
>> Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever...
>>
>> this should really be fixed...
>
> Features like this:
>
> typedef int type = 5;
> type var;
> var.init; // is 5
>
> AFAIK are also lost.

Mehrdad:
> Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever...
>
> this should really be fixed...

typedef is a quite useful feature, but the one present in D was unsound/broken, especially in presence of OOP. Fixing language features is hard (people didn't seem to understand that typedef is not meant to be used with classes), once their semantics is defined, it's quite hard to fix it. But adding features to D/Phobos is much simpler. So once there is a clear and sound design for what this feature has to do and its semantics, I expect to see in D a way to do the same things. Currently the Typedef in Phobos is more broken than the built-in typedef. Here the Ada language is a good reference to copy from. So the idea of removing typedef was good iff we eventually have something good to replace it.

Bye,
bearophile

On 2012-05-05 05:02:44 +0000, "Mehrdad" <wfunction@hotmail.com> said:

> Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever...
> 
> this should really be fixed...

It should be fixed indeed. Perhaps HWND should be defined more like this:

	struct HWND { void *handle; }

Or if you want it to implement some kind of inheritance scheme:

	struct HANDLE { void *ptr; }
	struct HWND { HANDLE handle; alias handle this; }

That's still a lot better than typedef since you can control what operations are allowed on the type. For instance, you can't multiply two handles with the struct definition, with typedef you could.

My only fear is that this might not work play well with the C calling convention (or Window's in this case). If that's the case, then it's a good argument for having a separate language construct.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

mixin template TypeDef(Type, string name, Type init)
{
    mixin(`struct `~name~` { public alias _impl this; private Type
_impl = init; };`);
}

unittest
{
    mixin TypeDef!(int, `MyInt`, 5);

    MyInt mi;

    assert(typeid(myInt) != typeid(int));
    assert(mi == 5);
}

On Sat, May 5, 2012 at 3:09 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> Mehrdad:
>
>> Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever...
>>
>> this should really be fixed...
>
>
> typedef is a quite useful feature, but the one present in D was unsound/broken, especially in presence of OOP. Fixing language features is hard (people didn't seem to understand that typedef is not meant to be used with classes), once their semantics is defined, it's quite hard to fix it. But adding features to D/Phobos is much simpler. So once there is a clear and sound design for what this feature has to do and its semantics, I expect to see in D a way to do the same things. Currently the Typedef in Phobos is more broken than the built-in typedef. Here the Ada language is a good reference to copy from. So the idea of removing typedef was good iff we eventually have something good to replace it.
>
> Bye,
> bearophile



-- 
Bye,
Gor Gyolchanyan.

How do you fix it for size_t and uint, etc.?

On Saturday, 5 May 2012 at 13:01:08 UTC, Michel Fortin wrote:
> On 2012-05-05 05:02:44 +0000, "Mehrdad" <wfunction@hotmail.com> said:
>
>> Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever...
>> 
>> this should really be fixed...
>
> It should be fixed indeed. Perhaps HWND should be defined more like this:
>
> 	struct HWND { void *handle; }
>
> Or if you want it to implement some kind of inheritance scheme:
>
> 	struct HANDLE { void *ptr; }
> 	struct HWND { HANDLE handle; alias handle this; }
>
> That's still a lot better than typedef since you can control what operations are allowed on the type. For instance, you can't multiply two handles with the struct definition, with typedef you could.
>
> My only fear is that this might not work play well with the C calling convention (or Window's in this case). If that's the case, then it's a good argument for having a separate language construct.

See my version.

On Sat, May 5, 2012 at 10:20 PM, Mehrdad <wfunction@hotmail.com> wrote:
> How do you fix it for size_t and uint, etc.?
>
>
> On Saturday, 5 May 2012 at 13:01:08 UTC, Michel Fortin wrote:
>>
>> On 2012-05-05 05:02:44 +0000, "Mehrdad" <wfunction@hotmail.com> said:
>>
>>> Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever...
>>>
>>> this should really be fixed...
>>
>>
>> It should be fixed indeed. Perhaps HWND should be defined more like this:
>>
>>        struct HWND { void *handle; }
>>
>> Or if you want it to implement some kind of inheritance scheme:
>>
>>        struct HANDLE { void *ptr; }
>>        struct HWND { HANDLE handle; alias handle this; }
>>
>> That's still a lot better than typedef since you can control what operations are allowed on the type. For instance, you can't multiply two handles with the struct definition, with typedef you could.
>>
>> My only fear is that this might not work play well with the C calling convention (or Window's in this case). If that's the case, then it's a good argument for having a separate language construct.
>
>
>



-- 
Bye,
Gor Gyolchanyan.

The one with TypeDef?

That's not how it's defined though.

On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote:
> See my version.