[Feature] Extend Guard Methods to Return Validated Arguments
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- csharp
- Lĩnh vực
- developer-experience
Hướng nghiên cứu
Bắt đầu bằng việc xem xét Guard API hiện có và các phương thức của nó, sau đó so sánh các cách tiếp cận ResultGuard và modified-Guard được đề xuất. Xác nhận với các maintainer về hành vi trả về dự kiến và khả năng tương thích của API; được xem là hoàn tất khi các phương thức Guard đã thống nhất trả về các đối số đã được xác thực mà không thay đổi các lỗi xác thực hoặc cách sử dụng hiện có.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
Guardclass. - Clear separation between validation-only (
Guard) and validation-with-return (ResultGuard).
Cons:
- Code duplication or the need to refactor
Guardto reuse logic. - Users must choose between
GuardandResultGuard.
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.
- Ngôn ngữ chính
- C#
- Star
- 3.8k
- Fork
- 401
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của CommunityToolkit/dotnet
-
bug :bug:
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
CommunityToolkit/dotnet#1206 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
CommunityToolkit/dotnet#1186 ·
-
bug :bug:
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
CommunityToolkit/dotnet#648 ·
-
bug :bug:
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
CommunityToolkit/dotnet#1215 ·
-
feature request :mailbox_with_mail:
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 45/100
CommunityToolkit/dotnet#1214 ·
Tất cả issue của CommunityToolkit/dotnet
Issue tương tự
-
:watch: Not Triaged dotnet-target-version
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày
-
copilot documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 2 ngày
-
untriaged
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
dotnet/dotnet-api-docs#13124 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
agentic-workflows
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 1 ngày
-
type:bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
BHoM/MidasCivil_Toolkit#441 ·