Prototype of Ownership/Borrowing System for D
timon.gehr at gmx.ch
Sun Nov 24 14:07:31 UTC 2019
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. :)
> 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
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.
More information about the Digitalmars-d