Concern about the ref return argument and scope

[Walter Bright via Digitalmars-d]

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.