On Tuesday, 24 February 2015 at 19:20:37 UTC, Andrei Alexandrescu wrote:
>> Compared to what ?
>
> There is no comparison involved. The proposal is too complicated for what it does. -- Andrei

There is always a comparison involved. Comparison options includes:
 - Not solving some of the issues we have and call it a day.
 - Add simpler solution dedicated to each of these problems.

The problems we are talking about are:
 - safe RC
 - fast GC by using type qualifier guarantee.
 - less reliance on GC by producing less garbage.
 - enforcing type qualifier constraint.
 - enabling more code to be @nogc (especially exception)
 - being able to delegate the memory management policy to the user.
 - immutable and shared building.
 - manipulating object of limited lifetime (DIP25 solve this partially).
 - `unique` message passing .
 - safe parallelism on graph of object instead of only value types.
 - lock on graph of objects (shared containers).

Now it is clear that we can come up with simpler solution for some of these problem than whatever all encompassing solution would be. It is also clear that is is not possible to get a set of simpler solution that is, as a whole, simpler than an all encompassing solution. That means that some of the above mentioned point must be acknowledged as not going to be fixed.

It is also to be noted that these above mentioned problems are not orthogonal. For instance, getting various GC optimizations in that take advantage of type qualifiers guarantee require that these guarantee are enforced. To get these constraints enforced, you need to be able to build immutable and/or shared in a way that don't break these constraints, and so on.

On Tuesday, 24 February 2015 at 21:03:38 UTC, Walter Bright wrote:
> On 2/24/2015 11:12 AM, bearophile wrote:
>> I don't like the look of the annotations of DIP25. I'd like DIP25 removed from D
>> language and replaced by a more principled solution. Sometimes a heavier
>> solution can be simpler to understand (and it can be actually safe).
>
> So far, DIP25 has been called by various posters unprincipled, hackish, and stupid, without supporting rationale.
>


I do think this comes from looking at the larger picture.

In isolation, DIP25 is not that bad. It solve a class of problems properly, which is already something. Where I think most people find it hacky, unprincipled, or whatever is when looking at the larger picture.

It seems obvious at this point that DIP25 is not the alpha and omega of the problem (this very thread is an example of this). For instance, DIP25 do not do anything for classes to be safely reference counted.

People are - legitimately - afraid that a set of DIP25 like solution will be adopted for each of these problems. When looking at the total cost of the set of solution, compared to a more complex, more principled solution, it seems that this is not the way forward.

In that sense, DIP25 seems like a hack to make reference counting work rather than the addition of a basic language feature that add a new dimension of expressiveness to the language. A bit like Rvalue references in C++ have been added to support std::move and std::forward instead of being a generally useful basic block to build upon.

> Note the thread "A Refcounted Array Type" thread, which uses DIP25 to implement a memory safe ref counted container. It is simple and requires exactly one annotation. It seems pretty straightforward to me, and so far nobody has shown any holes in it, or has even commented on the principle of it. (complaints about bounds checking, delete, etc., are off-topic)

I still have to review it in details, but I'm sure this is good or at least fixable in a way that make it good.

Yet, as mentioned, the problem do not come with DIP25 in isolation. DIP25 does its job well. It just does a too limited job, and it seems that DIP25 and DIP25 like solution for other jobs, will ultimately lead to a more complex situation than where the 'too complex' solutions would lead us.

On Tuesday, 24 February 2015 at 20:53:24 UTC, Walter Bright wrote:
> On 2/24/2015 10:00 AM, Andrei Alexandrescu wrote:
>> I also owe you apologies for not acknowledging that work. I find the proposal
>> too complicated for what it provides and that's the short and long of it. It's
>> easy to make a large and complex language addition to support any sensible
>> abstraction. That doesn't make it automatically good.
>
> My criticisms of it centered around:
>
> 1. confusion about whether it was a storage class or a type qualifier.
>
> 2. I agree with Andrei that any annotation system can be made to work - but this one (as are most annotation systems) also struck me as wordy, tedious, and aesthetically unappealing. I just can't see myself throwing it up on a slide and trying to sell it to the audience as cool.
>
> 3. In line with (2), I want a system that relies much more on inference. We've made good progress with the existing annotations being inferred.
>
> 4. I didn't see how one could, for example, have an array of pointers:
>
>     int*[] pointers;
>
> and then fill that array with pointers of varying ownership annotations.
>
> 5. The (4) homogeneity requirement would mean that templated types would get new instantiations every time they are used with a different ownership. This could lead to massive code bloat.
>
> 6. The 'return ref' scheme, which you have expressed distaste for, was one that required the fewest instances of the user having to add an annotation. It turned out that upgrading Phobos to this required only a handful of annotations.
>
> 7. 'return ref' makes memory safe ref counted types possible, finally, in D, without needing to upend the language or legacy code. And as the example I posted showed, they are straightforward to write. Only time and experience will tell if this will be successful, but it looks promising and I hope you'll be willing to give it a chance.

Thanks for summarizing your reasons. I knew that you were unhappy with 1 - 3); I wasn't aware of 4) and 5). I can't get into detail now, as it's already late at night here, but I'll try thinking about it tomorrow.

FWIW, Zach just wrote in another thread that he will have his own proposal ready soon, based on DIP25, with `scope` being a storage class. Let's see how this goes.

On 2/24/15 1:44 PM, deadalnix wrote:
> For instance, DIP25 do not do anything for classes to be safely
> reference counted.

It does. One small language change is necessary. DIP will be forthcoming. -- Andrei

Here's my best so far:

http://forum.dlang.org/post/offurllmuxjewizxedab@forum.dlang.org

On Tuesday, 24 February 2015 at 20:53:24 UTC, Walter Bright wrote:
> My criticisms of it centered around:
>
> 1. confusion about whether it was a storage class or a type qualifier.

My system has neither. Instead, it just bans unsafe reference copying in @safe code.

> 2. I agree with Andrei that any annotation system can be made to work - but this one (as are most annotation systems) also struck me as wordy, tedious, and aesthetically unappealing. I just can't see myself throwing it up on a slide and trying to sell it to the audience as cool.
>
> 3. In line with (2), I want a system that relies much more on inference. We've made good progress with the existing annotations being inferred.

Well you know I'm on board with this. The one penalty my system requires is two more parameter attributes, which I'm hoping can be alleviated by inference as much as possible.

> 4. I didn't see how one could, for example, have an array of pointers:
>
>     int*[] pointers;
>
> and then fill that array with pointers of varying ownership annotations.
>
> 5. The (4) homogeneity requirement would mean that templated types would get new instantiations every time they are used with a different ownership. This could lead to massive code bloat.

I deliberately designed my system to avoid all associations with type. No code bloat.

> 6. The 'return ref' scheme, which you have expressed distaste for, was one that required the fewest instances of the user having to add an annotation. It turned out that upgrading Phobos to this required only a handful of annotations.
>
> 7. 'return ref' makes memory safe ref counted types possible, finally, in D, without needing to upend the language or legacy code. And as the example I posted showed, they are straightforward to write. Only time and experience will tell if this will be successful, but it looks promising and I hope you'll be willing to give it a chance.

I do give it a chance! See my proposal!