Re: [swift-evolution] [proposal] Allow function argument type to be omitted when passing a default value from which it can be inferred

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On May 10, 2016, at 8:33 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On May 10, 2016, at 3:02 AM, Sam Dods via swift-evolution 
>>  wrote:
>> I propose that function argument types could be omitted in the same way as 
>> variable and property argument types are omitted when they are set at point 
>> of definition.
>> 
>> At present the type of properties and variables can be inferred as below:
>> 
>> class EvolutionManager {
>> let proposalManager = ProposalManager()   // type is inferred
>> 
>> func proposeTopic(topic: String) {
>>   let evolution = Evolution(topic: topic) // type is inferred
>>   proposalManager.proposeEvolution(evolution)
>> }
>> }
>> 
>> However, function arguments cannot be inferred, as below:
>> 
>> class EvolutionManager {
>> func proposeEvolution(evolution: Evolution, proposalManager = 
>> ProposalManager()) {   // compiler error, cannot infer type
> 
> We have a pretty strict rule here: types are allowed to be inferred in 
> implementations, but not interfaces.  This is important for efficient 
> compilation, encourages people to think about their API interfaces, and 
> somewhat reduces the damage when they don’t.

We broke this rule when we started allowing properties at type and module scope 
to have inferred types. I was moderately opposed to it at the time, but we have 
it, we're going to keep it, and this suggestion for inferring parameter types 
from default arguments seems to fit in the same category. 

That said, I have implementation concerns: we don't want the expression type 
checker to be involved when figuring out the type of a generic function, so we 
would need to define this in a way that doesn't affect the computation of 
generic signatures for a function. Probably, such types just aren't involved in 
inferring generic constraints. 

  - Doug

> 
> ___
> 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

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Douglas Gregor via swift-evolution]

> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> I think actual keyword “where” provides enough of a delimiter that it won’t 
> be hard to put something before it, and it seems unlikely to me that we would 
> want to add anything after it without some other delimiter. So I’m not too 
> concerned.

Yeah, that’s my feeling as well.

- Doug

> 
> Jordan
> 
>> On May 10, 2016, at 14:29, Hooman Mehr via swift-evolution 
>> > wrote:
>> 
>> Although handy for now, I am a bit concerned about moving `where` clause to 
>> the end of declaration. This reserves and occupies this wide open space at 
>> the end of declarations. I think we might find a better use for this space 
>> later as the language evolves. Any thoughts?
>> 
>>> On May 10, 2016, at 11:51 AM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0081: Move where clause to end of declaration" begins now 
>>> and runs through May 16. The proposal is available here:
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md
>>>  
>>> 
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager.
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and contribute to the direction of Swift. 
>>> When writing your review, here are some questions you might want to answer 
>>> in your review:
>>> 
>>> * What is your evaluation of the proposal?
>>> * Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>> * Does this proposal fit well with the feel and direction of Swift?
>>> * If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>>> * How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>> 
>>> More information about the Swift evolution process is available at
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>> 
>>> Thank you,
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> 
>>> ___
>>> 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 
>> 
> ___
> 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

Re: [swift-evolution] NSRange and Range

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On May 10, 2016, at 12:14 AM, David Hart  wrote:
> 
> But it’s reasonably implementable? I guess the answer is yes if you have 
> already faced the same bridging concerns with NSArray/Array. I’de really like 
> this going forward, but I don’t know how confident I am in writing a proposal.

Yes, it's implementable. We do something similar to turn Darwin's BOOL into 
Swift's Bool even though they are representationally different. 

  - Doug

> 
>> On 10 May 2016, at 08:29, Douglas Gregor  wrote:
>> 
>> 
>>> On May 9, 2016, at 11:23 PM, David Hart  wrote:
>>> 
>>> Why wouldn't it completely eliminate NSRange?
>> 
>> Because NSRange has a different representation than Range (start+length 
>> vs. start/end), a pointer-to-NSRange has to come in as 
>> Unsafe(Mutable)Pointer rather than 
>> Unsafe(Mutable)Pointer. It’s the same reason that (e.g.), an 
>> NSArray** parameter comes in as UnsafeMutablePointer rather than 
>> UnsafeMutablePointer<[AnyObject]>.
>> 
>>> Are you thinking of NSNotFound? Could we migrate those APIs to return an 
>>> Optional Range?
>> 
>> If you had annotations on the APIs to say that they use NSNotFound as a 
>> sentinel, yes.
>> 
>>- Doug
>> 
>>> 
 On 10 May 2016, at 05:49, Douglas Gregor  wrote:
 
 
> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution 
>  wrote:
> 
> Hello Swift-Evolution,
> 
> I spent some time coding on Linux with Swift 3 (latest developement 
> snapshot) and corelibs-foundation and I’ve hit one major hurdle: passing 
> and converting NSRange and Range around between the different stdlib and 
> Foundation APIs - specifically in regards to String.
> 
> Is there a plan to simplify those pain points by converting all 
> corelibs-foundation APIs to accept/return Range on String instead of 
> NSRange? In that case, can’t we get rid of NSRange completely?
 
 
 One idea that had come up before was to bridge NSRange to Range, 
 although it wouldn’t completely eliminate NSRange because the two types 
 are not representationally identical.
 
 - Doug
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] NSRange and Range

[Douglas Gregor via swift-evolution]

> On May 9, 2016, at 11:23 PM, David Hart  wrote:
> 
> Why wouldn't it completely eliminate NSRange?

Because NSRange has a different representation than Range (start+length 
vs. start/end), a pointer-to-NSRange has to come in as 
Unsafe(Mutable)Pointer rather than Unsafe(Mutable)Pointer. 
It’s the same reason that (e.g.), an NSArray** parameter comes in as 
UnsafeMutablePointer rather than UnsafeMutablePointer<[AnyObject]>.

> Are you thinking of NSNotFound? Could we migrate those APIs to return an 
> Optional Range?

If you had annotations on the APIs to say that they use NSNotFound as a 
sentinel, yes.

- Doug

> 
>> On 10 May 2016, at 05:49, Douglas Gregor  wrote:
>> 
>> 
>>> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift-Evolution,
>>> 
>>> I spent some time coding on Linux with Swift 3 (latest developement 
>>> snapshot) and corelibs-foundation and I’ve hit one major hurdle: passing 
>>> and converting NSRange and Range around between the different stdlib and 
>>> Foundation APIs - specifically in regards to String.
>>> 
>>> Is there a plan to simplify those pain points by converting all 
>>> corelibs-foundation APIs to accept/return Range on String instead of 
>>> NSRange? In that case, can’t we get rid of NSRange completely?
>> 
>> 
>> One idea that had come up before was to bridge NSRange to Range, 
>> although it wouldn’t completely eliminate NSRange because the two types are 
>> not representationally identical.
>> 
>>   - Doug
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Move where clause to end of declaration

[Douglas Gregor via swift-evolution]

> On May 2, 2016, at 12:16 AM, David Hart via swift-evolution 
>  wrote:
> 
> Hello swift-evolution,
> 
> I took the pitch originally from Developer to move the where clause out of 
> the generic parameter list, with improvements brought up by Pyry Jahkola, and 
> wrote a proposal for it. I opened a Pull Request, but if anybody wants to 
> bring some modifications to it before it is merged, please let me know what 
> you think:
> 
> Move where clause to end of declaration
> 
> Proposal: SE- 
> 
> Author(s): David Hart , Developer, Pry Jahkola 
> 
> Status: TBD
> Review manager: TBD
>  
> Introduction
> 
> This proposal suggests moving the where clause to the end of the declaration 
> syntax, but before the body, for readability reasons. It has been discussed 
> at length on the following swift-evolution thread:
> 
> [Pitch] Moving where Clauses Out Of Parameter Lists 
> 
>  
> Motivation
> 
> The where clause in declarations can become quite long. When that happens, it 
> breaks the declaration syntax in two, hurting its readability. There is also 
> no good way of formatting the declaration syntax to make it much better.
> 
>  
> Proposed
>  solution
> 
> The proposal suggests moving the where clause at the end of the declaration, 
> but before the body of concerned declarations. With the proposed change, 
> where clauses do not impede the main declaration and are also more easily 
> formattable. For example, here is the same function declaration before and 
> after the change: 
> 
> func anyCommonElements T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element>(lhs: T, _ rhs: U) -> Bool 
> where
> {
> ...
> }
> 
> func anyCommonElements(lhs: T, _ rhs: U) 
> -> Bool where
> T.Generator.Element: Equatable,
> T.Generator.Element == U.Generator.Element
> {
> …
Random minor comment: I find that putting the “where” at the end makes this 
almost unreadable, and would very much have preferred

> func anyCommonElements(lhs: T, _ rhs: U) 
> -> Bool
> where T.Generator.Element: Equatable, T.Generator.Element == 
> U.Generator.Element


- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] NSRange and Range

[Douglas Gregor via swift-evolution]

> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution 
>  wrote:
> 
> Hello Swift-Evolution,
> 
> I spent some time coding on Linux with Swift 3 (latest developement snapshot) 
> and corelibs-foundation and I’ve hit one major hurdle: passing and converting 
> NSRange and Range around between the different stdlib and Foundation APIs - 
> specifically in regards to String.
> 
> Is there a plan to simplify those pain points by converting all 
> corelibs-foundation APIs to accept/return Range on String instead of NSRange? 
> In that case, can’t we get rid of NSRange completely?


One idea that had come up before was to bridge NSRange to Range, although 
it wouldn’t completely eliminate NSRange because the two types are not 
representationally identical.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0086 "Drop NS Prefix in Swift Foundation" begins now and runs 
through May 16, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md
Reply text

Other replies
 
What
 goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

-Doug Gregor

Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0066: Standardize function type argument syntax to require parentheses

[Douglas Gregor via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md

Hello Swift community,

The review of SE-0066 “Standardize function type argument syntax to require 
parentheses” ran from April 25...May 2, 2016. The proposal is accepted for 
Swift 3.

There was a significant amount of feedback on the proposal, with a fairly 
common theme of “lukewarm acceptance.” A number of community members were sad 
to see this familiar syntactic shortcut go away, but acknowledge that it fits 
well with recent directions, e.g., the elimination of the implicit tuple splat 
behavior (SE-0029 
).
 The core team acknowledges that the ability to elide parentheses is not 
actively harmful to the language, but felt that it was better to have 
consistency around function types (always have parentheses) than provide a 
relatively small syntactic shortcut for higher-order functions. The core team 
did not feel that this proposal needed to include required parentheses within 
closures, which have their own fairly specific grammar.

- Doug, Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On May 2, 2016, at 3:50 PM, David Hart  wrote:
> 
> Hi Doug,
> 
> In the latest version of the proposal, which is now linked to a pull request, 
> I mentioned in the Detail Design section that the following syntax be valid:
> 
> protocol R : Q where AssocType : P {
>   // …
> }
> 
> Can you read through that part of the proposal and let me know if it is 
> descriptive enough?

I think you need to clarify the intended name lookup semantics. Does name 
lookup for "AssocType" start its lookup in R or in Q? If the former, can one 
refer to an associated type newly defined in R?

  - Doug


> 
> David.
> 
>>> On 26 Apr 2016, at 05:28, Douglas Gregor  wrote:
>>> 
>>> 
>>> On Apr 24, 2016, at 1:34 PM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> I wrote the proposal which was discussed to introduce generic constraints 
>>> for associated types. I’d like to get some feedback on it and get it ready 
>>> before submitting it:
>>> 
>>> More Powerful Constraints for Associated Types
>>> Proposal: SE-
>>> Author(s): David Hart
>>> Status: TBD
>>> Review manager: TBD
>>> Introduction
>>> 
>>> This proposal seeks to introduce a where expression to associated types 
>>> declarations to bring the same expressive power as generic type constraints.
>>> 
>>> This proposal was discussed on the Swift Evolution list in the 
>>> [swift-evolution] [Completing Generics] Arbitrary requirements in protocols 
>>> thread.
>>> 
>> Believe it or not, I support this direction…
>> 
>>> Motivation
>>> 
>>> Currently, associated type declarations can only express simple inheritance 
>>> constraints and not the more sophisticated constraints available to generic 
>>> types with the where expression. Some designs, including many in the 
>>> Standard Library, require more powerful constraints for associated types to 
>>> be truly elegant. For example, the SequenceType protocol can be declared as 
>>> follows:
>>> 
>>> protocol Sequence {
>>> associatedtype Iterator : IteratorProtocol
>>> associatedtype SubSequence : Sequence where 
>>> SubSequence.Iterator.Element == Iterator.Element
>>> ...
>>> }
>>> Detail Design
>>> 
>>> With this proposal, the grammar for protocols associated types would be 
>>> modified to:
>>> 
>>> protocol-associated-type-declaration → attributesopt 
>>> access-level-modifieropt associatedtype typealias-name 
>>> ­type-inheritance-clause­opt­ typealias-assignment­opt requirement-clauseopt
>>> 
>>> The new requirement-clause is then used by the compiler to validate the 
>>> associated types of conforming types.
>>> 
>> The only thing that bothers me about this syntax is that I have to introduce 
>> an associated type to add requirements. For example, what if I want my 
>> inheriting protocol to add a requirement to an existing associated type?
>> 
>> protocol P { }
>> 
>> protocol Q {
>>   typealias AssocType
>> }
>> 
>> protocol R : Q {
>>   // I want to just add “AssocType : P”, but I have to redeclare AssocType 
>> to do so
>>   typealias AssocType where AssocType : P
>> }
>> 
>> Did you consider an alternate syntax that puts the where clause outside the 
>> braces, e.g.,
>> 
>> protocol R : Q where AssocType : P {
>>   // …
>> }
>> 
>> There are two things I like about this. First, it breaks the unnecessary 
>> link between an associated type and a (possibly unrelated) where clause, 
>> eliminating the need to redeclare associated types in inheriting protocols. 
>> Second, it’s effectively the same syntax as constrained extensions, which 
>> have a similar feel.
>> 
>> Note that, if we do the above, I’d love to make it an error to define a new 
>> associated type with the same name as an associated type in an inherited 
>> protocol. It’s odd that we do so, and IIRC the only use case for it is to 
>> add requirement to an “existing” associated type.
>> 
>>  - Doug
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Manifesto] Completing Generics

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On May 2, 2016, at 3:58 PM, David Hart <da...@hartbit.com> wrote:
> 
> I’d like to continue moving Completing Generics forward for Swift 3 with 
> proposals. Can Douglas, or someone from the core team, tell me if the topics 
> mentioned in Removing unnecessary restrictions require proposals or if bug 
> reports should be opened for them instead?

I'd classify everything in that section as a bug, so long as we're restricting 
ourselves to the syntax already present in the language. Syntactic improvements 
(e.g., for same-type-to-concrete constraints) would require a proposal. 

  - Doug


> 
>> On 03 Mar 2016, at 02:22, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hi all,
>> 
>> Introduction
>> 
>> The “Complete Generics” goal for Swift 3 has been fairly ill-defined thus 
>> fair, with just this short blurb in the list of goals:
>> 
>> Complete generics: Generics are used pervasively in a number of Swift 
>> libraries, especially the standard library. However, there are a number of 
>> generics features the standard library requires to fully realize its vision, 
>> including recursive protocol constraints, the ability to make a constrained 
>> extension conform to a new protocol (i.e., an array of Equatable elements is 
>> Equatable), and so on. Swift 3.0 should provide those generics features 
>> needed by the standard library, because they affect the standard library's 
>> ABI.
>> This message expands upon the notion of “completing generics”. It is not a 
>> plan for Swift 3, nor an official core team communication, but it collects 
>> the results of numerous discussions among the core team and Swift 
>> developers, both of the compiler and the standard library. I hope to achieve 
>> several things:
>> 
>> Communicate a vision for Swift generics, building on the original generics 
>> design document, so we have something concrete and comprehensive to discuss.
>> Establish some terminology that the Swift developers have been using for 
>> these features, so our discussions can be more productive (“oh, you’re 
>> proposing what we refer to as ‘conditional conformances’; go look over at 
>> this thread”).
>> Engage more of the community in discussions of specific generics features, 
>> so we can coalesce around designs for public review. And maybe even get some 
>> of them implemented.
>> 
>> A message like this can easily turn into a centithread. To separate concerns 
>> in our discussion, I ask that replies to this specific thread be limited to 
>> discussions of the vision as a whole: how the pieces fit together, what 
>> pieces are missing, whether this is the right long-term vision for Swift, 
>> and so on. For discussions of specific language features, e.g., to work out 
>> the syntax and semantics of conditional conformances or discuss the 
>> implementation in compiler or use in the standard library, please start a 
>> new thread based on the feature names I’m using.
>> 
>> This message covers a lot of ground; I’ve attempted a rough categorization 
>> of the various features, and kept the descriptions brief to limit the 
>> overall length. Most of these aren’t my ideas, and any syntax I’m providing 
>> is simply a way to express these ideas in code and is subject to change. Not 
>> all of these features will happen, either soon or ever, but they are 
>> intended to be a fairly complete whole that should mesh together. I’ve put a 
>> * next to features that I think are important in the nearer term vs. being 
>> interesting “some day”. Mostly, the *’s reflect features that will have a 
>> significant impact on the Swift standard library’s design and implementation.
>> 
>> Enough with the disclaimers; it’s time to talk features.
>> 
>> Removing unnecessary restrictions
>> 
>> There are a number of restrictions to the use of generics that fall out of 
>> the implementation in the Swift compiler. Removal of these restrictions is a 
>> matter of implementation only; one need not introduce new syntax or 
>> semantics to realize them. I’m listing them for two reasons: first, it’s an 
>> acknowledgment that these features are intended to exist in the model we 
>> have today, and, second, we’d love help with the implementation of these 
>> features.
>> 
>> 
>> *Recursive protocol constraints
>> 
>> Currently, an associated type cannot be required to conform to its enclosing 
>> protocol (or any protocol that inherits that protocol). For example, in the 
>> standard library SubSeque

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

[Douglas Gregor via swift-evolution]

> On Apr 28, 2016, at 10:15 AM, Brad Hilton via swift-evolution 
>  wrote:
> 
> Type nesting allows some convenient and straightforward semantics that we see 
> inside the Swift standard library such as views on String like 
> String.CharacterView, String.UnicodeScalarView, etc. However a protocol 
> cannot be nested in a type and gives a non-obvious error that the 
> “Declaration is only valid at file scope.” Just as other nested types allow 
> proper contextual scoping, a nested protocol could make a lot sense for a 
> number of patterns. For example, there are many “Delegate” protocols 
> throughout the Cocoa frameworks. Here’s a controller/delegate pattern before 
> and after type nesting:
> 
> // Without type nesting
> 
> protocol MyControllerDelegate : class {
> 
> }
> 
> class MyController {
> 
> weak var delegate: MyControllerDelegate?
> 
> }
> 
> // With type nesting
> 
> class MyController {
> 
> weak var delegate: Delegate?
> 
> protocol Delegate : class {
> 
> }
> 
> }
> 
> Though the change is mostly semantics, it does allow an explicit association 
> between My Controller and the Delegate instead of only a named association. 
> It also cleans up the module name space like other nested types and makes 
> associated protocols more discoverable in my opinion. 
> 
> I’d love to hear everyone’s thoughts.

Note that this cannot work when any enclosing type is generic, e.g.,

class MyController {
  protocol Delegate {
// I’ve just created a parameterized protocol!
  }
}

Otherwise, I don’t see any issues with the proposal, and I like that it 
eliminates a large number of top-level names.

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Douglas Gregor via swift-evolution]

> On Apr 27, 2016, at 12:45 PM, L. Mihalkovic  
> wrote:
> 
> Inline
> 
> Regards
> (From mobile)
> 
> On Apr 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution 
> > wrote:
> 
>> On Apr 27, 2016, at 12:25 PM, Douglas Gregor > > wrote:
>>> 
>>> On Apr 27, 2016, at 10:10 AM, Erica Sadun >> > wrote:
 
 From the Swift Programming Language: Methods on a subclass that override 
 the superclass’s implementation are marked with override—overriding a 
 method by accident, without override, is detected by the compiler as an 
 error. The compiler also detects methods with override that don’t actually 
 override any method in the superclass.
 
 I would like to extend this cautious approach to protocols, forcing the 
 developer to deliberately override an implementation that’s inherited from 
 a protocol extension. This would prevent accidental overrides and force 
 the user to proactively choose to implement a version of a protocol member 
 that already exists in the protocol extension.
 
 I envision this as using the same `override` keyword that’s used in class 
 based inheritance but extend it to protocol inheritance:
 
 protocol A {
 func foo()
 }
 
 extension A {
 func foo() { .. default implementation … }
 }
 
 type B: A {
 
 override required func foo () { … overrides implementation … }
 }
>>> 
>>> A couple questions about your pitch:
>>> 
>>> 1) What is “required” doing there? 
>> 
>> I threw it in not because I’m tied to it but because I wanted it to be part 
>> of the conversation.
>> This is a requirement from conforming to the protocol.
>> 
>>> 2) Is “override” only required when there is a default implementation of 
>>> the protocol requirement, or is it required whenever you are implementing a 
>>> protocol requirement?
>> 
>> Override is only because it is overriding the default implementation of the 
>> protocol requirement. Without that default implementation there would be no 
>> override, it would simply be satisfying the requirement.
>> 
>>> * If the former, it might be the case that it’s too easy to forget to 
>>> add the “override” keyword (because it’s needed for some implementations of 
>>> protocol requirements but not others), which undercuts the value of having 
>>> it.
>> 
>> Forcing the override keyword makes it clear at the definition point that the 
>> story extends beyond the method or whatever to point to a default 
>> implementation that is being replaced. I *really* like having that reference 
>> in terms of both code construction (“I am doing this as a deliberate act”) 
>> with the compiler complaining otherwise, and in terms of code self 
>> documentation (“I know this was added deliberately, what default did it 
>> override?”)
>> 
>>> * If the latter, “override” is probably the wrong keyword because it’s 
>>> not overriding anything in the common case of implementing a non-defaulted 
>>> requirement.
>> 
>> It would be pointless if it’s just satisfying a requirement. That’s why  
>> introduced both keywords into the discussion. (And because I’m still being 
>> influenced by the “near miss” conversation.)
>> 
> 
> One could always argue that should protocol definitions ever be allowed to 
> contain default implementations ala-java default methods,

I fully expect this will happen someday. It would have happened when protocol 
extensions were introduced except that the implementation was a bit more 
involved than we had time for.


> the distinction between former and latter would go away, and it would be 
> happy anticipation to have mandated *override* all along in all cases, 
> ensuring that future default methods would not accidentally take precedence 
> of current code or wind up being treated differently than other overrides.

Please spell out the scenario you are talking about.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Douglas Gregor via swift-evolution]

> On Apr 27, 2016, at 12:31 PM, Erica Sadun  wrote:
> 
> On Apr 27, 2016, at 12:25 PM, Douglas Gregor  > wrote:
>> 
>> On Apr 27, 2016, at 10:10 AM, Erica Sadun > > wrote:
>>> 
>>> From the Swift Programming Language: Methods on a subclass that override 
>>> the superclass’s implementation are marked with override—overriding a 
>>> method by accident, without override, is detected by the compiler as an 
>>> error. The compiler also detects methods with override that don’t actually 
>>> override any method in the superclass.
>>> 
>>> I would like to extend this cautious approach to protocols, forcing the 
>>> developer to deliberately override an implementation that’s inherited from 
>>> a protocol extension. This would prevent accidental overrides and force the 
>>> user to proactively choose to implement a version of a protocol member that 
>>> already exists in the protocol extension.
>>> 
>>> I envision this as using the same `override` keyword that’s used in class 
>>> based inheritance but extend it to protocol inheritance:
>>> 
>>> protocol A {
>>> func foo()
>>> }
>>> 
>>> extension A {
>>> func foo() { .. default implementation … }
>>> }
>>> 
>>> type B: A {
>>> 
>>> override required func foo () { … overrides implementation … }
>>> }
>> 
>> A couple questions about your pitch:
>> 
>> 1) What is “required” doing there? 
> 
> I threw it in not because I’m tied to it but because I wanted it to be part 
> of the conversation.
> This is a requirement from conforming to the protocol.

Ah. Note that this isn’t *quite* the meaning of “required” for initializers of 
classes (where it means “my subclasses must override this”), but in practice 
it’s basically the only reason why anyone uses “required” for initializers.

> 
>> 2) Is “override” only required when there is a default implementation of the 
>> protocol requirement, or is it required whenever you are implementing a 
>> protocol requirement?
> 
> Override is only because it is overriding the default implementation of the 
> protocol requirement. Without that default implementation there would be no 
> override, it would simply be satisfying the requirement.

For me, this doesn’t provide additional value of “required”: i.e., the value of 
having a keyword here is in telling me that I failed to implement a requirement 
when I’ve clearly said that I wanted to implement a requirement. Whether there 
was a default there or not isn’t really very interesting. Plus, a default could 
be added later to a requirement that I implement: that change has zero impact 
on how my code works (before or after), but now I’d be require to add an 
“override” keyword when I recompile.

Contrast that with classes: if you recompile against a new version of a library 
and the compiler tells you that you need to add “override”, it’s serious 
because the semantics of your program will change if you’re now overriding 
something that you weren’t before.

> 
>>  * If the former, it might be the case that it’s too easy to forget to 
>> add the “override” keyword (because it’s needed for some implementations of 
>> protocol requirements but not others), which undercuts the value of having 
>> it.
> 
> Forcing the override keyword makes it clear at the definition point that the 
> story extends beyond the method or whatever to point to a default 
> implementation that is being replaced. I *really* like having that reference 
> in terms of both code construction (“I am doing this as a deliberate act”) 
> with the compiler complaining otherwise, and in terms of code self 
> documentation (“I know this was added deliberately, what default did it 
> override?”)

I see the former (“I am doing this as a deliberate act”)  as a very common 
complaint; the latter not nearly as much. What motivates that? And does it 
justify adding a *second* keyword to these declarations?

>> I’d also like to bring up two related topics, although they probably should 
>> at some point move to their own thread if they have any legs:
>>> 
>>> Related topic 1: How should a consumer handle a situation where two 
>>> unrelated protocols both require the same member and offer different 
>>> default implementations. Can they specify which implementation to accept or 
>>> somehow run both? 
>>> 
>>> type B: A, C {
>>> override required func foo() { A.foo(); C.foo() }
>>> }
>> 
>> I think the right answer here is for the compiler to produce an ambiguity if 
>> you don’t implement the requirement yourself, and then solving your “related 
>> topic 2” lets you choose which implementation you want.
> 
> How do you choose which one? What syntax? For example:
> 
> required func foo = A.foo
> 
> would be the simplest approach

type B: A, C {
  override required func foo() { A.foo(self)() }
}

> 
>> 
>>> Related topic 2: How can a consumer “inherit” the behavior of the default 
>>> 

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Douglas Gregor via swift-evolution]

