[swift-evolution] Partial list of open Swift 3 design topics

[Vladimir.S]

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
>> <swift-evolution at swift.org> 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, 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."

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