On 10/24/2022 4:18 PM, Timon Gehr wrote:
> It does not allow me to do most of the things I'd like to do with lifetime tracking.

I'd appreciate if you would write this all up, and in the simplest possible terms. Most examples I see are hopelessly overcomplicated, I have to do a lot of reduction to figure out the essence of it :-/

For example, there's no need for templates to demonstrate a lifetime issue. Or arrays, or non-static member functions, or copy constructors, or other abstractions. Almost always simple pointers and refs will do.

> At least `scope` is checked by the compiler more reliably now, which is good.

I try to distinguish between fundamental design faults and implementation bugs. I recently went through the entire list of dip1000 issues in bugzilla, including those that asserted that scope was unfixable, and they all turned out to be tractable.

On 10/24/22 21:38, Walter Bright wrote:

> I'd appreciate if you would write this all up

I think this has already past the point where interested parties should get together in a virtual meeting to understand each other.

Ali

On Tuesday, 25 October 2022 at 05:08:47 UTC, Ali Çehreli wrote:
> On 10/24/22 21:38, Walter Bright wrote:
>
> > I'd appreciate if you would write this all up
>
> I think this has already past the point where interested parties should get together in a virtual meeting to understand each other.
>
> Ali

Maybe Dconf online can be the place where this can happen 😃

On Monday, 24 October 2022 at 20:38:59 UTC, Walter Bright wrote:
> It seems you're suggesting attaching this behavior to the pointer, rather than the function. That means multiple pointer types.
>
> Multiple pointer types have been tried many times. They are attractive in theory, but work out poorly in practice. For example, take:
>
>     char* strcpy(char* dst, char* src);
>
> With two pointer types, now you have 4 implementations of strcpy rather than one. It does not scale.

1. Nobody should care about strcpy in 2022. It was a poor design back then and now it's ridiculously foolish.
2. You already have multiple pointer types in D, there is const*, immutable*, scope*... It's just that these multiple pointer types still don't get the job done because these don't deal with ownership nor memory regions effectively.
3. What does not scale is reason by analogy. "In DOS there were NEAR and FAR pointers so having multiple pointer types does not work so let's conflate traced and untraced pointers." No mainstream language that came after D copied this brilliant design of yours, maybe it's time to wonder *why*.

On Monday, 24 October 2022 at 22:26:41 UTC, Walter Bright wrote:
> The design of dip1000 does not preclude this, however, and it's good to see how far we can push things and avoid needing such complexity.


I am glad to see a language that is C-like, understandable, trying to not put
all the heavy-weight on the programmer but allowing it where it is necessary. This is what kept me with C++ and not Rust so far. Rust is just too rigid and restrictive for a lot of legal coding patterns.

As a long-time C++ user (20 years using it non-stop) D, combined with its powerful import('file.ext'), powerful metaprogramming, C/C++ linkage compatibility and interaction  and now DIP1000, and a more than reasonable standard library with Ranges, sumtypes and powerful type meta-programming and concurrency it is getting very attractive, at the top of the list: more than Zig, Rust or Nim.

Of course, I am more familiar with C++ than anything else. But this is a selling point for me: if you jump to Nim/Zig/Rust you are, in some way, in more foreign territory.

I wonder how the status is implementation-wise, that is the part that scares me a bit to jump in.

I think the tooling needed some love though I did not try recently.

Congrats for the hard work, it has been a ton of years but you show a lot of practical, real-life use in your decisions.

My advice would to sell D as an industrial language that can be incrementally adopted from C++ with safety and compatibility guarantees, besides the metaprogramming, beyond what the competition can achieve.