www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DIP1044---"Enum Type Inference"---Formal Assessment

reply Mike Parker <aldacron gmail.com> writes:
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.
Apr 24 2023
next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
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..
Apr 24 2023
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
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`?
Apr 24 2023
next sibling parent zjh <fqbqrr 163.com> writes:
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.
Apr 24 2023
prev sibling parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
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.
May 12 2023
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
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.
Apr 25 2023
prev sibling next sibling parent Doigt <labog outlook.com> writes:
This is not good news :-|
Apr 25 2023
prev sibling next sibling parent WebFreak001 <d.forum webfreak.org> writes:
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)
Apr 25 2023
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
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.
Apr 25 2023
prev sibling next sibling parent reply max haughton <maxhaton gmail.com> writes:
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.
Apr 25 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
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/mhqywnoqhoirtruykaqo 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)
Apr 25 2023
next sibling parent reply max haughton <maxhaton gmail.com> writes:
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.
Apr 25 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
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
Apr 25 2023
parent reply max haughton <maxhaton gmail.com> writes:
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
Apr 25 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 25 2023
parent max haughton <maxhaton gmail.com> writes:
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.
Apr 25 2023
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 25 2023
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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
Apr 26 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
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!
Apr 26 2023
prev sibling parent Ogi <ogion.art gmail.com> writes:
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
```
Apr 26 2023
prev sibling parent reply Jacob Shtokolov <jacob.100205 gmail.com> writes:
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);
     }
}

```
Apr 26 2023
next sibling parent reply bachmeier <no spam.net> writes:
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
Apr 26 2023
next sibling parent reply Jacob Shtokolov <jacob.100205 gmail.com> writes:
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 ¯\_(ツ)_/¯
Apr 26 2023
next sibling parent reply max haughton <maxhaton gmail.com> writes:
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
Apr 26 2023
parent Jacob Shtokolov <jacob.100205 gmail.com> writes:
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!
Apr 26 2023
prev sibling parent bachmeier <no spam.net> writes:
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)`.
Apr 26 2023
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
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
Apr 26 2023
parent bachmeier <no spam.net> writes:
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.
Apr 26 2023
prev sibling next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
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
Apr 26 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 26 2023
parent reply Basile B. <b2.temp gmx.com> writes:
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.
Apr 26 2023
parent reply bachmeier <no spam.net> writes:
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.
Apr 27 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
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"
Apr 30 2023
next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
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
Apr 30 2023
prev sibling parent reply bachmeier <no spam.net> writes:
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).
May 01 2023
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
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;
```
May 01 2023
prev sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
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
May 01 2023
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
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.
Apr 25 2023
prev sibling next sibling parent reply Greggor <Greggor notareal.email> writes:
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 :^)
Apr 26 2023
parent ryuukk_ <ryuukk.dev gmail.com> writes:
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!
Apr 26 2023
prev sibling next sibling parent bachmeier <no spam.net> writes:
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.
Apr 26 2023
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
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.
Apr 26 2023
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
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();
```
May 10 2023
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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.
May 10 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
May 11 2023
parent reply Paul Backus <snarwin gmail.com> writes:
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).
May 11 2023
parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
May 11 2023
prev sibling parent reply epilogue <blandness mygrave.net> writes:
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.
May 11 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
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.



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
May 11 2023
parent ryuukk_ <ryuukk.dev gmail.com> writes:
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.



 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
May 11 2023