> On Apr 27, 2016, at 10:10 AM, Erica Sadun  wrote:
> 
> From the Swift Programming Language: Methods on a subclass that override the 
> superclass’s implementation are marked with override—overriding a method by 
> accident, without override, is detected by the compiler as an error. The 
> compiler also detects methods with override that don’t actually override any 
> method in the superclass.
> 
> I would like to extend this cautious approach to protocols, forcing the 
> developer to deliberately override an implementation that’s inherited from a 
> protocol extension. This would prevent accidental overrides and force the 
> user to proactively choose to implement a version of a protocol member that 
> already exists in the protocol extension.
> 
> I envision this as using the same `override` keyword that’s used in class 
> based inheritance but extend it to protocol inheritance:
> 
> protocol A {
> func foo()
> }
> 
> extension A {
> func foo() { .. default implementation … }
> }
> 
> type B: A {
> 
> override required func foo () { … overrides implementation … }
> }

A couple questions about your pitch:

1) What is “required” doing there? 

2) Is “override” only required when there is a default implementation of the 
protocol requirement, or is it required whenever you are implementing a 
protocol requirement?

* If the former, it might be the case that it’s too easy to forget to 
add the “override” keyword (because it’s needed for some implementations of 
protocol requirements but not others), which undercuts the value of having it.

* If the latter, “override” is probably the wrong keyword because it’s 
not overriding anything in the common case of implementing a non-defaulted 
requirement.

> I’d also like to bring up two related topics, although they probably should 
> at some point move to their own thread if they have any legs:
> 
> Related topic 1: How should a consumer handle a situation where two unrelated 
> protocols both require the same member and offer different default 
> implementations. Can they specify which implementation to accept or somehow 
> run both? 
> 
> type B: A, C {
> override required func foo() { A.foo(); C.foo() }
> }

I think the right answer here is for the compiler to produce an ambiguity if 
you don’t implement the requirement yourself, and then solving your “related 
topic 2” lets you choose which implementation you want.

> Related topic 2: How can a consumer “inherit” the behavior of the default 
> implementation (like calling super.foo() in classes) and then extend that 
> behavior further. This is a bit similar to how the initialization chaining 
> works. I’d like to be able to call A.foo() and then add custom follow-on 
> behavior rather than entirely replacing the behavior.
> 
> type B: A {
> override required func foo() { A.foo(); … my custom behavior … }
> }

Seems totally reasonable to me. One ugly syntax: A.foo(self)(), leveraging the 
currying of self?

> cc’ing in Jordan who suggested a new thread on this and Doug, who has already 
> expressed some objections so I want him to  have the opportunity to bring 
> that discussion here.

My objections are described here:

http://thread.gmane.org/gmane.comp.lang.swift.devel/1799/focus=1831 


Essentially, my argument is that the point of “override” (as pitched above) is 
to declare the user’s intent to implement a requirement. I feel that the 
explicit protocol conformance ("type B : A”) declares that intent, and that 
various common conventions (e.g., one conformance per extension, where the 
extension is primarily there to conform to the protocol) reinforce intent well 
enough for the compiler to do a good job here. I’d prefer that over another 
boilerplate-y keyword.

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

[Douglas Gregor via swift-evolution]

> On Apr 26, 2016, at 3:33 AM, James Froggatt  wrote:
> 
> Fair enough. Upon reflection, I think my real issue is somewhat different to 
> what I suggested previously.
> 
> I wasn't intending to suggest such a thing would be practical, just that it 
> would be a decent alternative to optional protocol requirements. The 
> alternative given in the proposal seems to be more of a way to remove 
> optional protocol requirements on the surface, while actually helping to make 
> them a native feature, if you see what I mean. It's not a realistic 
> alternative - it's a worse syntax for the exact same thing, which also comes 
> with awful side-effects for Swift as a whole. No-one would ever seriously 
> consider this as an alternative, yet it's listed as under the heading 
> ‘Alternatives Considered’.

If you follow the swift-evolution discussion links in the proposal, you’ll note 
that a number of people have proposed exactly what is listed in “Alternatives 
Considered”. The only truly wacky idea in there is my caller-side default 
implementations idea, which I covered simply because it was my last stab at 
eliminating optional requirements before giving up and sequestering them 
permanently behind “@objc”.

> 
> You say the arguments given against optional closure properties are strong, 
> but I don't they would be nearly as relevant to the case I suggested. By 
> making them properties of the table view, the tableView parameter would be 
> eliminated, meaning the property names could be unique.
> 
> EG:
> var numberOfRows: (inSection: Int) -> Int
> var cellForRow:: (at: NSIndexPath) -> UITableViewCell
> var moveRow: (from: NSIndexPath, to: NSIndexPath)
> 
> This removes the need to add the mentioned workarounds, since a function 
> could be assigned to the closure property just as easily as an inline 
> closure. I feel this is much more worthy of being considered as an 
> alternative. The idea of these proposals is to document why we do things, so 
> at least for someone wondering why we require all this @objc syntax rather 
> than support optional protocol requirements natively, this would actually 
> present them with a viable alternative which could be applied in their APIs.

Doing this implies creating a potentially large number of stored closure 
properties, which is not as storage-efficient as storing a single delegate 
reference. Moreover, it makes it harder to set up your customization points: 
instead of implementing one protocol, you’re writing assignments into some 
number of stored closure properties. Imaging trying to change the delegate to 
some other delegate temporarily: you would have to manually store each of the 
closures into some local structure and introduce your own, except that you 
can’t get them all because some new version of the platform would add new 
stored closure properties. Finally, Cocoa just doesn’t work like this, so you 
would require some massive re-architecture to get there. I don’t see how this 
is a better design.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

[Douglas Gregor via swift-evolution]

Sent from my iPhone

On Apr 25, 2016, at 10:03 PM, Brent Royal-Gordon  wrote:

>> Note that, if we do the above, I’d love to make it an error to define a new 
>> associated type with the same name as an associated type in an inherited 
>> protocol. It’s odd that we do so, and IIRC the only use case for it is to 
>> add requirement to an “existing” associated type.
> 
> You also do it to specify or change a default associated type. This is from 
> an older copy of the stdlib source code, but I believe there's still 
> something equivalent:
> 
>public protocol CollectionType : Indexable, SequenceType {
>  associatedtype Generator: GeneratorType = IndexingGenerator

Ah yes, of course! Thank you. 

  - Doug
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Mutability for Foundation types in Swift

[Douglas Gregor via swift-evolution]

> On Apr 25, 2016, at 8:39 PM, Russ Bishop via swift-evolution 
>  wrote:
> 
> There aren’t enough +1s in the world for this, I fully endorse your proposal 
> and would like to subscribe to your newsletter ;)
> 
> Do you envision the apinotes will be the vehicle for performing the bridging 
> since ObjectiveCBridgeable was deferred? I actually haven’t checked if that 
> was merged but left as a private protocol or if it still only works in 
> collections.

_ObjectiveCBridgeable is still there, and despite the underscore and the fact 
that it doesn’t match the interface in the deferred proposal, it’s essentially 
fully implemented. The Clang side (swift_bridge attribute) is in swift-clang, 
and there is API notes support for adding it without modifying headers.

- Doug

> 
> Russ
> 
> 
>> On Apr 22, 2016, at 10:18 AM, Tony Parker via swift-evolution 
>> > wrote:
>> 
>> Dear swift-evolution denizens,
>> 
>> As you know from our announcement of Swift Open Source and our work on 
>> naming guidelines, one of our goals for Swift 3 is to “drop NS” for 
>> Foundation. We want to to make the cross-platform Foundation API that is 
>> available as part of swift-corelibs feel like it is not tied to just Darwin 
>> targets. We also want to reinforce the idea that new Foundation API must fit 
>> in with the language, standard library, and the rapidly evolving design 
>> patterns we see in the community.
>> 
>> You challenged us on one part of this plan: some Foundation API just doesn’t 
>> “feel Swifty”, and a large part of the reason why is that it often does not 
>> have the same value type behavior as other Swift types. We took this 
>> feedback seriously, and I would like to share with you the start of an 
>> important journey for some of the most commonly used APIs on all of our 
>> platforms: adopting value semantics for key Foundation types.
>> 
>> We have been working on this for some time now, and the set of diffs that 
>> result from this change is large. At this point, I am going to focus effort 
>> on an overview of the high level goals and not the individual API of each 
>> new type. In order to focus on delivering something up to our quality 
>> standards, we are intentionally leaving some class types as-is until a 
>> future proposal. If you don’t see your favorite class on the list — don’t 
>> despair. We are going to iterate on this over time. I see this as the start 
>> of the process.
>> 
>> One process note: we are still trying to figure out the best way to 
>> integrate changes to API that ship as part of the operating system (which 
>> includes Foundation) into the swift-evolution review process. 
>> Swift-evolution is normally focused on changes to functionality in the 
>> compiler or standard library. In general, I don’t expect all new Foundation 
>> API introduced in the Darwin/Objective-C framework to go through the open 
>> source process. However, as we’ve brought up this topic here before, I felt 
>> it was important to bring this particular change to the swift-evolution list.
>> 
>> As always I welcome your feedback.
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>  
>> 
>> 
>> Thanks,
>> - Tony
>> 
>> 
>> 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-dev] RFC: "Near-miss" checking for defaulted protocol requirements

[Douglas Gregor via swift-evolution]

> On Apr 25, 2016, at 1:13 PM, Erica Sadun  wrote:
> 
> With apologies, I do not see near miss checks as a pressing need:
> 
> * Quick Help lists of required members (including associated types and 
> inherited members) would be far more valuable to me than "near miss" 
> detection.

Understood.

> 
> * I'd like the compiler to check for unsatisfied conformances and emit a list 
> of required conformances including whether they are found and their origin. 
> This would tangentially address the "near miss" case but only for unsatisfied 
> conformances. It would not help when conformances are satisfied.

Yes, the experience here is terrible. What the compiler *should* do is give a 
serious of errors, each of which corresponds to a single requirement and has a 
Fix-It to stub out the appropriate method/property/etc. 

> * I believe "near miss" is less important than "intentional override", 
> requiring a signature of intent as in inheritance. 

> Here's what you said previously on the topic of default implementation 
> overrides that brought me here:
>> 
>> This is a commonly-requested feature that I don’t think we need. The TL;DR 
>> version is that I feel like specifying the conformance explicitly (my type 
>> Foo conforms to protocol P) already expresses intent, and the compiler 
>> should help with the rest. I’ve recently been working on providing better 
>> warnings for cases where one has tried to implement an optional requirement 
>> for a protocol (but got the declaration wrong), and I think we can turn it 
>> on for cases where one got a default implementation instead:
>> 
>>  http://thread.gmane.org/gmane.comp.lang.swift.devel/1799 
>> 
My opinion is that the signature of intent is the explicitly-stated conformance 
to the protocol, but this is not universally agreed upon (even within the core 
team). It suffices to say that a proposal to add some kind of “implements” 
keyword won’t come from me :)

- Doug

> 
> -- Erica
> 
> 
>> On Apr 22, 2016, at 4:33 PM, Douglas Gregor via swift-dev 
>> > wrote:
>> 
>> Hi all,
>> 
>> A common complaint with protocol conformance checking is that it’s easy to 
>> make a little mistake when trying to implement a protocol requirement that 
>> has a default implementation. Here is a silly example:
>> 
>> protocol P { 
>>   func foo(value: Float)
>> }
>> 
>> extension P {
>>   func foo(value: Float) { } // default implementation of P.foo(value:)
>> }
>> 
>> struct S { }
>> 
>> extension S : P {
>>   func foo(value: Double) { } // intended-but-incorrect attempt to satisfy 
>> the requirement P.foo(value:)
>> }
>> 
>> S satisfies the requirement for P.foo(value:) using the implementation from 
>> the protocol extension, although it certainly looks like the user intended 
>> to provide a different implementation.
>> 
>> This kind of problem has prompted repeated calls for some kind of 
>> “implements” keyword to indicate that one is intending to implement a 
>> protocol requirement. I, personally, *really* don’t want yet another 
>> decorator keyword to indicate the intent here, because I believe the user 
>> has already indicated intent by stating conformance to the protocol P. I’ve 
>> recently committed a number of changes that provide “near-miss” checking for 
>> optional requirements of @objc protocols (which have the same problem).
>> 
>> It might be worth enabling this functionality for cases like the above as 
>> well. The Swift compiler patch to do so is attached, and will produce the 
>> following warning for the code above:
>> 
>> t2.swift:12:8: warning: instance method 'foo(value:)' nearly matches 
>> optional requirement 'foo(value:)' of protocol 'P'
>>   func foo(value: Double) { }
>>^
>> t2.swift:12:8: note: candidate has non-matching type '(value: Double) -> ()'
>>   func foo(value: Double) { }
>>^
>> t2.swift:12:8: note: move 'foo(value:)' to another extension to silence this 
>> warning
>>   func foo(value: Double) { }
>>^
>> t2.swift:12:8: note: make 'foo(value:)' private to silence this warning
>>   func foo(value: Double) { }
>>^
>>   private 
>> t2.swift:2:8: note: requirement 'foo(value:)' declared here
>>   func foo(value: Float)
>>^
>> 
>> It’s unfortunate that it’s a lot of notes. The first says what is wrong with 
>> the candidate (and there is much we could do to improve the precision of 
>> this diagnostic!), while the next two are mitigation strategies: move it to 
>> another extension (which implies that it’s not part of the conformance to P) 
>> or explicitly mark it as having less visibility than the conformance (in 
>> this case, private), which feels like a good way to state “I intend this to 
>> be a helper”. This might nudge Swift developers toward a style where they 
>> write one conformance per extension, but I don’t think that’s necessarily a 
>> bad 

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Apr 25, 2016, at 12:37 PM, Joe Groff  wrote:
> 
> I support the approach of making optional requirements ObjC-only. As a 
> nitpick, it feels "wrong" to me to keep a decl modifier around for something 
> that's only a compatibility feature and not natively supported. The proposal 
> notes that a 'objcoptional' modifier was considered and rejected, but why not 
> a single attribute, '@objcOptional' or something like that?

It shouldn't be an attribute because it changes the type signature of 
references to the requirement. 

  - Doug


> 
> -Joe
> 
>> On Apr 25, 2016, at 10:19 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0070: Make Optional Requirements Objective-C only" begins 
>> now and runs through May 2. The proposal is available here:
>> 
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0070-optional-requirements.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>* What is your evaluation of the proposal?
>>* Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>* Does this proposal fit well with the feel and direction of Swift?
>>* If you have you used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
>>* How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> ___
>> 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

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

[Douglas Gregor via swift-evolution]

> On Apr 25, 2016, at 10:13 AM, Erica Sadun  wrote:
> 
> 
>> On Apr 25, 2016, at 10:49 AM, Douglas Gregor > > wrote:
>>> * Swift already has an `Optional` type. Importing ObjC "optional" protocol 
>>> requirements is therefore semantically problematic from a Swift development 
>>> POV. I don't like either the "@objcoptional" or "@objc optional" solutions 
>>> mentioned upthread. They overload "optional" syntactically and confuse 
>>> semantics. I think the key words that better describe what's happening in, 
>>> for example, a `UITableViewDelegate`, are "discretionary" or "elective" 
>>> implementations.  Swift has renamed lots of Objective C things (waves hi to 
>>> SE-0005 
>>> ).
>>>  Why not "optional”?
>> 
>> If we were adding optional requirements to Swift protocols, I would agree 
>> that it makes sense to change the nomenclature to avoid the oxymoron and the 
>> confusion with optionals. However, since this is now moving into the realm 
>> of “Objective-C compatibility feature”, I think it’s reasonable to retain 
>> the existing, Objective-C terminology.
>> 
>> Also, there is a link between the Optional type and optional requirements: 
>> when you reference an optional requirement, you get back an Optional.
> 
> Fair enough point but one that doesn't really sway me enough to include a 
> native keyword for an ObjC compatibility feature.

It’s a contextual keyword, so the impact is far less than a full-fledged 
keyword (but, point taken).

> 
>>> Therefore I find it insufficient to introduce attributes like `@elective` 
>>> or `@discretionary` in order to satisfy non-native requirements. I would 
>>> prefer to see the @objc attribute be extended to support these and any 
>>> future Objective-C-specific behaviors: @objc(elective), 
>>> @objc(importedProtocolSupport: elective), or whatever. While these are 
>>> wordy, I assume like any other Swift attributes they can be placed on a 
>>> line before the function declaration, and it would be instantly clear why 
>>> they've been placed there, and they would not overlap with Swift semantics 
>>> *or* expectations. I leave the color of the bikeshed as an exercise for the 
>>> reader.
>> 
>> Do remember that @objc(something) already has a meaning: it gives the 
>> Objective-C name “something” to the entity that the @objc(something) 
>> describes.
> 
> And this is something I *did* overlook. Is there leeway to add labeled items 
> `@objc(x: y)`?  If so, `@objc(something)` could transition to 
> `@objc(somelabel: something)` and a separate label be used for this.

@objc(x: y) looks suspiciously like a typo for the selector @objc(x:y:).

> 
> The key point I want to make is that something that is semantically and 
> syntactically external to the language should enter through a well regulated 
> gateway.

It’s not semantically and syntactically external. It is a real feature with 
specific, unique type-checking behavior. It is externally-motivated, and 
limited to interoperability with another language, but that doesn’t make it an 
external feature in the way that (say) some other tool that generates Swift 
code is external.

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Rewrite imported C function signatures

[Douglas Gregor via swift-evolution]

> On Apr 24, 2016, at 3:45 PM, Carlos Rodríguez Domínguez 
>  wrote:
> 
> Thanks for the explanation, which makes me think that it should be suitable, 
> as you comment, to promote API notes to a “first class” transition technology.
> 
> As a first approach towards that goal, would it be ok to expand the notion of 
> “bridging headers” to also include API notes? In that case, it could be 
> appropriate to develop a new C syntax to refer to YAML API notes inside 
> bridging headers. For instance, something like this could be nice:
> 
> #apinotes “notes.yaml”

I think of API notes like module maps: it’s an external format that lays 
additional semantic information on top of existing headers without requiring 
you to modify those headers (because you often don’t control them).

- Doug

> 
> 
>> El 29 mar 2016, a las 18:45, Douglas Gregor  escribió:
>> 
>> 
>>> On Mar 29, 2016, at 3:02 AM, Carlos Rodríguez Domínguez 
>>>  wrote:
>>> 
>>> Well, those proposal are more oriented towards annotating on C/Objective-C 
>>> files to allow a more sophisticate import into swift.
>> 
>> Yes, that is true. The philosophy behind these is that it’s better to 
>> automatically transform (via annotation) than manually wrap. Naturally, such 
>> transformations cannot handle everything.
>> 
>>> However, my proposal is to be able to directly annotate in swift, in order 
>>> to fix “old-style” imports, autogenerated code, etc. Please, allow me to 
>>> repeat myself, but consider the example of Core Data, in which model 
>>> classes are autogenerated from a graphical model that, for instance, lacks 
>>> from enums’ support. Therefore, if we use Core Data, then we can not use 
>>> enums (Please, take a look at the proposal named "[swift-evolution] Promote 
>>> "primitive" types to enums in extensions” in order to understand the 
>>> intention of my proposal as a whole).
>> 
>> There is a Clang attribute “swift_private” that prefixes the name of the 
>> declaration with “__” when it is imported into Swift. That way, you can wrap 
>> it with a different, more Swift-friendly, API that calls the “__” version.
>> 
>> Note that we do have a mechanism for annotating C/Objective-C APIs without 
>> modifying the headers, called “API notes”. It’s a simple YAML format that 
>> lets us describe various Clang attributes for entities, e.g., provide the 
>> Swift name for a given C function, mark a type as unavailable in Swift, and 
>> so on. It’s semi-documented in the swift-clang sources:
>> 
>>  
>> https://github.com/apple/swift-clang/blob/upstream-with-swift/lib/APINotes/APINotesYAMLCompiler.cpp
>> 
>> Essentially, one writes a YAML file for each module that needs annotation. 
>> API notes was designed as a transitional technology, so it’s a bit 
>> under-designed for a general-purpose tool. However, as we add more 
>> Clang-side annotations to improve the mapping of C/Objective-C APIs into 
>> Swift, it’s becoming more likely that API notes could/should grow into a 
>> more general mechanism for adapting existing C/Objective-C APIs to Swift 
>> without manually wrapping everything.
>> 
>>  - Doug
>> 
 El 28 mar 2016, a las 7:29, Douglas Gregor  escribió:
 
 
