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
