Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 06:41:04 UTC, zjh wrote: On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: .. Is it okay to use a new keyword `enumswitch` that is equivalent to `with final switch`? Why would you use a new keyword? Use `enum switch` with a space. Both are keywords already.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Friday, 12 May 2023 at 03:11:49 UTC, ryuukk_ wrote:
On Thursday, 11 May 2023 at 23:00:03 UTC, epilogue wrote:
On Thursday, 11 May 2023 at 00:56:03 UTC, ryuukk_ wrote:
Don't you find this code easier to read and review?
```D
if (target.os == .Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == .linux)
item("linux");
else if (target.os == .OSX)
item("osx");
else if (target.os == .FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == .OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == .Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
No, I find this harder to review.
`.` is the module scope operator, which is already going to be
difficult for new dlang coders to learn about given that they
would end up searching for the meaning of the `.` character (I
speak from *my* experience learning D).
I haven't reviewed the DIP in full, but a quick search of the
DIP for "module scope operator" does indicate that overloading
the module scope operator was already called out as
undesirable, so I'm not sure why you would use `.` again here
when trying to defend the rejected DIP.
Having read the conversation, but not the DIP, I think the
repetition issue is known, but the examples offered don't
demonstrate (to me, a random nobody reading this thread) a
clear improvement of the language or the code in question.
I will add that this particular case of repetition the DIP
seems to be intended to solve reminds me of brace-expansion in
bash, where `foo.iso{,.sig}` expands to `foo.iso foo.iso.sig`
allowing bashers to avoid repetition in some cases of
repetitive strings, but it should be evident to anyone
subjected to reading someone else's bash script that that
reducing repetition with brace expansion does not
unconditionally improve reviewability of the code in question.
The syntax doesn't matter, i could have used # or :, what ever,
let's focus on the idea first
It's am improvement to me, hence why i advocate for it, i'm not
a compiler developper, i can't think of everything, all i can
think of is it's going to improve the way i write my code
All it took me to appreciate it was to discover it when i was
using a language that happen to support it, as simple as that,
i'm not good at english, not even at programming, but i can
appreciate things makes me write nice code
```D
switch (action.type)
{
case .Attack: do_attack(); break;
case .Jump: do_jump(); break;
}
```
this is simple and readable, if i can't convice you, then there
is nothing i can do
Steve Jobs came up with the iPhone when everyone was saying
"touching your screen with your fingers is a stupid idea", and
look at us now..
All it takes is to try it
that switch could be further improved with pattern matching, but
that's a discussion for a different DIP
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 11 May 2023 at 23:00:03 UTC, epilogue wrote:
On Thursday, 11 May 2023 at 00:56:03 UTC, ryuukk_ wrote:
Don't you find this code easier to read and review?
```D
if (target.os == .Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == .linux)
item("linux");
else if (target.os == .OSX)
item("osx");
else if (target.os == .FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == .OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == .Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
No, I find this harder to review.
`.` is the module scope operator, which is already going to be
difficult for new dlang coders to learn about given that they
would end up searching for the meaning of the `.` character (I
speak from *my* experience learning D).
I haven't reviewed the DIP in full, but a quick search of the
DIP for "module scope operator" does indicate that overloading
the module scope operator was already called out as
undesirable, so I'm not sure why you would use `.` again here
when trying to defend the rejected DIP.
Having read the conversation, but not the DIP, I think the
repetition issue is known, but the examples offered don't
demonstrate (to me, a random nobody reading this thread) a
clear improvement of the language or the code in question.
I will add that this particular case of repetition the DIP
seems to be intended to solve reminds me of brace-expansion in
bash, where `foo.iso{,.sig}` expands to `foo.iso foo.iso.sig`
allowing bashers to avoid repetition in some cases of
repetitive strings, but it should be evident to anyone
subjected to reading someone else's bash script that that
reducing repetition with brace expansion does not
unconditionally improve reviewability of the code in question.
The syntax doesn't matter, i could have used # or :, what ever,
let's focus on the idea first
It's am improvement to me, hence why i advocate for it, i'm not a
compiler developper, i can't think of everything, all i can think
of is it's going to improve the way i write my code
All it took me to appreciate it was to discover it when i was
using a language that happen to support it, as simple as that,
i'm not good at english, not even at programming, but i can
appreciate things makes me write nice code
```D
switch (action.type)
{
case .Attack: do_attack(); break;
case .Jump: do_jump(); break;
}
```
this is simple and readable, if i can't convice you, then there
is nothing i can do
Steve Jobs came up with the iPhone when everyone was saying
"touching your screen with your fingers is a stupid idea", and
look at us now..
All it takes is to try it
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 11 May 2023 at 00:56:03 UTC, ryuukk_ wrote:
Don't you find this code easier to read and review?
```D
if (target.os == .Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == .linux)
item("linux");
else if (target.os == .OSX)
item("osx");
else if (target.os == .FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == .OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == .Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
No, I find this harder to review.
`.` is the module scope operator, which is already going to be
difficult for new dlang coders to learn about given that they
would end up searching for the meaning of the `.` character (I
speak from *my* experience learning D).
I haven't reviewed the DIP in full, but a quick search of the DIP
for "module scope operator" does indicate that overloading the
module scope operator was already called out as undesirable, so
I'm not sure why you would use `.` again here when trying to
defend the rejected DIP.
Having read the conversation, but not the DIP, I think the
repetition issue is known, but the examples offered don't
demonstrate (to me, a random nobody reading this thread) a clear
improvement of the language or the code in question.
I will add that this particular case of repetition the DIP seems
to be intended to solve reminds me of brace-expansion in bash,
where `foo.iso{,.sig}` expands to `foo.iso foo.iso.sig` allowing
bashers to avoid repetition in some cases of repetitive strings,
but it should be evident to anyone subjected to reading someone
else's bash script that that reducing repetition with brace
expansion does not unconditionally improve reviewability of the
code in question.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On 5/11/23 10:10 AM, Paul Backus wrote: On Thursday, 11 May 2023 at 13:31:58 UTC, Steven Schveighoffer wrote: On 5/10/23 11:22 PM, Paul Backus wrote: In fact, for this particular example, there are actually two enums in the DMD source code that these symbols could be coming from: `enum TargetOS` in `cli.d`, and `enum OS` in `target.d`. So you would have to scroll up and look at the imports to disambiguate. Then you misunderstand the DIP (as did Walter). There is only one enum that can be involved -- typeof(target.os). Oh no, I'm perfectly aware that, from the compiler's perspective, it would be unambiguous--only one of the two enums would actually be in scope. Scope has nothing to do with it. The wrong enum might be the only one in scope, and it will still use the correct one. Both enums might be in scope, and it still uses the correct one. But as a human reader, in order to figure out which one, I'd have to scroll to the top of the file and read through ~25 lines of imports (or rely on tooling, but there are contexts where that isn't available, like a Github code review). It's no different than: ```d if(target.os == target.os.Solaris) ``` It's not very hard to understand, nor harder to figure out. What type is `target.os`? It's an enum from that type. -Steve
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 11 May 2023 at 13:31:58 UTC, Steven Schveighoffer wrote: On 5/10/23 11:22 PM, Paul Backus wrote: In fact, for this particular example, there are actually two enums in the DMD source code that these symbols could be coming from: `enum TargetOS` in `cli.d`, and `enum OS` in `target.d`. So you would have to scroll up and look at the imports to disambiguate. Then you misunderstand the DIP (as did Walter). There is only one enum that can be involved -- typeof(target.os). Oh no, I'm perfectly aware that, from the compiler's perspective, it would be unambiguous--only one of the two enums would actually be in scope. But as a human reader, in order to figure out which one, I'd have to scroll to the top of the file and read through ~25 lines of imports (or rely on tooling, but there are contexts where that isn't available, like a Github code review).
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On 5/10/23 11:22 PM, Paul Backus wrote: In fact, for this particular example, there are actually two enums in the DMD source code that these symbols could be coming from: `enum TargetOS` in `cli.d`, and `enum OS` in `target.d`. So you would have to scroll up and look at the imports to disambiguate. Then you misunderstand the DIP (as did Walter). There is only one enum that can be involved -- typeof(target.os). -Steve
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 11 May 2023 at 00:56:03 UTC, ryuukk_ wrote:
Don't you find this code easier to read and review?
```D
if (target.os == .Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == .linux)
item("linux");
else if (target.os == .OSX)
item("osx");
else if (target.os == .FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == .OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == .Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
Honestly, not really. I've never looked at this part of DMD, and
without context, I'd have no idea where the symbols `Windows`,
`linux`, `FreeBSD`, and so on were coming from. Having it
explicitly spelled out at the usage site--either via qualified
names (`Target.OS.Windows`) or a local alias (`alias TOS =
Target.OS`) makes it trivial to understand what's being referred
to.
In fact, for this particular example, there are actually two
enums in the DMD source code that these symbols could be coming
from: `enum TargetOS` in `cli.d`, and `enum OS` in `target.d`. So
you would have to scroll up and look at the imports to
disambiguate.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
I was reading DMD source code, case of repetition that adds
nothing of value but useless reading strain
https://github.com/dlang/dmd/blob/999d835c1196eb993a99bb7f1c863da265a6b6c0/compiler/src/dmd/json.d#L843-L869
```D
if (target.os == Target.OS.Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == Target.OS.linux)
item("linux");
else if (target.os == Target.OS.OSX)
item("osx");
else if (target.os == Target.OS.FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == Target.OS.OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == Target.OS.Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
what could be done to avoid the repetition?
Reduce the length of the repetition with a short alias?
```D
alias TOS = Target.OS;
if (target.os == TOS.Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == TOS.linux)
item("linux");
else if (target.os == TOS.OSX)
item("osx");
else if (target.os == TOS.FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == TOS.OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == TOS.Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
Well, repetition is still there, now you got a short Type to type
that doesn't mean anything without context, why is it needed? why
do we need that noise? what problem does it solve?
We can use ``with()``? but why do i need a with here? target.os
is self explanatory already, it's supposed to be type safe, it's
a type safe enumeration, i should only care about the values, why
now introduce an extra scope with extra indentation? it'd create
more noise and now visual strain
Don't you find this code easier to read and review?
```D
if (target.os == .Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == .linux)
item("linux");
else if (target.os == .OSX)
item("osx");
else if (target.os == .FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == .OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == .Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Monday, 1 May 2023 at 14:03:51 UTC, bachmeier wrote: On Monday, 1 May 2023 at 00:34:03 UTC, ryuukk_ wrote: I don't think it's a misconception. It's more like a complete lack of clarity. the goal is not to use an anonymous enum, the goal is to leverage the robust type system to avoid repeting yourself, wich is bad ``` Value value; value.type = ValueType.STRING; ``` vs ``` Value value; value.type = .STRING; ``` This is another case of the "complete lack of clarity" I wrote about in my earlier comment. With an anonymous enum you could write ``` value.type = STRING; ``` Maybe you have something deeper in mind, but that example does not make a case for changing the language. Rather than shouting, you should put together a better example. I will let this conversation die. I don't think it's going to resolve anything (and I'm not the one that needs convincing anyway). Ok.. so you _refuse_ to understand (as opposed to not understanding, wich in that case you'd only have to listen and learn) You didn't read my previous comment, so let me copy/paste it: the goal is not to use an anonymous enum, the goal is to leverage the robust type system to avoid repeting yourself, wich is bad And to make sure i'm being understood, the goal is not to make code less verbose, quite the opposite, the goal is to encourage verbosity while avoiding useless repetitions, the two are not compatible Are you familiar with this popular quote? "democracy dies in darkness"? It goes the same way with discussing feature suggestions and language impromvents, don't "let this conversation die", convince me, argument, don't just try to silence me, that won't work
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Monday, 1 May 2023 at 14:03:51 UTC, bachmeier wrote: ``` value.type = STRING; ``` IRL people would use namespacing prefixes or actual namespaces anyway, so your example would look more like ``` value.type = VALUE_TYPE_STRING; ```
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Monday, 1 May 2023 at 00:34:03 UTC, ryuukk_ wrote: I don't think it's a misconception. It's more like a complete lack of clarity. the goal is not to use an anonymous enum, the goal is to leverage the robust type system to avoid repeting yourself, wich is bad ``` Value value; value.type = ValueType.STRING; ``` vs ``` Value value; value.type = .STRING; ``` This is another case of the "complete lack of clarity" I wrote about in my earlier comment. With an anonymous enum you could write ``` value.type = STRING; ``` Maybe you have something deeper in mind, but that example does not make a case for changing the language. Rather than shouting, you should put together a better example. I will let this conversation die. I don't think it's going to resolve anything (and I'm not the one that needs convincing anyway).
Re: DIP1044---"Enum Type Inference"---Formal Assessment
Do you write this? ``` float myfloat = float(1.0); ``` Or this? ``` float myfloat = 1.0; ``` Why would it be different for enums (or any other type) Also i suggest you to try all kind of languages to expand your knowledge and to try out new UX that modern languages provide, there is no reason to refuse to understand other people's opinion only because you thought the existing rule is immutable because you can't give a critical opinion on it
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 13:03:17 UTC, bachmeier wrote:
On Thursday, 27 April 2023 at 06:10:57 UTC, Basile B. wrote:
On Thursday, 27 April 2023 at 00:16:10 UTC, Walter Bright
wrote:
This also works:
alias F = MySuperLongNameFlag;
auto flag = F.A | F.B | F.C | F.D;
set_flags(F.A | F.B | F.C | F.D);
It's similar to setting a local variable to some complex
expression, just so you don't have to repeat that expression
multiple times.
It's a misconception of the problem that the DIP tried to
solve. What the DIP tried to solve is that the compiler should
know that you are using an enum member. Actually I even think
this should work without any special syntax, as a "last
resort", let's say. But as you've explained, through Mike's
report, this causes problems for D because the identifier
resolution is tied to a particular implementation, i.e your
fast symtabs.
I don't think it's a misconception. It's more like a complete
lack of clarity. What would be the point of complexifying the
language for the new programmer when you can just use an
anonymous enum? This program runs just fine:
```
import std.stdio;
enum {
A1,
B1,
C1,
D1
}
enum {
_A,
_B,
_C,
_D
}
void main() {
writeln(A1);
writeln(_A);
writeln(A1 == _A);
auto flag = _B;
switch(flag) {
case _A:
writeln("_A");
break;
case _B:
writeln("_B");
break;
case _C:
writeln("_C");
break;
case _D:
writeln("_D");
break;
default:
break;
}
}
```
What's the point in using a named enum if you want an anonymous
enum? The response when this question was asked was not
"because [something where it matters]". It was instead to
ignore the question, give an unrealistic example that was
solved by the response, and insert a bunch of unhelpful
hostility.
what's the point? if you read the discussion that happened for
the DIP you wouldn't ask the question
the goal is not to use an anonymous enum, the goal is to leverage
the robust type system to avoid repeting yourself, wich is bad
```
Value value;
value.type = ValueType.STRING;
```
vs
```
Value value;
value.type = .STRING;
```
Read your code, would you read a book where each sentence would
be a repetition of the previous one?
"Billy went to the town to buy some beer, as he arrived to the
town to buy some beer he met Richard, as he arrived to the town
to buy some beer Richard, that he just met, asked him how his
wife was doing"
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 06:10:57 UTC, Basile B. wrote:
It's a misconception of the problem that the DIP tried to
solve. What the DIP tried to solve is that the compiler should
know that you are using an enum member. Actually I even think
this should work without any special syntax, as a "last
resort", let's say. But as you've explained, through Mike's
report, this causes problems for D because the identifier
resolution is tied to a particular implementation, i.e your
fast symtabs.
I don't think it's a misconception. It's more like a complete
lack of clarity. What would be the point of complexifying the
language for the new programmer when you can just use an
anonymous enum? This program runs just fine:
```
import std.stdio;
enum {
A1,
B1,
C1,
D1
}
enum {
_A,
_B,
_C,
_D
}
void main() {
writeln(A1);
writeln(_A);
writeln(A1 == _A);
auto flag = _B;
switch(flag) {
case _A:
writeln("_A");
break;
case _B:
writeln("_B");
break;
case _C:
writeln("_C");
break;
case _D:
writeln("_D");
break;
default:
break;
}
}
```
What's the point in using a named enum if you want an anonymous
enum? The response when this question was asked was not "because
[something where it matters]". It was instead to ignore the
question, give an unrealistic example that was solved by the
response, and insert a bunch of unhelpful hostility.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 06:10:57 UTC, Basile B. wrote:
On Thursday, 27 April 2023 at 00:16:10 UTC, Walter Bright wrote:
This also works:
alias F = MySuperLongNameFlag;
auto flag = F.A | F.B | F.C | F.D;
set_flags(F.A | F.B | F.C | F.D);
It's similar to setting a local variable to some complex
expression, just so you don't have to repeat that expression
multiple times.
It's a misconception of the problem that the DIP tried to
solve. What the DIP tried to solve is that the compiler should
know that you are using an enum member. Actually I even think
this should work without any special syntax, as a "last
resort", let's say. But as you've explained, through Mike's
report, this causes problems for D because the identifier
resolution is tied to a particular implementation, i.e your
fast symtabs.
I don't think it's a misconception. It's more like a complete
lack of clarity. What would be the point of complexifying the
language for the new programmer when you can just use an
anonymous enum? This program runs just fine:
```
import std.stdio;
enum {
A1,
B1,
C1,
D1
}
enum {
_A,
_B,
_C,
_D
}
void main() {
writeln(A1);
writeln(_A);
writeln(A1 == _A);
auto flag = _B;
switch(flag) {
case _A:
writeln("_A");
break;
case _B:
writeln("_B");
break;
case _C:
writeln("_C");
break;
case _D:
writeln("_D");
break;
default:
break;
}
}
```
What's the point in using a named enum if you want an anonymous
enum? The response when this question was asked was not "because
[something where it matters]". It was instead to ignore the
question, give an unrealistic example that was solved by the
response, and insert a bunch of unhelpful hostility.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 00:16:10 UTC, Walter Bright wrote: This also works: alias F = MySuperLongNameFlag; auto flag = F.A | F.B | F.C | F.D; set_flags(F.A | F.B | F.C | F.D); It's similar to setting a local variable to some complex expression, just so you don't have to repeat that expression multiple times. It's a misconception of the problem that the DIP tried to solve. What the DIP tried to solve is that the compiler should know that you are using an enum member. Actually I even think this should work without any special syntax, as a "last resort", let's say. But as you've explained, through Mike's report, this causes problems for D because the identifier resolution is tied to a particular implementation, i.e your fast symtabs.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
This also works: alias F = MySuperLongNameFlag; auto flag = F.A | F.B | F.C | F.D; set_flags(F.A | F.B | F.C | F.D); It's similar to setting a local variable to some complex expression, just so you don't have to repeat that expression multiple times.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 14:54:40 UTC, max haughton wrote: https://github.com/dlang/dmd/pull/13776 Wow, didn't know about this PR exists. Thank you for sharing!
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On 4/26/2023 1:19 AM, Stefan Koch wrote: While it is true that it only implements a subset of the proposal. It does implemnent function overloading for non-templated functions the specific code for this is here: https://github.com/dlang/dmd/pull/14650/files#diff-fdd319cc59bac2d5ef6bc04f806fd564a3549e1cce44c7d01b4ec9e40792e3daR7172-R7190 Thanks for the correction!
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 15:07:36 UTC, ryuukk_ wrote: Again, all of this was covered and argumented during the DIP discussion The goal is to improve the language, not find excuses or workarounds, don't defend obfuscation, move forward Your proposals were built on unrealistic examples and false dichotomies. If the only choice is 48-character informative names or two-character uninformative names, the problem is not the language.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 13:08:22 UTC, Jacob Shtokolov wrote: On Wednesday, 26 April 2023 at 12:50:32 UTC, bachmeier wrote: Many other solutions were provided as well, including but not limited to - Using shorter names - Using alias - Using an IDE with autocomplete - Using copy and paste While aliases and shorter names are always good options, autocomplete and copy/paste really aren't as the end user of the code is either yourself or another developer, so reading the mess produced with copy/paste makes life much more miserable :) Unless you're using incredibly long names (which is not a reason to change the language) I find the explicit approach to be more readable. If I have to parse the code and do inference, it's a lot more work, and in some cases, more error-prone. We've had proposals to drop the semicolon requirement. I would hate that. It's easier to read code when I don't have to figure out where the lines end. I wish the `with()` operator would also be an expression, so you could do something like: ```d auto f = with(Flags) A | B | C |D; ``` This would be great, but it goes against the spirit of this DIP, since you have to explicitly type out `with(Flags)`.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 12:50:32 UTC, bachmeier wrote:
On Wednesday, 26 April 2023 at 11:52:31 UTC, Jacob Shtokolov
wrote:
On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote:
void set_connected()
{
network_connect_state = NetworkConnectState.CONNECTED
}
MySuperLongNameFlag flag = MySuperLongNameFlag.A |
MySuperLongNameFlag.B | MySuperLongNameFlag.C |
MySuperLongNameFlag.D;
set_flags(MySuperLongNameFlag.A | MySuperLongNameFlag.B |
MySuperLongNameFlag.C | MySuperLongNameFlag.D)
Okay, I understand this is sometimes really annoying, but in
this example, why can't you just:
Many other solutions were provided as well, including but not
limited to
- Using shorter names
Why make your code harder to read ?
```
// just use short name, duh
enum CState
{
CON, DC, WT
}
void on_con()
{
st = CState.CON;
}
// no, let me take advantage of the robust type system
enum NetworkConnectionState
{
CONNECTED, DISCONNECTED, WAITING
}
void on_connecte()
{
network_state = .CONNECTED;
}
```
- Using alias
Now you have multiple symbols doing the same thing, that's a
maintenance downgrade, "refactor? ohhh i forgot to refactor the
multiple aliases"
- Using an IDE with autocomplete
Now i need an IDE to code, nice
- Using copy and paste
Now introduce duplicates that are hard to manage during
refactors, wich copy pasta is the right one?
Again, all of this was covered and argumented during the DIP
discussion
The goal is to improve the language, not find excuses or
workarounds, don't defend obfuscation, move forward
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 10:48:21 UTC, Greggor wrote: On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. [...] I’m going to contribute to the peanut gallery, and say I support the rejection of the dip and the reasoning given is solid. I do like the suggestion of `with final switch` and I also like the even shorter `enumswitch` as a new keyword, it would be a nice bit of syntactic sugar. Regardless of this dip being added or not, I'm not going to be dramatic about it, its not the end of the world or of D :^) That's not contribution ``with final switch`` what kind of Java is that? or is it D? i'm getting lost for a moment, not sure!
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 11:52:31 UTC, Jacob Shtokolov
wrote:
On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote:
void set_connected()
{
network_connect_state = NetworkConnectState.CONNECTED
}
MySuperLongNameFlag flag = MySuperLongNameFlag.A |
MySuperLongNameFlag.B | MySuperLongNameFlag.C |
MySuperLongNameFlag.D;
set_flags(MySuperLongNameFlag.A | MySuperLongNameFlag.B |
MySuperLongNameFlag.C | MySuperLongNameFlag.D)
Okay, I understand this is sometimes really annoying, but in
this example, why can't you just:
```d
import std.stdio;
enum MySuperLongNameFlag : int
{
A = 0b0001,
B = 0b0010,
C = 0b0100,
D = 0b1000,
}
void set_flags(MySuperLongNameFlag f) {}
void main()
{
with (MySuperLongNameFlag)
{
auto flag = A | B | C | D;
set_flags(A | B | C | D);
writefln("%04b", flag);
}
}
```
No, what about this:
```d
import std.stdio;
enum MySuperLongNameFlag : int
{
A = 0b0001,
B = 0b0010,
C = 0b0100,
D = 0b1000,
}
void set_flags(MySuperLongNameFlag f) {}
void main()
{
MySuperLongNameFlag flag = A | B | C | D;
set_flags(A | B | C | D);
writefln("%04b", flag);
}
```
No bloat, no extra indentation, no auto, you know what you are
using
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 13:08:22 UTC, Jacob Shtokolov wrote: On Wednesday, 26 April 2023 at 12:50:32 UTC, bachmeier wrote: Many other solutions were provided as well, including but not limited to - Using shorter names - Using alias - Using an IDE with autocomplete - Using copy and paste While aliases and shorter names are always good options, autocomplete and copy/paste really aren't as the end user of the code is either yourself or another developer, so reading the mess produced with copy/paste makes life much more miserable :) I wish the `with()` operator would also be an expression, so you could do something like: ```d auto f = with(Flags) A | B | C |D; ``` But that breaks backwards compatibility ¯\_(ツ)_/¯ https://github.com/dlang/dmd/pull/13776
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. [...] While I was rather "pro" I think that D lacked an absolute necessity for that. As explained earlier on IRC, enum type inference is also very intersting when the language has a bitfield type based on an enum, like the `Set Of` pascal construct, which makes enum member something really commonly used, much more than in D.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 12:50:32 UTC, bachmeier wrote: Many other solutions were provided as well, including but not limited to - Using shorter names - Using alias - Using an IDE with autocomplete - Using copy and paste While aliases and shorter names are always good options, autocomplete and copy/paste really aren't as the end user of the code is either yourself or another developer, so reading the mess produced with copy/paste makes life much more miserable :) I wish the `with()` operator would also be an expression, so you could do something like: ```d auto f = with(Flags) A | B | C |D; ``` But that breaks backwards compatibility ¯\_(ツ)_/¯
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. This was the right decision, but it would have been nice to include as one of the reasons that it would have made it harder for new users.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 11:52:31 UTC, Jacob Shtokolov
wrote:
On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote:
void set_connected()
{
network_connect_state = NetworkConnectState.CONNECTED
}
MySuperLongNameFlag flag = MySuperLongNameFlag.A |
MySuperLongNameFlag.B | MySuperLongNameFlag.C |
MySuperLongNameFlag.D;
set_flags(MySuperLongNameFlag.A | MySuperLongNameFlag.B |
MySuperLongNameFlag.C | MySuperLongNameFlag.D)
Okay, I understand this is sometimes really annoying, but in
this example, why can't you just:
Many other solutions were provided as well, including but not
limited to
- Using shorter names
- Using alias
- Using an IDE with autocomplete
- Using copy and paste
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote:
void set_connected()
{
network_connect_state = NetworkConnectState.CONNECTED
}
MySuperLongNameFlag flag = MySuperLongNameFlag.A |
MySuperLongNameFlag.B | MySuperLongNameFlag.C |
MySuperLongNameFlag.D;
set_flags(MySuperLongNameFlag.A | MySuperLongNameFlag.B |
MySuperLongNameFlag.C | MySuperLongNameFlag.D)
Okay, I understand this is sometimes really annoying, but in this
example, why can't you just:
```d
import std.stdio;
enum MySuperLongNameFlag : int
{
A = 0b0001,
B = 0b0010,
C = 0b0100,
D = 0b1000,
}
void set_flags(MySuperLongNameFlag f) {}
void main()
{
with (MySuperLongNameFlag)
{
auto flag = A | B | C | D;
set_flags(A | B | C | D);
writefln("%04b", flag);
}
}
```
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. [...] I’m going to contribute to the peanut gallery, and say I support the rejection of the dip and the reasoning given is solid. I do like the suggestion of `with final switch` and I also like the even shorter `enumswitch` as a new keyword, it would be a nice bit of syntactic sugar. Regardless of this dip being added or not, I'm not going to be dramatic about it, its not the end of the world or of D :^)
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 01:39:14 UTC, Walter Bright wrote:
That only does a subset of the proposal. The inference only
works in specific cases. Things like function overloading are
not addressed.
Should we remove struct initializers as well?
```D
struct S { int x; }
void fun(S) {}
fun({42}); // Error
```
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 01:39:14 UTC, Walter Bright wrote: On 4/25/2023 1:15 PM, ryuukk_ wrote: Or perhaps, listen to this person: https://github.com/dlang/dmd/pull/14650 That only does a subset of the proposal. The inference only works in specific cases. Things like function overloading are not addressed. While it is true that it only implements a subset of the proposal. It does implemnent function overloading for non-templated functions the specific code for this is here: https://github.com/dlang/dmd/pull/14650/files#diff-fdd319cc59bac2d5ef6bc04f806fd564a3549e1cce44c7d01b4ec9e40792e3daR7172-R7190
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 01:39:14 UTC, Walter Bright wrote: On 4/25/2023 1:15 PM, ryuukk_ wrote: Or perhaps, listen to this person: https://github.com/dlang/dmd/pull/14650 That only does a subset of the proposal. The inference only works in specific cases. Things like function overloading are not addressed. Where were you when we discussed about it? https://forum.dlang.org/post/clkvzkxobrcqcelzw...@forum.dlang.org Nowhere to be seen For projects to move forward, discussion must happen Hiding in the back with a knife mean you waste everyone's time People who spending time thinking about the feature, writing the DIP, discussing about it, implementing the PR, arguing with people, doing the effort to argument etc etc Anyways, this is your project, you choose how it goes, it goes both ways tho, i choose what i use
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 01:26:03 UTC, Walter Bright wrote:
On 4/25/2023 4:12 PM, max haughton wrote:
I have never been in favour of D having bitfields. This isn't
worth breaking stuff for.
D bitfields didn't break anything. Also, it exposed an
overlooked bug in the ImportC bitfields.
I forgot to add a paragraph ("this" was meant to refer to the
enum changes), but any change to the grammar can break formatters
and autocomplete engines and so on - good formatters shouldn't
use an AST so bitfields in particular might have been OK but the
point stands in general.
At the moment ldc currently doesn't have bitfields so D basically
doesn't have them as a serious feature.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On 4/25/2023 1:15 PM, ryuukk_ wrote: Or perhaps, listen to this person: https://github.com/dlang/dmd/pull/14650 That only does a subset of the proposal. The inference only works in specific cases. Things like function overloading are not addressed.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On 4/25/2023 4:12 PM, max haughton wrote: I have never been in favour of D having bitfields. This isn't worth breaking stuff for. D bitfields didn't break anything. Also, it exposed an overlooked bug in the ImportC bitfields.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 22:39:35 UTC, ryuukk_ wrote: On Tuesday, 25 April 2023 at 20:59:23 UTC, max haughton wrote: On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote: On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote: [...] Why you guys focus on "switch" Because that's the example given by Mike... Who doesn't love writing other than Walter Bright: [...] Who are you saying said it's too hard to implement? Also consider that *any* change breaks all the tooling. It's in the 2nd paragraph But not my paragraph? Oh, now you care about the tooling? I was the only one who raised awareness about the new features landing but tooling was ignored all while i was getting ignored (importC // dub) (bitfields // dcd), how funny I have never been in favour of D having bitfields. This isn't worth breaking stuff for. You also aren't the only one... ImportC will save everything, i now understand You're either writing past me or ascribing ideas to me that I haven't said. It may be of note that I don't work for DLF anymore
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 20:59:23 UTC, max haughton wrote: On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote: On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote: [...] Why you guys focus on "switch" Because that's the example given by Mike... Who doesn't love writing other than Walter Bright: [...] Who are you saying said it's too hard to implement? Also consider that *any* change breaks all the tooling. It's in the 2nd paragraph Oh, now you care about the tooling? I was the only one who raised awareness about the new features landing but tooling was ignored all while i was getting ignored (importC // dub) (bitfields // dcd), how funny Same for the debugging issue, i got ignored Same for the TLS issue, i got ignored I has the wrong expectations it seems, you also seems to have the wrong expectation on your users ImportC will save everything, i now understand
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote: On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote: [...] Why you guys focus on "switch" Because that's the example given by Mike... Who doesn't love writing other than Walter Bright: [...] Who are you saying said it's too hard to implement? Also consider that *any* change breaks all the tooling.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote:
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:
Firstly I think this is the correct decision, certainly for
now, probably forever.
Regarding enums in switch statements, Walter suggested we
could shorten the `with final switch` syntax such that the
`with` is implicitly applied to the type of the switch
variable:
```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```
Alternatively, we could make the `with` implicit for case
statements, but that would break existing code.
What we have at the moment with `with` is, I think perfectly
fine.
The `switch(...) with(...)` pattern is used rather a lot in the
SDC codebase
for example and I think it's very readable.
On the topic of `with` I do think, and have even implemented
;), with expressions do need to happen eventually. The with
statement is a little heavy handed for places where these kinds
of shorthands are needed locally.
Why you guys focus on "switch"
Who doesn't love writing other than Walter Bright:
```
void set_connected()
{
network_connect_state = NetworkConnectState.CONNECTED
}
MySuperLongNameFlag flag = MySuperLongNameFlag.A |
MySuperLongNameFlag.B | MySuperLongNameFlag.C |
MySuperLongNameFlag.D;
set_flags(MySuperLongNameFlag.A | MySuperLongNameFlag.B |
MySuperLongNameFlag.C | MySuperLongNameFlag.D)
```
Too hard to implement? oh really? then i suggest trying other
languages and reading their source code, so you can learn new
techniques and improve your project
Or perhaps, listen to this person:
https://github.com/dlang/dmd/pull/14650
He seem talented, he did what you find "too hard" to implement
Being stuck is a good thing if you work, if you don't work, and
you are stuck, then perhaps is time to reflect on the time spent
working on being stuck?
I still can't debug my program btw
https://forum.dlang.org/thread/mhqywnoqhoirtruyk...@forum.dlang.org
So i now understand better, things aren't "hard to implement",
things are frozen in time, and no will to improve anything, the
motto is go template yourself! (sumtype)
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. [snip] I didn't follow this too closely last year, but I don't see a lot wrong with the "implicit with" approach (or at least I'm not sure how wrong it would be, I would lean toward adding it to a preview switch and see if it broke anything). The DIP proponents would argued against that approach seem to just be saying that the DIP is more powerful than that. Sure, that may be true, but this is also a situation where they probably shouldn't let perfect be the enemy of good. I'd rather "implicit with" than using strings and mixins to hack together the same effect for function argument lists.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:
Firstly I think this is the correct decision, certainly for now,
probably forever.
Regarding enums in switch statements, Walter suggested we could
shorten the `with final switch` syntax such that the `with` is
implicitly applied to the type of the switch variable:
```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```
Alternatively, we could make the `with` implicit for case
statements, but that would break existing code.
What we have at the moment with `with` is, I think perfectly fine.
The `switch(...) with(...)` pattern is used rather a lot in the
SDC codebase
for example and I think it's very readable.
On the topic of `with` I do think, and have even implemented ;),
with expressions do need to happen eventually. The with statement
is a little heavy handed for places where these kinds of
shorthands are needed locally.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. IMO this is the correct decision. While a feature like this would be nice to have, it's not of critical importance, so we can afford to have high standards for the quality of the proposal. During the review process, there was some discussion in the community Discord about generalizing this idea, of literals with "holes" that the compiler can fill in, to other types of data beyond just enums. Perhaps it could even be unified with pattern matching--e.g., you could use a pattern as a literal outside of a `switch` or `match` statement, and the compiler would attempt to fill it in based on the context. I can't say with confidence that such a proposal would be accepted (the concerns about top-down vs bottom-up inference still apply), but I personally would be excited to see one.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:
I submitted DIP1044, "Enum Type Inference", to Walter and Atila
on April 1. I received the final decision from them on April
18. They have decided not to accept this proposal.
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1044.md
The said the proposal was well done and an interesting read,
but found it to be too complex for insufficient benefit. They
provided the following list of concerns that led them to their
decision:
* Given that D already has `with`, `alias`, and `auto`, it does
not seem worthwhile to add a special case for enums.
* Semantic analysis in D is strictly bottom-up. This proposal
would add top-up type inference on top of that. This presents
problems in handling function and template overloads, as well
as variadic parameter lists.
* The proposal only allows ETI in some contexts. This is
potentially confusing for the programmer, particularly in the
presence of mixin templates (which draw symbols from the
instantiation context) and function overloads.
* Symbol tables can get very large. Lookups are done via hash
table for max speed, but this will not work for ETI. There may
be a very large number of "enums in scope", and each one will
have to be searched to resolve a member.
* ETI is similar to ADL (Argument Dependent Lookup) in C++.
Walter implemented ADL in the Digital Mars C++ compiler and is
strongly against allowing anything like it in D. He finds it
slow and complex, and few people really know how it's going to
work.
Regarding enums in switch statements, Walter suggested we could
shorten the `with final switch` syntax such that the `with` is
implicitly applied to the type of the switch variable:
```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```
Alternatively, we could make the `with` implicit for case
statements, but that would break existing code.
I'm a little glad for reading and reviewing code that this didn't
get through, at least without IDE, but I think this would have
been quite a useful feature for writing code.
However I think we probably should still implement this in DCD /
have better auto-suggest according to the rules here. I think it
will be similarly useful having better auto-complete suggestion
contexts compared to having new syntax in the language. (maybe
being able to trigger it explicitly using $ at the start, but
definitely want to have these suggestions being prioritized)
Re: DIP1044---"Enum Type Inference"---Formal Assessment
This is not good news :-|
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. That DIP sure became a bikeshed at the last review. Good effort from you and Aya to revise and submit it regardless. Note though, the links to the community review currently point to ProtoObject DIP review.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 06:41:04 UTC, zjh wrote: Is it okay to use a new keyword `enumswitch` that is equivalent to `with final switch`? If there were an `official restriction` that could simplify `long keywords`, that would be great,like: ```d alias keyword enumswitch=with final switch; ``` Multiple `keywords/@property` can also be simplified (`pure/@ nogc/@ safe/public/...`), but it is best to only allow `official simplification`, otherwise it will mess up the grammar.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: .. Is it okay to use a new keyword `enumswitch` that is equivalent to `with final switch`?
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:
I submitted DIP1044, "Enum Type Inference", to Walter and Atila
on April 1. I received the final decision from them on April
18. They have decided not to accept this proposal.
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1044.md
The said the proposal was well done and an interesting read,
but found it to be too complex for insufficient benefit. They
provided the following list of concerns that led them to their
decision:
* Given that D already has `with`, `alias`, and `auto`, it does
not seem worthwhile to add a special case for enums.
* Semantic analysis in D is strictly bottom-up. This proposal
would add top-up type inference on top of that. This presents
problems in handling function and template overloads, as well
as variadic parameter lists.
* The proposal only allows ETI in some contexts. This is
potentially confusing for the programmer, particularly in the
presence of mixin templates (which draw symbols from the
instantiation context) and function overloads.
* Symbol tables can get very large. Lookups are done via hash
table for max speed, but this will not work for ETI. There may
be a very large number of "enums in scope", and each one will
have to be searched to resolve a member.
* ETI is similar to ADL (Argument Dependent Lookup) in C++.
Walter implemented ADL in the Digital Mars C++ compiler and is
strongly against allowing anything like it in D. He finds it
slow and complex, and few people really know how it's going to
work.
Regarding enums in switch statements, Walter suggested we could
shorten the `with final switch` syntax such that the `with` is
implicitly applied to the type of the switch variable:
```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```
Alternatively, we could make the `with` implicit for case
statements, but that would break existing code.
Welp, time for me to find a new language then, that's
unfortunate..
DIP1044---"Enum Type Inference"---Formal Assessment
I submitted DIP1044, "Enum Type Inference", to Walter and Atila
on April 1. I received the final decision from them on April 18.
They have decided not to accept this proposal.
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1044.md
The said the proposal was well done and an interesting read, but
found it to be too complex for insufficient benefit. They
provided the following list of concerns that led them to their
decision:
* Given that D already has `with`, `alias`, and `auto`, it does
not seem worthwhile to add a special case for enums.
* Semantic analysis in D is strictly bottom-up. This proposal
would add top-up type inference on top of that. This presents
problems in handling function and template overloads, as well as
variadic parameter lists.
* The proposal only allows ETI in some contexts. This is
potentially confusing for the programmer, particularly in the
presence of mixin templates (which draw symbols from the
instantiation context) and function overloads.
* Symbol tables can get very large. Lookups are done via hash
table for max speed, but this will not work for ETI. There may be
a very large number of "enums in scope", and each one will have
to be searched to resolve a member.
* ETI is similar to ADL (Argument Dependent Lookup) in C++.
Walter implemented ADL in the Digital Mars C++ compiler and is
strongly against allowing anything like it in D. He finds it slow
and complex, and few people really know how it's going to work.
Regarding enums in switch statements, Walter suggested we could
shorten the `with final switch` syntax such that the `with` is
implicitly applied to the type of the switch variable:
```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```
Alternatively, we could make the `with` implicit for case
statements, but that would break existing code.
