Apply the "bang" or "damnit operator" to nullable value types

[burtonrodman]

Sorry if this has already been proposed. basic searching did not reveal it.

As I understand, we will be creating an operator to apply to assert that a reference typed variable is not null.

Please allow this on value types as a synonym for the longer .Value or .GetValueOrDefault().

as example, current code:
int? a = 5;
int b = a.GetValueOrDefault();

with the "damnit operator":
int? a = 5;
int b = a!;

[CyrusNajmabadi]

Interesting idea. But there would be a concern about the asymmetry here. Namely that ! on a reference type does nothing but suppress warnings. Whereas ! on a nullable type would actually throw if it was null.

[DavidArno]

@CyrusNajmabadi,

As I read @burtonrodman's request, he wants the lines assigning to b1 and b2 in the following to be synonymous:

int? a = 5;
int b1 = a.GetValueOrDefault();
int b2 = a!;

ie, ! becomes shorthand for .GetValueOrDefault().

[iam3yal]

@DavidArno Yes but assuming a is null what happens in this case int? x = a!; x.GetType()? I'm not sure but maybe this is the concern unless the OP implying that this wouldn't be allowed.

[burtonrodman]

It was my understanding that using ! on a reference type was only necessary when the compiler could not prove that it was not null and so it would suppress a warning, AND indicate that the developer is taking responsibility that an exception is possible.

[GeirGrusom]

I at least would prefer that a! throws for both reference and value types.

If you want GetValueOrDefault you could always just write a ?? 0.

[yaakov-h]

@eyalsk I'm pretty sure you can't GetType on a nullable, you always get back the underlying type due to boxing.

[GeirGrusom]

@yaakov-h
Surprisingly GetType() on nullable value types behaves the same way as with reference types. I.e. it will cause a NRE if it's null, and return the underlying type otherwise.

[yaakov-h]

Yeah, that's what I was referring to. Sent from my phone, widescreen iPod, and internet communicator.

…

On 23 Aug 2017, at 8:57 pm, Henning Moe ***@***.***> wrote: @yaakov-h Surprisingly GetType() on nullable value types behaves the same way as with reference types. I.e. it will cause a NRE if it's null, and return the underlying type otherwise. ― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[HaloFour]

I would prefer just using the ?? operator to achieve this behavior. It makes the code more clear and forces the developer to be explicitly about the "default" value that they expect in the case of null.

[burtonrodman]

I believe I misspoke... What I intended was that the developer could assert that it is not null and therefore I think it would be a synonym for .Value, instead of GetValueOrDefault. Sorry if I led the conversation in the wrong direction

[CyrusNajmabadi]

I at least would prefer that a! throws for both reference and value types.

We definitely don't want that. The purpose of ! is to say that you're taking control over the analysis. Not that 'null' does not exist (or should throw). For example, for a very temporary point in an algorithm, i might need to use null for a short period of time. But, as far as anyone else is concerned, they will never observe that null.

I want to be able to use null temporarily, while telling the system that it's ok (because my own analysis will ensure that there is not a problem, vs. the compiler's very weak analysis).

[CyrusNajmabadi]

Surprisingly GetType() on nullable value types behaves the same way as with reference types. I.e. it will cause a NRE if it's null

Why is that surprising? All the inherited methods behave that way. Only the special Nullable methods (like .HasValue) work differently.

[bbarry]

I at least would prefer that a! throws for both reference and value types.

I would rather prefer that ! has no runtime cost at all (perhaps it is not even expressed in the IL). I am concerned that too often I will know it will not be null but the compiler cannot prove it.

[Thaina]

If ! would be GetValueOrDefault what default it would be used?

default(T) or new T()

This will be difference when we have #99

[GeirGrusom]

@CyrusNajmabadi

GetHashCode() returns 0, ToString() returns an empty string, Value throws InvalidOperationException but GetType() throws NullReferenceException.

I think it's a little bit surprising at least.

[jnm2]

Yep, I was surprised. It's a gotcha I may or may not remember.

[iam3yal]

My train of thoughts was that when a is null then doing a.GetValueOrDefault will result null because doing a.HasValue results false and doing something like default(int?) results null so I thought the default would be null as opposed to 0 but then I'm not using nullable value types a lot so I'm not always sharp on the details, should have tried it before posting but anyway I learnt something. :)

[jnm2]

@eyalsk If ((int?)null).GetValueOrDefault() returned (int?)null it would be a no-op.

[jveselka]

@Thaina The same default(T) it uses today. Nullable is just a struct and bool flag. GetValueOrDefault directly accesses the struct.

[GSPP]

It would have to be Value and not GetValueOrDefault. GetValueOrDefault usually is the wrong choice. It is very rare to actually ever want to use the default value. What's more common is to test for null and then to just want to obtain the value. Value is more useful because it contains an assertion that the value is actually there instead of silently continuing with bad data. GetValueOrDefault is ON ERROR RESUME NEXT.

[pentp]

@GSPP that's the exact opposite of the proposed logic for ! operator on reference types (and TypeScript) where it does not throw. If you have a null test before GetValueOrDefault then there is no reason to call Value and if you assert that the variable can't be null by using the ! operator, then it's your responsibility to ensure that it's true as @CyrusNajmabadi said earlier very clearly.

If you don't want to take that responsibility, then you can continue using Value without any new language features required. Despite what the name says, GetValueOrDefault does not return the default value if you know that it actually is not null, and it's used very often in actual code.

[yaakov-h]

@pentp ! actually does throw for reference types... it “throws” a NullReferenceException. You tell the compiler “oi shuddup I know what I’m doing”, but the runtime will still do what the runtime does. .Value is the closest parallel for Nullable.

[jnm2]

@yaakov-h ! doesn't throw though:

string? s = null;
string notNull = s!;

No exceptions to be found.
The NRE is caused by a later . dereference, not the !.

[yaakov-h]

Ah true. I was thinking more along the lines of ((string?)null)!.ToString().

[GSPP]

Looks like I don't understand the semantics of the proposed bang operator. That said, I stand by my point about asserting, instead of creating garbage data, in the case that you know the value cannot be null (because due to a bug it might be null and the assert is more helpful there. Find out about bugs instead of computing with garbage). GetValueOrDefault is for cases where the operand might actually be null. Then, it's useful.

[jnm2]

GetValueOrDefault is for cases where the operand might actually be null. Then, it's useful.

It's also useful for perf in cases where the operand is known to be not null.

[AqlaSolutions]

My vote for this!

Consider this code

                        var set = await GenerateArgumentsSet(current.ArgumentSet);
                        if (set != null)
                            activeTasks.Add(await LaunchEstimateAsync(set.Value));

It could be written as

                        var set = await GenerateArgumentsSet(current.ArgumentSet);
                        if (set != null)
                            activeTasks.Add(await LaunchEstimateAsync(set!));

[HaloFour]

@AqlaSolutions

                        var set = await GenerateArgumentsSet(current.ArgumentSet);
                        if (set != null)
                            activeTasks.Add(await LaunchEstimateAsync(set!));

This is already legal code and it means something else. Since the "dammit" operator shipped I think this ship has sailed, changing it to unwrap a nullable value type would be a breaking change.

[jnm2]

I think this issue is a subset of #1865.

From a language design member at #1865 (comment):

Note: we really didn't want to do this before, because the principle of the nullable feature is that we don't change runtime behavior. Now that C# 8 has shipped, we really can't do this as it would be a breaking change.