[Dlang-internal] DIP1000 discussion and testing

[Walter Bright via Dlang-internal]

On 10/23/2016 11:49 PM, Dicebot wrote:
> On 10/24/2016 05:29 AM, Walter Bright wrote:
>> On 10/22/2016 3:50 PM, Dicebot wrote:
>>> Beauty of borrowing is that it allows to to inc/dec skipping with no
>>> special RC support from compiler and works the very same for stack
>>> allocated data. What you are going at is simply replacing GC with
>>> (compiler enhanced) RC and that is not good at all.
>>
>> I don't see why supporting something beyond RC and GC is necessary.
>
> Both GC and RC are forms of automatic memory management with unavoidable
> associated overhead. Both have their uses but are unacceptable in most
> of the system code. Which means that would would either need to
> duplicate all Phobos/druntime functions to work with both RC and plain
> pointers or it will become even less suitable for low level code than it
> is now.

I'm afraid that is a bit vague. Can you give a more concrete example?


> The problem is DIP1000 is a lie. I started to rewrite it to match your
> implemented semantics but that would simply result in throwing much of
> its content away. Some of crucial things DIP1000 promises to deliver but
> are not possible with design as in https://github.com/dlang/dmd/pull/5972 :
>
> - @system code like std.internal.scopebuffer can be made @safe
> - reference counting systems need not adjust the count when passing
> references that do not escape
>
> That means that any counter-proposal that actually allows to do those
> things would already be considerably better.
>
> Now, I do agree that we don't want to go with amount of complexity Rust
> has. Something that makes basic idioms possible at 10% of complexity
> price would be a much better trade-off. Thus I'd propose to keep most of
> the stuff in DIP1000 as it is (including non-transitivity), but
> enhance/tweak lifetime rules, for example:
>
> - allow taking address of a `ref` and define lifetime of such expression
> to be same of `ref` lifetime

Again, why? Why can't the function return by 'ref'?


> - `return scope` of a struct methods binds returns value lifetime to one
> of the struct instance itself, not composition of its fields

'ref' return already does that.


> It is of similar complexity as existing proposal but is good enough to
> allow design patterns I have been trying to do.

Your design patterns all hinge on requiring conversion of a ref to a *. Why is 
this necessary, as opposed to using return by 'ref' ?


>> At some point we need to move forward. We are already years late.
>> Another month has slipped by.
> Current implementation does not bring us closer to feature rich
> compiler-verified safety in any way.

The numerous safety bugs it corrects, some reported by you, argues otherwise.


> What is even worse, going with it
> will close the option of using same syntax for something better and we
> will be stuck with it forever.
>
> I have a feeling that you completely misunderstand why Rust system has
> all the hype. Would it help if I explained some of compiler-verified
> safety patterns there? I have put some time into studying Rust last year.

Your understanding of Rust is likely better than mine. But I do know (and Rust 
documentation says this) that one has to rethink design patterns in order to 
work with the borrow checker, it cannot just be slapped onto any existing 
pattern, even if that pattern is correct. Trying to implement a Rust pattern in 
D is likely to be incorrect as well.


>> I am also not convinced that you cannot do what you want to do with
>> DIP1000. I do not understand why it is necessary to return the address
>> of a value passed by ref, when one can return by ref.
>
> You are author of the proposal. It is your obligation to convince
> everyone that it is possible to do what you claim possible, not mine. If
> you think it can be done, show me the code.

I don't know what you have in mind. I already showed you how it can help with 
unique pointers. The only concrete issue you have with it is that ref cannot be 
returned by *. I ask again why is this important as opposed to returning by ref.