Ideas for C# 5.0

Design by Contract syntax also comes with some very useful keywords such as old; in Eiffel the return value always has a name, called Result (this, by the way, encourages structured programming where control flow is expressed with if-then-else, making control flow visually clear via scoping), so there it is easy to refer to it when forming a post-condition; e.g.

    ensures

        positive: result > 0

One simple function I've found extremely blissful for contract programming is implies, defined as

    implies a b = not a or b

As an example, transitivity expressed with implication/entailment:

    (a > b and b > c) implies (a > c)

It's a bit of a shame we can use neither the natural words for logical operators, nor their symbolic representatives.

I may sound like a broken record, always praising Eiffel but there's also much to be loved about C#. Iterators, lamda expressions and extension methods for example. It doesn't hurt to look around though. Contracts are a way to specify, constrain and verify the state machines we are surrounded with.

Ion Todirel said:

exoteric said:

*snip*

I like the idea! But that doesn't fit with C# 's style, you want this:

 

ensures (result > 0); // The result is within spec limits

ensures immutable someLocalOrClassLevelMemebr; // The state doesn't change during method execution, this may be useful in multithreaded scenarios

 

require (arg1 > 0 && arg2 < 10);

require (arg1 /*string*/); // The compiler will emit code depending on the inputs, e.g. for string it would emit !String.IsNullOrWhitespace(arg1)

 

Just dreaming. This probably never will get into C#.

Agreed; I just wrote it like that to show how nicely readable it is. I would prefer non-nullness at the type level (string! arg1) and stronger conditions in the contract (requires !arg1.IsWhitespace()).

The new Rx video made me think about deferred execution in LINQ.

Bart mentions the Sum method which exits from the IEnumerable monad. As when you evaluate this expression

Enumerable.Range(0, 10).Sum()

the result is 45 but you have left the monad.

Staying alive, in the monad, one might imagine this simple code

Enumerable.Range(0, 10).Sum2()

driven by these extension methods

public static IEnumerable<T> Reduce<S, T>(this IEnumerable<S> source, Func<IEnumerable<S>, T> transform)
{
    yield return transform(source);
}
public static IEnumerable<int> Sum2(this IEnumerable<int> source)
{
    return source.Reduce(xs => xs.Sum());
}

Now looking at this code I cannot help but wonder whether the Sum2 method should not be implementable as

public static IEnumerable<int> Sum2(this IEnumerable<int> source)
{
    return source.Reduce(Sum);
}

or if that's too much magic. It should know the type of source and therefore also know about the extension methods available. See that one matches and resolve to use that.

Compile to native code.