~Robert Widmann
2016/09/16 10:03、Muhammad Tahir Vali のメッセージ:
> Type safety would make tuples far more powerful than their current
> limitations.
Tuples, like every other language construct in Swift are typed. If you find a
situation where they aren't, please let us know via JIRA or radar.
> Structs are usually used for slightly more complex objects compared to tuples
> and usually, you need them longer in memory.
How is this a limitation?
> Tuples are just for quick manipulation. Since you are interested in just the
> content inside, you should be able to manipulate it quickly. Concrete
> examples would be destructing JSON or manipulating any list. That
> manipulation itself shouldn't be something used with Switch statements or
> require multiple if let statements.
A tuple is just as valid a data structure as any. Though you may use them
less, it does not mean they exist in a different semantic space than nominal
types. I don't see why you are averse to switch and case-let. Switch allows
you all the same power as your suggestion of using functions to "squash out"
the Optionals from a tuple, and gives you diagnostics about completeness of
case handling to boot.
To your point, both of the operations you describe above are handled by
destructuring into enums with associated values, not by matching on tuple
patterns. In fact, I think the only convincing case I've seen for the absolute
need for tuple patterns is HLists , and nobody uses those anyway ;)
>
> I'm actually not a fan of the C#'s implementation of tuples. Mainly because
> they don't use optionals and the tuple implementation isn't very clean
>
> var aTuple = Tuple.Create ("foo","bar",111)
>
> The main problem is that Swift's tuples functionalities are very limited to
> be able to use them.
This is what I would like you to explain. Please expound on the current
limitations and what you wish to change. So far, all I've seen is a suggestion
for Monoidal Functors in stdlib.
>
>> On Thu, Sep 15, 2016 at 10:25 PM, Robert Widmann
>> wrote:
>> A few notes
>>
>> ~Robert Widmann
>>
>> 2016/09/16 0:54、Muhammad Tahir Vali via swift-evolution
>> のメッセージ:
>>
>>> The purpose of this proposal is to implement Tuples as a named typed in
>>> Swift. Tuples can be extremely useful for pattern matching, returning
>>> multiple values from a function, and destructing content to the list. C#
>>> has tuples as a named type as well I believe. Currently, Tuples in Swift
>>> are anonymous types that have limited functionality but this proposal can
>>> help solve that.
>>
>> Languages like C#, Scala, et al. that decided that Tuple should be a nominal
>> type have, in my opinion, made the wrong choice. A tuple is an anonymous
>> product; its content and not its name is what is important otherwise you'd
>> just use a struct.
>>
>>>
>>> The underlying implementations of this proposal can allow the following :
>>>
>>> 1) having parameters and return values of type : Tuple
>>> - enforces much more intuitive and clean code
>>> - less code too read
>>
>> This is already valid in Swift.
>>
>> func flip(_ t : (A, B)) -> (B, A) {
>> return (t.1, t.0)
>> }
>>
>>>
>>> 2) implicit & explicit optionals with tuples !!!
>>> - Can definitely take out many nested optional chains if tuples internally
>>> checks for .Some or .None in each variable stored inside of an optional of
>>> type Tuple.
>>
>> This operation will not scale well without variadic generics. Do you really
>> want ~8 different functions in stdlib that examine the contents of tuples
>> when it's much easier to just pattern match on the tuple in a `switch` or
>> `case let` statement?
>>
>>>
>>> 3) making tuples variable declarations more popular for functional call
>>> - parameter names in function calls within tuple variables can be used as
>>> getter
>>
>> This is, again, already supported.
>>
>> func project(_ t : (l : String, r : Int)) -> Int {
>> return t.r
>> }
>>
>> f(("Hello World, 42))
>>
>>>
>>> My proposal was very brief but I hope its one worth embracing. I didnt get
>>> to talk about applications but those are pretty self-explanatory. This
>>> definitely widens the vision for Swift and could be a "a-ha" thing for
>>> Swift developers. :)
>>
>> In short, I don't really see how this achieves the goal of making tuples
>> more flexible. Perhaps you have concrete examples of what is wrong and what
>> this proposal intends to fix?
>>
>>>
>>> --
>>> Best Regards,
>>>
>>> Muhammad T. Vali
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> --
> Best Regards,
>
> Muhammad T. Vali
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
