[Dlang-internal] DIP1000 discussion and testing

[Walter Bright via Dlang-internal]

On 10/20/2016 3:52 PM, Dicebot wrote:
> On 10/21/2016 12:36 AM, Walter Bright wrote:
>> On 10/20/2016 12:27 PM, Dicebot wrote:
>>> If I was to judge by available test cases only, I would have decided
>>> DIP1000 is waste of time and brings nothing useful to the table. They
>>> are terrible in showing implementation goals being low level regression
>>> testing artifacts.
>>>
>>> Really, do you think anyone will ever be impressed seeing code like
>>> `int* foo1(return scope int* p) { return p; }`? DIP1000 as defined can
>>> allow much more interesting things and tests should show that too, not
>>> just synthetic artifacts.
>>
>> They are not meant to impress people, nor are they regression tests.
>> They illustrate closing of existing safety holes.
>>
>>   int* bar()
>>   {
>>     int p;
>>     return foo1(&p);
>>   }
>>
>> is a currently undetected bug. DIP1000 detects it. DIP1000 also closes
>> safety bugs that you posted to Bugzilla (listed in the PR for it).
>
> Yes, but that is not enough for such a major change. If we want to
> finally implement `scope`, it has to be _awesome_, plain good is not
> good enough.

Actually, I consider it a minor change, and I *want* the fix for this bug to be 
as minor as possible. Furthermore, Andrei, I, Bartosz, and others have struggled 
with this particular problem for about 10 years. This is the best (and simplest, 
by far) solution we've come up with. If you can think of a better one, I'm 
interested.


>> Yes, the test cases are very minimal. But understanding them is
>> necessary in order to understand more complex cases - I don't think
>> we've gotten anywhere by using complex cases to understand the mechanics
>> of it.
>
> Can you give a clear answer regarding borrowing snippets I am posting?
> Like one of:
>
> - Such idioms are not supposed to work with DIP1000 at all (why?) and
> you only want to focus on fixing existing @safe holes
> - It is supposed to work, but I am doing it wrong (please show how to
> write it in that case)
> - It is supposed to work, but bugs need fixing
> - It is supposed to work, but some parts will be implemented later
> (which ones?)
>
> 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.


> without taking actual example to the heart.

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