Wish I could edit a past comment...
But one more thing to note is that System.Nullable<T> has been around since v2, so things like ? and ?. (null-conditional operators) are merely candy to do something the .NET framework has already supported since v2.
Adding a new wrapper type or functionality to a similar level for something like NonNullable would require more than just a change in the framework, but also to each language that would need to support it (and compiler at that note)...sounds kind of scary for a feature that we've got by without up until now and sounds like it has very little need for.
I don't know if it helps any, but it's possible to add a couple things that are still obvious to the consumer of the method and the builder:
1) Add an attribute that you create that accepts the name of the non-nullable argument/parameter, it's job is to have a method that can be run to ensure that any null value passed in for that parameter is cause for an exception.
2) The above attribute can be run on the fly, but is publicly available for external calls
3) An automated test OR Roslyn build-check block of code could be added that can run through all methods with this attribute to ensure that nothing is currently passing in as null obviously/statically in code
public abstract void RunReport(Item param1, Item param2, string extraInformation);
then, on second thought, if something like this were to be added in, i would imagine a derivative of that that may allow more flexibility could be to extend the conditionals we can add to methods/classes:
public abstract void RunReport(Item param1, Item param2, string extraInformation) where param1 not Nullable where param2 not Nullable
1) this would give us more extensability with conditionals (we could now supply conditionals to a property name, rather than just to a type
2) this would also allow us to provide more functional conditions that apply to more than just build-time, but still could be applied to build-time (beyond generics)
What this doesn't do:
1) Prevent a nullable value store for variables within a closure
Though, if you want to do that kind of defensive programming, either your methods are too large, or you need to supply structs and primatives, instead, because they already have this desired behavior.
More often than not, it's preferred not to have extra side effects for your methods anyways, aside from the traditional TrySet methods: bool TryUpdateValueToSomething<TOutVal>(...., out TOutVal value);
You can always have a blocking or check variable that gets the results of your method call, and then only set if it is not null. I know this doesn't help with the monotonous work being done, but I feel hesitant to say that it's common enough to encourage this need by having a change to the language to support it.
One more thing to note about supporting non nullable as a type specifier rather than just another conditional is that you now open up a can of worms that were never there to begin with. How does your method handle setting values for ref/out? You now have to do what for those values in that scenario? outVar = default(TOutVar); ?...what if default(TOutVar) is null because we are dealing with a class (instead of the primatives and structs that prevent this behavior automatically?)
I'm concerned that this buys more trouble than it gains unless we limit just to extending conditionals to support run-time checks and apply to more than just Types and prevent the use of the 'out' and 'ref' specifiers when supplying parameters.
It just starts to sound more and more like UnitTests, Attributes, custom Build-Check rules via Roslyn, and Assertion statements are more and more the way to go with this.
This would be a really great feature. If at the very least, the ability to customize available tags via an attached xml doc that Visual Studio picks up would be swell :)
I also think that if plausible, the ability to add some features to increase it's functionality and usability such as snippet support (to be able to grab values from the entity being documented) could really drive home the use of this feature instead of it being ignored.
See the following 2 links for more information on how it works currently in the VB.NET IDE enviornment:
NateNate supported this idea ·