On 10/12/15 1:44 AM, deadalnix wrote:
On Sunday, 11 October 2015 at 20:35:05 UTC, Andrei Alexandrescu wrote:
Could you please point to the document you have already written?
For instance, we had a discussion with Walter and Mark that eventually
yielded DIP25. In there, I made the following proposal :
http://pastebin.com/LMkuTbgN
This is an unstructured text. Could you please use it as a basis for a
formal proposal?
I made several other very detailed proposal.
Where are they?
Other did. It's not about
me here. Others simply abandoned as far as I can tell. I'm just a
stubborn idiot.
At this point it would be great to just keep it calm and reduce
inflammation. It won't achieve anything.
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.
It is indeed the simplest. However, experiences that have been made and
discussed in the forum showed it was often too simple to be really
useful. I cited example of this, namely the RCArray thing and the
existence of DIP74.
I don't think the simplicity argument holds water in general as long as
we don't have the whole thing. DIP25 + DIP74 + ... must be measured
against the alternative.
What is the alternative? Some handwaving asking to do ownership a la
Rust cannot be analyzed.
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.
No that is inaccurate. I think I have evidence that it won't be taken
seriously. To start with, there are already several DIP on the subject
and they are not discussed at ALL. Namely :
http://wiki.dlang.org/DIP35
http://wiki.dlang.org/DIP36
http://wiki.dlang.org/DIP69
http://wiki.dlang.org/DIP71
These do not even register as a blip on the radar. I don't see how
adding my to the pile would change anything.
Creating a DIP is no guarantee it will be approved, or discussed
immediately. These in particular - I've been over most. I think DIP35 is
not good. DIP36 I didn't look at yet, but was aware of it and will
definitely do. DIP69 is obviously known to me because my name is on it.
DIP71 is very sketchy and is not in reviewable form.
There are not considered because DIP25 is "simpler" and you and Walter
"like it". As long as nothing changes here, there is really no point in
wasting my time.
That is a fair assessment. Basically I believe DIP25 is good language
design, and I have evidence for it. The evidence you showed failed to
convince me the design is a hack, and yelling at me is unlikely to help.
Please decide as you find fit. At some point it is clear that several
language designers will disagree on estimating the quality of something.
So I'm not sure how we can move forward from here. If you want to
discuss DIP74, great, it can be discussed because it exists. My
personal opinion on DIP74 is it has holes and corner cases so it seems
it doesn't quite hit the spot. One option is to make it work, another
is to take a different attack on the problem. But we need the
appropriate DIP.
Let's start by the beginning: what good design was enabled by DIP25 ? As
long as none is presented, we can't consider it a success.
Probably git grep in phobos may be a good starting point.
Andrei
