> On 17 Jan 2017, at 09:57, David Sweeris via swift-evolution 
> <[email protected]> wrote:
> 
> 
> On Jan 17, 2017, at 03:40, Charlie Monroe via swift-evolution 
> <[email protected] <mailto:[email protected]>> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to