April 12, 2015
On Sunday, 12 April 2015 at 04:18:54 UTC, Andrei Alexandrescu wrote:
> On 4/11/15 5:35 AM, matovitch wrote:
>> I am not convinced by the dip77, what about raii managed classes with
>> costly opAssign operator (like in w0rn example) ? The goal of passing an
>> object by reference is to avoid the copy and here you guess the
>> parameter is ref-counted and made a (pseudo-)copy ? Then any allocating
>> opAssign should be marked @system ?
>
> Expensive opAssign or expensive postblit? -- Andrei

Well both in the example given by w0rp. I guess D as no "rule of five" but still a "rule of three" (which is in fact rule of four with the copy-and-swap idiom) about coding posblit, opAssign and destructor together ?
April 12, 2015
On Sunday, 12 April 2015 at 07:17:07 UTC, Walter Bright wrote:
>
> A quick read of this suggests it is doing the Rust model of only one mutable reference at a time. Is this really viable with D?

I would love to see a storage class to add the rust ownership model to D. I surely don't know if it's feasible.
April 12, 2015
On Saturday, 11 April 2015 at 20:40:20 UTC, deadalnix wrote:
> On Saturday, 11 April 2015 at 09:28:46 UTC, Marc Schütz wrote:
>> It's not acceptable that it happens behind the user's back. Costly operations must be explicit.
>
> Nothing is costly here.

Of course it is:
http://forum.dlang.org/post/iehijjgdlfouplcngrjy@forum.dlang.org
April 12, 2015
On Sunday, 12 April 2015 at 07:17:07 UTC, Walter Bright wrote:
> On 4/11/2015 4:33 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>> http://wiki.dlang.org/User:Schuetzm/scope3#.40safety_violations_with_borrowing
>
> A quick read of this suggests it is doing the Rust model of only one mutable reference at a time. Is this really viable with D?

I think it is. You have to keep in mind that this is opt-in; it only applies to `scope` variables. I would agree that as a default, it wouldn't fit D at all. I think that, for all its usefulness, it'd be a tad too limiting for my taste if I were forced to use it everywhere. In Rust, it needs to be ubiquitous, because their goal is to get by without a GC. We on the other hand just want a way to make the GC easier to avoid. We also want to be able to use these different programming styles side by side, therefore an opt-in solution is good.

Besides, I too want to recommend the article Matovitch linked to, and Yehuda Katz' article mentioned therein, because they make a good point demonstrating that it gives more correctness guarantees than just memory safety:

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

It's a great building block for lots of nice things. In fact, it's quite likely the only way to get these guarantees once you look beyond reference counting.
April 12, 2015
Marc Schütz:

> You have to keep in mind that this is opt-in; it only applies to `scope` variables. I would agree that as a default, it wouldn't fit D at all. I think that, for all its usefulness, it'd be a tad too limiting for my taste if I were forced to use it everywhere.

I think D Zen asks for safety on default and opt-out on request.

See also "@safe by default":
https://issues.dlang.org/show_bug.cgi?id=13838

Bye,
bearophile
April 12, 2015
On Sunday, 12 April 2015 at 12:06:50 UTC, bearophile wrote:
> I think D Zen asks for safety on default and opt-out on request.

Marc talked about unique ownership vs. shared ownership, not about safe vs. unsafe.

April 12, 2015
On Sunday, 12 April 2015 at 07:17:07 UTC, Walter Bright wrote:
> On 4/11/2015 4:33 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>> On Saturday, 11 April 2015 at 09:41:07 UTC, Walter Bright wrote:
> A quick read of this suggests it is doing the Rust model of only one mutable reference at a time. Is this really viable with D?

It's a very good ownership model IMO, because it has no runtime overhead and often sharing/escaping isn't needed. Would at least be interesting to explore this in more detail for scoped variables.

As a side note, I find that unique ownership is strangely missing from our discussions, yet it's a perfect ownership model for resources such as a File.
https://github.com/D-Programming-Language/phobos/pull/3171
April 12, 2015
On Sunday, 12 April 2015 at 13:12:05 UTC, Martin Nowak wrote:
> As a side note, I find that unique ownership is strangely missing from our discussions, yet it's a perfect ownership model for resources such as a File.
> https://github.com/D-Programming-Language/phobos/pull/3171

I'm aware of it, but didn't want to open another can of worms. I have a vague idea what to do about it, based on deadalnix' "isolated" idea and the already existing uniqueness concept. I need to make up my mind about moving though, whether the benefits of making the compiler know about it are worth the added complexity.
May 01, 2015
Am Sat, 11 Apr 2015 20:42:52 +0000
schrieb "deadalnix" <deadalnix@gmail.com>:

> On Saturday, 11 April 2015 at 18:20:51 UTC, Marco Leise wrote:
> > Am Fri, 10 Apr 2015 14:04:39 +0000
> > schrieb "Ola Fosheim Grøstad"
> > <ola.fosheim.grostad+dlang@gmail.com>:
> >
> >> On Friday, 10 April 2015 at 10:28:03 UTC, Walter Bright wrote:
> >> > That's what ref counting is about.
> >> 
> >> That would require pervasive ref-counting.
> >
> > You make is sound like there was an alternative to ref counting for resources. Is there?
> 
> Ownership, GC.

That doesn't convince me yet. GC is just incorrect to use here. D's GC like any other that is non-deterministic will hold on to many external resources for longer than is feasible.

(Unique) ownership on the other hand isn't really what we are
looking at here, right? I mean, the DIP talks about what
happens when you are dealing with multiple references to
the same item.

That leaves us with RC, which I think is a good choice.

-- 
Marco

Next ›   Last »
1 2 3 4 5 6 7 8 9