Я тут ковыряю Go (может в принципе по работе пригодиться), возможно вот это будет тут в тему: http://golang.org/doc/go_spec.html#Defer_statements
Это синтаксический сахар. Он ничего не добавляет по сути.
Это действительно не то что тебе нужно, но это и не синтаксический сахар.
У меня задача вот какая. Те UnmanagedString о которых я говорил создаются в одном потоке как поля объекта-сообщения, далее этот объект-сообщение обрабатывается в другом потоке и удаляется (фактически помещается в пул для повторного использования). Во время уничтожения все его поля чистятся, соответственно у UnmanagedString вызываются деструктор и она отправляется в свой пул для повторного использования. Так вот мне хочется от языка и от компилятора гарантии, чтобы нигде эта строка никуда не была скопирована простым оператором ":=". Время её жизни равно времени жизни объекта-сообщения и если кто-то её скопирует себе простым оператором ":=", то потом получит сюрприз. Вот поэтому я и думаю о запрете оператора ":=" для некопируемых структур.
А! Хочется "гермитичности типов"? :-) То есть гарантировать чтобы ни один гад не сохранил "указатель" на сущность которая потом будет "удалена". В общем то умный указатель (типа shared_ptr) тут тебе не поможет, в том плане, что он предотвратит не утекание указателей в левые места, а удаление сущности в случае если они таки утекли. Гарантию в рантайме тут даст только какой-нибудь weak_ptr. Но гарантия в рантайме - это слишком слабая гарантия (IMHO).
Таким образом, умные указатели (как и сборщики мусора) тут совершенно не в тему.
По сути тебе тут для твоих "ссылок" (UnmanagedString) нужно изобрести механизм аналогичный обероновско-виртовской передачи по ссылке записей на стеке (VAR-параметры) и невозможности взять их адрес (получить указатель/ссылку на них в явном виде, которую можно скопировать и так далее).
PS. А в шарпе не бывает opaque типов?
