Opportunities for D

[Timon Gehr via Digitalmars-d]

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?