Is @safe still a work-in-progress?

[Walter Bright]

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.