> On Mar 25, 2016, at 3:25 AM, Carlos Rodríguez Domínguez via 
> swift-evolution  wrote:
> 
> (Please, take a look at the proposal named "[swift-evolution] Promote 
> "primitive" types to enums in extensions” in order to understand the 
> intention of my proposal as a whole)
> 
> This proposal intends to allow developers to rewrite func signatures to 
> better adapt certain imported C functions to swift. For instance, the 
> function to create a POSIX socket has a C signature like this:
> 
> int socket(int domain, int type, int protocol);
> 
> In swift, it is currently imported like this:
> 
> func socket(_: Int32, _: Int32, _: Int32) -> Int32
> 
> However, by documentation, the first parameter should be one of a set of 
> constants beginning with PF_. The second one should be either 
> SOCK_STREAM, SOCK_DGRAM or SOCK_RAW. The third one should be a constant 
> specifying the protocol to use. Finally, the result could be either -1 
> (to indicate an error) or another integer to indicate that a socket 
> descriptor has been returned.
> 
> As you can observe, that old-style signature is highly error prone, does 
> not comply with swift guidelines, it is difficult to understand, etc. My 
> opinion is that there should be some syntax to rewrite the signature to 
> avoid those issues. For instance, a possible syntax could be:
> 
> #mapsignature(socket(_:,_:,_:)->Int32)
> func socket(domain:SocketDomain, type:SocketType, 
> protocol:SocketProtocol) -> socket_t? {
>   let result = socket(domain.rawValue, type.rawValue, 

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

[Douglas Gregor via swift-evolution]

> On Apr 24, 2016, at 7:02 PM, Erica Sadun <er...@ericasadun.com> wrote:
> 
> 
>> On Apr 24, 2016, at 3:28 PM, Chris Lattner via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu <xiaodi...@gmail.com 
>>>> <mailto:xiaodi...@gmail.com>> wrote:
>>>> 
>>>> Not an expert on Obj-C compatibility in Swift by any means, but this
>>>> reads like it's largely a change of nomenclature. To me, though,
>>>> `objcoptional` reads exceedingly poorly. Why not emphasize the Obj-C
>>>> compatibility angle by requiring the `@objc` attribute to precede each
>>>> use of `optional`? (In other words, effectively rename `optional` to
>>>> `@objc optional`.)
>>> 
>>> That is a great idea. 
>> 
>> Doesn’t this have the same problem as the current (Swift 1/2) 
>> implementation?  People will continue to believe that it is a bug that you 
>> must specify @objc.
>> 
>> -Chris
> 
> I thought I'd throw a few ideas into the mix. I'm arriving late to the 
> discussion. (I didn't expect the conversation to last this long.) I did take 
> a quick look back through the thread but I may have missed some bits along 
> the way. Apologies in advance for any redundancy:

> * Swift's "optional" protocol implementations are no such thing. They are 
> default implementations that can be overridden.

(Pulling this one out first). When I read “a default implementation that can be 
overridden”, I think of the conforming type *or a subclass thereof* providing a 
different implementation from the default. “Optional” requirements are things 
that the conforming type does not have to provide…. and a user of the protocol 
must cope with conforming types that don’t provide them.

> (Tangentially, why not introduce a required "override" keyword for conforming 
> types that implement a version of a member introduced in protocol extensions? 
> This would match the class approach and enhance safety and intent.)

This is a commonly-requested feature that I don’t think we need. The TL;DR 
version is that I feel like specifying the conformance explicitly (my type Foo 
conforms to protocol P) already expresses intent, and the compiler should help 
with the rest. I’ve recently been working on providing better warnings for 
cases where one has tried to implement an optional requirement for a protocol 
(but got the declaration wrong), and I think we can turn it on for cases where 
one got a default implementation instead:

http://thread.gmane.org/gmane.comp.lang.swift.devel/1799

> 
> * Optional requirement is an oxymoron. (This is a redux of my previous 
> contribution to this topic but it's a good starting point.)
> 
> * Swift already has an `Optional` type. Importing ObjC "optional" protocol 
> requirements is therefore semantically problematic from a Swift development 
> POV. I don't like either the "@objcoptional" or "@objc optional" solutions 
> mentioned upthread. They overload "optional" syntactically and confuse 
> semantics. I think the key words that better describe what's happening in, 
> for example, a `UITableViewDelegate`, are "discretionary" or "elective" 
> implementations.  Swift has renamed lots of Objective C things (waves hi to 
> SE-0005 
> <https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md>).
>  Why not "optional”?

If we were adding optional requirements to Swift protocols, I would agree that 
it makes sense to change the nomenclature to avoid the oxymoron and the 
confusion with optionals. However, since this is now moving into the realm of 
“Objective-C compatibility feature”, I think it’s reasonable to retain the 
existing, Objective-C terminology.

Also, there is a link between the Optional type and optional requirements: when 
you reference an optional requirement, you get back an Optional.

> * I do *support* retaining `@objc` in some form and I believe it can be 
> addressed in a way that does not appear to be a bug. "Optional protocol 
> conformance" is a behavior that is external to the language. I do not believe 
> would be voluntarily added to Swift should the topic arise.

It’s a feature that exists to support compatibility with another language; we 
would not add it if it not for Objective-C. However, it is a real languag

Re: [swift-evolution] Mutability for Foundation types in Swift

[Douglas Gregor via swift-evolution]

> On Apr 25, 2016, at 9:20 AM, Tony Parker via swift-evolution 
>  wrote:
> 
> Hi Brent,
> 
> Thanks for your feedback! You’ve got some great questions below, I’ll try to 
> answer them as best I can.
> 
>> On Apr 24, 2016, at 3:44 AM, Brent Royal-Gordon  
>> wrote:
>> 
>>> We took this feedback seriously, and I would like to share with you the 
>>> start of an important journey for some of the most commonly used APIs on 
>>> all of our platforms: adopting value semantics for key Foundation types.
>> 
>> This proposal is way cool, and I think you've selected a great starting set 
>> of APIs.
>> 
>> Of the other candidate APIs you mentioned, I'm definitely looking forward to 
>> AttributedString and some parts of the NSURL Loading system (primarily the 
>> requests and responses; the connections and sessions should probably be 
>> object types). Predicate, OrderedSet, CountedSet, and possibly Number and 
>> Value make sense as well.
>> 
>> However, I think that Locale, Progress, Operation, Calendar, and Port are 
>> poor candidates for becoming value types, because they represent specific 
>> resources which may be partially outside of your thread's/process's control; 
>> that is, they're rather like NS/UIView, in that they represent a specific, 
>> identifiable "thing" which cannot be copied without losing some aspect of 
>> its meaning.
> 
>>>   if !isUniquelyReferencedNonObjC(&_box) {
>> 
>> 
>> Something I have often wondered about: Why doesn't 
>> `isUniquelyReferenced(_:)` use `-retainCount` on Objective-C objects? 
>> Alternatively, why not use `-retainCount` on fields in your value types when 
>> you're trying to implement COW behavior? It seems like that would allow you 
>> to extend the copy-on-write mechanism to Objective-C objects. I know that 
>> `-retainCount` is usually not very useful, but surely this copy-on-write 
>> situation, where you are using it in an advisory fashion and an 
>> overestimated retain count will simply cause you to unnecessarily lose some 
>> efficiency, is the exception to the rule?
>> 
>> There are likely good reasons for this decision—they simply aren't obvious, 
>> and I'd like to understand them.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
> 
> There are a few reasons for this, but the one that sticks out most to me is 
> that in Objective-C, retain, release, and retainCount don’t include weak 
> references. If you take a look at the internals for the swift retain count 
> function, you’ll see that there are two: owned and unowned.


Right. I went down this rabbit hole a few weeks ago, trying to determine if we 
could make an “isUniquelyReferenced” that works for Objective-C-defined 
classes. One obvious issue is that you can’t always trust retainCount to do the 
right thing for an arbitrary Objective-C class, because it may have been 
overridden. We can probably say “don’t do that” and get away with it, but that 
brings us to Tony’s point: Objective-C weak references are stored in a separate 
side table, so we can’t atomically determine whether an Objective-C class is 
uniquely referenced. On platforms that have a non-pointer “isa” we could make 
this work through the inline reference count (which requires changes to the 
Objective-C runtime and therefore wouldn’t support backward deployment), but 
that still doesn’t give us “isUniquelyReferenced” for Objective-C classes 
everywhere.

Interestingly, while Swift’s object layout gives us the ability to consider the 
weak reference count, the Swift runtime currently does not do so. IIRC, part of 
our reasoning was that isUniquelyReferencedNonObjC is generally there to 
implement copy-on-write, where weak references aren’t actually interesting. 
However, we weren’t comfortable enough in that logic to commit to excluding 
weak references from isUniquelyReferencedNonObjC “forever", and certainly 
aren’t comfortable enough in that reasoning to enshrine “excluding weak 
references” as part of the semantics of isUniquelyReference for Objective-C 
classes.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> Not an expert on Obj-C compatibility in Swift by any means, but this
> reads like it's largely a change of nomenclature. To me, though,
> `objcoptional` reads exceedingly poorly. Why not emphasize the Obj-C
> compatibility angle by requiring the `@objc` attribute to precede each
> use of `optional`? (In other words, effectively rename `optional` to
> `@objc optional`.)

That is a great idea. 
> 
> 
> On Fri, Apr 22, 2016 at 7:35 PM, Douglas Gregor via swift-evolution
> <swift-evolution@swift.org> wrote:
>> Proposal link:
>> https://github.com/DougGregor/swift-evolution/blob/objc-optional/proposals/-optional-requirements.md
>> 
>> After a whole lot of discussion and thrashing on optional requirements, I
>> have a draft for a modest proposal: change the ‘optional’ keyword to
>> something that indicates that this feature is only for compatibility with
>> Objective-C and will not be supported on Swift protocols. Comments welcome!
>> 
>> - Doug
>> 
>> Make Optional Requirements Objective-C-only
>> 
>> Proposal: SE-
>> Author(s): Doug Gregor
>> Status: Awaiting review
>> Review manager: TBD
>> 
>> Introduction
>> 
>> Swift currently has support for "optional" requirements in Objective-C
>> protocols, to match with the corresponding feature of Objective-C. We don't
>> want to make optional requirements a feature of Swift protocols (for reasons
>> described below), nor can we completely eliminate the notion of the language
>> (for different reasons also described below). Therefore, to prevent
>> confusion about our direction, this proposal changes the optional keyword
>> objcoptional to indicate that this is an Objective-C compatibility feature.
>> 
>> Swift-evolution threads: eliminate optional requirements, make Swift
>> protocols support optional requirements and make optional protocol
>> requirements first class citizens.
>> 
>> Motivation
>> 
>> Having optional only work for Objective-C requirements is very weird: it
>> feels like a general feature with a compiler bug that prevents it from
>> working generally. However, we don't want to make it a feature of Swift
>> protocols and we can't eliminate it (see alternatives considered), so we
>> propose to rename the keyword to make it clear that this feature is intended
>> only for compatibility with Objective-C.
>> 
>> Proposed solution
>> 
>> Rename the optional contextual keyword to objcoptional. Note that:
>> 
>> It would read better as objc_optional or objcOptional, but keywords in Swift
>> run the words together, and
>> 
>> It should not be an attribute @objcOptional because it changes the effective
>> type of the declaration. Referencing an optional requirement wraps the
>> result in one more level of optional, which is used to test whether the
>> requirement was implemented.
>> 
>> This means that:
>> 
>> @objc protocol NSTableViewDelegate {
>>  optional func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int)
>> -> NSView?
>>  optional func tableView(_: NSTableView, heightOfRow: Int) -> CGFloat
>> }
>> 
>> becomes:
>> 
>> @objc protocol NSTableViewDelegate {
>>  objcoptional func tableView(_: NSTableView, viewFor: NSTableColumn, row:
>> Int) -> NSView?
>>  objcoptional func tableView(_: NSTableView, heightOfRow: Int) -> CGFloat
>> }
>> 
>> Impact on existing code
>> 
>> Any code that declares @objc protocols with optional requirements will need
>> to be changed to use the objcoptionalkeyword. However, it is trivial for the
>> migrator to update the code and for the compiler to provide Fix-Its, so the
>> actual impact on users should be small.
>> 
>> Alternatives considered
>> 
>> It's a fairly common request to make optional requirements work in Swift
>> protocols (as in the aforementioned threads, hereand here). However, such
>> proposals have generally met with resistance because optional requirements
>> have significant overlap with other protocol features: "default"
>> implementations via protocol extensions and protocol inheritance. For the
>> former case, the author of the protocol can provide a "default"
>> implementation via a protocol extension that encodes the default case
>> (rather than putting it at the call site). In the latter case, the protocol
>> author can separate the optional requirements into a different protocol that
>>

[swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

[Douglas Gregor via swift-evolution]

Proposal link: 
https://github.com/DougGregor/swift-evolution/blob/objc-optional/proposals/-optional-requirements.md

After a whole lot of discussion and thrashing on optional requirements, I have 
a draft for a modest proposal: change the ‘optional’ keyword to something that 
indicates that this feature is only for compatibility with Objective-C and will 
not be supported on Swift protocols. Comments welcome!

- Doug

Make Optional Requirements Objective-C-only

Proposal: SE- 

Author(s): Doug Gregor 
Status: Awaiting review
Review manager: TBD
 
Introduction

Swift currently has support for "optional" requirements in Objective-C 
protocols, to match with the corresponding feature of Objective-C. We don't 
want to make optional requirements a feature of Swift protocols (for reasons 
described below), nor can we completely eliminate the notion of the language 
(for different reasons also described below). Therefore, to prevent confusion 
about our direction, this proposal changes the optional keyword objcoptional to 
indicate that this is an Objective-C compatibility feature.

Swift-evolution threads: eliminate optional requirements 
, make Swift 
protocols support optional requirements 
 and make optional 
protocol requirements first class citizens 
.

 
Motivation

Having optional only work for Objective-C requirements is very weird: it feels 
like a general feature with a compiler bug that prevents it from working 
generally. However, we don't want to make it a feature of Swift protocols and 
we can't eliminate it (see alternatives considered 
),
 so we propose to rename the keyword to make it clear that this feature is 
intended only for compatibility with Objective-C.

 
Proposed
 solution

Rename the optional contextual keyword to objcoptional. Note that:

It would read better as objc_optional or objcOptional, but keywords in Swift 
run the words together, and

It should not be an attribute @objcOptional because it changes the effective 
type of the declaration. Referencing an optional requirement wraps the result 
in one more level of optional, which is used to test whether the requirement 
was implemented.

This means that:

@objc protocol NSTableViewDelegate {
  optional func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int) -> 
NSView?
  optional func tableView(_: NSTableView, heightOfRow: Int) -> CGFloat
}
becomes:

@objc protocol NSTableViewDelegate {
  objcoptional func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int) 
-> NSView?
  objcoptional func tableView(_: NSTableView, heightOfRow: Int) -> CGFloat
}
 
Impact
 on existing code

Any code that declares @objc protocols with optional requirements will need to 
be changed to use the objcoptionalkeyword. However, it is trivial for the 
migrator to update the code and for the compiler to provide Fix-Its, so the 
actual impact on users should be small.

 
Alternatives
 considered

It's a fairly common request to make optional requirements work in Swift 
protocols (as in the aforementioned threads, here 
and here 
). However, such 
proposals have generally met with resistance because optional requirements have 
significant overlap with other protocol features: "default" implementations via 
protocol extensions and protocol inheritance. For the former case, the author 
of the protocol can provide a "default" implementation via a protocol extension 
that encodes the default case (rather than putting it at the call site). In the 
latter case, the protocol author can separate the optional requirements into a 
different protocol that a type can adopt to opt-in to whatever behavior they 
customize. While not exactlythe same as optional requirements, which allow one 
to perform per-requirement checking to determine whether the type implemented 
that 

Re: [swift-evolution] [META] Fast Track Reviews

[Douglas Gregor via swift-evolution]

> On Apr 18, 2016, at 7:39 PM, Douglas Gregor via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
> Sent from my iPhone
> 
> On Apr 18, 2016, at 8:56 AM, Erica Sadun via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> I would like to see Swift Evolution adopt a couple of styles of fast track 
>> reviews. Chris Lattner
>> suggested I bring this up on-list for discussion to allow the community to 
>> offer feedback 
>> on my idea.
>> 
>> STYLE ONE: Minor language enhancements AKA "Low hanging fruit"
>> 
>> I would like the core team to be able to add minor language enhancements 
>> without going
>> through a formal proposal process, with its normal review overhead. I have 
>> now been
>> involved in several reviews that involved API changes that were otherwise 
>> unremarkable
>> and primarily motivated by modernizing and style:
>> 
>> * Replacing Equal Signs with Colons For Attribute Arguments 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0040-attributecolons.md>
>> * Modernizing Playground Literals 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md>
>> * Disambiguating Line Control Statements from Debugging Identifiers 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md>
>> 
>> To this list, you could add:
>> 
>> * Remove explicit use of let from Function Parameters 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md>
>> 
>> Each of these proposals could have proceeded with a simple "any objections" 
>> sanity check 
>> discussion period rather than a more formal full review. As a another example
>> (now unnecessary <https://github.com/apple/swift-evolution/pull/256>), 
>> consider the `dynamicType` keyword, which would have required
>> a formal proposal to be modernized into Swift's lowercase keyword standard.
>> 
>> The hallmarks of these changes are:
>> 
>> * They have limited impact
>> * They increase language consistency
>> * They are uncontroversial, offering simple, straightforward, and correct 
>> changes 
>>that have already passed review in spirit, if not in letter
>> * A preponderance of reviews are "+1" rather than in-depth discussions of 
>> why the proposal 
>>   should or should not be adopted.
>> 
>> I would recommend retaining a change document requirement for these 
>> proposals.
>> This would be similar to a brief but formal proposal, that lays out the 
>> justification, 
>> detail design, and any associated background info for the change. Doing so
>> would provide a historic record of the change and any notes from the team, 
>> and be 
>> in a form that would support the extraction of key details for use in 
>> release notes.
>> 
>> I do not know whether these would need to be grouped and numbered with the 
>> normal
>> proposals or placed into their own numbering scheme.
> 
> My main concerns are to have a proper paper trail documenting when and why we 
> make a change. My preferred approach here would be to go through the normal 
> process up to the pull request for the proposal... Then if it's obviously 
> small and good, the core team could just go straight to accept, sending out 
> an announcement. 

The core team did discuss this, and we agreed that there are small changes 
(particularly those that come from actually implementing the proposal) that 
could be treated as “bug fixes” to the proposal. When we accept such a pull 
request, we will send out an [Amendment] to swift-evolution [*].

We expect to use this sparingly. The removal of the vestigial “let” from 
function parameter lists is one case where we could have done this, the others 
are on the fence.

- Doug

[*] I still owe one of these for a recent pull request we accepted to amend 
SE-0016.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Rejected] SE-0056: Allow trailing closures in `guard` conditions

[Douglas Gregor via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions” ran from 
March 31...April 5, 2016. The proposal is rejected. The core team felt that the 
benefits from this change were outweighed by the inconsistency it would 
introduce with `if` and `while`.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Douglas Gregor via swift-evolution]

> On Apr 19, 2016, at 12:41 AM, Vladimir.S <sva...@gmail.com> wrote:
> 
> Just wanted to go back to
> Apply API Guidelines to the Standard Library  SE-0006
> https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md
> for a second.
> 
> Just found out that this code is working in 3.0(mar 24):
> var z1 = [3,2,1]
> let z2 = z1.sort() // mutating method!
> print(z2) // => ()
> 
> so.. is this a final implementation or we are expecting to have a lot of 
> hard-to-find errors in our Swift 3.0 code if code written for previous Swift 
> will be used(private lib/snippet/etc)?
> 
> Also, just interesting, are we all expecting libs like RxSwift and 
> ReacriveCocoa will rename their methods accordingly to names changed in Swift 
> 3.0?

It definitely seems reasonable for us to warn on this kind of example, e.g., 
placing a Void result of a call to a mutating method in a variable. Can you 
file a ticket a bugs.swift.org? It would be a great starter bug.

- Doug

> 
> On 19.04.2016 0:18, Douglas Gregor via swift-evolution wrote:
>> 
>> Proposal
>> link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md
>> 
>> 
>> Hello Swift Community,
>> 
>> The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs
>> Accordingly” ran from March 31...April 5, 2016. The proposal is *accepted*.
>> 
>> There was much debate, both before and during the review, over the
>> “InPlace” suffix/ “form” prefix, and at this point any answer will be
>> objectionable to some. The core team has opted to accept the proposal
>> as-is, keeping the “form” prefix to describe the mutating counterpart to an
>> operation naturally described by a noun (e.g., “formUnion” for the mutating
>> variant of “union”), for the reasons described in the proposal itself.
>> Thanks all for the spirited discussion!
>> 
>> - Doug
>> 
>> 
>> ___
>> 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

Re: [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Apr 20, 2016, at 8:36 AM, Joanna Carter  
> wrote:
> 
> Hi Doug
> 
>> In programming-language circles, this feature is called “dependent types” 
>> (see, e.g., https://en.wikipedia.org/wiki/Dependent_type), and it introduces 
>> significant complicates into a type system. For example, determining whether 
>> two types are equivalent becomes a run-time property rather than a 
>> compile-time property. I don’t know if Swift will end with a 
>> dependently-typed type system. To get there, we would need a number of very 
>> strongly-motivating use cases illustrating how common programming tasks can 
>> be improved with dependent types,  and we would need to solid plan for 
>> managing the complexity—both implementation complexity in the compiler’s 
>> type checker and also the language complexity seen by Swift user’s when they 
>> encounter this feature.
> 
> I must admit to being ever so slightly confused about your connection with 
> "dependent types"; in all my years of programming, I have never come across 
> the context of the expression as found in the article cited. Anything that 
> needs algebraic formulae to explain is far too complicated for mere mortal 
> programmers and I am willing to state that I certainly didn't understand more 
> than a few words.

Programming language theory (PL) tends to be painfully formal; much of what 
Swift's type system can be describe in PL  formalisms as well. 

My point is that your suggestion falls into a known theoretical framework that 
adds significant complications to the type system (and compiler pipeline in 
general). That complexity needs to be understood and managed. 

> 
> All I am postulating is the ability to create instances of generic types, 
> bound to (a) parameter type(s) in the same manner as is currently possible 
> with non-generic types.

Yes. It's bringing runtime type information into the static type system. 

> 
> To bring it down to basics, take the example of wanting to create an array of 
> a given type of objects:
> 
>let aType: Any.Type = Int.self
> 
>var arr = [aType]
> 
> … creates an array of Any.type…
> 
>let aType: Any.Type = Int.self
> 
>var arr = [aType]()
> 
> … results in an error "Invalid use of '()' to call a value of non-function 
> type '[Any.Type]'"
> 
>let aType: Any.Type = Int.self
> 
>var arr = Array() 
> 
> … results in an error "'aType' is not a type"
> 
> 
> So, how are we meant to be able to create arrays, or any other generic type 
> that require to be bound to a type known only at runtime?

[Any] is a heterogenous array of elements whose types are known only at 
runtime. 

> In C#, We have the Type class, which contains useful properties like 
> isGenericType, isConstructedGenericType and methods like 
> GetGenericArguments() and, most important to this use case, 
> MakeGenericType(Type []).

This is a reflection facility. Swift should get better reflection, but that's a 
very different thing from dependent types. 

> 
> I would make a strong argument for completing Swift generics by including 
> such facilities in Any.Type, so that:
> 
> 1. we do not have to use the somewhat cumbersome Mirror mechanism
> 
> 2. we can do something useful with instances of Any.Type, which, at present, 
> does absolutely nothing.
> 
> Adding similar functionality to C#'s Type class to Any.Type would break 
> absolutely zero code but would make life a whole load easier for those of us 
> who are power users of generics. Otherwise, FMPOV, Swift generics are but a 
> pale imitation of the concept and very much second class citizens 

It's a stretch to call reflection part of the generics system, but it is a 
feature were interested in improving upon in the future. 

  - Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

[Douglas Gregor via swift-evolution]

Sent from my iPhone

On Apr 18, 2016, at 4:11 PM, Robert Schwalbe via swift-evolution 
 wrote:

>> Hello Robert,
>> 
>> My comment below:
>> 
>>> Per my reading of SE-0022, would SE-0064 institute the first exception to 
>>> the #selector expression where the expression is not a reference to a 
>>> method?
>> 
>> Indeed. But I don’t see the issue. It still generates a selector for an 
>> Objective-C method.
> 
> Thank you David.
> 
> I do agree it generates a selector. My objection would be that there are no 
> Objective-C methods named “getter” or “setter”.

Objective-C's @property syntax uses "getter" and "setter" to name the getter 
and setter selectors, and that's the information being extracted by this Swift 
expression. 

  - Doug

> 
>>> In the spirit of taking my lumps for not speaking up when asked to do so, 
>>> was there any discussion that considered:
>>> 
>>>  let firstNameGetter = #selector(get: Person.firstName)
>>>  let firstNameSetter = #selector(set: Person.firstName)
>>> 
>>> in lieu of the accepted:
>>> 
>>>  let firstNameGetter = #selector(getter: Person.firstName)
>>>  let firstNameSetter = #selector(setter: Person.firstName)
>>> 
>>> My concern would be a growing list of permitted non method name parameters 
>>> to the #selector expression.
>> 
>> I don’t think get/set was specifically mentioned. My personal opinion is 
>> that it does not read well because it reads as an action.
> 
> I could go along with you that it reads as an action, but I also think we 
> could come up with tons of existing toolbox method names that would also read 
> as actions.
> 
> Maybe I am hung up on insisting that the expression must be an actual name of 
> an Objective-C method.
> ___
> 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

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Douglas Gregor via swift-evolution]

> On Apr 15, 2016, at 5:24 PM, Brent Royal-Gordon  
> wrote:
> 
>> That’s the other part of my argument: if it is true that Swift code only 
>> needs to conform to ObjC protocols with optional requirements, but Swift 
>> code does not need to invoke optional requirements of ObjC protocols except 
>> very rarely, then it’s okay for calling-an-optional-requirement not to be 
>> part of the Swift language.
> 
> How much of a complication is the `methodName?` behavior?

It’s a semi-complicated path through the type checker, but it’s not awful to 
maintain. There’s a bit of a “fix it or remove it” issue here, because it 
doesn’t work for settable properties, even though there are very few such 
things. 

> If you're confident that `optional` is the wrong choice for protocols 
> designed in the future, perhaps you could just make it impossible to declare 
> a new optional requirement in Swift, but leave the calling behavior as-is?

Sure, we can make it arbitrarily hard to use. For example, calling it 
@objc_optional or similar would reinforce that it’s an Objective-C 
compatibility feature rather than an intended Swift feature.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Douglas Gregor via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md


Hello Swift Community,

The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs 
Accordingly” ran from March 31...April 5, 2016. The proposal is accepted. 

There was much debate, both before and during the review, over the “InPlace” 
suffix/ “form” prefix, and at this point any answer will be objectionable to 
some. The core team has opted to accept the proposal as-is, keeping the “form” 
prefix to describe the mutating counterpart to an operation naturally described 
by a noun (e.g., “formUnion” for the mutating variant of “union”), for the 
reasons described in the proposal itself. Thanks all for the spirited 
discussion!

- Doug___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0048: Generic Type Aliases

[Douglas Gregor via swift-evolution]

> On Apr 16, 2016, at 4:12 PM, Chris Lattner  wrote:
> 
> 
>> On Apr 16, 2016, at 1:12 AM, Nicola Salmoria via swift-evolution 
>>  wrote:
>> 
>>> Proposal link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
>>> 
>>> The review of SE-0048 “Generic Type aliases” ran from March 24…29, 2016. 
>>> The proposal received overwhelmingly positive feedback and has now been 
>>> implemented for Swift 3.
>>> 
>>> - Doug
>> 
>> Is this actually implemented fully?
> 
> No, I’m still working on it.


I’d forgotten that the implementation was still incomplete.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Douglas Gregor via swift-evolution]

> On Apr 15, 2016, at 4:27 PM, Matthew Johnson <matt...@anandabits.com> wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Apr 15, 2016, at 6:17 PM, Douglas Gregor <dgre...@apple.com 
> <mailto:dgre...@apple.com>> wrote:
> 
>> 
>>> On Apr 15, 2016, at 4:15 PM, Matthew Johnson <matt...@anandabits.com 
>>> <mailto:matt...@anandabits.com>> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>> On Apr 15, 2016, at 6:03 PM, Douglas Gregor <dgre...@apple.com 
>>> <mailto:dgre...@apple.com>> wrote:
>>> 
>>>> 
>>>>> On Apr 15, 2016, at 3:55 PM, Matthew Johnson <matt...@anandabits.com 
>>>>> <mailto:matt...@anandabits.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Apr 13, 2016, at 11:42 AM, Douglas Gregor <dgre...@apple.com 
>>>>>> <mailto:dgre...@apple.com>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Apr 11, 2016, at 10:30 AM, Matthew Johnson <matt...@anandabits.com 
>>>>>>> <mailto:matt...@anandabits.com>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Sent from my iPad
>>>>>>> 
>>>>>>>> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution 
>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution 
>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>>>> 
>>>>>>>>> One could perhaps work around (a), (b), and (d) by allowing compound 
>>>>>>>>> (function-like) names like tableView(_:viewFor:row:) for properties, 
>>>>>>>>> and work around (c) by allowing a method to satisfy the requirement 
>>>>>>>>> for a read-only property, but at this point you’ve invented more 
>>>>>>>>> language hacks than the existing @objc-only optional requirements. 
>>>>>>>>> So, I don’t think there is a solution here.
>>>>>>>> 
>>>>>>>> To me, compound names for closure properties and satisfying property 
>>>>>>>> requirements with methods aren't hacks, they're missing features we 
>>>>>>>> ought to support anyway. I strongly prefer implementing those over 
>>>>>>>> your proposed solution. It sounds to me like a lot of people using 
>>>>>>>> optional protocol requirements *want* the locality of control flow 
>>>>>>>> visible in the caller, for optimization or other purposes, and your 
>>>>>>>> proposed solution makes this incredibly obscure and magical.
>>>>>>> 
>>>>>>> Do you have the same thought for optional closure properties?  If so 
>>>>>>> and heightForRow was an optional closure property it would satisfy all 
>>>>>>> use cases elegantly.  It could have a default implementation that 
>>>>>>> returns nil.  When non-uniform heights are required a normal method 
>>>>>>> implementation can be provided.  Delegates that have uniform row 
>>>>>>> heights some of the time, but not all of the time, would also be 
>>>>>>> supported by implementing the property.
>>>>>> 
>>>>>> There are still some issues here:
>>>>>> 
>>>>>> 1) It doesn’t handle optional read/write properties at all, because the 
>>>>>> setter signature would be different. Perhaps some future lens design 
>>>>>> would make this possible. For now, the workaround would have to be 
>>>>>> importing the setter as a second optional closure property, I guess. 
>>>>>> (The current system is similarly broken).
>>>>> 
>>>>> I was only thinking about methods, not properties.  :)  How common are 
>>>>> optional, writeable property requirements?  I don’t have a good guess off 
>>>>> the top of my head, but my hunch is that they are not that common. 
>>>> 
>>>> They are *very* rare. Aside from UITextInputTraits 
>>>> <https://develo

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Douglas Gregor via swift-evolution]

> On Apr 15, 2016, at 4:15 PM, Matthew Johnson <matt...@anandabits.com> wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Apr 15, 2016, at 6:03 PM, Douglas Gregor <dgre...@apple.com 
> <mailto:dgre...@apple.com>> wrote:
> 
>> 
>>> On Apr 15, 2016, at 3:55 PM, Matthew Johnson <matt...@anandabits.com 
>>> <mailto:matt...@anandabits.com>> wrote:
>>> 
>>> 
>>>> On Apr 13, 2016, at 11:42 AM, Douglas Gregor <dgre...@apple.com 
>>>> <mailto:dgre...@apple.com>> wrote:
>>>> 
>>>>> 
>>>>> On Apr 11, 2016, at 10:30 AM, Matthew Johnson <matt...@anandabits.com 
>>>>> <mailto:matt...@anandabits.com>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> Sent from my iPad
>>>>> 
>>>>>> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution 
>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution 
>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>> 
>>>>>>> One could perhaps work around (a), (b), and (d) by allowing compound 
>>>>>>> (function-like) names like tableView(_:viewFor:row:) for properties, 
>>>>>>> and work around (c) by allowing a method to satisfy the requirement for 
>>>>>>> a read-only property, but at this point you’ve invented more language 
>>>>>>> hacks than the existing @objc-only optional requirements. So, I don’t 
>>>>>>> think there is a solution here.
>>>>>> 
>>>>>> To me, compound names for closure properties and satisfying property 
>>>>>> requirements with methods aren't hacks, they're missing features we 
>>>>>> ought to support anyway. I strongly prefer implementing those over your 
>>>>>> proposed solution. It sounds to me like a lot of people using optional 
>>>>>> protocol requirements *want* the locality of control flow visible in the 
>>>>>> caller, for optimization or other purposes, and your proposed solution 
>>>>>> makes this incredibly obscure and magical.
>>>>> 
>>>>> Do you have the same thought for optional closure properties?  If so and 
>>>>> heightForRow was an optional closure property it would satisfy all use 
>>>>> cases elegantly.  It could have a default implementation that returns 
>>>>> nil.  When non-uniform heights are required a normal method 
>>>>> implementation can be provided.  Delegates that have uniform row heights 
>>>>> some of the time, but not all of the time, would also be supported by 
>>>>> implementing the property.
>>>> 
>>>> There are still some issues here:
>>>> 
>>>> 1) It doesn’t handle optional read/write properties at all, because the 
>>>> setter signature would be different. Perhaps some future lens design would 
>>>> make this possible. For now, the workaround would have to be importing the 
>>>> setter as a second optional closure property, I guess. (The current system 
>>>> is similarly broken).
>>> 
>>> I was only thinking about methods, not properties.  :)  How common are 
>>> optional, writeable property requirements?  I don’t have a good guess off 
>>> the top of my head, but my hunch is that they are not that common.
>> 
>> They are *very* rare. Aside from UITextInputTraits 
>> <https://developer.apple.com/library/ios/documentation/UIKit/Reference/UITextInputTraits_Protocol/>,
>>  I see three in OS X and four in iOS.
>> 
>>>> 2) For an @objc protocol, you won’t actually be able to fully implement 
>>>> the optional closure property with a property of optional type, because 
>>>> “return nil” in the getter is not the same as “-respondsToSelector: 
>>>> returns false”. Indeed, the getter result type/setter parameter type 
>>>> should be non-optional, so we would (at best) need a special rule that 
>>>> optional closure properties of @objc protocols can only be implemented by 
>>>> non-optional properties of closure type or by methods.
>>> 
>>> This is related to why I asked about feasibility.  I know that “return nil” 
>&g

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Douglas Gregor via swift-evolution]

