Ad-hoc compiler attributes won't go far. What about arrays with even number of elements? Sorted arrays? Reverse-sorted arrays?
I think support for such feature has to wait for a macro system. Then, the topic of non-empty arrays will come back, stronger than ever. Gwendal > Le 17 janv. 2017 à 14:14, Haravikk via swift-evolution > <[email protected]> a écrit : > >> >> On 17 Jan 2017, at 09:57, David Sweeris via swift-evolution >> <[email protected] <mailto:[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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
