Question: How is !! envisaged to be used?

[dustinmoris]

After David Fowler posted this GitHub issue on Twitter I have discovered the !! operator for the first time which seems to have already been added to the upcoming version of C#.

I wanted to ask how the C# language team envisaged this new operator to be used?

If I understand this correctly this is a short hand form to essentially replace if (x == null) throw new ArgumentNullException(nameof(x));, right?

Essentially, unlike the nullable (e.g. string?) feature, which is a compile time check, this is an actual runtime check.

My first question is, are my above assumptions correct?

If yes, is this simply a new operator which converts random unhandled NullReferenceExceptions to random unhandled ArgumentNullExceptions? I see very little actual value added by essentially just changing my code to throw a differently named exception or does this operator add any extra benefits which I might have missed?

The second question I have is how is this new operator supposed to be used alongside the nullable feature?

Here's what I find strange. If I was to write "clean" code then I would simply only have two options for declaring a method argument:

1. It allows null
2. It doesn't allow null

There is no middle ground (a little bit null, but not too much null) if you see what I mean. So in connection with the nullable feature I essentially end up decorating each and every argument across an entire codebase with either ? or !!, because either I want to show that it can have null or it cannot have null. This is a lot of operator noise and it's unfortunate that the "naked" form of declaring an argument doesn't cover at least one of a binary choice in my code going forward.

On the other hand I could be wrong, and the new !! operator is not meant to be used alongside the nullable feature and perhaps a runtime checking replacement for the previous compiler feature. That would make sense, but then I find it very disturbing that two super recent features are competing against each other, one very quickly deprecating another and making the language unnecessarily complex and bloated. It also makes language design choices very short sighted if this was the case.

So you can see I struggle to really get my head around how this new operator is supposed to be used and how it is meant to fit into the rest of C#.

Would you be able to shed some light on this and feel free to correct me where I'm wrong :)

Thank you! 🙏

[HaloFour]

The proposal and discussion are here: #2145

TL;DR:

NRTs don't change the behavior of code, they only provide information to the compiler to allow it to warn on unexpected attempts to pass null to a method. If someone ignores the warning and passes null anyway (or disables the feature) then the code continues to behave as it did before.

Null validation is intended to replace the code currently required to do null argument validation in methods, and is it intended to have an impact on the behavior of the method. It does replace what might be a NullReferenceException later, but immediately instead of potentially much later and in the middle of other logic and far away from that original errand method call.

[HaloFour]

@huysentruitw

There's a lot of precedence as to what happens when a language has a massive schism and splits the ecosystem. It can take well over a decade for that rift to heal, if it ever does.

[CyrusNajmabadi]

This image shows how hard that is today:

Halo didn't say it was hard. He said it solve the ceremony problem for something incredibly common. People aren't asking for an improvement here because it's hard. THey're asking for an improvement because they feel that their code is full of more-noise-than-signal due to how ungainly it is to write this full form of this out today. It's common to have code where this simple concept dominates the amount of real code in a method, obscuring the actual interesting domain specific work being done.

Furthermore, there are many places in the language (like constructors/iterators/etc.) where the existing pattern is truly painful which this outright solves. For example:

public MyType(string s1, string s2) : base(bufferSize: s1.Length + s2.Length)
{
}

How do you cleanly check these parameters for null and give good argument null exceptions? There are ways to workaround this, but it's all incredibly ungainly and again obscures from the core logic you care about.

For iterators, the common pattern is to write the following:

IEnumerable<int> SomeIterator(string s1, string s2)
{
    // manual arg checks here.

    return SomeIteratorImpl(s1, s2);

    IEnumerable<int> SomeIteratorImpl(string s1, string s2)
    {
        // stuff
        yield return whatever;
    }
}

so taht you get appropriate arg checking at the right time (when the method is called, not when the iterator is enumerated).

[huysentruitw]

How do you cleanly check these parameters for null and give good argument null exceptions?

In my world, you wouldn't have to check for null as the caller should already have been forced to check for null before constructing MyType or calling SomeIterator, otherwise the code would not compile. string s1 = null should simlpy be forbidden everywhere. The same as string[] a = new string[20]; because it should be string?[] a = new string?[20], unless you initialize the array with actual string values. That should be the only way we need to head to with C#, or perhaps an other language D# or E should be built, which is somewhere between C# and F# 😅

Anyway, to avoid running in circles I would like to end this discussion here. You're telling us that our feedback is noted and I very much appreciate that‼️ Hope to see proof of that. In the meanwhile I would suggest to stop adding unnecessary features that do not align with moving C# forward.

[bradwilson]

In my world, you wouldn't have to check for null

Perfectly reasonable for an app developer, never happening for a library developer.

[huysentruitw]

Perfectly reasonable for an app developer, never happening for a library developer.

That's because you're looking at this from the current perspective. What I'm trying to make clear is that, whenever you use a external dependency (NuGet package or project reference) that has NRT enabled, your project also must enable NRT or add exclamation marks to override the behavior if you're sure you're not passing null (which you already should be if you don't want the potential ANE being thrown). So if I use your library with NRT enabled, I would also have to (enforced by compiler) enable NRT and check for null in advance before calling your methods. That's the only way to get rid of this and stop having to fear null is being passed where not allowed.

[nathan130200]

I hope they don't turn C# to be like Kotlin. Kotlin enforces this weird nullsafety """best practives""" that make code worse.

But what about nullable value types? int? count!! (based on .HasValue == false)?
Or cannot be null + default value: string format!! = "Awesome default value"

[Runaurufu]

This is exactly pov that i think this !! will not be useful, we only will receive an feedback in runtime.

It seems it will be even worse - you will get compiler warning if you are calling your code (so presumably inside same project??) but absolutely nothing when calling 3rd party dll...

[CyrusNajmabadi]

You will get the same NRT warnings/errors today that you would get against that library.

Simiarly, you will get the same warnings/errors today that you would get if that library has if (param == null) throw.

Nothing changes here wrt to that.

[mapgie]

It'll warn at compile time, and it'll throw at runtime. That's what it's designed to do. The !! only replaces what would be a manually-written null check within the method that would throw. It doesn't change anything else and it doesn't affect the type system or the signature of that method in any way.

Why would I specify int? x if I then want an unhandled exception to be thrown when I find that my value type is indeed null?

[tannergooding]

Why would I specify int? x if I then want an unhandled exception to be thrown when I find that my value type is indeed null?

That's part of the point. People keep using T? x!! as an example of some unreadable syntax or for other illogical behavior when the definition of T? x!! is likely something you will never see.

If you accept null, then you have just T? x
If you don't accept null, then you have T x
If you want to enforce not null, then you can use if (x is null) { throw new ArgumentNullException(nameof(x)); } or depend on the .NET 6 (7?) library API ArgumentNullException.ThrowIfNull(x) or you'll be able to utilize the new language syntax T x!!.

With all the annotations/context that have already been given about why this syntax has been chosen so far, what suggestions and considerations have been already raised and discussed (including by the community) over the past 3 years, and that the feature isn't set in stone nor is the syntax a hard/fixed choice.

What many are missing is that they are suggesting alternatives that aren't new, that have already had in depth and end-to-end discussions, and were decided to be the wrong path. Its not an unwillingness to change or take input; its that most are not giving new input or going back to get the context on what has already been raised/discussed. They saw something they didn't like and decided to chime in; where-as for features that they do like or are indifferent about, they don't.

That's also why this language feature has some 540 replies and 40 answers; but most of the other C# 11 language features (and even proposed features) barely have a peep on them. When in practice, I'm sure there are tons of people not commenting that think the features are great, perfect, fine, etc or are completely indifferent on it overall.

[JendaPerl]

If you implement an interface you can't decide to change the signature from int? to int just because you can't do anything sensible if passed a null value. That's why Foo(int? x!!) might make sense.

I'd still very much prefer Foo(int?! x) and Bar(Person! dude). Even if ? affects (mostly) compile time and ! affects (mostly) runtime.

[iancooper]

I think that adding annotations to the type, in the form of punctuation symbols, has low usability. We don't make variable names have special meaning anywhere else, and the industry knowledge about the failure modes that Hungarian notation set up for doing this by convention suggests this does not work out well.

If the goal is to provide a runtime check on a property then using a [NotNull] attribute on the parameter would be far more in keeping with the established idioms of C#.

Use of !! feels like it is bolted on from another language, and goes further to worsen the belief that C# is becoming a "kitchen sink language" where everything is just tossed in, regardless of whether it suits the idioms of the language.

The usage of !! on a variable name fails the "principle of least surprise" as it introduces idioms that don't fit with the rest of the language. Developers won't have trained their eye to look for symbols in parameter names, so this is likely to go unnoticed, whereas the use of attributes on parameters is understood.

Finally using [NotNull] fits with earlier exploration of Code Contracts and would open up the possibility of exploring what value that space could offer, although I recognize earlier attempts on Code Contracts were not widely adopted

[CyrusNajmabadi]

Which is irrelevant in this discussion as !! would not so gracefully throw ArgumentNullException

That is gracefully handling it.

This pattern already exists. The runtime easily users it in thousands of places. It's just now simpler to write and allows the more important code to stand out more instead of needing N lines of arg checking at the start of methods and constructors.

[Runaurufu]

This was considered and rejected. It would make the entire feature a non starter for the trillions of lines of existing code out there.

How.. it will not affect even single line of existing code. There are no ! tokens here.

Nrt aims to solve a problem for an the code that exists, not a the new 1% of code being added to that.

It had to be completely safe to move to for users and that means you have to be able to turn it in and not worry about anything going wrong in production.

And yet you still need to build project with NRT enabled to benefit from it... the core problem with NRT is that it does not bring non-nullable but "most-likely non-nullable" so as you said - it does not affect existing code...
So what we can have is compile time option which would turn NRT string into string! (but only in CLR output but not in source code) so that would happen ONLY if user wishes to do so.. and also bring true non-nullability for everybody (not only NRT users) and not just promise of such.

[nathan130200]

Use of !! feels like it is bolted on from another language

