http://d.puremagic.com/issues/show_bug.cgi?id=5115



--- Comment #9 from Kenji Hara <k.hara.pg@gmail.com> 2011-11-10 23:11:38 PST ---
(In reply to comment #8)
> scoped!Foo() returns a temporary of type scoped!(Foo).Scoped (or something like
> that).
> This temporary is implicitly converted to Foo using alias this, but the
> temporary never has it's destructor called due to bug 3516, which means Foo's
> destructor is never called either.
> 
> It is fine for the temporary to be converted to Foo, so long as the destructor is called when the scope that 'scoped' was called in is exited.

Now bug 3516 was fixed. Then comment#1 code prints two "Foo.dtor"

But allowing conversion from temporary type (e.g. Scoped!Foo) to Foo is unsafe, because the temporary has value type and its lifetime is limited in its scope, but Foo is class reference of the temporary and we can bring it out the scope.

Foo global_foo;
void test1() {
    auto foo = scoped!Foo();
    global_foo = foo;   // implicitly conversion from typeof(foo) to Foo
      // This line should be forbidden in compile time
}
void test2() {
    // use global_foo -> Access Violation!
}
void main() {
    test1();
    test2();
}

I think my ProxyOf mixin template is useful for this issue. https://github.com/D-Programming-Language/phobos/pull/300

--- Comment #10 from Kenji Hara <k.hara.pg@gmail.com> 2011-11-10 23:11:39 PST ---
(In reply to comment #8)
> scoped!Foo() returns a temporary of type scoped!(Foo).Scoped (or something like
> that).
> This temporary is implicitly converted to Foo using alias this, but the
> temporary never has it's destructor called due to bug 3516, which means Foo's
> destructor is never called either.
> 
> It is fine for the temporary to be converted to Foo, so long as the destructor is called when the scope that 'scoped' was called in is exited.

Now bug 3516 was fixed. Then comment#1 code prints two "Foo.dtor"

But allowing conversion from temporary type (e.g. Scoped!Foo) to Foo is unsafe, because the temporary has value type and its lifetime is limited in its scope, but Foo is class reference of the temporary and we can bring it out the scope.

Foo global_foo;
void test1() {
    auto foo = scoped!Foo();
    global_foo = foo;   // implicitly conversion from typeof(foo) to Foo
      // This line should be forbidden in compile time
}
void test2() {
    // use global_foo -> Access Violation!
}
void main() {
    test1();
    test2();
}

I think my ProxyOf mixin template is useful for this issue. https://github.com/D-Programming-Language/phobos/pull/300

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5115


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #11 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-12-18 13:02:40 PST ---
(In reply to comment #10)
> Now bug 3516 was fixed. Then comment#1 code prints two "Foo.dtor"
> 
> But allowing conversion from temporary type (e.g. Scoped!Foo) to Foo is unsafe, because the temporary has value type and its lifetime is limited in its scope, but Foo is class reference of the temporary and we can bring it out the scope.

There is another problem. You may want to pass the instance to another function, which is ok since the type will still be alive during that call:

class C { }
void func(C c) { }
void main()
{
    auto c = scoped!C();
    func(c);  // ok, c is still alive here
}

Disabling implicit conversion (maybe by using your ProxyOf mixin) might be ok, but then we can no longer pass the instance around because `Scoped` is a voldemort type hidden inside the `scoped` function. E.g.:

class C { }
void func(C c) { }
void funcScoped(??? c) { }  // param needs to be a proper type
void main()
{
    auto c = scoped!C();  // voldemort type
    func(c);  // error, no implicit conversion
    funcScoped(c);  // would be ok if we knew what type c was
}

So if we disable implicit conversion we should probably introduce a Scoped type instead of a voldemort, so we can write:

void funcScoped(ref Scoped!C c) { }

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5115


Dmitry Olshansky <dmitry.olsh@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitry.olsh@gmail.com


--- Comment #12 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2012-12-19 09:15:42 PST ---
(In reply to comment #11)
> 
> There is another problem. You may want to pass the instance to another function, which is ok since the type will still be alive during that call:
> 
> class C { }
> void func(C c) { }
> void main()
> {
>     auto c = scoped!C();
>     func(c);  // ok, c is still alive here
> }
> 
> Disabling implicit conversion (maybe by using your ProxyOf mixin) might be ok, but then we can no longer pass the instance around because `Scoped` is a voldemort type hidden inside the `scoped` function. E.g.:
> 
> class C { }
> void func(C c) { }
> void funcScoped(??? c) { }  // param needs to be a proper type
> void main()
> {
>     auto c = scoped!C();  // voldemort type
>     func(c);  // error, no implicit conversion
>     funcScoped(c);  // would be ok if we knew what type c was
> }
> 
> So if we disable implicit conversion we should probably introduce a Scoped type instead of a voldemort, so we can write:
> 
> void funcScoped(ref Scoped!C c) { }


Even more interesting is emplacing inside of class instance (to avoid pointer overhead while modeling composition):

class A{//A makes sure b & c are not escaped
   Scoped!B b;
   Scoped!C c;
}

Overall I think voldemort types are overpriced.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------