Что не так с не обнуляемыми объектами?

Question

В последнее время я смотрю на DbC и Spec #, которые, похоже, поддерживают необнуляемые объекты. К сожалению, Spec #, похоже, был заброшен.

1. В Spec #, похоже, было много встроенных языковых функций, так почему же он был заброшен?
2. Будет ли проблема с тем, чтобы все объекты по умолчанию не обнулялись, поэтому вам нужно было бы написать int ?, string? и даже MailMessage? если вы действительно хотели обнуляемый объект?
3. Я вижу здесь аналогию с SQL где вы можете проверить класс свойства как обнуляемые или не обнуляемый. Не могли бы вы поставить ограничения на свойства, как вы может с таблицами sql таблицы?

Я не вижу проблем с такими функциями, как эта, встроенными в язык. Может ли кто-нибудь просветить меня об этом?

Answer 1

Видели ли вы, что новая структура Контракты станет частью .NET 4.0?

Преимущество создания библиотеки, а не языковой функции, заключается в том, что она сразу становится доступной на всех языках без какой-либо работы со стороны языковых команд. Очевидно, есть и недостатки ...

Ссылки:

• Сообщение в блоге команды BCL
• И еще
• PDC 2008, видео

Сказав все это, я бы хотел написать:

public Stream! Foo(string! x)

, что указывает на то, что Foo не должен получать нулевую ссылку и не будет возвращать ее. Я думаю, что иметь дополнительный бит синтаксиса для просто такого типа контракта было бы удобно.