You are right, was from kotlin. In kotlin they use this horrible pattern to prevent null references, but sometimes enforces null safety where exists zero possibility to be null, like:

MyClass obj = new MyClass();


void IsMyClassNull(MyClass o){
 // suff
}

This is valid on C#, in kotlin you must be forced to call everyting on IsMyClassNull with !! that increase 2x more code and makes everything horrible to read. So i wanna call o.ToString() inside function kotlin will say Maybe 'o' can be null here, use !! even you are 100% sure that this never should happen.

[HaloFour]

@nathan130200

I believe that you aren't interpreting this feature correctly. That code above is totally unaffected by this proposal. It compiles and works fine, even with NRTs enabled, with no compile warnings. There is no need to apply !! to the method signature, and it's not even legal to apply it at the callsite as you seem to imply.

The only reason you'd ever want to apply !! is if you wanted the method IsMyClassNull to throw an ArgumentNullException if null was passed. This is still possible to do via disabling NRTs, reflection, invocation from other languages, etc. The !! gives you a safeguard that within the method that o cannot be null. It replaces a manual null check that would have to otherwise write to achieve the same result.

[CyrusNajmabadi]

@HaloFour is correct. The meaning in kotlin is unrelated to the meaning here. In kotlin it's the unsafe convert-from-nullable-to-non-nullable operator (which throws if the value was null). That's not what it is here. Here it's simply: inject a null check for this parameter at the start of hte member body.

[Mindstyler]

Please just add ! to the type and not the variable name.
1 - That makes it consistent with nullable annotations: string? obj and string! obj
2 - it also gets rid of strange behaviour, e.g.: string? obj!! what is happening here?? we are allowed to pass null but it also throws an exception when passed null? that's bad design in my opinion. string?! obj would already throw an error when writing the code.

[CyrusNajmabadi]

Yes, it cannot be used after any type name.

Then allowing it after the type name here sounds like it would just be confusing.

It is meant for method argument, and there it can be a suffix to the argument type.

Since it's not part of hte type, having it be in the type section seems really problematic. It relates simply to this variable and how values flow into it. So marking the variable itself, and at the place where the value enters, seems the most sensible.

[tmds]

Then allowing it after the type name here sounds like it would just be confusing.

I find it more natural and less confusing.

It precedes the variable name instead of being a suffix.

[CyrusNajmabadi]

I'm not sure why preceding the variable name is a virtue.

[tmds]

The reason for doing it as a suffix of the type (thus preceding the variable name) would be to match the nullable is syntax.

string obj  // may be null, NRT: should not be null.
string? obj // may be null
string! obj // throws when null

[CyrusNajmabadi]

I understand. But it's not part of the type. So matchign that would be problematic as it would imply it was part of the type when it really wasn't. FOr example, people would certainly expect that they could then use string! in all the places that string could be used.

[Runaurufu]

There is no middle ground (a little bit null, but not too much null) if you see what I mean. So in connection with the nullable feature I essentially end up decorating each and every argument across an entire codebase with either ? or !!, because either I want to show that it can have null or it cannot have null. This is a lot of operator noise and it's unfortunate that the "naked" form of declaring an argument doesn't cover at least one of a binary choice in my code going forward.

There are two things to that..

1. you wrongly assume that !! is showing anything to outside world. It does not. For outside world m(string s!!) is same as m(string s).
   Null check is done within method... It is not even visible for reflection..
   Moreover !! does not cause any compile-time issues other than warning... which I assume will not be triggered when you call 3rd party library as I have no idea how you could do this considering that lack of info in reflections and

No, it's not in the metadata, just as it wouldn't be if that method had code that checked for null and threw an exception internally.

2. "naked" and default (without NRT) form covers this:
   Reference types fall into "It allows null"
   Value types fall into "It doesn't allow null"
   Nullables fall into "It alllows null"

Now what we lack is "I am reference type but doesn't allow null"... and !! is still not solving it as I can still do this:
void fun(string me!) { me = null; }

So why on Earth we cannot have ! working on types system level (like ? does) which would let us cover all 4 cases for everyone without using OPTIONAL things like NRT or !!?

[HaloFour]

NRTs can be very disruptive to a codebase. It doesn't break everything only because it was very carefully designed to have a very light touch, but it's not uncommon for a project to generate a lot of warnings and have to be converted iteratively, file by file.

The idea of using ! to denote not-null types was already discussed, at great length. That was part of the original design of NRTs, ! is not nullable and blank was nullable. For a short while there were even three flavors, ! for not nullable, ? for nullable and blank for oblivious. It was eventually decided that since the vast majority of parameters are not intended to be null that not nullable should be the default. That has long since shipped and the lack of a suffix already means not nullable. There's no reason to change that and there's no reason to tie this proposal into it in any way.

[Runaurufu]

It was eventually decided that since the vast majority of parameters are not intended to be null that not nullable should be the default.

That is true only for NRT code... and here we talk about !! which aims mostly for use when interacting with non-NRT code...
Problem with NRT is that its string is not guaranteed to be non-nullable.

So instead of introducing !! for NRT to work without issues with non-NRT I really see more value in having that duality:
in NRT:
string - non-nullable
string? - nullable

without NRT:
string - nullable
string! - non-nullable

That means that "by default" in NRT you still would have non-nullable string as you pointed out but at the same time NRT issue of null passed into string parameter would be removed and at the same time non-NRT would have support for non-nullable types... nothing would get broken, everyone would be happy...

Example: while calling NRT foo(string s) from NRT you would use string type and from non-NRT would use string! type.
That seems so much more clear and straightforward approach.

[CyrusNajmabadi]

Example: while calling NRT foo(string s) from NRT you would use string type

This is not sufficient and woudl still allow nulls to flow in. You can have 100% NRT safe code (on both sides of the caller/callee) and still have nulls absolutely flow in in many places. Code must still defend itself from that.

[Runaurufu]

This is not sufficient and woudl still allow nulls to flow in. You can have 100% NRT safe code (on both sides of the caller/callee) and still have nulls absolutely flow in in many places. Code must still defend itself from that.

But why... enabling NRT should protect me from receiving nulls for non-nullable types... and it mostly does so when I write NRT code. Problem is with calling NRT from non-NRT which should also be handled by compiler and ! would allow that.

[CyrusNajmabadi]

But why...

Because that's what NRT is. It's not a set of rules that prevent nulls in all cases. THe only rules that could do that would be enormously onerous and unacceptable to the vast majority of the ecosystem. For example, the false positive rate on such rules is through the roof. For example, even basic patterns like the following would start warning:

if (a.b != null)
   DoSomethingWithNonNull(a.b);

NRT is a bunch of heuristics around common coding patterns. It seems to provide very high signal to noise, and that means it's more conservative about when it fires and hte sorts of assumptions it makes when looking at your code.

enabling NRT should protect me from receiving nulls for non-nullable types...

It does not.

and it mostly does so

Right. mostly. That's why we need features like this.

Problem is with calling NRT from non-NRT

No, as has been mentioned numerous times, calling NRT from NRT absolutely has nulls that happen and have to be dealt with.

[iancooper]

That is invisible from outside.. it is just name postfix silently translated into null check...

But from a usability perspective it appears to be part of the parameter name, folks aren't used to seeing a postfix on a parameter. That may not be what it is, but it is how it appears. An explicit notnull keyword would be better if we are concerned about the usage of an attribute at runtime - although the use of attributes at runtime is common in frameworks. Using a symbol that appears to be part of the name looks like syntactical noise.

This has been debated in some form for the past 6+ years

That is often a warning sign that the design is problematic...

[HaloFour]

That is often a warning sign that the design is problematic...

Most features here go through a lengthy design process. This proposal was winnowed down from the much larger code contracts proposals which were originally discussed when Roslyn was still on CodePlex. That design got mired in a lot of complexity, particularly around policy (what to do when the contract is violated). This proposal is vastly simpler and only seeks to replace what is an extremely common pattern in code. It may eventually expand beyond that.

[CyrusNajmabadi]

That is often a warning sign that the design is problematic...

Note this is a lose-lose situation. If we debate things thoroughly, it is viewed as a sign there is a problem. If we speed through things, it will be viewed as a sign that we didn't consider enough.

[iancooper]

This proposal is vastly simpler

It may be simpler, but I am not sure it is simple. It's possible that this change has a higher cost to value for the BCL where there maybe many more checks on null arguments than there are in many app developer codebases, and as such optimizing for a short postfix operator may seem better than optimizing for clarity and sympathy with expectations of syntax.

But this is sufficiently 'hidden' from the way most C# developers write code, that I would issue style guidance to any team I worked with to not use it. However, a notnull keyword would be obvious, expected, and add real value.

It may eventually expand beyond that.
How? If you goal is to provide greater support for code contracts you are going to rapidly run out of operators, or create some sort of semantic soup of symbols. Surely you would need a very different approach to expose contractual agreements between caller and callee. Attributes seem much clearer for that context than syntactic sugar.

When you make something syntatic sugar your goal, such as with async, is to remove complexity from developers. I would suggest that the conditional block does not represent complexity. It may represent a burden to regularly have to write it.

If there is a burden to writing it - it's just boilerplate code - then a more typical answers would be to use attributes for code generation or generic types.

The addition of syntactical elements just creates further complexity around the language - developers now have to be alert to postfix operators on arguments.

So it feels like we have added complexity, when what we needed to create was not simplicity, but simply remove the burden of writing code. There are more obvious solutions to that.

It's this test - the obviousness of the solution - that I think this fails.

[HaloFour]

But this is sufficiently 'hidden' from the way most C# developers write code, that I would issue style guidance to any team I worked with to not use it.

You're free to not use it and to continue to write out null checks manually in code. I imagine there will be an editor option to warn/error on use of the feature, as there is with most features.

However, a notnull keyword would be obvious, expected, and add real value.

Lots of options were considered: https://github.com/dotnet/csharplang/blob/main/meetings/2020/LDM-2020-06-17.md
But the team ultimately agreed on !!: https://github.com/dotnet/csharplang/blob/main/meetings/2020/LDM-2020-06-24.md#Parameter-Null-Checking

then a more typical answers would be to use attributes for code generation or generic types.

