1

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:

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

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:

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

Thank you,

-Joe
Review Manager

2

  • What is your evaluation of the proposal?

I vaguely remember that this feature exists, but have never used it, so I’m in favor of removing it.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes, I’d favor simplicity in the compiler, which could enable easier implementation of new features, than having tuple splats.

  • 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?

A quick reading.

···

On Feb 5, 2016, at 10:12, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

3

I am fine with this proposal, except for having to name the parameter. The argument should be known as $0, within the function. Explanation and example…

My single use case of where this feature might have worked, actually does not. See the double parentheses:

protocol Protocol {
   typealias Arguments
   func ƒ1(parameters: Arguments) -> Arguments
   func ƒ2(parameters: Arguments)
}

struct Struct1: Protocol {
   typealias Arguments = (goodName: String, otherGoodName: String)
   func ƒ1(parameters: Arguments) -> Arguments {
      return (goodName: "", otherGoodName: "")
   }
   func ƒ2(parameters: Arguments) {}
}

let struct1 = Struct1()

// Too many parentheses are needed, but whatever.
// Not a big deal.
let struct1Arguments = struct1.ƒ1((goodName: "", otherGoodName: ""))

struct1.ƒ2(struct1Arguments)

Typealiases fall apart when I need a single parameter:

struct Struct2: Protocol {
   // Should be (goodName: String) but named 1-tuples don't work.
   typealias Arguments = String
   
   func ƒ1(parameters: Arguments) -> Arguments {return ""}
   func ƒ2(parameters: Arguments) {}
}

let struct2 = Struct2()

// No extra parentheses are needed but I don't know what the argument is.
// This is a big deal.
let struct2Arguments = struct2.ƒ1("")

struct2.ƒ2(struct2Arguments)

We need to be able to name the element of a single-item tuple, and we need to stop enforcing internal parameter names:

protocol Protocol {
   typealias Arguments
   func ƒ1(Arguments) -> Arguments
   func ƒ2(Arguments)
}

struct Struct: Protocol {
   typealias Arguments = (goodName: String)
   func ƒ1(Arguments) -> Arguments {
      return (goodName: $0.goodName)
   }
   func ƒ2(Arguments) {}
}

let `struct` = Struct()
let structArguments = `struct`.ƒ1((goodName: ""))
`struct`.ƒ2(structArguments)

4

• What is your evaluation of the proposal?

I’ve known about the tuple splat feature but have never used it in my code or seen a real need for it. Therefore, if removing can simplify the language and the compiler, I’m all for it.

• Is the problem being addressed significant enough to warrant a change to Swift?

I believe so.

• Does this proposal fit well with the feel and direction of Swift?

It does fit well with a desire to start simplifying or removing features which are rarely used.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have used other functional languages which have that functionality, but I’ve always shed away from it because it made code harder to read.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the proposal in detail and read the discussion in the mailing list, so a fairly serious study.

···

On 05 Feb 2016, at 19:12, Joe Groff via swift-evolution <swift-evolution@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

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

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

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

Thank you,

-Joe
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

+1

