Steven Schveighoffer <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #7 from Steven Schveighoffer <> 2010-08-12 
05:21:10 PDT ---
(In reply to comment #6)
> It could be an attribute, or it could be something else.
> For instance, instead of having just destructors, we could have destructors
> (~this) and finalizers (~~this). A struct with neither can go anywhere, a
> struct with a destructor but no finalizer cannot go on the GC-heap,  a struct
> with only a finalizer can go anywhere (the finalizer is used as the
> destructor), and a struct with both can go anywhere. The finalizer cannot be
> made @safe.

I think rather than prevent where these items should go, you should just not
call the destructor when the struct/class is being destroyed by the GC.

I'd say you could even prevent what the finalizer contains, but it's too
limiting for the compiler to assume what type of memory a reference is
referencing.  My thought is simply that a finalizer is not safe, and a
destructor is safe.  That at least gives a path for implementation (just mark
your finalizer as @trusted, and it can be used in SafeD).

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to