Custom attributes don't affect code behavior in that manner, and using source generators for AOP has been effectively rejected by the language team. Changing that in the compiler would also require shipping a completely separate set of attributes specifically for this feature as changing the behavior of the code for any of the existing attributes would be a big breaking change.

[ericsampson]

FWIW, it's too bad that those links weren't added to the text of the original proposal (#2145) as an update.

[AartBluestoke]

The addition of syntactical elements just creates further complexity around the language - developers now have to be alert to postfix operators on arguments.

A developer doesn't need to care about the postfix operator on things it calls, and an implementor of a function, when they are about to put in a null check, can do so via !! rather than a 1-4 lines of boilerplate of code.

Given Interface IFoo{f(string? a, string b); }, it doesn't matter to the user of the function if the implementation of b has !! on it or not; if you pass null to a non nullable parameter expect an exception.

[CyrusNajmabadi]

@AartBluestoke is correct. This wouldn't even be anything the IDE would proffer up in things like signature-help/intellisense/etc. The signatures on the consumption side will look exactly like they look today. It's just an aspect of the internals of the method that are affected. This is similar to how unsafe/partial/async/etc. are in the sig, but have zero effect on callers. It's all about what the compiler does with the internals.

[Vake93]

May have suggested this to be a flag that we can set on the csproj as

  <PropertyGroup>
    <Nullable>throw</Nullable>
  </PropertyGroup>

or #nullable thrown

was this or something similar considered as an option, if so just curious why was that approach not selected.

As I see it that would have improved the existing nullable reference type experience and would have been easier to adopt as well on application code if the nullable annotations are already there.

[themisir]

Still !! end of the method parameters doesn't look right to me, but at the same time, I don't have a better suggestion as well. 😝

I think, and hope !! will be temporary solution until the day where we could get some sort of sound null safety on C# and after that we can deprecate !! syntax as compiler will do necessary work with existing NRT annotations.

But it will probably take a long time to come.

I just worry that C# becomes bloated one day with different set features for supporting similar features. But I guess it's the cost we have to pay for keeping language stable.

[CyrusNajmabadi]

I think, and hope !! will be temporary solution until the day where we could get some sort of sound null safety on C# and after that we can deprecate !! syntax as compiler will do necessary work with existing NRT annotations.

Well, if we can actually get null-safety, we'd deprecate the NRT annotations as well :)

I just worry that C# becomes bloated one day with different set features for supporting similar features. But I guess it's the cost we have to pay for keeping language stable.

If it makes you feel better, this phrase has been uttered in nearly the exact same way for every release of the language :)

[Pentadome]

The fact that string? parameter!! would become correct syntax even though it makes no sense seems very wrong to me

[Dojan5]

The fact that string? parameter!! would become correct syntax even though it makes no sense seems very wrong to me

I concur; it's ridiculous. How can you have a nullable that cannot be null? That makes no sense. Extending the null-coalescing operator makes more sense to me. I know that in this case it doesn't really coalesce, but if you think of ?? as "if left null then right" it makes sense.

[HaloFour]

The fact that string? parameter!! would become correct syntax even though it makes no sense seems very wrong to me

Which is why the compiler generates a warning when you do this.

[CyrusNajmabadi]

!! serves exactly one purpose. A shorthand for the very common pattern around null checking a parameter. That's it.

[HaloFour]

If the team went with nonnull or some other approach there'd be just as loud of an outcry from folks that they don't like that design. I guarantee that there wasn't unanimous for this syntax on the design team, and the language would pretty much stop evolving if that was ever required. Language design is compromise. I can guarantee that these considerations regarding NRTs and readability were factored into the consideration, though.

[Runaurufu]

A shorthand for the very common pattern

Problem with such approach is that when introduced I would like to have also shorthand for check that array is not empty... and string is not empty... or int is not 0...

so in a way making !! check for not being default...

[CyrusNajmabadi]

and this makes the code harder to read,

We disagree. I find it completely fine to read.

[iancooper]

!! serves exactly one purpose. A shorthand for the very common pattern around null checking a parameter. That's it.

But you have introduced in a new semantic concept, postfix operators that result in runtime checks. The weight of that is large. Whether we use it or not. And it either now becomes an outlier - let's not do that again because feedback was bad - so we have to forever internalize - hey there is this weird edge case set of semantics around null argument checking you have to just learn as an exception - or more features develop on this, and we drown in symbols that we have to watch for.

It feels a lot like local optima, that this was designed to ease pain in the BCL, but without considering the cost to the wider ecosystem

[CyrusNajmabadi]

It feels a lot like local optima, that this was designed to ease pain in the BCL, but without considering the cost to the wider ecosystem

It was designed to ease the pain for all code that has to currently do null checks. The impact on the wider ecosystem was considered.

[javiercampos]

I'm going to copy here what I wrote on the implementation MR thread:

Please stop adding weird symbols for nullability reasons. Everything is already confusing enough with using the same nullability symbols for value and reference types (int?/string?) with completely different meaning and behaviors.

The feature itself is fine, but it could be easily added with something like:

void M([ThrowIfNull] string a) {}

Which is explicit, and readable... because the next thing you know, we'll be reading the language when loud as questioning and shouting stuff (string?[]? M(int? a!!) anyone?).

This is all making the language completely unreadable

And yes, I understand [ThrowIfNull] could clash with custom attributes, was just an example of something to make it readable... it could be <ThrowIfNull> or something else, but the trend of adding symbols to everything will never stop if we follow this route.

You could even use notnull which is already a C# keyword (and used for constraints), something like:

void M(notnull string a) {}

