May 05, 2014
On Sunday, 4 May 2014 at 16:13:23 UTC, Andrei Alexandrescu wrote:
> On 5/4/14, 4:42 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>> But I'm afraid your suggestion is unsafe: There also needs to be a way
>> to guarantee that no references to the scoped object exist when it is
>> destroyed.
>
> Actually, it should be fine to call the destructor, then blast T.init over the object, while keeping the actual memory in the GC. This possible approach has come up a number of times, and I think it has promise. -- Andrei

Then accesses at runtime would still appear to work, but you're actually accessing something else than you believe you do. IMO, this is almost as bad as silent heap corruption. Such code should just be rejected at compile-time, if at all possible.
May 05, 2014
Very short feedback about original proposal:

1) managing local objects is not really a problem, we already have `scoped` in Phobos for that (and unimplemented scope qualifier as possible more reliable approach)

2) real problem is managing global objects without clear destruction point while still keeping those compatible with Object hierarchy (for inheritance / polymorphism). There is nothing proposed to address it.
May 05, 2014
On 5/5/14, 3:18 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> On Sunday, 4 May 2014 at 16:13:23 UTC, Andrei Alexandrescu wrote:
>> On 5/4/14, 4:42 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>>> But I'm afraid your suggestion is unsafe: There also needs to be a way
>>> to guarantee that no references to the scoped object exist when it is
>>> destroyed.
>>
>> Actually, it should be fine to call the destructor, then blast T.init
>> over the object, while keeping the actual memory in the GC. This
>> possible approach has come up a number of times, and I think it has
>> promise. -- Andrei
>
> Then accesses at runtime would still appear to work, but you're actually
> accessing something else than you believe you do. IMO, this is almost as
> bad as silent heap corruption.

Not as bad because memory safety is preserved and the errors are reproducible.

> Such code should just be rejected at
> compile-time, if at all possible.

Yah that would be best.


Andrei

1 2 3
Next ›   Last »