Is @safe still a work-in-progress?

[Steven Schveighoffer]

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