# Partial list of open Swift 3 design topics **URL:** \ **Category:** Discussion\ **Created:** [June 23, 2016, 1:07am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094 "2016-06-23T01:07:56Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [June 23, 2016, 1:07am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/1 "2016-06-23T01:07:56Z")
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\ 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] - \ Bridge NSRange to “Range\?” ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 23, 2016, 1:16am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/2 "2016-06-23T01:16:13Z")
> 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\ 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. ^^^ What's the thinking behind this particular item? > **···** > > On Wed, Jun 22, 2016 at 8:07 PM, Chris Lattner via swift-evolution \< swift-evolution@swift.org\> wrote: > > > - 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] > > - \ Bridge NSRange to “Range\?” > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![hartbit](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hartbit/32/738_2.png) [@hartbit](https://forums.swift.org/u/hartbit)\ **Post date:** [June 23, 2016, 6:48am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/3 "2016-06-23T06:48:53Z")
> - \ Bridge NSRange to “Range\?” I don’t think I can handle writing a proposal for this one, but I’d die for it. ---
**Author:** ![Paul\_Cantrell](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/paul_cantrell/32/16764_2.png) [@Paul\_Cantrell](https://forums.swift.org/u/Paul_Cantrell)\ **Post date:** [June 24, 2016, 4:22pm UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/4 "2016-06-24T16:22:12Z")
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:     [http://thread.gmane.org/gmane.comp.lang.swift.evolution/3915/](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](https://bugs.swift.org/browse/SR-586) 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 \ 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\ 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] > > - \ Bridge NSRange to “Range\?” > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Austin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/austin/32/1196_2.png) [@Austin](https://forums.swift.org/u/Austin)\ **Post date:** [June 25, 2016, 6:30am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/5 "2016-06-25T06:30:18Z")
Would you be willing to elaborate a bit on "Removing argument labels from the type system"? The bulk of this went away when tuple splatting was removed, and values of function type already seem to ignore the labels of the functions they are assigned. Best, Austin > **···** > > > On Jun 22, 2016, at 6:07 PM, Chris Lattner via swift-evolution \ 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\ 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] > > - \ Bridge NSRange to “Range\?” > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Wallacy](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/wallacy/32/1097_2.png) [@Wallacy](https://forums.swift.org/u/Wallacy)\ **Post date:** [June 28, 2016, 2:36pm UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/6 "2016-06-28T14:36:35Z")
And something about Property Behaviors? It's a very good proposal, and can solve many problems cited in other proposals in this list. > **···** > > Em qua, 22 de jun de 2016 às 22:08, Chris Lattner via swift-evolution \< swift-evolution@swift.org\> escreveu: > > > 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\ 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] > > - \ Bridge NSRange to “Range\?” > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Austin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/austin/32/1196_2.png) [@Austin](https://forums.swift.org/u/Austin)\ **Post date:** [June 23, 2016, 1:30am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/7 "2016-06-23T01:30:25Z")
I'd be happy to put together proposals for associated type inference removal and removing type system significance from argument labels, if nobody else wants them. Austin > **···** > > On Wed, Jun 22, 2016 at 6:16 PM, Xiaodi Wu via swift-evolution \< swift-evolution@swift.org\> wrote: > > > On Wed, 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\ 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. > > > > ^^^ > > What's the thinking behind this particular item? > > > > > - 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] > > > - \ Bridge NSRange to “Range\?” > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [June 23, 2016, 2:45am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/8 "2016-06-23T02:45:53Z")
“Boolean” isn’t pulling its weight: - It only abstracts over Bool and ObjCBool. - It only enables a few operations on ObjCBool, which are not very important. - ObjCBool is a bridging problem, and we don’t handle bridging by introducing common protocols (e.g. in the case of String vs NSString, we don’t introduce a common “Stringable” protocol. Further, it complicates the model: - People are confused by it and the similar but very different Bool type. - Bool is a simple enough concept to not need a family of protocols. > **···** > > On Jun 22, 2016, at 6:16 PM, Xiaodi Wu \ wrote: > > > - Remove Boolean protocol. > > ^^^ > > What's the thinking behind this particular item? ---
**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\ **Post date:** [June 23, 2016, 2:48am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/9 "2016-06-23T02:48:26Z")
> - Bool is a simple enough concept to not need a family of protocols. Literally, the most fundamental concept. ---
**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\ **Post date:** [June 24, 2016, 4:57pm UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/10 "2016-06-24T16:57:08Z")
> 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: > > > | | | > |------------------|-----------------|… > |Previous ID | SR-1334 | > |Radar | None | > |Original Reporter | VladimirS (JIRA User) | > |Type | Bug | > > \ > \Additional Detail from JIRA\ > > | | | > |------------------|-----------------| > |Votes | 0 | > |Component/s | | > |Labels | Bug | > |Assignee | None | > |Priority | Medium | > > > > md5: e9e08c67a6041aa28a44745bd5d0ebfc > > \ > > > > > > \*\*Issue Description:\*\* > > > I wanted to ask if founded by me strange behaviour of compiler/parser is bug or it is 'feature' and 'by design' : > (Swift version 3.0-dev (LLVM b010debd0e, Clang 3e4d01d89b, Swift 7182c58cb2)) > (IBM Swift Sandbox) > > 1\\. I was not expecting this will compile : > > \`\`\` none > 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 generates error in runtime : > > \`\`\` none > let ft2 : (Int,Int) -\> Void = { x in print(x)} > ft2(1, 2) > \`\`\` > > 3\\. Could you describe why this compile, as types of closures are not the same > > \`\`\` none > func z1(block: (Int,Int) -\> Void) { > block(1,2) > } > > z1 { x, y in print(x,y)} > z1 { x in print(x.0, x.1)} > z1 { (x, y) in print(x, y)} > > func z2(block: ((Int,Int)) -\> Void) { > block((1,2)) > } > > z2 { x, y in print(x,y)} > z2 { x in print(x.0, x.1)} > z2 { (x, y) in print(x, y)} > //z2 { ((x, y)) in print(x, y)} // compilation error ??? > \`\`\` > > Thank you for your description and comments. > > > | | | > |------------------|-----------------|… > |Previous ID | SR-1854 | > |Radar | None | > |Original Reporter | VladimirS (JIRA User) | > |Type | Bug | > |Status | Closed | > |Resolution | Cannot Reproduce | > > \ > \Environment\ > > IBM Swift Sandbox > Swift Ver. 3.0 (Jun 6, 2016) > Target: x86\_64-ubuntu-linux-gnu > > > \ > > \ > \Additional Detail from JIRA\ > > | | | > |------------------|-----------------| > |Votes | 0 | > |Component/s | Compiler | > |Labels | Bug, CompilerCrash | > |Assignee | None | > |Priority | Medium | > > > > md5: ceeff5fc884b27df509c065f88320a3b > > \ > > > > > \*\*relates to\*\*: > \* \[SR-1896\](https://bugs.swift.org/browse/SR-1896) crash when compile > > > \*\*Issue Description:\*\* > > > This code crashes the compiler, as I understand from the output: > > \`\`\` none > let ft2 : (Int,Int) -\> Void = { x in print(x) } > > ft2(1, 2) > \`\`\` > > Unhandled conversion from exploded tuple > UNREACHABLE executed at /home/buildnode/jenkins/workspace/oss-swift-package-linux-ubuntu-15\_10/swift/lib/SILGen/SILGenPoly.cpp:879! > 0 swift 0x00000000032ecf28 llvm::sys::PrintStackTrace(llvm::raw\_ostream&) + 40 > 1 swift 0x00000000032eb726 llvm::sys::RunSignalHandlers() + 54 > 2 swift 0x00000000032eda56 > 3 libpthread.so.0 0x00007fb389be7d10 > 4 libc.so.6 0x00007fb38852f1c7 gsignal + 55 > 5 libc.so.6 0x00007fb388530e2a abort + 362 > 6 swift 0x000000000329b92d llvm::llvm\_unreachable\_internal(char const\*, char const\*, unsigned int) + 461 > 7 swift 0x00000000009b6aad > 8 swift 0x00000000009bf6f5 > 9 swift 0x00000000009b2b63 > 10 swift 0x00000000009b245c > 11 swift 0x000000000098b0ff > 12 swift 0x000000000097fd1d > 13 swift 0x000000000096feb9 > 14 swift 0x000000000096ff9d > 15 swift 0x00000000009349fe > 16 swift 0x00000000009352fb > 17 swift 0x0000000000936002 swift::SILModule::constructSIL(swift::ModuleDecl\*, swift::SILOptions&, swift::FileUnit\*, llvm::Optional\, bool, bool) + 482 > 18 swift 0x0000000000936596 swift::performSILGeneration(swift::FileUnit&, swift::SILOptions&, llvm::Optional\, bool) + 118 > 19 swift 0x00000000007d973f > 20 swift 0x00000000007d578e swift::performFrontend(llvm::ArrayRef\, char const\*, void\*, swift::FrontendObserver\*) + 2830 > 21 swift 0x00000000007a277b main + 2603 > 22 libc.so.6 0x00007fb38851aac0 \_\_libc\_start\_main + 240 > 23 swift 0x00000000007a02f9 \_start + 41 > Stack dump: > 0. Program arguments: /usr/bin/swift -frontend -c -primary-file /swift-execution/Sources/main.swift -target x86\_64-unknown-linux-gnu -disable-objc-interop -I /swift-execution/.build/debug -enable-testing -g -module-cache-path /swift-execution/.build/debug/ModuleCache -D SWIFT\_PACKAGE -emit-module-doc-path /swift-execution/.build/debug/TempCode.build/main~partial.swiftdoc -Onone -module-name TempCode -emit-module-path /swift-execution/.build/debug/TempCode.build/main~partial.swiftmodule -emit-dependencies-path /swift-execution/.build/debug/TempCode.build/main.d -emit-reference-dependencies-path /swift-execution/.build/debug/TempCode.build/main.swiftdeps -num-threads 8 -o /swift-execution/.build/debug/TempCode.build/main.swift.o > 1. While emitting reabstraction thunk in SIL function @\_TTRXFo\_iP\_\_\_XFo\_dSidSi\_\_\:0: error: unable to execute command: Aborted > \:0: error: compile command failed due to signal (use -v to see invocation) 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/](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](https://bugs.swift.org/browse/SR-586) > > > > 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 \>\> \ 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\ > > > 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] - \ Bridge NSRange to “Range\?” > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ swift-evolution > > > mailing list swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ swift-evolution mailing > > list swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Russ\_Bishop1](https://avatars.discourse-cdn.com/v4/letter/r/ccd318/32.png) [@Russ\_Bishop1](https://forums.swift.org/u/Russ_Bishop1)\ **Post date:** [June 26, 2016, 10:57pm UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/11 "2016-06-26T22:57:47Z")
Will this work the way people expect, especially given how NSString handles unicode vs Swift String and the various views? My suspicion is at least a chunk of the things people imagine doing with the bridged NSRange won’t actually work and they’ll be sad. Russ > **···** > > > On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution \ wrote: > > > > > - \ Bridge NSRange to “Range\?” > > > > I don’t think I can handle writing a proposal for this one, but I’d die for it. > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [June 27, 2016, 8:36pm UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/12 "2016-06-27T20:36:53Z")
This came from a short list of topics Doug provided me, but the basic issue is that: func f(a : Int, b : Int) {   let x = f // x has type (a: Int, b: Int) -\> () } I’m not exactly sure what the counterproposal is. -Chris > **···** > > > On Jun 24, 2016, at 11:30 PM, Austin Zheng \ wrote: > > > > Would you be willing to elaborate a bit on "Removing argument labels from the type system"? The bulk of this went away when tuple splatting was removed, and values of function type already seem to ignore the labels of the functions they are assigned. ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [June 28, 2016, 3:55pm UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/13 "2016-06-28T15:55:32Z")
> 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: > >    [http://thread.gmane.org/gmane.comp.lang.swift.evolution/3915/](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](https://bugs.swift.org/browse/SR-586) > > 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.) I consider this a bug. The removal of implicit tuple splats should, IMO, encompass making $0 consistently capture the first argument. I’d love for this to happen in Swift 3.   - Doug > **···** > > > On Jun 24, 2016, at 9:22 AM, Paul Cantrell via swift-evolution \ wrote: > > > Cheers, P > > > > > On Jun 22, 2016, at 8:07 PM, Chris Lattner via swift-evolution \ 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\ 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] > > > - \ Bridge NSRange to “Range\?” > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [June 29, 2016, 3:40am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/14 "2016-06-29T03:40:10Z")
I’m also looking forward to property behaviors, but there is a ton of open design work left to be done. They are clearly post-swift-3.0 at this point. -Chris > **···** > > > On Jun 28, 2016, at 7:36 AM, Wallacy \ wrote: > > > > And something about Property Behaviors? It's a very good proposal, and can solve many problems cited in other proposals in this list. ---
**Author:** ![Charlie\_Monroe1](https://avatars.discourse-cdn.com/v4/letter/c/d6d6ee/32.png) [@Charlie\_Monroe1](https://forums.swift.org/u/Charlie_Monroe1)\ **Post date:** [June 28, 2016, 5:04am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/15 "2016-06-28T05:04:11Z")
> This came from a short list of topics Doug provided me, but the basic issue is that: > > func f(a : Int, b : Int) { > let x = f // x has type (a: Int, b: Int) -\> () > } > > I’m not exactly sure what the counterproposal is. My guess is to require let x = f(a:,b:) (specifying arguments)? > **···** > > > -Chris > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\ **Post date:** [June 28, 2016, 5:11am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/16 "2016-06-28T05:11:54Z")
This is a good point. I asked @CC Tony Parker recently about doing the conversion inside Foundation and just exposing Range\ directly. Basically everybody who uses those Foundation methods which return an NSRange for strings needs to write their own conversion functions anyway, and less-experienced developers might not get the UTF-16 thing correct. That’s something we should be handling for them; it’s an implementation detail of the underlying CoreFoundation APIs. Karl > **···** > > > On 27 Jun 2016, at 00:57, Russ Bishop via swift-evolution \ wrote: > > > > > On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution \ wrote: > > > > > > > - \ Bridge NSRange to “Range\?” > > > > > > I don’t think I can handle writing a proposal for this one, but I’d die for it. > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > Will this work the way people expect, especially given how NSString handles unicode vs Swift String and the various views? My suspicion is at least a chunk of the things people imagine doing with the bridged NSRange won’t actually work and they’ll be sad. > > > > Russ > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [June 28, 2016, 4:29pm UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/17 "2016-06-28T16:29:39Z")
I’ll try to elaborate on the issues: 1) NSRange could be mapped to Range\. This would involve executing bridging code (much like we do for String \<-\> NSString or Bool \<-\> BOOL), because NSRange’s location + length representation is different from Range’s lowerBound/upperBound. 2) Some NSRanges use location == NSNotFound to indicate “no value”. We would want to bridge these NSRanges to a Range\?, where we location == NSNotFound maps to nil. We cannot guess whether the range treats NSNotFound as special from the API: we’ll need some kind of annotation (e.g., via some kind of Objective-C attribute) that indicates that we should be mapping to an optional value as well as how to identify the nil value. That attribute would then have to be applied to popular APIs. 3) When the NSRange is describing indices into a String, we’d need some kind of Objective-C attribute to say that these are indices and (possibly?) point to which NSString\* they reference (although the latter is not strictly necessary in the new collection indexing model), so that NSRange can be mapped to Range\ or Range\? (so it needs to compose with #2). That attribute would then have to be applied to popular APIs. 4) Similar to #3, we should do the same thing for NSIntegers that represent locations in a String, so those NSIntegers can get mapped to String.Index. There are likely conventions that would map to String.Index? as well, so this also calls for a generalization of #2. That attribute would then have to be applied to popular APIs.. Although this is on my personal list of things that would be great to clean up for Cocoa, it doesn’t seem feasible for Swift 3 to get it designed, implemented, and rolled out to enough APIs .   - Doug > **···** > > > On Jun 26, 2016, at 3:57 PM, Russ Bishop via swift-evolution \ wrote: > > > > > On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution \ wrote: > > > > > > > - \ Bridge NSRange to “Range\?” > > > > > > I don’t think I can handle writing a proposal for this one, but I’d die for it. > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > Will this work the way people expect, especially given how NSString handles unicode vs Swift String and the various views? My suspicion is at least a chunk of the things people imagine doing with the bridged NSRange won’t actually work and they’ll be sad. ---
**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\ **Post date:** [June 28, 2016, 4:42pm UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/18 "2016-06-28T16:42:16Z")
> > 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: > > > > [http://thread.gmane.org/gmane.comp.lang.swift.evolution/3915/](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](https://bugs.swift.org/browse/SR-586) > > > > 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.) > > I consider this a bug. The removal of implicit tuple splats should, IMO, > encompass making $0 consistently capture the first argument. I’d love > for this to happen in Swift 3. Doug, could you please comment this related thread in mailing list: "[Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency." > **···** > > On 28.06.2016 18:55, Douglas Gregor via swift-evolution wrote: > > > > On Jun 24, 2016, at 9:22 AM, Paul Cantrell via swift-evolution \>\> \ wrote: > > > - Doug > > > > > Cheers, P > > > > > > > On Jun 22, 2016, at 8:07 PM, Chris Lattner via swift-evolution \>\>\> \ 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\ 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] - \ Bridge NSRange to “Range\?” > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ swift-evolution > > > > mailing list swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ swift-evolution > > > mailing list swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ swift-evolution mailing > > list swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Austin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/austin/32/1196_2.png) [@Austin](https://forums.swift.org/u/Austin)\ **Post date:** [June 28, 2016, 5:06am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/19 "2016-06-28T05:06:56Z")
I think the point is to get rid of the argument labels. 'x' should be typed simply (Int, Int) -\> (). That being said, right now the argument labels in the type don't seem to actually affect anything, so like Chris I'm not sure what the counter-proposal is. (cc. Doug) Best, Austin > **···** > > > On Jun 27, 2016, at 10:04 PM, Charlie Monroe \ wrote: > > > > > This came from a short list of topics Doug provided me, but the basic issue is that: > > > > > > func f(a : Int, b : Int) { > > > let x = f // x has type (a: Int, b: Int) -\> () > > > } > > > > > > I’m not exactly sure what the counterproposal is. > > > > My guess is to require let x = f(a:,b:) (specifying arguments)? > > > > > -Chris > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Charlie\_Monroe1](https://avatars.discourse-cdn.com/v4/letter/c/d6d6ee/32.png) [@Charlie\_Monroe1](https://forums.swift.org/u/Charlie_Monroe1)\ **Post date:** [June 28, 2016, 5:40am UTC](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094/20 "2016-06-28T05:40:59Z")
Oh, I see. The issue is then the following: let x = f x(1, 2) // Error: Missing argument labels 'a:b:' in call let y: (Int, Int) -\> () = f f(1, 2) // OK Which requires you to write x(a: 1, b: 2). I must admit, however, that I always liked this behavior... > **···** > > > On Jun 28, 2016, at 7:06 AM, Austin Zheng \ wrote: > > > > I think the point is to get rid of the argument labels. 'x' should be typed simply (Int, Int) -\> (). > > > > That being said, right now the argument labels in the type don't seem to actually affect anything, so like Chris I'm not sure what the counter-proposal is. > > > > (cc. Doug) > > > > Best, > > Austin > > > > > On Jun 27, 2016, at 10:04 PM, Charlie Monroe \ wrote: > > > > > > > This came from a short list of topics Doug provided me, but the basic issue is that: > > > > > > > > func f(a : Int, b : Int) { > > > > let x = f // x has type (a: Int, b: Int) -\> () > > > > } > > > > > > > > I’m not exactly sure what the counterproposal is. > > > > > > My guess is to require let x = f(a:,b:) (specifying arguments)? > > > > > > > -Chris > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) [Next page](https://forums.swift.org/t/partial-list-of-open-swift-3-design-topics/3094.md?page=2)