Opportunities for D

[Timon Gehr via Digitalmars-d]

On 07/10/2014 07:41 AM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jul 10, 2014 at 05:12:23AM +0200, Timon Gehr via Digitalmars-d wrote:
> [...]
>> - 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 is starting to look like some parts of my 'scope' proposal in
> another part of this thread.
>
> I'm wondering if it makes sense to simplify lifetimes

(This is not complicated.)

> by tying them to lexical context

They are.

> rather than using explicit annotations?

Suitable rules can be added to automatically do some sensible thing by 
default, but I don't think it makes sense to try and guess suitable 
lifetimes just by staring at a function signature in the general case.

> Being able to
> specify explicit lifetimes seem a bit excessive to me, but perhaps you
> have a use case in mind that I'm not aware of?
>...

If lifetimes cannot transcend function invocations, this is a serious 
limitation, don't you agree? How would you do e.g. an identity function 
on a borrowed pointer type, to name a simple example?