[swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

[Robert Widmann]

Some simple questions:

Say Tuples are deprecated and removed from the language: 

How would you go about pattern matching on multiple values in the same switch statement?  

What about pattern bindings for multiple values?

When a function that takes more than one argument in a particular parameter list is partially applied, how will I apply the needed tuple of arguments to complete the call later?

There is a lot of overlap if you view them simply as data structures, but there is also a lot the language itself does with them that has to be worked out if they're going to be replaced.

~Robert Widmann

2017/01/07 19:17、Freak Show via swift-evolution <swift-evolution at swift.org> のメッセージ:

> FWIW, I searched the previous proposals for any kind of mention of tuple and found nothing so forgive me if this has been discussed before.  
> 
> Swift currently has 5 ways to represent multi-values.
> 
> Classes, structs, arrays, dictionaries, and tuples.
> 
> Of these, classes are well established and unique in that they support inheritance and often have identity.  
> 
> The others, however, are primarily used as value types in their immutable incarnations.  Consider a desire to pass around a cartesian coordinate.  The following representations are available:
> 
> let x = "x"
> let y = "y"
> 
> struct XY { var x: Int; var y: Int }
> 
> var txy = (x: 1, y: 2)       // (.0 1,.1 2)
> var sxy = XY(x: 1, y: 2 )    // XY
> var dxy = [ x: 1, y: 2]  // ["y": 2, "x": 1]
> var axy = [ 1, 2 ] // [1,2]
> var taxy = ( 1, 2 ) // (.0 1,.1 2)
> 
> Their print strings are in the comment to the right - that could be a source of a whole other proposal. 
> 
> A developer might choose from any one of these to represent a Point.  They all represent the same information.  Yet the syntax required to make use of them is annoyingly different.
> 
> Consider the tuple with named fields which is being used as a sort of anonymous ad hoc struct:
> 
> txy.x // 1
> txy.0 // 1
> txy[x] // error
> txy[0] // error
> 
> vs the declared struct
> 
> sxy.x
> sxy.0  //error
> sxy[x]  //error
> sxy[0]  //error
> 
> vs the dictionary
> 
> dxy.x // error
> dxy.0 // error
> dxy[x] // 1
> dxy[0] // error
> 
> and then we have the tuple with unnamed fields
> 
> taxy.0 // 1
> taxy[0] // error
> 
> vs the array
> axy.0  // error
> axy[0] // 1
> 
> It is worth observing that, to the programmer the variable sxy is indistinguishable from txy.  They represent the same informtion, they are accessed in the exactly the same way.  They are completely equivalent.  However this fails:
> 
> sxy = txy // error
> 
> this succeeds (which may or may not be good depending on context and coincidence):
> 
> var txy = (x: 1, y: 2)
> var txy2 = ( x: 2, y: 3)
> txy = txy2 // OK
> 
> but this fails (which I think is a good thing)
> 
> struct XY { var x: Int; var y: Int }
> struct XY2 { var x: Int; var y: Int }
> 
> var sxy2 = XY2(x: 2, y: 3)
> var sxy = XY(x: 1, y: 2 )
> 
> sxy=sxy2 // error
> 
> The point of this comparison is to point out that the anonymous type generating tuple is a) superfluous and b) a source of confusion and gratuitous complexity.  It assumes the role at times of immutable arrays, anonymous structs, and immutable dictionaries depending on context and we already have all of those things.  
> 
> Proposal:
> 
> 1) Eliminate the tuple as a first level concept.
> 2) Replace tuples that have named fields with structs or immutable dictionaries.
> 3) Replace tuples without named fields with immutable arrays.
> 4) Disallow tuple expressions that mix named and unnamed fields - IOW - this is an abomination:
> 
> var mixed = (z: 1, 2)
> 
> If nothing else in this proposal resonates at all - that should be adopted.
> 
> 5) Unify field access syntax.  Pick one or allow both on everything (similar to javascript).
> 
> FWIW, this isn't hard to do already in Objective C.  It is possible to make use of default handlers to allow dict.field access on NSDictionary with a very small amount of code.  Javascript also supports both dictionary oriented access (obj['field']) and dot notation (obj.field) so there is precedent for this kind of flexibility.  
> 
> 6) Unify iteration over all the fields of all the kinds of things that have fields.  In this case, tuples are kind of like sequenced collections that have been lobotomized.  
> 
> Conclusion
> 
> There is a lot of overlap among the concepts of structs, immutable dictionaries, immutable arrays and tuples.  They are a source of gratuitous complexity in the language and a likely ongoing source of frustration as developers choose different, equivalent, but incompatible representations for common types of data.  My primary fear is that anonymous tuples will tend to phase out named struct types and an important source of documentation of intent will be lost.
> 
> It should also be noted that I am not a compiler or VM writer and I don't give a fig how the language does things at the implementation level and this is primarily a conceptual/syntactic proposal.  The goal is to make consuming data types predictable and simple and eliminate gratuitous complexity at the conceptual level through generalization of special cases.
> 
> Thanks for reading.  Still reading the process document to figure out how to make this "official".
> 
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170108/0279ce82/attachment.html>