FYI Why a .NET 2.0 project allows ?. operator

etienne_marais

Honorary Master
Joined
Mar 16, 2008
Messages
15,093
The ?. (null conditional / safe navigation) operator was added in C# 6.

We ran across a problem where a project using this operator did not compile in VS 2010 but did in VS 2015. The project was set as a .NET 2.0 project and it confused me why it should work in VS2015.

The reason turned out that this C# 6 feature is independent of the .NET framework, but dependent on the new Roslyn Compiler. There are however C# 6 features that ARE framework dependent and won't compile if you don't specify a .NET target version with a compatible CLR version.
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
6,282
Never seen the point of nullable (option) types in C# or Java 8 -- how can something that's optional ever be an effective solution to null pointer exceptions. Personally would have preferred it if MS and Oracle had taken a python 3 approach (break from backward compatibility). This "stupid" decision creates this type of confusion and circumvents general adoption of option types.

IMO They've either delayed the inevitable; or there's plans to replace C# and Java in the future.
 

etienne_marais

Honorary Master
Joined
Mar 16, 2008
Messages
15,093
[)roi(];18012764 said:
Never seen the point of nullable (option) types in C# or Java 8 -- how can something that's optional ever be an effective solution to null pointer exceptions. Personally would have preferred it if MS and Oracle had taken a python 3 approach (break from backward compatibility). This "stupid" decision creates this type of confusion and circumvents general adoption of option types.

IMO They've either delayed the inevitable; or there's plans to replace C# and Java in the future.

I feel your pain, but there is a workaround which involves an IL (MSIL) rewriter.

How cool would it be to just write this code and let the compiler do all the checks required?

Customer! customer = _repository.GetById(id);

Console.WriteLine(customer.Name);

Where Customer! stands for non-nullable type, i.e. a type whose instances can’t turn into null in any way. How cool would it be to be sure that the compiler will tell you if there are any possible code paths that return null?

Yep, very cool. Or even better:

Customer customer = _repository.GetById(id);

Console.WriteLine(customer.Name);

http://enterprisecraftsmanship.com/2015/03/13/functional-c-non-nullable-reference-types/
 

[)roi(]

Executive Member
Joined
Apr 15, 2005
Messages
6,282
I feel your pain, but there is a workaround which involves an IL (MSIL) rewriter.
:sick: not quite; the code I wrote before option types is certainly not something that is easily converted or reverse engineered; and it certainly shouldn't be -- I don't want to maintain / support the result. :crying:

Functional paradigms never work as an afterthought.

For example, I've found most GoF patterns are just no longer required or even applicable to FP.

If you're interested, here's a series of recent Java articles on this:
https://www.voxxed.com/blog/2016/04/gang-four-patterns-functional-light-part-1/
https://www.voxxed.com/blog/2016/05/gang-four-patterns-functional-light-part-2/
https://www.voxxed.com/blog/2016/05/gang-four-patterns-functional-light-part-3/
https://www.voxxed.com/blog/2016/05/gang-four-patterns-functional-light-part-4/
 
Last edited:
Top