On 4/27/2022 8:59 AM, Satoshi wrote:
> Also I don't know why they didn't take the inspiration from other modern languages.

Other languages have taken inspiration from D, such as ranges and compile time expression evaluation.

D now has an ownership/borrowing system inspired from other languages.

Right, D doesn't have async/await. That's mainly because nobody has spent the time to figure out how to do it, not because I'm blocking it.

On 4/28/2022 5:04 AM, bauss wrote:
> * async/await
> * Properties that actually work and also with a really good syntax IMHO (getters/setters)
> * string interpolation
> * Shortened methods (and properties.) - much better than the proposed version for D
> * nullability built-in ex. object?.method(), as well null-coalescing
> * pattern matching / switch expressions
> * out parameters that can be declared directly in the method call
> * built-in tuples, as well auto-expanding them to variables etc.

It's a good list. Though I proposed a straightforward string interpolation method, but it received no traction.

I don't know what you're driving at about properties not working in D. I use them all the time.

On 4/28/2022 5:33 AM, SealabJaster wrote:
> It's not even about the amount of keystrokes like many here claim, it's about readability. All these little things add up as the code grows, and it makes C# a joy for me to read and write.

Fortunately, bitfields are now in the language, although they're behind a -preview=bitfields switch. Builtin bitfields are indeed all about syntax sugar.

I agree with you that readability is more important than keystrokes.

On 4/29/2022 7:56 AM, Paul Backus wrote:
> On Friday, 29 April 2022 at 07:56:15 UTC, bauss wrote:
>> I think his point was that D seems to favor library-only solutions in a lot of cases and then the syntactic sugar is never added properly.
>>
>> No matter how good your library solutions are then you can never implement async/await in a clear fashion without the compiler emitting you a state machine for it.
> 
> The dirty secret here is that the code quality of the DMD fronted has deteriorated to the point where it is basically impossible to do a correct, complete implementation of any non-trivial language feature. So we can either have a library solution that works, but has ugly syntax; or we can have a language solution that has nice syntax, but doesn't work.

I don't know what the rewrites of async/await would be. If someone would write that down, I doubt it would be that hard. After all, I got ImportC to work :-/

On 4/28/2022 12:02 PM, Iain Buclaw wrote:
> GCC-12 has been branched and is currently in prerelease phase, with an RC to be made on Monday if all is going to schedule.
> 
> GDC in there is currently in sync with the current DMD HEAD on the stable branch (tag: `v2.100.0-beta.1`, dmd `313d28b3d`, druntime `e361d200`, phobos `ac296f80c`).

Great news!

On Friday, 29 April 2022 at 15:31:05 UTC, Walter Bright wrote:
> Though I proposed a straightforward string interpolation method, but it received no traction.

A few modifications to your proposal was and still is plenty workable, just the DIP process is extremely draining.

On 4/29/2022 3:40 AM, Chris wrote:
> I don't know to which extent this is true, but D is certainly more of a research than a real world language. What galls ex-users is that this is not communicated clearly to newcomers. Instead, you have to get deep into D (which, in fairness, has its merits, because you learn a lot) before you realize that your projects will forever be hampered by D's shortcomings. Same shortcomings are never really addressed because D is, at its core, a CS research language (which is slowly losing its edge over mainstream languages like C#, C++ etc.). The language should not be sold as production ready. I remember the "update lottery" whenever a new version was available: will it break my code or not? This is a situation you find yourself in with languages that are below 1.0 and then you know what you're in for. However, D is already 2.+. The only explanation is that in reality D is still at a stage that is below 1.0. I've been an early adopter with some PLs and one OS, it's always a bit of a gamble and it takes some effort. However, those PLs and the OS have matured and stabilized. D never ever matures or stabilizes, it just goes on and on and on being between 0.1 and 0.9. This made it impossible for me to create real world applications. Apart from making my work unnecessarily difficult, how could I justify the use of an eternal 0.x language to superiors and users? break (D) { switch; }

We leave deprecated features alive for several years, and there are quite a lot of long term projects on buildkite that are part of the test suite so we know if something breaks.

On Friday, 29 April 2022 at 15:36:34 UTC, Walter Bright wrote:
> On 4/29/2022 7:56 AM, Paul Backus wrote:
>> On Friday, 29 April 2022 at 07:56:15 UTC, bauss wrote:
>>> I think his point was that D seems to favor library-only solutions in a lot of cases and then the syntactic sugar is never added properly.
>>>
>>> No matter how good your library solutions are then you can never implement async/await in a clear fashion without the compiler emitting you a state machine for it.
>> 
>> The dirty secret here is that the code quality of the DMD fronted has deteriorated to the point where it is basically impossible to do a correct, complete implementation of any non-trivial language feature. So we can either have a library solution that works, but has ugly syntax; or we can have a language solution that has nice syntax, but doesn't work.
>
> I don't know what the rewrites of async/await would be. If someone would write that down, I doubt it would be that hard. After all, I got ImportC to work :-/

I would hardly call ImportC's implementation "correct" and "complete" at this point, given the large number of outstanding bugs and the fact that it does not even support the preprocessor yet.

This is exactly what people mean when they call features of D "incomplete" or "unfinished" or "half-assed": the happy path works, but important features are missing and the edge cases are riddled with bugs.

I'm sure ImportC will improve, given enough time--maybe 3-5 years? But outside of a tiny number of core developers such as yourself who work on D full-time, it is unrealistic to expect an open-source contributor to see a project of that scale through to completion. That's what I really mean by "basically impossible". Not that it literally cannot be done, but that the amount of time and effort required is prohibitive for the vast majority of contributors.

On Friday, 29 April 2022 at 14:21:46 UTC, Walter Bright wrote:
> Zortech C++ was about 4 times faster than cfront based C++ on DOS machines. This was my measurements. I agree it had nothing to do with templates. Personally I doubt Stroustrup had ever tried ZTC++.
>
> I was wrong, ZTC++ came out in 1988, not 1987.
>
> DOS computers were where the great mass of programmers were at the time. 90% is likely conservative. The programming magazines were all focused on DOS programming, the articles about C++ were for DOS C++ programming.
>
> Before ZTC++, the traffic on comp.lang.c++ and comp.lang.objectivec was about the same, and not very much. After ZTC++, the traffic in comp.lang.c++ took off, and comp.lang.objectivec stagnated.

Thank you!

On Friday, 29 April 2022 at 14:21:46 UTC, Walter Bright wrote:
> Zortech C++ was about 4 times faster than cfront based C++ on DOS machines. This was my measurements. I agree it had nothing to do with templates. Personally I doubt Stroustrup had ever tried ZTC++.
>

For this comparison which underlying C compiler did cfront use? Zortech's?