Nested NonEmpty

[RemiBardon]

Following our discussion #45, here is a pull request introducing my proposed ideas.

It doesn't break any existing test, and adds new ones for introduced features.

Let me know what you think 🙂

[RemiBardon]

I just realized I forgot to add tests for try AtLeast3([1,2]) for example, which, obviously, doesn't throw 🙈
I'll fix it tomorrow 🛠

[RemiBardon]

Turns out it's quite easy to make XCTAssertThrowsError(try AtLeast10(Array(1...9))) pass, but I can't find a way to fix XCTAssertThrowsError(try AtLeast10(AtLeast10(Array(1...19)))).

[stephencelis]

@RemiBardon Just wanted to chime in to let you know we saw this, and thanks for exploring! We won't have time to dig in quite yet but hopefully soon.

[RemiBardon]

No problem, I'm busy too 😉

I really tried to work around my problem, but I couldn't find a clever way to do it without storing more than the initial collection in memory 😕

[RemiBardon]

I finally made it! It works like a charm 🙂

The biggest issue, which I tried hours to avoid, but couldn't get around, is that I have to store one Int along with the NonEmpty collections. This counts the minimum number of elements, and I could not avoid needing it.

I should have noted everything I tested, but my main problem was that because of how Swift's type system works, I couldn't create a static function which could calculate the minimum count from the type. With Swift 5.6, maybe it could work, but at least this solution doesn't break compatibility.

[RemiBardon]

@stephencelis This PR is now ready 🙂

[RemiBardon]

I found a bug, I'm fixing it.

For some reason, .drop10 can be called from an AtLeast2… which is super strange 🤔

fileprivate typealias AtLeast11<C: Swift.Collection> = NonEmpty<AtLeast10<C>>
extension AtLeast11 {
  public var drop10: NonEmpty<Collection.SubSequence> {
    try! NonEmpty<Collection.SubSequence>(from: self.rawValue.dropFirst(10))
  }
}

[RemiBardon]

I found a bug, I'm fixing it.

For some reason, .drop10 can be called from an AtLeast2… which is super strange 🤔

fileprivate typealias AtLeast11<C: Swift.Collection> = NonEmpty<AtLeast10<C>>
extension AtLeast11 {
  public var drop10: NonEmpty<Collection.SubSequence> {
    try! NonEmpty<Collection.SubSequence>(from: self.rawValue.dropFirst(10))
  }
}

This also means .tenth is available for AtLeast2 😭
This makes no sense but I'll have to change my extensions with a lot of where statements 😥 Hopefully it'll help 🤞🏻

[RemiBardon]

After hours of searching how to make drop10 type safe, I decided to remove it. It would probably never have been used anyway, as the use case is very specific.

[RemiBardon]

Nested NonEmpty do not have type safe (non-throwing) initializers, how did I miss it?

I'm adding them.

[RemiBardon]

b1a422a was a long commit… I had to change many things 😕

I see a few problems here:

• I added a safe atLeast2(_:_:) initializer, but because of the AtLeast2 type alias, AtLeast2(_:) also compiles. This means a single letter with bad casing can raise a fatal error 😰 I'll have to get rid of the type aliases 😕
• Because OneMore is a struct different from NonEmpty, I loose the extensions you created for NonEmpty, and if I copy them, they might not stay in sync.

Now that it works, I will try to refactor it in two steps:

