[Pitch?] Way to declare a Swift Array that guarantees it can't be empty

This isn't a fully formed pitch, and maybe already discussed, but...

If we have have optionals and non-optionals, shouldn't we also have a way
to declare that an Array never be empty? It seems like this would naturally
lead to more elegant designs.

Here's a use-case:

struct Wavelet {
var buff: [Double]
var sign: Sign
var peak: Double {
return buff.find_max()! // <-- Yuck!
}
}

In my app, I never want to create an empty "buff" here. If I could declare
that the Array always contain at least 1 element, I wouldn't need to worry
about a whole bunch of unwrapping elsewhere in my program. Native ability
to do this would also be handy to store chunks of memory, too?

Would this be worthwhile?

I think it would make sense to have arrays with a minimal size, but wouldn't consider it very important.
But there is a long-running discussion about fixed-size arrays, and depending on (if any) solution is chosen for them, your use case could be solved rather easy as well.

You would have this guarantee with the fixed-size arrays currently being discussed.
Perhaps this could be an amendment to that proposal - you could declare an array with bounds for its size.
Fixed-size arrays would be a subset of those where the upper and lower bounds are equal.
They could also offer non-opitional ‘first’ and ‘last’ properties, which, if the bounds are fixed,
could use the tuple .0, .1, etc syntax.

···

This isn't a fully formed pitch, and maybe already discussed, but...

If we have have optionals and non-optionals, shouldn't we also have a way to declare that an Array never be empty? It seems like this would naturally lead to more elegant designs.

Here's a use-case:

struct Wavelet {
var buff: [Double]
var sign: Sign
var peak:Double{
returnbuff.find_max()! //<-- Yuck!
}
}

In my app, I never want to create an empty "buff" here. If I could declare that the Array always contain at least 1 element, I wouldn't need to worry about a whole bunch of unwrapping elsewhere in my program. Native ability to do this would also be handy to store chunks of memory, too?

Would this be worthwhile?

I had a similar though some time ago (and even suggested it here) - as e.g. "Hello".components(separatedBy: "123") will always produce a non-empty array. Even "".components(separatedBy: "") is [""].

Which would allow e.g. first, last and some other members to loose the optionality - which would be great. But would probably add unnecessary complexity to the stdlib.

Fixed-size arrays do not solve this particular issue that I've noted above.

···

On Aug 8, 2017, at 1:39 PM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

I think it would make sense to have arrays with a minimal size, but wouldn't consider it very important.
But there is a long-running discussion about fixed-size arrays, and depending on (if any) solution is chosen for them, your use case could be solved rather easy as well.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Fixed-size arrays do not solve this particular issue that I've noted above.

And I didn't say so :wink:
But generic value parameters would not only allow you to define fixed-size arrays, but also arrays with certain other properties:
Minimal size, maximal size… maybe even number of elements or other more complicated things.
(that is one reason why I think this is the best approach — its more versatile than the alternative)

I really hope that you find supporters for non-empty arrays - that would also be a strong motivation to add subtyping for arrays :wink: (struct NonEmptyArray: Array)

Terms of Service

Privacy Policy

Cookie Policy