November 20, 2022

On Sunday, 20 November 2022 at 01:00:58 UTC, deadalnix wrote:

>

STOP CHANGING THE GOD DAMN SYNTAX! STOP, STOP, STOP, and if you still have some doubt, STOP! STOP IT!
(etc. etc.)

Thank you for your hateful rant, but please actually read the DIP. ;P
I carefully wrote the DIP for ETI in order to avoid breaking or changing the behaviour of any existing code. That's why I settled on the $member syntax for the original draft.

November 20, 2022
On Sunday, 20 November 2022 at 15:28:37 UTC, deadalnix wrote:
> There is. Bundle the breakage, and release them all at once every couple of years. Every single language out there does that, there is a reason for it.

Sorry but haha... Python exists.
They broke heaps of code with an unannounced security patch to "fix" the bigints being ...
you'll never guess this one...

...

... ... ... too big.
November 20, 2022
On 20.11.22 16:28, deadalnix wrote:
> On Sunday, 20 November 2022 at 09:39:11 UTC, Timon Gehr wrote:
>> It's not worth freezing the language over temporary tool breakage. Just don't update the compiler until the tools have caught up.
>>
> 
> Here is where you are wrong: it's not temporary breakage, it's permanent,

I am pretty sure tools can be updated.

> but this whole circus happens every few of months.
> 
> We can argue all day long,

I'd rather not, but I do think it's a bit weird that you are arguing against new language features in general, in a DIP discussion thread about one specific feature, on the grounds that you actually just disagree with the release schedule.

> but the proof is in the pudding: D tooling is abysmal and kinda broken pretty much everywhere. It's not hard to figure out why:

Sure, the reason is lack of resources and the fact that tooling is not viewed as a priority because it is not already a strength.

> people implement D support at some point, and then changes accumulate and support kinda work, kinda not.
> ...

There is no such thing as "D" support. Versioning exists.

>> There has to be a better way.
> 
> There is. Bundle the breakage,

Which D is doing. Nobody is expected to build their programs off DMD master.

> and release them all at once every couple of years.

I.e., the difference is that they have LTS versions. The solution you proposed (and I had an issue with) is to stop evolving the language.

> Every single language out there

That seems a little bit exaggerated.

> does that, there is a reason for it.

The reason is that they have more resources.
November 20, 2022
On 20.11.22 17:31, IchorDev wrote:
> On Sunday, 20 November 2022 at 01:00:58 UTC, deadalnix wrote:
>> STOP CHANGING THE GOD DAMN SYNTAX! STOP, STOP, STOP, and if you still have some doubt, STOP! STOP IT!
>> (etc. etc.)
> 
> Thank you for your hateful rant, but please actually read the DIP. `;P`
> I carefully wrote the DIP for ETI in order to avoid breaking or changing the behaviour of any existing code. That's why I settled on the `$member` syntax for the original draft.

His problem is that the compiler will be the first tool that can parse the new syntax and other tools will by default not work anymore on code that uses the new syntax.
November 20, 2022
On 11/19/2022 5:00 PM, deadalnix wrote:
> STOP CHANGING THE GOD DAMN SYNTAX!
> STOP, STOP, STOP, and if you still have some doubt, STOP!

You might like the Alternative Possibility in this thread.

November 20, 2022
On Sunday, 20 November 2022 at 17:07:52 UTC, Timon Gehr wrote:
> His problem is that the compiler will be the first tool that can parse the new syntax and other tools will by default not work anymore on code that uses the new syntax.

I'll quote what I said on the server:
> [...] Languages update. D has always had regular breaking changes for better or worse... that's just what it is. If they don't like that... they should probably not be maintaining a code formatter for [Dlang.]
November 20, 2022
On Sun, Nov 20, 2022 at 03:31:44AM +0000, ryuukk_ via Digitalmars-d wrote: [...]
> ```D
> MySuperDuperLongEnum stuff = MySuperDuperLongEnum.VALUE_A;
> ```

Why not just write:

	auto stuff = MySuperDuperLongEnum.VALUE_A;

?  No repetition necessary.


[...]
> why should i use an alias here?
> ```D
> ctx.network_state = State.NetworkState.CONNECTED;
> 
> // vs
> 
> ctx.network_state = .CONNECTED;
> ```

Walter's proposal of implicit `with` would solve this case.


T

-- 
"You are a very disagreeable person." "NO."
November 20, 2022

On Friday, 18 November 2022 at 15:37:31 UTC, Mike Parker wrote:

>

Discussion Thread

[...]

Putting aside the syntax, which is aesthetically displeasing to me, I don't see much utility over alias and with to justify this DIP's acceptance, and that's without considering the tooling argument.
That said, Walter's "implicit with" looks neat.

November 20, 2022
On 11/20/2022 8:29 AM, IchorDev wrote:
> On Saturday, 19 November 2022 at 08:49:31 UTC, Walter Bright wrote:
>>
>> Advantages of this scheme:
>>
>> 1. doesn't need the special `$` which people don't seem to like, and using `.` conflicts with existing use
> 
> I'm up for changing it to something else, like I've said. It's just that I can't think of anything better except maybe `#member`, but I think `#` is reserved right?
> `:member` would be cool but it reminds me of C++ and would be a nightmare in so many cases. `%member` is alright but it looks like an operator. What about `->member`... actually nevermind I hate it.
> `\member`???

So far, I haven't thought of a good syntax for it, either. That's what led me to think "what if we don't need the prefix at all".


>> 3. seems to have a natural feel to it
> 
> I have mixed feelings about this. It's *very* hard to intuitively read that it's an enum member when it's written without any kind of affix at all,

There is precedent for it. Fields in non-static member functions do not need a `this.` prefix, as there's an implicit `with(this)` for the function.


> and it can't even work with overloaded functions.

Overloaded functions are necessary, but I've often thought they are overused. But as I've mentioned in several comments here, the inferred enums lead to awkward problems for overload resolution - not just for the compiler, but for the user trying to figure out which overload is a better match. C++ overloading is so complex that basically nobody understands it - how people figure out which is matched is by trial and error, not understanding. While we could come up with arbitrary rules to resolve this, I suspect it is not worth it.


> With some changes, I'd consider it.

Good! This discussion thread is very productive.
November 20, 2022

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.

>

first off, name properly your functions/types/variables

Irrelevant.

>

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.

>

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