Concern about the ref return argument and scope

[Zach the Mystic via Digitalmars-d]

On Wednesday, 28 January 2015 at 08:32:33 UTC, Walter Bright 
wrote:
> On 1/28/2015 12:02 AM, deadalnix wrote:
>> On Wednesday, 28 January 2015 at 07:55:22 UTC, Walter Bright 
>> wrote:
>>> On 1/27/2015 8:57 PM, deadalnix wrote:
>>>> For ref return, we can still
>>>> make it safe by defining the lifetime of the ref return as 
>>>> the intersection of
>>>> the lifetime of the ref parameters and call it a day. As far 
>>>> as I can tell, this
>>>> cover the vast majority of cases.
>>>
>>> The trouble with that is when you *do* need to return a ref 
>>> that is unrelated
>>> to the ref parameters, there will be no way to do it.
>>
>> True, but unless you are returning a ref to a static variable, 
>> it has to come
>> from an explicit or an implicit argument.
>
> Or a ref to a new'd object. Or a ref to what the ref parameter 
> pointed to. (ref is not transitive)
>
>
>> And the solution to this is not an ad hoc way to specify each 
>> useful lifetime we
>> can think of, but have sensible defaults and a generic way to 
>> specify them when
>> default fall short.
>
> I believe DIP25 has the most sensible default that results in 
> the least disruption. Besides, it makes more sense to say:
>
>    "I am returning this parameter"
>
> than:
>
>    "I am not returning this parameter, or that one, or this 
> other one, either"
>
> Of course, there is a bit of leap of faith in the "least 
> disruption" thing, only some experience with the feature will 
> tell for sure.

I'm totally on board with this. In fact, to me 'ref' has nothing 
to do with it. If a parameter contains a pointer in safe code, 
you need to know what is done with it. I deliberately created 
DIP71 without 'ref' to illustrate my point:

http://forum.dlang.org/post/xjhvpmjrlwhhgeqyoipv@forum.dlang.org

As far as disruption is concerned, my current philosophy is that 
all covariant attribute inference should be so thorough that you 
only have to add attributes if you *want* them, for your own 
personal purposes. You should never need them. I think the 
overall linking mechanism should be upgraded to allow reliable 
connections between the auto-generated `.di` files and the 
binaries they were generated for. `.di` files may be littered 
with attributes, but normal user code need not be. Unless you 
*want* them for code clarity purposes.

I have no claim to know how this will actually play out. I won't 
pretend I know all the ins and outs of linking and `.di` file 
generation. But here's Dicebot's description of his forthcoming 
DIP on this matter:

http://forum.dlang.org/post/otejdbgnhmyvbyaxatsk@forum.dlang.org

If the problem can be solved at the linking phase, inference can 
be assumed, no one will be burdened with marking their code 
involuntarily, and code can be completely safe. I still have to 
write an article on how I view reference safety. I haven't really 
thought about ownership, but I'm sure reference safety is an 
essential foundation for ownership.