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

[Freak Show]

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".




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170107/41d0699e/attachment.html>