Given

alias GLenum = uint;
void glSomeFunction(GLenum, uint);

Now, is there some way to differentiate between GLenum and uint when using ParameterTypeTuple!glSomeFunction?

I'm writing a function which shows the arguments a GL function was called with when an error occurs. The GLenum needs to be printed as a stringified version of the constant's name, while the uint is just an uint.

On 25/05/2014 12:04, Rene Zwanenburg wrote:
> Given
>
> alias GLenum = uint;
> void glSomeFunction(GLenum, uint);
>
> Now, is there some way to differentiate between GLenum and uint when
> using ParameterTypeTuple!glSomeFunction?
>
> I'm writing a function which shows the arguments a GL function was
> called with when an error occurs. The GLenum needs to be printed as a
> stringified version of the constant's name, while the uint is just an uint.

Apparently this is deprecated even though alias cannot replicate it.

typedef uint GLenum;
writeln(GLenum.stringof);

On Sun, 25 May 2014 04:04:09 -0700, Rene Zwanenburg <renezwanenburg@gmail.com> wrote:

> Given
>
> alias GLenum = uint;
> void glSomeFunction(GLenum, uint);
>
> Now, is there some way to differentiate between GLenum and uint when using ParameterTypeTuple!glSomeFunction?
>
> I'm writing a function which shows the arguments a GL function was called with when an error occurs. The GLenum needs to be printed as a stringified version of the constant's name, while the uint is just an uint.

An alias is simply another name for the same thing. There is no type difference.

You may be able to do some template trickery with template aliases to detect when an alias is used. But I'd recommend using enum instead of alias:

enum GLenum : uint { constant = value}

This creates a genuine new type, and also gives you a place to put constants. However, it's not implicitly castable from uint, so it has some drawbacks. You can cast back to uint implicitly though.

There is also a library typedef mechanism (in std.typecons perhaps?), you can look into that. It should have the same limitations as enum.

-Steve

On Sunday, 25 May 2014 at 14:40:06 UTC, Steven Schveighoffer wrote:
> On Sun, 25 May 2014 04:04:09 -0700, Rene Zwanenburg <renezwanenburg@gmail.com> wrote:
>
>> Given
>>
>> alias GLenum = uint;
>> void glSomeFunction(GLenum, uint);
>>
>> Now, is there some way to differentiate between GLenum and uint when using ParameterTypeTuple!glSomeFunction?
>>
>> I'm writing a function which shows the arguments a GL function was called with when an error occurs. The GLenum needs to be printed as a stringified version of the constant's name, while the uint is just an uint.
>
> An alias is simply another name for the same thing. There is no type difference.
>
> You may be able to do some template trickery with template aliases to detect when an alias is used. But I'd recommend using enum instead of alias:
>
> enum GLenum : uint { constant = value}
>
> This creates a genuine new type, and also gives you a place to put constants. However, it's not implicitly castable from uint, so it has some drawbacks. You can cast back to uint implicitly though.
>
> There is also a library typedef mechanism (in std.typecons perhaps?), you can look into that. It should have the same limitations as enum.
>
> -Steve

I'm using Derelict as OpenGL binding, so I can't change the API. Derelict has chosen not to use enum so any C code sample can be used as-is. The downside is that it makes writing idiomatic D code a bit harder. For a D enum I could get the string representation using to!string, now I have to do some compile time magic.

It's not really an issue though. I was wondering if there was a simple solution, but I'll just print both the uint value and string representation if any. Good enough for me :)

On Sun, 25 May 2014 18:13:17 -0400, Rene Zwanenburg <renezwanenburg@gmail.com> wrote:

> On Sunday, 25 May 2014 at 14:40:06 UTC, Steven Schveighoffer wrote:
>> On Sun, 25 May 2014 04:04:09 -0700, Rene Zwanenburg <renezwanenburg@gmail.com> wrote:
>>
>>> Given
>>>
>>> alias GLenum = uint;
>>> void glSomeFunction(GLenum, uint);
>>>
>>> Now, is there some way to differentiate between GLenum and uint when using ParameterTypeTuple!glSomeFunction?
>>>
>>> I'm writing a function which shows the arguments a GL function was called with when an error occurs. The GLenum needs to be printed as a stringified version of the constant's name, while the uint is just an uint.
>>
>> An alias is simply another name for the same thing. There is no type difference.
>>
>> You may be able to do some template trickery with template aliases to detect when an alias is used. But I'd recommend using enum instead of alias:
>>
>> enum GLenum : uint { constant = value}
>>
>> This creates a genuine new type, and also gives you a place to put constants. However, it's not implicitly castable from uint, so it has some drawbacks. You can cast back to uint implicitly though.
>>
>> There is also a library typedef mechanism (in std.typecons perhaps?), you can look into that. It should have the same limitations as enum.
>>
>
> I'm using Derelict as OpenGL binding, so I can't change the API.Derelict has chosen not to use enum so any C code sample can be used as-is.

I get it. I don't necessarily agree with that, but it's not my library :)

I think it would be difficult to achieve without changing the actual function definition. Perhaps you could wrap the functions with your own, and use your own enum type. The enum as I defined it above, should implicitly cast to uint.

-Steve

On Tuesday, 27 May 2014 at 18:05:24 UTC, Steven Schveighoffer wrote:
> I get it. I don't necessarily agree with that, but it's not my library :)
>
> I think it would be difficult to achieve without changing the actual function definition. Perhaps you could wrap the functions with your own, and use your own enum type. The enum as I defined it above, should implicitly cast to uint.
>
> -Steve

Apologies for the late reply.

Manually wrapping seems a bit too heavy handed. On the other hand I have similar issues with the other Derelict libraries. For example, the GLFW_KEY_XXX enums. I'd much rather store stringified key bindings in a configuration file than raw key codes. With a bit of effort I should be able to build something that translates all these C like libraries to something more D like...