Could Guard methods return a value?

[prlcutting]

Per the docs, Guard methods all return void. For the typical use case of evaluating a parameter and then assigning it to a backing field or property when using constructor injection, the pattern looks like this:

public class C
{
    public C(ISomeService someService)
    {
        Guard.IsNotNull(someService); // Guard
        SomeService = someService; // Assignment
    }

    private ISomeService SomeService { get; }
}

This code could be a little terser if the various Guard methods returned a value, such that the parameter could be validated and an exception thrown if the validation fails, otherwise assigned to the member/variable all in one step, e.g.:

public class C
{
    public C(ISomeService someService)
    {
        SomeService = Guard.IsNotNull(someService); // Guard and assignment
    }

    private ISomeService SomeService { get; }
}

Of course this would not preclude the first pattern as the return value could just be ignored if not needed/desired.

Was this use case considered? I'm sure it was, and there was a reason for not doing this - perhaps performance related? If there is merit to this idea, could this be implemented in a non-breaking manner?

Note: the inspiration for this API idea was drawn from Steve Smith's excellent Ardalis.GuardClauses library.

[prlcutting]

Ah, I just saw #187 that pretty much asked exactly the same question.

[JorgeCandeias]

It would be nice but it would be a very significant breaking change to method signatures. It also defeats one of the main use purposes of Guard, to clearly separate pure validation from side-effects. Having Guard return void kicks us down that particular pit of success one way or another.

There is an open proposal for a partner API called Check in #176 that may or may not be of interest to you.

[prlcutting]

Thanks for the feedback. Yes, after initially submitting this idea, I am coming around to favoring the separation that a void-returning API enforces over the terseness of a result-returning one.

[michael-hawker]

FYI @Sergio0694

[Sergio0694]

As others have mentioned, they could return a value, but:

• It'd be a massive breaking change, so a non-starter.
• It's not the design those APIs were meant to have. One of the points is to clearly separate argument validation from logic.

[michael-hawker]

I thought also the fact that they didn't have a return value was part of the optimization obtained from the errors throwing within them, or am I misremembering how that all ties together?