digitalmars.D - Accessing types by context
- Hiemlick Hiemlicker (25/25) Jun 28 2016 Suppose one has void test(myEnum e)
- Carl Vogel (8/14) Jun 28 2016 Doesn't the with statement solve your problem here?
- Hiemlick Hiemlicker (3/19) Jun 28 2016 Not really it's, only half the way there. Why not extend the
- Anonymouse (9/27) Jun 29 2016 [...]
- Chang Long (4/5) Jun 28 2016 I like this:
- Hiemlick Hiemlicker (3/8) Jun 28 2016 Does that even work? Regardless, You still have littered the code
- qznc (23/33) Jun 29 2016 Can you expand on "then look in the enum itself"? Which enum? How
- Lodovico Giaretta (15/53) Jun 29 2016 I think he means that function 'test' is declared with a
- Jacob Carlborg (11/20) Jun 29 2016 Swift has this feature (the enum member needs to be prefix with a dot).
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
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
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:Not really it's, only half the way there. Why not extend the language the extra step?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
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, HiemlickI'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.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?void foo() { with(myEnum): // doesn't work test(A); test(B); test(C); }
Jun 29 2016
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
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:Does that even work? Regardless, You still have littered the code with the same context.test(myEnum.A | myEnum.B & myEnum.C).I like this: myEnum.( A | B & C) == myEnum.A | myEnum.B & myEnum.C
Jun 28 2016
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
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: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.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: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
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