Can the methods be simplified?

[stap123]

Hello,

I was looking into the new APIs in .NET 6 and C# 10 and came across this. It allows you to use ArgumentException.ThrowIfNull().

It uses this attribute.

Would using this attribute/pattern in the guard methods remove the need for the nameof(xyz) part of the call or am I misunderstanding it's use?

[stap123]

I made a POC here to check if it works. It does seem to achieve the desired outcome!

How much of an improvement would it be to not need to put nameof(parameter) everywhere and just have Guard.Against.Null(parameter) instead of Guard.Against.Null(parameter, nameof(parameter)).

Downsides are this is a .NET 6 feature so need to add a new target and it won't work with the existing targets so it will make the code need #if defs everywhere. Unless a new major version could be created that drops support for the "old" frameworks. Microsoft isn't moving netstandard or netframework forward anymore so maybe that would be ok and anyone wanting/needing the old frameworks would be able to continue to use the old version of the package?

[stap123]

I can put something together if you'd like? (I've not contributed code before so this would be my first PR to an open source project 😟)

I did a quick unit test to check that the message was correct but it would need cleaning up and adding to all of the other extension methods for the final PR.

If you're happy for me to put something together I'll give it a shot. Should I add it for all methods that can be updated?

[ardalis]

Let's start with one. Pick one, adjust it and all of its overloads, write some unit tests, and make a pull request. If it doesn't work or needs any tweaks we can do it with just one and then merge that, then do a follow up to apply same approach to others. That minimizes work so you don't have to apply a common change to every method in the package.

Let me know if you have questions or need help with the pull request process. Thanks!

[stap123]

Would your preferred approach be to maintain support for netstandard and netframework and avoid people having to stay on an older version for support of these?

If so I'll use the #if NETSTANDARD || NETFRAMEWORK approach.

[stap123]

Created a PR #149 let me know if it looks alright.

[ardalis]

Support for both preferred.

[rafaelsc]

This feature should work for NetCore3, NetCore31, net5 and net6 when using C#10.

Recent I was thinking I'm adding this support to some libs.

I didn't tried with GuardClauses or with your POC @stap123. But I imagine we would have a small issue with Guarding with custom messages.

Guard.Against.Null(parameter); // will work nicely and pretty.
Guard.Against.Null(parameter, "Null Found"); // this would set the 'parametersName' to the text 'Null Found' not the custom error message
Guard.Against.Null(parameter, message: "Null Found"); // this will probably work

I would like to try find more elegant way to apply this new C#10 to GuardClauses

[stap123]

C#10 is only supported in net6: see here

This example Guard.Against.Null(parameter, "Null Found"); would already set the parameterName to "Null Found" I think. It's already present as a string argument in that position. We aren't changing the order of the parameters just making the parameterName auto-populate itself essentially.

The below would also still work I think as all 3 arguments are provided.

Guard.Against.Null(parameter, "Param Name", "Null Found");
Guard.Against.Null(parameter, nameof(parameter), "Null Found");

[rafaelsc]

You can Override a default C# language versioning to a old framework.
From the link that you shared.

When your project targets a preview framework that has a corresponding preview language version, the language version used is the preview language version. You use the latest features with that preview in any environment, without affecting projects that target a released .NET Core version.

To make this feature work you need you need the code be compiled in C#10 and the Attribute be available, and the Attribute is present in .Net Core 3 and Above.

[stap123]

But that article also says:

C# 9.0 is supported only on .NET 5 and newer versions.

Unless I'm misunderstanding something that means using a C# 9.0 feature in anything less than .NET 5 is not supported by Microsoft and therefore it would be reckless to implement anything that goes against this in a library. Following the same logic C#10.0 features are likely only supported in .NET 6 and newer versions.

Unfortunately I think that means that what you're proposing isn't a supported scenario from Microsoft?

[rafaelsc]

Yes. Is not supported by is Possible. I use C#9 with NetCore3 all the time.