On Wednesday, 10 April 2013 at 09:26:38 UTC, Zach the Mystic
wrote:
On Wednesday, 10 April 2013 at 07:46:41 UTC, Dicebot wrote:
On Wednesday, 10 April 2013 at 01:40:49 UTC, Zach the Mystic
wrote:
I think for convenience the function must only be considered
unsafe if it does the above. Even returning the 'ref' is
@safe so long as the *caller* keeps track of what it passes
in, according to DIP25.
Safety of "ref" is not problem that this DIP tries to solve.
It should be solved with DIP25. Now ref is not safe (despite
the fact it pretends to) and it still won't be after DIP36
approval, not until issue is addressed in DIP25.
No need to mix it.
My proposed DIP35 uses 'scope' to enhance DIP25. I don't
believe DIP25 is really complete. 'scope' would help it a lot,
but that would give more meanings to 'scope' which are
potentially in conflict with it just meaning rvalue temp.
And how it is relevant to DIP36? It solves specific issue. It
provides some hints how other DIP may use new opportunities. It
is up to DIP25 and DIP35 to be built on top if this gets accepted
first. Or other way around.
DIPs are built in context for current language implementation,
not some potential other DIPs.