> On Apr 15, 2016, at 3:55 PM, Matthew Johnson <matt...@anandabits.com> wrote:
> 
> 
>> On Apr 13, 2016, at 11:42 AM, Douglas Gregor <dgre...@apple.com 
>> <mailto:dgre...@apple.com>> wrote:
>> 
>>> 
>>> On Apr 11, 2016, at 10:30 AM, Matthew Johnson <matt...@anandabits.com 
>>> <mailto:matt...@anandabits.com>> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>>> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> 
>>>>> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>> One could perhaps work around (a), (b), and (d) by allowing compound 
>>>>> (function-like) names like tableView(_:viewFor:row:) for properties, and 
>>>>> work around (c) by allowing a method to satisfy the requirement for a 
>>>>> read-only property, but at this point you’ve invented more language hacks 
>>>>> than the existing @objc-only optional requirements. So, I don’t think 
>>>>> there is a solution here.
>>>> 
>>>> To me, compound names for closure properties and satisfying property 
>>>> requirements with methods aren't hacks, they're missing features we ought 
>>>> to support anyway. I strongly prefer implementing those over your proposed 
>>>> solution. It sounds to me like a lot of people using optional protocol 
>>>> requirements *want* the locality of control flow visible in the caller, 
>>>> for optimization or other purposes, and your proposed solution makes this 
>>>> incredibly obscure and magical.
>>> 
>>> Do you have the same thought for optional closure properties?  If so and 
>>> heightForRow was an optional closure property it would satisfy all use 
>>> cases elegantly.  It could have a default implementation that returns nil.  
>>> When non-uniform heights are required a normal method implementation can be 
>>> provided.  Delegates that have uniform row heights some of the time, but 
>>> not all of the time, would also be supported by implementing the property.
>> 
>> There are still some issues here:
>> 
>> 1) It doesn’t handle optional read/write properties at all, because the 
>> setter signature would be different. Perhaps some future lens design would 
>> make this possible. For now, the workaround would have to be importing the 
>> setter as a second optional closure property, I guess. (The current system 
>> is similarly broken).
> 
> I was only thinking about methods, not properties.  :)  How common are 
> optional, writeable property requirements?  I don’t have a good guess off the 
> top of my head, but my hunch is that they are not that common.

They are *very* rare. Aside from UITextInputTraits 
<https://developer.apple.com/library/ios/documentation/UIKit/Reference/UITextInputTraits_Protocol/>,
 I see three in OS X and four in iOS.

>> 2) For an @objc protocol, you won’t actually be able to fully implement the 
>> optional closure property with a property of optional type, because “return 
>> nil” in the getter is not the same as “-respondsToSelector: returns false”. 
>> Indeed, the getter result type/setter parameter type should be non-optional, 
>> so we would (at best) need a special rule that optional closure properties 
>> of @objc protocols can only be implemented by non-optional properties of 
>> closure type or by methods.
> 
> This is related to why I asked about feasibility.  I know that “return nil” 
> is not that same as a “respondsToSelector:” implementation that returns false 
> if the property was implemented to return nil.  Some magic would need to 
> handle that translation to make it work with existing Objective-C protocols.  
> This would automate what I have done in Objective-C several times by 
> implementing respondsToSelector manually to hide protocol method 
> implementations when necessary.  
> 
> The advantage of going this route is that Swift implementations of the legacy 
> Cocoa protocols will still function as expected in Cocoa while fitting the 
> Swift model much better than optional protocol requirements.

Both Joe’s suggestion and my proposal need hackery to do the right thing for 
Objective-C interoperability, and both are feasible. I feel like my proposal is 
more honest about the hackery going on :)

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

[Douglas Gregor via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md

Hello Swift Community,

The review of SE-0064 "Referencing the Objective-C selector of property getters 
and setters” ran from April 7...12, 2016. The proposal is accepted. Feedback 
was light but positive, with many considering this to effectively be an 
obviously-missing piece of the #selector proposal (SE-0022 
).

We welcome an implementation of this proposal. I’ve filed a ticket at

https://bugs.swift.org/browse/SR-1239

to track the implementation.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0062: Referencing Objective-C key-paths

[Douglas Gregor via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md

Hello Swift Community,

The review of SE-0062 "Referencing Objective-C key-paths” ran from April 
7...12, 2016. The proposal is accepted, with one adjustment to the handling of 
collections: rather than support any SequenceType as a collection, the core 
team wants a narrower rule for only the primary Cocoa collection types 
(NSArray, NSDictionary, NSSet) and their Swift-bridged equivalents (Array, 
Dictionary, Set), due to implementation concerns.

Feedback on this proposal was generally positive, and the proposal fits well 
with #selector (SE-0022 
).
 There was some discussion during the review of extending the proposal to more 
strongly-typed key paths. However, the core team felt that this feature is 
important for Swift 3 to support the renaming of Objective-C APIs in Swift 
(SE-0005 
),
 and that such a significant increase in scope would jeopardize the feature for 
Swift 3.

We welcome an implementation of this proposal. I’ve filed a ticket at

We welcome an implementation of this proposal. I’ve filed a ticket at

to track the implementation.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Douglas Gregor via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md

Hello Swift Community,

The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance Member 
Implementations” ran from March 31...April 5, 2016. The proposal is accepted 
for Swift 3. 

We welcome an implementation of this proposal. I’ve filed a ticket at

https://bugs.swift.org/browse/SR-1236

to track the implementation.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0049: Move @noescape and @autoclosure to be type attributes

[Douglas Gregor via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md

Hello Swift Community,

The review of SE-0049 "Move @noescape and @autoclosure to be type attributes” 
ran from March 28...31, 2016. The proposal is accepted for Swift 3. Feedback on 
the proposal was light but positive.

We welcome an implementation of this proposal. I’ve file a ticket at

https://bugs.swift.org/browse/SR-1235

to track the implementation.

- Doug___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0048: Generic Type Aliases

[Douglas Gregor via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md

The review of SE-0048 “Generic Type aliases” ran from March 24…29, 2016. The 
proposal received overwhelmingly positive feedback and has now been implemented 
for Swift 3.

- Doug
 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Douglas Gregor via swift-evolution]

> On Apr 11, 2016, at 10:30 AM, Matthew Johnson <matt...@anandabits.com> wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> One could perhaps work around (a), (b), and (d) by allowing compound 
>>> (function-like) names like tableView(_:viewFor:row:) for properties, and 
>>> work around (c) by allowing a method to satisfy the requirement for a 
>>> read-only property, but at this point you’ve invented more language hacks 
>>> than the existing @objc-only optional requirements. So, I don’t think there 
>>> is a solution here.
>> 
>> To me, compound names for closure properties and satisfying property 
>> requirements with methods aren't hacks, they're missing features we ought to 
>> support anyway. I strongly prefer implementing those over your proposed 
>> solution. It sounds to me like a lot of people using optional protocol 
>> requirements *want* the locality of control flow visible in the caller, for 
>> optimization or other purposes, and your proposed solution makes this 
>> incredibly obscure and magical.
> 
> Do you have the same thought for optional closure properties?  If so and 
> heightForRow was an optional closure property it would satisfy all use cases 
> elegantly.  It could have a default implementation that returns nil.  When 
> non-uniform heights are required a normal method implementation can be 
> provided.  Delegates that have uniform row heights some of the time, but not 
> all of the time, would also be supported by implementing the property.

There are still some issues here:

1) It doesn’t handle optional read/write properties at all, because the setter 
signature would be different. Perhaps some future lens design would make this 
possible. For now, the workaround would have to be importing the setter as a 
second optional closure property, I guess. (The current system is similarly 
broken).

2) For an @objc protocol, you won’t actually be able to fully implement the 
optional closure property with a property of optional type, because “return 
nil” in the getter is not the same as “-respondsToSelector: returns false”. 
Indeed, the getter result type/setter parameter type should be non-optional, so 
we would (at best) need a special rule that optional closure properties of 
@objc protocols can only be implemented by non-optional properties of closure 
type or by methods.

> If we decide to favor this approach it would be really nice to be able to 
> import Cocoa delegate protocols this way.  Is that something that might be 
> feasible?


Yes. If we favor this approach, it should be fairly direct to make imported 
Objective-C protocols work this way.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Douglas Gregor via swift-evolution]

> On Apr 12, 2016, at 11:23 PM, David Hart via swift-evolution 
>  wrote:
> 
> I wouldn't mind driving the discussion and proposal, because I'd really like 
> to see a more complete generics system. Before I start, can David or Doug, or 
> someone else with a high-level view of the generics system tell me if this is 
> where to start or if there is another feature in the Complete Generics 
> manifesto which is more urgent first?

I think this is a fine feature to focus on. It’s useful, fits well in the 
system, and it’s scope is small enough that it’s achievable.

- Doug

> 
> David
> 
> On 13 Apr 2016, at 01:46, Jacob Bandes-Storch via swift-evolution 
> > wrote:
> 
>> I'm interested, but I'm by no means claiming I'll have enough time to drive 
>> any of the discussion/proposal/implementation. :-(
>> 
>> Jacob
>> 
>> On Tue, Apr 12, 2016 at 3:07 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> on Tue Apr 12 2016, Douglas Gregor > > wrote:
>> 
>> > On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution
>> > > wrote:
>> >
>> > Doug wrote this in the Completing Generics manifesto, under "Minor
>> > extensions":
>> >
>> > *Arbitrary requirements in protocols
>> >
>> > Currently, a new protocol can inherit from other protocols, 
>> > introduce
>> > new associated types, and add new conformance constraints to 
>> > associated
>> > types (by redeclaring an associated type from an inherited 
>> > protocol).
>> > However, one cannot express more general constraints. Building on 
>> > the
>> > example from “Recursive protocol constraints”, we really want the
>> > element type of a Sequence’s SubSequence to be the same as the 
>> > element
>> > type of the Sequence, e.g.,
>> >
>> > protocol Sequence {
>> > associatedtype Iterator : IteratorProtocol
>> > …
>> > associatedtype SubSequence : Sequence where 
>> > SubSequence.Iterator.Element
>> > == Iterator.Element
>> > }
>> >
>> > +1.
>> >
>> > To make it into Swift 3, would this feature require a proposal of its 
>> > own?
>> >
>> > Yes. Also, be wary that the syntax above potentially conflicts with the 
>> > syntax
>> > discussed as "moving the where clauses”:
>> >
>> > http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058 
>> > 
>> >
>> > How feasible would it be to implement on top of the current system?
>> >
>> > Definitely! The archetype builder would need to learn to check these extra 
>> > where
>> > clauses, and one would need to be sure that the constraint solver is 
>> > picking
>> > them up as well.
>> 
>> By the way, having this would enable us to massively simplify the
>> standard library, and potentially lots of user-written generic code,
>> too.  So I'm very excited that someone's interested!
>> 
>> --
>> Dave
>> 
>> ___
>> 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 
>> 
> ___
> 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

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Douglas Gregor via swift-evolution]

> On Apr 12, 2016, at 11:19 PM, David Hart <da...@hartbit.com> wrote:
> 
> Hi Doug,
> 
> I've read the discussion about moving the where clause to the right of 
> declarations (which I full-heartedly approve) but I don't see how it would 
> have any impact on the syntax of associated types requirements.

I think “arbitrary requirements in protocols” doesn’t necessarily require them 
to be attached to an associated type. For example, Collection might require 
that the SubSequence type itself be a Collection:

protocol Collection : Sequence {
  associatedtype SubSequence : Collection
} 

Why did we have to declare the SubSequence associated type again (since it’s 
already down in SubSequence) just to make it conform to Collection. In fact, 
why are we even allowed to declare a redundant associated type, which we know 
is defined in Sequence and will have to be the same? Seems to me that we just 
want a where clause to add the constraint, e.g.,

protocol Collection : Sequence {
  where SubSequence : Collection
} 

which of course would conflict with moving where clauses later, e.g.,

protocol Collection : Sequence {
  func foo() // is the following where clause part of foo() or part of 
Collection?
  where SubSequence : Collection
} 


- Doug


> 
> David
> 
> On 12 Apr 2016, at 19:07, Douglas Gregor via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Doug wrote this in the Completing Generics manifesto, under "Minor 
>>> extensions":
>>> 
>>> *Arbitrary requirements in protocols
>>>  
>>> Currently, a new protocol can inherit from other protocols, introduce new 
>>> associated types, and add new conformance constraints to associated types 
>>> (by redeclaring an associated type from an inherited protocol). However, 
>>> one cannot express more general constraints. Building on the example from 
>>> “Recursive protocol constraints”, we really want the element type of a 
>>> Sequence’s SubSequence to be the same as the element type of the Sequence, 
>>> e.g.,
>>>  
>>> protocol Sequence {
>>> associatedtype Iterator : IteratorProtocol
>>> …
>>> associatedtype SubSequence : Sequence where 
>>> SubSequence.Iterator.Element == Iterator.Element
>>> }
>>> 
>>> 
>>> +1.
>>> 
>>> To make it into Swift 3, would this feature require a proposal of its own?
>> 
>> Yes. Also, be wary that the syntax above potentially conflicts with the 
>> syntax discussed as "moving the where clauses”:
>> 
>>  
>> http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058 
>> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058>
>> 
>> 
>>> How feasible would it be to implement on top of the current system?
>> 
>> Definitely! The archetype builder would need to learn to check these extra 
>> where clauses, and one would need to be sure that the constraint solver is 
>> picking them up as well.
>> 
>>  - Doug
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Douglas Gregor via swift-evolution]

> On Apr 11, 2016, at 10:15 AM, Joe Groff <jgr...@apple.com> wrote:
> 
> 
>> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> One could perhaps work around (a), (b), and (d) by allowing compound 
>> (function-like) names like tableView(_:viewFor:row:) for properties, and 
>> work around (c) by allowing a method to satisfy the requirement for a 
>> read-only property, but at this point you’ve invented more language hacks 
>> than the existing @objc-only optional requirements. So, I don’t think there 
>> is a solution here.
> 
> To me, compound names for closure properties and satisfying property 
> requirements with methods aren't hacks, they're missing features we ought to 
> support anyway. I strongly prefer implementing those over your proposed 
> solution.

I haven’t seen these come up in any discussion that wasn’t about mapping 
Objective-C optional requirements to something else in Swift. What other use 
cases are you envisioning?

>  It sounds to me like a lot of people using optional protocol requirements 
> *want* the locality of control flow visible in the caller, for optimization 
> or other purposes,

Most of the requests I see for this feature are of the form “this works for 
@objc protocols, so it should work everywhere,” and most of the push-back I’ve 
seen against removing ‘optional’ is a concern over interaction with Cocoa. I 
haven’t gotten the sense that optional requirements are considered to be the 
best design for any particular task in Swift.

> and your proposed solution makes this incredibly obscure and magical.


That’s fair. The mechanism I’m talking about *is* a bit hard to explain—we 
would need to rely on the diagnostic for cases where one tries to call a method 
that is caller-defaulted from Swift code, e.g.,

error: method ‘foo(bar:wibble:)’ may not be implemented by the adopting 
class; add a default implementation via an extension to protocol ‘Foo'

This would only affect optional requirements of protocols imported from 
Objective-C. My hypothesis is that those just aren’t used in Swift app code.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Douglas Gregor via swift-evolution]

> On Apr 8, 2016, at 8:53 AM, Shawn Erickson <shaw...@gmail.com> wrote:
> 
> I want to reiterate that I have objective-c code, others have objc code, and 
> the cocoa, etc. frameworks have code that depend on optional protocol for 
> things like (but not limited to) delegates. This is of course obvious but 
> what seems to get lost in the discussion is that you can't always replace the 
> non-existence of an implementation of an optional protocol method with a 
> default implementation.
> 
> I have code that probes a delegate when registered and based on the what 
> subset of the optional protocol methods it handles configures its runtime 
> state to optimize itself to that reality. For example it may avoid allocating 
> and maintaining potentially complex state if one or more methods are not 
> implemented by the delegate (since no one is interested in it). If we just 
> blindly provide default  implementation for optional methods then this 
> optimization couldn't take place.
> 
> I know others - including I believe Apple framework code - do similar 
> optimizations based on what methods an object implements.

Just to be very clear (which I think my initial post wasn’t) my proposal does 
*not* break this optimization when a Swift class is conforming to an @objc 
protocol: even if a default is present, it won’t be visible to the Objective-C 
runtime at all.

My proposal *does* make it significantly harder to implement a check for “did 
the type implement this method?”, because one will effectively have to use 
-respondsToSelector:. For Cocoa-defined delegates, that doesn’t matter at all: 
apps generally implement requirements of delegates/data sources, but almost 
never go through the protocol to use those methods/properties. It’s the 
frameworks that do the calling, and of course they’re already using 
-respondsToSelector: checks.

The main effect is in Swift code that uses @objc optionals and tests for the 
absence of an implementation to perform some optimization. The tenor of the 
previous thread seems to indicate that this probably isn’t common, because 
there are probably better ways to model these cases in Swift—whether it’s with 
multiple protocols or something that specifically describes the policy (e.g., 
http://thread.gmane.org/gmane.comp.lang.swift.evolution/13347/focus=13480).


> I think we should maintain the optional concept in support of bridging 
> existing objc code into swift (confined to @objc)... unless a way to bridge 
> things can be defined that avoids the loss of optimization potential I 
> outlined above.

The direction I’m trying to go is not to have half of a feature—something that 
seems like it should be general, but is tied to @objc—in the language. We get a 
very large number of requests to make “optional” work for Swift protocols, 
because it’s a confusing limitation and there is a ton of overlap with default 
implementations. It would be far better to remove the feature.

> 
> Optional protocols don't need to be expanded into Swift itself since I 
> believe alternate methods and patterns exists to solve the same type of need.

Given that you don’t feel that optional requirements need to work in Swift-only 
protocols, and what I’ve said above about compatibility with Cocoa, do you 
still think we need to keep ‘@objc optional’ as a notion in the language?

    - Doug

> 
> -Shawn
> 
> On Thu, Apr 7, 2016 at 5:12 PM Douglas Gregor via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Hi all,
> 
> Optional protocol requirements in Swift have the restriction that they only 
> work in @objc protocols, a topic that’s come up a number 
> <http://thread.gmane.org/gmane.comp.lang.swift.devel/1316/focus=8804> of 
> times 
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/13347/focus=13480>. 
> The start of these threads imply that optional requirements should be 
> available for all protocols in Swift. While this direction is implementable, 
> each time this is discussed there is significant feedback that optional 
> requirements are not a feature we want in Swift. They overlap almost 
> completely with default implementations of protocol requirements, which is a 
> more general feature, and people seem to feel that designs based around 
> default implementations and refactoring of protocol hierarchies are overall 
> better.
> 
> The main concern with removing optional requirements from Swift is their 
> impact on Cocoa: Objective-C protocols, especially for delegates and data 
> sources, make heavy use of optional requirements. Moreover, there are no 
> default implementations for any of these optional requirements: each caller 
> effectively checks for the presence of the method explicitly, and implements 
> its own logic if the method

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

[Douglas Gregor via swift-evolution]

> On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Doug wrote this in the Completing Generics manifesto, under "Minor 
> extensions":
> 
> *Arbitrary requirements in protocols
>  
> Currently, a new protocol can inherit from other protocols, introduce new 
> associated types, and add new conformance constraints to associated types (by 
> redeclaring an associated type from an inherited protocol). However, one 
> cannot express more general constraints. Building on the example from 
> “Recursive protocol constraints”, we really want the element type of a 
> Sequence’s SubSequence to be the same as the element type of the Sequence, 
> e.g.,
>  
> protocol Sequence {
> associatedtype Iterator : IteratorProtocol
> …
> associatedtype SubSequence : Sequence where 
> SubSequence.Iterator.Element == Iterator.Element
> }
> 
> 
> +1.
> 
> To make it into Swift 3, would this feature require a proposal of its own?

Yes. Also, be wary that the syntax above potentially conflicts with the syntax 
discussed as "moving the where clauses”:


http://thread.gmane.org/gmane.comp.lang.swift.evolution/13886/focus=14058


> How feasible would it be to implement on top of the current system?

Definitely! The archetype builder would need to learn to check these extra 
where clauses, and one would need to be sure that the constraint solver is 
picking them up as well.

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0062 Referencing Objective-C key-paths

[Douglas Gregor via swift-evolution]

> On Apr 7, 2016, at 9:34 PM, Les Pruszynski via swift-evolution 
>  wrote:
> 
> This is my first post on this list so please bear with me.
> 
> I very much like this proposal but what bothers me is this doubling of 
> valueForKeyPath(#keyPath(xxx) in the signature of the function.
> 
> chris.valueForKeyPath(#keyPath(Person.bestFriend.lastName)) // => Groff
> chris.valueForKeyPath(#keyPath(Person.friends.firstName)) // => ["Joe", 
> "Douglas"]
> 
> I’m not sure whether the form below is actually possible. For me it reads 
> more naturally and is more consistent with “Modern Swift” as far as I know.
> 
> chris.valueFor(#keyPath(Person.friends.firstName)) // => ["Joe", "Douglas”]
> or maybe
> chris.valueOf(#keyPath(Person.friends.firstName)) // => ["Joe", "Douglas”]
> 

If key paths were some stronger type (as Brent is suggesting), we could do 
this. However, because key paths are just Strings, we need to compensate for 
weak type information 
, 
so valueForKeyPath should retain it’s currently name despite the redundancy in 
many use sites with #keyPath.

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

[Douglas Gregor via swift-evolution]

Hi all,

Optional protocol requirements in Swift have the restriction that they only 
work in @objc protocols, a topic that’s come up a number 
 of times 
. 
The start of these threads imply that optional requirements should be available 
for all protocols in Swift. While this direction is implementable, each time 
this is discussed there is significant feedback that optional requirements are 
not a feature we want in Swift. They overlap almost completely with default 
implementations of protocol requirements, which is a more general feature, and 
people seem to feel that designs based around default implementations and 
refactoring of protocol hierarchies are overall better.

The main concern with removing optional requirements from Swift is their impact 
on Cocoa: Objective-C protocols, especially for delegates and data sources, 
make heavy use of optional requirements. Moreover, there are no default 
implementations for any of these optional requirements: each caller effectively 
checks for the presence of the method explicitly, and implements its own logic 
if the method isn’t there.

A Non-Workable Solution: Import as optional property requirements
One suggestion that’s come up to map an optional requirement to a property with 
optional type, were “nil” indicates that the requirement was not satisfied. For 
example, 

@protocol NSTableViewDelegate
@optional
- (nullable NSView *)tableView:(NSTableView *)tableView 
viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row;
- (CGFloat)tableView:(NSTableView *)tableView heightOfRow:(NSInteger)row;
@end

currently comes in as

@objc protocol NSTableViewDelegate {
  optional func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int) -> 
NSView?
  optional func tableView(_: NSTableView, heightOfRow: Int) -> CGFloat
}

would come in as:

@objc protocol NSTableViewDelegate {
  var tableView: ((NSTableView, viewFor: NSTableColumn, row: Int) -> NSView?)? 
{ get }
  var tableView: ((NSTableView, heightOfRow: Int) -> CGFloat)? { get }
}

with a default implementation of “nil” for each. However, this isn’t practical 
for a number of reasons:

a) We would end up overloading the property name “tableView” a couple dozen 
times, which doesn’t actually work.

b) You can no longer refer to the member with a compound name, e.g., 
“delegate.tableView(_:viewFor:row:)” no longer works, because the name of the 
property is “tableView”.

c) Implementers of the protocol now need to provide a read-only property that 
returns a closure. So instead of

class MyDelegate : NSTableViewDelegate {
  func tableView(_: NSTableView, viewFor: NSTableColumn, row: Int) -> NSView? { 
… }
}

one would have to write something like

class MyDelegate : NSTableViewDelegate {
  var tableView: ((NSTableView, viewFor: NSTableColumn, row: Int) -> NSView?)? 
= {
… except you can’t refer to self in here unless you make it lazy ...
  }
}

d) We’ve seriously considered eliminating argument labels on function types, 
because they’re a complexity in the type system that doesn’t serve much of a 
purpose.

One could perhaps work around (a), (b), and (d) by allowing compound 
(function-like) names like tableView(_:viewFor:row:) for properties, and work 
around (c) by allowing a method to satisfy the requirement for a read-only 
property, but at this point you’ve invented more language hacks than the 
existing @objc-only optional requirements. So, I don’t think there is a 
solution here.

Proposed Solution: Caller-side default implementations

Default implementations and optional requirements differ most on the caller 
side. For example, let’s use NSTableView delegate as it’s imported today:

func useDelegate(delegate: NSTableViewDelegate) {
  if let getView = delegate.tableView(_:viewFor:row:) { // since the 
requirement is optional, a reference to the method produces a value of optional 
function type
// I can call getView here
  }

  if let getHeight = delegate.tableView(_:heightOfRow:) {
// I can call getHeight here
  }
}

With my proposal, we’d have some compiler-synthesized attribute (let’s call it 
@__caller_default_implementation) that gets places on Objective-C optional 
requirements when they get imported, e.g.,

