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.

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.

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.

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.

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.]

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."

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.