Opportunities for D

[Walter Bright via Digitalmars-d]

On 7/9/2014 5:24 PM, Timon Gehr wrote:
> On 07/09/2014 09:50 PM, Walter Bright wrote:
>> On 7/9/2014 7:37 AM, Timon Gehr wrote:
>>> On 07/08/2014 11:22 PM, Walter Bright wrote:
>>>> 3. 'ref' means 'borrowed', to use Rust's terminology
>>>> We're almost there with this. This means better escape analysis, too.
>>> What makes you think that 'ref' is a good match for this
>>> functionality, and how
>>> are we almost there with this?
>>
>> 'ref' is already used conventionally in such a manner as implying it is
>> borrowed. 'ref' pointers cannot be stored,
>
> Borrowed pointers can be stored in data structures and they can be reassigned.

My purpose in posting this is not "I have a design". I don't have a design. A 
design needs to be created:

1. assess where we are
2. decide where we want to be
3. have a design and a plan that gets there

There's no law that says D refs must be exactly like Rust borrowed. We can come 
up with a design that works best for D. D != Rust. Do you have a design in mind?


>> and one cannot take the address of a ref'd variable in @safe code.
>> ...
>
> Borrowed should also be enforced in @system code by default.
> Also, how do I borrow a class reference?

Address that in the design.


>>>> For those that want a non-nullable reference type. This should be doable
>>>> as a library type.
>>> No.
>>
>> Rationale?
>
> null

??