> without a nominal type to attach the =destroy etc. to... @Araq, unless I'm wrong (again), there would be nominal types for every =destroy, just that the nominal types would include more than just object types: there would be default cases for primitives, primitive pointer's and ptr T's, for object types just as there are now where the three "hooks" may or may not be needed to override default behaviour just as now, with your owned ref and unowned ref there are the three "hooks" just as you propose in the spec 2 document, each of them triggered as appropriate by you strong typing and proc override system.
I see it as being safer than as now, as for instance primitive pointer's would never not be destroyed if that was the default and they weren't moved to sink and ptr T could also be automatically destroyed unless moved when they go out of scope unless there was a specialization for the particular ptr Mytype. The rule would be very simple: the general case would be the standard default; if something else is required then declare the "hooks" for the specific type to override the default. I have done some quick tests and the type system seems to quite readily pick up the my simulated "hook" specializations. It seems complicated but a large percentage of possible types can't be destroyed so fall through to the lowest default case of a =destroy that just discard's and =copy and =move that just copy. Many of the rest such as ptr have very trivial default hooks and defer to the hooks on the inner type, etc. The reason I like it as it seems to allow one to specify the exact behaviour required for every case, including the one where a given field in the source and destination is a pointer or reference to the same memory location. It would seem that there would be no special cases that couldn't be handled quite simply, and for most the compiler macros could automatically generate the boilerplate for, say, multiple levels of nested fields.
