On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:

I don’t want to be discouraging of good work, but D is not lacking in great features, it is lacking in its implementation of the basics.

I have come to believe over several years working in D, managing work in D at some scale (10s of devs, not 100s) & advocating for D that the foundations are shaky and crumbly and need work.

While it is not possible to implement a struct as drop-in replacement for a built in slice, while template symbol emission bugs keep happening[1], while the built in AAs are not in great shape (and the signature of toHash is a PITA), while the compiler is a huge memory hog and compile times for templates get wild, while speculative compilation results somehow go wrong and leak in to the non-speculative parts of compilation (e.g. https://issues.dlang.org/show_bug.cgi?id=19545), while syntax changes happen without enough noise (so even basic tooling ends up breaking), while shared and property and synchronised classes and so on sit in poor and/or incomplete shape, while delegate contexts still have qualifier problems[2]…

Why would the limited resources available be focused on a built-in sum type?

D is an amazing language. “Another killer feature” isn’t the missing piece to it getting some real, persistent, large-scale traction. They key is the rock solid basics and the cleaning up of lingering nonsense. Then the features can come, if they need to, because everyone loves building features and the more the basics are sorted out the easier it will be to add more.

The really committed and talented people here need to choose quality and build it.

I think D has a culture of accepting all sorts of badness while promising greatness, which is self-limiting.

I have poured a unbelievable number of hours in to D over the years, both commercially and open source, it has formed the backbone of my career, I want to see it succeed, but this will not happen if the basics are not dealt with.

I’m happy talk more about this with any of the core developers, I may not write a lot more out here as I don’t want to keep ladling on negativity in public, but for a variety of reasons I think change is needed.

[1] please no “where’s the bug report”, it’s whackamole. There needs to be a reckoning with the fundamental nature of the problem. Does anyone even understand the current design & implementation?

[2] this is pretty much what I could think of off the top of my head. I’m sure there’s more!

On Saturday, 3 December 2022 at 16:17:19 UTC, John Colvin wrote:

Well put.

The benefits of an alternate front end development effort have never been clearer.

On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:

Actually why not to introduce optional type first and then base sumtype implementation on optional saying that sumtype_obj.value yields to optional of type typeof(sumtype_obj.value)?

Offtopic about strictly non-null pointers: what's about int*! ptr syntax? a pointer that can be null: int*? ptr. And the regular pointer (int* ptr) can be, for example, force-treated as int*! ptr or int*? ptr based on compiler option.

On Saturday, 3 December 2022 at 16:17:19 UTC, John Colvin wrote:

Yep. I 100% agree.

The issue with D right now are not the bells and whistles.
It's the bread and butter.

As for the template emission, having been away from the issues and scene for a while made me realize the reason of the emission issues.
It's that we cannot emit the same symbol twice.

@Ibuclaw if I am correct at least that would be solved by making template instances weak symbols no?

If we did that we could remove some complexity from the emission.

On Wednesday, 30 November 2022 at 14:32:56 UTC, Basile.B wrote:

a?.b = c

typeof(a.b) fallback;
(a.b ? a.b : fallback) = c;

// let me explain the problem
// you want optional access

struct S
{
    int a;
}

// so you cant get optional access to `a`
// because "int" does not allows this so
// you write

struct S
{
    SomeSumtype a;
}

// nice but it's not anymore compatible with C
// the optional value is part of the struct size
// you see the problem ?
//
// your struct size is not anymore 4 but 8.
//
// Optional access must be built in the language as an operator.

you see what I mean ?

On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:

I like the a | b | c syntax, because the simpler and cleaner it is to use a tool suitable for efficient expressive error checking, the more likely I'll be to actually use it to implement error checking. The seductive alternative in my experience will always be "Ehh, error checking? What a hassle. I'll wrap everything in try/catch tomorrow... maybe."

On Saturday, 3 December 2022 at 16:17:19 UTC, John Colvin wrote:

I agree. The question is who other than Walter is going to do this. These are the things that, IMO, Walter should not even be part of.

On Saturday, 3 December 2022 at 16:17:19 UTC, John Colvin wrote:

SDC seems to be a pathway to a nicer frontend, at least. Would love to see its representation at the meetings.