feat: IListEmpty and friends

[LowLevelSubmarine]

Fix for #75

[LowLevelSubmarine]

I've just added the other Empty types aswell, do you have some suggestion what i could add to the current tests? @marcglasberg

[LowLevelSubmarine]

Two things: Whats your opinion on overriding isEmpty / isNotEmpty on the Empty types like so:

  /// An empty list is always empty, by definition
  @override
  bool get isEmpty => true;

  /// An empty list is always empty, by definition
  @override
  bool get isNotEmpty => false;

Do you think we should discourage or even disallow instantiating the IListEmpty directly instead of using IList.empty()? Although it is one char longer, i see the benefit of automatic type coercion beeing IList and not IListEmpty:

var ilist1 = IList.empty() // is of type IList
var ilist2 = IListEmpty() // is of type IListEmpty

I do not see the benefit of having a variable of type FooEmpty, users will always want to reassign the list if they declare an empty ilist right?

[marcglasberg]

Yes, you should override all methods that now have trivial implementations, including isEmpty etc. This will make it faster.

And I also see no point in instantiating IListEmpty directly, if you can simply write const ilist1 = IList.empty() and get an IList.

[LowLevelSubmarine]

What do you think can we do to discourage instantiating IListEmpty()? We could make the constructors private

[marcglasberg]

Yes, sure, make them private.

[LowLevelSubmarine]

I did all the changes we've discussed, you can merge now if you want

[marcglasberg]

Thanks.