Make Assert.IsNotNull generic and have it return the value that was checked

[drieseng]

Summary

I'm 120% sure that the boat has long sailed for this proposal (with probably very good reasons, such as code side explosion), but I'll try anyway.

It would've been nice if the Assert.IsNotNull() overloads where generic and returned the value that was passed to it.
This would've allowed for nice code like this:

var fi = new System.IO.FileInfo(@"c:\temp\x.log");
var dir = Assert.IsNotNull(fi.Directory);
Assert.AreEqual("temp", dir.Name);

[Youssef1313]

What's the point/value of making this change?

How is that different from either:

var fi = new System.IO.FileInfo(@"c:\temp\x.log");
Assert.IsNotNull(fi.Directory);
Assert.AreEqual("temp", fi.Directory.Name);

or

var fi = new System.IO.FileInfo(@"c:\temp\x.log");
var dir = fi.Directory;
Assert.IsNotNull(dir);
Assert.AreEqual("temp", dir.Name);

[Evangelink]

The main benefit is that the assertion can be used as a narrowing expression without evaluating the value twice:

var dir = Assert.IsNotNull(fi.Directory);
Assert.AreEqual("temp", dir.Name);

The first alternative evaluates fi.Directory again, which can matter for computed or stateful properties. The second is equivalent but requires a separate declaration and assertion. Returning the checked value also aligns with value-returning assertions such as Assert.IsInstanceOfType<T> and Assert.ContainsSingle.

I have prototyped this by adding generic overloads while retaining the existing void IsNotNull(object?, ...) overloads as binary-compatibility shims. The repository builds successfully, and the TestFramework unit tests pass across all target frameworks.

[Youssef1313]

Adding an additional generic overload is risky. It's also possible that it introduces a source breaking change (for F# maybe - needs to be double checked)

If anything to be done here, I would vote for doing a breaking change in v5 to drop the non-generic overload and only have the generic one (binary breaking). But even then I'm not sure it brings enough value to take a breaking change for.

In addition to that, I think it does not make sense for Assert.IsNull to follow the same pattern, and the API will feel weird if IsNull and IsNotNull are not consistent.

[Evangelink]

The benefit here is ergonomic rather than a capability gap: a temporary variable followed by Assert.IsNotNull is equally safe and evaluates the expression only once.

I agree that it is cleaner to wait for the next breaking release and change the existing API shape, rather than permanently retain void overloads alongside generic value-returning overloads solely for binary compatibility.

The apparent asymmetry with Assert.IsNull is consistent with existing APIs. Assert.IsInstanceOfType<T> and Assert.IsExactInstanceOfType<T> return the successfully narrowed T, while Assert.IsNotInstanceOfType<T> and Assert.IsNotExactInstanceOfType<T> return void. Positive assertions can expose a useful narrowed value; their negative counterparts cannot.

Moving this to the MSTest 5.0 / MTP 3.0 milestone.