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
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 Sw
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 exampl
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
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
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
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);
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. Yo
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 sc
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,
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
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
Le 29/09/2012 14:04, Bernard Helyer a écrit :
Yeah, to respond to the larger topic, the with statement
is more than enough here. I'm not convinced that complicating
lookup rules further is worth it.
Well, they are not complicated, they are mostly undefined.
On Saturday, 29 September 2012 at 23:49:47 UTC, Tommi wrote:
It is quite a mess. I think I'm ready to admit that this is not
a feature we'd like to have in this language (probably not in
any language for that matter).
Using "with" should do the trick just fine for the few situations
where the
Although it's not very obvious what is a "hot-spot" and what is
not.
enum Char { a, b, c, d }
Char a = c; // OK: 'c' is in a "hot-spot"
Char b = c + 1; // ERROR: 'c' is undefined, because it's not in
// a "hot-spot" and therefore Char enumerations
// aren't visi
On Saturday, 29 September 2012 at 02:57:42 UTC, David Piepgrass
wrote:
I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you
don't need to explicitly specify the scope of the enum value.
This would reduce redun
Scratch my previous post. It had a weird rule where the types of
identifiers had a say in whether or not there's ambiguity in the
name lookup. That's just silly. It should always be an ambiguity
error if the names are identical.
This new rule is easier to conceptualize too. Basically you just
On 9/29/12 2:44 PM, Tommi wrote:
But, if we were allowed to make a breaking change
I stopped reading here :o).
Andrei
But, if we were allowed to make a breaking change, then this is
how I think it should work:
// in a module scope...
enum E { foo, bar };
-
// These cause a compile error "foo is ambiguous":
1) E foo = E.bar;
2) E foo = E.foo;
3) enum
On Saturday, 29 September 2012 at 07:04:19 UTC, kenji hara wrote:
After a while, you may add a global variable in module scope.
enum E { foo ,bar }
int foo = 10;
void test(E e) {}
void main() {
test(foo); // foo is defined, and look up module scope foo.
// Then, now the code is
On 29/09/2012 04:11, Andrej Mitrovic wrote:
On 9/29/12, David Piepgrass wrote:
I like the spirit of this feature, but as Alex pointed out,
ambiguity is possible (which could theoretically cause errors in
existing code)
It could also cause subtle problems because enum values are implicitly
con
On Saturday, 29 September 2012 at 05:47:59 UTC, Bernard Helyer
wrote:
Except a theoretical feature doesn't exist, so someone has
to write the code. So no, it's not an 'unacceptable
argument'.
I'll explain my way of seeing this in the form we all understand:
code.
bool tryImplement(Feature x
Yeah, to respond to the larger topic, the with statement
is more than enough here. I'm not convinced that complicating
lookup rules further is worth it.
On 29 September 2012 04:12, Andrej Mitrovic wrote:
> On 9/29/12, Jonathan M Davis wrote:
>> you could simply use with to solve the problem:
>>
>> with(MyFruit)
>> {
>> switch(fruit)
>> {
>> case apple: break;
>> case orange: break;
>> case banana: break;
>> }
>
2012/9/29 Tommi :
> On Saturday, 29 September 2012 at 04:26:01 UTC, Alex Rønne Petersen wrote:
>>
>>
>> It's an awful lot of magic (it's not as easy in the implementation as it
>> sounds like) for questionable gain when we have the with statement IMO.
>
>
> "it's not as easy in the implementation a
On Saturday, 29 September 2012 at 05:08:12 UTC, Tommi wrote:
then that's completely an unacceptable argument. The question
of how much work it is to implement, has nothing to do with
whether it's a good feature to have or not. And that's what
we're discussing.
Except a theoretical feature doe
On Saturday, 29 September 2012 at 04:26:01 UTC, Alex Rønne
Petersen wrote:
It's an awful lot of magic (it's not as easy in the
implementation as it sounds like) for questionable gain when we
have the with statement IMO.
"it's not as easy in the implementation as it sounds like"
-
On 29-09-2012 06:06, Tommi wrote:
So, these would be the new rules we'd give to the compiler:
1) See if you can compile the code exactly the way you've been doing it
thus far. If it compiles, great, we're done.
2) Else, if there are undefined identifiers that are passed to places
where named en
On Saturday, 29 September 2012 at 02:57:42 UTC, David Piepgrass
wrote:
Plus, I don't like the fact that when you see something like
"MyIterator!forward" by itself in code, there is no obvious
clue that forward is an enum value and not a class name or a
variable.
I might also add, that once
So, these would be the new rules we'd give to the compiler:
1) See if you can compile the code exactly the way you've been
doing it thus far. If it compiles, great, we're done.
2) Else, if there are undefined identifiers that are passed to
places where named enum variables are expected, try t
On Saturday, 29 September 2012 at 02:57:42 UTC, David Piepgrass
wrote:
Plus, I don't like the fact that when you see something like
"MyIterator!forward" by itself in code, there is no obvious
clue that forward is an enum value and not a class name or a
variable. So there is a sort of decrease
On Saturday, 29 September 2012 at 02:37:40 UTC, Alex Rønne
Petersen wrote:
Regardless of the conditions under which to throw an error, it
would be a breaking change.
I guess that's a bad thing. Hmmm... too bad.
Well... maybe we could make it so that variables of the requested
enum type are
On 9/29/12, Jonathan M Davis wrote:
> you could simply use with to solve the problem:
>
> with(MyFruit)
> {
> switch(fruit)
> {
> case apple: break;
> case orange: break;
> case banana: break;
> }
> }
>
It's even simpler:
switch(fruit) with (MyFruit)
{
case
On 9/29/12, David Piepgrass wrote:
> I like the spirit of this feature, but as Alex pointed out,
> ambiguity is possible (which could theoretically cause errors in
> existing code)
It could also cause subtle problems because enum values are implicitly
convertible to the enum's base type. Take thi
On Saturday, September 29, 2012 03:55:48 Tommi wrote:
> enum MyFruit { apple, orange, banana }
>
> MyFruit fruit;
>
> switch (fruit)
> {
> case apple: break; // Case expressions know what type to
> case orange: break; // expect based on the switch expression
> case banana: break;
I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you
don't need to explicitly specify the scope of the enum value.
This would reduce redundancy in typing, just like automatic
type inference does.
Examples:
On 29-09-2012 04:31, Tommi wrote:
On Saturday, 29 September 2012 at 02:01:15 UTC, Alex Rønne Petersen wrote:
The first issue with this proposal that comes to mind is this:
enum Foo { bar }
void func(Foo f)
{
// ...
}
// ...
Foo bar = Foo.bar;
func(bar); // ?
Maybe it should simply thro
On Saturday, 29 September 2012 at 02:01:15 UTC, Alex Rønne
Petersen wrote:
The first issue with this proposal that comes to mind is this:
enum Foo { bar }
void func(Foo f)
{
// ...
}
// ...
Foo bar = Foo.bar;
func(bar); // ?
Maybe it should simply throw a compile error about the ambigui
On 29-09-2012 03:55, Tommi wrote:
I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you don't
need to explicitly specify the scope of the enum value. This would
reduce redundancy in typing, just like automatic type
I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you
don't need to explicitly specify the scope of the enum value.
This would reduce redundancy in typing, just like automatic type
inference does.
Examples:
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, b
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.
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 == e
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
const
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.
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 expos
"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?
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 a
"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 on
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 expose
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.
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()
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
> alias int UITableViewRowAnimation;
> enum
> {
> UITableViewRowAnimationFade,
> UITableViewRowAnimationRight,
> UITableViewRowAnimationLeft,
> UITableViewRowAnimationTop,
> UITableViewRowAnimationBottom,
> UITableViewRowAnimationNone,
> UITableViewRowAnimationMiddle,
> UITableViewRowAnimationAutom
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
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
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
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,
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 s
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,
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 Carl
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
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.
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
ins
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.Som
Often C enum value naming takes into account that they'll live
in the outer scope. For instance:
enum UITableViewRowAnimation {
UITableViewRowAnimationFade,
UITableViewRowAnimationRight,
UITableViewRowAnimationLeft,
UITableViewRowAnimationTop,
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 liv
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
You can use anonymous enums. The members will then live in the
global scope. You can then use just one alias to an int, uint
or what's appropriate.
Yeah but you loose type safety.
On 2012-01-26 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
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 au
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? Yo
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?
73 matches
Mail list logo
