www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Accessing types by context

reply Hiemlick Hiemlicker <HH reign.com> writes:
Suppose one has void test(myEnum e)

enum myEnum
{
A,B,C
}

It would be very cool if we could do

test(A) instead of test(myEnum.A).

by context, the compiler can look first in the scope for 
something named A then look in the enum itself and prepend myEnum 
internally.


For flags, it would make it much easier to combine them:

test(A | B & C)

instead of

test(myEnum.A | myEnum.B & myEnum.C).

Similarly for comparisions of enums with objects:

if (object == A)

instead of

if (object == myEnum.A)

only if object is of type myEnum and A is not defined.

Seems logical? Is it possible in D to achieve something like this?

This could be extended to classes and structs but might create 
too much confusions.

For enums, I don't see any reason why it wouldn't work well.

Just a thought. Prefixing the same id to everything gets tiring 
after a while.
Jun 28 2016
next sibling parent reply Carl Vogel <carljv gmail.com> writes:
On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker 
wrote:
 Suppose one has void test(myEnum e)

 enum myEnum
 {
 A,B,C
 }

 [...]
Doesn't the with statement solve your problem here? with (myEnum) { test(A); test(B); test(C); }
Jun 28 2016
parent reply Hiemlick Hiemlicker <HH reign.com> writes:
On Wednesday, 29 June 2016 at 03:50:35 UTC, Carl Vogel wrote:
 On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker 
 wrote:
 Suppose one has void test(myEnum e)

 enum myEnum
 {
 A,B,C
 }

 [...]
Doesn't the with statement solve your problem here? with (myEnum) { test(A); test(B); test(C); }
Not really it's, only half the way there. Why not extend the language the extra step?
Jun 28 2016
parent Anonymouse <asdf asdf.net> writes:
On Wednesday, 29 June 2016 at 05:06:08 UTC, Hiemlick Hiemlicker 
wrote:
 On Wednesday, 29 June 2016 at 03:50:35 UTC, Carl Vogel wrote:
 On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick
[...]
 Doesn't the with statement solve your problem here?

 with (myEnum) {
     test(A);
     test(B);
     test(C);
 }
Not really it's, only half the way there. Why not extend the language the extra step?
I'm not sure I understand how it doesn't. Inside the with scope you could refer to myEnum members by their (unqualified) names alone. Isn't this the behaviour you're asking for? As a pet peeve of mine, it's unfortunate that with: cannot be used as attributes can, to last until the end of the current scope without adding a new one.
 void foo()
 {
     with(myEnum):  // doesn't work

     test(A);
     test(B);
     test(C);
 }
Jun 29 2016
prev sibling next sibling parent reply Chang Long <changlon gmail.com> writes:
On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker 
wrote:
 test(myEnum.A | myEnum.B & myEnum.C).
I like this: myEnum.( A | B & C) == myEnum.A | myEnum.B & myEnum.C
Jun 28 2016
parent Hiemlick Hiemlicker <HH reign.com> writes:
On Wednesday, 29 June 2016 at 04:34:26 UTC, Chang Long wrote:
 On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker 
 wrote:
 test(myEnum.A | myEnum.B & myEnum.C).
I like this: myEnum.( A | B & C) == myEnum.A | myEnum.B & myEnum.C
Does that even work? Regardless, You still have littered the code with the same context.
Jun 28 2016
prev sibling next sibling parent reply qznc <qznc web.de> writes:
On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker 
wrote:
 Suppose one has void test(myEnum e)

 enum myEnum
 {
 A,B,C
 }

 It would be very cool if we could do

 test(A) instead of test(myEnum.A).

 by context, the compiler can look first in the scope for 
 something named A then look in the enum itself and prepend 
 myEnum internally.
Can you expand on "then look in the enum itself"? Which enum? How to find the correct myEnum, if there is also myEnum2 and myEnum3? The problem with implicit lookups is that you might accidentally insert bugs when editing somewhere else. This is why D forbids shadowing variables in general. For example: class Foo { int x; void bar(int a) { baz(x); return a+1; } } Now imagine someone changed the variable "a" into "x". That would change the behavior of "baz(x)" although you did not change the line at all. I have the habit to always prepend this as in "this.x" from Python. It avoids such errors. Back to enums: If someone inserts another myEnum42 which also has A, the code might suddenly pick the wrong A. The other way round, if you delete myEnum, maybe it finds another A somewhere else. The with-statement makes this explicit and thus more reliable with respect to changes elsewhere.
Jun 29 2016
parent Lodovico Giaretta <lodovico giaretart.net> writes:
On Wednesday, 29 June 2016 at 10:51:39 UTC, qznc wrote:
 On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker 
 wrote:
 Suppose one has void test(myEnum e)

 enum myEnum
 {
 A,B,C
 }

 It would be very cool if we could do

 test(A) instead of test(myEnum.A).

 by context, the compiler can look first in the scope for 
 something named A then look in the enum itself and prepend 
 myEnum internally.
Can you expand on "then look in the enum itself"? Which enum? How to find the correct myEnum, if there is also myEnum2 and myEnum3?
I think he means that function 'test' is declared with a parameter of type 'myEnum', so the only two scopes to look up are the current one and the correct enum 'myEnum', because other enums won't match the function parameter type. If there are two overloads of 'test', with different enums that share a member name, the compiler complains about ambiguity. But maybe this is difficult to accomplish in the compiler, and not worth the advantage.
 The problem with implicit lookups is that you might 
 accidentally insert bugs when editing somewhere else. This is 
 why D forbids shadowing variables in general. For example:
With the behaviour I wrote above, there would be no way to insert bugs; the worst thing would be the compiler rejecting the line as wrong, even if you didn't touch it.
 class Foo {
   int x;
   void bar(int a) {
     baz(x);
     return a+1;
   }
 }

 Now imagine someone changed the variable "a" into "x". That 
 would change the behavior of "baz(x)" although you did not 
 change the line at all. I have the habit to always prepend this 
 as in "this.x" from Python. It avoids such errors.

 Back to enums: If someone inserts another myEnum42 which also 
 has A, the code might suddenly pick the wrong A. The other way 
 round, if you delete myEnum, maybe it finds another A somewhere 
 else. The with-statement makes this explicit and thus more 
 reliable with respect to changes elsewhere.
It wouldn't be ambiguous (as I said above). Nonetheless, I'm not a huge fan of this extension request.
Jun 29 2016
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 29/06/16 05:11, Hiemlick Hiemlicker wrote:
 Suppose one has void test(myEnum e)

 enum myEnum
 {
 A,B,C
 }

 It would be very cool if we could do

 test(A) instead of test(myEnum.A).

 by context, the compiler can look first in the scope for something named
 A then look in the enum itself and prepend myEnum internally.
Swift has this feature (the enum member needs to be prefix with a dot). This has been brought up before and Walter doesn't like it. It will complicate the language, especially function overloading: enum Foo { A } enum Bar { A } void foo(Foo); void foo(Bar); foo(A); // ambiguity -- /Jacob Carlborg
Jun 29 2016