Proposal: Allow 'as' operator to be used with non-nullable value types

[andre-ss6]

Currently C# has two ways of converting between types outside of selection statements in the language - casts and the as operator. Those two of course work differently from a implementation perspective, however the point I want to raise here is aesthetics/developer preference/code style.

Current Options

int i = (int) await _service.GetIntAsObject();
int j = await _service.GetIntAsObject() as int;

Some find the second option to be more aesthetically pleasing/easier to read and try to use it where it makes sense. However, the language currently forbids the as operator from being used with non-nullale value types, so that code won't actually compile under C# 7. The current alternative is to write something like:

int i = await _service.GetIntAsObject() as int? ?? 0;

Which not only can be a little confusing at first sight but, more importantly, doesn't really convey the meaning desired by the developer which is to say that the method will certainly return an int.

If the method is not guaranteed to return a non-null value, the developer might then write something like:

int i = await _service.GetIntAsObject() as int? ?? throw new NullReferenceException();

However, this not only is a bit long, but this code also throws a NullReferenceException(), which is not a good practice (since NREs should be thrown by the framework). There is then a third, similar, option:

int i = await _service.GetIntAsObject() as int? ?? throw new InvalidCastException();

This also throws an exception which is more or less reserved for the framework, but it is [arguably] more acceptable. It stills suffers from the problem of being too long and cumbersome to write. It also litters the code with unnecessary logic: both these last two examples write logic that should be reserved to the framework.

How the new operator could work

Now, if we were to allow as with non-nullable value types, I can see three viable paths we could follow - two of them which are shown in the preceding examples:

Use default

When used with non-nullable value types, as could return default. The problem with this is that there is no way to know if the conversion failed and it could make as error-prone and be a source of bugs for those who are less experienced with C#.

Raise an exception

A NullReferenceException or InvalidCastException could be thrown to indicate that you tried to put a null value into an object of a non-nullable value type. This is my preferred option.

New syntax along with the new nullable reference types feature

