On Tuesday, 24 February 2015 at 01:43:11 UTC, Andrei Alexandrescu wrote:
> This is a free world. Walter and I are working on a DIP. Please work on yours. I can't promise we'll choose to your liking, but this is the one way you can make your point heard and understood. What doesn't work is trash talk.
>
> I guarantee I recognize brilliance when I see it. So if you have a brilliant idea, it won't be missed. Have at it. One thing I cannot do is choose a solution that you prefer over one I prefer - this does remain a subjective topic. I can't help it. But please don't consider me an idiot because I don't like what you propose.
>

I don't think you are being fair here. Even if not formally expressed as a DIP, at least Mark and myself have come up with fairly detailed explanations, in topic you participated in, so we can't really do as if it didn't existed. Also, I do not think this is a subjective matter. Yes there is a part of it that is matter of taste and is subjective, but overall there is a big chunk of objectively discussable things is there proposal, like language complexity and expressiveness added to the language.

But here is mostly what I think is going on. We are discussion various issues, including make the GC faster, enable safe RC, make @nogc more usable (for instance exception usability), safe ref, enforcing type qualifier contraints, and so on...

For each of these issues, solution are proposed. What I (and I think Mark would agree) propose would solve them all. Yes this is more complex than any of the solution proposed for each of these. But this is way simpler, and enable way more than having a unique, simpler solution for each of these problems.

On Monday, 23 February 2015 at 18:16:38 UTC, Andrei Alexandrescu wrote:
> On 2/23/15 6:56 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>> These two points have undesirable consequences: All consumers such
>> objects need to be aware of the exact type, which includes the
>> management strategy (RC, Unique, GC). But this is a violation of the
>> principle of separation of concerns: a consumer shouldn't need to have
>> information about the management strategy, it should work equally with
>> `RefCounted!C`, `Unique!C` and bare (GC) `C`, as long as it doesn't take
>> ownership of the resource.
>
> Well I don't know of another way.

Ok, I wrote my reply assuming that you are aware of the various proposals deadalnix, myself and several other people have made in the past, some of them quite specific. But now that I think of it, I don't remember that you were ever directly referring to it in any of your posts. Maybe you just missed it?

As one example, here is what I originally suggested:
http://wiki.dlang.org/User:Schuetzm/scope

