April 25, 2023

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:

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)

April 25, 2023

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.

April 25, 2023

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

April 25, 2023

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

April 25, 2023
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.

April 25, 2023
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.

April 26, 2023
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.
April 26, 2023
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
April 26, 2023

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?

struct S { int x; }
void fun(S) {}

fun({42}); // Error
April 26, 2023

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 :^)