Is @safe still a work-in-progress?

[Steven Schveighoffer]

On 8/23/18 9:32 AM, Steven Schveighoffer wrote:
> On 8/23/18 4:58 AM, Walter Bright wrote:
>> On 8/22/2018 6:50 AM, Steven Schveighoffer wrote:
>>> As for things being made "more flexible in the future" this basically 
>>> translates to code breakage. For example, if you are depending on 
>>> only the first parameter being considered the "return" value, and all 
>>> of a sudden it changes to encompass all your parameters, your 
>>> existing code may fail to compile, even if it's correctly safe and 
>>> properly annotated.
>>
>> It's a good point. But I don't see an obvious use case for considering 
>> all the ref parameters as being returns.
> 
> You would have to consider the shortest liftetime and assume everything 
> goes there. It would restrict your legitimate calls. Only mitigating 
> factor may be if you take the ones you aren't going to modify as const 
> or inout.

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