Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Feature] Extend Guard Methods to Return Validated Arguments

Aperta
  • Qualcosa non va?
#1,110 0 commenti 3 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
csharp
Ambito
developer-experience

Direzione di ricerca

Inizia esaminando la Guard API esistente e i relativi metodi, quindi confronta gli approcci proposti ResultGuard e modified-Guard. Conferma con i maintainer il comportamento di ritorno previsto e la compatibilità dell'API; il lavoro è completato quando i metodi Guard concordati restituiscono argomenti validati senza modificare gli errori di validazione né l'utilizzo esistente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C#
Stelle
3.8k
Fork
401
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CommunityToolkit/dotnet

Tutte le issue di CommunityToolkit/dotnet

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.