It's not completely up to date, during discussions I gained many useful new insights to simplify it and make things more consistent. It's also part of a bigger picture (deadalnix's ideas about ownership play an important role, too), which unfortunately isn't easy to recognize, because this page has become quite large und unwieldy. I should make a post explaining this.

>> In general, this and related proposals tend to limit themselves on
>> memory management (as witnessed by the importance that `ref` and `@safe`
>> play in them). This is too narrow IMO. A well thought-out solution can
>> be equally applicable to the broader field of resource management.
>
> Looking forward to your insights.

See above. I had the impression that you were aware of the proposals, but for some reason were opposed to them. Maybe that's not the case?

On Tuesday, 24 February 2015 at 02:35:41 UTC, deadalnix wrote:
> For each of these issues, solution are proposed. What I (and I think Mark would agree) propose would solve them all. Yes this is more complex than any of the solution proposed for each of these. But this is way simpler, and enable way more than having a unique, simpler solution for each of these problems.

Indeed I agree.

But judging by Andrei's response above, I'm longer so sure he is actually aware of what we proposed.

On Tuesday, 24 February 2015 at 12:44:54 UTC, Marc Schütz wrote:
> On Monday, 23 February 2015 at 18:16:38 UTC, Andrei Alexandrescu wrote:
>> On 2/23/15 6:56 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>>> These two points have undesirable consequences: All consumers such
>>> objects need to be aware of the exact type, which includes the
>>> management strategy (RC, Unique, GC). But this is a violation of the
>>> principle of separation of concerns: a consumer shouldn't need to have
>>> information about the management strategy, it should work equally with
>>> `RefCounted!C`, `Unique!C` and bare (GC) `C`, as long as it doesn't take
>>> ownership of the resource.
>>
>> Well I don't know of another way.
>
> Ok, I wrote my reply assuming that you are aware of the various proposals deadalnix, myself and several other people have made in the past, some of them quite specific. But now that I think of it, I don't remember that you were ever directly referring to it in any of your posts. Maybe you just missed it?
>
> As one example, here is what I originally suggested:
> http://wiki.dlang.org/User:Schuetzm/scope
>
> It's not completely up to date, during discussions I gained many useful new insights to simplify it and make things more consistent. It's also part of a bigger picture (deadalnix's ideas about ownership play an important role, too), which unfortunately isn't easy to recognize, because this page has become quite large und unwieldy. I should make a post explaining this.

I'm working on my own idea now. I make scope transitive, because it's both memory safe and simple to implement, but doing so may cause some things which are actually safe to be considered unsafe (but then you could just use @system blocks or @trusted lambdas to correct this). Also, I don't think `scope` needs to be part of the type.

I'm about 90 percent sure, 10 percent unsure that my system will work. I'll have it soon enough. It needs DIP25 to be expanded to all reference types (not just `ref`), requires my own DIP71, http://wiki.dlang.org/DIP71 for total safety, and possibly one or two more additions for a reliable ownership. The only real cost is added complexity to function signatures (a la DIP25), which can and should be inferred in most cases, assuming we aren't crippled by an ancient and subpar linking mechanism which requires all this manual marking of signatures all the time.

Stay tuned, sir!

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.

I think it can be made to work. I also think it's overly complicated for what it does and that it's not brilliant.

These are the most dangerous designs: complicated, not brilliant, but can be made to work - because they end up getting implemented. We want to get away without implementing it.

Currently we want to explore DIP25, which we believe has a very good price/performance profile (whilst not being brilliant itself), and its impact on designing safe struct types. It is our suspicion that DIP25 is all we need for making involved struct types safe. If that's the case, that paves the road toward safe class types using reference counting with very small language changes.

There will be stragglers, such as taking slices into stack-allocated statically-sized arrays. At that point the question will be whether we can implement that as a @safe struct, we need a language change, or we can just live with it (after all, using stack-allocated arrays in safe code is a rather niche use).

So the short answer is: yes, I've studied your proposal and I don't think it's good enough. Furthermore I don't think there are small changes to it that will make it good enough. This is not personal and please don't take offense over that. In contrast, I think DIP25 is good (partly because it's deceptively simple) and I want to pursue it and its consequences.


Andrei

On 2/23/15 6:35 PM, deadalnix wrote:
> On Tuesday, 24 February 2015 at 01:43:11 UTC, Andrei Alexandrescu wrote:
>> This is a free world. Walter and I are working on a DIP. Please work
>> on yours. I can't promise we'll choose to your liking, but this is the
>> one way you can make your point heard and understood. What doesn't
>> work is trash talk.
>>
>> I guarantee I recognize brilliance when I see it. So if you have a
>> brilliant idea, it won't be missed. Have at it. One thing I cannot do
>> is choose a solution that you prefer over one I prefer - this does
>> remain a subjective topic. I can't help it. But please don't consider
>> me an idiot because I don't like what you propose.
>>
>
> I don't think you are being fair here. Even if not formally expressed as
> a DIP, at least Mark and myself have come up with fairly detailed
> explanations, in topic you participated in, so we can't really do as if
> it didn't existed. Also, I do not think this is a subjective matter. Yes
> there is a part of it that is matter of taste and is subjective, but
> overall there is a big chunk of objectively discussable things is there
> proposal, like language complexity and expressiveness added to the
> language.
>
> But here is mostly what I think is going on. We are discussion various
> issues, including make the GC faster, enable safe RC, make @nogc more
> usable (for instance exception usability), safe ref, enforcing type
> qualifier contraints, and so on...
>
> For each of these issues, solution are proposed. What I (and I think
> Mark would agree) propose would solve them all. Yes this is more complex
> than any of the solution proposed for each of these. But this is way
> simpler, and enable way more than having a unique, simpler solution for
> each of these problems.

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

Andrei Alexandrescu:

> using stack-allocated arrays in safe code is a rather niche use).

I use stack-allocated arrays in supposedly safe code. And having a future D compiler that makes that kind of code actually safe is a good thing.

Bye,
bearophile

On 2/24/15 8:34 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>> using stack-allocated arrays in safe code is a rather niche use).
>
> I use stack-allocated arrays in supposedly safe code. And having a
> future D compiler that makes that kind of code actually safe is a good
> thing.

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.

Andrei

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.

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.
>
> I think it can be made to work. I also think it's overly complicated for what it does and that it's not brilliant.
>
> These are the most dangerous designs: complicated, not brilliant, but can be made to work - because they end up getting implemented. We want to get away without implementing it.
>
> Currently we want to explore DIP25, which we believe has a very good price/performance profile (whilst not being brilliant itself), and its impact on designing safe struct types. It is our suspicion that DIP25 is all we need for making involved struct types safe. If that's the case, that paves the road toward safe class types using reference counting with very small language changes.
>
> There will be stragglers, such as taking slices into stack-allocated statically-sized arrays. At that point the question will be whether we can implement that as a @safe struct, we need a language change, or we can just live with it (after all, using stack-allocated arrays in safe code is a rather niche use).
>
> So the short answer is: yes, I've studied your proposal and I don't think it's good enough. Furthermore I don't think there are small changes to it that will make it good enough. This is not personal and please don't take offense over that. In contrast, I think DIP25 is good (partly because it's deceptively simple) and I want to pursue it and its consequences.

I'm certainly not offended. I don't think the proposal is "brilliant" either, it was meant as a starting point for discussions, not as a completely finished proposal aka DIP. 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?