Re: Opportunities for D

[Timon Gehr via Digitalmars-d]

On 07/10/2014 02:39 AM, Walter Bright wrote:
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

I think we are basically nowhere. Borrowing is about controlling lifetimes.

2. decide where we want to be

I don't know, but I assume it would have to be competitive with what 
Rust provides.

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

Roughly, but not with 'ref'. It is also an issue of syntax at this 
point. I think we should get at least the basics fixed there before 
talking in-depth about semantics. (In any case, I still have one DIP 
pending in an unacceptable state that I couldn't find the time to write 
down properly yet.)

Fundamentally, we need syntax for (examples provided for illustration, 
those are not proposals):

- Parametric polymorphism

Eg.: void foo[A](int x){ ... }


- Lifetime parameters. (it's more future-proof if they are not 
introduced by simple identifiers.)

Eg.: void foo[lifetime lt](int x){ ... }


- Attaching a lifetime to a pointer, class reference, ref argument.

Eg.: void foo[lifetime lt](int scope(lt)* x){ ...}
     void foo[lifetime lt](scope(lt) C c){ ... }
     void foo[lifetime lt](scope(lt) ref int x){ ... }
     void foo[lifetime lt1,lifetime lt2](scope(lt1)(C)scope(lt2)[] a){ 
... }

(The last example talks about a slice where the array memory has 
different lifetimes than the class instances it contains.)

- Lifetime intersection:

Eg.: scope(lt1&lt2)Tuple!(int*,int*) pair[lifetime lt1,lifetime lt2](int 
scope(lt1)* p1, int scope(lt1)* p2){ ... }

(It can alternatively be done only implicitly at function boundaries.)


- Specifying the lifetime of a struct/class upon construction:

Eg.: struct S[lifetime lt1,lifetime lt2]{
         ...
         this(int scope(lt1)* x, int scope(lt2)* y)scope(lt1&lt2){ ... }
     }

...

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

Rationale?

null

??

My point exactly. http://xkcd.com/641/

Also, there will be the usual problems with subtyping.