Is @safe still a work-in-progress?
Chris M.
chrismohrfeld at comcast.net
Thu Aug 23 15:48:00 UTC 2018
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.
More information about the Digitalmars-d
mailing list