On Sunday, 20 November 2022 at 19:11:31 UTC, Johan wrote:
>On Sunday, 20 November 2022 at 16:30:46 UTC, ryuukk_ wrote:
>On Sunday, 20 November 2022 at 16:14:41 UTC, Johan wrote:
>On Sunday, 20 November 2022 at 01:00:58 UTC, deadalnix wrote:
>On Friday, 18 November 2022 at 15:37:31 UTC, Mike Parker wrote:
>Discussion Thread
This is the discussion thread for the first round of Community Review of DIP 1044, "Enum Type Inference":
https://github.com/dlang/DIPs/blob/e2ca557ab9d3e60305a37da0d5b58299e0a9de0e/DIPs/DIP1044.md
I have very simple feedback.
STOP CHANGING THE GOD DAMN SYNTAX!
STOP, STOP, STOP, and if you still have some doubt, STOP!
Every time, it breaks a ton of tools.
It's not worth it.
If typing the name of the enum is too long, then just use with
or alias E = MyEnumNameThatIsTooLongAndAnoyingToType;
.
These changes do not solve any actual problem. They just break tools.
I quite strongly agree.
The DIP does not show any real improvements. The rationale mentions "few drawbacks" but then does not mention those actual drawbacks, so people can judge whether they are few or not.
The DIP show this example as an improvement:
myObj.myFn($medium, $square, $undefined);
Is the height medium?, the location the town square?, the shape undefined?
This is the "worse" version:
myObj.myFn(Size.medium, Shape.square, State.undefined);
Code will be read much more often than it is written.
Please give a real world example where really the enum name is so long and tedious that reading it is worse than without (and where with
does not solve the problem).
Besides tooling, also take into account someone relatively unfamiliar with D, stumbling upon a $
. (now what the heck is this gratuitous obfuscation?)
-Johan
D has good type system
Irrelevant.
It is relevant, care to bring more argumentation?
> >first off, name properly your functions/types/variables
Irrelevant.
It is relevant, care to bring more argumentation?
> >then about the problem you are raising:
In your long email, you are not addressing at all how this DIP addresses any of the problems I am raising. Just mentioning more examples of code that are not fixed by this DIP.
I'm unfortunately not qualified to answer every concerns and questions, i'm not a language developer or a compiler designer, i never wrote grammar stuff, i'm a mere language user, i can only share my experience writing code in my project
So i am thankful for all of you who share your opinions too, there is lot to learn
> >TOK
enum in DMD codebase instead of SymbolTokenType
Thank you for this example. Search DMD codebase for TOK
, and tell me how this DIP would matter for renaming TOK
to SymbolTokenType
:
dmd/compiler/src/dmd/cond.d:
195 {
196 auto tf = new TypeFunction(ParameterList(), null, LINK.default_, 0);
197: auto fd = new FuncLiteralDeclaration(loc, loc, tf, TOK.reserved, null);
198 fd.fbody = s;
199 auto fe = new FuncExp(loc, fd);
...
407 auto exps = new Expressions(length);
408
409: if (rangefe.op == TOK.foreach_)
410 {
411 foreach (i; 0 .. length)
dmd/compiler/src/dmd/cparse.d:
112 while (1)
113 {
114: if (token.value == TOK.endOfFile)
115 {
116 addDefines(); // convert #define's to Dsymbols
This DIP is not needed. TOK
can happily be renamed to SymbolTokenType
.
Let's not waste time on it.
-Johan
I used TOK example because it was mentioned in this thread
if (token.value == TOK.endOfFile)
what's token.value????? you guessed that .value is the value of the TokenType?
if (token.token_type == .endOfFile)
I'd love to know what was the reasoning behind TOK
naming, was it because it was too long? that would be my guess