with it's Optional type,

C# has Nullable<T> (aka T?)[0]. I'm not a Java expert, but they appear to be the same (represent a value or a null value, allow you to inspect for the presence of a value or null).

ex:

  int? x = null;
  int y = x ?? 0;
  int z = x.HasValue ? x.Value : 0;
  if(x.HasValue && x.Value == 42){}

C# definitely doesn't have checked exceptions.

edit:

For reference types, as compared to value types, c# has the null coalescing operator

  List<string> y = someList() ?? new List<string>;

and the null conditional operator

  int? length = customers?.Length; // null if customers is null

which are defintely not Optional, but are what I use.

[0] - https://msdn.microsoft.com/en-us/library/1t3y8s4s.aspx

Yes, Nullable was introduced in 2005 with C# 2.0 if memory serves me right.

Checked Exceptions was a design choice, http://www.artima.com/intv/handcuffs.html

Nullables work at a pinch, but they are a poor mans option type.

http://fsharpforfunandprofit.com/posts/the-option-type/

Scroll down to "Option vs. Null vs. Nullable" for an explanation of the differences.

I'm unfamiliar with Java's Optional type, but the .NET type Nullable can only be parameterized over value types. It is there to add the concept of null to value types, not allow you to more precisely characterize the nullability of reference types.

Optional in Java is just a library. If you want to to use Optional in C#, there is no reason to believe that that is not possible due to some issue that makes it only available to Java. https://github.com/louthy/language-ext/tree/master/LanguageE...

I didn't imply it was desired or wasn't possible...? Another reply to my comment clarified that Optional also only applies to value types, which makes it analogous to Nullable. There's no reason to port it (as opposed to any other implementation of an Optional type) over.

What is really necessary is an equivalent for reference types.

struct Maybe<T> where T : class {

  private bool _isInitialized;
  private T _data;

  public Maybe(T data) {
    _isInitialized = (data != null);
    _data = data;
  }

  // ...etc
}

> Optional also only applies to value types

no - Java's Optional applies to reference types.

Yes, I was misreading the documentation. The Optional class itself is to be considered a value type, and reference equality on Optional objects shouldn't be done.

And in Java they're in the the standard library. Which is going to go down better - simply using something official that every java library program will already have, or trying to explain to your colleagues why all your methods are returning something defined in this obscure library you added to all your builds?

Only since Java 8. The coalesce operator is in c# since the version 3.5 or 4 I think and c# 6 introduced the null conditional operator that, as I said before, is objectively nicer than the verbose Java optional. Before c# 6 I used this simple extension method:

    public static TDest IfNotNull<TSource, TDest>(this TSource obj, Func<TSource, TDest> func)
    {
        return obj != null ? func(obj) : default(TDest);
    }

Or something similar (writing c# code on the iPad before sleeping is not exactly simple), inspired by some blog post ages ago. Just adding these three line of codes in a static class in the solution will enable you to write something like this:

    var id = order.IfNotNull(o => o.Customer).IfNotNull(c => c.Id) ?? "INVALID"

Still not as good as the null check operator but comparable with the Java optional (arguably better from my point of view)

How is it better? All you've done is re-implemented mapping over an option. Your C# code is this in Java:

    String id = order.map(o -> o.Customer).map(c -> c.Id).orElse("INVALID");

The Java code is actually shorter and works straight out of the box, so I don't know why you're calling Optionals "verbose".

The null check operator is much more concise than my pre-c# 6 solution. Moreover you can apply both my solution and the null check operator to any type, while for Java you have to specify that a field is optional (increasing the verbosity and moving the responsibility to who write the class) and you can't do it for types that you don't own. So for these types the only way is to create a wrapper type just to add the optional fields, and this brings the amount of boilerplate code through the roof. So, just to sum it up, contrary to what you say the c# solution works out of the box, is much shorter than the Java alternative and works for every type. Honestly I can't really see why Java solution is superior for you.

It's not shorter than out-of-the-box c# 6, which would be var id = order?.Customer?.Id ?? "INVALID";

I think that was the point he was making, that it's always been possible, and now is simple.

Except that nullable types aren't the same thing as option types, so it's not doing the same thing. Nullables are much weaker than options. You can't do this for instance:

    string? id = "Name";

While you can do stuff like this:

   int x = 0;
   int? y = x;

Again, F# has nullable types and options, and the fact that no one in F# uses nullable types should tell you something.

this is a different question than the premise you initially outlined "It's much easier to write robust code in Java - with it's Optional type... than in C#."

Why the pedantry? C# is my day job - I'd love to be able to use options but I would have a hell of a time getting it cleared.

Your quote also omitted checked exceptions, which is another reason why it's easier than me to write robust code in Java than in C#.

You seem to be making several arguments at once. My only point is that C# has no problem implementing java's Optional, which some other folks seemed confused about, and there are already libraries that do so. If there is a social/cultural issue too, I was not commenting on that, or commenting on the usefulness of checked exceptions.

Look how many people here are advocating for the nullable hack because they don't understand what an option is. With java the discussion could be side stepped entirely, since they added proper support and put it in the standard lib.

Again, you are arguing a different point than than one I was addressing.

edit: this is wrong, I was misreading the documentation, which states that the Optional class is a value type, not the contents of the Optional class.

According the documentation, Optional is only valid with value types[0]:

"This is a value-based class; use of identity-sensitive operations (including reference equality (==), identity hash code, or synchronization) on instances of Optional may have unpredictable results and should be avoided."

Again, I have no experience, so if this is wrong, then additional corrective references would be awesome.

[0] - https://docs.oracle.com/javase/8/docs/api/java/util/Optional...

> I really hate this attitude. Programming languages should be designed to be safe and strict by default, but with easy outs. I utterly reject the notion that we should design languages first and foremost to protect us from people can't program that well or aren't careful when they write code.

I don't think the author has a beef with easy outs, but with accidental outs. Specifically with regards to the JVM, too, there are some practical security ramifications, with regards to running plugins.

Thanks god c# doesn't have checked exceptions, they are just an enormous pain, especially when heavily using actions and functions, and most of the time they are completely ignored, rendering them completely useless. The option type in Java is extremely verbose and doesn't guarantee that you won't have null pointers. In c# you can use the null conditional operator and the coalesce operator that at least are much less verbose and more elegant. The best solution is obviously to use a functional language like f# where you can't have null pointers.

> The best solution is obviously to use a functional language like f# where you can't have null pointers.

You absolutely can:

    Microsoft (R) F# Interactive version 14.0.23413.0
    Copyright (c) Microsoft Corporation. All Rights Reserved.

    For help type #help;;

    > let s:string = null ;;

    val s : string = null

String is a .net type, f# types cannot reference null unless you explicitly add some attribute if I recall correctly.

checked exceptions? They lead to very un-robust code like try{...}catch(Exception e){//ignore or log, continue along like everything is grand!} or (much better) every method declaring "throws Exception"

Sure, it may lead to that kind of code if you have mediocre programmers who don't care about robustness - absolutely. But in C# it's much harder to keep track of all the exceptions that might be thrown.

Now, if a programming language has error aware return types - using algebraic data types or multiple dispatch - that's a better solution than both. But in the absence of that, give me checked exceptions over unchecked ones any day.

We don't always have to appeal to the lowest common denominator, but languages that do appeal to more people. Hence popularity.