Prototype of Ownership/Borrowing System for D

[Timon Gehr]

On 24.11.19 03:33, mipri wrote:
> On Sunday, 24 November 2019 at 02:10:41 UTC, mipri wrote:
>> It's really hard to see you as only having sincere technical
>> objections to @live after reading this.
> 
> Even after rewriting this so many times,

Rewriting is a waste of time, because I respond to what you say, not how 
you say it. If you find yourself in such a situation, it can help to 
think about whether you actually want to say it. My drafts folder is 
overflowing with posts I never submitted.

> I reckon it still won't be received well.
> ...

I think a simple "I'm sorry, it wasn't my intention to question your 
motives" would have been more appropriate than predicting unreasonable 
animosity and implying it would be my fault. If I wanted to, I could 
choose to get offended by that just the same. :)

> So:
> 
> I'm actually very interested in criticisms of @live (I hope
> more people are testing it than is apparent from the posts
> here), and even of alternatives that won't happen. But I don't
> have a four-year degree with a major of "the last 300 years of
> your bitter disputes about language design", and every single
> post of yours has required that.

I don't think this is the case. In particular, the borrowing/ownership 
discussion is not very old.

> (I still have no idea what you
> could possibly mean with a remark like "It doesn't make
> @safe code any more expressive.")
> ...

It's a summary of some of the other points in the post.

@safe restricts code to be memory safe in a way that is checked by the 
compiler, such that only @trusted functions can be a potential source of 
memory unsafety in a @safe program. (Basically, @trusted functions are 
at the same level of trust as the compiler implementation of @safe, so 
that not everything at this level of trust has to be implemented in the 
compiler, which makes sense.)

If @live @safe code can interact arbitrarily with @safe code, @live 
@safe cannot establish that the invariants that @live attempts to 
preserve (every memory location has a unique mutable reference to it or 
many non-mutable references, pointers are not leaked, etc) actually 
hold. Therefore, we cannot use @live invariants to write @safe code 
whose safety depends on those invariants. This means @live does not 
improve the expressiveness of @safe code: it does not allow us to write 
new and interesting @safe code that we could not write before. Walter 
however claimed that @live enables safe manual memory management in 
@safe code

What I am complaining about is a discrepancy between the stated goals of 
@live and what it actually accomplishes. The goal is to close the gap, 
to keep the quality of D high. I believe this is Walter's sincere goal 
too, this is why he is asking for feedback in the first place.

My arguments are not very complicated, but necessarily a bit abstract, 
because Walter is not providing any concrete examples of @safe code that 
are helped by @live that I could then break immediately by applying that 
abstract reasoning. The burden of proof shouldn't even be on me, because 
if @live @safe indeed enables safe manual memory management, he can 
demonstrate it by providing a code example that I can't break.

> I realize it's tiresome to repeat things that you think are
> already established, though.

What's tiresome is when people keep responding with nonsense or personal 
attacks. I have no problem at all with people asking for additional 
details that I didn't think to provide, or let alone people responding 
with good points!

> Please feel free to disregard my input.
> 

I will disregard your personal attack, but I don't see any reason to 
disregard your input.