On Saturday, 11 April 2015 at 09:28:46 UTC, Marc Schütz wrote:
> On Friday, 10 April 2015 at 23:12:55 UTC, deadalnix wrote:
>> On Friday, 10 April 2015 at 10:02:01 UTC, Martin Nowak wrote:
>>> On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
>>>> http://wiki.dlang.org/DIP77
>>>
>>> So someone passes an RCO via ref to avoid the inc/dec, and because that imposes safety issues we turn it into some sort of pass by value under the hood, defeating the purpose, and provide an opt-out via @system opAssign.
>>>
>>> Wouldn't it more straightforward to make pass-by-ref unsafe (@system) for RCOs?
>>>
>>> Then the only thing missing to make this equally powerful, would be an optimization opportunity for the compiler to elide copies of pass-by-value RCOs, e.g. it could avoid calling the postblit when the function retains the refcount.
>>
>> Only the first pass by ref create a copy. You can then pass the ref down all you want without copy.
>>
>> That is an acceptable cost IMO.
>
> It's not acceptable that it happens behind the user's back. Costly operations must be explicit.

If we somehow know for a fact that the object really is a reference counted object, then the cost should be acceptable. Running the postblit will consist of incrementing a reference count and nothing else. There's no other way I can think of that permits passing the object safely.

I think the one thing in the DIP I'm not sure of is the definition of what is a reference counted object. Say you write this.

struct Widget {
    byte* data;
    size_t length;

    @trusted
    opAssign(ref const(Widget) other) {
        length = other.length;

        data = malloc(length);
        memcpy(cast(void*) data, cast(void*) other.data, length);
    }

    @trusted
    this(this) {
        auto oldData = data;

        data = malloc(length);
        memcpy(cast(void*) data, cast(void*) oldData, length);
    }

    @trusted
    ~this() {
        free(data);
    }
}

Why would you want to do this? Who knows. According to DIP77 the object above is defined to be a reference counted object, when it isn't. If we're rejecting the C++ answer of "don't write code that way," then the same rejection should apply here. We need to be able to say with 100% certainty that we are dealing with a reference counted object, or at least an object where we know the postblit is so trivial the cost of calling it will be small.

On Saturday, 11 April 2015 at 10:14:00 UTC, w0rp wrote:

> I think the one thing in the DIP I'm not sure of is the definition of what is a reference counted object.

I believe it's still defined by DIP74?
http://wiki.dlang.org/DIP74

On Saturday, 11 April 2015 at 09:41:07 UTC, Walter Bright wrote:
> On 4/11/2015 2:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>> It's not acceptable that it happens behind the user's back. Costly operations
>> must be explicit.
>
> Don't know of a better solution.

How about this?

http://wiki.dlang.org/User:Schuetzm/scope3#.40safe-ty_violations_with_borrowing

Btw, I also made other changes: No implied scope for @safe functions, no overloading on scope (instead postblit and destructor are skipped), and added a terminology section (rather important!).

On Saturday, 11 April 2015 at 11:33:51 UTC, Marc Schütz wrote:
> On Saturday, 11 April 2015 at 09:41:07 UTC, Walter Bright wrote:
>> On 4/11/2015 2:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>>> It's not acceptable that it happens behind the user's back. Costly operations
>>> must be explicit.
>>
>> Don't know of a better solution.
>
> How about this?
>
> http://wiki.dlang.org/User:Schuetzm/scope3#.40safe-ty_violations_with_borrowing
>
> Btw, I also made other changes: No implied scope for @safe functions, no overloading on scope (instead postblit and destructor are skipped), and added a terminology section (rather important!).

Just passing, a bit off topic and clearly not familiar enough with the discussed subject but in case you missed it the last rust blog post is an nice and motivated introduction to their ownership system :

http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html

I need to read about Marc's scope proposal...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 ?

On 04/09/2015 01:10 AM, Walter Bright wrote:
> http://wiki.dlang.org/DIP77

It's a very interesting proposal to tackle this specific problem.

As with all the scope/lifetime related stuff, I find it extremely difficult to anticipate all the needs and foresee how this will integrate with the rest of the language, or even the other scope related DIPs.

At this point it might be better to make a dmd branch and throw up a prototype for all the scope/ref-counted work. The litmus test for a successful design would be safe, efficient, @nogc containers.

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?

-- 
Marco

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.

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.

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

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:
>> On 4/11/2015 2:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>>> It's not acceptable that it happens behind the user's back. Costly operations
>>> must be explicit.
>>
>> Don't know of a better solution.
>
> How about this?
>
> http://wiki.dlang.org/User:Schuetzm/scope3#.40safe-ty_violations_with_borrowing
>
> Btw, I also made other changes: No implied scope for @safe functions, no
> overloading on scope (instead postblit and destructor are skipped), and added a
> terminology section (rather important!).

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?