Hi 👋

I'm trying this library out in my codebase. I already have a naive extension on Array -- a computed property called nonEmpty -- which returns self if the array has at least one element, or nil otherwise. Literally just

extension Array {
    var nonEmpty: Array<Element>? {
        guard !self.isEmpty else { return nil }
        return self
    }
}

But I would rather use the NonEmptyArray type in this library. So I changed my extension to return a NonEmptyArray if possible, like this:

import NonEmpty

extension Array {
    var nonEmpty: NonEmptyArray<Element>? {
        guard let head = self.first else { return nil }
        let tail = Array(self.dropFirst())
        return NonEmptyArray(head, tail)
    }
}

Now the problem is that all my existing code that depends on this extension still expects the result to be an Array, and not a NonEmptyArray. The two are of course not interchangeable.

Logically, if you think about it, a NonEmptyArray is functionally equivalent to an Array (though not the other way around). Any operation or method that takes a list of something should also work with a non-empty list of those things. So I was wondering if you have any tips for elegantly converting from NonEmptyArray to Array? Best I've come up with so far is a computed property on NonEmptyArray, or an initialiser on Array. Swift is (for better or for worse) deliberately designed to avoid implicit conversions, making these strategies quite verbose.

If this were a new project, I could just use NonEmptyArray instead of Array anywhere that it makes sense, which I imagine is in most places. But doing that conversion now would be too painful.

It looks like conforming to the ExpressibleByStringLiteral protocol isn't safe and leads to the following use case:

let a: NonEmptyString = ""

And obviously it is a silenced crash.
The same for all the other initializators like this.

As far as I see, it was discussed before there: #48 (comment). Don't you think that avoiding cases like the one above is the exact reason of having such a solution?

Swift.DecodingError.typeMismatch(Swift.Dictionary<Swift.String, Any>, Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "poiList", intValue: nil)], debugDescription: "Expected to decode Dictionary<String, Any> but found an array instead.", underlyingError: nil))

This is my structre

struct LocationCarModel: Codable {
    
    // MARK: - Properties
    var poiList: NonEmptyArray<PointOfInterest>
    
    // MARK: - PointOfInterest
    struct PointOfInterest: Codable {
        var id: Int
        var coordinate: Position
        var fleetType: String
        let numberPlate = "HCD837EC"
        let model: String = "Tesla S"
        let fuel: Double = 0.9
    }
}

This is the response I'm getting https://fake-poi-api.mytaxi.com/?p2Lat=53.394655&p1Lon=9.757589&p1Lat=53.694865&p2Lon=10.099891

and this how I'm decoding it.

 public extension Decodable {
   
   static func parse(from item: Any?, strategy: JSONDecoder.KeyDecodingStrategy = .useDefaultKeys) -> Self? {
       
       guard let data = self.data(from: item) else {
           return nil
       }
       
       let decoder = JSONDecoder()
       decoder.keyDecodingStrategy = strategy
       
       do {
           let result = try decoder.decode(Self.self, from: data)
           return result
       } catch {
           debugPrint(error)
           return nil
       }
   }
   
   private static func data(from item: Any?) -> Data? {
       switch item {
       case let data as Data:
           return data
       case let string as String:
           return string.data(using: .utf8)
       case .some(let item):
           return try? JSONSerialization.data(withJSONObject: item, options: [])
       case nil:
           return nil
       }
   }
}

and the line to decode using the above function is

let model = LocationCarModel.parse(from: data)

Any ideas how I can solve this issue? Any help would be appreciated. Thank you in advance.

Hi there, any plans on releasing a new version? One hasn't been released since #26 was merged.

struct Emoji {
    let aliases: NonEmpty<[String]>
    let tags: [String]
}

let emoji = /* an Emoji */
let searchTerms: [String] = [emoji.aliases, emoji.tags].flatMap { $0 } // error

The error is Cannot convert value of type '[Any]' to specified type '[String]'.

I'm using Xcode 11.4.1 and Swift 5.

It would be very convenient to have these conformances, since non-empty collections could be initialized as naturally as the built-in collection types:

let x: NonEmpty<[Int]> = [1, 2, 3]
let y: NonEmpty<[Int: String]> = [1: "abc", 2: "def"]

However, since ExpressibleByArrayLiteral and ExpressibleByDictionaryLiteral don't allow their initializers to fail, we would have to crash at runtime, which might not be desirable given the description of the library as a compile-time guarantee:

init(arrayLiteral: Element...) {
  guard !arrayLiteral.isEmpty else { fatalError("Non-empty array literal!") }
  self.init(rawValue: arrayLiteral)!
}

or

init(arrayLiteral: Element...) {
  assert(!arrayLiteral.isEmpty, "Non-empty array literal!")
  self.init(rawValue: arrayLiteral)!
}

Thoughts?

