On 8/22/18 5:23 AM, Walter Bright wrote:
On 8/21/2018 6:07 PM, Mike Franklin wrote:
The proposed idea wants to make the first parameter, if it's `ref`,
special.
This is because Phobos is written with functions of the form:
void put(sink, parameters...)
which corresponds to:
sink.put(parameters...)
The two forms are fairly interchangeable, made more so by the Uniform
Function Call Syntax.
> Why not the first `ref` parameter regardless of whether it's the
absolute first in the list. Why not the last `ref` parameter? Why not
all `ref` parameters?
Good question. If this fairly restricted form solves the problems, then
there is no need for the more flexible form. Things can always be made
more flexible in the future, but tightening things can be pretty
disruptive. Hence, unless there is an obvious and fairly strong case
case for the flexibility, then it should be avoided for now.
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.
Or how about a member function that takes a ref parameter? Is `this` the
"return" or is the ref parameter the "return"?
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.
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.
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.
-Steve
