www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - enum scope

reply "Trass3r" <un known.com> writes:
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?
Jan 25 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 25 2012
next sibling parent bcs <bcs example.com> writes:
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?
Jan 25 2012
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Jan 26 2012
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 1/26/2012 8:55 PM, Michel Fortin wrote:
 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

enum { UITableViewRowAnimationFade, UITableViewRowAnimationRight, UITableViewRowAnimationLeft, UITableViewRowAnimationTop, UITableViewRowAnimationBottom, UITableViewRowAnimationNone, UITableViewRowAnimationMiddle, UITableViewRowAnimationAutomatic = 100 }
Jan 26 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
 alias int UITableViewRowAnimation;
 enum
 {
 UITableViewRowAnimationFade,
 UITableViewRowAnimationRight,
 UITableViewRowAnimationLeft,
 UITableViewRowAnimationTop,
 UITableViewRowAnimationBottom,
 UITableViewRowAnimationNone,
 UITableViewRowAnimationMiddle,
 UITableViewRowAnimationAutomatic = 100
 }

That works for interfacing c, but not c++. The following is a better solution, and should probably be in the standard library. enum UITableViewRowAnimation { UITableViewRowAnimationFade, UITableViewRowAnimationRight, UITableViewRowAnimationLeft, UITableViewRowAnimationTop, UITableViewRowAnimationBottom, UITableViewRowAnimationNone, UITableViewRowAnimationMiddle, UITableViewRowAnimationAutomatic = 100 } alias UITableViewRowAnimation.UITableViewRowAnimationFade UITableViewRowAnimationFade; alias UITableViewRowAnimation.UITableViewRowAnimationRight UITableViewRowAnimationRight; alias UITableViewRowAnimation.UITableViewRowAnimationLeft UITableViewRowAnimationLeft; alias UITableViewRowAnimation.UITableViewRowAnimationTop UITableViewRowAnimationTop; alias UITableViewRowAnimation.UITableViewRowAnimationBottom UITableViewRowAnimationBottom; alias UITableViewRowAnimation.UITableViewRowAnimationNo UITableViewRowAnimationNo; alias UITableViewRowAnimation.UITableViewRowAnimationMiddle UITableViewRowAnimationMiddle; alias UITableViewRowAnimation.UITableViewRowAnimationAutomatic UITableViewRowAnimationAutomatic; (could be mixin(exposeEnumMembers!UITableViewRowAnimation); )
Jan 26 2012
prev sibling next sibling parent Mike Wey <mike-wey example.com> writes:
On 01/26/2012 12:55 PM, Michel Fortin wrote:
 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

I would probably use: enum UITableViewRowAnimation { Fade, Right, Left, Top, Bottom, None, Middle, Automatic = 100 } Then you can use it like so: UITableViewRowAnimation.Fade -- Mike Wey
Jan 28 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2012 3:55 AM, Michel Fortin wrote:
 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,

Enums are not part of the C ABI.
 how do you use that in D?

      UITableViewRowAnimation.UITableViewRowAnimationFade

enum UITableViewRowAnimation { Fade, Right, Left, Top, Bottom, None, Middle, Automatic = 100 } ITableViewRowAnimation.Fade
Jun 07 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-06-08 01:58, deadalnix wrote:

 I'm not sure why it is usually done that way in D binding. This is
 idiotic (and all Deimos exhibit this).

 enum UITableViewRowAnimation {
      Fade,
      Right,
      Left,
      Top,
      Bottom,
      None,
      Middle,
      Automatic = 100
 }

 Here you go. You gain type safety (well kind of) and you don't need to
 increase verbosity. You can even use the with statement for code that
 use the enum intensively, for instance :

 final switch(myvar) with(UITableViewRowAnimation) {
      case Fade:
         // Do fading...
      case Right:
         // That's right...
      case Left:
         // That's not right..
      // And so on...
 }

 That is superior to the idiotic C copy pasta in all aspects.

In Swift you don't have to specify the full enum name if the compiler can infer that it's an value of specific enum that is needed: void foo (UITableViewRowAnimation); foo(Fade); Actually in Swift you would append a dot to the enum value: foo(.Fade); -- /Jacob Carlborg
Jun 08 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/8/2014 2:15 AM, Jacob Carlborg wrote:
 In Swift you don't have to specify the full enum name if the compiler can infer
 that it's an value of specific enum that is needed:

 void foo (UITableViewRowAnimation);

 foo(Fade);

 Actually in Swift you would append a dot to the enum value:

 foo(.Fade);

Does that apply to all symbols in Swift, or just enums?
Jun 08 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-06-08 19:50, Walter Bright wrote:

 Does that apply to all symbols in Swift, or just enums?

