[swift-evolution] Three quick(ish) generics enhancements; *maybe* phase 1

David Sweeris davesweeris at mac.com
Fri Dec 23 10:19:34 CST 2016


> On Dec 23, 2016, at 04:08, Антон Жилин <antony.zhilin at gmail.com> wrote:
> 
> On 2) and 3), I feel like @pure and variadic generics/tuples would cover most of the use cases.

How so? I agree that variadic tuples could replace the third example (quite well, actually), but I don't see how they or @pure (alone or in combination) have the same functionality in general. With default generic parameters, you could effectively have partial sub-typing of non-reference types. You wouldn't be able to add any non-computed properties, but every function and computed property could have a different implementation depending on the value of the generic parameter in question. Of course, we could do this now, but it'd be quite annoying to have to specify, say, 5 configuration every parameter when most of the time they have the same value (and it'd be quite easy to make a mistake in their order without the labels reminding you what goes where).

Is your claim that, regardless of whether their functionality exactly overlaps, for any given use case for 2&3, there's a semantically (as opposed to syntactically) equivalent way to do it with the existing language plus @pure or variadic generics/tuples? Strictly speaking, I'm not sure I can disprove that. It seems to me, though, that it'd be easier to have an 'Array<T, Length: 3, FixedSize: true>' interoperate with the rest of the stdlib than it would a '(T, T, T)'. (Don't misunderstand me, though, I'm still very much in favor of enhancing tuples... they solve different problems.)

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161223/633f78fc/attachment.html>


More information about the swift-evolution mailing list