On Saturday, 15 February 2020 at 15:03:56 UTC, rikki cattermole wrote:
> From Walter's perspective it makes sense to want to limit the surface area of potential new bugs when you don't have the support to back you up.


OK now let's not get too carried away. If that was even something Walter was considering he wouldn't be maintaining his own backend. I've come across a few code gen bugs, and they aren't fun to diagnose and fix especially with how poor quality the backend code is. Some 20 years of legacy ported from C over those years.

On Thursday, 13 February 2020 at 07:29:00 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1031, "Deprecate Brace-Style Struct Initializers":
>
> https://github.com/dlang/DIPs/blob/c0c1c9f9665e0bc1db611f4e93e793d64451f763/DIPs/DIP1031.md
>
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits... in other words, business as usual.
>
> However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> The review period will end at 11:59 PM ET on February 27, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Please stay on topic here. I will delete posts that are completely off topic.

:(

I really like them and would prefer to have them do more.

So currently I can write this:

struct Q { int b; string c; }
struct S { int a; Q q; }
S s = { a: 3, q: { b: 5, c: "hello" } }

and that's great.

But what I'd really love to be able to do would be this:

S foo()
{
    return { a: 3, q: { b: 5, c: "hello" } };
}

and

Tuple!(int, "a", int, "b") bar()
{
    return { x: 3, y: 7 };
}

and even

auto bar()
{
    return { x: 3, y: 7 };
}
static assert(is(typeof(bar()) == Tuple!(int, "x", int, "y")));

Although probably not lowering to the phobos std.typecons.Tuple for obvious reasons.


Anonymous structures are great.

On Saturday, 15 February 2020 at 21:59:26 UTC, John Colvin wrote:
> On Thursday, 13 February 2020 at 07:29:00 UTC, Mike Parker wrote:
>> [...]
>
> :(
>
> I really like them and would prefer to have them do more.
>
> So currently I can write this:
>
> struct Q { int b; string c; }
> struct S { int a; Q q; }
> S s = { a: 3, q: { b: 5, c: "hello" } }
>
> and that's great.
>
> But what I'd really love to be able to do would be this:
>
> S foo()
> {
>     return { a: 3, q: { b: 5, c: "hello" } };
> }
>
> and
>
> Tuple!(int, "a", int, "b") bar()
> {
>     return { x: 3, y: 7 };
> }
>
> and even
>
> auto bar()
> {
>     return { x: 3, y: 7 };
> }
> static assert(is(typeof(bar()) == Tuple!(int, "x", int, "y")));
>
> Although probably not lowering to the phobos std.typecons.Tuple for obvious reasons.
>
>
> Anonymous structures are great.

I know this statement is completely unconstuctive but

😍

On 2/15/2020 6:39 AM, Steven Schveighoffer wrote:
>  From the perspective of the user, the complications in the compiler or library are of zero significance.

The complication is in the language. This affects the user:

1. the language is larger
2. user has to decide "should I do it the A way or the B way?"
3. documentation is longer
4. anyone writing a book/tutorial on D has to become proficient with it
5. introduces bugs (such as the one just noticed that the { } allows access to private fields)

It is not at all zero.

On 2/15/2020 9:58 AM, jxel wrote:
> how poor quality the backend code is.

Baloney.

It's written in an older style, sure, but it's remarkably bug free considering how complex it is. The complexity is a result of the fiendishly complex x86 instructions set.

The proof of its quality is it has successfully been extended from a purely 16 bit generator to 32 and extended again to 64 bit, and has been extended to support multiple ABIs and object file formats.

The DFA optimizer has also proven to be fast and very robust.

On 2/15/2020 6:23 AM, Steven Schveighoffer wrote:
> Not sure what this is supposed to mean.

Generally, such things can get a lot clearer if you use better formatting rather than mushing it all into one line.

On Saturday, 15 February 2020 at 23:54:17 UTC, Walter Bright wrote:
> On 2/15/2020 6:39 AM, Steven Schveighoffer wrote:
>>  From the perspective of the user, the complications in the compiler or library are of zero significance.
>
> The complication is in the language. This affects the user:
>
> 1. the language is larger
> 2. user has to decide "should I do it the A way or the B way?"
> 3. documentation is longer
> 4. anyone writing a book/tutorial on D has to become proficient with it
> 5. introduces bugs (such as the one just noticed that the { } allows access to private fields)
>
> It is not at all zero.

You could remove quite a few features, and prevent new ones for those reasons. Named parameters to start, especially with the current DIP that just introduces complexity for very little benefit and increases the burden on library authors to maintain compatibility. The new @live attribute, that's going to add way more complexity. The "in" and "out" qualifiers aren't really needed, and kind of useless and redundant. The ?: operator, don't really need it, just use a normal if statement. The "const" qualifier could be removed and nothing of significance would be lost, no body uses it anyway. Interpolated strings as well, its just syntactic sugar. The in and out contracts, there's a bunch of bugs with those and really just having asserts in the body of the function provides basically the same functionality. I don't really see anyone using that feature. I'm sure I could go on with some more. Deprecate 'real', it should be a 128 bit float, no body uses 80 bit floats and just having it be the largest possible dp unit is just repeating c's mistakes. Anyways for sure now, there's probably more features that you could remove for the same rationale you are giving as this one. D has numerous issues with not following private. Its cause its not something that someone pays attention to. I forget if allMembers was updated to not all private access.or to allow it, either way its not just this one feature that breaks private.

On Saturday, 15 February 2020 at 23:59:39 UTC, Walter Bright wrote:
> On 2/15/2020 9:58 AM, jxel wrote:
>> how poor quality the backend code is.
>
> Baloney.

No thank you, I don't eat baloney.

> It's written in an older style, sure, but it's remarkably bug free considering how complex it is. The complexity is a result of the fiendishly complex x86 instructions set.

The x86 instruction set is complex, but it allows you to generate simpler assembly. The backend will never support ARM because its a simpler instruction set and architecture that leans heavily on the codegen/optimizer producing correct assembly.

> The proof of its quality is it has successfully been extended from a purely 16 bit generator to 32 and extended again to 64 bit, and has been extended to support multiple ABIs and object file formats.

What you've just described is a symptom that leads to poor quality code. Some sort of Frankenstein that has to be mcgyvered into doing something it originally wasn't designed to do.

On 2/15/20 6:54 PM, Walter Bright wrote:
> On 2/15/2020 6:39 AM, Steven Schveighoffer wrote:
>>  From the perspective of the user, the complications in the compiler or library are of zero significance.
> 
> The complication is in the language. This affects the user:
> 
> 1. the language is larger
> 2. user has to decide "should I do it the A way or the B way?"
> 3. documentation is longer

All these points apply to for loops and foreach loops as well. All of these can be done with while loops.

Yet, we don't want to remove them because they provide a good readable syntax for what is required in most cases.

In my opinion, when you are adding features, you have a different bar to cross than when you are removing them. If adding, does the feature provide enough benefit syntactically over existing mechanisms to justify a language change. If removing, is there an alternate feature that can mimic it to a sufficient degree that we can remove it with a straightforward positive conversion?

Look at octals and hex strings. Both of these were implemented via a library call that provided equivalent operation. The syntax sugar was gone, but octals were confusing and error prone in their current state (being more verbose there with an `octal!` was a benefit), and hex strings simply weren't worth an entire language feature for it when CTFE could do exactly the same thing with a single call (newCTFE will help here too).

In this DIP, we are exploding the verbosity and repetitiveness to an uncomfortable degree, which frankly wasn't even necessary before. The brace syntax is beautifully minimal.

If we can alleviate that concern, I think there would be no problem to remove this feature.

> 4. anyone writing a book/tutorial on D has to become proficient with it

Really? You have to be proficient in D struct initializers to write a book? I'm pretty sure I have at least 2 D books without this in it.

I actually don't ever use braced struct initializers. But the use cases that have been provided are pretty compelling, and your workarounds have not been. At least not enough to remove the syntax sugar provided without a comparable replacement.

> 5. introduces bugs (such as the one just noticed that the { } allows access to private fields)

Is that really a bug? Struct literals have this access as well.

I'll also note that Mathias' example was not a private data member, but a private type (i.e. Voldemort type) with public members. His point was that everything being initialized was public, except the name. Which the new syntax requires whereas the old does not.

.tupleof provides private access also. I think there are many libraries that probably depend on this, so you may want to deprecate that slowly.

-Steve

On 2/15/2020 5:23 PM, jxel wrote:
> The backend will never support ARM because its a simpler instruction set

There actually was one for the ARM. It wasn't completed because the person writing it ran out of steam, not because he hit architectural dead ends.

Besides, the idea that an architecture designed to support a kludgy instruction set can't support a regular one doesn't make much sense.

> What you've just described is a symptom that leads to poor quality code. Some sort of Frankenstein that has to be mcgyvered into doing something it originally wasn't designed to do.

BTW, it was also extended to support the SIMD instruction set, which is architecturally fairly different. It was extended as well to support x87, which is architecturally rather unique.

I'm amused that a hallmark of poor quality is being adaptable to diverse architectures.

No other backend has ever been able to come close to its speed at the level of code quality it produces (it was originally designed to run on 16 bit floppy systems).

But I'm open to suggestions for improvement of the quality. If you have something specific, PRs are welcome.