@objc protocol NSTableViewDelegate {
  @__caller_default_implementation func tableView(_: NSTableView, viewFor: 
NSTableColumn, row: Int) -> NSView?
  @__caller_default_implementation func tableView(_: NSTableView, heightOfRow: 
Int) -> CGFloat
}

And “optional” disappears from the language. Now, there’s no optionality left, 
so our useDelegate example tries to just do correct calls:

func useDelegate(delegate: NSTableViewDelegate) -> NSView? {
  let view = delegate.tableView(tableView, viewFor: column, row: row)
  let height = delegate.tableView(tableView, heightOfRow: row)
}

Of course, the code above will fail if the 

[swift-evolution] [Review] SE-0064: Referencing the Objective-C selector of property getters and setters

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0064 "Referencing the Objective-C selector of property getters 
and setters" begins now and runs through April 12, 2016. The proposal is 
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md
Reply text

Other replies
 What goes 
into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

Doug Gregor

Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0062: Referencing Objective-C key-paths

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0062 “Referencing Objective-C key-paths" begins now and runs 
through April 12, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md
Reply text

Other replies
 What goes 
into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

-Doug Gregor

Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] deployment targets and frameworks

[Douglas Gregor via swift-evolution]

> On Apr 5, 2016, at 4:04 PM, Drew Crawford  wrote:
> 
> 
>> On Apr 5, 2016, at 12:06 PM, Douglas Gregor > > wrote:
>> 
>> I would not want this to be implicit behavior: it should be recorded in the 
>> source with, e.g.,
>> 
>>  @availability(iOS: 9.3) import YourCustomFramework
>> 
>> so that it is clear that the imported declarations are only available on iOS 
>> 9.3 or newer.
>> 
>>  - Doug
> 
> Would you promote using this syntax for the Apple frameworks as well?


> A major goal for me is syntax consistency between Apple's and third-party 
> frameworks.  That way the knowledge of how to use one transfers to the other, 
> and we ensure people with fresh ideas about how to build frameworks are not 
> burdened with educating application developers about "novel" import syntax.

Apple frameworks tend to have ail their various classes and other APIs 
annotated with availability attributes, so I wouldn’t expect to need this 
import syntax for any of those. Really, this syntax is a shorthand for “treat 
the imported library as if the author had put this availability annotation on 
all of its public APIs”. If your goal is consistency between Apple frameworks 
and other frameworks, I don’t think this is the way to go.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Douglas Gregor via swift-evolution]

> On Apr 5, 2016, at 11:36 AM, Russ Bishop  wrote:
> 
> 
>> On Apr 5, 2016, at 10:14 AM, Douglas Gregor > > wrote:
>>> 
 Suppose there is also a subclass (say, ObjCMutableFizzer), and we have 
 this Objective-C API:
 
ObjCMutableFizzer* mutableFizzer;
 
 Which of these represents how it is imported?
 
var myMutableFizzer: ObjCMutableFizzer
var myMutableFizzer: Fizzer
>>> 
>>> The intention there is that it imports as the bridged type so the latter.
>> 
>> I disagree here: ObjCFizzer is bridged, not ObjCMutableFizzer, so it would 
>> be the former.
>> 
> 
> Hmmm… So all subclasses are hidden as far as the interface is concerned (and 
> the ambiguity rules)? I’m fine with that, it seems like it suites the class 
> cluster approach just fine.

Not “hidden”; they’re accessible and not bridged.

>> 
 
 * * *
 
 Foundation classes can sometimes be bridged using an upcast (a plain 
 `as`), which cannot crash. Is this possible with ObjectiveCBridgeable? If 
 so, how? If not, will Foundation classes lose that ability?
 
 If this feature can't be expressed with ObjectiveCBridgeable, is this seen 
 as a shortcoming we should try to overcome, or the proper design? I worry 
 about the unnecessary proliferation of exclamation points, especially 
 since many style guides strongly discourage them, which will turn this 
 into an unnecessary proliferation of unnecessary `if let`s.
>>> 
>>> This would not be possible. This sort of bridging only works with special 
>>> magic types because they are known to always succeed. There is no condition 
>>> under which Swift will fail to convert String to NSString. The 
>>> compiler/runtime can’t prove that about any arbitrary type.
>> 
>> We can bridge from, e.g., Fizzer to ObjCFizzer via “as Fizzer” using the 
>> entry-point
>> 
>>  func bridgeToObjectiveC() -> ObjectiveCType
>> 
> 
> It does seem strange that this is asymmetrical but I don’t know that it is 
> worth the complexity to introduce an extended protocol to declare a type has 
> a bi-directional always-succeeds bridging conversion.

It is a little odd; we have isBridgedToObjectiveC and bridgeToObjectiveC, where 
we could possibly have the latter produce an ObjectiveCType? and remove the 
former.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

[Douglas Gregor via swift-evolution]

> On Apr 4, 2016, at 9:54 PM, Russ Bishop via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 4, 2016, at 9:22 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md
>> 
>> There are a number of things I'm not really clear on.
>> 
>> * * *
>> 
>> Consider this Objective-C API:
>> 
>>  ObjCFizzer* myFizzer;
>> 
>> Which of these represents how it is imported?
>> 
>>  var myFizzer: ObjCFizzer
>>  var myFizzer: Fizzer
> 
> The latter. The idea is that the importer sees the bridged type is available 
> and substitutes it on all imported signatures. The actual mechanics of that 
> will involve some generated code (thunk) to call the protocol. I could update 
> the proposal to include what the body of that thunk might look like but it 
> didn’t seem terribly interesting.

Right. There will be some thunking the compiler does.

>> Suppose there is also a subclass (say, ObjCMutableFizzer), and we have this 
>> Objective-C API:
>> 
>>  ObjCMutableFizzer* mutableFizzer;
>> 
>> Which of these represents how it is imported?
>> 
>>  var myMutableFizzer: ObjCMutableFizzer
>>  var myMutableFizzer: Fizzer
> 
> The intention there is that it imports as the bridged type so the latter.

I disagree here: ObjCFizzer is bridged, not ObjCMutableFizzer, so it would be 
the former.

> 
> 
>> 
>> On the basis of NSArray and friends, I assume they come across like this:
>> 
>>  var myFizzer: Fizzer
>>  var myMutableFizzer: ObjCMutableFizzer
>> 
>> Is that correct?
> 
> No

I would have said “yes" ;)

>> 
>> * * *
>> 
>> Foundation classes can sometimes be bridged using an upcast (a plain `as`), 
>> which cannot crash. Is this possible with ObjectiveCBridgeable? If so, how? 
>> If not, will Foundation classes lose that ability?
>> 
>> If this feature can't be expressed with ObjectiveCBridgeable, is this seen 
>> as a shortcoming we should try to overcome, or the proper design? I worry 
>> about the unnecessary proliferation of exclamation points, especially since 
>> many style guides strongly discourage them, which will turn this into an 
>> unnecessary proliferation of unnecessary `if let`s.
> 
> This would not be possible. This sort of bridging only works with special 
> magic types because they are known to always succeed. There is no condition 
> under which Swift will fail to convert String to NSString. The 
> compiler/runtime can’t prove that about any arbitrary type.

We can bridge from, e.g., Fizzer to ObjCFizzer via “as Fizzer” using the 
entry-point

func bridgeToObjectiveC() -> ObjectiveCType


> For bridging an Objective-C library into Swift, ideally all the APIs will be 
> annotated with SWIFT_BRIDGED so on import the Swift code won’t even be aware 
> the Objective-C type exists. All you’ll see in Swift is the appropriate Swift 
> types. This gives a library (say Photos.framework or UIKit) the chance to 
> provide truly native Swift types by shipping a module with combined Swift and 
> Objective-C code.
> 
> Similarly, going the other direction (an app with Objective-C and Swift code) 
> this proposal eliminates the need to deal with the Objective-C types in Swift.

The ObjC types will still exist (unless explicitly banned via 
NS_UNAVAILABLE_IN_SWIFT or similar), and can leak through in some cases (e.g., 
UnsafeMutablePointer).

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] deployment targets and frameworks

[Douglas Gregor via swift-evolution]

> On Apr 4, 2016, at 4:48 PM, Drew Crawford via swift-evolution 
>  wrote:
> 
> Suppose *Apple* ships a framework that is only supported in iOS 9.3.  As a 
> direct consequence, the framework is only #available in iOS 9.3 or later.
> 
> Suppose Jane links this framework into her iOS application.  The deployment 
> target for her application *can be any value*.  She sets the framework to be 
> weakly linked, and as long as the code that uses the Apple framework is 
> guarded by a 9.3 availability check, she can deploy back to 8.0, 7.0, etc.
> 
> Suppose *I* ship a custom framework that I only want to bother supporting for 
> iOS 9.3 users.  I'm not testing on old OS, I don't have CI on old OS, and 
> quite frankly I have no idea if it works.  And I'm not in the habit of 
> shipping code that wasn't even tested on my machine.  As a direct 
> consequence, I set my framework deployment target to 9.3.
> 
> Now Jane links this framework into her "deployment target 8.0" application.  
> She weakly links it and uses availability checks just like she did with the 
> Apple framework.  But this time the compiler says no:
> 
> error: module file's minimum deployment target is ios9.3 v9.3
> 
> Jane now has a set of bad choices:
> 
> 1.  She can not use my framework at all
> 2.  She can drop support for <9.3 entirely from her application in order to 
> use my framework
> 3.  She can convince me to support iOS 8, when I don't want to invest in the 
> QA and test time.
> 4.  She can convince me to set my deployment target to 8, try to find all my 
> public APIs, sprinkle `@available(iOS 9.3, *)` everywhere and hope I didn't 
> miss any.  Spoiler alert: that's what I did all afternoon.
> 
> This is too hard.  IMO Jane should be able to use my "9.3+" frameworks as 
> easily as she can use Apple's.
> 
> IMO, when Jane imports a "DT 9.3" framework, into her "DT 8.0" application, 
> it should A) import successfully, B) link weakly, and C) have 
> `@availability(9.3, *)` overlayed on the interface.

I would not want this to be implicit behavior: it should be recorded in the 
source with, e.g.,

@availability(iOS: 9.3) import YourCustomFramework

so that it is clear that the imported declarations are only available on iOS 
9.3 or newer.

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level (DECISION)

[Douglas Gregor via swift-evolution]

> On Apr 4, 2016, at 7:54 AM, Ilya Belenkiy  wrote:
> 
> Just to double check: do I need to do anything with the proposal? It sounds 
> like it was decided, and Doug will update the proposal, but I 'd like to make 
> sure that there is nothing to be done on my end.

I’ll handle the update to the proposal, thank you!

- Doug

> 
> On Fri, Apr 1, 2016 at 5:07 PM Ilya Belenkiy  > wrote:
> Great! Glad that we have a decision.
> 
> On Fri, Apr 1, 2016 at 4:34 PM Chris Lattner via swift-evolution 
> > wrote:
> On Mar 30, 2016, at 9:22 PM, Chris Lattner  > wrote:
> >
> > I’ve seen a number of concerns on this list about moduleprivate, and how it 
> > penalizes folks who want to explicitly write their access control.  I’ve 
> > come to think that there is yes-another possible path forward here (which I 
> > haven’t seen mentioned so far):
> >
> > public
> > internal
> > fileprivate
> > private
> 
> Hi Everyone,
> 
> Thank you for all of the input.  I know that this was a highly contentious 
> topic, that it is impossible to make everyone happy.  Getting the different 
> inputs and perspectives has been very very useful.
> 
> The core team met to discuss this, and settled on the list above: 
> public/internal/fileprivate/private.  This preserves the benefit of the 
> “fileprivate” concept that we have today in Swift, while aligning the 
> “private” keyword with common expectations of people coming to Swift. This 
> also makes “private" the "safe default” for cases where you don’t think about 
> which one you want to use, and this schema will cause minimal churn for 
> existing Swift code.
> 
> Thank you again for all of the input and discussion!
> 
> -Chris
> 
> btw, to be clear, this is *not* an April 1 joke.
> ___
> 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

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Douglas Gregor via swift-evolution]

> On Apr 4, 2016, at 9:20 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> Hmm, "emplace" looks like more or less a synonym for "install." I
> don't think it suggests that the object is being put in place of the
> subject.

It’s roughly a synonym. “emplaceUnion” is "putting the union into position". 
There is no other position than “self”.

> The latest example in the Oxford English Dictionary, from
> 2010, is:
> "Insurgents would hastily emplace victim-activated IEDs...after
> Pathfinder came through."
> Here, the IEDs are not taking the place of the insurgents.

I was going to comment about your choice of a terrorism-related example 
sentence, but the online OED *only* uses war-related examples for this verb.

    - Doug

> 
> On Mon, Apr 4, 2016 at 11:14 AM, Douglas Gregor via swift-evolution
> <swift-evolution@swift.org> wrote:
>> 
>> On Apr 3, 2016, at 1:56 PM, Shawn Erickson <shaw...@gmail.com> wrote:
>> 
>> 
>> 
>> On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson <shaw...@gmail.com> wrote:
>>> 
>>> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>>> What is your evaluation of the proposal?
>>>> 
>>>> I don't like "form" as a prefix. To me there is no difference between
>>>> `union` and `formUnion`: both sounds functional-style, and actually the
>>>> second one perhaps a bit more to my ears. There's basically two dictionary
>>>> definitions of "form":
>>>> 
>>>> 1. "bring together parts or combine to create (something)" which to me
>>>> implies a new value is created, and
>>>> 2. "make or fashion into a certain shape or form" which would imply that
>>>> the material you start with is transformed, which is apparently the 
>>>> intended
>>>> meaning and also the reverse meaning from the above.
>>>> 
>>>> I mean, doesn't this make sense as an API?
>>>> 
>>>>let donut = baker.formDonut(dough) // non-mutating
>>>> 
>>>> Perhaps instead of "form" we could use "become" as a prefix when the
>>>> operation is naturally described by a noun. That would seem less ambiguous
>>>> to me:
>>>> 
>>>>a.becomeUnion(b)
>>>>a.becomeIntersection(b)
>>>>a.becomeSuccessor(b)
>>>> 
>>>> It's a bit passive, but I find it fits well when the operation is a noun.
>>>> 
>>>> And there's no way the term lends itself to non-mutating cases without
>>>> things becoming nonsensical:
>>>> 
>>>>let donut = baker.becomeDonut(dough) // non-mutating?
>>> 
>>> 
>>> I also am having difficulty coming to terms with the use of "form" (I am a
>>> native English speaker). As you note "form" can imply the creation of
>>> something from parts (more like assembling a new thing) as well as the
>>> creation of something out of a material say a of block clay (more like
>>> molding something out of an existing thing). It doesn't seem clear cut to me
>>> to imply in place mutation.
>>> 
>>> Additionally my eyes / brain keep seeing "from" instead of "form". This
>>> type of issue is generally true with any short word made up of the same set
>>> of letters (made worse since "from" is more common in programming then
>>> "form"). The mind quickly narrows in on a set of possible words given the
>>> letters we see and then uses context to help get the correct one and/or
>>> additional visual parsing to understand the exact ordering of letters (more
>>> energy expended). Anyway since I keep seeing "from" instead of "form" I keep
>>> going in the direction of thinking it returns something made from the two
>>> (or more) items involved (not really sure why "from" goes that direction in
>>> my head, it could also go the in place direction).
>>> 
>>> I would prefer something other then "form" (note I just typed "from" by
>>> mistake)... I think your suggestion of "become" has merit.
>>> 
>>> y.becomeUnion(x) --reads to me as--> "y become union with x"
>>> y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
>>> y.becomeIntersection(x) --reads to me

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Douglas Gregor via swift-evolution]

> On Apr 1, 2016, at 5:37 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> Protocol requirements with default (no-op) implementations already satisfy 
>> that design goal, no?
> 
> Kind of. If I may steelman* optional members for a moment...
> 
> In cases where a default implementation would do, the default implementation 
> will usually also be the behavior you want for a nil instance, but there's no 
> convenient way to share logic between the two. For example, consider this:
> 
>   protocol UITableViewDelegate {
>   ...
>   func tableView(_ tableView: UITableView, 
> heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat
>   }
>   extension UITableViewDelegate {
>   func tableView(_ tableView: UITableView, 
> heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
>   return tableView.rowHeight
>   }
>   }
>   
>   class UITableView {
>   ...
>   private func addRow(at indexPath: NSIndexPath) {
>   ...
>   cell.size.height = delegate?.tableView(self, 
> heightForRowAtIndexPath: indexPath) ?? rowHeight
>   ...
>   }
>   ...
> 
> You have to duplicate the default logic both in the default implementation 
> and at the call site, but there is no convenient way to share it—the 
> extension method can't call into an expression at some call site, and 
> contrarily the call site can't invoke the default logic from the extension.

Interesting point.

> 
> If the method were optional, then optional chaining would solve this problem 
> for us:
> 
>   protocol UITableViewDelegate {
>   ...
>   optional func tableView(_ tableView: UITableView, 
> heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat
>   }
>   
>   class UITableView {
>   ...
>   private func addRow(at indexPath: NSIndexPath) {
>   ...
>   cell.size.height = delegate?.tableView?(self, 
> heightForRowAtIndexPath: indexPath) ?? rowHeight
>   ...
>   }
>   ...
> 
> This way, there is only one source of default behavior: the call site.

It’s “each" call site, not “the” call site. If there are multiple call sites, 
we’d presumably want to factor out the default behavior computation anyway.

> I'm also concerned by the thought of just how many sub-protocols we might end 
> up with. When I try to fully factor NSTableViewDelegate (as it currently 
> exists in the headers), I end up with ten protocols:
> 
>   NSTableViewDelegate
>   - tableView:willDisplayCell:forTableColumn:row:
> 
>   NSTableViewLayoutDelegate: NSTableViewDelegate
>   - tableView:heightOfRow:
> 
>   NSTableViewRowSelectionDelegate: NSTableViewDelegate
>   - tableView:shouldSelectRow:
>   - selectionShouldChangeInTableView:
>   - tableViewSelectionIsChanging:
>   - tableViewSelectionDidChange:
>   - tableView:shouldTrackCell:forTableColumn:row: (10.5)
>   - tableView:selectionIndexesForProposedSelection: (10.5)
> 
>   NSTableViewTypeSelectDelegate: NSTableViewDelegate (10.5)
>   - tableView:typeSelectStringForTableColumn:row:
>   - tableView:nextTypeSelectMatchFromRow:toRow:forString:
>   - tableView:shouldTypeSelectForEvent:withCurrentSearchString:
> 
>   NSTableViewToolTipDelegate: NSTableViewDelegate
>   - tableView:toolTipForCell:rect:tableColumn:row:mouseLocation:
> 
>   NSTableViewColumnDelegate: NSTableViewDelegate
>   - tableView:shouldEditTableColumn:row:
>   - tableView:shouldSelectTableColumn:
>   - tableView:mouseDownInHeaderOfTableColumn:
>   - tableView:didClickTableColumn:
>   - tableView:didDragTableColumn:
>   - tableViewColumnDidMove:
>   - tableViewColumnDidResize:
>   - tableView:sizeToFitWidthOfColumn: (10.6)
>   - tableView:shouldReorderColumn:toColumn: (10.6)
> 
>   NSTableViewCellExpansionDelegate: NSTableViewDelegate (10.5)
>   - tableView:shouldShowCellExpansionForTableColumn:row:
>   
>   NSTableViewCustomCellDelegate: NSTableViewDelegate (10.5)
>   - tableView:dataCellForTableColumn:row:
>   - tableView:isGroupRow:
> 
>   NSTableViewCellViewDelegate: NSTableViewDelegate (10.7)
>   - tableView:viewForTableColumn:row:
> 
>   NSTableViewRowViewDelegate: NSTableViewDelegate (10.7)
>   - tableView:rowViewForRow:
>   - tableView:didAddRowView:forRow:
>   - tableView:didRemoveRowView:forRow:
>   - tableView:rowActionsForRow:edge: (10.11)
> 
> Some of these are probably unnecessary; they could 

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Douglas Gregor via swift-evolution]

> On Apr 3, 2016, at 10:21 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> As the problem seems to be to eliminate having to write the extension with 
> all its duplication, I'd prefer a more general solution instead of 
> introducing the notion of an "optional" function: just make it possible to 
> write default implementations inline in a protocol definition. 

I think we can consider it as a given that, at some point, we’ll be able to 
write default implementations inline in the protocol definition. It’s not there 
now because we never got around to implementing it.

> Documenting the optionality can be done in the doc comment, maybe with a new 
> documentation keyword "default". Having "optional" in the code has no 
> additional value over a comment because the method is not optional in the 
> Obj-C sense and the proposal requires a default value. Therefore the presence 
> of "optional" has essentially no effect at all and is better moved into a 
> comment.

I tend to agree. ‘optional’ and the ‘= value’ syntax are fairly heavyweight 
language mechanisms for what is effectively documentation.

- Doug

> 
> -Thorsten 
> 
> Am 04.04.2016 um 00:13 schrieb Chris Lattner via swift-evolution 
> >:
> 
>> 
>>> On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov >> > wrote:
>>> 
 Protocol requirements with default (no-op) implementations already satisfy 
 that design goal, no?
>>> 
>>> Chris, as we've discussed in a thread that I think got forked from this one:
>>> 
>>> Yes, they do technically, but it would be nice to both:
>>> 
>>> 1) make it an obvious documented part of the signature, possibly including 
>>> the default return value
>>> 
>>> 2) possibly make it less verbose by getting rid of the explicitly spelled 
>>> out protocol extension
>> 
>> Right, but “more is worse” when it comes to language design.  Having a "more 
>> general" facility that greatly overlaps with a “more narrow” facility always 
>> makes us question whether it is worth the complexity to have both.
>> 
>> -Chris
>> 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Douglas Gregor via swift-evolution]

> On Apr 3, 2016, at 1:56 PM, Shawn Erickson  wrote:
> 
> 
> 
> On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson  > wrote:
> On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution 
> > wrote:
> > What is your evaluation of the proposal?
> 
> I don't like "form" as a prefix. To me there is no difference between `union` 
> and `formUnion`: both sounds functional-style, and actually the second one 
> perhaps a bit more to my ears. There's basically two dictionary definitions 
> of "form":
> 
> 1. "bring together parts or combine to create (something)" which to me 
> implies a new value is created, and
> 2. "make or fashion into a certain shape or form" which would imply that the 
> material you start with is transformed, which is apparently the intended 
> meaning and also the reverse meaning from the above.
> 
> I mean, doesn't this make sense as an API?
> 
> let donut = baker.formDonut(dough) // non-mutating
> 
> Perhaps instead of "form" we could use "become" as a prefix when the 
> operation is naturally described by a noun. That would seem less ambiguous to 
> me:
> 
> a.becomeUnion(b)
> a.becomeIntersection(b)
> a.becomeSuccessor(b)
> 
> It's a bit passive, but I find it fits well when the operation is a noun.
> 
> And there's no way the term lends itself to non-mutating cases without things 
> becoming nonsensical:
> 
> let donut = baker.becomeDonut(dough) // non-mutating?
> 
> I also am having difficulty coming to terms with the use of "form" (I am a 
> native English speaker). As you note "form" can imply the creation of 
> something from parts (more like assembling a new thing) as well as the 
> creation of something out of a material say a of block clay (more like 
> molding something out of an existing thing). It doesn't seem clear cut to me 
> to imply in place mutation.
> 
> Additionally my eyes / brain keep seeing "from" instead of "form". This type 
> of issue is generally true with any short word made up of the same set of 
> letters (made worse since "from" is more common in programming then "form"). 
> The mind quickly narrows in on a set of possible words given the letters we 
> see and then uses context to help get the correct one and/or additional 
> visual parsing to understand the exact ordering of letters (more energy 
> expended). Anyway since I keep seeing "from" instead of "form" I keep going 
> in the direction of thinking it returns something made from the two (or more) 
> items involved (not really sure why "from" goes that direction in my head, it 
> could also go the in place direction).
> 
> I would prefer something other then "form" (note I just typed "from" by 
> mistake)... I think your suggestion of "become" has merit.
> 
> y.becomeUnion(x) --reads to me as--> "y become union with x"
> y.formUnion(x) --read to me as--> "y from oops... y forming a union of x"
> y.becomeIntersection(x) --reads to me as--> "y become intersection with x"
> y.formIntersection(x) --read to me as--> "y from oops... y forming an 
> intersection with x"
> 
> After stepping away for a bit and looking at it from the POV of the API of 
> Set and not in the context of "y" I could read things in the abstract as...
> 
> "becomeUnion(with other:Self)" --> "I become a union with other"
> "formUnion(with other:Self)" --> "I form a union with other"
> 
> No clear winner to me however when used in code "become" still feels more 
> strongly mutating then "form": y.formUnion(with:x) or y.becomeUnion(with:x)
> 
> All in all the API would have mutating in front of it (at least for structs) 
> and it wouldn't have a return type. It would become clear fairly quickly as a 
> result (hence learned).
> 
> Just still not that happy with "form" but with use my mind would likely 
> quickly adapt.

I think the best English verb for this construction is “emplace”:

http://www.dictionary.com/browse/emplace

It means “to put in position”, and is always used with an object (the noun). 
It’s basically free from incorrect connotations because it’s obscure enough 
that most English speakers won’t know it, and is easily searchable for English- 
and non-English speakers alike.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0057: Importing Objective-C Lightweight Generics

[Douglas Gregor via swift-evolution]

> On Mar 31, 2016, at 2:40 PM, Andrew Bennett via swift-evolution 
>  wrote:
> 
> A few quick questions:
> 
>  * Is there a swift-evolution discussion thread? It's marked as TODO 
> currently.

Thanks for catching that. The thread is here:

http://thread.gmane.org/gmane.comp.lang.swift.evolution/2886

and I’ve updated the proposal with a link.

>  * What if you want your generic parameter to be a protocol instead of a 
> class?

The generic parameter itself can be required to conform to @objc protocols; the 
generic argument will be able to be an @objc protocol when the protocol 
conforms to itself.

- Doug

> 
> Thanks!
> Andrew Bennett
> 
> On Friday, 1 April 2016, Chris Lattner via swift-evolution 
> > wrote:
> Hello Swift community,
> 
> The review of "Importing Objective-C Lightweight Generics" begins now and 
> runs through April 5. The proposal is available here:
> 
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a 
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs 
Accordingly" begins now and runs through April 5, 2016. The proposal is 
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md
Reply text

Other replies
 What goes 
into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

Doug Gregor

Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions" begins 
now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
Reply text

Other replies
 What goes 
into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

Doug Gregor

Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Rewrite imported C function signatures

[Douglas Gregor via swift-evolution]

> On Mar 29, 2016, at 3:02 AM, Carlos Rodríguez Domínguez 
>  wrote:
> 
> Well, those proposal are more oriented towards annotating on C/Objective-C 
> files to allow a more sophisticate import into swift.

Yes, that is true. The philosophy behind these is that it’s better to 
automatically transform (via annotation) than manually wrap. Naturally, such 
transformations cannot handle everything.

