`NonEmpty` collections support

[jawbroken]

@Dmitriy_Ignatyev

"why it's better to try to enforce this in the type system rather than just in an initialiser somewhere" – of course, there are throwable initializers and checks. The problem is that in large application we need to get data from server, save it in local database, do lots of filter-map & map-reduce operations.
So there is no guarantee in many pieces of code, that an Array of flights is not empty, because it is passed from one screen to another and modified, and if developer made an error, then array is empty.

Exactly, if you're doing filtering and reducing then you will be not be able to maintain the type-level guarantee that the resulting collection is still non-empty, so you're going to need to be making the moral equivalent of that runtime test all over again anyway. If you want to make it more concise then you could wrap it up in a firstAndLast: (Element, Element)? convenience property. A NonEmpty collection type can only carry its weight if you're using a collection in an immutable, append-only or reorder-only fashion across a large enough call graph.

[sighoya]

@jawbroken

A NonEmpty collection type can only carry its weight if you're using a collection in an immutable, append-only or reorder-only fashion across a large enough call graph

I think you can also delete elements, but you have the constraint not to delete anything if only one element is available :).

[Dmitriy_Ignatyev]

"wrap it up in a firstAndLast: (Element, Element)? convenience property" – this doesn't help in reality. Mental model is that it is not optional, but compiler still can not prove that.
As for filter-map & map-reduce, sorry for misleading. Travelroute itself is not filtered, it is only mapped. Saying filter-map & map-reduce is supposed in more wide meaning, not just applying functions like travelRoute.filter {}.map {}.
Examples I have provided are battle tested on real application from travel domain. Convenience of using NonEmptyArray is not theoretical reasoning. It is proven by real code and help a lot to reduce amount of code.
I just only share my own experience. If it was easy to write this code using Array and current language abilities, trust me, we would do) But using of plain Array leads to lots of meaningless if-let constructions or unsafe index operations. NonEmptyArray solves all these problems. The question is "Why should we suffer from using plain Array and write more complicated code, if there is alternative solution?"

Although, other variants are possible. If we have fixed size collections, like Array<Int, 1...>, then NonEmptyArray is not needed by itself. We can simply make typealias NonEmptyArray<T> = Array<T, 1...>

[idrougge (Iggy Drougge)]

Unfortunately, map et consortes will always map to a plain Array. You can’t map a Set to a new Set, for instance.

[DevAndArtist (Adrian Meister)]

Unless Swift would introduce higher kinded types, this is correct.

[Dmitriy_Ignatyev]

This will be fixed in future