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