On 07/10/2014 08:59 AM, Walter Bright wrote:
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?
...
...
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?
...
It's a mechanism for compile-time parameters with homogeneous
translation. (It is sufficient if it supports lifetimes at this point,
but inout could profit as well.)
We get a (potentially) differently typed function 'foo' for every
argument `A', but it is the same function at runtime, hence this works
for virtual methods and function pointers/delegates.
- Lifetime parameters. (it's more future-proof if they are not
introduced by
simple identifiers.)
Eg.: void foo[lifetime lt](int x){ ... }
??
...
This introduces a compile-time parameter that is a lifetime. (It's not a
use case, just an example.)
- 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.
...
Are you talking about the concept, the examples, or just the last
example? What makes it seem complicated?