While I liked the idea the fact it can't be used to operate on a returned tuple directly means that it can't be used in the most interesting ways from the functional world (I raised a radar on that rdar://17356912). I also understand the danger of the implicit nature.

In most app development I haven't used the feature.

While I think a proper explicit splat operator would be nice it is definitely low priority and the specification would need some thought and the main use might be teaching functional fundamentals so I'm not sure how much real use it would get.

Joseph

···

On 5 Feb 2016, at 18:12, Joe Groff <jgroff@apple.com> 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

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

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

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

Thank you,

-Joe
Review Manager
_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

6

+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@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

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

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

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

Thank you,

-Joe
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

• What is your evaluation of the proposal?

I never use the feature and therefore wouldn't miss it. More importantly it
is confusing to both human and compiler and therefore should be removed.

• Is the problem being addressed significant enough to warrant a change to
Swift?

Yes, it causes confusion and complicates the compiler.

• Does this proposal fit well with the feel and direction of Swift?

Yes, it is a little used feature and part of the direction of Swift is to
focus on useful features and not be a collection of all possible ideas.

• If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

No experience of using the feature in either Swift or other languages.

• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

I have followed the thread on Swift Evolution.

···

On Saturday, 6 February 2016, Joe Groff via swift-evolution < swift-evolution@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

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

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

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

Thank you,

-Joe
Review Manager

--
  -- Howard.

8

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

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

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

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?

I do not use tuple splatting in Swift. Thus, if removing it will contribute to cleaning up the language and the compiler, then I support the change.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Sometimes we have to take a step backwards before taking two steps forward. We heard multiple proposals to better support the notion of tuple splatting during the debate following this proposal. However, it strikes me that none of these proposals can happen until the existing tuple splatting feature has been removed. Thus, I think it significant to progress.

  • Does this proposal fit well with the feel and direction of Swift?

Yes, for reasons I have already stated.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have never seen or used tuple splatting in any language. However, I have used array splatting in Ruby, which I found very useful on occasion.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the proposal and the debate following the proposal very carefully.

···

On Feb 5, 2016, at 1:12 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

  • What is your evaluation of the proposal?

+1. I don't quite agree that it's purely a sugar feature -- the use-case I brought up in the discussion thread involves the use of generics in combination with tuple splatting, and removing the feature would require abandoning type safety by using Any typing or writing lots and lots of duplicate code.

That said, I do think that this feature should be redesigned and replaced, and given that it's not practical to do so in time for Swift 3, and that we want to minimize backwards compatibility breaks after Swift 3, it's important to remove the existing feature now. My personal use case mentioned above is only used to facilitate testing, where type safety is less important, so dropping down to Any typing is fine as a temporary workaround.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes, for the reasons described above.

  • Does this proposal fit well with the feel and direction of Swift?

Yes.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I don't have experience with tuple splatting outside of Swift.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the entire proposal and participated in the original discussion.

Jarod

10

https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md

  • What is your evaluation of the proposal?

-1.

As I said in the preliminary discussion, I use this feature reasonably often and I think my code is better for it. I won't repeat the details here, but suffice it to say, I could work around its absence if I had to but my code would be worse for it.

I do agree that the problems described in the proposal are real, but I think the feature's value is underestimated, and I think the proposed solution maximizes migration difficulties.

I don't agree with the proposal's blithe assertion that tuple splat "is purely a sugar feature". Tuple splat allows you to write generic functions that work with a function of any arity; in fact, it allows *most* generic functions to work in this fashion, even built-in ones like `map` which are designed for unary functions. Even something so simple as a function composition operator is impossible to write without it. In short, you *can* work around its absence, but only by distorting your code and obscuring its purpose—and to a far greater extent than this proposal complains about tuple splat doing.

Finally—and perhaps most importantly, because we're setting a precedent here—the proposal seems very concerned with breaking code now rather than later. However, if the feature is removed without replacement, and then a replacement is added in a later version, that means people using this feature will have to change their code twice: once to remove implicit tuple splat, and again to adopt its eventual replacement. And if the fix-it essentially involves creating a closure to wrap the call, it seems unlikely that removing that closure can be fix-it guided, so the second change will have to be done manually.

Thus, for those using the feature, removing it in Swift 3 and re-adding it in a later version is *more* disruptive than replacing it in Swift 4 or some other future release cycle, while for those *not* using the feature, both strategies cause the same amount of disruption (none).

It's one thing to remove features we don't want to keep, like the `++` operator, or disable only-the-test-suite-will-notice corner cases due to implementation limits, like the curried super calls. It's another thing to remove features we think are a good idea, but want to redesign at some unspecified future date.

Like preemptive war, preemptive feature removal is not an action to be taken lightly. If we want to remove it and replace it, fine. If we want to remove it and *not* replace it, let's talk about that. But removing it and maybe replacing it eventually, but probably not in this release cycle, is essentially the most disruptive possible way this could be handled.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes, but I don't think the change that should be made is to simply delete the feature and defer any decisions on its replacement.

  • Does this proposal fit well with the feel and direction of Swift?

In the sense that we seem to be seeking a stronger separation between tuples and parameters, yes. In the sense that Swift attempts to make higher-order functions practical, no.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I've used languages with a variety of parameter type arrangements, and I've always found splatting very useful. I found it useful in Swift, too.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A full reading of the proposal, participation in the preliminary discussion thread, review of my codebases to look at where I had used it. I have not really looked at the implementation issues, but other than that, I think I have a pretty good understanding of this proposal.

···

--
Brent Royal-Gordon
Architechies

11

  • What is your evaluation of the proposal?

Strongly in favor of. In it's current form tuple splatting seems to be more trouble than it's worth.

Personally I've never made much use of it beyond simple experiments and it could always be reintroduced in a more fully baked form if there are compelling use cases.

  • 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?

I've read the review and followed the discussion here on the mailing list.

- Janosch

12

+1 for removing implicit tuple splat.

I think this is a rarely used feature and would fit well in the Swift 3 goal of cleaning up the type system. I believe this would also solve some ambiguities that, IMO, cannot be properly solved, e.g.

func f(x: Any) {
  print("Any")
}

func f(a: Int, _ b: Int) {
  print("Int, Int")
}

f(3,4) // Currently resolved as f(Int, Int)

let a = (3,4)
f(a) // Currently resolved as f(Int, Int)

f(a as Any) // Currently resolved as f(Any)

f((3,4)) // Currently ambigous expression

If tuple splatting is not remove, I think that there should be a consistent solution to resolving ambiguity in the example provided above (in particular I think that there shouldn’t be a difference between f(a) and f((3,4)). I already tried to solve this issue but am not going to put more effort into it until this proposal is decided.

- Alex

···

On 05 Feb 2016, at 19:12, Joe Groff <jgroff@apple.com> 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

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

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

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

Thank you,

-Joe
Review Manager
_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

13

Hello,

I use this feature to make generic "weak target actions" like this :

func weakTarget<T, S: AnyObject>(target: S, action: S -> (T -> Void)) -> (T -> Void) {
    return { [weak target] (input: T) -> Void in
        guard let target = target else { return }
        return action(target)(input)
    }
}

class Target {
    init() {}
    func printHello(firstName: String, lastName: String) {
        print("Hello \(firstName) \(lastName) !")
    }
}

class Receiver {
    init() {}
    var printSomething: ((String, String) -> Void)? = nil
}

var aTarget: Target? = Target()
let aReceiver = Receiver()

aReceiver.printSomething = weakTarget(aTarget!, action: Target.sayHello)

aReceiver.printSomething?("Jérôme", "Alves") // => "Hello Jérôme Alves !"

a = nil

aReceiver.printSomething?("Jérôme", "Alves") // => aReceiver.printSomething still has a value, but it does nothing

As you can see, if you call weakFunc() with a func which has multiple arguments, the T generic will be a tuple and I guess this is thanks to this "implicit tuple splat" feature but I'm not sure.
So can someone enlighten me ? Will this code continue to work if this proposal is approved ?

···

Le 5 févr. 2016 à 19:12, Joe Groff via swift-evolution <swift-evolution@swift.org> a écrit :

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

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

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

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

Thank you,

-Joe
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

14

I am fine with this proposal, except for having to name the parameter. The argument should be known as $0, within the function. Explanation and example…

Hi Jessy,

I don’t understand what you’re referring to here. The proposal is about removing a feature, not changing existing functionality or adding new things. If you’d like to propose a language change, please do so on a new thread.

-Chris

···

On Feb 5, 2016, at 11:15 AM, Jessy Catterwaul via swift-evolution <swift-evolution@swift.org> wrote:

My single use case of where this feature might have worked, actually does not. See the double parentheses:

protocol Protocol {
   typealias Arguments
   func ƒ1(parameters: Arguments) -> Arguments
   func ƒ2(parameters: Arguments)
}

struct Struct1: Protocol {
   typealias Arguments = (goodName: String, otherGoodName: String)
   func ƒ1(parameters: Arguments) -> Arguments {
      return (goodName: "", otherGoodName: "")
   }
   func ƒ2(parameters: Arguments) {}
}

let struct1 = Struct1()

// Too many parentheses are needed, but whatever.
// Not a big deal.
let struct1Arguments = struct1.ƒ1((goodName: "", otherGoodName: ""))

struct1.ƒ2(struct1Arguments)

Typealiases fall apart when I need a single parameter:

struct Struct2: Protocol {
   // Should be (goodName: String) but named 1-tuples don't work.
   typealias Arguments = String
   
   func ƒ1(parameters: Arguments) -> Arguments {return ""}
   func ƒ2(parameters: Arguments) {}
}

let struct2 = Struct2()

// No extra parentheses are needed but I don't know what the argument is.
// This is a big deal.
let struct2Arguments = struct2.ƒ1("")

struct2.ƒ2(struct2Arguments)

We need to be able to name the element of a single-item tuple, and we need to stop enforcing internal parameter names:

protocol Protocol {
   typealias Arguments
   func ƒ1(Arguments) -> Arguments
   func ƒ2(Arguments)
}

struct Struct: Protocol {
   typealias Arguments = (goodName: String)
   func ƒ1(Arguments) -> Arguments {
      return (goodName: $0.goodName)
   }
   func ƒ2(Arguments) {}
}

let `struct` = Struct()
let structArguments = `struct`.ƒ1((goodName: ""))
`struct`.ƒ2(structArguments)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

15

I am sorry for taking up your time. To be more concise:

Associated types as argument lists were my only intended usage of this feature. Because the feature does not work for that case, I evaluate this proposal to be magnificent. It will end some confusion.

···

On Feb 5, 2016, at 2:31 PM, Chris Lattner <clattner@apple.com> wrote:

On Feb 5, 2016, at 11:15 AM, Jessy Catterwaul via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I am fine with this proposal, except for having to name the parameter. The argument should be known as $0, within the function. Explanation and example…

Hi Jessy,

I don’t understand what you’re referring to here. The proposal is about removing a feature, not changing existing functionality or adding new things. If you’d like to propose a language change, please do so on a new thread.

-Chris

My single use case of where this feature might have worked, actually does not. See the double parentheses:

protocol Protocol {
   typealias Arguments
   func ƒ1(parameters: Arguments) -> Arguments
   func ƒ2(parameters: Arguments)
}

struct Struct1: Protocol {
   typealias Arguments = (goodName: String, otherGoodName: String)
   func ƒ1(parameters: Arguments) -> Arguments {
      return (goodName: "", otherGoodName: "")
   }
   func ƒ2(parameters: Arguments) {}
}

let struct1 = Struct1()

// Too many parentheses are needed, but whatever.
// Not a big deal.
let struct1Arguments = struct1.ƒ1((goodName: "", otherGoodName: ""))

struct1.ƒ2(struct1Arguments)

Typealiases fall apart when I need a single parameter:

struct Struct2: Protocol {
   // Should be (goodName: String) but named 1-tuples don't work.
   typealias Arguments = String
   
   func ƒ1(parameters: Arguments) -> Arguments {return ""}
   func ƒ2(parameters: Arguments) {}
}

let struct2 = Struct2()

// No extra parentheses are needed but I don't know what the argument is.
// This is a big deal.
let struct2Arguments = struct2.ƒ1("")

struct2.ƒ2(struct2Arguments)

We need to be able to name the element of a single-item tuple, and we need to stop enforcing internal parameter names:

protocol Protocol {
   typealias Arguments
   func ƒ1(Arguments) -> Arguments
   func ƒ2(Arguments)
}

struct Struct: Protocol {
   typealias Arguments = (goodName: String)
   func ƒ1(Arguments) -> Arguments {
      return (goodName: $0.goodName)
   }
   func ƒ2(Arguments) {}
}

let `struct` = Struct()
let structArguments = `struct`.ƒ1((goodName: ""))
`struct`.ƒ2(structArguments)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

16

Hi Joe,

I'm sorry to bring up the "common point of confusion", but I'd like a
little more clarification to help me review :). Your example of valid
syntax is this:

func f2<T>(a : T) -> T { ... }let x = (1, 2)
f2(x)

It gets a little more complicated when generic closures are involved. I am
wondering which aspects of this (if any) will still valid:

func call<T,U>(value: T, apply: T->U) -> U {

    return apply(value)

}

func call2<T,U>(apply: T->U) -> (T -> U) {

    return { apply($0) }

}

func test(a: Int, b: Int, c: Int) -> (Int, Int) {

    return (a + b, b + c)

}

let a = call((1, 2, 3), apply: test)

let b = call2(test)(1, 2, 3)

By my interpretation apply uses "pass an entire argument list as a single
value", so it would be invalid. However I don't think it has the same
syntactic ambiguity that you talked about in your proposal.

*If it is invalid:*

   - Should the compiler only allow (T->U) to be a function from a single
   value?
   - Should a change to closure type signatures be more explicit in the
   proposal?
   - You mention a foo(*x) style solution, this would probably also require
   T* equivalent. Is this something that you view as inevitable, do you
   think it will be considered within the Swift4 timeframe?

I don't believe a compiler fixit could resolve this without duplicating call
and call2 for different arities, that only works if they are in a module
under the user's control.

A more common example can be seen in:
/swift/stdlib/internal/SwiftExperimental/SwiftExperimental.swift

The function composition operator "(f ∘ g)(1,2,3)".

*Preliminary review:*

In general I'm in favour, it seems like a necessary fix. I can see it being
a potential for confusion in most cases. I think it's unclear how many
flow-on effects there may be, and perhaps the impact is underestimated.

However it would be a shame to lose useful function composition utilities,
I believe it is only potentially confusing for the few people writing those
utilities, not for the many people using them.

Thanks,
Andrew

···

On Sat, Feb 6, 2016 at 8:31 AM, Joseph Lord via swift-evolution < swift-evolution@swift.org> wrote:

+1

While I liked the idea the fact it can't be used to operate on a returned
tuple directly means that it can't be used in the most interesting ways
from the functional world (I raised a radar on that rdar://17356912). I
also understand the danger of the implicit nature.

In most app development I haven't used the feature.

While I think a proper explicit splat operator would be nice it is
definitely low priority and the specification would need some thought and
the main use might be teaching functional fundamentals so I'm not sure how
much real use it would get.

Joseph

On 5 Feb 2016, at 18:12, Joe Groff <jgroff@apple.com> 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

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

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

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

Thank you,

-Joe
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

17

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@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@swift.org <mailto:swift-evolution@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

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

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

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

Thank you,

-Joe
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

18

Hi plx,

Please take a look at my proposal:
    http://comments.gmane.org/gmane.comp.lang.swift.evolution/5334

It introduces tuple operators capable of doing many of the things you
suggest.

In case you missed it, you can currently do unlabel/relabel like this:

    let m = (a: 1, b: 2) as (Int,Int) as (c: Int, d: Int)

It's just not as concise.

···

On Sun, Feb 7, 2016 at 1:01 AM, plx via swift-evolution < swift-evolution@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@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

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

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

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

Thank you,

-Joe
Review Manager
_______________________________________________
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

19

• What is your evaluation of the proposal?
+1
• Is the problem being addressed significant enough to warrant a change to
Swift?
Yes. Though I am in favor of thinking about functions as maps from tuple to
tuple, the current behavior has too many nuanced wrinkles.
• Does this proposal fit well with the feel and direction of Swift?
Yes
• If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?
errr… yes?
• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
I have followed the discussion, commented previously, and have both used
and explained the behavior being changed.

···

On Sun, Feb 7, 2016 at 11:23 AM, Patrick Gili via swift-evolution < swift-evolution@swift.org> wrote:

On Feb 5, 2016, at 1:12 PM, Joe Groff via swift-evolution < > swift-evolution@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

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

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

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?

I do not use tuple splatting in Swift. Thus, if removing it will
contribute to cleaning up the language and the compiler, then I support the
change.

• Is the problem being addressed significant enough to warrant a change to
Swift?

Sometimes we have to take a step backwards before taking two steps
forward. We heard multiple proposals to better support the notion of tuple
splatting during the debate following this proposal. However, it strikes me
that none of these proposals can happen until the existing tuple splatting
feature has been removed. Thus, I think it significant to progress.

• Does this proposal fit well with the feel and direction of Swift?

Yes, for reasons I have already stated.

• If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?

I have never seen or used tuple splatting in any language. However, I have
used array splatting in Ruby, which I found very useful on occasion.

• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

I read the proposal and the debate following the proposal very carefully.

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe
Review Manager
_______________________________________________
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

20

-0.5, I agree with Andrew Bennett and Brent Roayal-Gordon.

I use this functionality a lot, which means I've had to experience and
navigate around the inconsistencies and bugs of the current implementation,
but removing this functionality all together would leave us with a
significantly less capable/expressive language.

IMHO this (albeit buggy) aspect of the language is what allows one of its
key must-have-features, namely being able to work with generic higher order
functions in an (almost) acceptable way.

Suddenly loosing the ability to write and use higher order generic
functions (eg generic function composition, generic function application,
without having to special-case for every arity etc) would severely bloat my
code and decrease my productivity.

I was delighted to see Swift resurfacing these simple yet powerful and,
really, basic tools of programming. Now I'm not sure what to expect. I fear
that I will have to seriously consider moving back to using C++ templates :
( or perhaps resort to always use only a single tuple parameter, like eg
this:
func f(args: (T, T)) -> T { ... }
instead of this:
func f(a: T, b: T) -> T { ... }
How else would I be able to do simple stuff like composing them etc?

/Jens

···

On Tue, Feb 9, 2016 at 10:13 AM, Jerome ALVES via swift-evolution < swift-evolution@swift.org> wrote:

Hello,

I use this feature to make generic "weak target actions" like this :

func weakTarget<T, S: AnyObject>(target: S, action: S -> (T -> Void)) ->
(T -> Void) {
    return { [weak target] (input: T) -> Void in
        guard let target = target else { return }
        return action(target)(input)
    }
}

class Target {
    init() {}
    func printHello(firstName: String, lastName: String) {
        print("Hello \(firstName) \(lastName) !")
    }
}

class Receiver {
    init() {}
    var printSomething: ((String, String) -> Void)? = nil
}

var aTarget: Target? = Target()
let aReceiver = Receiver()

aReceiver.printSomething = weakTarget(aTarget!, action: Target.sayHello)

aReceiver.printSomething?("Jérôme", "Alves") // => "Hello Jérôme Alves !"

a = nil

aReceiver.printSomething?("Jérôme", "Alves") //
=> aReceiver.printSomething still has a value, but it does nothing

As you can see, if you call weakFunc() with a func which has multiple
arguments, the T generic will be a tuple and I guess this is thanks to this
"implicit tuple splat" feature but I'm not sure.
So can someone enlighten me ? Will this code continue to work if this
proposal is approved ?

Le 5 févr. 2016 à 19:12, Joe Groff via swift-evolution < > swift-evolution@swift.org> a écrit :

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

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

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

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

Thank you,

-Joe
Review Manager
_______________________________________________
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

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden

Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com