When writing C bindings I usually create lots of aliases via a string mixin to pull enum members into the enclosing scope so it's compatible to C.
Would it be wise to let the compiler do this automatically for extern(C) enums?

On Thursday, January 26, 2012 02:06:45 Trass3r wrote:
> When writing C bindings I usually create lots of aliases via a
> string mixin to pull enum members into the enclosing scope so
> it's compatible to C.
> Would it be wise to let the compiler do this automatically for
> extern(C) enums?

Why? You're using them in D code, not C code. What difference does it make if the enum is one that's used in C code or not? Why would you use such aliases with enums from C but not those from D/ What makes enums from C different?

- Jonathan M Davis

On 01/25/2012 05:12 PM, Jonathan M Davis wrote:
> On Thursday, January 26, 2012 02:06:45 Trass3r wrote:
>> When writing C bindings I usually create lots of aliases via a
>> string mixin to pull enum members into the enclosing scope so
>> it's compatible to C.
>> Would it be wise to let the compiler do this automatically for
>> extern(C) enums?
>
> Why? You're using them in D code, not C code. What difference does it make if
> the enum is one that's used in C code or not? Why would you use such aliases
> with enums from C but not those from D/ What makes enums from C different?
>
> - Jonathan M Davis

Copy paste portability?

On 2012-01-26 02:06, Trass3r wrote:
> When writing C bindings I usually create lots of aliases via a string
> mixin to pull enum members into the enclosing scope so it's compatible
> to C.
> Would it be wise to let the compiler do this automatically for extern(C)
> enums?

You can use anonymous enums. The members will then live in the global scope. You can then use just one alias to an int, uint or what's appropriate.

-- 
/Jacob Carlborg

> You can use anonymous enums. The members will then live in the global scope. You can then use just one alias to an int, uint or what's appropriate.

Yeah but you loose type safety.

On 2012-01-26 01:12:40 +0000, Jonathan M Davis <jmdavisProg@gmx.com> said:

> On Thursday, January 26, 2012 02:06:45 Trass3r wrote:
>> When writing C bindings I usually create lots of aliases via a
>> string mixin to pull enum members into the enclosing scope so
>> it's compatible to C.
>> Would it be wise to let the compiler do this automatically for
>> extern(C) enums?
> 
> Why? You're using them in D code, not C code. What difference does it make if
> the enum is one that's used in C code or not? Why would you use such aliases
> with enums from C but not those from D/ What makes enums from C different?

Often C enum value naming takes into account that they'll live in the outer scope. For instance:

	enum UITableViewRowAnimation {
   	UITableViewRowAnimationFade,
	    UITableViewRowAnimationRight,
	    UITableViewRowAnimationLeft,
	    UITableViewRowAnimationTop,
	    UITableViewRowAnimationBottom,
	    UITableViewRowAnimationNone,
	    UITableViewRowAnimationMiddle,
	    UITableViewRowAnimationAutomatic = 100
	}

So if you're doing direct bindings where you don't want to change the names, how do you use that in D?

	UITableViewRowAnimation.UITableViewRowAnimationFade

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

On 2012-01-26 11:51:10 +0000, "Trass3r" <un@known.com> said:

>> You can use anonymous enums. The members will then live in the global scope. You can then use just one alias to an int, uint or what's appropriate.
> 
> Yeah but you loose type safety.

Or if you absolutely need both type safety and the values to live in the outer scope, you can do this:

	enum Something
	{
		SomethingPointy,
		SomethingSmooth,
	}
	alias Something.SomethingPointy SomethingPointy;
	alias Something.SomethingSmooth SomethingSmooth;

But that's rather extreme verbosity at the definition.


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

> Or if you absolutely need both type safety and the values to live in the outer scope, you can do this:
>
> 	enum Something
> 	{
> 		SomethingPointy,
> 		SomethingSmooth,
> 	}
> 	alias Something.SomethingPointy SomethingPointy;
> 	alias Something.SomethingSmooth SomethingSmooth;
>
> But that's rather extreme verbosity at the definition.

As I said in the first post, this is what I actually do.
Though I use a mixin like mixin(bringIntoCurrentScope!Something);

But inserting this everywhere is rather annoying. And since the whole module is guarded by an extern(C): anyway I figured the compiler could do it for me.

> Often C enum value naming takes into account that they'll live in the outer scope. For instance:
>
> 	enum UITableViewRowAnimation {
>   	UITableViewRowAnimationFade,
> 	    UITableViewRowAnimationRight,
> 	    UITableViewRowAnimationLeft,
> 	    UITableViewRowAnimationTop,
> 	    UITableViewRowAnimationBottom,
> 	    UITableViewRowAnimationNone,
> 	    UITableViewRowAnimationMiddle,
> 	    UITableViewRowAnimationAutomatic = 100
> 	}
>
> So if you're doing direct bindings where you don't want to change the names, how do you use that in D?
>
> 	UITableViewRowAnimation.UITableViewRowAnimationFade

Precisely.
See dmd's source code, enum STC {STCscope, STCforeach, ...}, enum MOD {MODconst, MODshared,...}, etc.

On 2012-01-26 12:51, Trass3r wrote:
>> You can use anonymous enums. The members will then live in the global
>> scope. You can then use just one alias to an int, uint or what's
>> appropriate.
>
> Yeah but you loose type safety.

It's not type safe in C. But you can wrap it in a struct with alias this instead.

-- 
/Jacob Carlborg