Added Area-Language, Triaged labels.

This comment was originally written by bord...@gmail.com

If you decided to implement this, I'd recommend making Option<T> implement Iterable<T> and more tightly defining the return types of the methods that return Iterable to return Option<T>. I find the easiest way for users to reason about option is to present it as the an Iterable that contain 1 or 0 elements.

This comment was originally written by mario.plon...@gmail.com

I'm hoping opinions are allowed here: I really hope this "feature" as it is described doesn't make it into Dart, or at least get their own Map and List classes. Why? Because it actually makes code more verbose, without any additional benefit. If I'm just getting something wrong here, please correct me (mail is fine too).

I've tried to write code as I would do it two different ways, once with Dart as it is, and once with a hypothetical option type, using the examples and descriptions above.

// not really that much of a difference
//////
map["key"].map((String s) => print(s.endsWith("example"));
// VS
if(map["key"]!=null) print(map["key"].endsWith("example"));

// current way is even better? key presses in dart editor (without shift): 60 : 66
//////
itr.elementAt(2)
  ..map((s) => print(s))
  ..orElse("default");
// VS
if(itr.length > 2)
  print(itr.elementAt(2));
else
  print("default");

So, there isn't really much difference in "coding speed".
But what if I actually WANT to throw an error if an element doesn't exist? This use-case isn't described above, but I'd imagine it would look similar to this:

map["key"].doSomething();
// VS
map["key"]
  ..map((o) => o.doSomething());
  ..orThrow("'key' doesn't exist in map");

That's a lot of additional code, compared to previous use-cases.

This comment was originally written by mario.pl...@gmail.com

Why don't you just use a wrapper, if this behaviour is needed?

class Option<T> {
  
  T _val;
  
  Option(T v) {
    this._val = v;
  }
  
  void run(void fn(T param), [T defaultValue]) {
    T realVal = this._val;
    if(realVal==null && defaultValue!=null) realVal = defaultValue;
    if(realVal!=null) {
      fn(realVal);
    }
  }
  
}

class OptionList<T> extends ListBase<T> {
  
  List<T> _list;
  
  OptionList() {
    this._list = [];
  }
  
  OptionList.fromList(List<T> l) {
    this._list = new List.from(l);
  }
  
  Option<T> operator[](int index) => elementAt(index);
  
  Option<T> elementAt(int index) {
    if(index < this._list.length) {
      return new Option<T>(this._list[index]);
    }
    return new Option<T>(null);
  }
  
}

void main() {
  OptionList<String> l = new OptionList.fromList(["test1", "test2"]);
  l[0].run((s) => print(s), "element not found");
  l[1].run((s) => print(s), "element not found");
  l[2].run((s) => print(s), "element not found");
}

This comment was originally written by kurisu....@gmail.com

@mario, the use case isn't as much "speed of coding." It's mostly about correctness. Nullable types have been considered by most of the PLT community I know (and plenty of programmers in the Industry too!) as the biggest mistake in computing, because it makes everything so much more error prone — programmers are lazy ;)

When you can't have nulls creeping throughout all of your code base, you can not possibly have NullPointerException, and you're forced to be remembered that you're dealing with a computation that might fail, and handle the errors accordingly. When any type can also be null, someone might change something in an library you're using, and you will only realise things broke when you start getting random NullPointerExceptions far down the road where they've actually happened!

Set owner to @gbracha.
Added Accepted label.

As others have noted, you can definitely define your own Option class at the library level, and there are a number of third party ones floating around the ecosystem.

We don't currently have any plans to bake an option type into the core libraries. Instead, we're going to pursue supporting non-nullable types directly (#22). If that doesn't pan out, we may revisit this. But, until then, I'm going to close this as not planned.