On Wednesday, 10 April 2013 at 09:31:22 UTC, Dicebot wrote:
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.
I would say, if you are going to use a keyword ('scope' in this
case) to mean something, and there are other uses of the keyword
which are also useful, you have to decide first if there is a
conflict, and second how it should be resolved. In my opinion
there is a conflict. The only existing definition of 'scope'
parameters we have suggets that it means the parameter may not be
escaped. It turns out that such a parameter is possibly necessary
to successfully seal references in D. If a different proposal
wants to use the word to mean something else, then it's important
to decide either that two different features require two
different parameter attributes (DIP36 understands this, and
proposes several alternate possibilities to use), or that each
feature can always automatically include the other feature
without any problems (possible but see my other responses), or
that only one feature is truly important enough to be included in
the language, allowing you to disregard the other feature
entirely.
