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

[Rod Brown]

Apart from your seeming distain for Swift, this proposal seems misguided to me, and to ignore some of the recent discussion around named parameters on tuples (which are currently in flux).

Each of the types you mention each have clear, specific meanings.

The following two are basic type system representations:
1. Classes - Reference, inheritance based items.
2. Structs  - Formal Value based items with storage (as opposed to enums which generally aren’t designed for storage).

The following two are collection types you’ve arbitrarily attacked for no reason. There are plenty of examples where each of these makes sense and is relevant within the language:
3. Arrays - Lists of items.
4. Dictionarys - Key value pair collections.

The final one is a separate basic type system representation:
5. Tuple. “Multiple values grouped together for a single compound value” (from Swift Programming Language Guide 3.0.1).

This type is to group related items together informally. That is, not as a wider type that is commonly used, but as an ad-hoc solution in cases where defining a type is neither required nor desirable. Say if I want to pass a return value of an item, and an associated description string for one method only, should I go and create a struct and all the boilerplate for that? This is an ad-hoc solution. That is in opposition to your example, which most definitely makes sense as a struct, and there already is one: CGPoint. Tuples themselves are actually a major part of how the language is built under the covers, and removing them for no reason is part of taking the guts out of Swift, for no reason.

I definitely agree there needs to be discussions regarding improving the situation for named parameters in tuples.

Accessing items: Each accessor is based on the one appropriate for the type. Unifying all member syntax purely for the sake of unifying it is a non-goal. We need to work out what is best for each case independently: properties vs subscripts. Rather than finding one obscure case where you used all of them and put them side by side, each should be assessed individually on their own merits.


> On 8 Jan 2017, at 1:17 pm, Freak Show via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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/20170109/db3d2a0b/attachment.html>