On Tuesday, 24 February 2015 at 16:22:47 UTC, Andrei Alexandrescu wrote:
> Just replied to Marc about this. I should have phrased my response as "I don't know of a _reasonable_ solution". BTW please don't call me dishonest anymore, it's doubly inappropriate seeing as we also work together. You wouldn't think there's an actual possibility I go around lying to people about such stuff. Thanks.
>
> Andrei

You have my apologies.

Still, qualifying something of _reasonable_ or not do not constitute a solid argument IMO. That is where my frustration come from here. You are arguing as if nothing was proposed when various persons made proposals. That do not foster progress. If actual criticism of the proposals were made, then we could argue about these criticisms, or come up with improvement of the proposals, but if you argue as if these proposal do not exists, we are condemned to talk past each other and no progress can be made.

On 2/24/15 9:35 AM, "Ulrich =?UTF-8?B?S8O8dHRsZXIi?= <kuettler@gmail.com>" wrote:
> On Tuesday, 24 February 2015 at 16:18:45 UTC, Andrei Alexandrescu wrote:
>> On 2/24/15 4:44 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>"
>> wrote:
>>> As one example, here is what I originally suggested:
>>> http://wiki.dlang.org/User:Schuetzm/scope
>>
>> Walter and I discussed this proposal at length several times.
>
> Is there a place where the outcome of such discussions is documented?
>
> This feels inappropriate like asking for additional paperwork. Still,
> there are so many heated discussions going on here. It might be helpful
> to know what was considered, what was decided and for what reason. Then
> again, maybe I just did not get the memo.

Closest thing to documentation are http://wiki.dlang.org/DIP69 and http://wiki.dlang.org/DIP25, both of which came at the same time inspired by that work, and in reaction to its complexity. We are looking at what parts of DIP69 are simplified/obviated by DIP25. If we can get away with no DIP69 at all, so much the better. -- Andrei

On 2/24/15 9:47 AM, deadalnix wrote:
> On Tuesday, 24 February 2015 at 16:22:47 UTC, Andrei Alexandrescu wrote:
>> Just replied to Marc about this. I should have phrased my response as
>> "I don't know of a _reasonable_ solution". BTW please don't call me
>> dishonest anymore, it's doubly inappropriate seeing as we also work
>> together. You wouldn't think there's an actual possibility I go around
>> lying to people about such stuff. Thanks.
>>
>> Andrei
>
> You have my apologies.
>
> Still, qualifying something of _reasonable_ or not do not constitute a
> solid argument IMO. That is where my frustration come from here. You are
> arguing as if nothing was proposed when various persons made proposals.
> That do not foster progress. If actual criticism of the proposals were
> made, then we could argue about these criticisms, or come up with
> improvement of the proposals, but if you argue as if these proposal do
> not exists, we are condemned to talk past each other and no progress can
> be made.

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.

Andrei

On 2/24/15 9:47 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> Out of interest, because that will be crucial for the further
> development: are you completely opposed to any kind of ownership system,
> or is it something specific about this particular proposal that you
> don't like?

There's no opposition on matters of principle/dogma. It's just too complicated for what it provides.

Andrei

Andrei Alexandrescu:

> It definitely is a good thing. The question is balancing its goodness against the costs of allowing it. It's not impossible you may get asked to change your code to use a struct instead of a fixed-sized array.

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).

Bye,
bearophile

On Tuesday, 24 February 2015 at 18:01:35 UTC, Andrei Alexandrescu wrote:
> On 2/24/15 9:47 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>> Out of interest, because that will be crucial for the further
>> development: are you completely opposed to any kind of ownership system,
>> or is it something specific about this particular proposal that you
>> don't like?
>
> There's no opposition on matters of principle/dogma. It's just too complicated for what it provides.
>
> Andrei

Compared to what ?

On 2/24/15 11:14 AM, deadalnix wrote:
> On Tuesday, 24 February 2015 at 18:01:35 UTC, Andrei Alexandrescu wrote:
>> On 2/24/15 9:47 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>"
>> wrote:
>>> Out of interest, because that will be crucial for the further
>>> development: are you completely opposed to any kind of ownership system,
>>> or is it something specific about this particular proposal that you
>>> don't like?
>>
>> There's no opposition on matters of principle/dogma. It's just too
>> complicated for what it provides.
>>
>> Andrei
>
> Compared to what ?

There is no comparison involved. The proposal is too complicated for what it does. -- Andrei

On 2/24/15 11:12 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>> It definitely is a good thing. The question is balancing its goodness
>> against the costs of allowing it. It's not impossible you may get
>> asked to change your code to use a struct instead of a fixed-sized array.
>
> I don't like the look of the annotations of DIP25.

The way things are going you'll likely have to live with that. -- Andrei

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.

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.

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)