On 5/10/2025 9:07 PM, Manu wrote:
> I tested that and it didn't work for me. Maybe my test was faulty somehow since I was working through numerous combinations, I'll try it again...


I just tried it again, with the same result.

On 5/11/2025 4:32 AM, Timon Gehr wrote:
> Well, it's common enough to need type system support.

That's not necessarily true. You can do everything in C that D does, it's just less convenient.


> Support for multiple indirections is also important. Rust actually provides both of these.

There are other ways to do that. Multiple indirections can be handled by using structs and then only allowing access to structs through member function interfaces.


>> It's a minor inconvenience that can be refactored away.
> In general you'll have to resort to `@system` code,

While you can always do it with @system code, I'm not convinced some refactoring won't work. It's not a disaster to use @system code now and then.


> and it will stand in the way of other refactorings you may want to do.

You've got to do a lot of refactoring to make Rust code work anyway.


> Anyway, I don't think this is a theoretical issue anymore, even though my perspective was the same when we first discussed this. AFAIU, real industry users have already found DIP1000 to be lacking because of its lack of compositionality.

I'm not aware of any particular instance of this, so cannot help with it.

On 5/11/2025 5:32 AM, Timon Gehr wrote:
> On 5/10/25 06:13, Walter Bright wrote:
>> The @live design was done in a manner to not need any new syntax - it is an extra layer of error checking.
> 
> That would be giving too much credit.

This is why I stopped working on D's borrow checker. It's all been relentlessly negative. But I did get it to the point where it proved that a borrow checker can work in D with zero changes to the syntax (except marking a function as @live), and I'm happy about that.

When I embarked on ImportC, I got the same response. Until suddenly it became a major asset for D. I was just more willing to push through with it.

On 5/11/25 20:23, Walter Bright wrote:
> 
> This is why I stopped working on D's borrow checker.

That was the right call.

> It's all been relentlessly negative.

Well, sorry, this is not fun for me.

> But I did get it to the point where it proved that a borrow checker can work in D with zero changes to the syntax (except marking a function as @live), and I'm happy about that. 

I think nobody competent doubted it is possible to do what `@live` does, it's just not a particularly sensible thing to do.

I also completely disagree that what `@live` does is somehow equivalent to "a borrow checker working in D" comparing to standard expectations by a competent user.

> When I embarked on ImportC, I got the same response.

This is not true, I was on board with ImportC.
https://forum.dlang.org/post/skmhil$p8n$1@digitalmars.com

> Until suddenly it became a major asset for D.

In addition to it becoming a minor liability due to the temptation of copying over the bitfields implementation to D proper. :o)

> I was just more willing to push through with it.

It's just not true that `@live` would be good if you prioritized it over ImportC. It's a fundamentally flawed design.

On Sunday, 11 May 2025 at 18:23:56 UTC, Walter Bright wrote:
> On 5/11/2025 5:32 AM, Timon Gehr wrote:
>> On 5/10/25 06:13, Walter Bright wrote:
>>> The @live design was done in a manner to not need any new syntax - it is an extra layer of error checking.
>> 
>> That would be giving too much credit.
>
> This is why I stopped working on D's borrow checker. It's all been relentlessly negative. But I did get it to the point where it proved that a borrow checker can work in D with zero changes to the syntax (except marking a function as @live), and I'm happy about that.

The reason for the negativity is that people do not want "a borrow checker." What they want is more powerful safety analysis. A borrow checker is merely one possible means of achieving that goal.

In business terms, this is a failure of "product-market fit." You are supplying something that there is no demand for. Even if it works perfectly, nobody is going to buy it.

On Sunday, 11 May 2025 at 18:23:56 UTC, Walter Bright wrote:
>
> This is why I stopped working on D's borrow checker. It's all been relentlessly negative.

At some point when someone won't listen and every other option to convince them has been tried, the only option is to get upset.

On Sunday, 11 May 2025 at 18:23:56 UTC, Walter Bright wrote:
> On 5/11/2025 5:32 AM, Timon Gehr wrote:
>> On 5/10/25 06:13, Walter Bright wrote:
>>> The @live design was done in a manner to not need any new syntax - it is an extra layer of error checking.
>> 
>> That would be giving too much credit.
>
> This is why I stopped working on D's borrow checker. It's all been relentlessly negative.

Isn't that the point of negative feedback? I mean people say "yeah thats crap, we dont want it" so you stop working on it.

The system works!

Might help to find a way to figure it out sooner tho, maybe some kind of proposal system where people could critique it before you waste your time doing all that work?

On 12/05/2025 7:58 AM, Timon Gehr wrote:
>     It's all been relentlessly negative.
> 
> Well, sorry, this is not fun for me.

It has long since crossed over into "just implement it" territory for energy reasons for me.

On 5/11/2025 2:01 PM, claptrap wrote:
> Might help to find a way to figure it out sooner tho, maybe some kind of proposal system where people could critique it before you waste your time doing all that work?

Presenting a working solution is more effective than a proposal.

On Mon, 12 May 2025 at 03:55, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 5/10/2025 9:07 PM, Manu wrote:
> > I tested that and it didn't work for me. Maybe my test was faulty
> somehow since
> > I was working through numerous combinations, I'll try it again...
>
>
> I just tried it again, with the same result.
>

__gshared int* g;
void test(scope int* x)
{
    g = x;
}

I just compiled this with -dip1000, and it compiles... This looks like an escape to me! What have I misunderstood here?