Opportunities for D

[Walter Bright via Digitalmars-d]

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