On 2/15/2020 7:20 PM, Steven Schveighoffer wrote:
> All these points apply to for loops and foreach loops as well. All of these can be done with while loops.

It's the while loop that is redundant. foreach is key to writing generic code that would be impractical using for loops for.


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

That's not really why. I can explain more if you like.


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

You said you don't use this syntax. I've used it since the beginning. I wouldn't miss it.

Left unsaid in all this is the static initializer syntax can only be use for statics, and even then only for structs without a constructor. I've never heard a complaint about how terrible it was to use the function-style syntax, which is required for every other use.

As for using Voldemort types in a static initializer, good luck contriving a use case for that. And if one manages to do it, there's still a usable workaround - typeof - which Mathias used.


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

Ali's book certainly does (Section 47.3). Andrei's does not, it uses the function style syntax.

---

BTW, if you want to present a DIP for anonymous struct literals, please do so.

On Sunday, 16 February 2020 at 05:57:22 UTC, Walter Bright wrote:
> Left unsaid in all this is the static initializer syntax can only be use for statics, and even then only for structs without a constructor.

It actually works for dynamic initialization too:

> The static initializer syntax can also be used to initialize non-static variables. The initializer need not be evaluable at compile time.

Source: https://dlang.org/spec/struct.html#dynamic_struct_init

On Sat, Feb 15, 2020 at 09:13:01PM -0800, Walter Bright via Digitalmars-d wrote: [...]
> I'm amused that a hallmark of poor quality is being adaptable to diverse architectures.

Yeah, I think the original criticism here was a bit ridiculous. However:


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

What's the point of lightning fast generation of poor quality code? Okay, during development it's good to have fast turnaround times. But what when it's release time and I want to squeeze the last bit of juice from the generated code?  Running dmd -O for this is, sorry to say, a disappointment. I've measured this against LDC and GDC, and they *consistently* produce code that outperforms dmd-generated code. A 20%/30% speedup is typical, sometimes with compute-heavy code it can be 40% faster than dmd generated code.

I've been saying this for years, and even reported bugs about it. But so far, things have not changed very much. When runtime performance matters, I don't even consider dmd, I already know ldc/gdc will produce faster code.

So sure, the dmd backend is the fastest of its kind that produces 20% slower code, but that's hardly something to boast about now, is it?


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

Well this is part of the problem: because the code style is old and unfamiliar to most contemporary programmers, you're not going to find many people who would be able to contribute a PR. And those who can may not necessarily be willing to spend the time to do so.  Chicken and egg problem.

People *can* file bugs related to performance, though. I did. And I'm still waiting for results.


T

-- 
One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"

