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

[Wallacy]

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 at 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<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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/9d73eb26/attachment.html>