[swift-evolution] [Review] SE-0029 Remove implicit tuple splat behavior from function applications

[Craig Cruden]

I agree with you that tuples theoretically (not sure about practicality)  should be part of something broader (though I have not thought too deeply about it).  

A tuple is not much different than just a heterogeneous list of typed values (immutable).  

A label in a certain way could be seen as another type of some sort - a column header of sorts.  

The same things that you can do on lists should really be available at tuples.  You should be able to append values - which returns a new immutable heterogenous list of the similar types.  

Filter out values, flatten the list, map values from one list to another (including ability to transform labels).  

I do not see them as a function signature, but a collection type.  

> On 2016-02-06, at 21:01:43, plx via swift-evolution <swift-evolution at swift.org> wrote:
> 
> +1.
> 
> I’m in the camp of people who would want an explicit version of this to make an eventual return, ideally as part of a broader suite of "tuple-manipulation operations”.
> 
> In such a proposal I’d hope to see, for example, splatting, but also compiler-assistance for things like:
> 
> - tuple-concatenation: (a,b)##(c,d) => (a,b,c,d)
> - tuple-flattening: (a,(b,(c,d))#flatten => (a,b,c,d)
> - tuple-rearrange: (a,b,c,d)#rearrange(($2,$1),($4,$3)) => ((b,a),(d,c))
> - tuple-relabel: (a,b,c,d)#relabel(foo:,bar:,baz:,qux:) => (foo: a, bar: b, baz: c, qux: d)
> - tuple-unlabel: (foo: a, bar: b, baz: c, qux: d)#unlabel => (a,b,c,d)
> 
> …with the above as examples of the kinds of operations, and not really the syntax; whatever’s chosen, it ought to be possible — although perhaps not *advisable* — to write e.g.:
> 
> // plz use a dedicated “zip4" in real life:
> for (a,b,c,d) in zip(zip(as,bs),zip(cs,ds)).lazy.map(#flatten) { … }
> 
> …but that’s enough about tuple operations for now, I just wanted to illustrate some of the operations that be supported. 
> 
> Moving on, as I’m in favor of the proposal as it stands, I don’t have anything to contribute to the proposal itself.
> 
> That said, I *do* think it’s unwise to infer too much from low rates of use for implicit tuple splatting at this time; it seems a little unfair to treat  “this feature doesn’t work" and "no one seems to be using it” as *independent* variables, here.
> 
> As one such example, I implemented a large amount of a largely-declarative, combinator-ish “JSON parsing” library that would’ve made heavy use of tuple-splatting *if* it actually worked, but as splatting wound up seeming troublesome I gave up trying to use splatting. 
> 
> FWIW not having splatting doesn’t change the size of the *library* code very much, but makes each site-of-use substantially-larger.
> 
>> On Feb 5, 2016, at 12:12 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of “Remove implicit tuple splat behavior from function applications” begins now and runs through February 9, 2016. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md <https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md>
>> 
>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
>> 
>> Proposal link:
>> 
>> http://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md <http://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md>
>> 
>> Reply text
>> 
>> Other replies
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>> 
>> 	• What is your evaluation of the proposal?
>> 	• Is the problem being addressed significant enough to warrant a change to Swift?
>> 	• Does this proposal fit well with the feel and direction of Swift?
>> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
>> 
>> Thank you,
>> 
>> -Joe
>> Review Manager
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20160206/83613a91/attachment.html>