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

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.

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

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?

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

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

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.

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

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?

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.