On Sunday, 11 October 2015 at 20:35:05 UTC, Andrei Alexandrescu
wrote:
On 10/11/15 9:57 PM, deadalnix wrote:
On Sunday, 11 October 2015 at 18:52:44 UTC, deadalnix wrote:
On Sunday, 11 October 2015 at 13:51:18 UTC, Andrei
Alexandrescu wrote:
Walter and I are happy with DIP25, and the fact of the
matter is we
weren't surprised more complementary work is needed. So no,
I won't
acknowledge what I don't believe.
That is an empty statement. What is there to be happy about ?
Also the complementary argument pretty much destroy the best
argument
you and Walter made for DIP25 : it is simple. I mean, one
need to look
at the big picture. DIP25 + complementary addition is not
simple anymore.
I'd say the one way to get things looked at seriously is to
create a
DIP. That's no guarantee it will be accepted but there is a
guarantee
that our chat at DConf is not sufficient even as a basis for
further
study.
Yeah there are IRL discussion, there are many posts in the
forum,
there are by mail discussions at DIP25 creation time, there
are at
least one DIP already.
The only rebuttal to all of this is "Walter and I are happy
with
DIP25, and the fact of the matter", while everybody else is
wondering
what there is to be happy about.
Also, I'm sorry but there is no me writing once again a
document about
what alternative are possible.
Could you please point to the document you have already written?
Spending hours to write documents so that
one is answered something along the line of "we are happy with
the other
thing, but we can't give any reason why" is something I've
engaged in
several time in already, and has no desire to indulge into
this if I
have reason to think the same will happen. Your answer here
are telling
me one thing: it won't be taken seriously.
There's a bit of a stalemate here. So we have:
1. You say that DIP25 is a failure. More so, you demand that is
admitted without evidence. What I see is a feature that solves
one problem, and solves it well: annotating a function that
returns a reference to its argument. The syntactic cost is low,
the impact on existing code is small, and the impact on safety
is positive. Walter and I think it is the simplest solution of
all considered.
Except that it isn't a solution to the problems it was claimed to
solve. For example, Walter tried to build a safe RCArray
implementation with it, and it turned out that it's still unsafe
in the presence of aliasing.
I still see DIP25 as going in the right direction, but it from my
POV it must at least a) be usable with all kinds of references,
not just `ref`, and without double indirections, b) solve the
problems with global variables (probably easy, just make them
unsafe), and c) keep track of aliases or otherwise handle them
correctly to avoid the RCArray problems.
(An additional nice-to-have feature would be a method to make a
variable inaccessible that can be enforced at compile time,
because that will enable various uniqueness-related things. This
is closely related, but not a necessity.)
2. You refuse to write a DIP under the assumption it will not
be taken seriously. Conversely if you do write a DIP there is
an expectation it will be approved just because you put work in
it. I don't think rewarding work is the right way to go. We
need to reward good work. The "work" part (i.e. a DIP) is a
prerequisite; you can't demand to implement a complex feature
based on posts and discussions.
The problem is the signals we get from you and Walter. From
various posts (or lack of response to certain questions) and the
way you've treated this entire topic so far, I got the impression
that you both are opposed to anything similar to Rust's approach.
Unfortunately, we know that Rust's approach (or other solutions
involving linear type systems) is the only thing that can provide
a compiler-verifiable free-at-runtime solution. That's the real
stalemate as I see it. I hope you see how that's not particularly
motivating.