I'm not sure if it applies to all symbols but it's not limited to enums. The reference documentation [1] says: "An implicit member expression is an abbreviated way to access a member of a type, such as an enumeration case or a class method, in a context where type inference can determine the implied type. It has the following form: .member name For example: var x = MyEnumeration.SomeValue x = .AnotherValue " [1] https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Expressions.html#//apple_ref/swift/grammar/implicit-member-expression -- /Jacob Carlborg
Jun 08 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/8/2014 12:11 PM, Jacob Carlborg wrote:
 "An implicit member expression is an abbreviated way to access a member of a
 type, such as an enumeration case or a class method, in a context where type
 inference can determine the implied type. It has the following form:

      .member name

 For example:

      var x = MyEnumeration.SomeValue
      x = .AnotherValue

I see, so it is using the type of the lvalue to guide the symbol resolution of the rvalue. Andrei had proposed something like this a few years ago, but I talked him out of it :-) (I felt it would play havoc with overload resolution.)
Jun 08 2014
parent Jacob Carlborg <doob me.com> writes:
On 08/06/14 21:53, Walter Bright wrote:

 I see, so it is using the type of the lvalue to guide the symbol
 resolution of the rvalue.

 Andrei had proposed something like this a few years ago, but I talked
 him out of it :-)

 (I felt it would play havoc with overload resolution.)

I'm pretty sure Swift doesn't support function overloading. They use mandatory named parameters, like Objective-C instead. -- /Jacob Carlborg
Jun 08 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/7/2014 4:58 PM, deadalnix wrote:
 You can even use the with statement for code that use the enum
 intensively, for instance :

 final switch(myvar) with(UITableViewRowAnimation) {
      case Fade:
         // Do fading...
      case Right:
         // That's right...
      case Left:
         // That's not right..
      // And so on...
 }

That use of with never occurred to me! It's cool.
Jun 08 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-06-08 19:51, Walter Bright wrote:

 That use of with never occurred to me! It's cool.

It's very nice. I use it quite heavily in a project where I need to access enum members often. It's mostly useful when you need to access many enum members in the same scope. -- /Jacob Carlborg
Jun 08 2014
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On 6/9/2014 2:51 AM, Walter Bright wrote:
 On 6/7/2014 4:58 PM, deadalnix wrote:
 You can even use the with statement for code that use the enum
 intensively, for instance :

 final switch(myvar) with(UITableViewRowAnimation) {
      case Fade:
         // Do fading...
      case Right:
         // That's right...
      case Left:
         // That's not right..
      // And so on...
 }

That use of with never occurred to me! It's cool.

I saw it here in the NG some time ago and have been using it ever since. Love this one.
Jun 09 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 25 2012
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
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/
Jan 26 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 26 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-26 14:23, Trass3r wrote:
 It's not type safe in C. But you can wrap it in a struct with alias
 this instead.

Yep, but in D we have strong enums, so why not use them.

What about be able to do something like this: enum Foo { public: bar, fooBar, } Foo f = bar; -- /Jacob Carlborg
Jan 26 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/26/2012 07:21 PM, Gor Gyolchanyan wrote:
 That would break the independence between parser and semantic
 analyzer, because there's no way to disambiguate "bar" from "Foo.bar"
 without knowing, that "Foo" is actually an enum.

No, it would not. The parser does not have to care.
 On Thu, Jan 26, 2012 at 5:41 PM, Jacob Carlborg<doob me.com>  wrote:
 On 2012-01-26 14:23, Trass3r wrote:
 It's not type safe in C. But you can wrap it in a struct with alias
 this instead.

Yep, but in D we have strong enums, so why not use them.

What about be able to do something like this: enum Foo { public: bar, fooBar, } Foo f = bar; -- /Jacob Carlborg


Jan 26 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/26/2012 02:41 PM, Jacob Carlborg wrote:
 On 2012-01-26 14:23, Trass3r wrote:
 It's not type safe in C. But you can wrap it in a struct with alias
 this instead.

Yep, but in D we have strong enums, so why not use them.

What about be able to do something like this: enum Foo { public: bar, fooBar, } Foo f = bar;

public is the wrong keyword. Furthermore, the solution is not better than mixin Import!Foo; I think the extern(C) enum proposal is pragmatic and makes more sense.
Jan 26 2012
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On 1/26/2012 10:23 PM, Trass3r wrote:
 It's not type safe in C. But you can wrap it in a struct with alias
 this instead.

Yep, but in D we have strong enums, so why not use them.

If your binding is for yourself, that's not a big deal. But if you're putting it out there for public consumption, then I think compatibility with the C version would be more important. If someone is looking at sample C code, you should make it they don't need to adjust it much at all. In some cases, this is unavoidable (bit fields, macros), but where it *is* avoidable, it should be.
Jan 26 2012
prev sibling next sibling parent "Trass3r" <un known.com> writes:
 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.
