On 10/12/15 2:39 AM, Timon Gehr wrote:
> On 10/11/2015 10:35 PM, Andrei Alexandrescu wrote:
>> ...
>>
>> 1. You say that DIP25 is a failure. More so, you demand that is admitted
>> without evidence.
>
> FWIW, DIP25 is insufficiently formal and/or incorrect.

That I agree with. We need to get a lot better at making precise DIPs.

> I have been able to find those holes in the implementation pretty
> quickly (I'll also put them to bugzilla):

Thanks. That's great work!


Andrei

On Monday, 12 October 2015 at 06:02:47 UTC, Andrei Alexandrescu wrote:
>> 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.
>

If you are wondering why I'm inflammatory, here you go. You are pulling me the old prove a negative trick. You have good evidence that DIP25 is good design ? Good, because I have none. And that's my proof. As long as I have no evidence that DIP25 is good, DIP25 is bad.

> Probably git grep in phobos may be a good starting point.
>

I don't think grepping for return will have a good noise to signal ratio. You also mentioned several time that you have good evidence that DIP25 rox. Yet, every time you post that without any evidence, I'm a bit more convinced that none exists.

On 10/12/15 7:19 AM, Jonathan M Davis wrote:
> On Monday, 12 October 2015 at 03:59:04 UTC, Marco Leise wrote:
>> Am Sun, 11 Oct 2015 07:32:26 +0000
>> schrieb deadalnix <deadalnix@gmail.com>:
>>
>>> In C++, you need to assume things are shared, and, as such, use
>>> thread safe inc/dec . That means compiler won't be able to optimize
>>> them. D can do better as sharedness is part of the type system.
>>
>> With the little nag that `shared` itself is not fleshed out.
>
> Well, it really should be better fleshed out, but the reality of the
> matter is that it actually works pretty well as it is. The problem is
> primarily that it's a pain to use - and to a certain extent, that's
> actually a good thing, but it does make it harder to use correctly.

Yah, I'd like to make "finalizing the language" a priority going forward, and finalizing shared is a big topic. It's hard to present to the world a language with fuzzy corners. -- Andrei

On 10/12/15 10:21 AM, deadalnix wrote:
> On Monday, 12 October 2015 at 06:02:47 UTC, Andrei Alexandrescu wrote:
>>> 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.
>>
>
> If you are wondering why I'm inflammatory, here you go. You are pulling
> me the old prove a negative trick. You have good evidence that DIP25 is
> good design ? Good, because I have none. And that's my proof. As long as
> I have no evidence that DIP25 is good, DIP25 is bad.

Instead of assuming my purpose here is to pull tricks on you and manipulate the dialog politically, it's more productive to just stick to the technical discussion. I only started the dialog to get more informed about technical things.

>> Probably git grep in phobos may be a good starting point.
>>
>
> I don't think grepping for return will have a good noise to signal
> ratio.

Sorry, I meant to git grep for "return ref".

> You also mentioned several time that you have good evidence that
> DIP25 rox. Yet, every time you post that without any evidence, I'm a bit
> more convinced that none exists.

The motivation is in the document and follows many discussions derived from it. It's all about functions and particularly member functions returning up references to data safely.

Amaury, you and Timon are probably the most competent PL theorists in this forum. He did great work: found real problems with DIP25 that need to be looked at. In that light, spending time protesting and yelling figuratively at people is a distinctly unproductive way to spend your time as a very talented contributor. Do great work. It will be recognized. Don't point me at your past posts. They are not great work and you know it. Don't point me at those related DIPs. They are not great work and you know it. Don't find reasons to not do great work because it'll be wasted on my ego. Do great work and you will prevail.

This tone of discussion has carried its course. I'm done arguing so if you want to continue arguing, great - last word is yours. In the recent times I've done my best to reduce my participation to unproductive discussions in forums, and the added perspective and time for real work have been very valuable. I suggest everyone to try it.


Andrei

On Monday, 12 October 2015 at 07:44:47 UTC, Andrei Alexandrescu wrote:
> Instead of assuming my purpose here is to pull tricks on you and manipulate the dialog politically, it's more productive to just stick to the technical discussion. I only started the dialog to get more informed about technical things.
>

I'm not assuming this. I'm fairly confident that you have the best intention for D in mind rather than winning internet debate points. So do I.

Still you are pulling the above mentioned trick. i don't think you did it on purpose. I think you did it because you are convinced that DIP25 is great, in fact so convinced that you take thing for granted that aren't.

It is a natural tendency we all have to lower the standard of evidence we require when we are already convinced. You, me, everybody.

>> I don't think grepping for return will have a good noise to signal
>> ratio.
>
> Sorry, I meant to git grep for "return ref".
>

So I did. I found 2 uses of return ref in current master that aren't in unitests. These are both related to unicode decoding. These are legit use of DIP25, and I recognize their value.

Still I don't think this is valuable enough to have its own syntax. I also, on the other hand presented cases of things that people thought could be done with DIP25, but ended up to be either not possible or to have a disappointingly low complexity to added value ratio.

I can agree on something: DIP25 is the right direction. But it is too little to pay for itself and I haven't seen anything here that would suggest otherwize.

>> You also mentioned several time that you have good evidence that
>> DIP25 rox. Yet, every time you post that without any evidence, I'm a bit
>> more convinced that none exists.
>
> The motivation is in the document and follows many discussions derived from it. It's all about functions and particularly member functions returning up references to data safely.
>
> Amaury, you and Timon are probably the most competent PL theorists in this forum. He did great work: found real problems with DIP25 that need to be looked at. In that light, spending time protesting and yelling figuratively at people is a distinctly unproductive way to spend your time as a very talented contributor. Do great work. It will be recognized. Don't point me at your past posts. They are not great work and you know it. Don't point me at those related DIPs. They are not great work and you know it. Don't find reasons to not do great work because it'll be wasted on my ego. Do great work and you will prevail.
>
> This tone of discussion has carried its course. I'm done arguing so if you want to continue arguing, great - last word is yours. In the recent times I've done my best to reduce my participation to unproductive discussions in forums, and the added perspective and time for real work have been very valuable. I suggest everyone to try it.
>

Ok, I'll write a DIP.

Am Mon, 12 Oct 2015 10:44:47 +0300
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> >> Probably git grep in phobos may be a good starting point.
> >> 
> >
> > I don't think grepping for return will have a good noise to signal ratio.
> 
> Sorry, I meant to git grep for "return ref".

AFAICS this returns only 6 results:

// false positive
std/functional.d:        static ref int func_ref() { return refvar; }

// test functions for return ref
std/functional.d:    ref int foo(return ref int a) { return a; }
std/traits.d:        void test(scope int, ref int, out int, lazy
  int, int, return ref int) { }
std/traits.d:        ref const(Inner[string]) retfunc( return ref Inner
var1 );



// Real examples

// I don't see the advantage here. Simple example, private API anyway,
// not using @safe
std/stdio.d:    private char[] takeFront(return ref char[4] buf)

// A good, but very simple example
std/utf.d:wchar[] toUTF16(return ref wchar[2] buf, dchar c) nothrow
  @nogc @safe



So AFAICS it's not used much and the use cases are rather simple compared to RCSlice / RC!T / Unique and all these complex cases that have been discussed related to ownership.

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.

On 10/12/15 4:38 PM, Marc Schütz wrote:
> 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.

Yes, I agree. Experience with Rust is still young, but there seems to have already been a backlash; programmers try it and it's just too arcane to use in constant preoccupation about them ownership rules.

Copying linear types and going whole-hog stealing the ownership system from Rust doesn't sound like the best strategy to Walter and myself. At least one PL researcher whose opinion I trust believes linear types don't have a future.

D has its own context and its own approach to matters. I believe creative solutions are possible that achieve much of what we need without going the Rust way, which seems not appropriate for us.

I agree that DIP74 has problems; it has had several corner cases that needed patching. That's a signal DIP74 doesn't quite cut with the grain. What we need here is good creative work that takes us where we want to be without breaking the complexity bank.

BTW where we want to be is: expressive reference counting without loss of @safe-ty and hopefully good uniqueness control again with @safe-ty and possibly a bit of compiler help.


Andrei

On Monday, 12 October 2015 at 07:21:58 UTC, deadalnix wrote:
> On Monday, 12 October 2015 at 06:02:47 UTC, Andrei Alexandrescu wrote:
>>> 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.
>>
>
> If you are wondering why I'm inflammatory, here you go. You are pulling me the old prove a negative trick. You have good evidence that DIP25 is good design ? Good, because I have none. And that's my proof. As long as I have no evidence that DIP25 is good, DIP25 is bad.
>

I've noticed that you seem to be quite arrogant. Usually it is a result of ignorance. Your statement basically proves that.

Maybe you should take a break from programming for a while and work on your attitude?

While you have no proof of this, If you do a little soul searching you'll find that the world doesn't revolve around you. Put down your toys and get out of the sandbox and you might learn something!

On Monday, 12 October 2015 at 16:56:27 UTC, Jacob wrote:
> I've noticed that you seem to be quite arrogant. Usually it is a result of ignorance. Your statement basically proves that.
>
> Maybe you should take a break from programming for a while and work on your attitude?
>
> While you have no proof of this, If you do a little soul searching you'll find that the world doesn't revolve around you. Put down your toys and get out of the sandbox and you might learn something!

Dude you are kind of being a jerk. He's just arguing against, rather passionately, a design decision he thinks is poor. It values no one if individuals remain quiet and conform. Certainly not the leadership. What you see as arrogance is really just passion.