Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Feature] Extend Guard Methods to Return Validated Arguments

Abierto
  • ¿Algo no está bien?
#1,110 0 comentarios 3 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
csharp
Área
developer-experience

Línea de trabajo

Empieza revisando la Guard API existente y sus métodos; después, compara los enfoques propuestos ResultGuard y modified-Guard. Confirma con los maintainers el comportamiento de retorno previsto y la compatibilidad de la API; se considera terminado cuando los métodos Guard acordados devuelven argumentos validados sin cambiar los fallos de validación ni el uso existente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C#
Estrellas
3.8k
Forks
401
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de CommunityToolkit/dotnet

Todos los issues de CommunityToolkit/dotnet

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.