On 14.11.2014 16:44, Steven Schveighoffer wrote:
> On 11/14/14 6:25 AM, Rainer Schuetze wrote:
>>
>>
>> On 11.11.2014 21:41, Steven Schveighoffer wrote:
>>> In other words, putting a struct in the GC heap that was written to be
>>> scope-destroyed is an error before and after this pull. Before the pull,
>>> the dtor doesn't run, which is wrong, and after the pull the dtor may
>>> cause race issues, which is wrong. So either way, it's wrong :)
>>
>> I think if someone uses "new" to allocate a struct on the GC heap, he
>> must be aware of the consequences of using the GC. What happens within
>> destruction/finalization is just the same as if it had been wrapped in a
>> class, and that's what everyone(?) expects.
>
> The issue I have is, how do you enforce that as the author of the struct?
>
> Basically, I think you have 2 situations with struct dtors:
> 1. the struct author intends a struct to strictly be used on the stack
> (or on some other heap, such as C heap), and never expects to be GC
> destructed.

You can define "new" in the struct:

struct S
{
	new(size_t sz);
	int x;
}

This causes a link error with "new S;" Unfortunately @disable has no effect (bug?). You can also generate a runtime error within "new".

> 2. the struct author allows it to be GC stored, and faces the
> consequences of that.
>

> Even with these 2 options, allowing GC storage precludes certain things.
> For example, the RefCounted struct goes through great pains to ensure
> its payload is NOT on the GC heap, because the dtor will not work if the
> payload is GC based (it may be already deallocated). The issues are so
> numerous and hairy, that option 2 should really only be left to "experts."
>
> I think we need a better story for GC-stored structs than just letting
> people do it.

I understand there are some complications involved, especially with stuff like RefCounted. With precise scanning, we might be able to sort finalization according to (likely) dependencies, but this will not be 100% safe and slow down collection even more.

There are so many ways people can do something silly/wrong, I don't think we can foresee everything. In addition to allocating it on the heap, the struct could be copied to some global, be kept forever in an associative array, be part of a class or just memset with zeros.

>
> All this being said, having the GC perform what it is supposed to is
> also good. Bottom line -- I think the pull is the right thing to do
> (clearly, not calling dtors in some cases is not correct), but the
> problems are not all solved. We need to continue working on this until
> it's quite simple to make a struct that behaves correctly no matter
> where you put it.

Yeah, even if not fulfilling all desires it is progress in the right direction ;-)

On 11/14/14 11:55 AM, Rainer Schuetze wrote:
>
>
> On 14.11.2014 16:44, Steven Schveighoffer wrote:
>> The issue I have is, how do you enforce that as the author of the struct?
>
> You can define "new" in the struct:
>
> struct S
> {
>      new(size_t sz);
>      int x;
> }

This doesn't stop array allocation, or allocation as part of a class.

-Steve