[Dlang-internal] DIP1000 discussion and testing

[Dicebot via Dlang-internal]

On 10/21/2016 09:04 AM, Walter Bright wrote:
> On 10/20/2016 3:52 PM, Dicebot wrote:
>> So far you have only given answers regarding technical trivialities
> 
> That is true, but we must reach mutual understanding on how those
> trivialities work before we can do more. So far, we have not.

Well, it doesn't work that way. So far all you explanations made zero
sense until I have only finally understood what your intentions are
thanks to next answer ..

> 1. D has no notion of "borrowing" and describing DIP1000 in those terms
> is going to mislead. There is no "borrow checker".
> 
> 2. This design has nothing in common with Rust's design. Any notions
> brought from Rust will mislead.
> 
> 3. The design utterly relies on a 'ref' value not being returned as a
> '*'. Any attempts to circumvent this will lose the checking. The
> rationale for this is a dramatic simplification of the design.
> 
> 4. The effects of 'ref' and 'scope' are not transitive.
> 
> 5. 'scope' is ignored if applied to a type with no indirections (this is
> necessary to support generic code).
> 
> 6. What does 'return ref scope' mean? If the function returns by ref,
> then the 'return' applies to the 'ref'. Otherwise, it applies to the
> 'scope'.
> 
> 7. 'scope' applies to the value of a type, 'ref' applies to its address.
> Your example failed to apply 'scope' to the 'int*' return, because the
> struct had no pointer types in it.
> 
> 8. A container passed by 'ref' can return a 'ref' to the container's
> value or indirect contents, or by '*' to indirect contents, but it
> cannot return the address of the container by '*'. (This is a
> restatement of item 3.)

.. and means two things for me:

1) DIP1000 has to be changes a lot because it doesn't list most of those
limitation, leading to natural conclusion that borrowing can be emulated
as a user code concept. Most importantly, the statement "The design
utterly relies on a 'ref' value not being returned as a '*'. Any
attempts to circumvent this will lose the checking" is not mentioned at all.

2) The whole thing is very disappointing and won't revive dead body of
@safe as I hoped it will. It won't allow to fix `Unique`, won't enable
new RNG design Joe has been going, won't allow easy skipping of
reference count inc/dec - the list goes on.

Leaving aside issue 2, I'd like to give a try at updating DIP1000 this
weekend to be more in match with what you have just explained.

-------------- 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/20161021/97706b90/attachment.sig>