Reason for returning 'input' from the Guard clauses?

[jshergal]

I just recently learned about this library and like how it cleans up as well as clarifies the code. One thing that I am wondering about is the reason to explicitly return the input from the Guard clause. I guess it could be beneficial in some cases, but the way in which I saw the library being used and the way in which I am using it there is no need for it and it actually causes VS2019 to complain that I have an unnecessary expression value (IDE0058). Example code:

public void SomeMethod(IList<int> myInput)
{ 
    Gaurd.Against.Null(myInput, nameof(myInput);
    // Some other code in the method that does some things
}  

The solution to remove the VS nag is to actually write this code using the discard variable, but then I feel like I am losing the benefit of the cleanliness of these clauses.

public void SomeMethod(IList<int> myInput)
{
    _ = Gaurd.Against.Null(myInput, nameof(myInput);
    // Some other code in the method that does some things
}

[ardalis]

In constructors most of the time you're doing some check and then assigning the input to a field. Guards get used in constructors a lot - it's a primary use case. So going from

public void SomeClass(IDependency a, IDependency b, IDependency c)
{
  Guard.Against.Null(a, nameof(a);
  Guard.Against.Null(a, nameof(b);
  Guard.Against.Null(a, nameof(c);

  _a = a;
 _b = b;
 _c = c;
}

to this:

public void SomeClass(IDependency a, IDependency b, IDependency c)
{
  _a = Guard.Against.Null(a, nameof(a);
  _b = Guard.Against.Null(a, nameof(b);
  _c = Guard.Against.Null(a, nameof(c);
}

is a big win.

I can see how it could cause some annoyance in your methods, though. Using a discard is probably your best bet.

[jshergal]

I can see that and it definitely makes the code cleaner and more readable in those cases.