Shouldn't this fail?

[snobu]

Shouldn't this fail?

    (9).ShouldNotBeAssignableTo<UInt32>(); // Pass
    (9).ShouldNotBeAssignableTo<byte>(); // Pass
    (0xFF).ShouldNotBeAssignableTo<byte>(); // Pass

Shouldly from NuGet.org -- version 3.0.0.
CLR: dotnet 2.1.300

[SimonCropp]

ShouldNotBeAssignableTo maps to Type.IsInstanceOfType. so i think the current behavior is correct.

[snobu]

While i appreciate the answer even if it comes two years late (i do open source as well and best effort is still real effort) and i'm not mad at all, still, reading this out loud doesn't make any sense:

(0xFF).ShouldNotBeAssignableTo<byte>(); // Pass

[jnm2]

@snobu I'm not sure what we can do about it. Any ideas?

C# rules say: 0xFF syntax is an int. .NET runtime rules say: int is not assignable to byte.

[snobu]

I would ignore the runtime in this case if you can. Since there may be different runtime implementations at different points in time they could have different opinions.

[jnm2]

I'm very sure that Shouldly will never run on a runtime implementation where IsAssignableTo has a different meaning. If something that fundamental in System.Reflection changed, it would be nearly impossible to port applications so that they run on both runtimes. This is true to such an extent that .NET is unifying all runtime implementations to run everywhere ("One .NET") rather than using the .NET Standard concept and catering to different runtime implementations. The concept is that no one wants to be in the business of reimplementing the runtime and core libraries because they are missing out on the constant, significant improvements being made in dotnet/runtime.

Also we want to keep special knowledge of C# to a minimum in Shouldly since C# is not the only .NET language we want to support, so baking in rules like "C# allows you to target-type 0xFF as byte" is something we would be reluctant to do.

I'm not sure how to overcome these difficulties without shipping a Shouldly.CSharp package or having a ShouldNotBeCSharpAssignableTo method.

[snobu]

Totally agree. I would open a poll and ask the community.

[jnm2]

As a maintainer, I do not want ShouldBeAssignableTo to diverge from Type.IsAssignableTo/IsAssignableFrom/IsInstanceOf. The runtime value (object)0xFF cannot be cast to byte, and this is what ShouldBeAssignableTo has always meant for existing tests. It would break intuition in the opposite direction to make this more permissive.

More urgently, reflect on the fact that this works:

byte b = 0xFF;

And this does not:

var a = 0xFF;
byte b = a;

Shouldly can't know whether this value came from = 0xFF syntax or = a syntax. The only thing Shouldly has access to is the runtime value. This shows that the assertion can never be about syntax. Therefore, the only thing relevant to the assertion can be the typed runtime value, not the C# syntax used.