You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Proposal: Extend Guard Methods to Return Validated Arguments
Summary
Extend the existing Guard functionality to provide an alternative version of all guard methods that return the validated argument when the validation passes. This enhancement would allow method chaining and inline validation assignments.
Current Usage
The current Guard methods validate an argument and throw an exception if the validation fails, but they return void. This requires an extra assignment step when the argument is needed after validation.
Example:
public class Processor
{
private readonly string _input;
public Processor(string input)
{
Guard.IsNotNullOrEmpty(input);
_input = input;
}
public void Print()
{
Console.WriteLine(_input);
}
}
Proposed Enhancement
Provide an alternative version of all guard methods that return the validated argument when the validation passes. This would allow inline validation while preserving the original API behavior.
Proposed Usage
Instead of requiring a separate assignment, the new API would allow:
public class Processor
{
private readonly string _input;
public Processor(string input)
{
_input = Guard.IsNotNullOrEmpty(input);
}
public void Print()
{
Console.WriteLine(_input);
}
}
Implementation Options
Two approaches could be taken to introduce this feature:
Option 1: Create a ResultGuard Class
Introduce a new ResultGuard class that mirrors Guard but returns the validated argument.
public static class ResultGuard
{
public static T IsNotNullOrEmpty<T>(T value, [CallerArgumentExpression("value")] string? paramName = null)
where T : class
{
Guard.IsNotNullOrEmpty(value, paramName);
return value;
}
}
Pros:
No changes to the existing Guard class.
Clear separation between validation-only (Guard) and validation-with-return (ResultGuard).
Cons:
Code duplication or the need to refactor Guard to reuse logic.
Users must choose between Guard and ResultGuard.
Option 2: Modify Guard to Return the Argument
Modify the existing Guard class to return the argument instead of void.
public static class Guard
{
public static T IsNotNullOrEmpty<T>(T value, [CallerArgumentExpression("value")] string? paramName = null)
where T : class
{
if (string.IsNullOrEmpty(value))
{
throw new ArgumentException($"{paramName} cannot be null or empty.", paramName);
}
return value;
}
}
Pros:
No need for a new class.
Maintains a single validation API.
Fully backward-compatible since it only extends the return type.
Cons:
Changes the return type of existing methods, which may have unforeseen consequences in certain use cases.
Personal Preference
I personally prefer Option 2 (modifying Guard) because it avoids duplication, maintains backward compatibility, and enhances usability with minimal changes. However, I am open to other suggestions if the maintainers have concerns or alternative approaches in mind.
Would the maintainers be open to this enhancement? If so, I can submit a PR with the implementation.
The text was updated successfully, but these errors were encountered:
Proposal: Extend Guard Methods to Return Validated Arguments
Summary
Extend the existing
Guard
functionality to provide an alternative version of all guard methods that return the validated argument when the validation passes. This enhancement would allow method chaining and inline validation assignments.Current Usage
The current
Guard
methods validate an argument and throw an exception if the validation fails, but they returnvoid
. This requires an extra assignment step when the argument is needed after validation.Example:
Proposed Enhancement
Provide an alternative version of all guard methods that return the validated argument when the validation passes. This would allow inline validation while preserving the original API behavior.
Proposed Usage
Instead of requiring a separate assignment, the new API would allow:
Implementation Options
Two approaches could be taken to introduce this feature:
Option 1: Create a
ResultGuard
ClassIntroduce a new
ResultGuard
class that mirrorsGuard
but returns the validated argument.Pros:
Guard
class.Guard
) and validation-with-return (ResultGuard
).Cons:
Guard
to reuse logic.Guard
andResultGuard
.Option 2: Modify
Guard
to Return the ArgumentModify the existing
Guard
class to return the argument instead ofvoid
.Pros:
Cons:
Personal Preference
I personally prefer Option 2 (modifying
Guard
) because it avoids duplication, maintains backward compatibility, and enhances usability with minimal changes. However, I am open to other suggestions if the maintainers have concerns or alternative approaches in mind.Would the maintainers be open to this enhancement? If so, I can submit a PR with the implementation.
The text was updated successfully, but these errors were encountered: