DIP74 - where is at?

[Marc Schütz via Digitalmars-d]

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.