On 8/22/2018 6:50 AM, Steven Schveighoffer wrote:
What about:
size_t put(sink, parameters...)
Does this qualify as the sink being the "return" type? Obviously the real return
can't contain any references, so it trivially can be ruled out as the
destination of any escaping parameters.
Your reasoning is correct, but currently it only applies with 'void' return
types.
Or how about a member function that takes a ref parameter? Is `this` the
"return" or is the ref parameter the "return"?
`this` is the ref parameter. In particular, consider a constructor:
struct S {
int* p;
this(return scope int* p) { this.p = p; }
}
int i;
S s = S(&i);
This code appears in Phobos, and it is very reasonable to expect it to check as
safe.
My problem with the idea is that it is going to seem flaky -- we are using
convention to dictate what is actually the return parameter, vs. what
semantically happens inside the function. It's going to confuse anyone trying to
do it a different way. I've experienced this in the past with things like
toHash, where if you didn't define it with the exact signature, it wouldn't
actually be used.
I realize obviously, that `put` is already specified. But as I said in the bug
report, we should think twice about defining rules based solely on how Phobos
does things, and calling that the solution.
Phobos doesn't do this by accident. It's how constructors work (see above) and
how pipeline programming works.
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.
> I want to ensure Atila is successful with this. But that means Phobos has to
compile with dip1000. So I need to make it work.
I think it's a very worthy goal to make Phobos work, and a great proof of
concept for dip1000's veracity.
However, one-off rules just to make it work with existing code go against that
goal IMO. Rules that stand on their own I think will fare better than ones that
are loopholes to allow existing code to compile.
I couldn't come up with a better idea than this, and this one works.