> However, my proposal is to be able to directly annotate in swift, in order to 
> fix “old-style” imports, autogenerated code, etc. Please, allow me to repeat 
> myself, but consider the example of Core Data, in which model classes are 
> autogenerated from a graphical model that, for instance, lacks from enums’ 
> support. Therefore, if we use Core Data, then we can not use enums (Please, 
> take a look at the proposal named "[swift-evolution] Promote "primitive" 
> types to enums in extensions” in order to understand the intention of my 
> proposal as a whole).

There is a Clang attribute “swift_private” that prefixes the name of the 
declaration with “__” when it is imported into Swift. That way, you can wrap it 
with a different, more Swift-friendly, API that calls the “__” version.

Note that we do have a mechanism for annotating C/Objective-C APIs without 
modifying the headers, called “API notes”. It’s a simple YAML format that lets 
us describe various Clang attributes for entities, e.g., provide the Swift name 
for a given C function, mark a type as unavailable in Swift, and so on. It’s 
semi-documented in the swift-clang sources:


https://github.com/apple/swift-clang/blob/upstream-with-swift/lib/APINotes/APINotesYAMLCompiler.cpp

Essentially, one writes a YAML file for each module that needs annotation. API 
notes was designed as a transitional technology, so it’s a bit under-designed 
for a general-purpose tool. However, as we add more Clang-side annotations to 
improve the mapping of C/Objective-C APIs into Swift, it’s becoming more likely 
that API notes could/should grow into a more general mechanism for adapting 
existing C/Objective-C APIs to Swift without manually wrapping everything.

- Doug

>> El 28 mar 2016, a las 7:29, Douglas Gregor  escribió:
>> 
>> 
>>> On Mar 25, 2016, at 3:25 AM, Carlos Rodríguez Domínguez via swift-evolution 
>>>  wrote:
>>> 
>>> (Please, take a look at the proposal named "[swift-evolution] Promote 
>>> "primitive" types to enums in extensions” in order to understand the 
>>> intention of my proposal as a whole)
>>> 
>>> This proposal intends to allow developers to rewrite func signatures to 
>>> better adapt certain imported C functions to swift. For instance, the 
>>> function to create a POSIX socket has a C signature like this:
>>> 
>>> int socket(int domain, int type, int protocol);
>>> 
>>> In swift, it is currently imported like this:
>>> 
>>> func socket(_: Int32, _: Int32, _: Int32) -> Int32
>>> 
>>> However, by documentation, the first parameter should be one of a set of 
>>> constants beginning with PF_. The second one should be either SOCK_STREAM, 
>>> SOCK_DGRAM or SOCK_RAW. The third one should be a constant specifying the 
>>> protocol to use. Finally, the result could be either -1 (to indicate an 
>>> error) or another integer to indicate that a socket descriptor has been 
>>> returned.
>>> 
>>> As you can observe, that old-style signature is highly error prone, does 
>>> not comply with swift guidelines, it is difficult to understand, etc. My 
>>> opinion is that there should be some syntax to rewrite the signature to 
>>> avoid those issues. For instance, a possible syntax could be:
>>> 
>>> #mapsignature(socket(_:,_:,_:)->Int32)
>>> func socket(domain:SocketDomain, type:SocketType, protocol:SocketProtocol) 
>>> -> socket_t? {
>>> let result = socket(domain.rawValue, type.rawValue, protocol.rawValue)
>>> if result == -1 {
>>> return nil
>>> }
>>> else{
>>> return result
>>> }
>>> }
>>> 
>>> Note that the compiler should enforce a function call to the original 
>>> function that we are rewriting.
>>> 
>>> After a rewriting has happened, three options may be considered: either to 
>>> allow the original function to be called, to avoid the original function to 
>>> be called (through a compiler error with a fix-it) or to emit a warning, 
>>> advising the developer to adopt the rewritten signature.
>>> 
>>> Anyhow, this proposal should allow a greatly increased interoperability 
>>> between old style code and swift, which, in my opinion, is quite “forced” 
>>> right now.
>> 
>> FWIW, there have been a number of proposals in roughly this space, using 
>> annotations in the C headers to improve the mapping into Swift, including
>> 
>>  Import as member: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md
>>  Import Objective-C constants as Swift types: 
>> 

[swift-evolution] [Review] SE-0049 Move @noescape and @autoclosure to be type attributes

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0049 "Move @noescape and @autoclosure to be type attributes" 
begins now and runs through March 31, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md
Reply text

Other replies
 What goes 
into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

-Doug Gregor

Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Rewrite imported C function signatures

[Douglas Gregor via swift-evolution]

> On Mar 25, 2016, at 3:25 AM, Carlos Rodríguez Domínguez via swift-evolution 
>  wrote:
> 
> (Please, take a look at the proposal named "[swift-evolution] Promote 
> "primitive" types to enums in extensions” in order to understand the 
> intention of my proposal as a whole)
> 
> This proposal intends to allow developers to rewrite func signatures to 
> better adapt certain imported C functions to swift. For instance, the 
> function to create a POSIX socket has a C signature like this:
> 
> int socket(int domain, int type, int protocol);
> 
> In swift, it is currently imported like this:
> 
> func socket(_: Int32, _: Int32, _: Int32) -> Int32
> 
> However, by documentation, the first parameter should be one of a set of 
> constants beginning with PF_. The second one should be either SOCK_STREAM, 
> SOCK_DGRAM or SOCK_RAW. The third one should be a constant specifying the 
> protocol to use. Finally, the result could be either -1 (to indicate an 
> error) or another integer to indicate that a socket descriptor has been 
> returned.
> 
> As you can observe, that old-style signature is highly error prone, does not 
> comply with swift guidelines, it is difficult to understand, etc. My opinion 
> is that there should be some syntax to rewrite the signature to avoid those 
> issues. For instance, a possible syntax could be:
> 
> #mapsignature(socket(_:,_:,_:)->Int32)
> func socket(domain:SocketDomain, type:SocketType, protocol:SocketProtocol) -> 
> socket_t? {
>   let result = socket(domain.rawValue, type.rawValue, protocol.rawValue)
>   if result == -1 {
>   return nil
>   }
>   else{
>   return result
>   }
> }
> 
> Note that the compiler should enforce a function call to the original 
> function that we are rewriting.
> 
> After a rewriting has happened, three options may be considered: either to 
> allow the original function to be called, to avoid the original function to 
> be called (through a compiler error with a fix-it) or to emit a warning, 
> advising the developer to adopt the rewritten signature.
> 
> Anyhow, this proposal should allow a greatly increased interoperability 
> between old style code and swift, which, in my opinion, is quite “forced” 
> right now.

FWIW, there have been a number of proposals in roughly this space, using 
annotations in the C headers to improve the mapping into Swift, including

Import as member: 
https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md
Import Objective-C constants as Swift types: 
https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md
Better translation of Objective-C APIs into Swift (the swift_name 
attribute part, at least): 
https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

[Douglas Gregor via swift-evolution]

> On Mar 24, 2016, at 12:39 AM, Russ Bishop  wrote:
> 
> 
>>> I added a separate section on Ambiguity and what the behavior is. I think 
>>> you should be able to resolve ambiguity by casting so I went ahead and put 
>>> that in. An example:
>>> 
>>> //Bar and Foo bridge to SomeObjectiveCType
>>> struct Bar: ObjectiveCBridgeable { }
>>> struct Foo: ObjectiveCBridgeable { }
>>> 
>>> class API {
>>> let foo: Foo
>>> func objCVersionOfAFunction(obj: SomeObjectiveCType) -> 
>>> SomeObjectiveCType {
>>> let x = obj as! Bar
>>> // We've told the compiler which protocol impl to call
>>> return foo as! SomeObjectiveCType
>>> }
>>> }
>>> 
>>> Any problems with this approach? It makes handling the ambiguous or manual 
>>> bridging case relatively straightforward, though there may be objections to 
>>> using casting this way. [Be careful, I still mourn the loss of @conversion 
>>> so I’m biased :)]
>> 
>> 
>> The problem I have with allowing the ambiguity is that you can get weird 
>> behavior if Bar and Foo are in different modules: import just Bar’s module, 
>> and an Objective-C API mentioning SomeObjectiveCType gets bridged as a Bar. 
>> Import just Foo’s module, and an Objective-C API mentioning 
>> SomeObjectiveCType gets bridged as a Foo. Import both, and 
>> SomeObjectiveCType doesn’t get bridged! Now start splitting class 
>> hierarchies among those modules and you get some very inconsistent imports… 
>> that’s why I think this needs to be an error.
>> 
> 
> The rule requiring the Swift and @objc types to be in the same module 
> wouldn’t allow the scenario you describe.

Ah, yes.

> 
> I’m fine to say it’s an error as this isn’t a capability I have any use for 
> and it definitely could cause confusion. The rule could always be relaxed in 
> the future if there’s a convincing case for it. I’ll update the proposal to 
> make it an error again.

I’d rather call it an error and consider relaxing the rule if we find it’s very 
important later on.

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0048: Generic Type Aliases

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0048 "Generic Type Aliases" begins now and runs through March 
29, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
Reply text

Other replies
 What goes 
into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

Doug Gregor

Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

[Douglas Gregor via swift-evolution]

> On Mar 23, 2016, at 1:25 PM, Russ Bishop  wrote:
> 
> 
>> On Mar 23, 2016, at 11:49 AM, Douglas Gregor > > wrote:
>>> 
>>> I assume this is a static function to avoid allocating memory by calling 
>>> the initializer directly for each element, given the point is to defer the 
>>> work? I wonder if we can skip the static though and just call the 
>>> initializer directly? It would simplify the protocol a tiny bit.
>> 
>> From an implementation perspective, the entry point for an initializer in a 
>> protocol handles the allocation itself. It’s a static function because it 
>> was easy to implement that way and the actual definitions get a bit more 
>> flexibility in how they can come up with the object (since we don’t have 
>> factory initializers).
>  
> Good point about the factory initializers. I’ve been trying to keep the whole 
> “class cluster” situation in mind. I wonder if there should be an equivalent 
> static function for the conditional bridging for similar reasons?

I realize that my comment about factory initializers was a bit off: these are 
initializers on the value type, so there are no “class clusters” to be had. 
Sorry for the noise!

> I added a separate section on Ambiguity and what the behavior is. I think you 
> should be able to resolve ambiguity by casting so I went ahead and put that 
> in. An example:
> 
> //Bar and Foo bridge to SomeObjectiveCType
> struct Bar: ObjectiveCBridgeable { }
> struct Foo: ObjectiveCBridgeable { }
> 
> class API {
> let foo: Foo
> func objCVersionOfAFunction(obj: SomeObjectiveCType) -> 
> SomeObjectiveCType {
> let x = obj as! Bar
> // We've told the compiler which protocol impl to call
> return foo as! SomeObjectiveCType
> }
> }
> 
> Any problems with this approach? It makes handling the ambiguous or manual 
> bridging case relatively straightforward, though there may be objections to 
> using casting this way. [Be careful, I still mourn the loss of @conversion so 
> I’m biased :)]


The problem I have with allowing the ambiguity is that you can get weird 
behavior if Bar and Foo are in different modules: import just Bar’s module, and 
an Objective-C API mentioning SomeObjectiveCType gets bridged as a Bar. Import 
just Foo’s module, and an Objective-C API mentioning SomeObjectiveCType gets 
bridged as a Foo. Import both, and SomeObjectiveCType doesn’t get bridged! Now 
start splitting class hierarchies among those modules and you get some very 
inconsistent imports… that’s why I think this needs to be an error.

> 
> 
> `NSInteger` is already imported as `Int` from Objective-C right? I assume a 
> Clang attribute is specifying that somewhere but there wouldn’t be any 
> ambiguity on the Swift side during import.

It’s hardcoded, but it’s completely reasonable to imagine swift_bridge doing 
this some day.

> I could definitely see having an attribute to declare that this specific 
> parameter or return value should bridge to a specific Swift type (this 
> NSNumber should import as Int) but that’s a lot of work and may be worth a 
> separate proposal.

It would be hard for me to get motivated for such a proposal; at that point, 
just wrap up the API.

> It seems like the problem is going the other direction: you want to 
> materialize this parameter or whatever as `NSInteger` instead of the default 
> `NSNumber *` but only when directly bridged, not inside collections. There’s 
> no existing Objective-C header to tell us what to do. I’m not sure how we can 
> resolve this without a Swift attribute to tell the compiler because the 
> handling of it would be specific to each declaration. 

I don’t have a good answer here; today, it’s hardcoded.

> We could just  say that we aren’t going to let people have that level of 
> granularity. Then just introduce a BuiltInBridgeable protocol that supersedes 
> ObjectiveCBridgeable. A type adopting both will cause the compiler to prefer 
> the built-in protocol when generating a bridging header, but the collection 
> types can ignore that and just use ObjectiveCBridgeable. Presumably the 
> BuiltInBridgeable protocol would just have an associated type to indicate 
> that the bits are directly mapped to BuiltIn.Word or whatever.

Yes, that’s a reasonable approach. I don’t think it’s important for this 
proposal.

Two last comments came up, then I’d like to merge and schedule this:

(1) isBridgedToObjectiveC should be a computed property, not a function

(2) Please add something indicating that, while one can “as” cast between a 
value type and its bridged Objective-C type, there are no implicit conversions. 
We currently have implicit conversions from String -> NSString, Array -> 
NSArray, Dictionary -> NSDictionary, and Set -> NSSet, but we’re not 
happy about them and we don’t want to create more implicit conversions [*].

- Doug

[*] The fact that you mourn the loss of @conversion did not go 

[swift-evolution] [Accepted] SE-0044: Import as member

