What’s new in Light.GuardClauses 3.0 and 3.1

In the past weeks, I’ve released Light.GuardClauses 3.0 and 3.1. This post discusses new features and breaking changes of these versions.

Whats new?

The new releases mainly offer you assertions for the Type and TypeInfo classes. You can now easily check if a type is a class, struct, interface, delegate, or enum by using the corresponding assertion methods. Also, you can easily verify if one type derives from or implements another type. Thus, if you incorporate metaprogramming in your current application / framework, you can easily check that two types are in a certain polymorphic relation.

It wasn’t that easy to implement this functionality, because generic types come in different shapes. For example, look at the following test:

// This test uses xunit.net and FluentAssertions
[Fact]
public void CompareGenericTypes()
{
    var genericTypeDefinition = typeof(List<>);
    var methodReturnType = GetType().GetTypeInfo().GetDeclaredMethod(nameof(CreateList)).ReturnType;

    genericTypeDefinition.Should().Be(methodReturnType);
}

public static List<T> CreateList<T>()
{
    return new List<T>();
}

You would probably guess that this test would pass, because both the typeof operator and the return type of CreateList get the type instance of List<T>. However, the test fails because indeed, there is a difference: typeof(List<>) returns the so-called Generic Type Definition, while the return type of CreateList<T> is actually a so-called Open Constructed Generic Type. This means that the return type takes the generic parameter T of the method and applies it to List<T>. Of course, there are also Closed Constructed Generic Types, that’s when you provide a concrete type to a generic type parameter, e.g. when you specify List<string>.

However, I find this default behavior of the .NET type system a bit cumbersome when e.g. checking that List<string> is in the inheritance hierarchy of IList<T>, and that’s where the TypeAssertions.IsEquivalentTo method comes into play: this assertion checks if two types are equal or if one of the types is a constructed generic type and the other one its corresponding generic type definition. This way, you can use all the type assertions of Light.GuardClauses that deal with inheritance to easily compare generic types in there different shapes. Naturally, you can change this default behavior of Light.GuardClauses by providing your custom IEqualityComparer<Type> to the corresponding assertion method. In v3.1, you can also easily check if a type is a closed or open constructed generic type, a generic type definition, or a generic parameter type. Check the releases page on GitHub to see all the details as there are also some other new assertions for other contexts.

Breaking changes

For v3.0, I’ve reimplemented the MustContain and MustBeSubstringOf methods so that they don’t create new strings when the search is performed with case sensitivity turned off. This resulted in an adjustment of the method parameters as you can now optionally specify the CultureInfo that is used for case-insensitive comparison. All the details about this can be found in the XML comments of the assertions.

You like it? Then share it!

I’ve really grown accustomed to using Light.GuardClauses in my daily work, and I dearly miss it in projects where it is not referenced. It’s just so easy to call an extension method that ensures a parameter’s validity, throwing a sensible exception message when the check fails, so that I can really concentrate on the core logic of my code while being sure that my objects are well-encapsulated and unable to go into a false state.

You like Light.GuardClauses, too? Then please spread the word and share it with your coworkers and friends.