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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
