At the moment I’m only considering the zero-cardinality tuple and don’t want to address the implicit destructuring issues. Therefore you are right with foo(fnA) and foo(fnB); but foo(fnC) won’t compile.
My goal is to add small propositions with simple rules to have better compatilibty and a more natural way to approach the code. This could be addressed by another proposition (not on this topic) — very short reply expected - vsre.info Jérémie Girault On 12 juin 2017 at 19:03:51, Jens Persson ([email protected]) wrote: I have just had a quick look but I'm interested in what you think about the following example, which currently behaves like the comments say: func foo<A>(_ fn: (A) -> Void) {} func fnA() {} func fnB(_ a: Int) {} func fnC(_ a: Int, _ b: Int) {} foo(fnA) // Compiles in Swift 3, error in Swift 4 foo(fnB) // Compiles in both Swift 3 and Swift 4 foo(fnC) // Compiles in Swift 3, error in Swift 4 From what I read in your proposal, I assume that you want foo(fnA) to compile in both. But if so, don't you think foo(fnC) should also compile in both? /Jens On Mon, Jun 12, 2017 at 10:48 AM, Jérémie Girault via swift-evolution < [email protected]> wrote: > Hi here, > > As I tested swift4 in xcode9b1 I noticed a lot of regressions about tuples > usage. > > After documenting myself about the changes which happened, I thought that > they could be improved. Instead of fighting these propositions (which make > sense), I wanted create a few proposal which would improve these recent > changes with a few simple rules. > > My propositions are based on the recent decisions and in the continuation > of SE-0110. The first one is about Void. > Void is historically defined as the type of the empty tuple. The reason of > this is that arguments were initially considered as tuple. If this is no > more the case, then it’s no more a reason to keep Void as an empty tuple. > > I think that by having a few rules around tuples of cardinality 0 and 1 > and also arguments list, we could greatly improve source compatibility and > keep a lot of what makes swift great when using functional style and > generics. > > I drafted a proposal that would allow more source compatibility and type > consistency and would enjoy discussing it with you, in order to improve it > : > > https://github.com/jeremiegirault/swift-evolution/blob/master/ > proposals/NNNN-flatten-void.md > > Let me know what you think about it, > > — > very short reply expected - vsre.info > Jérémie Girault > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
