Re: enum scope
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.
Re: enum scope
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
Re: enum scope
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.)
Re: enum scope
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
Re: enum scope
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
Re: enum scope
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.
Re: enum scope
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?
Re: enum scope
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
Re: enum scope
On Thursday, 26 January 2012 at 11:55:00 UTC, Michel Fortin wrote:
On 2012-01-26 01:12:40 +, Jonathan M Davis
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.
Re: enum scope
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
Re: enum scope
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;
}
Re: enum scope
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?
Re: enum scope
On Saturday, January 28, 2012 23:10:01 Andrej Mitrovic wrote: > On 1/28/12, Trass3r 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
Re: enum scope
On 1/28/12, Trass3r 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.
Re: enum scope
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.
Re: enum scope
On 1/28/12, Trass3r 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! :)
Re: enum scope
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.
Re: enum scope
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!
Re: enum scope
"Andrej Mitrovic" 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?
Re: enum scope
On 1/28/12, Daniel Murphy wrote:
> "Andrej Mitrovic" wrote in message
> news:mailman.101.1327757271.25230.digitalmar...@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..
Re: enum scope
"Andrej Mitrovic" wrote in message news:mailman.101.1327757271.25230.digitalmar...@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...
Re: enum scope
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..
Re: enum scope
On 1/28/12, Andrej Mitrovic 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.
Re: enum scope
On 1/27/12, Daniel Murphy 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. :/
Re: enum scope
On 01/26/2012 12:55 PM, Michel Fortin wrote:
On 2012-01-26 01:12:40 +, Jonathan M Davis 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
Re: enum scope
> 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); )
Re: enum scope
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
Re: enum scope
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.
Re: enum scope
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 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
Re: enum scope
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.
Re: enum scope
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 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
--
Bye,
Gor Gyolchanyan.
Re: enum scope
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.
Re: enum scope
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
Re: enum scope
On 1/26/2012 8:55 PM, Michel Fortin wrote:
On 2012-01-26 01:12:40 +, Jonathan M Davis 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
}
Re: enum scope
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.
Re: enum scope
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
Re: enum scope
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.
Re: enum scope
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.
Re: enum scope
On 2012-01-26 11:51:10 +, "Trass3r" 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.for...@michelf.com
http://michelf.com/
Re: enum scope
On 2012-01-26 01:12:40 +, Jonathan M Davis 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.for...@michelf.com
http://michelf.com/
Re: enum scope
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.
Re: enum scope
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
Re: enum scope
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?
Re: enum scope
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