Trying to compile in Xcode 11 beta 2 result in the build error. It might be Xcode issue (and I haven't tried latest beta) but maybe you'll have an idea for a fix if it is not.

Build NonEmpty_2019-07-07T16-23-17.txt

UPD: same on beta 3

I'm using SwiftUI's move(fromOffsets:toOffsets) method on MutableCollection to move an element in my non-empty array, since it's O(n log n), whereas if I were to do it manually using remove(at:) and insert(at:) the operation would be O(n^2). However, using it on NonEmpty always leads to a crash:

import NonEmpty
import SwiftUI

var nonEmpty: NonEmptyArray<String> = .init("Hello", "Kenobi...", "there!")

nonEmpty.move(fromOffsets: IndexSet(integer: 1), toOffset: 3) // Thread 1: EXC_BAD_ACCESS (code=2, address=0x16f603fc0)

print(nonEmpty)

Using a normal Array works just fine:

var array: Array<String> = ["Hello", "Kenobi...", "there!"]

array.move(fromOffsets: IndexSet(integer: 1), toOffset: 3)

print(array) // ["Hello", "there!", "Kenobi..."]

Could it be due to some quirk in NonEmpty's conformance to MutableCollection?

Your extension NonEmpty where C: MutableCollection, C.Index == Int breaks for base collections that have integer indices that don't necessarily start at zero, such as ArraySlice or Data.

Example: this test crashes with "Fatal error: Index out of bounds".

  func testMutableCollectionWithArraySlice() {
    let numbers = Array(1...10)
    var xs = NonEmpty(0, numbers[5...])
    xs[1] = 43
    XCTAssertEqual(43, xs[1])
  }

I was attempting to decode a network response that contains an array directly to NonEmpty. However, the synthesized decodable init does not work with an array as the input. I attempted to override the synthesized init via an extension, but it's ignored at runtime.

I'm wondering if we could remove that conformance from the library and let clients add the conformance as needed to allow for more flexible decoding. The other option is that I'm doing something wrong, of course :)

It looks like if I were to pass a NonEmptyArray an input of type Range or ClosedRange, NonEmptyArray actually produces an array comprising a single element, which is that range itself, instead of an array comprising the numbers within the range:

// Succeeds
func testArrayRange() {
  let input = 0...2
  let fooList: [String] = Array(input).map {
    "\($0)"
  }
  XCTAssertEqual(fooList, ["0", "1", "2"])
}

// Fails
func testNonEmptyArrayRange() {
  let input = 0...2
  let fooList: [String] = NonEmptyArray(input).map {
    "\($0)"
  }
  XCTAssertEqual(fooList, ["0", "1", "2"])
}

I tried creating a fix myself so I could just create a PR and save you all time, but I'm struggling to get a way to generate the expanded array and map that to an existing NonEmpty convenience initializer. Maybe I'm the only one in the world to try and use NonEmptyArray in this manner and it's not worth the effort ;)

See: pointfreeco/swift-html#27

If the elements in the collection are Sendable, NonEmpty variant of it should be too

If building using the release config on the master branch:

swift build -c release

The build fails with a bunch of errors relating to Collection protocol conformance. Seems bizarre as the debug build works fine, so not sure if its a linker bug similar to SR-11564.

Do not declare new conformances to StringProtocol. Only the String and Substring types in the standard library are valid conforming types.

https://developer.apple.com/documentation/swift/stringprotocol

Hi, thanks for this great library. I was just curious how you handle some conflicts for specific collections, as each collection has certain characteristics. For example, dictionary can't store duplicated keys

let zs = NonEmpty<[Int: String]>((1, "one"), [1: "one again", 3: "three"])

I think we need to have specific init extension for each kind of collection, like for Set 🤔

extension NonEmpty where C: SetAlgebra

I'm suddenly getting this issue when using Validated 0.2.1 and NonEmpty 0.3.0.

The compiler says he has these two candidates:

  public static func + <S: Sequence>(lhs: NonEmpty, rhs: S) -> NonEmpty where Element == S.Element {
    var lhs = lhs
    lhs += rhs
    return lhs
  }

  public static func + <S: Sequence>(lhs: S, rhs: NonEmpty) -> NonEmpty where Element == S.Element {
    var rhs = rhs
    rhs.insert(contentsOf: ContiguousArray(lhs), at: rhs.startIndex)
    return rhs
  }

In the issue #1 you fixed the case:

  func testMutableCollectionWithArraySlice() {
    let numbers = Array(1...10)
    var xs = NonEmpty(0, numbers[5...])
    xs[1] = 43
    XCTAssertEqual(43, xs[1])
  }

But is it expected to have an index 1 on a NonEmpty of ArraySlice starting with 5?

I really like the safety of NonEmpty. I am writing a fully type-safe geographical library, also providing GeoJSON mapping, and I need to store arrays that have at least four values for example (see RFC 7946, section 3.1.6 for example).

I thought I'd use NonEmpty<NonEmpty<NonEmpty<NonEmpty<[MyType]>>>>, but I was surprised to se it's not how the library works. NonEmpty.swift#L9-L10 shows that the collection is stored as-is, not cut into a head value and a tail Slice.

Is it a conscious choice? Wouldn't it be semantically better to make NonEmpty behave as I thought?

thanks for the library! would it be possible to get 0.4.1 released so that #57 (Sendable conformance) could be included?

The purpose of this package is to provide a provable, compile-time guarantee that it holds a non-empty collection. There are valid reasons why a compile-time guarantee is better than a runtime check.

Recently the implementation was changed to a runtime check without updating the readme, so now this one-liner crashes the library:

withUnsafeBytes(of: "") { $0.load(as: NonEmptyString.self).first }

All because the library no longer provides a compile-time guarantee as it claims. A previous implementation with head is resilient to those types of crashes.

I suggest either to revert the implementation or to change the description of the library.

How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

^SemVer.org

The release major version number is still less than 1 (right now, it's 0.2.2). By the SemVer standard, this mean that this is still in initial development and the API may change drastically between minor versions:

4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

^SemVer.org

Since it seems initial development is complete and this is ready for production use, can we increment the major version number to 1 (or greater) to indicate this? That would not preclude big future changes which change the functionality or public API:

8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

^SemVer.org