[I was already not a fan of this approach because the ! operator will already be used as a 'compiler directive' (as opposed to a language feature) and thus it could be confusing to extend its use even further to convey other meanings. I like the 'Option 3' shown below, but it involves a whole new language feature altogether, so it's more of a dream. The discussion has shown that the first two options shown below are not a popular option with the designers either. So I guess we're leaving this behind, but I'll leave this here for history anyway.]

We could also use the ! syntax from C# 8 to indicate that we know the return won't be null.

// In C# 8 this is possible
possiblyNullObj!.ToString(); // will not generate an error/warning from the compiler because of the '!'

// 1) So we could do the same here
int i = possiblyNullObj as! int;

// 2) Or maybe like this
int j = possiblyNullObj as int!;

// 3) Or maybe
int k = possiblyNullObj! as int;

Option 1 and 2 could be transformed by the compiler into:

int i = possiblyNullObj  as int? ?? throw new NullReferenceException();

Option 3, I guess, would mean something new in the language: the as operator would be overloaded to only accept reference or nullable types when the input object is of a nullable type (the current implementation) and, as a new addition to the language, to accept non-nullable types (independently of being a reference or value type) when the input is a non-nullable type (be it reference or value). When the conversion failed, it would throw a InvalidCastException instead of a NRE.

[HaloFour]

IMO the existing cast syntax is the most concise and readable way of conveying that you want to cast something. I think trying to extend the as operator to apply here would only be more confusing as your options for behavior demonstrates.

[andre-ss6]

I think trying to extend the as operator to apply here would only be more confusing as your options for behavior demonstrates.

Hmm, I'm sorry but I disagree. I don't see how my options for behavior demonstrates that. Could you elaborate?

IMO the existing cast syntax is the most concise and readable way of conveying that you want to cast something.

The very point of this proposal is that different developers prefer different coding styles. Also, the point is not simply casting, but converting in general. We could use that same argument to remove the as keyword entirely. Still, here we are.

[CyrusNajmabadi]

The very point of this proposal is that different developers prefer different coding styles.

I certainly can see that this is a style you prefer... but i have no information that would make me feel this is any way something enough of the community would want to warrant doing this.

It would be equivalent to someone coming here and saying: "i would prefer to say foo struct instead of struct foo". Ok... so you have a different preference on the style... but that's not really a good reason to make such a change.

[CyrusNajmabadi]

I don't see how my options for behavior demonstrates that. Could you elaborate?

Well, you're having to come up with all sorts of decisions about what as valuetype means. One of those decisions is to just make it mean the same thing that (valuetype) means. So why have two identical ways to say the exact same thing?

The virtue of 'is'/'as' today is that they do mean different things. (type) is "convert to this type, and throw if you can't". as type is "convert to this type and give me null if you can't". Unless your proposal substantively gives me something different from those two options, then it's not really something valuable to add to the language.

[HaloFour]

@andre-ss6

Hmm, I'm sorry but I disagree. I don't see how my options for behavior demonstrates that. Could you elaborate?

The fact that there are multiple options for what this operator should do if it fails is evidence that it is confusing. The as operator never throws, but it doesn't make sense for it to return a sentinel default value either. The route that makes the most sense would be to have the operator return a nullable struct, but you can already use as with nullable structs which means, at best, you're reducing the verbosity by one character.

The current rules seem to be quite sufficient, and they allow the developer to decide the policy on failed casts:

int withDefaultValue = expression as int? ?? default;
int withAlternateValue = expression as int? ?? -1;
int withException = expression as int? ?? throw new Exception("boom");

The very point of this proposal is that different developers prefer different coding styles.

Indeed they do, but having the language enshrine that through duplication of syntax is generally not considered a good thing unless that alternate syntax provides sufficient additional benefit.

[CyrusNajmabadi]

Some find the second option to be more aesthetically pleasing/easier to read and try to use it everywhere.

Can you point to such communities?

Also, in codebases where as is the preferred alternative to deal with conversions, this leads to code with an inconsistent style, using as in most places, but casts in others.

Can you point to such codebases? It seems odd for a codebase to have a preference here as these are two totally different things. it's not like (T) and as T are different ways of doing the same thing. They're very different things altogether. The former is when you expect the conversion to succeed, and you want to die/throw when it doesn't. The latter is when you expect it may fail, and you want to be able to not throw and check the result to see if was ok. Mixing/matching these doesn't make sense. You should use the right operator for the right sort of approach you're taking.

[andre-ss6]

but i have no information that would make me feel this is any way something enough of the community would want to warrant doing this.

That is why we have reactions and an open discussion forum.

It would be equivalent to someone coming here and saying: "i would prefer to say foo struct instead of struct foo".

Well, and I guess it's totally OK to propose that as well (not that the community would like it though 😄).
However, no, that is not equivalent to what I'm asking. The as operator already exists in the language. It only happens that it is currently forbidden to be used in some places. Your argument could be used to say that we should never done the obj is null ?? throw syntax. Why not just if (obj is null) throw?. Heh.

so you have a different preference on the style... but that's not really a good reason to make such a change.

No, not "you". Stop thinking about me. Think about the proposal. Think about the community, not the OP. This is open-source.

Well, you're having to come up with all sorts of decisions about what as valuetype means.

Of course! I mean, when you're proposing to change something in the language, of course you'll have to come up with decisions as to how it will behave. (?!)

So why have two identical ways to say the exact same thing?

I think this is a very valid point. My main reason is to bring consistency -- to be able to use the same construct everywhere it seems to make sense.
And by the way, we have plenty of examples in the language where this happens, the most obvious being, I guess, String and string. But we also have anonymous delegates and lambdas, access modifiers which can be ommited, local functions and normal private methods and so on. All of these last ones I mentioned were all created to make the syntax clearer/to make the language seem more natural/easier to use, even though there were already ways to express the same intent.
Lastly, I think having two ways to do the same thing is not really that harmful. We have plenty of others things in the language that seem to do the same thing but actually don't. is null vs == null is one of those. They seem to do the same thing, but actually don't. I think that is worse than having something that seem to do the same thing and actually does the same thing.

[andre-ss6]

The as operator never throws, but it doesn't make sense for it to return a sentinel default value either.

Yes, and that is why I proposed the third way, which - I think - would marry well with the new nullable reference types feature. In C# 8 (possibly), writing possiblyNullObj!.ToString() would throw if the object is null. The ! operator would be a way to tell the compiler, though, that you know that object won't be null. I think the same could then apply to the as operator.

[CyrusNajmabadi]

I think this is a very valid point. My main reason is to bring consistency -- to be able to use the same construct everywhere it seems to make sense.

That's fair. But it's worth pointing out that i think the language already has that. You can do as ref_type or as value_type?. It's consistent in that it checks if the conversion is possible, does the conversion if so, or gives you 'null' if not.

[CyrusNajmabadi]

Lastly, I think having two ways to do the same thing is not really that harmful. We have plenty of others things in the language that seem to do the same thing but actually don't. is null vs == null is one of those.

Note that some of these things 'fell out' of other full features added to the language. i.e. the intent was not to add "another way to check for null". INstead, "pattern matching" was added. But patterns wanted to check for null (a very common thing to do in a pattern), and so we ended up with where we are now.

That's a very different situation than this proposal. I'm ok with having very large scale features that end up makign it so there are occasionally multiple ways to do things. I'm not a huge fan with a feature that exists solely and specifically to duplicate something that can already be done :)

(does that help clarify things).

[CyrusNajmabadi]

No, not "you". Stop thinking about me. Think about the proposal. Think about the community, not the OP. This is open-source.

Well... it was your claim that people want this and that codebases follow these styles. I'm just asking for clarification :)

[andre-ss6]

You can do as ref_type or as value_type?. It's consistent in that it checks if the conversion is possible, does the conversion if so, or gives you 'null' if not.

I agree. It's just that currently the only way to tell the compiler "I know this will have an int; it won't be null, trust me" is using a cast. Which is, of course, a totally valid and sensible way to do it. However, if you, like me, thinks that expression as int reads better and want to be consistent with the rest of your codebase, you'll be disappointed to find that you can't.

(does that help clarify things).

Yep, thanks.

Well... it was your claim that people want this and that codebases follow these styles. I'm just asking for clarification :)

Nope, I never claimed that. I'll quote myself here:

Some find the second option to be more aesthetically pleasing

"Some", I said. Like: me, some couple people on SO (https://stackoverflow.com/questions/24265139/why-can-the-as-operator-not-be-used-to-parse-non-nullable-value-types), some fellows here in the company, whoever upvotes this issue...

Also, in codebases where as is the preferred alternative to deal with conversions

Note I didn't say any codebase follow this style. I said that in codebases that follows it... Not that there are codebases that follow it - just that in the ones which do follow.... So no, I never claimed any of these things you said I claimed.

Anyway, inb4: yes, we do follow this style in one of the projects here in my company. Yes, we do know casts and as means different things. However, it doesn't matter in the scope of our project. It's a web client, a web api and an api client. Micro-optimizations are not a thing in our codebase. We're not writing libraries either.

[CyrusNajmabadi]

Note I didn't say any codebase follow this style. I said that in codebases that follows it... Not that there are codebases that follow it

Sorry... i'm confused by this. You said "in codebases that follows it". Are there codebases that follow this? If so, can you point me to them so i can look at them? If there are, great, it will be helpful to see and try to understand what's going on. If there aren't... then i'm not sure why it's relevant to bring up "in codebases that follows it"

Micro-optimizations are not a thing in our codebase. We're not writing libraries either.

It's not about micro-optimizations. it's about using the relevant construct to convey the concept you're trying to convey. cast/as are two entirely different concepts. One is "do this, and fail otherwise" the other is "try this, and give me a sentinel otherwise". It's not about a micro-opt, it's about what the failure behavior should be and what makes sense in that domain :)

[DavidArno]

I think this an excellent proposal. I like the shape of as code, but rarely use it as it's a faff tat it only supports nullables. Changing the pattern from "try cast, null if not" to "try cast, default if not" would really make this feature universal. Like @andre-ss6. I'd then use it for all casts.

[HaloFour]

@DavidArno

I'd then use it for all casts.

It's not supposed to be used for all casts. It's to be used specifically for fallible casts, and to that end requires a sensible default value for when the cast fails. That doesn't exist with value types.

Liking the appearance or the flow doesn't address any the problems with it.

[DavidArno]

@jnm2,

My thinking goes like this:

1. (SomeType)(some expression) and some expression as SomeType are equivalent, except that the latter will always succeed and give a null when the cast fails.
2. (SomeType)(some expression) is fine if you like writing Lisp and filling your code with parentheses. Otherwise it's really ugly syntax.
3. some expression as SomeType is far more elegant. But it suffers from a problem: it swallows exceptions, so can be a source of bugs.
4. Therefore use as (it's more elegant) but only use it with is to protected against that exception swallowing.

However, I accept that point 1 is flawed as the two are not equivalent as the rules around casting are complex and there are differences between the two. And I accept that is/as involves a double check.

Thankfully, x is T y now exists, so the whole is/cast versus is/as debate is moot; don't use either.

I'd still like to be able to use var x = expression as T everywhere, for classes, structs and generics, but looking at the 👍 / 👎 ratio for this proposal, that isn't going to happen. Sometimes it's worth fighting against the tide; other times it's not. This is one of those where I think it isn't worth it.

[iam3yal]

@DavidArno

some expression as SomeType is far more elegant. But it suffers from a problem: it swallows exceptions, so can be a source of bugs.

What?

You're basically claiming that the following code:

object o = new object();
string s = null;
try
{
	s = (string)o;
}
catch(InvalidCastException)
{
}

Is equivalent to the following code:

object o = new object();
string s = o as string;

But the IL is very different so I'm not sure how you came to this conclusion.

[jveselka]

I wasn't fan of this proposal at first, but the more I think about it the more I believe the mental swap @DavidArno mentioned is usefull:

Changing the pattern from "try cast, null if not" to "try cast, default if not" would really make this feature universal.

If zero is part of your domain, then too bad and you shouldn't use as int. But you run into the same issue when null is part of your domain. It is impossible to differentiate from var s = o as string whether o was actual null or object of incompatible type.

[iam3yal]

@zippec

But you run into the same issue when null is part of your domain.

There's a major difference between null that you expect to one that don't, in a case of failure the latter will throw an exception whereas with zero you might never even know about it, you go from "safer" to "less safer".

What's funny is that some people are avid advocates of the famous mantra "falling into the pit of success" only when it suits them. 😄

[DavidArno]

@eyalsk,

You're basically claiming that the following code ... Is equivalent to the following code ...

They are functionally equivalent. I don't see the relevance of how they are implemented in IL. If I can swap one version for the other in code and have no unit tests fail, then they are equivalent.

I believe there are edge cases I think where they differ, but I mentioned that caveat already.

[iam3yal]

@DavidArno

They are functionally equivalent. I don't see the relevance of how they are implemented in IL. If I can swap one version for the other in code and have no unit tests fail, then they are equivalent.

Well, I mentioned the IL part only because you wrote it swallows exceptions.

Personally, I don't have a strong opinion about this change so I removed my downvote and completely understand why people would like it although I'm more in favour of something like to.

[DavidArno]

@eyalsk,

"it swallows exceptions" should not be taken literally. "It doesn't throw an exception when the cast fails" is likely a more accurate description of what I was trying to say.

Isn't to tainted beyond all redemption by "he who shall not be named"'s behaviour?

[yaakov-h]

I thought so too, I was quite surprised to see the idea being revived.

IMHO it wouldn't be so bad if obj as int would always return a value of type Nullable<int>. It would then preserve the null semantics of obj as string (ref type vs value type).

The other way to look at it is obj as string doesn't produce null explicitly if the conversion fails, rather it produces default(string). Therefore, obj as int should produce default(int), i.e. 0. I don't like that approach, but it is arguable.

[iam3yal]

@DavidArno

Isn't to tainted beyond all redemption by "he who shall not be named"'s behaviour?

I dunno I just like the idea of a general feature where you can convert from one thing to another and it would also cover the cases discussed here, the only downside to this is that the BCL would have to adapt this feature but the advantage is that you have full control over it and can add different kinds of conversions without thinking about the semantics of casting so you get the benefit of as and more, maybe, I'm wrong about this but it feels right.

Anyway, I don't want to derail the discussion so if you feel like I'm doing it please, tell me and I'll stop.

[HaloFour]

@yaakov-h

IMHO it wouldn't be so bad if obj as int would always return a value of type Nullable<int>. It would then preserve the null semantics of obj as string (ref type vs value type).

Possibly, but that would be the same behavior as obj as int? which works today and is more explicit. Even if you take the null-propagation operator as an example of the compiler converting a fallible int expression and making the type Nullable<int> the reduction of a single character doesn't seem worth the time/effort.

[DavidArno]

Definitely agree with @HaloFour there. Having obj as int return an int? would be confusing and a waste of effort.

[osexpert]

What about introducing a cast keyword?
int j = await _service.GetIntAsObject() cast int;
This is sugar for:
int j = (int) await _service.GetIntAsObject();

[CyrusNajmabadi]

@gdalsnes I don't think there's any indicated interest in adding new syntax that serves the exact purpose of a normal (cast).