[Dlang-internal] DIP1000 discussion and testing

[Dicebot via Dlang-internal]

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.

>> Would you at least be willing to consider an alternative proposal before
>> `scope` branch is merged for release? I have a feeling that with
>> relatively few changes to DIP1000 rules we can both have the cookie and
>> eat it (i.e. get a way to express non-transitive borrowing), more in
>> spirit of original proposal by Marc.
> 
> It'd have to be a big improvement over DIP1000, without sacrificing easy
> use. I find Rust's system to be seriously restrictive, off-putting, and
> hear many reports of users fighting its borrow checker. (I have not
> written any Rust code myself.)

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
- `return scope` of a struct methods binds returns value lifetime to one
of the struct instance itself, not composition of its fields

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

> 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. 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.

> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/dlang-internal/attachments/20161024/407cff79/attachment.sig>