> On Jun 24, 2016, at 9:22 AM, Paul Cantrell via swift-evolution 
> <[email protected]> wrote:
> 
> 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/
>    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

> 
> Cheers, P
> 
> 
>> On Jun 22, 2016, at 8:07 PM, Chris Lattner via swift-evolution 
>> <[email protected]> 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
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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

Reply via email to