DIP74 - where is at?

[Andrei Alexandrescu via Digitalmars-d]

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