On Saturday, 15 February 2020 at 21:59:26 UTC, John Colvin wrote:
>
> :(
>
> I really like them and would prefer to have them do more.
>
> [...]
>
> 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 [...]
>

This (and the rest of the post) 100%.
The only thing that ever annoyed me about struct literals is that they don't work everywhere.

On Sunday, 16 February 2020 at 05:13:01 UTC, Walter Bright wrote:
> PRs are welcome.

They really aren't. Every time there's some sort of significant change of a pull request, you shut it down as 'reshuffling'.

It's also not my job to cleanup. There's a perfectly fine D compiler with a quality backend known as LDC. The only pull request I'd make would be to merge LDC in.

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

Effectlively this DIP proposes simplifying the compiler - not so much the language itself
 - primarily because this feature is used seldomly and provides little value. But there are several problem which undermine this rationale.

I would argue that this feature is one of the simpler features of for beginners to learn. You have a struct, enumerate it's field with appropriate values and get an initialized instance. This has compelling use cases (which Andre already presented) and were the alternatives are much more verbose. This is in conflict with one of D's core strengths, writing expressive and clean code.

This leads to the question why this feature is rarely used. The current discussion mentions them being type system holes (because they circumvent constructors) [1] and their restriction to variable initializers [2]. I think we should address these issues to increase the usability of the current syntax instead of simply deprecating it.

Suggestions:
[1] Deprecate (and soon disallow) brace-style initializers for non-PODs
[2] Allow brace-style initializers wherever a corresponding struct rvalue is allowed (and can be resolved unambiguously)

On 2/15/2020 10:27 PM, H. S. Teoh wrote:
> What's the point of lightning fast generation of poor quality code?

The speed of the code generated was competitive with (and sometimes ahead of) the other compilers from 1985 to 2000 when I worked actively on it. It slowly fell behind after that as I was spending my time on the D front end.

This is not evidence that the code quality of the back end is poor.


> Well this is part of the problem: because the code style is old and
> unfamiliar to most contemporary programmers, you're not going to find
> many people who would be able to contribute a PR. And those who can may
> not necessarily be willing to spend the time to do so.  Chicken and egg
> problem.

There are very, very few programmers out there who understand code generation issues well enough to improve things. It has nothing to do with the back end being old fashioned. The data structures in it are simple and straightforward.

That said, some people have contributed some good work to the back end, but nothing fundamental.

On Sun, Feb 16, 2020 at 12:18:30PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/15/2020 10:27 PM, H. S. Teoh wrote:
> > What's the point of lightning fast generation of poor quality code?
> 
> The speed of the code generated was competitive with (and sometimes ahead of) the other compilers from 1985 to 2000 when I worked actively on it. It slowly fell behind after that as I was spending my time on the D front end.
> 
> This is not evidence that the code quality of the back end is poor.

Note that I did not say the code quality of the back end is poor. I said that the quality of the code *generated* by the back end is poor.  And that's not in an absolute sense, since obviously it's still of the same quality as it was back in 2000, but it's poor in the relative sense, compared to the output of modern backends like GDC or LDC.

The problem is that while the rest of the world has marched on since 2000, the DMD backend has remained stagnant.  Effectively, therefore, it's regressing -- not in the absolute sense of course, but relative to the rest of the world that has since moved on.  Which means that now it's a much harder sell to choose the DMD backend over, say, LDC or GDC's.  As a user, I don't care how good the DMD backend is as long as its output is inferior compared to alternative backends; obviously I'm going to choose the backend that gives me better generated code, regardless of how either backend arrives at it.  Maybe the GDC backend is garbage in terms of its own code quality (as an example -- I don't know the GDC backend code), but as long as the code it *generates* performs faster than the code DMD generates, users are going to choose it over DMD.


> > Well this is part of the problem: because the code style is old and unfamiliar to most contemporary programmers, you're not going to find many people who would be able to contribute a PR. And those who can may not necessarily be willing to spend the time to do so. Chicken and egg problem.
> 
> There are very, very few programmers out there who understand code generation issues well enough to improve things. It has nothing to do with the back end being old fashioned. The data structures in it are simple and straightforward.
> 
> That said, some people have contributed some good work to the back end, but nothing fundamental.

And that is precisely the problem.  While GDC/LDC backends may or may not have the technical superiority over DMD's backend, what matters is that people are improving it over time, whereas the DMD backend has been staying stagnant. It doesn't matter what the reason is -- maybe programmers are not competent enough to work on the DMD backend, maybe there's some other reason, but what matters is that there are very few people actively improving the DMD backend, whereas there are large teams of people honing the GDC/LDC backends continually.  Effectively, therefore, the DMD backend is regressing, not in the sense that it's actually *degrading*, but in the sense that it's lagging behind the other backends.

No matter how technically superior the DMD code may be, and no matter how inferior the other backends may be, what the user is going to choose will be decided by what kind of code is generated, not by what kind of code the backend is running.  The DMD backend can be superior all it wants, but if the code it generates is slower than the code produced by GDC or LDC, then there is really no reason for me to prefer DMD over GDC or LDC.  Therein lies the rub.


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson

Would removing support for brace-style struct initializers significantly simplify or speed up some portion of DMD?

On Sunday, 16 February 2020 at 15:24:26 UTC, Mathias Lang wrote:
> [..]
>
> The only thing that ever annoyed me about struct literals is that they don't work everywhere.

I completely agree. I have several developers on my team with mostly JavaScript/TypeScript background, and it would be quite difficult to introduce D to them without the relatable (and also people for coming from C) struct literal syntax.

These days is quite rare to find a JS/TS project that doesn't make a heavy use of this feature:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment

https://javascript.info/destructuring-assignment

If accepting the named parameters proposal meant that we could simply replace braces with parentheses, I'd onboard with DIP1031, but not before.

(Of course that would involve a semantic change, as currently the brace literal syntax works only for initializing structs without constructors and named parameters are meant to invoke either the user defined constructor or the default synthesized one.)