On Monday, 29 November 2021 at 12:47:35 UTC, Nick Treleaven wrote:

Yeah, I'm not really supportive of everything having to be a library.

There are far more advantages of having some things built-in, rather than added as a library solution.

On Monday, 29 November 2021 at 13:11:12 UTC, user1234 wrote:

No lies. Compiler optimizations that focus on standard library constructs are not uncommon and makes a lot of sense: these constructs occur frequently.

It is still a library solution. Change the library implementation, it will still work, but the optimizer may not recognize it.

Nothing unusual about this.

On Monday, 29 November 2021 at 14:16:56 UTC, bauss wrote:

What advantages?

Keep the language small and make it possible to implement a bug-free compiler.

On Monday, 29 November 2021 at 13:22:34 UTC, Nick Treleaven wrote:

Yes, that would make a lot of sense.

Or you could make the current behaviour more general and add support for "dependent typing" of null-pointers.

So, this would work like this: you can specify that an operator is "value dependent", meaning there are two or more implementations that will be selected based on the value of the argument.

Is this sufficient to cover the current implementation?

On Monday, 29 November 2021 at 14:57:04 UTC, Ola Fosheim Grøstad wrote:

Maybe overkill?

One step would be to make this optionally explicit in overloading functions such as opIndexAssign.

So you could specify opIndexAssign(ref … this, …) and modify this if it is a null pointer.

Anyway, seems like such issues could be solved with minor adjustments.

On Monday, 29 November 2021 at 13:56:08 UTC, Petar Kirov [ZombineDev] wrote:

Yes, it is a powerful concept, but TypeScript is "reinterpreting" the underlying types. If done in D it might be the same as refining types with constraints.

A long time ago I suggested using reqular expressions for expressing constness, which perhaps is what TypeScript is doing. Just with a verbose syntax.

It could be done in a more concise fashion by borrowing ideas from query languages for tree-datastructures, such as XQuery or CSS selectors.

Using the more verbose syntax of TypeScript only makes sense if you also do your point 3:

Concepts/traits in C++ and Rust are making the lack of this feature more apparent, I guess.

By "affine types" in this context, do you mean "use once or never" types?

So you would make all functions "templated"? Or, how else would this work?

On Monday, 29 November 2021 at 16:05:46 UTC, Ola Fosheim Grøstad wrote:

Typescript's object types look to me like Go's interfaces (which are like Rust's traits), but with a bit more flexibility. They look more runtime-oriented than C++'s concepts.

On Monday, 29 November 2021 at 16:14:29 UTC, jmh530 wrote:

Hm. I think I understand what you mean, but TypeScripts type system does not exist at runtime at all, so it is static and for compile time only (or mostly). Runtime type checks are limited to JavaScript. Go is more dynamic in nature and therefore not fully static, so some typing errors will be discovered at runtime in Go.

TypeScripts types are however weak, in the sense that they are just painted over JavaScript objects that may have content that contradicts the types TypeScript paints over them. Kinda like how D can paint incompatible types over data-structures received from C code.

In that context maybe it would be interesting to have something similar, and allow programmers to «paint constraints» over both D and C data-structures to catch more bugs at compile time.

On Sunday, 28 November 2021 at 20:47:28 UTC, Ola Fosheim Grøstad wrote:

I just don't understand the premise of a "D3".
We don't need "D3" to have breaking changes, we now have a better system with -preview/-revert.

Considering D2 approximately halved the userbase, talks about "D3" should really be talks about new -preview flags. The idea that a magical breaking change fixes the langage without a nice upgrade path is magical thinking, because it would be strictly worse than what we have today.

On Tuesday, 30 November 2021 at 13:49:12 UTC, Guillaume Piolat wrote:

There should absolutely be an upgrade path, which is why "equally expressive" would be very much a requirement. I believe to a large extent that one could do it this way:

For files ending in ".d" emulate most of the current behaviour. For files ending in ".d3" provide the full cleanup. Then you can combine ".d" and ".d3" files. Much like how you combine ".c", ".cpp", ".mm" files in X-Code for C, C++, Objective-C.

One possible way to arrive at this path would be to create a high level IR (HIR) for the current DMD compiler, then a new D3 compiler would emit the same high level IR and you would combine the HIR output using a high level linker (basically a compiler). You could do the same for C too.

The problem right now is that there is neither LTS or a compiler code base that is suitable for further evolution, so with no change on the technological level you effectively "halve the population" anyway by slow evolution. There are other languages quite close to D in semantics, so without "D3" there are other languages that take that role regardless.

It also makes absolutely no sense to write a new compiler codebase that emulate the quirks of dmd?

The better strategy is to have:

1. DMD -> HIR
2. D3 -> HIR
3. HIR -> LLVM

That allows you to give DMD D2 long term support and also improve on compilation speed and backend support (ARC and borrowing) for both.