Which doesn't add any new keywords (notnull is already a constraint-related keyword), or symbols, it's readable, it's non-breaking, works with or without NRT enabled, works fine for value-nullables (Nullable<T>) and prefixing like that before the type doesn't "look weird" anymore since async was introduced (even for things -like async- that are not part of a method's signature/contract, nor visible to the caller)

[iancooper]

That's just how it goes when you have an audience this big and have to weigh in so many varying aspects of a design.

But it seems to be being explicitly stated that the main goal here was to help the BCL team avoid writing boilerplate, and to optimize it. So it seems as though one group is being satisfied and not others. I can't think of anywhere where this was widely trailed for everyone to provide feedback.

The problems are:

• The scenario - code generation to reduce boilerplate in the BCL - does not seem like a good fit for a language feature
• It is new paradigm - postfix operators for parameters controlling the production of generated code
• The paradigm is not extensible to new use cases, making this feature single purpose. So it is a new paradigm with one purpose i.e. an exception which therefore has poor usability and high cognitive load
• It does not work as expected, because the postfix operator is not exposed in package code, so behavior of calling a method cannot be inferred from having this in the signature and is thus likely to be unexpected.

The current discourse here is often of the form that feels more like bikeshedding

And the response from the team seems particularly "ivory tower" - we don't care what you think, and we don't care if you will use it or not. Is it any surprise that you don't get feedback on most language feature when the attitude is "your opinion is just bikeshedding, far smarter people have already discussed this, please go away". I don't think those responses are helpful to improving the language

[HaloFour]

I am a member of the community, not of the language design team. The problem is that such a survey would not cover 80% or 55% or 40% of the developers. It would cover a tiny fraction of a tiny fraction of a percent, mostly made up of people who are annoyed at whatever the current situation happens to be. And they would likely vote across the board for anything different, a rainbow of possible sheds. And if any of those were chosen instead of the current decision that process would repeat itself, over and over and over again, as the next Tweet drives a different community of outraged developers. C# isn't designed that way. No programming language is designed that way, and for very good reason.

Of all of the comments here I've yet to see something new. Every single one of these options were already considered by the design team, up to and including doing nothing. If there's no new information why should that drive a relitigation of the design process that has already occurred?

[HaloFour]

@iancooper

But it seems to be being explicitly stated that the main goal here was to help the BCL team avoid writing boilerplate, and to optimize it. So it seems as though one group is being satisfied and not others.

They are one of the stakeholders, and quite a big one. Many features have been added to the language specifically because they have demonstrated a use for them. That doesn't mean that they are the exclusive beneficiary, by far. Not every feature needs to meet the needs of every developer. The old adage is that anyone only uses 10% of the features, but everyone uses a different 10%.

we don't care what you think, and we don't care if you will use it or not

Because literally every language feature ever added to the language gets this kind of reaction. Generics, extension methods, LINQ, coroutines, pattern matching, optional parameters, dynamic, default implementations, etc. Most of them got substantially more negative feedback than this, including from within Microsoft. Language design isn't a game of trying to please everyone because that is an impossible goal.

[CyrusNajmabadi]

But it seems to be being explicitly stated that the main goal here was to help the BCL team avoid writing boilerplate,

No. That was not what was stated. As I said above, the purpose of the feature is for anyone to have a much simpler syntax for the very common task of checking a parameter for null and throwing in that case. There are currently tens of millions of these checks over the codebases we look at, and this is simply a useful shorthand to allow those codebases to have less 'noise' and have more 'signal' in their method bodies.

[CyrusNajmabadi]

And the response from the team seems particularly "ivory tower" - we don't care what you think

The exact opposite was stated. The opinions here are cared about a great deal. And all of these opinions and directions were debated heavily when the feature was worked in for the past couple of years.

But just because that happens doesn't mean the end result will satisfy everyone with an opinion. Again, I'm on the design team and there have been many language changes Ipersonally do not like and have fought against. Having a spilt of opinions on lang changes is the norm for everything we've done.

[MgSam]

I'm still strongly against this feature.

• It covers only a small slice of the validations one might need to do on parameters. Some other extremely common ones:

void Foo(string bar) 
{
    if (string.IsNullOrEmpty(bar)) throw new ArgumentException(nameof(bar)); //Extremely common to want to guard against empty or whitespace strings
}

void Foo2(string bar) 
{
    bar ??= "howdy do"; //Extremely common to want to default a value if its null since parameter defaults are required to be compile-time constants. null allows us to work around that limitation
}

• As demonstrated in many of the comments here, it continues C# down the path of operator bloat. C# is becoming more like Perl each year. And that isn't a good thing.
• The "best practice" C# is becoming more and more verbose over time rather than less. Soon "best practice" will have required on properties (or whatever keyword is chosen), nullability annotations everywhere, null checking !!s on every parameter, and ConfigureAwait(false) on nearly every use of await. We're supposed to aim for the pit of success - the right thing to do should be the easiest.

[CyrusNajmabadi]

Is is not null considered an operator,

Is is not (no pun intended) :D

It's two pattern operators. The is pattern and the not pattern, each of which is independent.

My impression is that folks are "revolting" (mostly) against cryptic-looking operators.

There is no such sentiment on the team. We use sigils where we think they're the right choice, and words where we feel otherwise. You'll see that in practically every release of the language.

[MgSam]

As demonstrated in many of the comments here, it continues C# down the path of operator bloat.

C# has never shied away from operators. You're using the wrong language if you want that to be one of our design goals. It's simply not something that is believed in by the team, nor is it something we're going to avoid in the future either.

What you're saying is simply not true. The mantra used to be that all new features started at -1000 points and needed to overcome the massive justification needed to be added to the language. Operators and keywords being especially sensitive because they add baggage that will remain forever more. And operators via punctuation were especially frowned against. See await as the quintessential example of this.

Now it seems like features start at +1000 points if they're suggested by Microsoft itself, and there needs to be massive community backlash to not do them.

[MgSam]

the right thing to do should be the easiest.

This is easier than the code needed to write prior to this feature.

"Most" code doesn't and shouldn't need null checking in the parameters unless its in a public library. But inevitably now that this operator exists it will be "best practice" to use it everywhere. And inevitably Visual Studio and R# will nag us to do so once its added into the language. So our code gets a little uglier. And when we need to do some more validation besides null checking it gets more confusing to read and reason about.

[CyrusNajmabadi]

Most of the Guard pattern implementations are more than adequate in dealing with it and verbose enough that less experienced devs can get to grips with it quickly.

None of that has anything to do with us adding operators or not.

And, in this case, we felt the operator was appropriate here and taht this feature overcame those points.

And operators via punctuation were especially frowned against.

This is not true. Where we have felt that keywords are the better solution, we use them. Where we feel that operator punctuation is a better solution, we use that. As i stated above:

C# has never shied away from operators. You're using the wrong language if you want that to be one of our design goals. It's simply not something that is believed in by the team, nor is it something we're going to avoid in the future either.

Now it seems like features start at +1000 points if they're suggested by Microsoft itself, and there needs to be massive community backlash to not do them.

This feature started at teh same place and had to withstand an enormous amount of scrutiny and design adjustments to get through our process, the same as others.

[CyrusNajmabadi]

"Most" code doesn't and shouldn't need null checking in the parameters unless its in a public library.

Then they don't need to use this operator.

But inevitably now that this operator exists it will be "best practice" to use it everywhere.

No one has ever claimed or pushed for that. As i said before. !! exists as a shorthand for the code that you would otherwise be using if (...) throw ArgumentNullException for. If your code has no need for that pattern, then it has no need for !!. That is the official guidance here.

And inevitably Visual Studio and R# will nag us to do so once its added into the language.

Visual studio will not nag you to use this ever. For the feature side of this:

1. if you already have a null check, it will suggest simplifying to thsi form (which maintains equal runtime semantics).
2. if you explicitly bring up the refactorings available on a method, we offer to add a null check. That refactoring already has existed for numerous releases to speed up the work of adding null checks where you think it is appropriate.

In no way will we nag you to use this otherwise. I cannot make any claims about R#. If they choose to do things differently, that's on them.

So our code gets a little uglier.

That's subjective. I find it far cleaner than the explicit 'if' check.

And when we need to do some more validation besides null checking it gets more confusing to read and reason about.

In that case, you can choose what to do with your null checks. There is no lang requirement that you use this. There is no tooling requirement that forces this. It's all an additional option at your disposal. But all the existing patterns still continue to work and will do so in perpetituity.

This is the same with practically all features we add. When we added ?. there was no requirement to use it. And yes, many people thought it was 'ugly'. But we still offer it as many people vastly prefer it to the much more verbose approach you have to write otherwise. If you're in that group, we understand and get that you don't want to use it. And we even provide mechanisms so that you can disallow this entirely in your codebases. However, we view this as still having enough value to the ecosystem that we make it available as an optional feature for anyone to use if they believe the value is worth it to them.

[HaloFour]

A bit tangential but I do really hope that those individuals who are taking an interest in the design process of the language stick around. The feedback is welcome and this process does happen out in the open. The linked issue and meeting notes hopefully give some insight into how the sausage is made.

It may seem like that feedback is hitting a wall at the moment but I think that's largely due to this particular feature having already been shepherded pretty deep through the design process and already merged into the Roslyn codebase.

I am not on the language design team nor do I speak for them.

[MgSam]

@CyrusNajmabadi To be fair, this feature has always been unpopular. It's the fourth most downvoted feature in the entire C# lang repo. You guys have received that feedback for years before implementing it. Nothing about people's reaction in this discussion should come as a surprise to you guys.

[HaloFour]

My question relates to this specific feature.

Language design decisions are published to this repository, because this repository is where the language design is occurring. That's true of this feature and every other feature. As language feature proposals solidify into something that looks like it will make it into the language the language team does regularly present on it. So do other people in the community, such as the following:

https://www.infoq.com/news/2020/06/CSharp-9-Null/
https://www.infoq.com/news/2020/01/CSharp-Null-Validation/
https://exceptionnotfound.net/bite-size-csharp-10-null-parameter-checking/
https://hackernoon.com/c-parameter-null-validation-explained-9h113uca
https://www.daveabrock.com/2020/06/24/simplified-null-validation/

[CyrusNajmabadi]

@MgSam It's also one of the highest upvoted features ever:

You guys have received that feedback for years before implementing it.

Yes. And that affected the design and was absolutely incorporated into the decision making.

Nothing about people's reaction in this discussion should come as a surprise to you guys.

I haven't argued that it was a surprise :)

[HaloFour]

@MgSam

I'd suggest more people are annoyed with the syntax than with the concept of the feature, given the various forms of bikeshedding that has arisen on this discussion. I'd think that the number of people who actually believe that such a feature isn't useful to be in the minority.

This reminds me a great deal of the discussion around private protected.

[CyrusNajmabadi]

My question relates to this specific feature.

I would recommend directly subscribing here as it is the canonical source of information directly from us, without any outside interpretation.

Csharplang is primarily for async discussion around it. Discord is primarily for synchronous discussion (though async still happens).

[alrz]

void Foo(string bar) 
{
    if (string.IsNullOrEmpty(bar)) throw new ArgumentException(nameof(bar)); //Extremely common to want to guard against empty or whitespace strings
}

I think "method contracts" feature aims to solve this problem.
For null-checking in particular the signature already conveys this info; there's only a need to enforce it at runtime. #2145 (comment)

[DigiBanks99]

My biggest issue with this is that it makes it extremely difficult to read the code and it isn't intuitive.

From a readability perspective, the examples already mentioned numerous times above show how convoluted the syntax becomes. Additionally, when doing code reviews, reasoning about the parameters in this way is very difficult. Should the code be formatted across multiple lines or use long parameter names, these clumsy operators get missed. For example:

public static Task<Patient> GenerateNewInPatientRecordAsync(Person patientPersonRecord!!, Person? accountHolderRecord, bool isPatientSameAsAccountHolder!!, CancellationToken cancellationToken = default)

I just feel the above kind of example happens so frequently in general code bases that reviewing the code and reasoning about it down the line is incredibly difficult. Is there not a more intuitive operator we could use? Maybe bool isPresent throw? or bool isPresent not null? It is much clearer and easier to reason about. The !! is going to get lost.

Secondly, I've spent so much time clarifying over and over again to our more junior devs that foo!.Bar() isn't a wise thing to do and most of the time. They keep forgetting the rules around it and now there is this new version of it which kind of does the same thing, but not. I really think this isn't the way to go. It seems like much more of a headache than throwing ArgumentNullExceptions explicitly. Most of the Guard pattern implementations are more than adequate in dealing with it and verbose enough that less experienced devs can get to grips with it quickly.

[ericsampson]

then don't use it? ¯_(ツ)_/¯

[CyrusNajmabadi]

From a readability perspective, the examples already mentioned numerous times above show how convoluted the syntax becomes.

Sure, if you subjectively don't like it, that's that. I look at that syntax and it looks great to me. THe first arg cannot be null, the second can be, the third is illegal in the language (you can't have a null-checked value parameter), and the last is an optional cancellation token.

All of those (except the illegal bit) are very sensible. It's easy to read and grok and waht's going on, and it takes minimal effort to codify all these common things i want to state about a signature.

[CyrusNajmabadi]

Most of the Guard pattern implementations are more than adequate in dealing with it and verbose enough that less experienced devs can get to grips with it quickly.

That's great :) Seriously, it is. Like i said above, we do not believe there is a one-size-fits-all solution here. THe language supports (and ill continue to support) numerous ways you could do your guards. If you are a codebase that strongly believes in being as explicit and verbose for these constructs, then definitely continue to do that.

If you are a codebase that feels that !! is sufficiently easy to see and reason about, and that it substantively clears up your code to allow different logic that you care about to stand out, then it's the right tool for you.

Think of the language as a toolbox that provides items for everyone from teh beginner to the master craftsman. You can and should use the items which make the best sense for your domains and your personal evaluations of waht is important or not.

[alfredmyers]

then don't use it? ¯_(ツ)_/¯

Not everybody has the priviledge of maintaining only code written by themselves.

[HaloFour]

Not everybody has the priviledge of maintaining only code written by themselves.

And nobody has the privilege to dictate that nobody should be able to have a feature just because you don't want to see it.

[iancooper]

But subjectively we assessed many options and decided we preferred !! to everything else.

We get that, but are providing feedback on usability.

I understand the 'please provide feedback on language features' request, but this feature was not trailed in a way that might attract feedback as many others were. It can be tough for anyone to find the time to monitor all the changes, unless there is some kind of heads up that we see on it. This one really seemed to fly under the radar, and hence the surprise everyone is treating it with.

I note you say that it is too late to provide this feedback, but that is the "sunk cost fallacy". Once you have added this complexity to the language, its a far greater magnitude of effort to undo it. Given that much of the feedback has not been "yeah, this is great" but "no, please don't" I'm not sure what goals that the team has this is furthering to proceed without a review of the feedback you are receiving.

[CyrusNajmabadi]

Given that much of the feedback has not been "yeah, this is great" but "no, please don't"

I don't know what this is based off of.

I'm not sure what goals that the team has this is furthering to proceed without a review of the feedback you are receiving.

This feedback was already received and strongly considered as part of the design process.

[CyrusNajmabadi]

We get that, but are providing feedback on usability.

Note: teh usability of htis feature has been strongly considered. From my personal perspective, it ticks the boxes well. Short, simple, easy to read. It's also vastly more usable than the form it replaces which is the full:

if (param == null) // or is null
{
    throw new ArgumentNullException(nameof(param));
}

[MgSam]

@iancooper Just FYI, it's definitely not too late to provide feedback. They've scrapped features from the language mere weeks before shipping previously. We're still 9 months out from the next release.

[DigiBanks99]

@CyrusNajmabadi

Given that much of the feedback has not been "yeah, this is great" but "no, please don't"

I don't know what this is based off of.

Some examples:

• https://twitter.com/davidfowl/status/1491261213179002880
• Initial roll out of !! runtime#64720
• https://twitter.com/ardalis/status/1491406861190713347
• And the very existence of this discussion

[CyrusNajmabadi]

This all seems to be the exact feedback that we got when designing and debating the feature as well. I don't see the 'much' portion. Just about the same similar amount of feedback we get with every feature when the lang changes.

(this actually seems somewhat mild).

Note: a lot of the feedback seems to be in teh category of:

1. i wish this did more
2. i don't like the syntax

For '1', we have no disagreement. And we are always interested in the language doing more. If you are interested in that, please open discussions on ways you think this can be expanded.

For '2', i'm not sure what to tell you. I don't like a lot of our syntax either. That's the nature of syntax. It's subjective and very much comes down to individual preferences on what feels ok or not. As an example, i despise ?. as a syntax, despite being something i use all the time. My own feedback was noted in the design of that, and my own counter options were rejected here with the majority believing that ?. was more ideal overall. That's just the way the cookie crumbles at times with heavy bikeshed topics.

[theunrepentantgeek]

A suggestion I made a long time ago (because I see !! as needlessly cryptic) was to express the constraints after the method signature but before the method body.

It would have looked like this:

void Deposit(string message, decimal, Account account) 
    where message is not null, 
        amount is >= 0, 
        Account is { Status: AccountStatus.Open }
{
    ...
}

I think my suggestion was mistakenly assumed to be advocating for contracts and therefore discarded.

Yes, this syntax may have been forward compatible with code contracts, but my suggestion was purely about expression of guard clauses. I reused the where keyword because we already use it in similar ways, though maybe the run-time vs compile-time difference would have needed a different keyword.

[bjorg]

@theunrepentantgeek that's even better at it has the advantage of being able to describe argument relationships which was not possible with the per-argument pattern.

void Deposit(string message, decimal, Account account) 
    where message is not null, 
        amount is > 0 and Account is { Status: AccountStatus.Open }
        or amount is == 0
{
    ...
}

For me, the whole point is (a) reuse an existing notation that is instinctively familiar and (b) make it trivial to write argument validation, because right now it's too verbose. ArgumentNullException.ThrowIfNull(id) and ArgumentAssertException.Assert(value is > 0 and < 10) (from prototype) is an improvement, but it can't compete with the pattern syntax suggested here.

[HaloFour]

@theunrepentantgeek

A suggestion I made a long time ago (because I see !! as needlessly cryptic) was to express the constraints after the method signature but before the method body.

That's pretty much exactly what is suggested by #105, except that proposal uses requires instead of where. It's only syntactically forward compatible if the design for method contracts accepts that the default behavior should be to always emit argument checks that throw exceptions, but that's only one of the many policy questions involved. There's also the entire question around static analysis, something null checks can short-circuit due to NRTs and flow analysis. It's a big hammer with a lot of unanswered questions, and it still doesn't preclude having a short-hand form for the most common version.

[davhdavh]

In my opinion this syntax is hard to understand.
string? Val means possible null string
string Val means optional compile time check of nullability, but can be null at runtime.
And then string Val!! is supposed to mean optional compile time check of nullability and runtime check to ensure.
To me it would make alot more sense if these operators were similar.
string?! Val is alot more obvious that this is related to a special case of the nullability to mean this is a compile time check for nullablity plus additional runtime checks to throw if null is given anyway.
But honestly i think this is so much of a corner case that it should be handled by attributes instead. [ThrowIfNull] string? Val and yes, i feel it should have ? because it's api does accept a null value, but it should still give null warnings as if it was not there.

[rcollina]

Was notnull (either prefix or postfix) ever considered?

public static void M(string s notnull)
{
    // Body of the method
}

or

public static void M(notnull string s)
{
    // Body of the method
}

Is it too late to suggest to strongly reconsider introducing such an opaque sigil?

[CyrusNajmabadi]

I assume this is why there's a need for a non-alpha token? Is it because it simplifies parsing?

No, that was not part of the decision making here. The reason was because we genuinely think this is an incredibly trivial piece of data about this variable (literally: "is this null checked or not"). So the syntax should be similarly trivial. Brevity is a virtue here commensurate with the amount of information this is trying to convey.

[rcollina]

This was explicitly considered from the start of records. We intentionally allowed class to be dropped to have the simpler form. It was not an 'oh oops' moment.

We would have shipped the same thing. We were very happy with class-records (including allowing them to have a simpler form). And we knew we wanted struct-records (and the syntax for them). We just had a few semantic things to finish there before shipping.

Don't get me wrong, @CyrusNajmabadi , I'm glad you shipped class-records earlier, and glad you followed up with their struct counterpart.

However short forms or shortcuts come with associated tutoring and governance costs, and a cognitive load when you need to fill in the blanks.
I think language features should empower users in the leeway between stable, familiar and/or unsurprising constructs.

But I digress - that's just me and the language has been on a different trajectory for some time now :-)

[CyrusNajmabadi]

However short forms or shortcuts come with associated tutoring and governance costs, and a cognitive load when you need to fill in the blanks.

Sure. And taht is weighted against the value we think this brings. Ultimately, that weighting is entirely subjective and any choice we make will be worse that some alternative for some group of people. :)

[bjorg]

Brevity has little value in a world with auto-complete, but it creates barriers to entry for newcomers. Remember when we used to use short variable names or abbreviations (shudder), because we were too lazy to type them out every time? Those were the days I don't miss!

[CyrusNajmabadi]

Brevity has little value in a world with auto-complete, but it creates barriers to entry for newcomers.

I would not expect a newcomer to ever need to use this feature. And if they run across it, they can learn waht it means, just as they can learn what practically every sigil/keyword means once they run into it and are curious.

Those were the days I don't miss!

This is the language today. You use ! to negate a boolean. You use == to check if things are equal. You use ? to conditionally check something, or state that a type is nullable, etc. etc.

We use brief sigils throughout the language as part and parcel of its nature.

[sab39]

(Mandatory disclaimer: I'm fine with !! as currently proposed and think it's about as good as you can get without a time machine to go back and redo decisions from as far back as the introduction of Nullable<T> back in 2005. This idea could replace !! but more likely would complement it)

I'm wondering if some of the readability benefits of the "contract" syntax various people have proposed here could be achieved without needing to come up with metadata representations etc if there were a convenient shorthand syntax that used patterns and applied some heuristics to follow standard conventions. For example:

public void Foo(string str)
{
    // equivalent to 'if (str is null) throw new ArgumentNullException(nameof(str));'
    // applies if the LHS is an argument to the method that has definitely not been modified and the RHS is literal null
    throw if str is null;
}

It should be possible to have similar heuristics for ArgumentException (the LHS is an unmodified argument and the RHS isn't covered by another heuristic), NullReferenceException (the RHS is literal null and the LHS isn't covered by another heuristic), IndexOutOfRangeException (for > or < patterns), and probably others I haven't thought of, and fall back to InvalidOperationException if nothing specific applies. It could take advantage of the same backend as CallerArgumentExpression to put more helpful diagnostics into the exception message too.

[JesperTreetop]

After reading @jaredpar 's summary in another reply, I think I pretty much agree that suffix !! is the least worst alternative given the circumstances. But I think what's getting the community up in arms about this is a few things in combination:

• Nullable Reference Types were a long time coming, is still a wild ride and inevitably ended up in much confused C# language landscape. Things used to be "broken" in a specific way for historical reasons, and now it's kinda sorta fixed but with a lot of footnotes. For example, there's no way to make a generic type parameter that's nullable and either value or reference type, since it fundamentally changes code generation. Nullable Reference Types goes longer than I thought it would be able to and makes more of the situation and is a heroic effort in every single way to move the needle, but not being able to fix everything up was given as the answer to why not for many years, and I think the outcome proves that answer prescient.
• !! feels like a big duct tape solution to close off some gaps in Nullable Reference Types, or like an admission that it didn't work, and either can sting a little to people who have put a lot of energy into transitioning their code bases (amidst many other transitions).
• !! is a "tricky" syntax. Nullable ? and null-coalescing ?? is tricky syntax, but lets you do something that feels very useful. !! feels rather more like a necessary evil.
• !! pinpoints one specific exception (albeit one that is tightly tied to its analysis); it puts the germ in people's heads that there may be similar syntaxes for other exceptions.
• As an occasional follower of language feature issues, there have been many ideas that were more broadly applicable that have been shot down as too narrow or too niche.
• It's one of the things you would be able to do effortlessly (although I admit maybe without feedback to the nullability tracking engine) with a stronger metaprogramming/macro story and that code generation on the track C# is currently on (ie additive partials, not weaving) doesn't really give a way to solve. The people who want those things are upset that !! "gets fast-tracked", the people who don't want those things are upset that this gets in at all.
• And finally: what does this set the stage for? Good language features feel like they lead somewhere. Even if this is just a singular thing, it's not hard to imagine features that build off of this, and they give at least me an icky feeling. (And the idea that it doesn't somehow also feels disconcerting.)

