DIP1044---"Enum Type Inference"---Formal Assessment

[ryuukk_]

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