• Trass3r (5/5) Jan 25 2012 When writing C bindings I usually create lots of aliases via a
• Jonathan M Davis (5/10) Jan 25 2012 Why? You're using them in D code, not C code. What difference does it ma...
• bcs (2/12) Jan 25 2012 Copy paste portability?
• Michel Fortin (20/30) Jan 26 2012 Often C enum value naming takes into account that they'll live in the
• Trass3r (3/18) Jan 26 2012 Precisely.
• Mike Parker (13/42) Jan 26 2012 alias int UITableViewRowAnimation;
• Daniel Murphy (31/43) Jan 26 2012 That works for interfacing c, but not c++.
• Andrej Mitrovic (6/7) Jan 28 2012 I don't think that's possible without passing the name of the enum.
• Andrej Mitrovic (4/5) Jan 28 2012 Nevermind, I was wrong. It appears typeid() returns a mangled name
• Andrej Mitrovic (19/19) Jan 28 2012 import std.conv;
• Daniel Murphy (4/8) Jan 28 2012 Are you sure? I thought it was the other way around, mixed-in members d...
• Andrej Mitrovic (5/13) Jan 28 2012 int foo, bar;
• Daniel Murphy (2/6) Jan 28 2012 Yes, but does target end up referenceing foo or bar?
• Trass3r (14/29) Jan 28 2012 The extra template is senseless.
• Andrej Mitrovic (15/17) Jan 28 2012 No it's not. Your sample won't compile with -property. That's why I've
• Trass3r (5/10) Jan 28 2012 I do have that constraint in some other version of the function in anoth...
• Andrej Mitrovic (3/6) Jan 28 2012 I don't use it either myself, but I believe someone mentioned it's
• Jonathan M Davis (8/16) Jan 28 2012 Yes. -property was introduced to give an opportunity for people to migra...
• Trass3r (3/6) Jan 28 2012 That's what I already do.
• Mike Wey (16/45) Jan 28 2012 I would probably use:
• Walter Bright (13/28) Jun 07 2014 enum UITableViewRowAnimation {
• deadalnix (26/56) Jun 07 2014 I'm not sure why it is usually done that way in D binding. This
• Jacob Carlborg (9/34) Jun 08 2014 In Swift you don't have to specify the full enum name if the compiler
• Walter Bright (2/8) Jun 08 2014 Does that apply to all symbols in Swift, or just enums?
• Jacob Carlborg (16/17) Jun 08 2014 I'm not sure if it applies to all symbols but it's not limited to enums....
• Walter Bright (6/13) Jun 08 2014 I see, so it is using the type of the lvalue to guide the symbol resolut...
• Jacob Carlborg (5/10) Jun 08 2014 I'm pretty sure Swift doesn't support function overloading. They use
• Walter Bright (2/13) Jun 08 2014 That use of with never occurred to me! It's cool.
• Jacob Carlborg (6/7) Jun 08 2014 It's very nice. I use it quite heavily in a project where I need to
• Mike Parker (3/17) Jun 09 2014 I saw it here in the NG some time ago and have been using it ever since....
• Jacob Carlborg (6/11) Jan 25 2012 You can use anonymous enums. The members will then live in the global
• Trass3r (1/4) Jan 26 2012 Yeah but you loose type safety.
• Michel Fortin (15/20) Jan 26 2012 Or if you absolutely need both type safety and the values to live in
• Trass3r (5/15) Jan 26 2012 As I said in the first post, this is what I actually do.
• Jacob Carlborg (5/9) Jan 26 2012 It's not type safe in C. But you can wrap it in a struct with alias this...
• Trass3r (1/3) Jan 26 2012 Yep, but in D we have strong enums, so why not use them.
• Jacob Carlborg (11/14) Jan 26 2012 What about be able to do something like this:
• Gor Gyolchanyan (7/24) Jan 26 2012 That would break the independence between parser and semantic
• Timon Gehr (2/28) Jan 26 2012
• Timon Gehr (4/17) Jan 26 2012 public is the wrong keyword. Furthermore, the solution is not better
• Trass3r (1/15) Jan 26 2012 +1
• Mike Parker (7/10) Jan 26 2012 If your binding is for yourself, that's not a big deal. But if you're
• Trass3r (1/5) Jan 26 2012 Yep, one big argument for my proposal.
• Meta (48/51) Jun 07 2014 Enums aren't as strongly typed as you would think (or as I would
• Trass3r (2/7) Jun 07 2014 Does anyone know how you would implement this in the compiler?

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

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

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?

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/

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

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

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

"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); ) 

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

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.

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

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

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

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

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!

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

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.

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.

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

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.

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

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

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

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

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?

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

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

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

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.

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

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.

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

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

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/

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

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

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

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

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.

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

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.

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

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.

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.

"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;
}

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