> On 29 Jan 2017, at 00:16, Slava Pestov <spes...@apple.com> wrote:
>
>>
>> On Jan 27, 2017, at 4:55 PM, Karl Wagner <razie...@gmail.com
>> <mailto:razie...@gmail.com>> wrote:
>>
>>
>>> On 27 Jan 2017, at 22:25, Slava Pestov <spes...@apple.com
>>> <mailto:spes...@apple.com>> wrote:
>>>
>>>
>>>> On Jan 27, 2017, at 11:44 AM, Karl Wagner via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>> So, 2 quick points:
>>>>
>>>> 1) I have often wanted a shorthand for expressing long tuples; I
>>>> definitely think that’s something worth bike-shedding, e.g. - (String * 4,
>>>> Int32 * 4) or something
>>>
>>> Why not define a struct, or a tuple consisting of two arrays?
>>
>> Because I want a fixed-length guarantee; ([String], [Int]) could have any
>> number of Strings or Ints.
>
> Ok, maybe a struct would named fields would be better though.
>
>> It’s just a shorthand for defining long or complex tuples; we currently
>> import C arrays as massive tuples which can be basically impossible to read.
>
> I agree that this is a problem — fixed length arrays should be imported
> better, once we have the right language features.
>
>>
>>>
>>>> 2) Having a special non-growing array type which is called “array” and
>>>> separate from Array<T> is not such a good idea IMO. I would rather allow
>>>> tuples to conform to protocols (see:
>>>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types
>>>>
>>>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types>).
>>>>
>>>> If tuples could conform to protocols, we could say “any tuple of
>>>> homogenous elements is a Collection”. There would be benefits for the
>>>> standard library, too - EmptyCollection<T> would disappear, replaced with
>>>> the empty tuple (),
>>>
>>> This sounds too clever.
>>
>> Yeah… the cleverness is one of things I like about it. We get to remove
>> these canned conformances and reduce the stdlib surface area while gaining
>> an efficient way to express a fixed-size Collection. It would come with all
>> kinds of supplementary benefits, such as iterating and mapping the elements
>> of a tuple.
>>
>>>
>>>> as would CollectionOfOne<T>, to be replaced by a single-element tuple (T).
>>>
>>> For what it’s worth, Swift doesn’t have single-element tuples. (T) is just
>>> sugar for the type T itself.
>>
>> Would it be unreasonable to separate those, so that (T) is separate from T
>> instead of being a synonym for it? There is some awkwardness with tuples due
>> to legacy designs. Perhaps this would help clean it up a little (or perhaps
>> make it worse, who knows?)
>>
>> For source compatibility, we could allow an implicit conversion; in the same
>> way that a T can be implicitly “promoted" to an Optional<T>, it could be
>> implicitly “promoted” to a single-element tuple of T (and vice-versa).
>
> Sure, we *could* re-design tuple types in a way where single element tuples
> make sense. Then we’d have to come up with a source compatibility story for
> Swift 3 vs Swift 4, fix any fallout (compiler crashes) from this change,
> implement migrator support when the stdlib is changed to use the new
> features, etc. But think of it this way — every such “unnecessary” change
> (and I realize this is subjective!) is taking away cycles the team could use
> to fix crashes, improve compiler speed, and improve diagnostics. Not to
> mention implementing the other evolution proposals which arguably increase
> expressive power in important ways we feel we need for ABI stability, such as
> generic subscripts.
>
>>
>>>
>>>> We would also be able to remove our limited-arity == overloads in favour
>>>> of actual, honest-to-goodness Equatable conformance.
>>>
>>> I like this idea though.
>>>
>>>>
>>>> - Karl
>>>>
>>>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types>_______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
I appreciate that, but I don’t think this is a small feature. Fixed-size arrays
(or, more generally, fixed-size collections) are an important hole in the
standard library. I think it’s a given that we want to approach that one day.
At the same time, we already _have_ tuples. They use these freestanding
limited-arity == operators rather than an actual Equatable conformance, so they
can’t be used as Equatables by generic code. If we did improve that, the same
mechanism (whatever it is) would like have all the bolts in place for a
Collection conformance, too - and that’s great, since conceptually a tuple is a
group of things. There would, of course, be an implementation cost - but likely
less than what the OP suggested (with a whole new “array” declaration).
Consider even if we had compile-time constants like Vector<T, size: Int> — how
would that be implemented? What would its backing-type be? It would probably
want to use that constant to create a fixed-length tuple; again, there would be
less implementation effort by just having the tuple conform to Collection
directly, instead.
Single-element tuples aren’t necessary for Collection conformance, anyway. It
would just make things _even_ neater by allowing us to remove a standard
library type.
- Karl
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