[Douglas Gregor via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md
 


The review of SE-0044 “Import as member” ran from March 15...22, 2016. The 
proposal has been *accepted*.

While there wasn’t a huge amount of feedback, all of the feedback received was 
positive. During the review period, the proposal was amended to support mapping 
getter/setter functions to subscripts (via the swift_name attribute) and to 
support importing instance members into an extension of an Objective-C protocol.

The core team has requested one small change to the proposal: that the 
“newValue” placeholder name introduced for the value parameter of subscript 
setters also be required for the value parameter of property setters, for 
consistency.

Cheers,
Doug Gregor
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

[Douglas Gregor via swift-evolution]

> On Mar 23, 2016, at 12:21 AM, Russ Bishop  wrote:
> 
>> 
>> On Mar 21, 2016, at 9:41 AM, Douglas Gregor > > wrote:
>> 
>> 
>>> On Mar 9, 2016, at 12:26 PM, Russ Bishop via swift-evolution 
>>> > wrote:
>>> 
>>> An official proposal PR has been opened on this: 
>>> https://github.com/apple/swift-evolution/pull/198 
>>> 
>>> 
>>> It includes clarifications, a few changes, and some better examples.
> 
>> 
>> /// Returns `true` iff instances of `Self` can be converted to
>> /// Objective-C.  Even if this method returns `true`, a given
>> /// instance of `Self._ObjectiveCType` may, or may not, convert
>> /// successfully to `Self`.
>> ///
>> /// A default implementation returns `true`.
>> @warn_unused_result
>> static func isBridgedToObjectiveC() -> Bool
>> It’s probably worth saying why someone might override this method: usually, 
>> it’s because the Swift type is generic and it only makes sense to bridge for 
>> some type arguments. Granted, there is no way to communicate this 
>> information to the compiler, which is a bit of a hole in the design. For 
>> example, Array only bridges to NSArray when T is itself representable in 
>> Objective-C. We really need conditional conformances to for this part of the 
>> feature to work properly.
> 
> I’ve added a section to the proposal to call out that it is intended for 
> conformance to be conditional in some cases (eg Array), and a small 
> explanation of what to do and a code example. It’s a bit unwieldy but 
> workable until we have conditional conformance.

Great. The suggestion to use an extension won’t actually work:

/// A default implementation returns `true`. If a Swift type is 
/// generic and should only be bridged for some type arguments,
/// provide alternate implementations in extensions 
/// and return `false` in those cases.
///
/// struct Foo: ObjectiveCBridgeable { ... }
/// extension Foo where T: NonBridgedType {
/// static func isBridgedToObjectiveC() -> Bool { 
/// return false 
/// }
/// }
because you don’t get dynamic dispatching based on T. Instead, you want one 
implementation of isBridgedToObjectiveC that does a dynamic check, e.g.,

struct Foo: ObjectiveCBridgeable {
  static func isBridgedToObjectiveC() -> Bool {
return !(T is NonBridgedType)
  }
}
  

>> 
>> /// Try to construct a value of the Self type from
>> /// an Objective-C object of the bridged class type.
>> ///
>> /// If the conversion fails this initializer returns `nil`.
>> init?(bridgedFromObjectiveC: ObjectiveCType)
>> FWIW, implementing this required a new “unconditional” entry point used by 
>> the compiler:
>> 
>>   static func _unconditionallyBridgeFromObjectiveC(source: _ObjectiveCType?)
>>   -> Self
>> 
>> It can get a default implementation, and should be a non-failable 
>> initializer.
> 
> I’ve updated the proposal to add this. The default implementation of 
> "init(unconditionallyBridgedFromObjectiveC: ObjectiveCType?)" just calls the 
> fallible initializer and aborts if anything goes wrong. Default 
> implementation of “unconditionallyBridgeFromObjectiveC(source: 
> ObjectiveCType?)” calls the initializer. My guess is most types will probably 
> just accept the default behavior.

Yes, I suspect you’re right that most types will use the default.

> 
> I assume this is a static function to avoid allocating memory by calling the 
> initializer directly for each element, given the point is to defer the work? 
> I wonder if we can skip the static though and just call the initializer 
> directly? It would simplify the protocol a tiny bit.

>From an implementation perspective, the entry point for an initializer in a 
>protocol handles the allocation itself. It’s a static function because it was 
>easy to implement that way and the actual definitions get a bit more 
>flexibility in how they can come up with the object (since we don’t have 
>factory initializers).

>>  4. The ObjectiveCType must be defined in Swift. If a -swift.h header is 
>> generated, it will include a SWIFT_BRIDGED()macro where the parameter 
>> indicates the Swift type with which the ObjectiveCType bridges. The macro 
>> will be applied to the ObjectiveCType and any subclasses.
>> 
>> This is unnecessarily restrictive, and eliminates the “make my Objective-C 
>> class bridge into a Swift value type” case that (for example) the compiler 
>> already does for String/Array/Dictionary/Set. I think there are two cases:
>> 
>>  (a) The ObjectiveCType is defined in Objective-C. It must be an 
>> Objective-C class with the attribute swift_bridge(“Bar”), where “Bar” is the 
>> name of the bridged Swift type.
>>  (b) The ObjectiveCType is defined in Swift, in which case it must 

Re: [swift-evolution] #selector and Void methods

[Douglas Gregor via swift-evolution]

> On Mar 23, 2016, at 10:14 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
>> 
>> On Mar 23, 2016, at 10:11, Joe Groff via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Mar 22, 2016, at 8:49 PM, Brent Royal-Gordon via swift-evolution 
>>> > wrote:
>>> 
>>> So, today is day 2 of Swift 2.2 being in the hands of mere mortals. This 
>>> evening, I walked into my weekly NSCoder Night meeting and talked to a 
>>> pretty experienced developer struggling with this:
>>> 
>>> class EditEventViewController: UIViewController {
>>> ...
>>> @IBAction func cancel(sender: AnyObject?) {
>>> cancel()
>>> }
>>> func cancel() {
>>> // actual canceling logic is here
>>> }
>>> }
>>> 
>>> class EditEventContainerViewController: UIViewController {
>>> ...
>>> func prepareForSegue(_ segue: UIStoryboardSegue, sender sender: 
>>> AnyObject?) {
>>> switch segue.identifier {
>>> ...
>>> let cancelButton = 
>>> UIBarButtonItem(barButtonSystemItem: .Cancel, target: nil, action: nil)
>>> cancelButton.target = vc
>>> cancelButton.action = #selector(vc.cancel)  
>>> // This is the problem line
>>> ...
>>> }
>>> }
>>> }
>>> 
>>> `vc.cancel` was, of course, ambiguous, and the SE-0021 `vc.cancel(_:)` 
>>> syntax can't select a Void function. I had to explain how to use `as Void 
>>> -> Void` to select the right version.
>>> 
>>> This is merely an anecdote, but I think it may end up being an issue.
>> 
>> Thanks for reporting this. I also saw this come up at least one other place:
>> 
>> https://twitter.com/bendodson/status/712208662933200896 
>> 
>> 
>> I wonder if it's worth making #selector(vc.cancel()) work. What do you 
>> think, Doug?
> 
> Very strong +1; I consider it a bug that we didn't have this already. It was 
> reported as SR-1016 .

Yes, I agree.

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Notes from Swift core team 2016-03-15 design discussion

[Douglas Gregor via swift-evolution]

> On Mar 16, 2016, at 5:27 PM, Alex Martini via swift-evolution 
>  wrote:
> 
> To help keep proposals moving forward, the Swift core team has set aside some 
> time specifically for design discussions of upcoming proposals.  Below are 
> some rough notes from the yesterday's discussion.
> 
> These are informal comments, intended to guide the proposals in directions 
> that draw constructive feedback. You are welcome to ignore the feedback, 
> agree with it, or disagree with it.  As always, the formal decision doesn't 
> happen until after the review period ends.
> 
> SE-0048 
> 
> This is straightforward and 95% implemented. The contentious point is that it 
> starts simple: you can’t add constraints to the type alias.
> 
> We want to avoid type-based metaprogramming.
> 
> Unclear if this would work:
> 
> typealias StringDictionary = Dictionary
> It need to infer that T must be hashable. Maybe it’s only 85% implemented.
> 
> 

Clarification here: the example is

typealias DictionaryToStrings = Dictionary

Either we infer T to require Hashable, or we call this ill-formed and require 
the user to write

typealias DictionaryToStrings = Dictionary



- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

[Douglas Gregor via swift-evolution]

> On Mar 9, 2016, at 12:26 PM, Russ Bishop via swift-evolution 
>  wrote:
> 
> An official proposal PR has been opened on this: 
> https://github.com/apple/swift-evolution/pull/198 
> 
> 
> It includes clarifications, a few changes, and some better examples.

FWIW, I’ve implemented much of this proposal as a series of compiler cleanups. 
It introduces a few tweaks to the _ObjectiveCBridgeable protocol that were 
necessary to generalize (and de-special-case) the 
NSString/NSArray/NSDictionary/NSSet bridging, but it’s still considered an 
implementation detail. So, some comments on the proposal itself…


/// A type adopting `ObjectiveCBridgeable` will be exposed
/// to Objective-C as the type `ObjectiveCType`
public protocol ObjectiveCBridgeable: _ObjectiveCBridgeable {
associatedtype ObjectiveCType : AnyObject
associatedtype _ObjectiveCType = ObjectiveCType
I think we should just say that ObjectiveCBridgeable replaces 
_ObjectiveCBridgeable, and only have the first associated type. (You actually 
wanted a typealias anyway, I think).

/// Returns `true` iff instances of `Self` can be converted to
/// Objective-C.  Even if this method returns `true`, a given
/// instance of `Self._ObjectiveCType` may, or may not, convert
/// successfully to `Self`.
///
/// A default implementation returns `true`.
@warn_unused_result
static func isBridgedToObjectiveC() -> Bool
It’s probably worth saying why someone might override this method: usually, 
it’s because the Swift type is generic and it only makes sense to bridge for 
some type arguments. Granted, there is no way to communicate this information 
to the compiler, which is a bit of a hole in the design. For example, Array 
only bridges to NSArray when T is itself representable in Objective-C. We 
really need conditional conformances to for this part of the feature to work 
properly.

/// Try to construct a value of the Self type from
/// an Objective-C object of the bridged class type.
///
/// If the conversion fails this initializer returns `nil`.
init?(bridgedFromObjectiveC: ObjectiveCType)
FWIW, implementing this required a new “unconditional” entry point used by the 
compiler:

  /// Bridge from an Objective-C object of the bridged class type to a
  /// value of the Self type.
  ///
  /// This bridging operation is used for unconditional bridging when
  /// interoperating with Objective-C code, either in the body of an
  /// Objective-C thunk or when calling Objective-C code, and may
  /// defer complete checking until later. For example, when bridging
  /// from `NSArray` to `Array`, we can defer the checking
  /// for the individual elements of the array.
  ///
  /// \param source The Objective-C object from which we are
  /// bridging. This optional value will only be `nil` in cases where
  /// an Objective-C method has returned a `nil` despite being marked
  /// as `_Nonnull`/`nonnull`. In most such cases, bridging will
  /// generally force the value immediately. However, this gives
  /// bridging the flexibility to substitute a default value to cope
  /// with historical decisions, e.g., an existing Objective-C method
  /// that returns `nil` to for "empty result" rather than (say) an
  /// empty array. In such cases, when `nil` does occur, the
  /// implementation of `Swift.Array`'s conformance to
  /// `_ObjectiveCBridgeable` will produce an empty array rather than
  /// dynamically failing.
  static func _unconditionallyBridgeFromObjectiveC(source: _ObjectiveCType?)
  -> Self

It can get a default implementation, and should be a non-failable initializer.

static func _getObjectiveCType() -> Any.Type {
return ObjectiveCType.self
}
This was an implementation hack; it’s gone now.

Expose the protocol ObjectiveCBridgeable
Any type adopting ObjectiveCBridgeable will gain conformance to 
_ObjectiveCBridgeable
As noted earlier, I think there should just be one protocol here, 
ObjectiveCBridgeable.

4. The ObjectiveCType must be defined in Swift. If a -swift.h header is 
generated, it will include a SWIFT_BRIDGED()macro where the parameter indicates 
the Swift type with which the ObjectiveCType bridges. The macro will be applied 
to the ObjectiveCType and any subclasses.

This is unnecessarily restrictive, and eliminates the “make my Objective-C 
class bridge into a Swift value type” case that (for example) the compiler 
already does for String/Array/Dictionary/Set. I think there are two cases:

(a) The ObjectiveCType is defined in Objective-C. It must be an 
Objective-C class with the attribute swift_bridge(“Bar”), where “Bar” is the 
name of the bridged Swift type.
(b) The ObjectiveCType is defined in Swift, in which case it must be an 
@objc class. When emitting the generated header, the appropriate swift_bridge 
attribute will be added to the @interface declaration.



(This was 

Re: [swift-evolution] Removing explicit use of `let` from Function Parameters

[Douglas Gregor via swift-evolution]

Looks great, thanks!

- Doug

> On Mar 17, 2016, at 9:45 PM, Nicholas Maccharoli <nmacchar...@gmail.com> 
> wrote:
> 
> Thank you!
> 
> I have filed a PR here: https://github.com/apple/swift-evolution/pull/215 
> <https://github.com/apple/swift-evolution/pull/215>
> 
> How does it look?
> 
> - Nick
> 
> 
> All the best,
> 
> Nicholas
> 
> Linked in:
> http://lnkd.in/328U22 <http://lnkd.in/328U22>
> 
> 
> On Fri, Mar 18, 2016 at 9:07 AM, Douglas Gregor <dgre...@apple.com 
> <mailto:dgre...@apple.com>> wrote:
> Yes, please file a PR. 
> 
> Sent from my iPhone
> 
> On Mar 17, 2016, at 5:05 PM, Chris Lattner <clatt...@apple.com 
> <mailto:clatt...@apple.com>> wrote:
> 
>> Sure, I’m ok with that if that is what Doug prefers.
>> 
>> -Chris
>> 
>>> On Mar 17, 2016, at 4:54 PM, Nicholas Maccharoli <nmacchar...@gmail.com 
>>> <mailto:nmacchar...@gmail.com>> wrote:
>>> 
>>> Thank you for the feedback!
>>> 
>>> I checked SE-0003 again and didnt see explicit mention of this.
>>> 
>>> I would like to write up a quick proposal today if its ok.
>>> 
>>> Chris, I promise to make it very concise is it ok to send over a PR to 
>>> swift evolution?
>>> 
>>> - Nick
>>> 
>>> 2016年3月18日金曜日、Chris Lattner<clatt...@apple.com 
>>> <mailto:clatt...@apple.com>>さんは書きました:
>>> 
>>>> On Mar 17, 2016, at 11:08 AM, Douglas Gregor via swift-evolution 
>>>> <swift-evolution@swift.org <>> wrote:
>>>> 
>>>> 
>>>>> On Mar 17, 2016, at 1:27 AM, Nicholas Maccharoli via swift-evolution 
>>>>> <swift-evolution@swift.org <>> wrote:
>>>>> 
>>>>> ​As a follow-up to proposal SE-0003​: "Removing var from Function 
>>>>> Parameters" being accepted,
>>>>> I think it might make sense to disallow explicitly declaring function 
>>>>> parameters with the `let` keyword since function parameters are immutable 
>>>>> by default.
>>>>> 
>>>>> Basically disallow writing functions like this:
>>>>> 
>>>>> func foo(let i: Int)  { ... }
>>>>> 
>>>>> and only allow the function above to be expressed as this:
>>>>> 
>>>>> func foo(i: Int) { … }
>>>> 
>>>> This makes perfect sense to me. Want to write up a proposal?
>>> 
>>> The intention was for this to be included as part of SE-0003.  If it 
>>> wasn’t, then that was an accidental omission.  Do we really need a full 
>>> proposal for that?
>>> 
>>> -Chris
>>> 
>>> 
>>> 
>>> -- 
>>> 
>>> All the best,
>>> 
>>> Nicholas
>>> 
>>> Linked in:
>>> http://lnkd.in/328U22 <http://lnkd.in/328U22>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

[Douglas Gregor via swift-evolution]

> On Mar 16, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>  • What is your evaluation of the proposal?
> 
> Overall in favor.
> 
> I don't like the getter syntax:
> 
>   float Point3DGetRadius(Point3D point) 
> __attribute__((swift_name("getter:Point3D.radius(self:)")));
> 
> I think we would be better off thinking of this instead as adding an accessor 
> to a property, perhaps with a syntax along these lines:
> 
>   float Point3DGetRadius(Point3D point) 
> __attribute__((swift_name("Point3D.radius.get(self:)")));
> 
> However, talking about operations-associated-with-a-property seems to be a 
> common theme with the behaviors proposal; you may want to think about a 
> syntax that could be used for both of them (and perhaps in demangling and 
> diagnostics as well).

FWIW, the “getter:” and “setter:” syntax was borrowed from the discussion of 
extending #selector to work with getters and setters of properties. Also, 
Point3D.radius.get could be a badly-named function “get” in a badly-named type 
“Point3D.radius” ;)

> I also find it odd that this proposal doesn't address subscripts.

Yeah. It should probably be a part of the proposal for completeness.

> 
> I assume that, on types imported as value types, Swift treats operations 
> whose self parameter is a (non-const) pointer to the type as mutating and 
> others as nonmutating. (This is not explicitly stated in the proposal, 
> though.)

That’s correct. It’s in the implementation but not the proposal.

> However, it's not clear how Swift makes that initial determination of whether 
> a type should be imported as a value type or a reference type.

That’s actually orthogonal to this proposal. However, right now you have C 
enums and structs mapping to value types, CF types mapping to reference types, 
and ObjC classes and protocols mapping to reference types.

> Has this proposal's use against libdispatch been evaluated? I would love to 
> see `dispatch_async(_:_:)` become `dispatch_queue.async(function:)`.

IIRC, the heuristics didn’t work so well, but it should be possible to 
swift_name libdispatch.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Removing explicit use of `let` from Function Parameters

[Douglas Gregor via swift-evolution]

> On Mar 17, 2016, at 11:22 AM, Harlan Haskins <har...@harlanhaskins.com> wrote:
> 
> Since we’re allowing keywords as argument names, shouldn’t this:
> 
> func foo(let i: Int)

Right now, you’d have to declare this as

  func foo(`let` i: Int)

but the proposal would fix that.

> be allowed, such that it’ll be called as this:
> 
> foo(let: 3)

Right.

- Doug


> 
> — Harlan
> 
>> On Mar 17, 2016, at 11:08 AM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Mar 17, 2016, at 1:27 AM, Nicholas Maccharoli via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> ​As a follow-up to proposal SE-0003​: "Removing var from Function 
>>> Parameters" being accepted,
>>> I think it might make sense to disallow explicitly declaring function 
>>> parameters with the `let` keyword since function parameters are immutable 
>>> by default.
>>> 
>>> Basically disallow writing functions like this:
>>> 
>>> func foo(let i: Int)  { ... }
>>> 
>>> and only allow the function above to be expressed as this:
>>> 
>>> func foo(i: Int) { … }
>> 
>> This makes perfect sense to me. Want to write up a proposal?
>> 
>>  - Doug
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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

[swift-evolution] [Review] SE-0044 Import as Member

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0044 “Import as Member" begins now and runs through March 22, 
2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md
 

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md
 

Reply text

Other replies
 What goes 
into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

Doug Gregor

Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

[Douglas Gregor via swift-evolution]

> On Jan 6, 2016, at 6:56 AM, Greg Parker via swift-evolution 
>  wrote:
> 
> 
>> On Jan 6, 2016, at 6:17 AM, Honza Dvorsky via swift-evolution 
>>  wrote:
>> 
>> I remember this being discussed in the conversation about this proposal and 
>> I haven't seen anyone being *against* there being a compiler flag, assuming 
>> it's off by default.
> 
> We don't want language-changing compiler flags. swiftc doesn't even have 
> flags to control warnings today, though I don't know if we'll be able to 
> preserve that forever.
> 
> Style rules should be enforced by tools other than the compiler. 

I tend to agree with Greg, in part because I don’t like the idea of having a 
cornucopia of potentially-conflicting warning flags for different coding 
conventions within the compiler proper (e.g., -Wimplicit-self vs. 
-Wunnecessarily-qualified-self, for the opposite ends of the spectrum in this 
particular debate).

The core team did talk about such a warning flag briefly, and there was no 
consensus either way. We think this needs more discussion in the community, but 
not as a discussion specific to requiring “self.”. Rather, the question is 
“does checking of coding conventions belong in the Swift compiler or in a 
separate tool?” and “how do we decide which coding conventions are 
important/popular/useful enough to include?”

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] STDLibs

[Douglas Gregor via swift-evolution]

> On Jan 6, 2016, at 11:06 AM, James Campbell via swift-evolution 
>  wrote:
> 
> I did but it redirects elsewhere now :S

It’s “swiftdoc.org”, not “swiftdocs.org” as in the link.

- Doug

> 
> On Wed, Jan 6, 2016 at 6:50 PM, Erica Sadun  > wrote:
> Have you stopped by swiftdoc.org  recently?
> 
> :)
> 
> -- Erica
> 
> 
>> On Jan 6, 2016, at 3:43 AM, James Campbell via swift-evolution 
>> > wrote:
>> 
>> Is there a way of improving the documentation and hosting it on Swift 
>> instead of Apple ?
>> 
>> Currently the Array page lists all of the things the class directly 
>> implements but doesn't include any of the methods mixed in by protocol 
>> extensions (i.e all of the methods from CollectionType).
>> 
>> With YardDoc for Ruby it does this, so you know exactly what methods a class 
>> has.
>> 
>> This confused me to no end as some topics here suggest adding ways of 
>> dropping the first X elements and even I have implemented `shift` which I 
>> didn't know already exist albeit under another name.
>> 
>> Would be great if we could improve these documents for the language in an 
>> open source way :)
>> 
>> -- 
>>  Wizard
>> ja...@supmenow.com 
>> +44 7523 279 698  
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> 
> 
> -- 
>  Wizard
> ja...@supmenow.com 
> +44 7523 279 698
>  ___
> 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

[swift-evolution] [Review] SE-0010 Add StaticString.UnicodeScalarView

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0010 "Add StaticString.UnicodeScalarView" begins now and runs 
through Friday, January 8th. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0010-add-staticstring-unicodescalarview.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 


or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 


Cheers,
Doug Gregor
Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor via swift-evolution]

> On Jan 5, 2016, at 3:51 AM, Andrey Tarantsov <and...@tarantsov.com> wrote:
> 
> I'm against this, because I often write extensions on Apple classes (like, 
> say, UIColor) that are only intended to be used from Swift, in a pure-Swift 
> project, and I need no stinking' @nonobjc in there.

You are misreading my proposal. I’m not proposing to change anything about how 
extensions of classes work. Your extensions of UIColor and other Objective-C 
classes remain unchanged.

How many Apple *protocols*, such as delegates, have you extended? I expect it’s 
not that many.

> 
> How much of a problem can this surprise be? You call a method, the compiler 
> tells you it's not there, you look up the reason, no harm done.

I’ve seen enough bugs filed and general confusion about this that the answer is 
“it’s quite a bit of a surprise”. The common case seems to be that people write 
a protocol extension of a delegate that implements some of its optional 
members. The only calls to that method occur in some framework code written in 
Objective-C, so there place for the compiler to tell you it’s not there.

- Doug

> 
> A.
> 
> 
> 
>> On Jan 5, 2016, at 11:32 AM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi all,
>> 
>> We currently have a bit of a surprise when one extends an @objc protocol:
>> 
>> @objc protocol P { }
>> 
>> extension P {
>>   func bar() { }
>> }
>> 
>> class C : NSObject { }
>> 
>> let c = C()
>> print(c.respondsToSelector("bar")) // prints "false"
>> 
>> because the members of the extension are not exposed to the Objective-C 
>> runtime. 
>> 
>> There is no direct way to implement Objective-C entry points for protocol 
>> extensions. One would effectively have to install a category on every 
>> Objective-C root class [*] with the default implementation or somehow 
>> intercept all of the operations that might involve that selector. 
>> 
>> Alternately, and more simply, we could require @nonobjc on members of @objc 
>> protocol extensions, as an explicit indicator that the member is not exposed 
>> to Objective-C. It’ll eliminate surprise and, should we ever find both the 
>> mechanism and motivation to make default implementations of @objc protocol 
>> extension members work, we could easily remove the restriction at that time.
>> 
>>  - Doug
>> 
>> [*] Assuming you can enumerate them, although NSObject and the hidden 
>> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
>> root class itself might default such a method, and the category version 
>> would conflict with it, so...
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor via swift-evolution]

> On Jan 5, 2016, at 5:41 AM, Charles Srstka <cocoa...@charlessoft.com> wrote:
> 
>> On Jan 4, 2016, at 10:32 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> There is no direct way to implement Objective-C entry points for protocol 
>> extensions. One would effectively have to install a category on every 
>> Objective-C root class [*] with the default implementation or somehow 
>> intercept all of the operations that might involve that selector. 
> 
> I can almost do it right now, just hacking with the Objective-C runtime 
> functions, so I’d think that if you were actually working with the compiler 
> sources, it should be doable. The trouble is on the Swift side; currently 
> there aren’t any reflection features that I can find that work on Swift 
> protocols.

The compiler isn’t the limitation here, it’s the Objective-C runtime. That’s 
somewhat malleable, but making changes there to support a Swift feature affects 
backward deployment.

> @implementation NSObject (Swizzle)

Note that all approaches based on adding categories to a root class require you 
to enumerate root classes, as I noted in my original message. That’s 
unfortunate and requires more trickery.

> + (void)load {
> CFAbsoluteTime startTime = CFAbsoluteTimeGetCurrent();
> 
> unsigned int classCount = 0;
> Class *classes = objc_copyClassList();

Doing it this way won’t handle protocol conformances or classes loaded later 
via a dlopen’d dylib.

> 
> Protocol *proto = @protocol(HasSwiftExtension);
> 
> for (unsigned int i = 0; i < classCount; i++) {
> Class eachClass = classes[i];
> 
> if (class_conformsToProtocol(eachClass, proto)) {
> unsigned int protoCount = 0;
> Protocol * __unsafe_unretained *protocols = 
> class_copyProtocolList(eachClass, );
> 
> for (unsigned int j = 0; j < protoCount; j++) {
> Protocol *eachProto = protocols[j];
> 
> if (protocol_conformsToProtocol(eachProto, proto)) {
> unsigned int methodCount = 0;
> // what we would want would be to pass YES for 
> isRequiredMethod; unfortunately,
> // adding optional methods to an @objc protocol in an 
> extension currently just
> // crashes the compiler when I try it. So pass NO, for 
> the demonstration.

The crash is a bug; please file it.

> struct objc_method_description *methods = 
> protocol_copyMethodDescriptionList(eachProto, NO, YES, );
> 
> for (unsigned int k = 0; k < methodCount; k++) {
> struct objc_method_description method = methods[k];
> 
> if (!class_respondsToSelector(eachClass, 
> method.name)) {
> [SwizzleWrapper swizzleClass:[eachClass class] 
> protocol:eachProto method:method];
> }
> }
> 
> free(methods);
> }
> }
> 
> free(protocols);
> }
> }
> 
> free(classes);
> 
> NSLog(@"took %f seconds", CFAbsoluteTimeGetCurrent() - startTime);
> }
> @end
> 

[snip]

> (For the record, I’m not advocating actually using the swizzling method 
> described above; just pointing out that intercepting the selector is 
> possible. Working with the compiler sources, I’d expect more elegant 
> solutions would be possible.)


There are better mechanisms for this than +load. But one would have to deal 
with the dylib loading issue and the need to enumerate root classes to get to a 
complete implementation. Frankly, I don’t think this level of Objective-C 
runtime hackery is worth the effort, hence my suggestion to make the existing 
behavior explicit.

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0014 Constraining `AnySequence.init`

[Douglas Gregor via swift-evolution]

The review of SE-0014 "Constraining `AnySequence.init`" ran from December 
18–21, 2015. The proposal has been accepted for Swift 2.2.


https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md

Thank you to everyone who participated in the review process! We welcome an 
implementation of this proposal, which is tracked by

https://bugs.swift.org/browse/SR-474

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

[Douglas Gregor via swift-evolution]

The review of SE-0009 "Require self for accessing instance members`" ran from 
December 16–20, 2015. The proposal has been rejected.


https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md
 


This proposal spawned a massive, polarized discussion with 200+ messages 
involving 80+ participants. We’re thrilled at the enthusiasm and thank all who 
participated. There were many, many interesting points made, along with 
experience reports from various Swift code bases, ideas to help mitigate the 
concerns that motivated the proposal, and so on. Quantitatively, the overall 
community assessment of the proposal was roughly 5:2 against requiring “self.”.

The core team agreed that this proposal is not the right direction for Swift. 
There are a number of reasons for this decision:

* Mandatory “self.” introduces a significant amount of verbosity that does not 
justify itself with added clarity. While it is true that mandatory “self.” may 
prevent a class of bugs, the cost of eliminating those bugs is fairly high in 
terms of visual clutter, which goes against the generally uncluttered feel of 
Swift. Paul Cantrell put it well in his review 

 when he said, “anything that is widely repeated becomes invisible.” Swift aims 
to avoid such boilerplate and repetition in its design, a principle also 
espoused by the Swift API Design Guidelines 
.

* The requirement to use “self.” within potentially-escaping closures is a 
useful indicator of the potential for retain cycles that we don’t want to lose. 
Additionally, developers can optionally use “self.” when they feel it improves 
clarity (e.g., when similar operations are being performed on several different 
instances, of which “self” is one).

* The name-shadowing concerns behind the mandatory “self.” apply equally well 
to anything found by unqualified name lookup, including names found in the 
global scope. To call out members of types as requiring qualification while 
global names do not (even when global names tend to be far more numerous) feels 
inconsistent, but requiring qualification for everything (e.g., “Swift.print”, 
“self.name”) exacerbates the problem of visual clutter. 

* Individuals or teams that feel that explicit “self.” is beneficial for their 
own code bases can enforce such a coding convention via tooling with the status 
quo. If this proposal were accepted, those opposed to the proposal would 
effectively have no recourse because the language itself would be enforcing 
“self.”.

Doug Gregor
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 8:58 PM, John Joyce <uchuug...@icloud.com> wrote:
> 
> Would it not be possible to do the relative analog of Objective-C nullability 
> macro sandwiches in Swift?
> And then allowing exceptions within the file to be called out explicitly with 
> @nonobjc or @objc ?
> @begin_assume_nonobjc
> @end_assume_nonobjc
> @begin_assume_objc
> @begin_assume_objc

Ick :)

If we need to annotate several things at once, doing it an extension 
granularity is good enough, because there’s essentially no cost to merging or 
breaking apart extensions as needed.

- Doug

>> On Jan 5, 2016, at 1:54 PM, Kevin Lundberg via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I like this idea, but I would imagine that for an extension with many 
>> functions in it, requiring @nonobjc on each one would get tedious very fast. 
>> Could it be required (or at least allowed in addition to per-method 
>> annotations) at the extension level?:
>>  
>>  @objc protocol P {}
>>  
>>  @nonobjc extension P {
>>  func foo() { }
>>  func bar() { }
>>  func baz() { }
>>  func blah() { } 
>>  // etc...
>>  }
>> 
>> I don’t know if this would have specific implementation ramifications over 
>> only doing this on each method, if extensions cannot already be modified 
>> with attributes. I can’t think of a case where I’ve seen annotations added 
>> to protocol extensions, or any other extensions for that matter.
>> 
>> 
>>> On Jan 4, 2016, at 11:32 PM, Douglas Gregor via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hi all,
>>> 
>>> We currently have a bit of a surprise when one extends an @objc protocol:
>>> 
>>> @objc protocol P { }
>>> 
>>> extension P {
>>>   func bar() { }
>>> }
>>> 
>>> class C : NSObject { }
>>> 
>>> let c = C()
>>> print(c.respondsToSelector("bar")) // prints "false"
>>> 
>>> because the members of the extension are not exposed to the Objective-C 
>>> runtime. 
>>> 
>>> There is no direct way to implement Objective-C entry points for protocol 
>>> extensions. One would effectively have to install a category on every 
>>> Objective-C root class [*] with the default implementation or somehow 
>>> intercept all of the operations that might involve that selector. 
>>> 
>>> Alternately, and more simply, we could require @nonobjc on members of @objc 
>>> protocol extensions, as an explicit indicator that the member is not 
>>> exposed to Objective-C. It’ll eliminate surprise and, should we ever find 
>>> both the mechanism and motivation to make default implementations of @objc 
>>> protocol extension members work, we could easily remove the restriction at 
>>> that time.
>>> 
>>> - Doug
>>> 
>>> [*] Assuming you can enumerate them, although NSObject and the hidden 
>>> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
>>> root class itself might default such a method, and the category version 
>>> would conflict with it, so...
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto: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 <mailto: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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 2:49 PM, plx via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> On a re-read I am -1; I like the `associatedtype` keyword but didn’t realize 
> there was no plan to let `typealias` be used within a protocol to as a 
> convenience (and to preserve intent, and to improve the development 
> experience when still figuring out an interface design).
> 
> I would prefer the new keyword and also adding/allowing one to add 
> convenience typealiases within a protocol definition.

You can evaluate the proposal however you wish, but I don’t think it makes 
sense to vote against a proposal because it is missing some additional feature 
*unless* the lack of that additional feature makes the proposal effectively 
useless. I don’t think that’s the case here: changing ‘typealias’ to 
‘associatedtype’ can easily be viewed as an improvement on its own, which then 
opens the door to additional features (real typealiases in protocols or 
protocol extensions).

- Doug

> 
>> On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "Replace `typealias` keyword with `associatedtype` for 
>> associated type declarations” begins now and runs through Wednesday, January 
>> 6th. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
>>  
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md>
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>>  https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have you used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md 
>> <https://github.com/apple/swift-evolution/blob/master/process.md>
>> 
>>  Cheers,
>>  Doug Gregor
>>  Review Manager
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor via swift-evolution]

Hi all,

We currently have a bit of a surprise when one extends an @objc protocol:

@objc protocol P { }

extension P {
  func bar() { }
}

class C : NSObject { }

let c = C()
print(c.respondsToSelector("bar")) // prints "false"

because the members of the extension are not exposed to the Objective-C 
runtime. 

There is no direct way to implement Objective-C entry points for protocol 
extensions. One would effectively have to install a category on every 
Objective-C root class [*] with the default implementation or somehow intercept 
all of the operations that might involve that selector. 

Alternately, and more simply, we could require @nonobjc on members of @objc 
protocol extensions, as an explicit indicator that the member is not exposed to 
Objective-C. It’ll eliminate surprise and, should we ever find both the 
mechanism and motivation to make default implementations of @objc protocol 
extension members work, we could easily remove the restriction at that time.

- Doug

[*] Assuming you can enumerate them, although NSObject and the hidden 
SwiftObject cover the 99%. Even so, that it’s correct either, because the root 
class itself might default such a method, and the category version would 
conflict with it, so...___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 8:49 PM, Félix Cloutier <felix...@yahoo.ca> wrote:
> 
> For the folks who don't mix Swift and Objective-C that much, extensions on 
> @objc classes are exposed to the Objective-C runtime, so there is a 
> discrepancy here. I'm not passionate about the outcome, just dropping the 
> info.

Right. I think this is the reason that developers expect members of @objc 
protocol extensions to show up in Objective-C, because it automatically happens 
for extensions of @objc classes. (We’ve received a number of bug reports about 
this)

- Doug

> 
> Félix
> 
>> Le 4 janv. 2016 à 23:32:25, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>> 
>> Hi all,
>> 
>> We currently have a bit of a surprise when one extends an @objc protocol:
>> 
>> @objc protocol P { }
>> 
>> extension P {
>>   func bar() { }
>> }
>> 
>> class C : NSObject { }
>> 
>> let c = C()
>> print(c.respondsToSelector("bar")) // prints "false"
>> 
>> because the members of the extension are not exposed to the Objective-C 
>> runtime. 
>> 
>> There is no direct way to implement Objective-C entry points for protocol 
>> extensions. One would effectively have to install a category on every 
>> Objective-C root class [*] with the default implementation or somehow 
>> intercept all of the operations that might involve that selector. 
>> 
>> Alternately, and more simply, we could require @nonobjc on members of @objc 
>> protocol extensions, as an explicit indicator that the member is not exposed 
>> to Objective-C. It’ll eliminate surprise and, should we ever find both the 
>> mechanism and motivation to make default implementations of @objc protocol 
>> extension members work, we could easily remove the restriction at that time.
>> 
>>  - Doug
>> 
>> [*] Assuming you can enumerate them, although NSObject and the hidden 
>> SwiftObject cover the 99%. Even so, that it’s correct either, because the 
>> root class itself might default such a method, and the category version 
>> would conflict with it, so...
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On Jan 3, 2016, at 10:44 PM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Jan 3, 2016, at 9:14 PM, Drew Crawford >> > wrote:
>>> 
>>> Sure, here's the start of the thread: 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>>>  
>>> 
>> Thanks.  Joe was basically saying is that associated types would be 
>> automatically bound to the existential for their constraints, or Any if 
>> there are no constraints.  
>> 
>> He didn’t specifically mention anything about Self, but I suppose Self 
>> requirements could also be automatically bound to Any if the existential 
>> type doesn’t specify anything more specific, although I’m not sure I would 
>> like that behavior.
>> 
>> Self is what would apply in the case of:
>> 
>>> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // error!
>>>   if first < second {
>>> return -1
>>>   }
>>>   //...
>>> }
>> If Self were automatically bound to Any what would this do?  Would it 
>> compile and invoke a `<` operator that takes two Any parameters?  That 
>> doesn’t seem to make sense to me.  It certainly wouldn’t guarantee you get 
>> the correct behavior if first and second were both Int for example.
> 
> I gave this some further thought last night and realized what would happen 
> here is pretty clear.  I hadn’t considered existentials where associated 
> types aren’t bound to concrete types before so it just took a few minutes to 
> work through.
> 
> Existentials reference a witness table pointing to an actual implementations 
> of the protocol requirements.  Actual implementations require parameters of 
> concrete types.  This means that you must know what that concrete type is and 
> supply a value of that type in order to actually call the member.  The 
> implication of this is that members which require parameters of an associated 
> type that is not bound to a concrete type will not be available on that 
> existential.  

There is a concrete type, which is known dynamically to the existential value, 
but you would need a way to name that type to (e.g.) cast down to it before you 
could use the member. That’s why the open..as operation I mentioned allows one 
to use these members: it gives a way to name the type. It actually helps to 
think of any operation on existentials as implicitly using open..as, because it 
makes the semantics far more explicit. (The compiler does this internally as 
well)

> In this example, `<` requires two arguments of type Self.  However, the 
> `Comparable` existential, if allowed, would have Self bound to `Any`, not a 
> concrete type.  Therefore `<` would not be available and you would receive a 
> compiler error on that line.  It would be different than the current error 
> and on a different line of code but it would still fail to compile.
> 
> With return types, you do not necessarily need to know the concrete type 
> returned by the implementation.  Swift could theoretically box the result 
> itself into an existential and return that to the caller.  I do not know 
> whether this is the actual design that will be implemented or not.

It’s a reasonable direction that we’ve discussed in passing but never committed 
to.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 9:54 AM, Matthew Johnson  wrote:
> 
>> 
>> On Jan 4, 2016, at 11:43 AM, Douglas Gregor > > wrote:
>> 
>>> 
>>> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
 
 On Jan 3, 2016, at 10:44 PM, Matthew Johnson > wrote:
 
 
> On Jan 3, 2016, at 9:14 PM, Drew Crawford  > wrote:
> 
> Sure, here's the start of the thread: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>  
> 
 Thanks.  Joe was basically saying is that associated types would be 
 automatically bound to the existential for their constraints, or Any if 
 there are no constraints.  
 
 He didn’t specifically mention anything about Self, but I suppose Self 
 requirements could also be automatically bound to Any if the existential 
 type doesn’t specify anything more specific, although I’m not sure I would 
 like that behavior.
 
 Self is what would apply in the case of:
 
> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // 
> error!
>   if first < second {
> return -1
>   }
>   //...
> }
 If Self were automatically bound to Any what would this do?  Would it 
 compile and invoke a `<` operator that takes two Any parameters?  That 
 doesn’t seem to make sense to me.  It certainly wouldn’t guarantee you get 
 the correct behavior if first and second were both Int for example.
>>> 
>>> I gave this some further thought last night and realized what would happen 
>>> here is pretty clear.  I hadn’t considered existentials where associated 
>>> types aren’t bound to concrete types before so it just took a few minutes 
>>> to work through.
>>> 
>>> Existentials reference a witness table pointing to an actual 
>>> implementations of the protocol requirements.  Actual implementations 
>>> require parameters of concrete types.  This means that you must know what 
>>> that concrete type is and supply a value of that type in order to actually 
>>> call the member.  The implication of this is that members which require 
>>> parameters of an associated type that is not bound to a concrete type will 
>>> not be available on that existential.  
>> 
>> There is a concrete type, which is known dynamically to the existential 
>> value, but you would need a way to name that type to (e.g.) cast down to it 
>> before you could use the member. That’s why the open..as operation I 
>> mentioned allows one to use these members: it gives a way to name the type. 
>> It actually helps to think of any operation on existentials as implicitly 
>> using open..as, because it makes the semantics far more explicit. (The 
>> compiler does this internally as well)
> 
> Casting down makes sense and of course you could use the member after that.  
> But why do we need a special cast operation “open” to do this?  Is there a 
> reason we couldn’t just cast down with the usual operators like we can with 
> `Any`?

How are you going to name the type you’re casting to?

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Douglas Gregor via swift-evolution]

> On Jan 3, 2016, at 4:19 PM, David Waite <da...@alkaline-solutions.com> wrote:
> 
> This would be wonderful - is it something that could happen in the Swift 3 
> timeframe?

I hesitate to say “yes” here. I think it fits with the goals of Swift 3, but my 
main concern is that there isn’t enough engineering bandwidth to implement it 
for Swift 3.

> Is it something that myself or someone else could work on a formal proposal 
> for?

Yes, absolutely. This is a case where I think it’s useful to design what we 
want, even if we cannot fit the implementation into the Swift 3 schedule. It’s 
also a case where the compiler has a lot of the pieces already implemented 
(with some runtime bits landing soon), so the implementation should not be 
*that* hard and will likely not require architectural changes.

- Doug

> 
> -DW
> 
>> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Introduction of interfaces will clean up the current blend of static and 
>>> dynamic protocols, and solve at least three popular issues.
>>> Please see:
>>> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
>>>  
>>> <https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md>
>> I am *completely* against this proposal.
>> 
>> Fundamentally, you're trying to address the limitation that protocols with 
>> Self or associated type requirements can't be existential. But it's just a 
>> limitation that isn't (conceptually) that hard to fix: the primary operation 
>> you need to work with an existing of such a protocol is to "open" a value of 
>> existential type, giving a name to the dynamic type it stores. Let's invent 
>> one:
>> 
>>   func eq(x: Equatable, y: Equatable) -> Bool {
>> // give the name T to the dynamic type stored in xT
>> let xT = open x as T
>> // is y also storing a T?
>> guard let yT = y as? T else { return false }
>> // check whether the Ts are equal
>> return xT == yT
>>   }
>> 
>> Ignore the syntax: semantically, we've gone from a "dynamic" existential 
>> thing back to something more "static", just by giving a name to the type. 
>> Swift generics aren't really even static in any sense: what the do is give 
>> names to the types of values so one can establish relationships among 
>> different values. "open..as" would do that for existentials. 
>> 
>> Note that ether Swift compilers AST and SIL both have "open existential" 
>> operations that do this internally. They have no spelling in Swift code, but 
>> they are useful to describe operations on existentials. At present, they 
>> cannot be formed when the existential involves a protocol with Self or 
>> associated type requirements, but that's a limitation that isn't hard to 
>> address. 
>> 
>> As for your concerns about knowing when one can dynamically override and 
>> when one cannot...  There are issues here that need to be addressed. They 
>> aren't significant enough to warrant such a drastic change, and may not even 
>> require language changes at all. 
>> 
>>  - Doug
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

[Douglas Gregor via swift-evolution]

> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>  wrote:
> 
> Introduction of interfaces will clean up the current blend of static and 
> dynamic protocols, and solve at least three popular issues.
> Please see:
> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md

I am *completely* against this proposal.

Fundamentally, you're trying to address the limitation that protocols with Self 
or associated type requirements can't be existential. But it's just a 
limitation that isn't (conceptually) that hard to fix: the primary operation 
you need to work with an existing of such a protocol is to "open" a value of 
existential type, giving a name to the dynamic type it stores. Let's invent one:

  func eq(x: Equatable, y: Equatable) -> Bool {
// give the name T to the dynamic type stored in xT
let xT = open x as T
// is y also storing a T?
guard let yT = y as? T else { return false }
// check whether the Ts are equal
return xT == yT
  }

Ignore the syntax: semantically, we've gone from a "dynamic" existential thing 
back to something more "static", just by giving a name to the type. Swift 
generics aren't really even static in any sense: what the do is give names to 
the types of values so one can establish relationships among different values. 
"open..as" would do that for existentials. 

Note that ether Swift compilers AST and SIL both have "open existential" 
operations that do this internally. They have no spelling in Swift code, but 
they are useful to describe operations on existentials. At present, they cannot 
be formed when the existential involves a protocol with Self or associated type 
requirements, but that's a limitation that isn't hard to address. 

As for your concerns about knowing when one can dynamically override and when 
one cannot...  There are issues here that need to be addressed. They aren't 
significant enough to warrant such a drastic change, and may not even require 
language changes at all. 

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of "Replace `typealias` keyword with `associatedtype` for associated 
type declarations” begins now and runs through Wednesday, January 6th. The 
proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
 


Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 


or, if you would like to keep your feedback private, directly to the review 
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 


Cheers,
Doug Gregor
Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

>> On Dec 27, 2015, at 10:37 AM, Joe Groff <jgr...@apple.com> wrote:
>> 
>> 
>> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hi all,
>> 
>> Here’s a proposal draft to allow one to name any function in Swift. In 
>> effect, it’s continuing the discussion of retrieving getters and setters as 
>> functions started by Michael Henson here:
>> 
>>  
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>> 
>> the proposal follows, and is available here as well:
>> 
>>  
>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>> 
>> Comments appreciated!
>> 
>> Generalized Naming for Any Function
>> 
[snip]
> 
>> Getters and setters can be written using dotted syntax within the back-ticks:
>> 
>> let specificTitle = button.`currentTitle.get` // has type () -> String?
>> let otherTitle = UIButton.`currentTitle.get`  // has type (UIButton) -> () 
>> -> String?
>> let setTintColor = button.`tintColor.set` // has type (UIColor!) -> ()
>> The same syntax works with subscript getters and setters as well, using the 
>> full name of the subscript:
>> 
>> extension Matrix {
>>   subscript (row row: Int) -> [Double] {
>> get { ... }
>> set { ... }
>>   }
>> }
>> 
>> let getRow = someMatrix.`subscript(row:).get` // has type (Int) -> () -> 
>> [Double]
>> let setRow = someMatrix.`subscript(row:).set` // has type (Int) -> 
>> ([Double]) -> ()
> At least as far as pure Swift is concerned, for unapplied access, like 
> `UIButton.currentTitle`, I think it would be more consistent with the way 
> method references works for that to give you the getter (or lens) without 
> decoration. instance.instanceMethod has type Args -> Ret, and 
> Type.instanceMethod has type Self -> Args -> Ret; by analogy, since 
> instance.instanceProperty has type Ret or inout Ret, it's reasonable to 
> expect Type.instanceProperty to have type Self -> [inout] Ret.

Yes, that seems reasonable.

> Forming a getter or setter partially applied to an instance feels unmotivated 
> to me—{ button.currentTitle } or { button.currentTitle = $0 } already work, 
> and are arguably clearer than this syntax.

I’m not strongly motivated by it in and of itself; rather, I like the idea of 
being able to get at all of the functions (for completeness/consistency), 
partly because of the Objective-C selector issue.

> I acknowledge that this leaves forming selectors from setters out to dry, but 
> I feel like that's something that could be incorporated into a "lens" design 
> along with typed selectors. As a rough sketch, we could say that the 
> representation of @convention(selector) T -> inout U is a pair of 
> getter/setter selectors,

I should weigh in over on a typed-selectors thread, but my personal view is 
that typed selectors are a well-designed feature that isn't worth doing: one 
would probably not use them outside of interoperability with Objective-C. To 
make that work, we'd need a Clang feature as well (to express the types), then 
all of the relevant Objective-C APIs would need to adopt it for us to see the 
benefits. On iOS, we are talking about a relatively small number of APIs 
(100-ish), and many of those have blocks/closure-based variants that are 
preferred. 

> and provide API on Selector to grab the individual selectors from that, maybe 
> Selector(getterFor: UIView.currentTitle)/(setterFor: UIView.currentTitle)

Sure. I suspect that retrieving the selector of a getter/setter will be fairly 
rare, so I'm fine with that operation being ugly. 

> . I don't think get/set is a good interface for working with Swift 
> properties, so I don't like the idea of building in language support to 
> codify it beyond what's needed for ObjC interaction.

That is an excellent point. I think you've convinced me to drop the 
getter/setter part of this: lenses are the right abstraction for working with 
properties, and we can handle ObjC getter/setter in some other way. 

>> Can we drop the back-ticks? It's very tempting to want to drop the 
>> back-ticks entirely, because something like
>> 
>> let fn = someView.insertSubview(_:at:)
>> can be correctly parsed as a reference to insertSubview(_:at:). However, it 
>> breaks down at the margins, e.g., with getter/setter references or 
>> no-argument functions:
>> 
>> extension Optional {
>>   func get() -> T { return self! }
>> }
>> 
>> let fn1 = button.currentTitle.get   // getter or Opt

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Dec 29, 2015, at 11:03 AM, Douglas Gregor via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Dec 29, 2015, at 10:17 AM, Joe Groff <jgr...@apple.com> wrote:
>> 
>> We also have a problem with disambiguating same-named members that come from 
>> different extensions, whether via protocol extensions or independent 
>> concrete extensions from different modules. Could we extend this scheme to 
>> allow for disambiguating extension methods by protocol/module name?
> 
> That's a fantastic idea!

It does introduce some ambiguities at the margins. Given

  foo.`bar.get`()

Do we look for bar in the lexical scope or in the member scope of foo? Or both 
with yet another disambiguation mechanism?

I'm still traumatized by implementing the related C++ rules for

  foo.bar::get 

:)

This is the other thing that nudges me toward dropping getters/setters from the 
generalized naming proposal, because it leaves the use of '.' within backticks 
for your newly-proposed meaning. 
> 
>> 
>> extension ProtocolA { func foo() }
>> extension ProtocolB { func foo() }
>> 
>> public struct Foo: ProtocolA, ProtocolB {
>>   func callBothFoos() {
>> self.`ProtocolA.foo`()
>> self.`ProtocolB.foo`()
>>   }
>> }
>> 
>> import A // extends Bar with bar()
>> import B // also extends Bar with bar()
>> 
>> extension Bar {
>>   func callBothBars() {
>> self.`A.bar`()
>> self.`B.bar`()
>>   }
>> }
>> 
>> -Joe
>> 
>>> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Hi all,
>>> 
>>> Here’s a proposal draft to allow one to name any function in Swift. In 
>>> effect, it’s continuing the discussion of retrieving getters and setters as 
>>> functions started by Michael Henson here:
>>> 
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>>> 
>>> the proposal follows, and is available here as well:
>>> 
>>> 
>>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>>> 
>>> Comments appreciated!
>>> 
>>> Generalized Naming for Any Function
>>> Proposal: SE-
>>> Author(s): Doug Gregor
>>> Status: Awaiting Review
>>> Review manager: TBD
>>> Introduction
>>> 
>>> Swift includes support for first-class functions, such that any function 
>>> (or method) can be placed into a value of function type. However, it is not 
>>> possible to specifically name every function that is part of a Swift 
>>> program---one cannot provide the argument labels when naming a function, 
>>> nor are property and subscript getters and setters referenceable. This 
>>> proposal introduces a general syntax that allows one to name anything that 
>>> is a function within Swift in an extensible manner.
>>> 
>>> Swift-evolution thread: Michael Henson started a thread about the 
>>> getter/setter issue here, continued here. See the Alternatives considered 
>>> section for commentary on that discussion.
>>> 
>>> Motivation
>>> 
>>> It's fairly common in Swift for multiple functions or methods to have the 
>>> same "base name", but be distinguished by parameter labels. For example, 
>>> UIView has three methods with the same base name insertSubview:
>>> 
>>> extension UIView {
>>>   func insertSubview(view: UIView, at index: Int)
>>>   func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
>>>   func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
>>> }
>>> When calling these methods, the argument labels distinguish the different 
>>> methods, e.g.,
>>> 
>>> someView.insertSubview(view, at: 3)
>>> someView.insertSubview(view, aboveSubview: otherView)
>>> someView.insertSubview(view, belowSubview: otherView)
>>> However, when referencing the function to create a function value, one 
>>> cannot provide the labels:
>>> 
>>> let fn = someView.insertSubview // ambiguous: could be any of the three 
>>> methods
>>> In some cases, it is possible to use type annotations to disambiguate:
>>> 
>>> let fn: (UIView, Int) = someView.insertSubview// ok: uses 
>>> insertSubview(_:at:)
>>> let fn: (UIView, 

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Dec 29, 2015, at 11:48 AM, Félix Cloutier <felix...@yahoo.ca> wrote:
> 
> Currently, they can be disambiguated using (self as ProtocolA).bar(), no?

Not if ProtocolA has self requirements or associated types. 
> 
> Félix
> 
>> Le 29 déc. 2015 à 14:10:51, Erica Sadun via swift-evolution 
>> <swift-evolution@swift.org> a écrit :
>> 
>> Talk about things you didn't know you needed until you see them. This is a 
>> really nice way of disambiguating!
>> 
>> -- E
>> 
>>> On Dec 29, 2015, at 12:03 PM, Douglas Gregor via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Dec 29, 2015, at 10:17 AM, Joe Groff <jgr...@apple.com> wrote:
>>>> 
>>>> We also have a problem with disambiguating same-named members that come 
>>>> from different extensions, whether via protocol extensions or independent 
>>>> concrete extensions from different modules. Could we extend this scheme to 
>>>> allow for disambiguating extension methods by protocol/module name?
>>> 
>>> That's a fantastic idea!
>>> 
>>>> 
>>>> extension ProtocolA { func foo() }
>>>> extension ProtocolB { func foo() }
>>>> 
>>>> public struct Foo: ProtocolA, ProtocolB {
>>>>   func callBothFoos() {
>>>> self.`ProtocolA.foo`()
>>>> self.`ProtocolB.foo`()
>>>>   }
>>>> }
>>>> 
>>>> import A // extends Bar with bar()
>>>> import B // also extends Bar with bar()
>>>> 
>>>> extension Bar {
>>>>   func callBothBars() {
>>>> self.`A.bar`()
>>>> self.`B.bar`()
>>>>   }
>>>> }
>>>> 
>>>> -Joe
>>>> 
>>>>> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> Here’s a proposal draft to allow one to name any function in Swift. In 
>>>>> effect, it’s continuing the discussion of retrieving getters and setters 
>>>>> as functions started by Michael Henson here:
>>>>> 
>>>>>   
>>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>>>>> 
>>>>> the proposal follows, and is available here as well:
>>>>> 
>>>>>   
>>>>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>>>>> 
>>>>> Comments appreciated!
>>>>> 
>>>>> Generalized Naming for Any Function
>>>>> 
>>>>> Proposal: SE-
>>>>> Author(s): Doug Gregor
>>>>> Status: Awaiting Review
>>>>> Review manager: TBD
>>>>> Introduction
>>>>> 
>>>>> Swift includes support for first-class functions, such that any function 
>>>>> (or method) can be placed into a value of function type. However, it is 
>>>>> not possible to specifically name every function that is part of a Swift 
>>>>> program---one cannot provide the argument labels when naming a function, 
>>>>> nor are property and subscript getters and setters referenceable. This 
>>>>> proposal introduces a general syntax that allows one to name anything 
>>>>> that is a function within Swift in an extensible manner.
>>>>> 
>>>>> Swift-evolution thread: Michael Henson started a thread about the 
>>>>> getter/setter issue here, continued here. See the Alternatives considered 
>>>>> section for commentary on that discussion.
>>>>> 
>>>>> Motivation
>>>>> 
>>>>> It's fairly common in Swift for multiple functions or methods to have the 
>>>>> same "base name", but be distinguished by parameter labels. For example, 
>>>>> UIView has three methods with the same base name insertSubview:
>>>>> 
>>>>> extension UIView {
>>>>>   func insertSubview(view: UIView, at index: Int)
>>>>>   func insertSubview(view: UIView, aboveSubview siblingSubview: UIView)
>>>>>   func insertSubview(view: UIView, belowSubview siblingSubview: UIView)
>>>>> }
>>&

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Dec 27, 2015, at 12:07 AM, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
> 
> This is a neat idea. Here are some of my thoughts after initial readthrough:
> 
> - For symmetry with Obj-C code, how about using "@selector", such as 
> @selector(UIView.`insertSubview(_:at:)`) ?

@ means at-tribute in Swift, whereas this is a specific expression. 

> - Or, why bother with a new expression? Could the compiler just do this 
> automatically when it encounters an @objc function being passed as a 
> Selector? So, you'd simply be able to say "let sel1: Selector = 
> UIView.`frame.get`"

It could, but I don't think it should: the operation is not common enough that 
making it implicit would reduce overall syntactic noise, and it would introduce 
ambiguities between selector- and closure-based APIs. 

> - Should the migrator offer to convert string-constant selectors to this form?

Yes, absolutely.

> - It might be worth considering this in the context of the "type-safe 
> selectors" idea that was floating around a while back.

Yes, I should have referenced that. Apologies!

> - Would it be valid to qualify a function with a subclass's name, when it's 
> really only defined on the superclass? That is, would 
> "objc_selector(MyView.`frame.get`)" work even if MyView doesn't override the 
> `frame` property?

Yes. MyView still has that property even if it doesn't override it. 
> 
> I could see this last one as a potential source of user confusion, because 
> naming a particular class wouldn't actually tell you which implementation 
> gets called when performing the selector (that's just the nature of the Obj-C 
> runtime).

To some extent, that's the nature of overriding. But objective-c allows one to 
use a selector with an unrelated class, which can certainly be confusing. I 
feel like that comes from the runtime itself, and isn't something we can avoid 
with any syntax we pick. 

> Jacob Bandes-Storch
> 
>> On Sat, Dec 26, 2015 at 11:48 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> Hi all,
>> 
>> Currently, producing an Objective-C selector in Swift is an error-prone 
>> operation. One effectively just writes a string literal and uses it in a 
>> context where an ObjectiveC.Selector is expected:
>> 
>> control.sendAction(“doSomething:”, to: target, forEvent: event)
>> 
>> There are many points of failure here:
>> 
>> 1) The compiler doesn’t syntax-check at all to make sure it’s a valid 
>> spelling for a selector
>> 2) The compiler doesn’t look for existing methods with this selector anywhere
>> 3) The mapping from a Swift method name to an Objective-C selector isn’t 
>> always immediately obvious (especially for initializers), and will be 
>> getting significantly more complicated with the renaming work for Swift 3 
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md).
>> 
>> I suggest that we add an expression ‘objc_selector(method-reference)` that 
>> produces the Objective-C selector for the named method, and produces an 
>> error if the method does not have an Objective-C entry point. For example:
>> 
>> control.sendAction(objc_selector(MyApplication.doSomething), to: 
>> target, forEvent: event)
>> 
>> “doSomething” is a method of MyApplication, which might even have a 
>> completely-unrelated name in Objective-C:
>> 
>> extension MyApplication {
>> @objc(jumpUpAndDown:)
>> func doSomething(sender: AnyObject?) { … }
>> }
>> 
>> By naming the Swift method and having objc_selector do the work to form the 
>> Objective-C selector, we free the programming from having to do the naming 
>> translation manually and get static checking that the method exists and is 
>> exposed to Objective-C.
>> 
>> This proposal composes with my “Generalized Naming for Any Function” 
>> proposal, which lets us name methods fully, including getters/setters:
>> 
>> let sel1: Selector = objc_selector(UIView.`insertSubview(_:at:)`) // 
>> produces the Selector “insertSubview:atIndex:"
>> let sel2: Selector = objc_selector(UIView.`frame.get`) // produces 
>> the Selector “frame"
>> 
>> I don’t like the `objc_selector` syntax at all, but otherwise I think this 
>> functionality is straightforward.
>> 
>> - Doug
>> 
>> ___
>> 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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Dec 27, 2015, at 8:34 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>>> On Dec 27, 2015, at 4:27 PM, John McCall  wrote:
>>> 
>>> On Dec 27, 2015, at 4:15 PM, Chris Lattner  wrote:
>>> 
>>> On Dec 27, 2015, at 4:09 PM, John McCall  wrote:
> I’m a fan of good error recovery, but I don’t think it is a major concern 
> here for two reasons:
> 
> 1) The most common case in a method will lack a label, and "thing.foo(_: 
> “ and “thing.foo(:” are both unambiguously a curried reference.
> 2) A common case of accidentally completing a nullary call (thing.foo() 
> vs thing.foo) will produce a type error.  We already produce good QoI for 
> an unapplied function - adding the inverse would be simple.
> 
> Further, it will be uncommon *in general* to form a curried reference, so 
> error recovery doesn’t have to be perfect in all the edge cases.  As with 
> other commenters, if it is at all possible to avoid the extra backticks, 
> I’d really prefer that.
 
 The concern, I think, is that a messed-up normal call might look like a 
 curried reference.
 
 My inclination would be to go the other way: if we get a syntax for this 
 that we like, I think we should use it for *all* curried member 
 references, and reject things like foo.bar in favor of foo.`bar`.  The 
 ability to write foo.bar for a method has always struck me as more clever 
 than wise, to be honest.
>>> 
>>> If you were to go that far, I’d suggest looking at this as a different 
>>> version of the “." operator.  If you resyntax curried to something else 
>>> like (just a strawman, intentionally ugly syntax):
>>> 
>>>foo.#bar
>>> 
>>> Then you’d get a nice property that the plain old dot operator always has 
>>> to be fully applied.  This certainly would be a win for error recovery.  
>>> Also, if you did this, you wouldn’t need the backticks from doug’s proposal 
>>> either for things like:
>>> 
>>>foo.#bar(param1:param2:)
>>> 
>>> either.
>> 
>> Right.  I really like this effect.
>> 
>> I’m not that bothered by requiring the backticks, especially because it 
>> generalizes well to non-member function references, which I’m not sure any 
>> sort of different-member-access syntax does.
> 
> I’m bothered by it because it overloads backtick to mean two things: 
> keywords-as-names, and annoying-sequences-of-tokens-as-names.  Either use 
> would be acceptable to me, but the fact that we have to support one nested 
> inside the other makes it pretty nasty.

In the context of this proposal, I think of backticks as delimiters around a 
generalized name. It's a generalization of today's notion that it's an escaped 
identifier; more like an escaped name. 

> -Chris
> 
> ___
> 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

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

[Douglas Gregor via swift-evolution]

> On Dec 27, 2015, at 12:27 AM, Frederick Kellison-Linn via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Given that someView.insertSubview(_:at:) can be correctly parsed, I would 
> strongly lean towards the no-backtick alternative mentioned at the end. I 
> feel as though the backticks end up looking very cluttered (particularly when 
> you get into the double-nested backticks), and it seems cleaner to be able to 
> reference a method as it was declared rather than having to add extra syntax.
> 
> In reference to the issues noted with this approach:
> 
> IMO, there is already enough syntactic difference between getters/setters and 
> normal methods to justify requiring a different syntax to reference them. For 
> instance, the # syntax could be used so that, button.currentTitle.get would 
> reference Optional.get, and button.currentTitle#get would reference 
> the getter. Or, button.`currentTitle.get` could reference the getter (i.e. 
> backticks are only required in cases that are ambiguous).
> 
> I also think it is reasonable to require that in the case of a method with no 
> arguments such as set.removeAllElements, the programmer be expected to know 
> the difference between the expression with and without the trailing 
> parenthesis. After all, that distinction already exists in the language, and 
> would not disappear with this proposed addition. If a parallel syntax for 
> referencing methods with no arguments is strongly desired, perhaps something 
> such as set.removeAllElements(:), set#removeAllElements(), or similar could 
> be used, though I think that the present system for referencing these methods 
> is sufficient.
> 
> Are there other obvious reasons why this alternative wouldn’t work? I think 
> it is the cleanest of the alternatives and avoids littering the code with 
> backticks.

Not having the back-ticks means that you will need to use contextual type 
information to disambiguate the zero-parameter case from other cases. For 
example:

class Foo {
func doSomething() { }
func doSomething(value: Int) { }
}

let fn = Foo.doSomething // ambiguous
let fn2 = Foo.doSomething(_:) // okay
let fn3: (Foo) -> () -> Void = Foo.doSomething // okay
let fn3: (Foo) -> (Int) -> Void = Foo.doSomething // okay

My general complaint with the “drop the backticks” approach is that it doesn’t 
solve the whole problem. Sure, it solves 95% of the problem with a little less 
syntax, but now you need to invent yet another mechanism to handle the other 
cases (#set, contextual type disambiguation, etc)… which seems inconsistent to 
me.

- Doug


> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> Hi all,
>> 
>> Here’s a proposal draft to allow one to name any function in Swift. In 
>> effect, it’s continuing the discussion of retrieving getters and setters as 
>> functions started by Michael Henson here:
>> 
>>  
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html
>>  
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>
>> 
>> the proposal follows, and is available here as well:
>> 
>>  
>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md
>>  
>> <https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md>
>> 
>> Comments appreciated!
>> 
>> Generalized Naming for Any Function
>> 
>> Proposal: SE- 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/-generalized-naming.md>
>> Author(s): Doug Gregor <https://github.com/DougGregor>
>> Status: Awaiting Review
>> Review manager: TBD
>>  
>> <https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/-generalized-naming.md#introduction>Introduction
>> 
>> Swift includes support for first-class functions, such that any function (or 
>> method) can be placed into a value of function type. However, it is not 
>> possible to specifically name every function that is part of a Swift 
>> program---one cannot provide the argument labels when naming a function, nor 
>> are property and subscript getters and setters referenceable. This proposal 
>> introduces a general syntax that allows one to name anything that is a 
>> function within Swift in an extensible manner.
>> 
>> Swift-evolution thread: Michael Henson started a thread about the 
>> getter