NonEmpty(List, 1, 2, 3) : NonEmpty[List[Int]] // with (1, 2, 3) as elements

Usable proof that NonEmptyF is actually equivalent to its NonEmpty parent type, not a strict subtype. (We want Scala to treat it as a strict subtype, usually, so that the type will be deconstructed by partial-unification correctly.)

Like apply, but because A occurs directly in the result type, if the call to mk has an expected A type, hd and tl will have that expected type as well. Particularly useful for Sets, as expected type can widen the element type of the produced set, and _ as an argument, because the lambda argument type can be inferred from the expected result type.

However, strictly speaking, it is less general than apply; for example, it doesn't work on Maps at all. So it should only be used when you need its particular type inference behavior. See "mk" should tests in NonEmptySpec.scala for examples where mk works but apply doesn't.

Usable proof that NonEmpty is a subtype of its argument. (We cannot put this in an upper-bound, because that would prevent us from adding implicit methods that replace the stdlib ones.)

In pattern matching, think of NonEmpty as a sub-case-class of every imm.Iterable; matching case NonEmpty(ne) adds the non-empty type to ne if the pattern matches.

You will get an unchecked warning if the selector is not statically of an immutable type. So scala.collection.Seq will not work.

The type-checker will not permit you to apply this to a value that already has the NonEmpty type, so don't worry about redundant checks here.