Jan 26 2012
prev sibling next sibling parent "Trass3r" <un known.com> writes:
 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.
Jan 26 2012
prev sibling next sibling parent "Trass3r" <un known.com> writes:
 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.
Jan 26 2012
prev sibling next sibling parent "Trass3r" <un known.com> writes:
 It's not type safe in C. But you can wrap it in a struct with 
 alias this instead.

Yep, but in D we have strong enums, so why not use them.
Jan 26 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
That would break the independence between parser and semantic
analyzer, because there's no way to disambiguate "bar" from "Foo.bar"
without knowing, that "Foo" is actually an enum.

On Thu, Jan 26, 2012 at 5:41 PM, Jacob Carlborg <doob me.com> wrote:
 On 2012-01-26 14:23, Trass3r wrote:
 It's not type safe in C. But you can wrap it in a struct with alias
 this instead.

Yep, but in D we have strong enums, so why not use them.

What about be able to do something like this: enum Foo { public: =C2=A0 =C2=A0bar, =C2=A0 =C2=A0fooBar, } Foo f =3D bar; -- /Jacob Carlborg

--=20 Bye, Gor Gyolchanyan.
Jan 26 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 If your binding is for yourself, that's not a big deal. But if you're  
 putting it out there for public consumption, then I think compatibility  
 with the C version would be more important. If someone is looking at  
 sample C code, you should make it they don't need to adjust it much

Yep, one big argument for my proposal.
Jan 26 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 What about be able to do something like this:

 enum Foo
 {
 public:
 bar,
 fooBar,
 }

 Foo f = bar;

public is the wrong keyword. Furthermore, the solution is not better than mixin Import!Foo; I think the extern(C) enum proposal is pragmatic and makes more sense.

+1
Jan 26 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/27/12, Daniel Murphy <yebblies nospamgmail.com> wrote:
 (could be mixin(exposeEnumMembers!UITableViewRowAnimation); )

I don't think that's possible without passing the name of the enum. Once you pass the type to the "expose" template it won't know the enum is named "UITableViewRowAnimation". You /could/ use typeid() to get the mangled name and try to demangle that, but lo' and behold core.demangle doesn't work at compile-time. :/
Jan 28 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/28/12, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 I don't think that's possible without passing the name of the enum.

Nevermind, I was wrong. It appears typeid() returns a mangled name only when used in a *pragma* call, otherwise you do get the proper name.
Jan 28 2012
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
import std.conv;
import std.traits;

string exposeEnumMembersImpl(T)()
{
    string result;
    foreach (member; EnumMembers!UITableViewRowAnimation)
        result ~= "alias " ~ to!string(T.stringof) ~ "." ~
to!string(member) ~ " " ~ to!string(member) ~ ";\n";
    return result;
}

template exposeEnumMembers(T)
{
    enum exposeEnumMembers = exposeEnumMembersImpl!T();
}

mixin( exposeEnumMembers!UITableViewRowAnimation );

I did notice something about mixins, they hide existing aliases. If
you already had those aliases listed and you added this mixin, the
newly mixed in aliases will not conflict with the old ones. I find
this behavior rather odd, even if it's defined this way..
Jan 28 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.101.1327757271.25230.digitalmars-d puremagic.com...
 I did notice something about mixins, they hide existing aliases. If
 you already had those aliases listed and you added this mixin, the
 newly mixed in aliases will not conflict with the old ones. I find
 this behavior rather odd, even if it's defined this way..

Are you sure? I thought it was the other way around, mixed-in members did not override existing ones...
Jan 28 2012
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/28/12, Daniel Murphy <yebblies nospamgmail.com> wrote:
 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 news:mailman.101.1327757271.25230.digitalmars-d puremagic.com...
 I did notice something about mixins, they hide existing aliases. If
 you already had those aliases listed and you added this mixin, the
 newly mixed in aliases will not conflict with the old ones. I find
 this behavior rather odd, even if it's defined this way..

Are you sure? I thought it was the other way around, mixed-in members did not override existing ones...

int foo, bar; alias foo target; alias bar target; // error mixin("alias bar target;"); // but use this instead and no problem..
Jan 28 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 int foo, bar;
 alias foo target;
 alias bar target;  // error
 mixin("alias bar target;");  // but use this instead and no problem..

Yes, but does target end up referenceing foo or bar?
Jan 28 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 import std.conv;
 import std.traits;

 string exposeEnumMembersImpl(T)()
 {
     string result;
     foreach (member; EnumMembers!UITableViewRowAnimation)
         result ~= "alias " ~ to!string(T.stringof) ~ "." ~
 to!string(member) ~ " " ~ to!string(member) ~ ";\n";
     return result;
 }

 template exposeEnumMembers(T)
 {
     enum exposeEnumMembers = exposeEnumMembersImpl!T();
 }

 mixin( exposeEnumMembers!UITableViewRowAnimation );

