Contract Killers

Seriously, is this the most succinct way of expressing this?

[InheritedExport]
[ContractClass(typeof(RequestFailureContract))]
public interface IRequestFailure
{
    string FailureMessage { get; }
}

[ContractClassFor(typeof(IRequestFailure))]
public class RequestFailureContract : IRequestFailure
{
    public string FailureMessage
    {
        get { 
            Contract.Ensures(Contract.Result<string>() != null);
            return null;
        }
    }
}

Personally, I would prefer to write this:

public interface IRequestFailure
{
    string! FailureMessage { get; }
}

If you’re currently thinking there’s something very wrong with code contracts in C# you’d be right.  What’s wrong is that code contracts aren’t actually a language feature.  They’re implemented as a post-compilation rewrite.  Don’t get me wrong, it’s really impressive that they achieved it this way, and they’re still an improvement on what went before, but I can’t help feeling they lost sight of the ultimate goal on this one.  Worse, enforcing code contracts is achieved by a DevLabs download that’s feature-locked to particular versions of Visual Studio.  I’m pretty sure I missed the part of the Liskov Substitution Principle that said “This doesn’t apply if you happen to be running Visual Studio Professional”.