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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