The extra template is senseless. And no imports are needed. string bringToCurrentScope(alias EnumType)() { string res = ""; foreach (e; __traits(allMembers, EnumType)) { res ~= "alias " ~ EnumType.stringof ~ "." ~ e ~ " " ~ e ~ ";\n"; } return res; } mixin(bringToCurrentScope!EnumName); Anyway the whole point of this thread is to get rid of a crappy mixin(blabla); after each enum I define!
Jan 28 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 The following is a better solution, and should probably be in the  
 standard library.

 (could be mixin(exposeEnumMembers!UITableViewRowAnimation); )

That's what I already do. The whole point of the thread is to get rid of that crap after each enum.
Jan 28 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/28/12, Trass3r <un known.com> wrote:
 The extra template is senseless.

No it's not. Your sample won't compile with -property. That's why I've wrapped it into a template, to avoid having to use parens.
 And no imports are needed.

Fair enough. But if we're going to be anal about it you should add a constraint `if (is(EnumType == enum))`. Otherwise your sample will compile for non-enum types, which may or may not be what you want. You probably don't want to end up with static method imported into the local scope by accident. For classes it will generate: alias MyClass.toString toString; alias MyClass.toHash toHash; alias MyClass.opCmp opCmp; alias MyClass.opEquals opEquals; alias MyClass.Monitor Monitor; alias MyClass.factory factory; Fun! :)
Jan 28 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 No it's not. Your sample won't compile with -property. That's why I've
 wrapped it into a template, to avoid having to use parens.

Never used -property. I don't mind adding parentheses either.
 Fair enough. But if we're going to be anal about it you should add a
 constraint `if (is(EnumType == enum))`. Otherwise your sample will
 compile for non-enum types

I do have that constraint in some other version of the function in another project. So it's an old one.
Jan 28 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/28/12, Trass3r <un known.com> wrote:
 No it's not. Your sample won't compile with -property. That's why I've
 wrapped it into a template, to avoid having to use parens.

Never used -property.

I don't use it either myself, but I believe someone mentioned it's going to become the default one day.
Jan 28 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 28, 2012 23:10:01 Andrej Mitrovic wrote:
 On 1/28/12, Trass3r <un known.com> wrote:
 No it's not. Your sample won't compile with -property. That's why I've
 wrapped it into a template, to avoid having to use parens.

Never used -property.

I don't use it either myself, but I believe someone mentioned it's going to become the default one day.

Yes. -property was introduced to give an opportunity for people to migrate to property enforcement and to give the compiler a chance to iron out any bugs that it may have with regards to property enforcement. But property is supposed to be enforced. It only isn't because we're still in a period of migration from when property didn't exist and you could call any no-argument (or single-argument function when using assignment) with or without parens. - Jonathan M Davis
Jan 28 2012
prev sibling next sibling parent "Trass3r" <un known.com> writes:
On Thursday, 26 January 2012 at 01:06:46 UTC, 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?

Does anyone know how you would implement this in the compiler?
Jun 07 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Thursday, 26 January 2012 at 13:23:43 UTC, Trass3r wrote:
 It's not type safe in C. But you can wrap it in a struct with 
 alias this instead.

Yep, but in D we have strong enums, so why not use them.

Enums aren't as strongly typed as you would think (or as I would like). The major problem is that it's incredibly easy to get an invalid enum value, even without using a cast. enum Foo { one = 1, two, three, } enum Bar { first, second, third, } void takesFoo(Foo foo) { } void main() { int n = Foo.one; assert(n == 1); //Luckily, this doesn't compile //Foo foo1 = n; int[] arr = new int[](3); int m = arr[Foo.two]; //Unfortunately, this DOES compile Foo foo2 = Foo.one - Foo.two; assert(foo2 == -1); takesFoo(foo2); //Fails (thank goodness) //takesFoo(Bar.third); //This actually isn't as bad as it looks. //The result is of type int and thus //can't be assigned back to a Foo or Bar assert(Foo.two - Bar.third == 0); //Fails //Foo foo3 = Foo.two - Bar.second; //Fails //Bar bar = Bar.first - Foo.three; }
Jun 07 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 26 January 2012 at 11:55:00 UTC, Michel Fortin wrote:
 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

I'm not sure why it is usually done that way in D binding. This is idiotic (and all Deimos exhibit this). enum UITableViewRowAnimation { Fade, Right, Left, Top, Bottom, None, Middle, Automatic = 100 } Here you go. You gain type safety (well kind of) and you don't need to increase verbosity. You can even use the with statement for code that use the enum intensively, for instance : final switch(myvar) with(UITableViewRowAnimation) { case Fade: // Do fading... case Right: // That's right... case Left: // That's not right.. // And so on... } That is superior to the idiotic C copy pasta in all aspects.
Jun 07 2014