On 7/9/2014 8:12 PM, Timon Gehr wrote:
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){ ... }

What does that do?


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

This seems awfully complicated.


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


Reply via email to