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/xjhvpmjrlwhhgeqyo...@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/otejdbgnhmyvbyaxa...@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.
