On Thursday, 23 August 2018 at 15:14:07 UTC, Steven Schveighoffer
wrote:
On 8/23/18 9:32 AM, Steven Schveighoffer wrote:
[...]
Actually, thinking about this, the shortest lifetime is
dictated by how it is called, so there is no valid way to
determine which one makes sense when compiling the function.
In order for this to work, you'd have to attribute it somehow.
I can see that is likely going to be way more cumbersome than
it's worth.
If I had to design a specific way to allow the common case to
be easy, but still provide a mechanism for the uncommon cases,
I would say:
1. define a compiler-recognized attribute (e.g. @__sink).
2. If @__sink is applied to any parameter, that is effectively
the return value.
3. In the absence of a @__sink designation on
non-void-returning functions, it applies to the return value.
4. In the absence of a @__sink designation on void returning
functions, it applies to the first parameter.
5. Inference of @__sink happens even on non-templates.
6. If @__sink is attributed on multiple parameters, you assume
all return parameters are assigned to all @__sink parameters
for the purposes of verifying lifetimes are not exceeded.
Ugly to specify, but might actually be pretty non-intrusive to
use.
-Steve
This is more a general reply to the thread.
If I think I'm getting a good grasp on the issue here, it seems
like something Rust already solved with lifetime annotations.
Could they or something similar be leveraged for D as well?
https://doc.rust-lang.org/1.9.0/book/lifetimes.html
Current solution just seems too specific and very restrictive.
