Way back when, there was an unresolved discussion was about whether it’s
a bug or a feature that $0 sometimes captures a single arg and sometimes
captures all args as a tuple:
Just recently I started a new thread for that subject : "[Discussion] func/closure parameters and tuples" but no replies for it yet. Was planing to start the proposal thread.
I believe we should add consistency in Swift regarding allowed arguments of closure/func.
Dropped questions regarding this here:
So I'll repeat questions/issues here in one place:
1. I was not expecting this will compile :
let ft1 : (Int,Int) -> Void = { x in print(x.0, x.1)}
ft1(1, 2)
the type of ft1 is definitely not the same as closure
2. The same. But this crashes compiler at compile time(bug is reported) :
let ft2 : (Int,Int) -> Void = { x in print(x) }
ft2(1, 2)
3. Was expecting closure will require a single argument, which is tuple; but it accepts even just x, y
typealias IntInt = (Int,Int)
func foo(block: (IntInt) -> Void) {
let z : IntInt = (1,2)
block(z)
}
foo { x in print(x)} // ok
foo { x, y in print(x,y)}
foo { (x, y) in print(x, y)}
I'm not sending two values to closure, I send one instance which is tuple.
4.
typealias BinaryIntOp_v1 = (Int, Int) -> Int
typealias BinaryIntOp_v2 = ((Int, Int)) -> Int
print(BinaryIntOp_v2.self) // Prints ((Int, Int)) -> Int why?
print(BinaryIntOp_v2.self) // Prints ((Int, Int)) -> Int
let areRepresentingTheSameType = BinaryIntOp_v1.self == BinaryIntOp_v2.self // (alt-click the "==" and read doc.)
print(areRepresentingTheSameType) // Prints true
let add_v1: BinaryIntOp_v1 = (+)
let add_v2: BinaryIntOp_v2 = (+) // Or both could have been eg: { return $0 + $1 }
let ra = add_v1(1, 2)
let rb = add_v2((1, 2)) // NOTE: Needs these extra parens (otherwise error: "Extra argument in call")
let rc = (add_v1 as BinaryIntOp_v2)((1, 2)) // NOTE: I am type casting these to an identical type ...
let rd = (add_v2 as BinaryIntOp_v1)(1, 2) // ... in order to swap which one of them need extra parens ...
···
On 24.06.2016 19:22, Paul Cantrell via swift-evolution wrote:
http://thread.gmane.org/gmane.comp.lang.swift.evolution/3915/
[SR-586] $0 captures all closure argument as single tuple when no larger-numbed $N used · Issue #43203 · apple/swift · GitHub
I mention this because it would be a breaking change to make $0
consistently capture the first arg, and I wonder whether that should be
in the Swift 3?
(If anybody wants to comment on the question, I recommend catching up on
the discussion in the links above first.)
Cheers, P
On Jun 22, 2016, at 8:07 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote:
Hi everyone,
Here is a partial list of the open topics that the core team would
like to get resolved in Swift 3. The list is partial both because I’m
way behind on swift-evolution traffic, but also because new things may
come up. There are also a number of accepted proposals that are not
yet implemented. Some topics have proposals done, and therefore have
an SE number, but the review discussion hasn’t finalized. Some of
these topics have an “owner” that is driving or planning to start a
discussion on them them, which I’ve listed in square brackets.
If you’d like to discuss these topics in particular, please start a
new thread specific to them, or contribute to an already-existing
thread discussing it. Several of these don’t have an owner yet, so if
you’d like to pick them up and run with them, that would be great.
Thanks!
-Chris
Language: - SE-0091: Improving operator requirements in protocols
[Core team discussed this, will email about it shortly] - SE-0077:
Improve operator declaration syntax [Core team discussed this, Joe
Groff will follow up on this soon] - SE-0095: Replace protocol<P1,P2>
syntax with P1 & P2 syntax - SE-0102: Remove @noreturn attribute and
introduce an empty NoReturn type - SE-0103: Invert @noescape - Remove
T -> T? implicit promotion for operands to operators - Removing
argument labels from the type system (so they are declaration-only
constructs) - Some reshuffling with requiring @objc/@nonobjc for
things that shouldn’t/can’t be expressed via the Objective-C runtime -
Eliminating inference of associated type witnesses (as is mentioned in
the generics manifesto) - Should public classes be
non-publicly-subclassable by default? [John McCall] - Revising access
modifiers on extensions [Adrian Zubarev]
Standard library: - SE-0101: Rename sizeof and related functions to
comply with API Guidelines - Ongoing API naming adjustments for
stdlib: - Closure arguments [Dave Abrahams] - Others are being
discussed on swift-evolution. - Remove Boolean protocol. - SE-0104:
Revise Integer protocols to match FP ones. [Max Moiseev]
SDK / Cocoa / ObjC interop: - [SE-0086] Finalize NS removal plan.
[Tony Parker] - Importing “id” as Any [Joe Groff] - Revise
NSError/Error model for better interoperability and usability. [Doug
Gregor] - <rdar://15821981> Bridge NSRange to “Range<Int>?”
_______________________________________________ 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
