> On Dec 23, 2016, at 04:08, Антон Жилин <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
