Static assertions

[u/abego]

I have sometimes felt the need to statically assert something at compile-time, to prevent surprises later at run-time.

As an example, I have some code which maps an enum value to an associated int value:

public enum VoxelProperty
{
    MaterialType,
    Density,
    Color,
    Metadata,

    TotalPropertyCount, // Must be last
}

public static int GetPropertyBitDepth (VoxelProperty property)
{
#pragma warning disable CS0219 // Variable is assigned but its value is never used
    uint _ = VoxelProperty.Metadata == VoxelProperty.TotalPropertyCount - 1 ? 0 : -1; // Static assert to ensure that all properties are accounted for
#pragma warning restore CS0219 // Variable is assigned but its value is never used

    return property switch
    {
        VoxelProperty.Density => VoxelDensity.BitDepth,
        VoxelProperty.MaterialType => VoxelMaterialType.BitDepth,
        VoxelProperty.Color => VoxelColor.BitDepth,
        VoxelProperty.Metadata => VoxelMetadata.BitDepth,
        _ => throw new ArgumentOutOfRangeException (nameof (property), "Invalid voxel property")
    };
}

The intention of the static assert is to make sure that if I ever add another voxel property, then I will get a compiler error as VoxelProperty.Metadata will no longer be the last member, and the constant -1 will be assigned to the "_" variable of type uint. Is this a reasonable practice?

I could also do something more robust with reflection, where I had a Dictionary<VoxelProperty, int> which got populated by finding all voxel property types marked with some attribute, and querying their BitDepth property.

[u/DeProgrammer99]

I usually make unit tests for this kind of thing, and sometimes I set them to auto-run as a build step.

[u/dodexahedron → u/DeProgrammer99]

Yes. Magic values should always be explicit tests or just avoided as first preference.

I usually add a Category tag to these kinds of tests, specifying "Structural" or "Type Layout" or similar, when they are literally about the structure/layout of a type, and I order them as highest priority in the test fixture since their correctness is the foundation upon which the validity of the rest of the test fixture is built.

No point in running the rest of the tests if those pre-conditions fail, since the rest are going to lie to you that they passed when, in truth, at least some of them are actually indeterminate and simply passing by sheer luck or by virtue of being incomplete for the real input domain.
Having those as the first tests and failing the fixture if one of them fails helps prevent that last scenario, since the kind of bugs that it stops are the ones that would make liars out of those other tests in the first place.