1. Remove the type aliases
2. Try to remove the OneMore type, and use NonEmpty instead (with verbose type constraints, it might be possible, I'll see)

[RemiBardon]

2. Try to remove the OneMore type, and use NonEmpty instead (with verbose type constraints, it might be possible, I'll see)

The main problem with this is that I still have to separate two cases:

• When NonEmpty wraps any collection → Collection == RawValue
• When NonEmpty wraps a NonEmpty → Collection == NonEmpty<_>, RawValue == Collection.RawValue

The only way I can think of to separate these cases, and keep a single definition of protocol conformances, is to go back to the enum definition of NonEmpty. However, this time "head" and "tail" would mean "root NonEmpty" and "nested NonEmpty".

I will try to refactor this way, and I'll see where it takes me.

[RemiBardon]

I'll probably do one more step, which is to make NonEmpty a struct which stores a internal enum _NonEmpty. This way, people won't be able to access and alter the raw value.

[RemiBardon]

I feel stupid… I realize I can't have type safe nesting if I'm using enums 🤦🏻‍♂️

[RemiBardon]

I finally got it!

Separating WithMinimumCount from NonEmptyProtocol allowed me to avoid the "Self or associated type requirement" compiler error 😪 This was what blocked me in so many tries 😥

/// - Note: We need to separate `WithMinimumCount` from `NonEmptyProtocol`
///   to avoid the "Self or associated type requirement".
public protocol WithMinimumCount {
  static var minimumCount: Int { get }
}

[RemiBardon]

@stephencelis I marked this pull request as ready to review, as I think it has enough tests, which all pass, covering every requirement I had in mind.

I will start using it myself on my branch, to see if problems arise.

[RemiBardon]

One thing I would like to add, but I'm not sure if it's a good idea, is an extension saying AtLeast2(1, 2) is of type AtLeast2<[Int]> by default, to avoid needing <[Int]> everywhere. It's just syntactic sugar, with not much value (if at all), and potential issues, so I didn't include it here.

[RemiBardon]

I just force pushed twice to cleanup some things I had changed and shouldn't have.

I can also squash my commits if you want to.

[RemiBardon]

The biggest issue, which I tried hours to avoid, but couldn't get around, is that I have to store one Int along with the NonEmpty collections. This counts the minimum number of elements, and I could not avoid needing it.

Separating WithMinimumCount from NonEmptyProtocol allowed me to avoid the "Self or associated type requirement" compiler error 😪 This was what blocked me in so many tries 😥

/// - Note: We need to separate `WithMinimumCount` from `NonEmptyProtocol`
///   to avoid the "Self or associated type requirement".
public protocol WithMinimumCount {
  static var minimumCount: Int { get }
}

Oh, and by doing so, I was able to avoid storing minimumCount as a value, which is what I ultimately wanted 🤩

[RemiBardon]

I updated Xcode and the toolchain, and I get error: Abort trap: 6 (in target 'NonEmpty' from project 'swift-nonempty') 😭

It happens with:

• Xcode 13.3 (13E113)
• Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)

Let me fix it then…

Edit: Until then, I reported https://bugs.swift.org/browse/SR-16024.

[RemiBardon]

I removed AtLeast9 and AtLeast10, it fixes the issue and it was probably useless.

I propose we'll try to find a solution only if someone needs it.

[RemiBardon]

The biggest issue, which I tried hours to avoid, but couldn't get around, is that I have to store one Int along with the NonEmpty collections. This counts the minimum number of elements, and I could not avoid needing it.

Separating WithMinimumCount from NonEmptyProtocol allowed me to avoid the "Self or associated type requirement" compiler error 😪 This was what blocked me in so many tries 😥

/// - Note: We need to separate `WithMinimumCount` from `NonEmptyProtocol`
///   to avoid the "Self or associated type requirement".
public protocol WithMinimumCount {
  static var minimumCount: Int { get }
}

Oh, and by doing so, I was able to avoid storing minimumCount as a value, which is what I ultimately wanted 🤩

Following this discovery, I realised I could revert some changes I made in the code, to make the Pull Request as clean as possible.

[RemiBardon]

Converting this Pull Request to draft once again, because by using it I realized it introduces a huge increase in compile time (see https://forums.swift.org/t/wrong-redundant-conformance-constraint-warning/56207/15).

I will mark this PR as "ready" once I fix this issue.

[RemiBardon]

Worth sharing here: https://twitter.com/slava_pestov/status/1507537318315450370

[RemiBardon]

A new trunk development snapshot was released, and now everything (including AtLeast9 and AtLeast10) compiles in "normal" time.

I don't mark the PR as "ready", as you might want to wait for the compiler have a stable release containing the fix. I will use my branch personally, and wait for your approval on this PR.