On Wed, 22 Oct 2014 18:44:26 +0000
via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:

> On Wednesday, 22 October 2014 at 18:14:54 UTC, ketmar via Digitalmars-d-learn wrote:
> > yes, this is the case. i believe that this should be explicitly documented in `scoped` ddocs. documentation examples using 'auto', but there is no mention that this is what *must* be used.
> This is too dangerous to be used in real programs…
there is nothing really dangerous if the feature is used properly. i'm using `scoped` in my software without any troubles. yes, there might be better ways to do what `scoped` does, but for now `scoped` is... satisfactory. it just need some care. ;-)

On Wednesday, 22 October 2014 at 18:03:44 UTC, anonymous wrote:
> On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:

> `foo` should be a `Scoped!A`. When it's typed as `A`, the
> `Scoped!A` that is returned by `scoped`, is destructed
> immediately (and the reference leaks, I guess).

Just tell me that's a feature, not a bug...

On Wednesday, 22 October 2014 at 18:03:59 UTC, Ali Çehreli wrote:
> On 10/22/2014 08:45 AM, eles wrote:> C++ versions:

> Extremely dangerous and very tricky! The solution? Define the objects as 'auto' (or 'const', etc.), which you want anyway:
>
>     auto foo = scoped!(A)();
>     auto bar = scoped!(B)();
>
> You do not want to be left with A or B. You want Scoped!A and Scoped!B.

Write it on this page http://ddili.org/ders/d.en/destroy.html with red big font, please.

On 10/22/2014 03:59 PM, eles wrote:

> Write it on this page http://ddili.org/ders/d.en/destroy.html with red
> big font, please.

Don't worry, it's already in my short todo list. ;)

Ali

On Wednesday, 22 October 2014 at 18:03:44 UTC, anonymous wrote:
> On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
>> D version:

> `foo` should be a `Scoped!A`. When it's typed as `A`, the
> `Scoped!A` that is returned by `scoped`, is destructed
> immediately (and the reference leaks, I guess).

And the compiler swallows this without even barking? Why Scoped!A is convertible to A, then? And what the resulting A-typed variable contains if the object gets destroyed. And what use for that content?

On 10/22/2014 04:05 PM, eles wrote:

> And the compiler swallows this without even barking?

The compiler must obey an alias this inside Scoped.

I've thinking for a way do disallow this but haven't been able to spend much time on it today.

> Why Scoped!A is convertible to A, then?

So that Scoped!A can conveniently be used as an A.

> And what the resulting A-typed variable contains if the object
> gets destroyed.

Note that the A is not the object but the class reference to it. The 'alias this' hands out a reference to the object that is on the stack. The reference is valid when that occurs. Then, the compiler destroys the temporary Scoped!A object as it should, leaving behind a dangling reference.

There must be a way to disallow this.

Ali

On Wednesday, 22 October 2014 at 23:11:14 UTC, Ali Çehreli wrote:
> On 10/22/2014 04:05 PM, eles wrote:
>
> > And the compiler swallows this without even barking?
>
> The compiler must obey an alias this inside Scoped.
>
> I've thinking for a way do disallow this but haven't been able to spend much time on it today.
>
> > Why Scoped!A is convertible to A, then?
>
> So that Scoped!A can conveniently be used as an A.
>
> > And what the resulting A-typed variable contains if the object
> > gets destroyed.
>
> Note that the A is not the object but the class reference to it. The 'alias this' hands out a reference to the object that is on the stack. The reference is valid when that occurs. Then, the compiler destroys the temporary Scoped!A object as it should, leaving behind a dangling reference.
>
> There must be a way to disallow this.

Yet another use case for borrowing.

Am Thu, 23 Oct 2014 12:15:13 +0000
schrieb "Marc Schütz" <schuetzm@gmx.net>:

> Yet another use case for borrowing.

Cool, how does it keep the original struct alive though, if it isn't stored anywhere? Or will it error out when you attempt to use the dangling pointer to the object?

-- 
Marco

On Thursday, 23 October 2014 at 13:03:08 UTC, Marco Leise wrote:
> Am Thu, 23 Oct 2014 12:15:13 +0000
> schrieb "Marc Schütz" <schuetzm@gmx.net>:
>
>> Yet another use case for borrowing.
>
> Cool, how does it keep the original struct alive though, if it
> isn't stored anywhere? Or will it error out when you attempt
> to use the dangling pointer to the object?

It needs to error out. Artificial life support for the original object would be too much magic for my taste.

    struct Scoped(T) if(is(T == class)) {
        private T _payload;
        // <insert constructor and destructor here>
        scope!this(T) borrow() { return _payload; }
        alias borrow this;
    }

    void foo() {
        A a = scoped!A();
        // ERROR: cannot assign Scope!A to A
        scope b = scoped!A();
        // ERROR: local `b` outlives temporary
    }