There's a lot of emotions and gut feelings in here, and it's simple to dismiss them as being free of valid information and say that it's impossible to base decisions on, or plan schedules around, them. But I think listening to people's concerns and taking the collective, reasonably unison reaction can be instructive. (There's certainly been enough C# changes in the past few years that the people reacting now would have reacted a long time ago if this was just about "someone moving the cheese" or "not liking change".)

In recent years Microsoft has felt out of touch with the community in a few instances (like the removing-Hot-Reload debacle). Microsoft is driving the C# language design in a process that's not a democracy, and that is usually a process with a successful and productive outcome. Things feel holistic, well put together, well thought through, with a through-line going from the past into the future. But: I have been in many situations with other projects, as I'm sure many developers have, where there have been little features that haven't paid their weight or fit in or have actively been considered to be bad ideas by developers, but been implemented anyway because of clout or politics. Basically, this feature, although I am very much not making any accusations of the actual process, gives off a similar whiff and a similar sinking feeling, by many small indications in combination.

[JesperTreetop]

For instance, records could have been entirely achieved via source generators, but the team still felt that they were worth having first-class support from within the language. I believe the same applies here.

Precisely. I think we're using some of the same logic and arguments here, but I'm "turning left at Albuquerque" in that I want the big feature to be given consideration and opportunity to develop. That's hard to do without a concrete proposal, but it's also hard to get to a concrete proposal if the immediate reaction is out-of-hand dismissal.

original/replace was a good omen in that it was the first look at language-enlightened code generation from C#, but it's not close to what I would want in such a feature. If you want a good rundown, take a look at successful adoption of (hygienic, syntactical) macros in other languages, which makes most source generation C# efforts look like CSAML in comparison - a fate it shares with most of the cottage industry alternatives.

[HaloFour]

@JesperTreetop

I think we're using some of the same logic and arguments here, but I'm "turning left at Albuquerque" in that I want the big feature to be given consideration and opportunity to develop. That's hard to do without a concrete proposal, but it's also hard to get to a concrete proposal if the immediate reaction is out-of-hand dismissal.

I think that's fair. I also think that's never going to happen. Even if someone brought forth a proposal for macros/metaprogramming that the team found interesting enough to pursue I don't think it'd see the light of day for 5+ years at best. I don't think that there's enough interest on the team to explore that space on their own. So holding up this and all of the other potential features that could be solved by a feature that won't happen doesn't seem like a good use of time. And I say this as someone who would love to see at least AOP brought to the language in some capacity.

This feature also doesn't preclude the possibility of metaprogramming happening in the future, nor would metaprogramming preclude the likelihood that this feature is considered valuable enough to be considered separately as a first class citizen.

[JesperTreetop]

This feature also doesn't preclude the possibility of metaprogramming happening in the future, nor would metaprogramming preclude the likelihood that this feature is considered valuable enough to be considered separately as a first class citizen.

That's also fair, and I don't want to stop the feature. But it is my analysis - and maybe I'm wrong - that the people who want such a broader feature are upset by this smaller feature being basically a surgical feature to fill one specific niche, which they can't do. (Not everyone who dislikes !! does so for this reason, but I sure as hell know I do, and I don't think I'm particularly alone.)

To dramatize unfairly in an attempt to bring out the sore points: "no one in their right mind would want to - oh, just one moment, let me add !! - as I was saying, no one would want those types of features because it would muddy up the language too much and it wouldn't look right". In a way, putting it like this assigns intent and malice or lack of caring, and I know that's not the case, and I apologize for the bluntness and mischaracterization. But I also see that there's a big gulf between the community's concerns and the team's priorities, and if this is going to be a functional community, our concerns also have to be heard, acknowledged and recognized. Asking people to pick out an alternate syntax is valid but doesn't attempt to figure out and defuse the conflict.

So, since I haven't been as constructive as I would have liked, what would I like to have heard? Let's say the answer was "We did this as a quick feature to make life easier here across our many teams working with C#, but we have also heard that many people are frustrated with the lack of similar, non-hard-coded metaprogramming. We want to do something about this in the future and we're willing to work with the community to find a way forward that strikes the right balance, lets you be productive, takes advantage of what we've learned with source generators and what we can leverage in the great Roslyn compilers that has been ground-breaking in turning a compiler's knowledge into a reusable and correct library, doesn't make C# feel like something else and doesn't clutter things up. This may take some time, but it's in all our best interests and we respect the many millions of C# programmers and want to do right by them.". I would have loved that answer, and it wouldn't have chained anyone to a timetable, or to committing to or shipping a design that didn't feel right. It would have put all of us on one side with the problem on the other side, searching for a way forward.

[CyrusNajmabadi]

Lambda syntax opened the door to so many other things, it removed an obstacle that stood in the way.

And we believe the same to be true about !!. It addresses an obstacle in the way of null with .net. Namely that it's hard to actually prevent it from entering with the granularity people need and the perf overhead that is acceptable. I expect and want is to continue down this path so you have a robust null handling story for c# and .net. Nrt, ?., ??, !! (and more) are all part of a story of understanding null in your code and either being resilient to it, out preventing it from happening.

Just like => started in one place, but expanded to many other places, I expect the same to be true of null-handling and null-exploding constructs.

You look at these features with hindsight to now say: oh, this was totally a good idea.

However, at the time, the exact same complaints were levied. It wasn't that helpful. The existing boilerplate for delegates was fine. It was not composable. It didn't work in enough scenarios. Etc. Etc. Etc. And 15 years later, it's a construct found almost everywhere because we continued to expand on it where appropriate.

[CyrusNajmabadi]

I would have loved that answer, and it wouldn't have chained anyone to a timetable, or to committing to or shipping a design that didn't feel right. It would have put all of us on one side with the problem on the other side, searching for a way forward.

We do all our designs in the open here on GitHub and we take and accept feedback on all this work. This very feature was on GitHub for ages with tons of people involved in the discussion on it.

I feel like you're portraying this as something which didn't involve the community and didn't already have months of discussion of these exact critiques. What you're asking for did happen. However, at some point decisions are made, and that means picking things that some people don't like. That almost always the case as there are many different opinions and desires and neither the ldm or the community is a homogenous mass.

[CyrusNajmabadi]

We want to do something about this in the future and we're willing to work with the community to find a way forward that strikes the right balance, lets you be productive, takes advantage of what we've learned with source generators

But what if that's not the truth? What if what we've learned makes us feel we don't want to go that direction. I don't want us to make placating statements that can give false hope.

When we make statements about the future, it's important to me that they are realistic. Otherwise, all we'll have to do is just say the above any everything. And I don't think that will satisfy people. Indeed I think it will be worse. E.g. "you always say that you're interested in the bigger thing, but 98% of then don't happen, so stop with the false hope".

C# is, above all, pragmatic. Even with a community, the velocity we can achieve is both limited (and simultaneously, too fast for some). We aim to hit a reasonable sweet spot with what is possible to have large steps forward while also continually focusing on things like narrow syntactic niceties.

I see you dismissed a prior example of this. Because, of course, that's what people do if they happen to like a particular syntactic improvement. But every time we do that, we hear the same feedback from people who do not benefit from it or who do not want to use it. It's always: stop with the small stuff that I don't need, work in the big things I do need.

But, similarly, every large feature comes with the contrasting feedback of: this is such a big change for the language, can you please just focus on helping me reduce boilerplate with syntactic helpers.

This is why we try to blend both. We have millions of users with varying needs and desires. So we try for a set of features that can hit that within the available budget and velocity that is possible.

[JesperTreetop]

But what if that's not the truth? What if what we've learned makes us feel we don't want to go that direction. I don't want us to make placating statements that can give false hope.

Well, that's the point. I don't want for anyone to be placated, I want the ball to move forward. If !! is now being painted, by the comparison to => showing up in lambdas and then in other places, as the first step in future features, why wouldn't the current iteration of source generators be the first step towards other, similar features? The community has had a largely positive response to them, and there's certainly demand and ideas.

I dismissed lambdas being problematic because I was around for the introduction of LINQ and I thought it was the first big example that C# wanted to be something that wasn't just Java's twin Skippy. I was excited for them, just as there are many other language features like async-await, auto-properties, records and async iterators that I have been excited for over the years. Not shiny for shiny's sake, but ways to manage complexity. All of them have had aspects of getting more from the source code than what you have typed, which is why the attitude towards certain kinds of source transformation has been so bewildering. It makes sense from a perspective of trying to get the right thing into the language, but if it ends up with a culture of saying "we tried that once, we're not going to do it", I wonder what we're all doing here.

[CyrusNajmabadi]

I want the ball to move forward.

But we're genuinely not going to move the ball forward on many/most of these things. Saying otherwise is just not a good idea.

I was excited for them ... Not shiny for shiny's sake,

One person's "excited for them" is exactly just "shiny for shiny's sake" for another. That's the issue.

which is why the attitude towards certain kinds of source transformation has been so bewildering.

I'm happy to share any information on anything you find bewildering. In particular, i need to be clear on things like SGs that we went a particular direction on them entirely to sidestep issues in the areas you wish tehy were being taken into. There isn't a logical connection between: we went in direction X, so now we should pull back toward the other direction when taht is entirely what we were trying to avoid issues with with our designs here.

[JesperTreetop]

One person's "excited for them" is exactly just "shiny for shiny's sake" for another. That's the issue.

I'm very disappointed by this attitude and its lack of faith in and respect for the community.

[CyrusNajmabadi]

I'm very disappointed by this attitude

I'm not sure why this is disappointing. The community is not a homogenous mass. We have direct experience with this being the case across practically the entire feature set of C# for every release.

and its lack of faith in and respect for the community.

I'm not sure how this shows lack of faith or respect. It is simply the reality that the millions of users we have all have different views on what is important to them and what htey wish we would be working on. Any particular issue will have people that are big fans of it, and simultaneously a group of people that will find it pointless and wish that we were workign on something else. I think it's shows respect to the community to recognize and acknowledge that and not pretend otherwise.

[jnm2]

@JesperTreetop To clarify, Cyrus didn't say someone's ask was "shiny for shiny's sake." That would be lack of respect. What he said was, it's people from the rest of the community who call it that. And it's true, I've seen this happen multiple times by being part of the community for a while.

[LunarWhisper]

This functionality does not solve any problems, but it complicates the reading of the code. Most often, we have to read the code, not write it.

It can be implemented using attributes, such as [ThrowIfNull], which is more semantically and explicitly, and is suitable for implementing other checks (for example, that Enum is defined or the collection is not empty).

This is a step towards turning C# into an unreadable analogue of Kotlin.
A very hasty and ill-conceived decision in my opinion.

[SajadJalilian]

It's more compelling to me to write more code than messing with readability.
We can recognize type in milliseconds, when I see the int I know what it is, you can put all kind of hieroglyph characters before or after it, and it's still the int; But name is totally different story; Names are unpredictable, they can be anything!! adding characters to them is bad idea.

[ajdust]

I'm not a fan of !! because it looks like it should be a type system concept. Something here does not belong..

void Do(int? x, string? s!!) => Get(s)!.Run();

? is type system NRT or Nullable<>, !. is NRT again, !! is.. a special-cased ArgumentNullException code generator 😕?

But I understand the pain. This null check boilerplate is a pain and shows up everywhere.

public static bool Between<T>(this T foo, T a, T b)
    where T: IComparable<T>
{
    if (foo is null)
        throw new ArgumentNullException(nameof(foo));
    if (a is null)
        throw new ArgumentNullException(nameof(a));
    if (b is null)
        throw new ArgumentNullException(nameof(b));
    return foo.CompareTo(a) > 0 && foo.CompareTo(b) < 0;
}

However I agree with others above opining that the !! solution is the wrong path. I'll take the boilerplate. If the goal is to reduce throw boilerplate with new syntax, the first thought I have is the following. Put these extra operations with the where. throw: foo! is reminiscent of foo!. and you know it has something to do with exceptions because throw. The code then becomes

void Do(int? x, string? s) throw: s! => Get(s)!.Run();

public static bool Between<T>(this T foo, T a, T b)
    where T: IComparable<T>,
    throw: foo!, a!, b! => 
    foo.CompareTo(a) > 0 && foo.CompareTo(b) < 0;

I'm also a fan of @bjorg 's proposal if anyone interested in this topic hasn't glanced at that. It feels like a fuller solution whereas !! feels like a hack/bandaid to me.

But with all that said, we have attributes in C# that change behavior all the time.

int Get(string? s)
{
    if (s == null) throw new ArgumentNullException(nameof(s));
    if (!User.Authorized()) { throw ... }
}

Code review says we got attributes for that auth check! Pull that if out.

[Authorized]
int Get(string? s)
{
    if (s == null) throw new ArgumentNullException(nameof(s));
    ...
}

We even have magic attributes like [MethodImpl(MethodImplOptions.AggressiveInlining)]. Everyone knows attributes are magic and generate code (or at least, it feels like they do). So it's not a big leap in my mind to this. As an added bonus, everyone already understands attributes.

[Authorized]
int Get([ThrowNull] string? s)
{
    ...
}

[jnm2]

It is not a type system concept; it is a variable/expression concept. There's interest in allowing !! on expressions inside method bodies. If it was a type system concept then it would imply that things like List<string!!> might make sense to express as types.

[ajdust]

it is a variable/expression concept

I know, that's the problem. It is positioned so close to NRT but is actually completely different. My feeling is !! is a bolted on solution for something NRT is supposed to solve. !! digs the null-hole deeper. !! implicitly tells everyone "just keep using null everywhere".

interest in allowing !! on expressions inside method bodies

More confusion. I don't see why an ArgumentNullException halfway through a method is better than NullReferenceException halfway through a method.

Option A: person?.Addresses?[0].City!!.ToUpper()
Option B: person?.Addresses?[0].City.NotNull().ToUpper()
Option C: person?.Addresses?[0].City.Validate().ToUpper()

Here NotNull and Validate are extension methods that can and do exist today. They can use Caller argument expressions and throw exceptions with nice messages like in this case [0].City is null or too long. Or there's !!. Which looks like a typo for someone who meant to type [0].City!.ToUpper() with one !.

In any case, !! is a huge language change to elevate ArgumentNullException. I feel many developers will be double-taking, in a bad way, when they learn about it, with all the thoughts covered in this discussion.

[damienleroy]

A lot of comments here, hard to read all of them.
I understand why this operator. But I still not agree with it.

I was pretty disturbing with the null operator ?, but it was ok (in fact it help a lot), also it was almost the only one. When you have to explain what is it, it still easy.
But about !!, it become too much in the language.
One thing I like in C#, is writing clear code. Even newer (mean, like students) can come, read and understand the code. Implement this kind of things remove this, which is for me a big advantage of the langage.
It's why for me, adding this kind of feature, more there is, more the langage will be complicated, and more it will be forsaken. I know it's not mandatory, but people will using it anyway, and everyone will have to deal with.

I am not completly against this operator specificly, there are good reasons about it, but contributors have to be really carrefull if they want to implement more of them in the future.

To finish, I agree with a previous post. Using MyMethod([ThrowIsNull] Obj param) or MyMethod(notnull Obj param) for example is a better way, as it still in the spirit of C#.

[AartBluestoke]

@mikernet the problem isn't breaking stuff 20 years ago, its breaking the code i wrote yesterday that had different expectations, along with many hundreds of millions of other situations. - look at the path away from .net Framework to net 6 via net core and the mess that had. This, and all the other changes you're talking about would be something of similar size, except without the reunification possibility of net 6 / net 7 at the end of the tunnel, it would be a permanent new language - c#++

[CyrusNajmabadi]

However, since around C# 8.0 every new feature is some shorthand for something that already exists.

You're both correct and somewhat off base here. You are correct that our new features are often shorthand for something that already exists. Except that this wasn't a C#8 thing. IT's been the case since we started having successive language releases. For example:

With C# 2 we added partials (a way to write something you could already write, just spread across types). Anonymous methods (a shorthand for a closure and associated method). And Iterators (a shorthand for producing an IEnumerable/IEnumerator). Method-group-conversions (a shorthand for creating a delegate)

C# 3 then added auto-props (a shorthand for a prop+field), anonymous-types (a shorthand for for a simple property-based class), lambda-expressions (a shorthand for for anonymous methods from 2.0), extension methods (a shorthand for calling static methods), var (a shorthand for writing variables without having to specify the type), and object/collection initializers (shorthands for creating values)

C#4 added dynamic (a shorthand for avoiding writing reflection by hand) and optional args (a shorthand for having all callsites have to provide a value).

C#5 added async/await, a shorthand for for using Tasks and attaching continuations to them.

C# 6 added static imports (a shorthand for importing names into scope), auto-prop initializers (A shorthand for not needing to initialize in a constructor), expression-bodied members (a shorthand for writing out a full block with statements), null propagation (a shorthand for doing null checks and member accesses), string interpolation (a shorthand for producing string values).

c#7 added out-vars (a shorthand for avoiding having to declare the variable up front), tuples (a shorthand for creating a type to contain a list of named values), pattern matching (a shorthand for easily checking if values correspond to a particular shape), discards (a shorthand for indicating a value is intentionally being ignored), throw expressions (a shorthand for avoiding having to write statements to perform logic and then throw).

7.1 added 'async main' (a shorthand for adding your own code for blocking on asynchrony in your main method), default-literal-expressions (a shorthand for indicating you want the default value of a type), inferred tuple names (making tuples even shorter).

And so on and so forth.

C# is replete with feature intended to be a "shorthand for something that already exists". Why? Because people are writing code for hours a day each and every day. And when it takes more time and effort to write that code, that's a tax that continually adds to their lives and reduces efficiency.

So we do intentionally spend a lot of time making it easier and simpler to write code that can do what is already possible to do. But that's a virtue. Devs have limited time, and providing them ways to more expressive and efficient with less code has a tangible benefit to their lives. But you don't have to take my word for it. Feel free to use C# 2.0 and attempt to try to code up solutions to the same problems versus c# 10. I think you'll find that while you are capable of solving almost all of the same problems using 2.0 you will find it enormously verbose and painful to do so, and you will start really wanting and appreciating the enhancements to the language that make all those cases so much more palatable.

[CyrusNajmabadi]

Records for example are just structs (or can be classes now, I can't keep up).

Sure. But that's like saying: "anonymous-types are just classes" or "tuples are just structs". At the end of the day you can reformulate practically any piece of data as something else. But that doesn't mean that having more convenient ways of producing and handling such data is a problem. I could replace all my records with classes (or structs), but if i do so, i will often have to literally bloat up the code by 50x more loc. That's a ton of code i need to write, test and maintain. Records greatly diminish that burden and allow me to focus on problems in my domain that are far more relevant.

Patterns are switch statements as far as I know.

They really are much more than this. For example, patterns can allow very concise declarative ways to check if a value matches a very complex structure, while also enabling easy acquisition and reuse of many parts of that match. The equivalent code using C# could easily be 10-20x longer and much harder to maintain and reason about.

Linq is another good example of something that isn't really essential, but contributes to language bloat,

Not essential to you. :)

On the !! issue: why not just have a function that throws whatever you like when any of the parameters are null?:
NullCheck(params object[] o)

First, that will allocate, which now means extra burden on the CPU, memory and GC portions of your app. Second, if you have a null value, you will have no idea which value was actually null.

[CyrusNajmabadi]

but common, there is so much to gain right now from doing things right.

What is there to gain? It will effectively leave behind any groups that cannot spend the enormous amount of time and effort to move to X#. There are literally billions of lines of code in active development that represent unbelievable amounts of investments for thousands of companies and projects. That code is working fine and has a powerful and continually developing language and ecosystem around it. Killing all of that to chase a new shiny is downright irresponsible and reckless. We're not in a an unhealthy place now. The language is large yes. But not in a way that would be substantively different if we were to do it again. For example, any new language would likely have things like:

1. generics.
2. lambdas
3. shapes (taht's enormous in its own right)
4. patterns/deconstruction/matching
5. asynchony

etc. etc. etc.

If you think we should restart, be clear on what you think would actually be different and how you think that would substantively address complaints of complexity here. Because i think it's highly naive to think that that would be the case (unless we did something like 'go', in which case i think many would be extremely upset for the reason that it would feel like a massive step backwards for them).

[sab39]

I'm not the OP and I do understand why it would be completely impractical to start over so this is never going to be anything more than a thought experiment, but I've been using C# since VS2002 and I have a pretty clear list in my head of what I'd wish to have been done differently if I had a genie and a time machine 😉 (not including things that could still be done today, just things where the past decision prevents features now)

Given that it can only ever be a thought experiment I'm not sure there's any particular point in discussing such a wishlist at all, but I've typed it all out now and since this is a discussion rather than an issue hopefully it's ok to post anyway.

• No array variance. Obviously.
• No runtime named delegate types; if used, they'd just be aliases for an implicit Func-style type at the runtime level.
• Unified treatment of nullability between structs and classes so that T? meant the same thing for both and could be used as such in a generic context. (Side effect: T? on a struct type would expose the methods, properties etc of T directly rather than .HasValue and .Value; those properties and Nullable<T> might or might not still exist behind the scenes but would be invisible if you just used T?
• Runtime-enforced NRT, so that source-level non-nullability would be guaranteed at runtime. C#'s NRT feels a bit like Java's generics, and one of my favorite things about C# is that it didn't punt on the runtime side of generics like Java did.
• (Kind of contradictory to the first bullet point... not sure how to square that circle...) A more obvious indication at the source level of situations where you might be copying/boxing a mutable struct vs creating a new reference to the same object.
• The Extensions part of the Roles and Extensions proposal, built into the runtime so that boxing would not be necessary.
• Ideally, if possible, less boxing when passing around structs typed as interfaces they implement.
• Self type
• Ability to define different implementations of the same API element with different generic constraints and minimal or no runtime overhead in deciding which one gets called. For example Nullable<T> could be defined separately for where T : struct vs where T : class

[kjpgit]

If you add !! in expressions, can we agree that there should also be a standard compiler warning on the usage of !, that can be enabled for green field projects? (Can be suppressed around certain code blocks with pragmas) Think about it:

• The shortest, least greppable thing to do (!) removes runtime safety
• The longer thing to type (!!), and slightly more grep-able, is safe, and doesn't sacrifice runtime safety.

Not a good sign when the programmer's path of least resistance is unsafe --> safe

[333fred]

For example, let's say returning a Task<string> from a method that returns a Task<string?>. !! does you nothing here: there's no nullability to check. It's perfectly safe as well, but the compiler can't statically determine that. ! is the correct approach.

[jmarolf]

Assuming that !! is someday allowed on any expression, I could see something like this being considered.

Today there are two types of APIs in the .NET Ecosystem:

• Null-Annotated APIs
• Null-Oblivious APIs

As we move to a world where most apis (hopefully) are null-annotated we may want to consider a different mode for null-oblivious APIs.

Today if we encounter a null-oblivious api we assume that the value is not null. This is generally a safe default especially for existing code because if it was null your existing program would be crashing.

There was a desire from some folks in the community for a mode where null-oblivious mean "untrusted" or "unverified" to the point that we would warn you about the value potentially being null (or at least not verified to be non null). For the sake of argument let's call this potential option #nullable strict contrasting with the existing #nullable enable.

If some future version of the language had this #nullable strict feature I could see us also saying that ! doesn't make sense for that option. You are saying "I really want to be told about every place I haven't proven to be non-null, but I also want to put ! for places where I think that's unlikely to be an issue in practice."

To me it would make sense to say that in #nullable strict places where you get nullable warnings you should instead but !! to mean "I assume that this is never null in practice but if I am wrong that is a serious problem so throw immediately."

[kjpgit]

For example, let's say returning a Task<string> from a method that returns a Task<string?>. !! does you nothing here: there's no nullability to check. It's perfectly safe as well, but the compiler can't statically determine that. ! is the correct approach.

I'm afraid I'm not parsing this example.

[CyrusNajmabadi]

#nullable enable

using System;
using System.Threading.Tasks;

public class C
{

    public Task<string?> X(bool b)
    {
        if (b) return Y();
        else return Task.FromResult<string?>(null);
    }

    public Task<string> Y() => Task.FromResult("Y");
}

This gives a warning on return Y(); because Task<string> is not the same as Task<string?> and the nullability is changing. However, this is entirely safe. You suppress this by writing: return Y()!;. But there's on reason or purpose to any runtime check. Indeed, there is no runtime check you can actually emit here to validate anything.

[CyrusNajmabadi]

! is not: this is not null. It is suppress nullability analysis here.

In this case everything is fine due to information outside of the bounds of what lang analysis can understand. Namely, it is the contract and impl of Task<T> that makes this entirely safe. e.g. for a reference type Task<X> is always usable where a Task<X?> is needed. It is 100% safe as per the contract of that particular type (but not of all types).

Here ! is appropriate, and it can only be a compile time check. There is literally no runtime code that we could emit to ensure that the above is somehow 'safe' or cause it to 'blow up' at runtime or give you any sort of 'runtime safety'.

[kjpgit]

Thanks for explaining it.

outside of the bounds of what lang analysis can understand.

Outside of what it can understand today, I assume.

Well, I haven't hit this case of "doesn't match target type" yet, but I personally would do this:

        if (b) {
#nullable disable
            return Y();
#nullable enable
        }

Which is greppable and would cause a code review... just like we do with our unsafe usage for native libraries... and if we hit too many, we would consider an explicit Option class as a container, perhaps.... and if we still get too many, well, then I'll have to retreat into management... :)

[CyrusNajmabadi]

Outside of what it can understand today, I assume.

Yes. that's what ! is for. For the user to say "yes, i know what's going on. you don't. don't tell me it's a problem".

Well, I haven't hit this case of "doesn't match target type" yet, but I personally would do this:

Sure. THat's a fine opinion to have. As I mentioned above, it was paramount that this feature be palatable for users though. And having to wrap code like this in pp-directives is extremely unpleasant and not desirable with that goal.

[kjpgit]

Would this be as equivalent safety wise?

  public class C
  {
      public Task<string?> upcast_task(Task<string> s) {
  #nullable disable
          return s;
  #nullable enable
      }
  
      public Task<string?> X(bool b)
      {
          if (b) {
              return upcast_task(Y());
          }
          else return Task.FromResult<string?>(null);
      }
  
      public Task<string> Y() => Task.FromResult("Y");

[CyrusNajmabadi]

Yes. But with potential runtime overhead, and the overhead of the IL and metadata. The purpose of ! is exactly to be something that comes with guaranteed no runtime overhead. It is just about suppressing analysis.

[kjpgit]

Quite a few people on reddit think .Value and .HasValue work on NRTs like string?. Good luck explaining they need .Value for one and !! for the other one. :-)

[tagcode]

Why not executable annotations? [ThrowIfNull] is more elequent and indicative than '!!'.

void Do([ThrowIfNull] string action)
{
}

[return: ThrowIfNull] string SomeString()
{
    return null;
}

[ParameterInterceptor] could be added to Attribute subclass to indicate that compiler should inject .Intercept(ref stack-pointer, string name) on arguments when methods are called and returned. JIT can inline this.

System.Attribute
├── System.ThrowIfDefaultAttribute<T>
└── System.ThrowIfNullAttribute

[ParameterInterceptor, AttributeUsage(AttributeTargets.Parameter | AttributeTargets.ReturnValue)]
public class ThrowIfNullAttribute : Attribute
{
    [DebuggerHidden, MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Intercept(ref object value, string name)
    {
        if (value is null) throw new ArgumentNullException(name);
    }
}

[ParameterInterceptor, AttributeUsage(AttributeTargets.Parameter | AttributeTargets.ReturnValue)]
public class ThrowIfDefaultAttribute<T> : Attribute
{
    [DebuggerHidden, MethodImpl(MethodImplOptions.AggressiveInlining)]
    public void Intercept(ref T value, string name)
    {
        if (value is default) throw new ArgumentNullException(name);
    }
}

[ThrowIfDefault] would be for value-types.

void Do([ThrowIfDefault] int id)
{
}

[return: ThrowIfDefault] int SomeInteger()
{
    return 0;
}

Besides validation, interceptors have broader customization potential as they can modify the stack slot.

void AddKey([AssertPrefix] string key)

void Add([DefaultOnNull("")] string value);

[return: DefaultOnNull("")] string Do();

void Do([TraceHere] Exception e);

void Do([Abs] int value);

void Do([Decorate] IMyInterface value);

[CyrusNajmabadi]

Why not executable annotations? [NotNull] is more elequent than '!!', and would use existing syntax.

That has existing meaning today. It's compile-time-only. We cannot change to have runtime semantics without breaking code.

[tagcode]

Thanks for pointing that out. I ameded the example to use "[AssertNotNull]".

[LunarWhisper]

That has existing meaning today. It's compile-time-only. We cannot change to have runtime semantics without breaking code.

You enable nullable types in the project settings. What prevents you from making the same thing to change the behavior of NotNull? The meaning of the attribute does not change, so it does not affect with reading the code. It will be exactly the same as "Warning as Error".

[HaloFour]

@LunarWhisper

You enable nullable types in the project settings. What prevents you from making the same thing to change the behavior of NotNull? The meaning of the attribute does not change, so it does not affect with reading the code. It will be exactly the same as "Warning as Error".

Nullable Reference Types (NRTs) do not change runtime behavior, they only provide compile-time analysis and diagnostics on possible improper usage. They do not insert any code that enforces non-nullability. The language design team is very much against the notion of compiler options that would create dialects of the language. NRTs are one of exceptionally few cases where they were willing to add such an option given they are considered a "billion dollar mistake". However, even then they were not willing to allow such an option to have any impact on the runtime behavior of the written code.