Roslyn: [Proposal] Simplify boolean test of null with objects
Synopsis
Every object has those _canonical methods_: Equals(), GetHashCode(), GetType(), ToString(), with one more for value type: CompareTo().
Every object also has that _eternal boolean test_: if(someObject == null) { ... } or if(someObject != null) { ... }. Can we have some simplification here that the compiler can help with by abstracting the boolean test?
Proposal
A similar idea had been floated previously under #9606 by using the Null Propagation Operator (?). This proposal promotes the same concept but instead by using a pseudo property notation on an object as illustrated below. The property notation (syntactic sugar) is simply to abstract the boolean test.
Instead of if(someObject == null) { ... } => if(someObject.IsNull) { ... }
Instead of if(someObject != null) { ... } => if(someObject.IsNotNull) { ... }
Discussion
Really brief one here. The proposed technique enhances code readability, simplifies formation of more complex logic with multiple variables, and yes, reduces keyboard strokes with IntelliSense code completion.
dg2k
All 8 comments
I don't see how this new notation is any more readable than using the equality operators. If anything it's more confusing because someObject.IsNull should never be capable of evaluating to true, it should throw. This would create weird caveats to the existing semantics of the language. I argue that it's _less_ readable because now anytime you see an attempt to read a property you have to stop and mentally change context to evaluate if that is one of those weird "pseudo-properties".
How would you propose to deal with objects that actually have IsNull or IsNotNull properties? Changing how the compiler considers that syntax would be a breaking change. This increases confusion as anytime you see someObject.IsNull you then have to figure out if IsNull is one of these "pseudo-properties" or an actual property. If it is an actual property, if (someObject.IsNull) would certainly throw, which is not the desired behavior.
With #11159 you may be able to extend System.Object in order to offer these "pseudo-properties" as extension properties. That should allow you to effectively offer this syntax without making any changes to the language in order to support it.
HaloFour
on 26 May 2016
@alrz - care to share your thoughts for the thumbs down? I would appreciate your reason(s) behind it.
dg2k
on 26 May 2016
C# doesn't have the concept of "pseudo property" anywhere in the language, besides, this is not a "property" of the object in any ways, it's about the value itself, so if it was null I expect to get an exception if I didn't use the null propagation operator. idiomatically. If you think IsNull is any more readable than an operator you can use extension classes — if and only if you do it anywhere in your codebase, for the sake of consistency.
alrz
on 26 May 2016
@dg2k You can already do this via extension methods.
c#
public static class exts
{
public static bool IsNull<T>(this T obj) where T is class
{
return obj == null;
}
public static bool IsNotNull<T>(this T obj) where T is class
{
return obj != null;
}
}
AdamSpeight2008
on 26 May 2016
I'm not sure that this proposal adds enough value to modify the language. Especially with extension methods (and perhaps extension properties soon) allowing us to implement it ourselves.
AlgorithmsAreCool
on 26 May 2016
These pseudo-properties are jarring; they don't match with anything else in C#. I think it's not even true that every object has the "eternal" boolean test == null. There are just as many objects and contexts for which these properties showing up in Intellisense would look patently dumb. new MyObject().IsNull what? Even if an object could be null I wouldn't want Intellisense to be _eternally_ making me think about null comparisons when I'm doing other tasks. It's just unhelpful noise, especially since in C# 6 null comparisons are rarer for me than ever.
Some kind of ReSharper template would help with saving keystrokes, if your code does in fact have a ton of null comparisons.
jnm2
on 26 May 2016
I would prefer a unary prefix opererator for null checks (already suggested in #9606).
MillKaDe
on 30 May 2016
We are now taking language feature discussion in other repositories:
- https://github.com/dotnet/csharplang for C# specific issues
- https://github.com/dotnet/vblang for VB-specific features
- https://github.com/dotnet/csharplang for features that affect both languages
Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.
In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.
Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.
If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.
Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to https://github.com/dotnet/roslyn/issues/18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.
I am not moving this particular issue because I don't have confidence that the LDM would likely consider doing this.
gafter
on 29 Apr 2017
Related issues
binki
·
3Comments
asvishnyakov
·
3Comments
nlwolf
·
3Comments
OndrejPetrzilka
·
3Comments
orthoxerox
·
3Comments
Most helpful comment
@dg2k You can already do this via extension methods.
c# public static class exts { public static bool IsNull<T>(this T obj) where T is class { return obj == null; } public static bool IsNotNull<T>(this T obj) where T is class { return obj != null; } }