[swift-evolution] [Idea] NonEmptyArray

Haravikk swift-evolution at haravikk.me
Tue Jan 17 07:14:31 CST 2017

> On 17 Jan 2017, at 09:57, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> On Jan 17, 2017, at 03:40, Charlie Monroe via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> I've come across multiple cases, where you simply know the array is never empty and hence the optionality on first, last and behavior of a few other members is slightly different. Also, there are cases where you want to declare that you shouldn't pass an empty array e.g. into an initializer.
>> I was wondering whether Swift could have a specialized NonEmptyArray that could be used throughout the stdlib - e.g. String.components(separatedBy:) would return NonEmptyArray.
>> Thoughts?
> I've tried to make such a type a few times... The struct itself isn't hard ("var first:T; var tail:[T]"), but I never could figure out how to make `NonEmptyArray` conform to `ExpressibleByArrayLiteral` (because the protocol doesn't allow for failable inits) without just crashing if there wasn't at least one element.
> Anyway, I'm not opposed to adding it, as long as there's a non-crashy way to assign array literals to them.

Is a failable initialiser the way to go? Could we do something with some kind of compiler attribute?

For example:

	struct MyNonEmptyArray<E> : ExpressibleByArrayLiteral {
		typealias Element = E
		@minParameters(1) init(arrayLiteral:Element…) { … }

In this case the @minParameters attribute tells the compiler how many parameters must be present in direct calls to this method, however, for cases where this isn't possible to check it would still trigger a runtime error, but that would only be for more unusual cases like trying to handle this type as a generic ExpressibleByArrayLiteral.

Just trying to think whether there might be a more flexible way to do this, as if you can support arrays with at least 1 element, then why not 2 or 3 etc.? In the worst case this would just become a runtime error, which is how we would have to handle right now, but in more common cases the compiler can give an error right away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170117/30aeb75f/attachment.html>

More information about the swift-evolution mailing list