[swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0194 "Derived Collection of Enum Cases" begins now and runs 
through January 11, 2018. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.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/0194-derived-collection-of-enum-cases.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] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Douglas Gregor via swift-evolution]

> On Dec 1, 2017, at 9:37 AM, Chris Lattner  wrote:
> 
> On Dec 1, 2017, at 12:26 AM, Douglas Gregor  > wrote:
>>> On Nov 30, 2017, at 10:05 PM, Chris Lattner >> > wrote:
>>> Hi Doug,
>>> 
>>> Thank you for the detailed email.  I have been traveling today, so I 
>>> haven’t had a chance to respond until now.  I haven’t read the down-thread 
>>> emails, so I apologize if any of this was already discussed:
>>> 
 I think better interoperability with Python (and other OO languages in 
 widespread use) is a good goal, and I agree that the implementation of the 
 feature described is straight-forward and not terribly invasive in the 
 compiler.
>>> 
>>> Fantastic, I’m really pleased to hear that!  I only care about solving the 
>>> problem, so if we can find a good technical solution to the problems than 
>>> I’ll be happy.
> 
> After thinking about your email a bit more, I think I might understand the 
> disconnect we’re having.  I think we have different versions in mind of what 
> “success” looks like:
> 
> I believe your view is that people start using Python APIs from their Swift 
> code, but gradually add type annotations (either inline or in a sidecar 
> database) to make those APIs progressively more Swifty.  New features will be 
> added to Python (its type system, compilers, databases for common APIs, etc) 
> to improve this interoperability, along the lines of what we’ve done for 
> Objective-C over the years.  Fast forward several years, and large Python 
> libraries would be nice to use from Swift - perhaps nicer than they are to 
> use from Python itself.  This view aligns with what happened with Objective-C 
> <-> Swift interoperability.
> 
> In contrast, I’m specifically interested in developers in certain large 
> domains (e.g. data science and ML) which are “forced” to use Python because 
> that is where all the libraries are.  I have spoken to many of these sorts of 
> people, and a large number of them really *dislike* using Python for all the 
> obvious reasons (including the tooling issues you point out).  My view of 
> success is that we allow them to write all of *their code* in Swift, which 
> will lead to a massive quality of life benefit for these frustrated people.  
> You’re right that they will still chaff when using imported Python APIs 
> (which don’t feel “swifty” for LOTS of reasons - e.g. method naming and 
> design patterns), but my view is that this will provide incentive for these 
> people to provide a proper Swift implementation for these libraries over time.
> 
> In short, your end game is a pervasively intertwined Swift/Python world (like 
> ObjC and Swift are).  My view is that Swift holds Python at arm's length, and 
> wins over the hearts and minds of developers, leading to new Swift APIs 
> designed for Swift.

That’s not the end game I’m looking at. I’d rather make it feasible to generate 
Swift wrappers for Python libraries that fit well into Swift’s existing 
machinery. The complexity goes outside the compiler, with small extralinguistic 
tie-ins to make it work well.

> I’m not sure if you agree with that portrayal of your position, and if not, 
> I’m sorry and will try to understand another way.  However, if I’m close, 
> then I have several concerns about that vision and don’t believe the end-game 
> is achievable or better than what I’m proposing.  Consider:
> 
> - I don’t think there will be a lot of success getting people who *actually 
> love* Python to use Swift, unless there is already an extrinsic reason for 
> them to use it.
> - Type hints are not widely used in Python, and there are believable reasons 
> that they won’t ever be.  Because they are specifically poorly suited for 
> libraries, their use seems to be in “user’s own code” - but my proposal 
> solves this already!  See below for examples.
> - Even if type hints were widely adopted, it would require massive extensions 
> to them and to Python to make them be "good enough” to provide value for the 
> things you’re envisioning.  Analogs to instancetype, objc generics, lots of 
> the C macros, and many of the other things we’ve added to ObjC would have to 
> be added.
> - The Python community has no reason to do this work for the Swift community, 
> or accept changes to Python that are required to make this actually great.
> - Beyond the core type system, the Python and Objective-C languages work 
> extremely differently in other ways (e.g. lack of umbrella headers making 
> AnyObject-style dispatch questionable).
> - Even with those annotations and all the work, the APIs we’d end up with are 
> not going to be good Swift APIs.  I don’t think that “renamification” and 
> "IUO audits" would ever actually happen in practice, for example.
> - I believe the engineering effort required to implement this vision is so 
> massive (including the changes to Swift, 

Re: [swift-evolution] [RFC] Associated type inference

[Douglas Gregor via swift-evolution]

> On Dec 2, 2017, at 9:23 PM, Dave Abrahams <dabrah...@apple.com> wrote:
> 
> 
> On Nov 30, 2017, at 2:28 PM, Douglas Gregor via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> What’s a Good Solution Look Like?
>> Our current system for associated type inference and associated type 
>> defaults is buggy and complicated.
> 
> Well, that’s the problem, then.  Don’t worry, I won’t suggest that you simply 
> fix the implementation, because even if there weren’t bugs and the system 
> were predictable I’d still think we could improve the situation for users by 
> making associated type default declarations more explicit.
> 
>> The compiler gets it right often enough that people depend on it, but I 
>> don’t think anyone can reasonably be expected to puzzle out what’s going to 
>> happen, and this area is rife with bugs. If we were to design a new solution 
>> from scratch, what properties should it have?
>> 
>> It should allow the author of a protocol to provide reasonable defaults, so 
>> the user doesn’t have to write them
>> It shouldn’t require users to write typealiases for “obvious” cases, even 
>> when they aren’t due to defaults
>> It shouldn’t infer an inconsistent set of typealiases
>> It should be something that a competent Swift programmer could reason about 
>> when it will succeed, when and why it will fail, and what the resulting 
>> inferred typealiases would be
>> It should admit a reasonable implementation in the compiler that is 
>> performant and robust
> • It should cover all of the existing use cases.
> • It should not break code at this point.
> • We should have a migration strategy for existing code that avoids traps 
> like silent semantic changes.
> 
> My bullet is important to me; I don’t think existing use cases are 
> (inherently) so complex that we can sacrifice almost any of them and still 
> end up with a sufficiently useful system.  At the very least, existing use 
> cases provide the only guidance we really have as to what the feature should 
> do.

I honestly don’t feel like a have a good handle on all of the use cases for 
associated type inference, and it’s not something we can simply search for on 
GitHub. But I think it covers most of them—and Matthew and Greg’s positive 
feedback helps my confidence here. The biggest potential issue, I think, is 
that we’ll no longer infer associated types from default implementations, which 
protocol vendors might be relying on.

> 
> I think we need to acknowledge that my second bullet is unattainable, at 
> least if we want to improve type checking performance. Not breaking any code 
> means that given any existing code, the compiler would have to explore the 
> same solution space it currently does, and come up with the same answers.  
> Improving performance would require new  declarations to use totally optional 
> explicit syntax to prevent some explorations, and that’s an untenable user 
> experience.

Yes, I agree.

> Which brings me to my third bullet: unless we are willing to break the code 
> of protocol users (as opposed to vendors) we need to ensure that vendors can 
> confidently convert code to use the new system without changing semantics.

Yeah, (2) below is basically that feature.

>  
>> 
>> A Rough Proposal
>> I’ve been thinking about this for a bit, and I think there are three ways in 
>> which we should be able to infer an associated type witness:
>> 
>> Associated type defaults, which are specified with the associated type 
>> itself, e.g.,
>> 
>>   associatedtype Indices = DefaultIndices
>> 
>> These are easy to reason about for both the programmer and the compiler.
>> Typealiases in (possibly constrained) protocol extensions, e.g.,
>> 
>>   extension RandomAccessCollection where Index : Strideable, Index.Stride == 
>> IndexDistance {
>> typealias RandomAccessCollection.Indices = CountableRange
>>   }
>> 
>> I’m intentionally using some odd ‘.’ syntax here to indicate that this 
>> typealias is intended only to be found when trying to satisfy an associated 
>> type requirement, and is not a general typealias that could be found by 
>> normal name lookup. Let’s set the syntax bike shed aside for the moment. The 
>> primary advantage of this approach (vs. inferring Indices from “var Indices: 
>> CountableRange” in a constrained protocol extension) is that there’s 
>> a real typealias declaration that compiler and programmer alike can look at 
>> and reason about based just on the name “Indices”. 
>> 
>> Note that this mechanism technically obviates the need for (1), in the same 

Re: [swift-evolution] [RFC] Associated type inference

[Douglas Gregor via swift-evolution]

> On Dec 3, 2017, at 2:39 PM, Jens Persson <j...@bitcycle.com> wrote:
> 
> Would this help sorting out the behavior of typealiases in constrained 
> extensions?

Sadly, no.

> 
> If not, please ignore the following and accept my apologies for posting OT.
> 
> Typealiases in constrained extensions are - and have been, for a long time - 
> very broken.
> The following program (which is clearly crazy in several ways) compiles and 
> runs using the latest version of the compiler:
> 
> struct S {
>   var v: This
> }
> extension S where T == Int {
>   typealias This = Is
> }
> extension S where T == Bool {
>   typealias Is = Fine
> }
> extension S where T == String {
>   typealias Fine = T
> }
> let x = S(v: "uh")
> print(x.v) // uh
> 
> ( SR-5440 )
> The current behavior is so allowing and strange that I'm having trouble 
> seeing what the correct behavior would be if things worked as intended.

I’d said that “var v: This”, “typealias This = Is”, and “typealias Is = Fine” 
are ill-formed and the compiler should reject them. You should only be able to 
use types from another extension if your extra constraints imply the 
constraints of that extension. I *think* it’s actually a simple model, but it 
didn’t get implemented.

> For example should the following program still compile, and if so, should the 
> last line also compile (if uncommented)?
> 
> protocol P {
> associatedtype A = Int
> associatedtype B = Bool
> typealias C = Float
> }
> extension P where B == A {
> typealias C = String
> }

I think this should be ill-formed, because we shouldn’t allow two typealiases 
with the same name to “overload” within the same type.

> struct S<A, B> : P {
> var v: (A, B, C)
> }
> extension S where A == Int, B == Bool {
> typealias C = [String]
> }
> let s1 = S(v: (1, true, [""]))
> // let s2 = S(v: ("a", "b", "c")) // Not (currently) ok.
> 
> Again, sorry for the noise if this is unrelated to the discussion.

    - Doug

> /Jens
> 
> 
> On Sun, Dec 3, 2017 at 6:23 AM, Dave Abrahams via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
> On Nov 30, 2017, at 2:28 PM, Douglas Gregor via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> Hello Swift community,
>> 
>> Associated type inference, which is the process by which the Swift compiler 
>> attempts to infer typealiases to satisfy associated-type requirements based 
>> on other requirements, has caused both implementation problems and user 
>> confusion for a long time. Some of you might remember a previous (failed) 
>> attempt to remove this feature from the Swift language, in SE-0108 “Remove 
>> associated type inference”. 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md>
>>  
>> 
>> I’m not sure we can remove this feature outright (i.e., the concerns that 
>> sank that proposal are still absolutely valid), because it is so very 
>> convenient and a lot of user code likely depends on it in some form or 
>> other. So, here I’d like to describe the uses of the feature, its current 
>> (very problematic) implementation approach, and a half-baked proposal to 
>> narrow the scope of associated type inference to something that I think is 
>> more tractable. I need help with the design of this feature, because I feel 
>> like it’s going to be a delicate balance between implementability and 
>> expressiveness.
> 
> Aloha, Doug!
> 
>> 
>> A Motivating Example
>> As a motivating example, let’s consider a “minimal” random access collection:
>> 
>> struct MyCollection {
>> var contents: [T]
>> }
>> 
>> extension MyCollection: RandomAccessCollection {
>> var startIndex: Int { return contents.startIndex }
>> var endIndex: Int { return contents.endIndex }
>> subscript(index: Int) -> T { return contents[index] }
>> }
>> 
>> This is actually pretty awesome: by providing just two properties and a 
>> subscript, we get the full breadth of the random access collection API! This 
>> is relying heavily on associated type inference (for associated type 
>> requirements) and default implementations specified on protocol extensions. 
>> Without associated type inference, we would have had to write:
>> 
>> 
>> extension MyCollection: RandomAccessCollection {
>> typealias Element = T
>> typealias Index = Int
>> typealias Indices = Counta

Re: [swift-evolution] [RFC] Associated type inference

[Douglas Gregor via swift-evolution]

> On Dec 1, 2017, at 11:42 AM, Nevin Brackett-Rozinsky 
> <nevin.brackettrozin...@gmail.com> wrote:
> 
> On Thu, Nov 30, 2017 at 7:28 PM, Douglas Gregor via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> A Rough Proposal
> I’ve been thinking about this for a bit, and I think there are three ways in 
> which we should be able to infer an associated type witness:
> 
> Associated type defaults, which are specified with the associated type 
> itself, e.g.,
> 
>   associatedtype Indices = DefaultIndices
> 
> These are easy to reason about for both the programmer and the compiler.
> Typealiases in (possibly constrained) protocol extensions, e.g.,
> 
>   extension RandomAccessCollection where Index : Strideable, Index.Stride == 
> IndexDistance {
> typealias RandomAccessCollection.Indices = CountableRange
>   }
> 
> I’m intentionally using some odd ‘.’ syntax here to indicate that this 
> typealias is intended only to be found when trying to satisfy an associated 
> type requirement, and is not a general typealias that could be found by 
> normal name lookup. Let’s set the syntax bike shed aside for the moment. The 
> primary advantage of this approach (vs. inferring Indices from “var Indices: 
> CountableRange” in a constrained protocol extension) is that there’s a 
> real typealias declaration that compiler and programmer alike can look at and 
> reason about based just on the name “Indices”. 
> 
> Note that this mechanism technically obviates the need for (1), in the same 
> sense that default implementations in protocols 
> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-implementations-in-protocols->
>  are merely syntactic sugar.
> Declarations within the nominal type declaration or extension that declares 
> conformance to the protocol in question. This is generally the same approach 
> as described in “associated type inference” above, where we match 
> requirements of the protocol against declarations that could satisfy those 
> requirements and infer associated types from there. However, I want to turn 
> it around: instead of starting with the requirements of the protocol any 
> looking basically anywhere in the type or any protocol to which it conforms 
> (for implementations in protocol extensions), start with the declarations 
> that the user explicitly wrote at the point of the conformance and look for 
> requirements they might satisfy. For example, consider our initial example:
> 
>   extension MyCollection: RandomAccessCollection {
> var startIndex: Int { return contents.startIndex }
> var endIndex: Int { return contents.endIndex }
> subscript(index: Int) -> T { return contents[index] }
>   }
> 
> Since startIndex, endIndex, and subscript(_:) are declared in the same 
> extension that declares conformance to RandomAccessIterator, we should look 
> for requirements with the same name as these properties and subscript within 
> RandomAccessCollection (or any protocol it inherits) and infer Index := Int 
> and Element := T by matching the type signatures. This is still the most 
> magical inference rule, because there is no declaration named “Index” or 
> “Element” to look at. However, it is much narrower in scope than the current 
> implementation, because it’s only going to reason from the (probably small) 
> set of declarations that the user wrote alongside the conformance, so it’s 
> more likely to be intentional. Note that this is again nudging programmers 
> toward the style of programming where one puts one protocol conformance per 
> extension, which is admittedly my personal preference.
> 
> Thoughts?
> I think this approach is more predictable and more implementable than the 
> current model. I’m curious whether the above makes sense to someone other 
> than me, and whether it covers existing use cases well enough. Thoughts?
> 
>   - Doug
> 
> 
> How does this work with retroactive conformance, especially where all the 
> protocol requirements already exist on a type and an empty extension declares 
> conformance? For example, suppose Module A declares a protocol with 
> associated types, and Module B has a struct which naturally possesses all the 
> required members to conform (maybe B handles Double concretely, while A can 
> work with any FloatingPoint, or some such). As a client importing both 
> modules and providing an empty extension to conform B’s struct to A’s 
> protocol, will the associated types be inferred?

No, the associated types will not be inferred in this case. That will be a 
change in behavior (and a source compatibility regression).

> Also, have you considered the possibility of allowing protocol au

[swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md

Hello Swift Community,

The review of SE-0191 "Eliminate IndexDistance from Collection” ran from 
November 27…December 3, 2017. The proposal is accepted. Feedback for this 
simplification to the Collection protocols was positive.

Thank you to everyone who participated in the review!

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

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

[Douglas Gregor via swift-evolution]

> On Nov 29, 2017, at 9:21 AM, Wallacy via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Distances, yes... Count, not necessarily. 

It doesn’t really help you to have an extra bit of range for “count" that can’t 
be expressed in the distance, i.e., where c.count returns a value but 
c.distance(from: c.startIndex, to: c.endIndex) overflows.

- Doug

> 
> 
> Em qua, 29 de nov de 2017 às 15:17, Xiaodi Wu <xiaodi...@gmail.com 
> <mailto:xiaodi...@gmail.com>> escreveu:
> Distance must be signed, so it cannot be UInt.
> On Wed, Nov 29, 2017 at 11:14 Wallacy <walla...@gmail.com 
> <mailto:walla...@gmail.com>> wrote:
> I think is that's why some folks ask for count be UInt (or UInt64 when 
> appropriate) some time ago.
> 
> I dont know how solve this, but appear to be less painful than current 
> IndexDistance.
> 
> Em qua, 29 de nov de 2017 às 14:46, Ben Cohen via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> escreveu:
> You can argue the current status is a bug, but…
> 
> Welcome to Apple Swift version 4.0.1 (swiftlang-900.0.67 clang-900.0.38). 
> Type :help for assistance.
>   1> CountableRange.IndexDistance.self
> $R0: Int.Type = Int
>   2> (Int64.min..<Int64.max).count
> Execution interrupted. Enter code to recover and continue.
> 
>> On Nov 29, 2017, at 4:04 AM, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> So that we are all clear on the implications of this, if IndexDistance 
>> becomes Int, ranges of integers will stop conforming to Collection, because 
>> Int.min..> potentially many more.
>> 
>> This would entail nontrivial source breakage.
>> 
>> 
>> On Mon, Nov 27, 2017 at 22:02 Ben Cohen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> My suggestion would be: don’t have your Collection-like type conform to 
>> Collection. Give it collection-like methods if you want them, like an 
>> indexing and slicing subscript that takes an Int64. It can still conform to 
>> Sequence.
>> 
>> In practice, these “huge” collections will be mostly used concretely, so 
>> their Collection conformance doesn’t buy you much. The reality is that very 
>> few generic uses on these types will succeed. You get a few things like 
>> .first, .last etc. for free. But very few algorithms are written to handle > 
>> Int.max lengths (several in the std lib don’t) – it just isn’t practical. 
>> And meanwhile, this is a huge burden on many other use cases.
>> 
>> The existence of the memory mapped file case is hypothetical. I canvassed a 
>> bit on twitter for some use cases. The only one I got back was where someone 
>> was using IndexDistance to stash other information: but this isn’t really a 
>> legal use of IndexDistance, since it must be numerically castable to other 
>> integer types when needed which would be a lossy operation so at best, it 
>> would just be an optimization.
>> 
>>> On Nov 27, 2017, at 19:29, Nevin Brackett-Rozinsky via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> The proposal mentions one reasonable situation where a larger-than-Int type 
>>> would be useful, namely a Collection wrapping a memory-mapped file, being 
>>> used on 32-bit systems.
>>> 
>>> Is there a recommended migration strategy for this scenario?
>>> 
>>> Nevin
>>> 
>>> 
>>> On Mon, Nov 27, 2017 at 8:34 PM, Douglas Gregor via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> Hello Swift community,
>>> 
>>> The review of SE-0191 "Eliminate IndexDistance from Collection" begins now 
>>> and runs through December 3, 2017. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
>>>  
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.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. When replying, please try to keep the propo

Re: [swift-evolution] [RFC] Associated type inference

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Dec 2, 2017, at 1:37 PM, Matthew Johnson <matt...@anandabits.com> wrote:
> 
> 
>> On Nov 30, 2017, at 6:28 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hello Swift community,
>> 
>> Associated type inference, which is the process by which the Swift compiler 
>> attempts to infer typealiases to satisfy associated-type requirements based 
>> on other requirements, has caused both implementation problems and user 
>> confusion for a long time. Some of you might remember a previous (failed) 
>> attempt to remove this feature from the Swift language, in SE-0108 “Remove 
>> associated type inference”. 
>> 
>> I’m not sure we can remove this feature outright (i.e., the concerns that 
>> sank that proposal are still absolutely valid), because it is so very 
>> convenient and a lot of user code likely depends on it in some form or 
>> other. So, here I’d like to describe the uses of the feature, its current 
>> (very problematic) implementation approach, and a half-baked proposal to 
>> narrow the scope of associated type inference to something that I think is 
>> more tractable. I need help with the design of this feature, because I feel 
>> like it’s going to be a delicate balance between implementability and 
>> expressiveness.
>> 
>> A Motivating Example
>> As a motivating example, let’s consider a “minimal” random access collection:
>> 
>> struct MyCollection {
>> var contents: [T]
>> }
>> 
>> extension MyCollection: RandomAccessCollection {
>> var startIndex: Int { return contents.startIndex }
>> var endIndex: Int { return contents.endIndex }
>> subscript(index: Int) -> T { return contents[index] }
>> }
>> 
>> This is actually pretty awesome: by providing just two properties and a 
>> subscript, we get the full breadth of the random access collection API! This 
>> is relying heavily on associated type inference (for associated type 
>> requirements) and default implementations specified on protocol extensions. 
>> Without associated type inference, we would have had to write:
>> 
>> 
>> extension MyCollection: RandomAccessCollection {
>> typealias Element = T
>> typealias Index = Int
>> typealias Indices = CountableRange
>> typealias Iterator = IndexingIterator<MyCollection>
>> typealias SubSequence = RandomAccessSlice<MyCollection>
>> 
>> var startIndex: Int { return contents.startIndex }
>> var endIndex: Int { return contents.endIndex }
>> subscript(index: Int) -> T { return contents[index] }
>> }
>> 
>> where the bolded typealiases are currently inferred. It was worse back when 
>> we reviewed SE-0108, because IIRC there were a few underscored associated 
>> types (e.g., _Element) that have since been removed. Still, that’s a bit of 
>> additional work to define a “minimal” collection, and requires quite a bit 
>> more understanding: how do I know to choose IndexingIterator, and 
>> CountableRange, and RandomAccessSlice?
>> 
>> The issue would get worse with, e.g., SE-0174 “Change filter to return an 
>> associated type”, which adds an associated type Filtered that almost nobody 
>> will ever customize, and isn’t really fundamental to the way collections 
>> work. Adding Filtered to the standard library would be a source-breaking 
>> change, because users would have to write a typealias giving it its default.
>> 
>> Associated Type Defaults
>> One of the ways in which we avoid having to specify typealiases is to use 
>> associated type defaults. For example, the standard library contains 
>> associated type defaults for Indices, Iterator, and SubSequence. Let’s focus 
>> on Indices:
>> 
>> protocol Collection : Sequence {
>>   associatedtype Indices = DefaultIndices
>>   // ...
>> }
>> 
>> protocol BidirectionalCollection : Collection {
>>   associatedtype Indices = DefaultBidirectionalIndices
>>   // ...
>> }
>> 
>> protocol RandomAccessCollection : BidirectionalCollection {
>>   associatedtype Indices = DefaultRandomAccessIndices
>>   // ...
>> }
>> 
>> The basic idea here is that different protocols in the hierarchy provide 
>> different defaults, and you presumably want the default from the most 
>> specific protocol. If I define a type and make it conform to 
>> BidirectionalCollection, I’d expect to get DefaultBidirectionalIndices 
>> for Indices. If a define a type and make it conform to 

Re: [swift-evolution] [RFC] Associated type inference

[Douglas Gregor via swift-evolution]

> On Dec 1, 2017, at 10:07 AM, Greg Titus  wrote:
> 
> 
> 
>> On Dec 1, 2017, at 9:11 AM, Ben Langmuir via swift-evolution 
>> > wrote:
>> Hey Doug,
>> 
>> I'm very much in favour of reducing the scope of associated type inference.  
>> Can you outline why you believe that (3) is necessary?  If I am following 
>> correctly, if we had (1) and (2) the only thing you'd need to add to the 
>> "minimal collection" implementation would be a typealias for `Element`, 
>> which seems reasonable to me.
>> 
>> Ben
> 
> If nothing else, dropping (3) would be source breaking for 90%+ of current 
> associated type uses. Whereas even the very minimal inference in (3) probably 
> brings that figure down to 1% or so (outside of the stdlib, which would need 
> to adopt a bunch of (2)). Obviously these percentages are just my guesses and 
> not based on any real survey, but certainly would be the case for all Swift 
> code I’ve seen.

Many of the associated-type inference bugs I’ve seen were from people expecting 
something like (3), but the current implementation either fails to infer 
anything (the common case!) or we get inference from some seemingly-unrelated 
place. I included (3) specifically because I think taking away (3) will break 
source compatibility significantly (as Greg suggests)… and despite the fact 
that the complexity of implementation for (3) is fairly high.

- Doug


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

Re: [swift-evolution] [RFC] Associated type inference

[Douglas Gregor via swift-evolution]

> On Dec 1, 2017, at 9:11 AM, Ben Langmuir <blangm...@apple.com> wrote:
> 
>> 
>> On Nov 30, 2017, at 4:28 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hello Swift community,
>> 
>> Associated type inference, which is the process by which the Swift compiler 
>> attempts to infer typealiases to satisfy associated-type requirements based 
>> on other requirements, has caused both implementation problems and user 
>> confusion for a long time. Some of you might remember a previous (failed) 
>> attempt to remove this feature from the Swift language, in SE-0108 “Remove 
>> associated type inference”. 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md>
>>  
>> 
>> I’m not sure we can remove this feature outright (i.e., the concerns that 
>> sank that proposal are still absolutely valid), because it is so very 
>> convenient and a lot of user code likely depends on it in some form or 
>> other. So, here I’d like to describe the uses of the feature, its current 
>> (very problematic) implementation approach, and a half-baked proposal to 
>> narrow the scope of associated type inference to something that I think is 
>> more tractable. I need help with the design of this feature, because I feel 
>> like it’s going to be a delicate balance between implementability and 
>> expressiveness.
>> 
>> A Motivating Example
>> As a motivating example, let’s consider a “minimal” random access collection:
>> 
>> struct MyCollection {
>> var contents: [T]
>> }
>> 
>> extension MyCollection: RandomAccessCollection {
>> var startIndex: Int { return contents.startIndex }
>> var endIndex: Int { return contents.endIndex }
>> subscript(index: Int) -> T { return contents[index] }
>> }
>> 
>> This is actually pretty awesome: by providing just two properties and a 
>> subscript, we get the full breadth of the random access collection API! This 
>> is relying heavily on associated type inference (for associated type 
>> requirements) and default implementations specified on protocol extensions. 
>> Without associated type inference, we would have had to write:
>> 
>> 
>> extension MyCollection: RandomAccessCollection {
>> typealias Element = T
>> typealias Index = Int
>> typealias Indices = CountableRange
>> typealias Iterator = IndexingIterator<MyCollection>
>> typealias SubSequence = RandomAccessSlice<MyCollection>
>> 
>> var startIndex: Int { return contents.startIndex }
>> var endIndex: Int { return contents.endIndex }
>> subscript(index: Int) -> T { return contents[index] }
>> }
>> 
>> where the bolded typealiases are currently inferred. It was worse back when 
>> we reviewed SE-0108, because IIRC there were a few underscored associated 
>> types (e.g., _Element) that have since been removed. Still, that’s a bit of 
>> additional work to define a “minimal” collection, and requires quite a bit 
>> more understanding: how do I know to choose IndexingIterator, and 
>> CountableRange, and RandomAccessSlice?
>> 
>> The issue would get worse with, e.g., SE-0174 “Change filter to return an 
>> associated type” 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md>,
>>  which adds an associated type Filtered that almost nobody will ever 
>> customize, and isn’t really fundamental to the way collections work. Adding 
>> Filtered to the standard library would be a source-breaking change, because 
>> users would have to write a typealias giving it its default.
>> 
>> Associated Type Defaults
>> One of the ways in which we avoid having to specify typealiases is to use 
>> associated type defaults. For example, the standard library contains 
>> associated type defaults for Indices, Iterator, and SubSequence. Let’s focus 
>> on Indices:
>> 
>> protocol Collection : Sequence {
>>   associatedtype Indices = DefaultIndices
>>   // ...
>> }
>> 
>> protocol BidirectionalCollection : Collection {
>>   associatedtype Indices = DefaultBidirectionalIndices
>>   // ...
>> }
>> 
>> protocol RandomAccessCollection : BidirectionalCollection {
>>   associatedtype Indices = DefaultRandomAccessIndices
>>   // ...
>> }
>> 
>> The basic idea here is that different protocols in the hierarchy provide 
>> different defaults,

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Douglas Gregor via swift-evolution]

> On Dec 1, 2017, at 1:30 AM, Chris Lattner  wrote:
> 
>> On Dec 1, 2017, at 12:26 AM, Douglas Gregor > > wrote:
 Philosophy
> 
>>> More problematically for your argument: your preferred approach requires 
>>> the introduction of (something like) DynamicMemberLookupProtocol or 
>>> something like AnyObject-For-Python, so your proposal would be additive on 
>>> top of solving the core problem I’m trying to solve.  It isn’t an 
>>> alternative approach at all.
>> 
>> I wouldn’t say that’s my preferred approach. My preferred approach involves 
>> taking the method/property/etc. declarations that already exist in Python 
>> and mapping them into corresponding Swift declarations so we have something 
>> to find with name lookup. One could put all of these declarations on some 
>> PyVal struct or PythonObject and there would be no need for 
>> AnyObject-for-Python or DynamicMemberLookupProtocol.
> 
> You’re suggesting that the transitive closure of all Python methods and 
> properties be preprocessed into a single gigantic Swift PyVal type?  I guess 
> something like that could be done.

That’s effectively what Swift is already doing with AnyObject.

> I would be concerned because there are many N^2 or worse algorithms in the 
> Swift compiler would probably explode.

As noted above, we already do this for AnyObject with every @objc entity 
everywhere. The # of overloads for a given name is usually not so high that 
it’s a problem for the compiler.

>  It also doesn’t provide the great tooling experience that you’re seeking, 
> given that code completion would show everything in the Python universe, 
> which is not helpful.

It’s better for code completion to provide too much than to provide nothing at 
all. If code completion provides too much, typing a small number of characters 
will reduce the completion set down to something manageable quite fast.

> Further, it doesn’t provide a *better* experience than what I’m suggesting, 
> it seems strictly worse.  

>From my prior message, having the declarations of all Python methods and 
>properties available on PyVal makes Swift tooling work:

For the same working Swift code

  dog.add_trick(rollOver)

that calls into Python, the solution I’m proposing:

* Gave you the add_trick(<#trick#>) code completion with the number of 
parameters and their names
* Supports goto definition to jump to the wrapper method on PyVal
* Supports “quick help” to show the declaration of that wrapper method on 
PyVal, showing the documentation (docstring) and in which Python class it was 
declared.
* Supports indexing functionality so we can find the likely uses of “add_trick"

DynamicMemberLookup doesn’t gave any of those, because “add_trick” is just a 
string that looks like an identifier. Only the Python runtime can resolve.

> A preprocessing step prevents users from playfully importing random Python 
> modules into the Swift repl and playgrounds.

*At worst*, you invoke the tool from the command line to build the Swift module 
that corresponds to a given Python module.

py2swift 

We could absolutely introduce tooling hooks to make the compiler initiate that 
step.

>  It also seems worse for implementors (who will get a stream of new bugs 
> about compiler scalability).

To my knowledge, AnyObject lookup has not been a serious source of performance 
problems for the compiler. The global lookup table it requires was annoying to 
implement, but it’s just a symbol table.

> 
 Whenever we discuss adding more dynamic features to Swift, there’s a 
 strong focus on maintaining that strong static type system.
>>> 
>>> Which this does, by providing full type safety - unlike AnyObject lookup.
>> 
>> You get dynamic safety because it goes into the Python interpreter; fair 
>> enough. You get no help from your tools to form a correct invocation of any 
>> method provided by Python.
> 
> Sure, that’s status quo for Python APIs.

That’s not the status quo for Python IDEs. They will give you the basic shape 
of method calls.

> 
 Tooling
 The Python interoperability enabled by this proposal *does* look fairly 
 nice when you look at a small, correctly-written example. However, 
 absolutely none of the tooling assistance we rely on when writing such 
 code will work for Python interoperability. Examples:
 
 * As noted earlier, if you typo’d a name of a Python entity or passed the 
 wrong number of arguments to it, the compiler will not tell you: it’ll be 
 a runtime failure in the Python interpreter. I guess that’s what you’d get 
 if you were writing the code in Python, but Swift is supposed to be 
 *better* than Python if we’re to convince a community to use Swift instead.
 * Code completion won’t work, because Swift has no visibility into 
 declarations written in Python
 * Indexing/jump-to-definition/lookup documentation/generated interface 
 

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Douglas Gregor via swift-evolution]

> On Nov 30, 2017, at 10:05 PM, Chris Lattner  wrote:
> 
> Hi Doug,
> 
> Thank you for the detailed email.  I have been traveling today, so I haven’t 
> had a chance to respond until now.  I haven’t read the down-thread emails, so 
> I apologize if any of this was already discussed:
> 
>> I think better interoperability with Python (and other OO languages in 
>> widespread use) is a good goal, and I agree that the implementation of the 
>> feature described is straight-forward and not terribly invasive in the 
>> compiler.
> 
> Fantastic, I’m really pleased to hear that!  I only care about solving the 
> problem, so if we can find a good technical solution to the problems than 
> I’ll be happy.
> 
> A funny thing about swift-evolution is that it is populated with lots of 
> people who already use Swift and want to see incremental improvements, but 
> the people who *aren’t* using Swift yet (but should be) aren’t represented 
> here.  As you know, I’m perhaps the biggest proponent of Swift spreading into 
> new domains and earning the love of new users.

While I, too, am interested in attracting new users to Swift, it should not 
come at the cost of making the language less coherent.

>> However, I do not think this proposal is going in the right direction for 
>> Swift. I have objections on several different grounds.
> 
> Thanks for being up front about this.  It turns out that a majority of the 
> points you raise were brought up early in the pitch phases of the discussion, 
> but I screwed up by not capturing that discussion into the alternatives 
> section of the proposal.
> 
> Better late than never I guess: I just significantly revised the proposal, 
> adding a new “Alternative Python Interoperability Approaches” section.  I’d 
> appreciate it if you could read it and comment if you find any part 
> disagreeable:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#alternative-python-interoperability-approaches
>  
> 
> 
> Many of the points you make are discussed there, but I’ll respond 
> point-by-point below as well:
> 
>> Philosophy
>> Swift is, unabashedly, a strong statically-typed language.
> 
> That’s factually incorrect.

You’re going to have to explain that statement without reference to AnyObject 
(we’ll discuss that case below).

>> We don’t allow implicit down casting, we require “as?” so you have to cope 
>> with the possibility of failure (or use “as!” and think hard about the “!”). 
>> Even the gaping hole that is AnyObject dispatch still requires the existence 
>> of an @objc declaration and produces an optional lookup result, so the user 
>> must contend with the potential for dynamic failure.
> 
> AnyObject dispatch is one of the gaping holes for sure.  You don’t mention 
> it, but its lookup results are represented as *ImplicitlyUnwrappedOptional* 
> results, which do not force the user to contend with dynamic failure.  
> Further, unlike my proposal (which is fully type safe), AnyObject lookup is 
> not type safe at all.

As noted, AnyObject is a gaping hole, and the fact that it still produces an 
ImplicitlyUnwrappedOptional does make my statement weaker. It means you can 
dynamically end up with “unrecognized selector” without having acknowledged the 
possibility with a ‘!’.

>  It is also far more invasively intertwined throughout the compiler.

Not so much any more; there’s the weird lookup rule and some expression kinds 
that get mapped directly through to objc_msgSend.

> 
> More problematically for your argument: your preferred approach requires the 
> introduction of (something like) DynamicMemberLookupProtocol or something 
> like AnyObject-For-Python, so your proposal would be additive on top of 
> solving the core problem I’m trying to solve.  It isn’t an alternative 
> approach at all.

I wouldn’t say that’s my preferred approach. My preferred approach involves 
taking the method/property/etc. declarations that already exist in Python and 
mapping them into corresponding Swift declarations so we have something to find 
with name lookup. One could put all of these declarations on some PyVal struct 
or PythonObject and there would be no need for AnyObject-for-Python or 
DynamicMemberLookupProtocol.

>> Whenever we discuss adding more dynamic features to Swift, there’s a strong 
>> focus on maintaining that strong static type system.
> 
> Which this does, by providing full type safety - unlike AnyObject lookup.

You get dynamic safety because it goes into the Python interpreter; fair 
enough. You get no help from your tools to form a correct invocation of any 
method provided by Python.

> 
>> IMO, this proposal is a significant departure from the fundamental character 
>> of Swift, because it allows access to possibly-nonexistent members (as well 
>> as calls with incorrect arguments, in the related proposal) without any 

[swift-evolution] [RFC] Associated type inference

[Douglas Gregor via swift-evolution]

Hello Swift community,

Associated type inference, which is the process by which the Swift compiler 
attempts to infer typealiases to satisfy associated-type requirements based on 
other requirements, has caused both implementation problems and user confusion 
for a long time. Some of you might remember a previous (failed) attempt to 
remove this feature from the Swift language, in SE-0108 “Remove associated type 
inference”. 

 

I’m not sure we can remove this feature outright (i.e., the concerns that sank 
that proposal are still absolutely valid), because it is so very convenient and 
a lot of user code likely depends on it in some form or other. So, here I’d 
like to describe the uses of the feature, its current (very problematic) 
implementation approach, and a half-baked proposal to narrow the scope of 
associated type inference to something that I think is more tractable. I need 
help with the design of this feature, because I feel like it’s going to be a 
delicate balance between implementability and expressiveness.

A Motivating Example
As a motivating example, let’s consider a “minimal” random access collection:

struct MyCollection {
var contents: [T]
}

extension MyCollection: RandomAccessCollection {
var startIndex: Int { return contents.startIndex }
var endIndex: Int { return contents.endIndex }
subscript(index: Int) -> T { return contents[index] }
}

This is actually pretty awesome: by providing just two properties and a 
subscript, we get the full breadth of the random access collection API! This is 
relying heavily on associated type inference (for associated type requirements) 
and default implementations specified on protocol extensions. Without 
associated type inference, we would have had to write:


extension MyCollection: RandomAccessCollection {
typealias Element = T
typealias Index = Int
typealias Indices = CountableRange
typealias Iterator = IndexingIterator
typealias SubSequence = RandomAccessSlice

var startIndex: Int { return contents.startIndex }
var endIndex: Int { return contents.endIndex }
subscript(index: Int) -> T { return contents[index] }
}

where the bolded typealiases are currently inferred. It was worse back when we 
reviewed SE-0108, because IIRC there were a few underscored associated types 
(e.g., _Element) that have since been removed. Still, that’s a bit of 
additional work to define a “minimal” collection, and requires quite a bit more 
understanding: how do I know to choose IndexingIterator, and CountableRange, 
and RandomAccessSlice?

The issue would get worse with, e.g., SE-0174 “Change filter to return an 
associated type” 
,
 which adds an associated type Filtered that almost nobody will ever customize, 
and isn’t really fundamental to the way collections work. Adding Filtered to 
the standard library would be a source-breaking change, because users would 
have to write a typealias giving it its default.

Associated Type Defaults
One of the ways in which we avoid having to specify typealiases is to use 
associated type defaults. For example, the standard library contains associated 
type defaults for Indices, Iterator, and SubSequence. Let’s focus on Indices:

protocol Collection : Sequence {
  associatedtype Indices = DefaultIndices
  // ...
}

protocol BidirectionalCollection : Collection {
  associatedtype Indices = DefaultBidirectionalIndices
  // ...
}

protocol RandomAccessCollection : BidirectionalCollection {
  associatedtype Indices = DefaultRandomAccessIndices
  // ...
}

The basic idea here is that different protocols in the hierarchy provide 
different defaults, and you presumably want the default from the most specific 
protocol. If I define a type and make it conform to BidirectionalCollection, 
I’d expect to get DefaultBidirectionalIndices for Indices. If a define a 
type and make it conform to RandomAccessIterator, I’d expect to get 
DefaultRandomAccessIndices.

(Aside: DefaultRandomAccessIndices and DefaultBidirectionalIndices got 
collapsed into DefaultIndices now that we have conditional conformances for the 
standard library , but the issues 
I’m describing remain).

Associated type defaults seem like a reasonable feature that fits well enough 
into the design. However, it’s not the only thing in place with our 
MyCollection example, for which Indices was inferred to CountableRange. How’s 
that happen?

Associated Type Inference
Associated type inference attempts to look at the requirements of a protocol, 
and then looks into the conforming type for declarations that might satisfy 
those requirements, and infers associated types from the types of those 
declarations. Let’s look at some examples. RandomAccessCollection 

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Douglas Gregor via swift-evolution]

> On Nov 30, 2017, at 1:01 PM, Zach Wolfe <zacharyreidwo...@gmail.com> wrote:
> 
> Doug and others have brought up some great points, and I think Doug’s idea of 
> a common infrastructure for importing declarations from other languages is 
> _extremely_ attractive for the long-term future of Swift. 
> 
> However, unlike this proposal, that will (I imagine as a non-compiler 
> engineer) be a colossal undertaking, and as such it’s not going to make it 
> into Swift 5, or possibly even 6 or 7. I understand, then, Chris’s (and 
> other’s) desire to start interfacing with Python code now, not later. For me, 
> far and away the biggest problem with this proposal (and the only outright 
> deal-breaker) is that dynamic member lookups do not differentiate themselves 
> in any way from statically-checked member lookups syntactically. I don’t 
> object as strongly as others to the idea of adding this kind of dynamism to 
> the language, but if it’s going to be there, it should not be possible to 
> slightly misspell a static member name and end up with an unexpectedly 
> dynamic member that may or may not fail at compile-time.

As noted at the end of my message, I think one can write a Swift library to 
make working with the Python runtime much easier, and write a wrapper generator 
that produces Swift APIs from Python code that use said Swift library.

    - Doug

> 
> On Nov 30, 2017, at 2:24 AM, Douglas Gregor via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> 
>>> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I’d like to formally propose the inclusion of user-defined dynamic member 
>>> lookup types.
>>> 
>>> Here is my latest draft of the proposal:
>>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 
>>> <https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438>
>>> https://github.com/apple/swift-evolution/pull/768 
>>> <https://github.com/apple/swift-evolution/pull/768>
>>> 
>>> An implementation of this design is available here:
>>> https://github.com/apple/swift/pull/13076 
>>> <https://github.com/apple/swift/pull/13076>
>>> 
>>> The implementation is straight-forward and (IMO) non-invasive in the 
>>> compiler.
>> 
>> 
>> I think better interoperability with Python (and other OO languages in 
>> widespread use) is a good goal, and I agree that the implementation of the 
>> feature described is straight-forward and not terribly invasive in the 
>> compiler.
>> 
>> However, I do not think this proposal is going in the right direction for 
>> Swift. I have objections on several different grounds.
>> 
>> Philosophy
>> Swift is, unabashedly, a strong statically-typed language. We don’t allow 
>> implicit down casting, we require “as?” so you have to cope with the 
>> possibility of failure (or use “as!” and think hard about the “!”). Even the 
>> gaping hole that is AnyObject dispatch still requires the existence of an 
>> @objc declaration and produces an optional lookup result, so the user must 
>> contend with the potential for dynamic failure. Whenever we discuss adding 
>> more dynamic features to Swift, there’s a strong focus on maintaining that 
>> strong static type system.
>> 
>> IMO, this proposal is a significant departure from the fundamental character 
>> of Swift, because it allows access to possibly-nonexistent members (as well 
>> as calls with incorrect arguments, in the related proposal) without any 
>> indication that the operation might fail. It’s easy to fall through these 
>> cracks for any type that supports DynamicMemberLookupProtocol—a 
>> single-character typo when using a DynamicMemberLookupProtocol-capable type 
>> means you’ve fallen out of the safety that Swift provides. I think that’s a 
>> poor experience for the Python interoperability case, but more on that in 
>> the Tooling section below.
>> 
>> While we shouldn’t necessarily avoid a feature simply because it can be used 
>> distastefully, consider something like this:
>> 
>>  public extension NSObject :  DynamicMemberLookupProtocol, 
>> DynamicCallableProtocol { … }
>> 
>> that goes directly to the Objective-C runtime to resolve member lookups and 
>> calls—avoiding @objc, bridging headers, and so on. It’s almost frighteningly 
>> convenient, and one could imagine some mixed Objective-C/Swift code bases 
>> where this would

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Douglas Gregor via swift-evolution]

> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> I’d like to formally propose the inclusion of user-defined dynamic member 
> lookup types.
> 
> Here is my latest draft of the proposal:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> https://github.com/apple/swift-evolution/pull/768
> 
> An implementation of this design is available here:
> https://github.com/apple/swift/pull/13076
> 
> The implementation is straight-forward and (IMO) non-invasive in the compiler.


I think better interoperability with Python (and other OO languages in 
widespread use) is a good goal, and I agree that the implementation of the 
feature described is straight-forward and not terribly invasive in the compiler.

However, I do not think this proposal is going in the right direction for 
Swift. I have objections on several different grounds.

Philosophy
Swift is, unabashedly, a strong statically-typed language. We don’t allow 
implicit down casting, we require “as?” so you have to cope with the 
possibility of failure (or use “as!” and think hard about the “!”). Even the 
gaping hole that is AnyObject dispatch still requires the existence of an @objc 
declaration and produces an optional lookup result, so the user must contend 
with the potential for dynamic failure. Whenever we discuss adding more dynamic 
features to Swift, there’s a strong focus on maintaining that strong static 
type system.

IMO, this proposal is a significant departure from the fundamental character of 
Swift, because it allows access to possibly-nonexistent members (as well as 
calls with incorrect arguments, in the related proposal) without any indication 
that the operation might fail. It’s easy to fall through these cracks for any 
type that supports DynamicMemberLookupProtocol—a single-character typo when 
using a DynamicMemberLookupProtocol-capable type means you’ve fallen out of the 
safety that Swift provides. I think that’s a poor experience for the Python 
interoperability case, but more on that in the Tooling section below.

While we shouldn’t necessarily avoid a feature simply because it can be used 
distastefully, consider something like this:

public extension NSObject :  DynamicMemberLookupProtocol, 
DynamicCallableProtocol { … }

that goes directly to the Objective-C runtime to resolve member lookups and 
calls—avoiding @objc, bridging headers, and so on. It’s almost frighteningly 
convenient, and one could imagine some mixed Objective-C/Swift code bases where 
this would save a lot of typing (of code)… at the cost of losing static typing 
in the language. The presence of that one extension means I can no longer rely 
on the safety guarantees Swift normally provides, for any project that imports 
that extension and uses a subclass of NSObject. At best, we as a community 
decide “don’t do that”; at worse, some nontrivial fraction of the community 
decides that the benefits outweigh the costs (for this type or some other), and 
we can no longer say that Swift is a strong statically-typed language without 
adding “unless you’re using something that adopts DynamicMemberLookupProtocol”.

Tooling
The Python interoperability enabled by this proposal *does* look fairly nice 
when you look at a small, correctly-written example. However, absolutely none 
of the tooling assistance we rely on when writing such code will work for 
Python interoperability. Examples:

* As noted earlier, if you typo’d a name of a Python entity or passed the wrong 
number of arguments to it, the compiler will not tell you: it’ll be a runtime 
failure in the Python interpreter. I guess that’s what you’d get if you were 
writing the code in Python, but Swift is supposed to be *better* than Python if 
we’re to convince a community to use Swift instead.
* Code completion won’t work, because Swift has no visibility into declarations 
written in Python
* Indexing/jump-to-definition/lookup documentation/generated interface won’t 
ever work. None of the IDE features supported by SourceKit will work, which 
will be a significant regression for users coming from a Python-capable IDE.

Statically-typed languages should be a boon for tooling, but if a user coming 
from Python to Swift *because* it’s supposed to be a better development 
experience actually sees a significantly worse development experience, we’re 
not going to win them over. It’ll just feel inconsistent.

Dynamic Typing Features
It’s possible that the right evolutionary path for Swift involves some notion 
of dynamic typing, which would have a lot of the properties sought by this 
proposal (and the DynamicCallableProtocol one). If that is true—and I’m not at 
all convinced that it is—we shouldn’t accidentally fall into a suboptimal 
design by taking small, easy, steps. If we’re to include dynamic-typing 
facilities, we should look at more existing practice—C# ‘dynamic' is one such 
approach, but more promising would be some form 

Re: [swift-evolution] Feasibility of "T1 & ¬T2"

[Douglas Gregor via swift-evolution]

> On Nov 29, 2017, at 7:27 PM, Dave DeLong via swift-evolution 
>  wrote:
> 
> Hi SE,
> 
> I’m pondering some esoteric type stuff as I’m sketching out an improved 
> date/time library (https://github.com/davedelong/Chronology 
> ), and I’m wondering two things:
> 
> 1️⃣ Is there a way to express a type that does *not* conform to a protocol? 
> 
> For example, let’s say I have three protocols:
> 
> protocol YearHaving { var year: Int }
> protocol MonthHaving { var month: Int }
> protocol DayHaving { var day: Int }
> typealias DateHaving = YearHaving & MonthHaving & DayHaving
> 
> Now, I want to allow for some adjustments to values that have these types:
> 
> extension DayHaving {
> func removingDay() → Self & ¬DayHaving // whatever type “self” is, except 
> it does not conform to “DayHaving”, because you just removed the day value
> }
> 
> Is this possible?

There is no way to express this.

> 
> 2️⃣ If this is not possible, would it be hard to add something like this in?

It would not be hard, although do note that it can only check “there is no 
conformance of the type to the protocol visible from this module”; a 
conformance might be present in some other module, or might be loaded 
dynamically later on. It can also be “hidden” from the static type system:

func f(_: T) where ¬DayHaving { }
struct X { }
f(X()) // okay
struct Y : DayHaving { }
f(Y()) // error: Y conforms to DayHaving but shouldn’t

func g(_ t: T) { f(t) } // succeeds, because T is not known to conform to 
DayHaving
g(X()) // okay, as expected
g(Y()) // okay, but surprising

- Doug


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

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

[Douglas Gregor via swift-evolution]

> On Nov 26, 2017, at 9:21 PM, John McCall <rjmcc...@apple.com> wrote:
> 
>> 
>> On Nov 22, 2017, at 1:08 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Nov 22, 2017, at 9:48 AM, Chris Lattner <clatt...@nondot.org 
>> <mailto:clatt...@nondot.org>> wrote:
>> 
>>> IMO this is obvious and you should put it in.
>>> 
>>> The process serves a purpose: to ensure the evolution of the language is 
>>> going in the right place, both directionally in an details.  It is obvious 
>>> that we’re going to take this, and the details are clear, therefore doing 
>>> an evolution cycle for this would just waste everyone’s time.
>> 
>> I’ve been leaning this way as well. We can treat this small addition as an 
>> amendment to SE-0143 so the change is documented appropriately. 
> 
> Agreed.  I think bringing it up here and letting it "pass by acclamation" is 
> the appropriate process; doing a separate proposal would be a waste.

To close the loop here, the core team has agreed to this as an amendment to 
SE-0143, and the changed has been merged here:

https://github.com/apple/swift-evolution/pull/769

and we’ve merged the change into the Swift standard library for Swift 4.1, here:

https://github.com/apple/swift/pull/13046

- Doug

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

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

[Douglas Gregor via swift-evolution]

> On Nov 27, 2017, at 5:58 PM, Guillaume Lessard via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
>> On Nov 27, 2017, at 18:34, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0191 "Eliminate IndexDistance from Collection" begins now 
>> and runs through December 3, 2017. 
> [snip]
>> • What is your evaluation of the proposal?
> 
> I approve heartily.
> I previously complained about this on the swift-users list, making mostly the 
> same arguments against the idea of not using Int. The best argument against 
> that I know is a file-mapping collection on a 32-bit platform; if this 
> matters, IndexDistance could simply be Int64 instead of Int.

I’d like to point out that using Int64 would likely cause just as much 
numericCast'ing around as IndexDistance, so I don’t think that’s a viable 
alternative.

(Thanks for the review!)

- Doug

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

[swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0191 "Eliminate IndexDistance from Collection" begins now and 
runs through December 3, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.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/0191-eliminate-indexdistance.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

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

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Douglas Gregor via swift-evolution]

> On Nov 24, 2017, at 3:11 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> As mentioned in my prior message, I currently have a PR open to update the 
> generics manifesto (https://github.com/apple/swift/pull/13012 
> ).  I removed one topic from that 
> update at Doug Gregor’s request that it be discussed on the list first.  
> 
> The idea is to add the ability to make default arguments conditional (i.e. 
> depend on generic constraints).  It is currently possible to emulate 
> conditional default arguments using an overload set.  This is verbose, 
> especially when several arguments are involved.  Here is an example use case 
> using the overload method to emulate this feature:
> 
> ```swift
> protocol Resource {
>   associatedtype Configuration
>   associatedtype Action
> }
> struct ResourceDescription {
>   func makeResource(with configuration: R.Configuration, actionHandler: 
> @escaping (R.Action) -> Void) -> R {
> // create a resource using the provided configuration
> // connect the action handler
> // return the resource
>   }
> }
> 
> extension ResourceDescription where R.Configuration == Void {
>   func makeResource(actionHandler: @escaping (R.Action) -> Void) -> R {
> return makeResource(with: (), actionHandler: actionHandler)
>   }
> }
> 
> extension ResourceDescription where R.Action == Never {
>   func makeResource(with configuration: R.Configuration) -> R {
> return makeResource(with: configuration, actionHandler: { _ in })
>   }
> }
> 
> extension ResourceDescription where R.Configuration == Void, R.Action == 
> Never {
>   func makeResource() -> R {
> return makeResource(with: (), actionHandler: { _ in })
>   }
> }
> 
> ```
> 
> Adding language support for defining these more directly would eliminate a 
> lot of boilerplate and reduce the need for overloads.

If one could refer to `self` in a default argument (which is not a big 
problem), you could turn the default into a requirement itself… although it 
doesn’t *quite* work with your example as written because it would always need 
to be implemented somehow:

> protocol Resource {
>   associatedtype Configuration
>   associatedtype Action
func defaultConfiguration() -> Configuration
func defaultHandler() -> ((R.Action) -> Void)
> }


>  Doug mentioned that it may also help simplify associated type inference 
> (https://github.com/apple/swift/pull/13012#discussion_r152124535 
> ).

Oh, I thought this was something related to choosing a defaults for associated 
types, which might have helped with my current associated-type-inference 
quandary. The topic you actually wanted to discuss is disjoint (sorry).

- Doug


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Nov 24, 2017, at 4:06 PM, Chris Lattner <clatt...@nondot.org> wrote:
> 
>> On Nov 24, 2017, at 3:47 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> One could imagine adding a “curry” operation to function types:
> 
> Right, having non-nominal types participate in the generics system would be 
> undoubtably awesome! :)
> 
>> Or perhaps making metatypes Hashable so they can be used as keys into a 
>> Dictionary:
>> 
>>  extension T.Type: Hashable {
> 
> Ok, so you just happened to pick a simple one:

Yup. Try to make a nominal type to describe labeled tuples. 

> what is the benefit of plumbing knowledge of metatypes through the entire 
> generics system,

That’s not how one would implement this in the compiler. Most of the compiler 
doesn’t care whether the subject of a protocol conformance is a nominal type or 
not, and those scattered (but numerous) places that do care should be 
straightforward to generalize to include structural types. It’s not 
metatype-specific work.

> rather than define a “Swift.Metatype” type, and defining stuff against it?

It would be a nominal type in name only (pun intended!), with special cases 
throughout the compiler and ABI—like we have with Optional, except with poorer 
test coverage. Worse, unlike the generalization I discuss above, where one 
generalization refactoring makes all structural types work, we’d have to  put 
in all of the not-really-nominal hacks for each currently-structural type on a 
case-by-case basis. 

  - Doug

> 
> -Chris
> 
> 
> 
>>var hashValue: Int {
>>  return ObjectIdentifier(self).hashValue
>>}
>> 
>>   static func ==(lhs: T.Type, rhs: T.Type) -> Bool { /* standard library 
>> magic */ }
>>  }
>> 
>>- 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 22, 2017, at 2:59 PM, Mike Kluev <mike.kl...@gmail.com> wrote:
> 
> on Date: Tue, 21 Nov 2017 22:54:21 -0800 Douglas Gregor <dgre...@apple.com 
> <mailto:dgre...@apple.com>> wrote:
> 
> > On Nov 21, 2017, at 10:48 PM, David Hart <da...@hartbit.com 
> > <mailto:da...@hartbit.com>> wrote:
> >
> > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org> 
> > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> 
> > wrote:
> >
> >>
> >> I think it’s straightforward and less ugly to make structural types allow 
> >> extensions and protocol conformances.
> >
> > Can somebody explain to me what is less ugly about that? I would have 
> > naturally thought that the language would be simpler as a whole if there 
> > only existed nominal types and all structural types were just sugar over 
> > them.
> 
> See Thorsten’s response with, e.g.,
> 
>   Function<Double, InoutParam, Param>
> 
> which handles “inout” by adding wrappers around the parameter types (which 
> one would have to cope with in any user of Function), but still doesn’t 
> handle argument labels. To handle argument labels, we would need something 
> like strings as generic arguments. We’d also need to handle calling 
> conventions and anything else we invent for function types.
> 
> 
> can you outline how extensions and protocol conformances might look for 
> structural types? to compare the ugliness of both approaches.

There are some examples at


https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types

e.g., making all tuples of Equatable elements Equatable (which also mixes in 
conditional conformances and variadic generics):

extension<...Elements : Equatable> (Elements...) : Equatable { // 
extending the tuple type "(Elements...)" to be Equatable
}

One could imagine adding a “curry” operation to function types:

  extension<Param1, Param2, Result> (Param1, Param2) -> Result {
var curried: (Param1) -> (Param2) -> Result {
  return { (arg1: Param1) in { (arg2: Param2) in self(arg1, arg2) } }
}
  }

Or perhaps making metatypes Hashable so they can be used as keys into a 
Dictionary:

  extension T.Type: Hashable {
var hashValue: Int {
  return ObjectIdentifier(self).hashValue
}

   static func ==(lhs: T.Type, rhs: T.Type) -> Bool { /* standard library magic 
*/ }
  }

- Doug


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

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Nov 22, 2017, at 10:12 AM, Dave DeLong <sw...@davedelong.com> wrote:
> 
> 
> 
>> On Nov 21, 2017, at 11:51 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hi all,
>> 
>> We’re having a bit of a debate over the question of whether SE-0143 
>> “Conditional Conformances” actually proposes any standard library changes at 
>> all, or whether they should all be brought up separately. So, I’ll pitch the 
>> pieces that I’d love to put into 4.1 to see if they’re as obvious as I think 
>> they should be :)
>> 
>> Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary 
>> conform to Equatable when their type parameters are Equatable (and Set 
>> always conform to Equatable). Specifically, add to the standard library:
>> 
>>  extension Optional: Equatable where Wrapped: Equatable { /*== already 
>> exists */ }
>>  extension Array: Equatable where Element: Equatable { /*== already 
>> exists */ }
>>  extension ArraySlice: Equatable where Element: Equatable { /*== already 
>> exists */ }
>>  extension ContiguousArray: Equatable where Element: Equatable { /*== 
>> already exists */ }
>>  extension Dictionary: Equatable where Value: Equatable { /*== already 
>> exists */ }
>>  extension Set: Equatable { /*== already exists */ }
>> 
>> Motivation: we need these for ==/!= to properly compose. It’s a 
>> highly-requested feature and an obvious “first use” of conditional 
>> conformances for the standard library that is unlikely to break any code.
>> 
>> Implementation: https://github.com/apple/swift/pull/13046
>> 
>> Thoughts?
> 
> The reason these are on concrete types and not, say, Collection is because we 
> can’t conditionally conform protocols yet, right?

Right. SE-0143 has a discussion of this limitation. 

  - Doug

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

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Nov 22, 2017, at 9:48 AM, Chris Lattner <clatt...@nondot.org> wrote:
> 
> IMO this is obvious and you should put it in.
> 
> The process serves a purpose: to ensure the evolution of the language is 
> going in the right place, both directionally in an details.  It is obvious 
> that we’re going to take this, and the details are clear, therefore doing an 
> evolution cycle for this would just waste everyone’s time.

I’ve been leaning this way as well. We can treat this small addition as an 
amendment to SE-0143 so the change is documented appropriately. 

> 
> That said, when you get to less obvious introductions and start doing more 
> major consolidation and simplification of the stdlib, those changes may be 
> worthy of discussion to ensure the details are right.

Right. All of the consolidation of the various Slice and lazy types is big 
enough to warrant a proposal, for example. 

  - Doug

> 
> -Chris
> 
>> On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hi all,
>> 
>> We’re having a bit of a debate over the question of whether SE-0143 
>> “Conditional Conformances” actually proposes any standard library changes at 
>> all, or whether they should all be brought up separately. So, I’ll pitch the 
>> pieces that I’d love to put into 4.1 to see if they’re as obvious as I think 
>> they should be :)
>> 
>> Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary 
>> conform to Equatable when their type parameters are Equatable (and Set 
>> always conform to Equatable). Specifically, add to the standard library:
>> 
>>  extension Optional: Equatable where Wrapped: Equatable { /*== already 
>> exists */ }
>>  extension Array: Equatable where Element: Equatable { /*== already 
>> exists */ }
>>  extension ArraySlice: Equatable where Element: Equatable { /*== already 
>> exists */ }
>>  extension ContiguousArray: Equatable where Element: Equatable { /*== 
>> already exists */ }
>>  extension Dictionary: Equatable where Value: Equatable { /*== already 
>> exists */ }
>>  extension Set: Equatable { /*== already exists */ }
>> 
>> Motivation: we need these for ==/!= to properly compose. It’s a 
>> highly-requested feature and an obvious “first use” of conditional 
>> conformances for the standard library that is unlikely to break any code.
>> 
>> Implementation: https://github.com/apple/swift/pull/13046
>> 
>> Thoughts?
>> 
>> 
>>  - 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 21, 2017, at 10:48 PM, David Hart <da...@hartbit.com> wrote:
> 
> 
> 
> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> 
>>> On Nov 21, 2017, at 10:37 PM, Chris Lattner <clatt...@nondot.org 
>>> <mailto:clatt...@nondot.org>> wrote:
>>> 
>>> On Nov 21, 2017, at 9:25 PM, Douglas Gregor <dgre...@apple.com 
>>> <mailto:dgre...@apple.com>> wrote:
>>>>> Or alternatively, one could decide to make the generics system *only and 
>>>>> forever* work on nominal types, and make the syntactic sugar just be 
>>>>> sugar for named types like Swift.Tuple, Function, and Optional.  Either 
>>>>> design could work.
>>>> 
>>>> We don’t have a way to make it work for function types, though, because of 
>>>> parameter-passing conventions. Well, assuming we don’t invent something 
>>>> that allows:
>>>> 
>>>>Function<Double, inout String>
>>>> 
>>>> to exist in the type system. Tuple labels have a similar problem.
>>> 
>>> I’m totally aware of that and mentioned it upthread. 
>> 
>> Eh, sorry I missed it.
>> 
>>>  There are various encoding tricks that could make this work depending on 
>>> how you want to stretch the current generics system…
>> 
>> I think it’s straightforward and less ugly to make structural types allow 
>> extensions and protocol conformances.
> 
> Can somebody explain to me what is less ugly about that? I would have 
> naturally thought that the language would be simpler as a whole if there only 
> existed nominal types and all structural types were just sugar over them.

See Thorsten’s response with, e.g.,

  Function<Double, InoutParam, Param>

which handles “inout” by adding wrappers around the parameter types (which one 
would have to cope with in any user of Function), but still doesn’t handle 
argument labels. To handle argument labels, we would need something like 
strings as generic arguments. We’d also need to handle calling conventions and 
anything else we invent for function types.

- Doug


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

[swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

[Douglas Gregor via swift-evolution]

Hi all,

We’re having a bit of a debate  over 
the question of whether SE-0143 “Conditional Conformances” 

 actually proposes any standard library changes at all, or whether they should 
all be brought up separately. So, I’ll pitch the pieces that I’d love to put 
into 4.1 to see if they’re as obvious as I think they should be :)

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary 
conform to Equatable when their type parameters are Equatable (and Set always 
conform to Equatable). Specifically, add to the standard library:

extension Optional: Equatable where Wrapped: Equatable { /*== already 
exists */ }
extension Array: Equatable where Element: Equatable { /*== already 
exists */ }
extension ArraySlice: Equatable where Element: Equatable { /*== already 
exists */ }
extension ContiguousArray: Equatable where Element: Equatable { /*== 
already exists */ }
extension Dictionary: Equatable where Value: Equatable { /*== already 
exists */ }
extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a 
highly-requested feature and an obvious “first use” of conditional conformances 
for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?


- Doug

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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 21, 2017, at 10:37 PM, Chris Lattner  wrote:
> 
> On Nov 21, 2017, at 9:25 PM, Douglas Gregor  > wrote:
>>> Or alternatively, one could decide to make the generics system *only and 
>>> forever* work on nominal types, and make the syntactic sugar just be sugar 
>>> for named types like Swift.Tuple, Function, and Optional.  Either design 
>>> could work.
>> 
>> We don’t have a way to make it work for function types, though, because of 
>> parameter-passing conventions. Well, assuming we don’t invent something that 
>> allows:
>> 
>>  Function
>> 
>> to exist in the type system. Tuple labels have a similar problem.
> 
> I’m totally aware of that and mentioned it upthread.

Eh, sorry I missed it.

>  There are various encoding tricks that could make this work depending on how 
> you want to stretch the current generics system…

I think it’s straightforward and less ugly to make structural types allow 
extensions and protocol conformances.

- Doug


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 21, 2017, at 9:21 PM, Chris Lattner <clatt...@nondot.org> wrote:
> 
> 
> 
>> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Nov 21, 2017, at 3:46 PM, Tony Allevato <tony.allev...@gmail.com 
>> <mailto:tony.allev...@gmail.com>> wrote:
>> 
>>> Does that mean that once structural types can conform to protocols, would 
>>> the core team want to remove Optional as a nominal type and just use “T?”? 
>> 
>> Yes; at least, it’s a direction we’ve discussed a number of times. 
>> 
>>> Or has that ship sailed because of source compatibility and you just don’t 
>>> want to introduce any new nominals that shadow structurals?
>> 
>> typealias Optional = T?
>> 
>> Should address source compatibility. 
> 
> Or alternatively, one could decide to make the generics system *only and 
> forever* work on nominal types, and make the syntactic sugar just be sugar 
> for named types like Swift.Tuple, Function, and Optional.  Either design 
> could work.

We don’t have a way to make it work for function types, though, because of 
parameter-passing conventions. Well, assuming we don’t invent something that 
allows:

Function<Double, inout String>

to exist in the type system. Tuple labels have a similar problem.

- Doug


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Nov 21, 2017, at 3:46 PM, Tony Allevato <tony.allev...@gmail.com> wrote:
> 
> Does that mean that once structural types can conform to protocols, would the 
> core team want to remove Optional as a nominal type and just use “T?”?

Yes; at least, it’s a direction we’ve discussed a number of times. 

> Or has that ship sailed because of source compatibility and you just don’t 
> want to introduce any new nominals that shadow structurals?

typealias Optional = T?

Should address source compatibility. 

  - Doug

> 
>> On Tue, Nov 21, 2017 at 3:10 PM Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>>> On Nov 21, 2017, at 3:05 PM, Slava Pestov <spes...@apple.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Nov 21, 2017, at 6:02 PM, David Hart <da...@hartbit.com> wrote:
>>>> 
>>>> Can somebody explain to me what are 
>>>>  nominal and structural types and why Optional should really be a 
>>>> structural type?
>>> 
>>> Nominal types are structs, enums, protocols and classes. They have 
>>> declarations in source and are uniquely identified by their name. 
>>> Structural types are functions, meta types, protocol compositions, and 
>>> tuples.
>>> 
>>> The distinction is not as clear as you might think because as Chris said, 
>>> you can imagine tuple being implemented as ‘struct Tuple<T…>’, similarly 
>>> functions and meta types could also be written as such. It is mostly a 
>>> syntactic distinction in the language, but it has far-reaching consequences 
>>> in internal representations, which is why for now it would be tricky to 
>>> have structural types conform to protocols.
>> 
>> Right. Optionals are a tricky case because we wanted them to be nominal so 
>> we could write extensions on them and make them conform to protocols, but, 
>> they’re so integral to the language that they are really treated like a 
>> structural type.
>> 
>>  - 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 21, 2017, at 3:05 PM, Slava Pestov  wrote:
> 
> 
> 
>> On Nov 21, 2017, at 6:02 PM, David Hart > > wrote:
>> 
>> Can somebody explain to me what are 
>>  nominal and structural types and why Optional should really be a structural 
>> type?
> 
> Nominal types are structs, enums, protocols and classes. They have 
> declarations in source and are uniquely identified by their name. Structural 
> types are functions, meta types, protocol compositions, and tuples.
> 
> The distinction is not as clear as you might think because as Chris said, you 
> can imagine tuple being implemented as ‘struct Tuple’, similarly 
> functions and meta types could also be written as such. It is mostly a 
> syntactic distinction in the language, but it has far-reaching consequences 
> in internal representations, which is why for now it would be tricky to have 
> structural types conform to protocols.

Right. Optionals are a tricky case because we wanted them to be nominal so we 
could write extensions on them and make them conform to protocols, but, they’re 
so integral to the language that they are really treated like a structural type.

- Doug


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

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 20, 2017, at 6:07 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> This is something I've wanted to look at for a while. A few weeks ago I 
> pushed out https://github.com/apple/swift/pull/12598 
>  to extend the existing synthesis 
> to handle structs/enums when a field/payload has a tuple of things that are 
> Equatable/Hashable, and in that PR it was (rightly) observed, as Chris just 
> did, that making tuples conform to protocols would be a more general solution 
> that solves the same problem you want to solve here.
> 
> I'd love to dig into this more, but last time I experimented with it I got 
> stuck on places where the protocol conformance machinery expects 
> NominalTypeDecls, and I wasn't sure where the right place to hoist that logic 
> up to was (since tuples don't have a corresponding Decl from what I can 
> tell). Any pointers?

Tuples won’t have a corresponding Decl, because they’re structural. The 
protocol conformance machinery (e.g., the ConformanceLookupTable) would need to 
be generalized to cover the various kinds of types that can be made to conform 
to a protocol:  nominal types, function types, tuple types, metatypes, and 
protocol composition types. Similarly, the assumption that one can only write 
an extension on a nominal type is fairly widespread in the compiler.

All of these are fine refactors along the way, and could be used to improve the 
compiler long before we’re ready to turn it into a user-facing language feature.

- Doug

> 
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
> > wrote:
> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  > wrote:
>> the end goal here is to use tuples as a compatible currency type, to that 
>> end it makes sense for these three protocols to be handled as “compiler 
>> magic” and to disallow users from manually defining tuple conformances 
>> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and 
>> Comparable are special because they’re the basis for a lot of standard 
>> library functionality so i think the benefits of making this a special 
>> supported case outweigh the additional language opacity.
> 
> I understand your goal, but that compiler magic can’t exist until there is 
> something to hook it into.  Tuples can’t conform to protocols right now, so 
> there is nothing that can be synthesized.
> 
> -Chris
> 
> 
>> 
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner > > wrote:
>> 
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>>> > wrote:
>>> 
>>> when SE-185 
>>> 
>>>  went through swift evolution, it was agreed that the next logical step 
>>>  is 
>>> synthesizing these conformances for tuple types, though it was left out of 
>>> the original proposal to avoid mission creep. I think now is the time to 
>>> start thinking about this. i’m also tacking on Comparable to the other two 
>>> protocols because there is precedent in the language from SE-15 
>>> 
>>>  that tuple comparison is something that makes sense to write.
>>> 
>>> EHC conformance is even more important for tuples than it is for structs 
>>> because tuples effectively have no workaround whereas in structs, you could 
>>> just manually implement the conformance. 
>> 
>> In my opinion, you’re approaching this from the wrong direction.  The 
>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>> they could, synthesizing these conformances would be straight-forward.
>> 
>> If you’re interested in pushing this forward, the discussion is “how do 
>> non-nominal types like tuples and functions conform to protocols”?
>> 
>> -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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 20, 2017, at 6:17 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Yes, I agree, we need variadic generics before we can have tuples conform :-(

Well, we don’t *have* to have variadic generics to allow structural types to 
conform… it just composes really, really elegantly. One could certainly allow 
extensions of tuple types with fixed arity, which would then provide 
conditional conformances:

extension (T, U): Equatable {
  // ...
}

extension (T, U, V): Equatable {
  // ...
}

Yes, the variadic suggestion is more general and more elegant, but these are 
orthogonal features.

> At the end of the day, you want to be able to treat “(U, V, W)” as sugar for 
> Tuple just like we handle array sugar.  When that is possible, Tuple 
> is just a type like any other in the system (but we need variadics to express 
> it).
> 
> Once you have that, then you could write conformances in general, as well as 
> conditional conformances that depend on (e.g.) all the element types being 
> equatable.

As noted in my previous reply, we don’t need Tuple to make this work.

> We also need that to allow functions conform to protocols, because functions 
> aren’t "T1->T2” objects, the actual parameter list is an inseparable part of 
> the function type, and the parameter list needs variadics.

Variadics aren’t enough to fully generalize parameter lists, though, because 
they don’t capture calling conventions. It’s actually a bit of an issue for 
Swift, because something variadic like:

extension (Params…) -> Result { }

Isn’t going to work with “inout”, or with shared/owned (whatever is not the 
default).

- Doug

> 
> -Chris
> 
>> On Nov 20, 2017, at 6:10 PM, Slava Pestov > > wrote:
>> 
>> Ignoring synthesized conformances for a second, think about how you would 
>> manually implement a conformance of a tuple type to a protocol. You would 
>> need some way to statically “iterate” over all the component types of the 
>> tuple — in fact this is the same as having variadic generics.
>> 
>> If we had variadic generics, we could implement tuples conforming to 
>> protocols, either by refactoring the compiler to allow conforming types to 
>> be non-nominal, or by reworking things so that a tuple is a nominal type 
>> with a single variadic generic parameter.
>> 
>> Slava
>> 
>>> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
>>> > wrote:
>>> 
>>> This is something I've wanted to look at for a while. A few weeks ago I 
>>> pushed out https://github.com/apple/swift/pull/12598 
>>>  to extend the existing 
>>> synthesis to handle structs/enums when a field/payload has a tuple of 
>>> things that are Equatable/Hashable, and in that PR it was (rightly) 
>>> observed, as Chris just did, that making tuples conform to protocols would 
>>> be a more general solution that solves the same problem you want to solve 
>>> here.
>>> 
>>> I'd love to dig into this more, but last time I experimented with it I got 
>>> stuck on places where the protocol conformance machinery expects 
>>> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
>>> logic up to was (since tuples don't have a corresponding Decl from what I 
>>> can tell). Any pointers?
>>> 
>>> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
>>> > wrote:
>>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma >> > wrote:
 the end goal here is to use tuples as a compatible currency type, to that 
 end it makes sense for these three protocols to be handled as “compiler 
 magic” and to disallow users from manually defining tuple conformances 
 themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and 
 Comparable are special because they’re the basis for a lot of standard 
 library functionality so i think the benefits of making this a special 
 supported case outweigh the additional language opacity.
>>> 
>>> I understand your goal, but that compiler magic can’t exist until there is 
>>> something to hook it into.  Tuples can’t conform to protocols right now, so 
>>> there is nothing that can be synthesized.
>>> 
>>> -Chris
>>> 
>>> 
 
 On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner > wrote:
 
> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
> > wrote:
> 
> when SE-185 
> 
>  went through swift evolution, it was agreed that the next logical step 
> 

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Douglas Gregor via swift-evolution]

> On Nov 20, 2017, at 10:31 PM, Chris Lattner  wrote:
> 
> 
> 
>> On Nov 20, 2017, at 10:24 PM, David Hart > > wrote:
>> 
>> 
>> 
>> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>>> Yes, I agree, we need variadic generics before we can have tuples conform 
>>> :-(
>>> 
>>> At the end of the day, you want to be able to treat “(U, V, W)” as sugar 
>>> for Tuple just like we handle array sugar.  When that is possible, 
>>> Tuple is just a type like any other in the system (but we need variadics to 
>>> express it).
>> 
>> Eye-opening! Now I understand how important variadic generics are. Somebody 
>> should add that example to the Generics Manifesto.

It’s in there under “extensions of structural types”, here: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types

with this example:

extension<...Elements : Equatable> (Elements...) : Equatable { // 
extending the tuple type "(Elements...)" to be Equatable
}

>> Questions:
>> 
>> • Doesn’t this simplification of the type system hoist Variadic Generics 
>> back up the list of priorities?
> 
> Not above conditional and recursive conformances.

Right, and we don’t have bandwidth to take on Another Major Generics Feature 
this year.

> 
>> • Would it be desirable to implement them before ABI stability to “remove” 
>> tuples from the ABI?

Tuples are structural types in the ABI (and type system), and should remain 
that way. So, I disagree with Chris’s suggestion that (U, V, W) will become 
Tuple. The most relevant comparison today is Optional, which is 
technically a nominal type but is treated as a special case basically 
everywhere in the compiler (and ABI) because it should have been a structural 
type. I expect optionals to become structural types in the future (the ABI is 
designed for that) and tuples to remain structural types.

>> • If not, is the current ABI already flexible enough to support them if they 
>> are implemented later on?
> 
> I am not the expert on this (Doug Gregor is), but I think we can add it later 
> in an ABI additive way.

Yes, we can add it to the ABI later.

- Doug

> 
> -Chris
> 
> 
> 
> 
> 
>>> Once you have that, then you could write conformances in general, as well 
>>> as conditional conformances that depend on (e.g.) all the element types 
>>> being equatable.
>>> 
>>> 
>>> We also need that to allow functions conform to protocols, because 
>>> functions aren’t "T1->T2” objects, the actual parameter list is an 
>>> inseparable part of the function type, and the parameter list needs 
>>> variadics.
>>> 
>>> -Chris
>>> 
 On Nov 20, 2017, at 6:10 PM, Slava Pestov > wrote:
 
 Ignoring synthesized conformances for a second, think about how you would 
 manually implement a conformance of a tuple type to a protocol. You would 
 need some way to statically “iterate” over all the component types of the 
 tuple — in fact this is the same as having variadic generics.
 
 If we had variadic generics, we could implement tuples conforming to 
 protocols, either by refactoring the compiler to allow conforming types to 
 be non-nominal, or by reworking things so that a tuple is a nominal type 
 with a single variadic generic parameter.
 
 Slava
 
> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
> > wrote:
> 
> This is something I've wanted to look at for a while. A few weeks ago I 
> pushed out https://github.com/apple/swift/pull/12598 
>  to extend the existing 
> synthesis to handle structs/enums when a field/payload has a tuple of 
> things that are Equatable/Hashable, and in that PR it was (rightly) 
> observed, as Chris just did, that making tuples conform to protocols 
> would be a more general solution that solves the same problem you want to 
> solve here.
> 
> I'd love to dig into this more, but last time I experimented with it I 
> got stuck on places where the protocol conformance machinery expects 
> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
> logic up to was (since tuples don't have a corresponding Decl from what I 
> can tell). Any pointers?
> 
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
> > wrote:
> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  > wrote:
>> the end goal here is to use tuples as a compatible currency type, to 
>> that end it makes sense for these three protocols to be handled as 
>> “compiler 

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

[Douglas Gregor via swift-evolution]

> On Oct 30, 2017, at 9:43 PM, Chris Lattner  wrote:
> 
> JohnMC: question for you below.
> 
> On Oct 30, 2017, at 1:25 PM, Douglas Gregor  > wrote:
>>> 
>>> Thinking about the Perl case makes it clear to me that this should not be 
>>> built into the compiler as a monolithic thing.  Perl supports several 
>>> different types (SV/AV/HV) which represent different concepts (scalars, 
>>> arrays, hashes) so baking it all together into one thing would be the wrong 
>>> way to map it.  In fact, the magic we need is pretty small, and seems 
>>> generally useful for other things. Consider a design like this:
>>> 
>>> 
>>> // not magic, things like Int, String and many other conform to this. 
>>> protocol Pythonable {
>>>  init?(_ : PythonObject)
>>>  func toPython() -> PythonObject
>>> }
>> 
>> It’s not magic unless you expect the compiler or runtime to help with 
>> conversion between Int/String/etc. and PythonObject, as with 
>> _ObjectiveCBridgeable.
> 
> Right, as I said above “not magic”.  The conformances would be manually 
> implemented in the Python overlay.  This provides a free implicit conversion 
> from "T -> Pythonable” for the T’s we care about, and a failable init from 
> Python back to Swift types.

Note that, under this scheme,

let p: Pythonable = 17
let i: Int = p as! i

will work if Int is Pythonable, but not when p comes back from Python. 

> 
>>> // Not magic.
>>> struct PythonObject : /*protocols below*/ {
>>>   var state : UnsafePointer
>>> 
>>>   subscript(_ : Pythonable…) -> PythonObject {
>>> ...
>>>   }
>>> }
>>> 
>>> // Magic, must be on the struct definition.  
>>> // Could alternatively allow custom copy/move/… ctors like C++.
>>> protocol CustomValueWitnessTable {
>>>  static func init(..)
>>>  static func copy(..)
>>>  static func move(..)
>>>  static func destroy(..)
>>> }
>> 
>> Swift’s implementation model supports this. As a surface-level construct 
>> it’s going to be mired in UnsafeMutablePointers, and it’s not at all clear 
>> to me that we want this level of control there. 
> 
> There are two ways to implement it:
> 1) static func’s like the above, which are implemented as UnsafePointer's
> 2) Proper language syntax akin to the C++ “rule of 5”.
> 
> The pro’s and con’s of the first approach:
> 
> pro) full explicit control over what happens
> pro) no other new language features necessary to implement this.  The second 
> approach would need something like ownership to be in place.
> con) injects another avenue of unsafety (though it would be explicit, so it 
> isn’t that bad).  It isn’t obvious to me that approach #2 can be safe, but I 
> haven’t thought about it enough.
> ???) discourages people from using this protocol because of its explicit 
> unsafety.

con) much of the UnsafePointer interface is based on the value witness table, 
so one has to step lightly or work with something like 
COpaquePointer/UnsafePointer.

> 
> I can think of two things that could tip the scale of the discussion:
> 
> a) The big question is whether we *want* the ability to write custom 
> rule-of-5 style behavior for structs, or if we want it to only be used in 
> extreme cases (like bridging interop in this proposal).  If we *want* to 
> support it someday, then adding proper “safe” support is best (if possible).  
> If we don’t *want* people to use it, then making it Unsafe and ugly is a 
> reasonable way to go.
> 
> b) The ownership proposal is likely to add deinit's to structs.  If it also 
> adds explicit move initializers, then it is probably the right thing to add 
> copy initializers also (and thus go with approach #2).  That said,  I’m not 
> sure how the move initializers will be spelled or if that is the likely 
> direction.  If it won’t add these, then it is probably better to go with 
> approach #1.  John, what do you think?
> 
>> Presumably, binding to Python is going to require some compiler 
>> effort—defining how it is that Python objects are 
>> initialized/copied/moved/destroyed seems like a reasonable part of that 
>> effort.
> 
> Actually no.  If we add these three proposals, there is no other python (or 
> perl, etc…) specific support needed.  It is all implementable in the overlay.

Support for working with Python objects would be implementable in the overlay, 
but the result isn’t necessarily ergonomic (e.g., my “as!” case from a 
Python-generated integer object to Int, shown above). That might be fine! More 
comments on this below.

> 
>>> // Magic, allows anyobject-like member lookup on a type when lookup 
>>> otherwise fails.
>>> protocol DynamicMemberLookupable {
>>>   associatedtype MemberLookupResultType
>>>   func dynamicMemberLookup(_ : String) -> MemberLookupResultType
>>> }
>> 
>> AnyObject lookup looks for an actual declaration on any type anywhere. One 
>> could extend that mechanism to, say, return all Python methods and assume 
>> that you can call any Python 

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

[Douglas Gregor via swift-evolution]

> On Oct 30, 2017, at 2:54 PM, David Kopecky <dkope...@apple.com> wrote:
> 
> To Chris’s use case point, I see Python -> Swift interop as a very common use 
> case in data science / ML for speeding up certain functions/modules by 
> embedding Swift into Python, like you can with, say, ctypes or python 
> extensions in dynamic C libraries. This is very common practice in the Python 
> universe, it just could be a lot better with Swift instead.
> 
> Things like this *sort of* exist with Swift 
> (https://gist.github.com/jiaaro/e111f0f64d0cdb8aca38 
> <https://gist.github.com/jiaaro/e111f0f64d0cdb8aca38>), but it’s not really 
> very mature or functional.
> 
> I would LOVE to be able to speed up a lot of python code by implementing 
> swift libraries and importing into python. 

There are a bunch of ways one could export Swift functionality to Python, from 
a library solution like the C++ Boost.Python 
(http://www.boost.org/doc/libs/1_65_1/libs/python/doc/html/index.html 
<http://www.boost.org/doc/libs/1_65_1/libs/python/doc/html/index.html>), to 
code generators like SWIG or, with some future expansion of metadata, directly 
at runtime via reflection facilities. Python’s dynamic nature makes this 
direction easier.

The harder challenge (IMO!) is to get a Python library into Swift, because 
there isn’t a lot of type information in Python, so you have to show the Python 
in the much-more-strongly-typed Swift somehow (and keep it usable).

    - Doug

> 
> - David
> 
>> On Oct 30, 2017, at 13:25, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>>> On Oct 29, 2017, at 1:34 PM, Chris Lattner via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> 
>>>> On Oct 29, 2017, at 8:23 AM, Chris Lattner via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> 
>>>>> On Oct 29, 2017, at 4:04 AM, Lukas Stabe <lu...@stabe.de 
>>>>> <mailto:lu...@stabe.de>> wrote:
>>>>> 
>>>>>> On 28. Oct 2017, at 23:10, Chris Lattner via swift-evolution 
>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>> 
>>>>>> … which is to say, exactly identical to the Python version except that 
>>>>>> new variables need to be declared with let/var.  This can be done by 
>>>>>> blessing Python.Object (which is identical to “PyObject*” at the machine 
>>>>>> level) with some special dynamic name lookup behavior:  Dot syntax turns 
>>>>>> into a call to PyObject_GetAttrString, subscripts turn into 
>>>>>> PyObject_GetItem, calls turn into PyObject_Call, etc.  ARC would be 
>>>>>> implemented with INCREF etc.
>>>>> 
>>>>> That sounds like a very interesting prospect. Do you think it would make 
>>>>> sense to make the language features that facilitate this (dynamic 
>>>>> dispatch of method calls, property accesses, subscript and ARC) available 
>>>>> to Swift classes annotated in some way, so that interop like this can be 
>>>>> implemented as a library without special treatment by the Swift compiler? 
>>>>> This could also enable more dynamic DSL like features.
>>>> 
>>>> I haven’t explored enough of the design space to be sure, but I’d want to 
>>>> make sure that a library version of this could be done without giving up 
>>>> ergonomics of the result.  If you were interested in being able to interop 
>>>> with other languages that are dynamically typed and reference counted, 
>>>> then something like this could be possible in principle:
>>> 
>>> Thinking about the Perl case makes it clear to me that this should not be 
>>> built into the compiler as a monolithic thing.  Perl supports several 
>>> different types (SV/AV/HV) which represent different concepts (scalars, 
>>> arrays, hashes) so baking it all together into one thing would be the wrong 
>>> way to map it.  In fact, the magic we need is pretty small, and seems 
>>> generally useful for other things. Consider a design like this:
>>> 
>>> 
>>> // not magic, things like Int, String and many other conform to this. 
>>> protocol Pythonable {
>>>  init?(_ : PythonObject)
>>>  func toPython() -> PythonObject
>>> }
>>

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

[Douglas Gregor via swift-evolution]

> On Oct 29, 2017, at 1:34 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> 
>> On Oct 29, 2017, at 8:23 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Oct 29, 2017, at 4:04 AM, Lukas Stabe  wrote:
>>> 
 On 28. Oct 2017, at 23:10, Chris Lattner via swift-evolution 
  wrote:
 
 … which is to say, exactly identical to the Python version except that new 
 variables need to be declared with let/var.  This can be done by blessing 
 Python.Object (which is identical to “PyObject*” at the machine level) 
 with some special dynamic name lookup behavior:  Dot syntax turns into a 
 call to PyObject_GetAttrString, subscripts turn into PyObject_GetItem, 
 calls turn into PyObject_Call, etc.  ARC would be implemented with INCREF 
 etc.
>>> 
>>> That sounds like a very interesting prospect. Do you think it would make 
>>> sense to make the language features that facilitate this (dynamic dispatch 
>>> of method calls, property accesses, subscript and ARC) available to Swift 
>>> classes annotated in some way, so that interop like this can be implemented 
>>> as a library without special treatment by the Swift compiler? This could 
>>> also enable more dynamic DSL like features.
>> 
>> I haven’t explored enough of the design space to be sure, but I’d want to 
>> make sure that a library version of this could be done without giving up 
>> ergonomics of the result.  If you were interested in being able to interop 
>> with other languages that are dynamically typed and reference counted, then 
>> something like this could be possible in principle:
> 
> Thinking about the Perl case makes it clear to me that this should not be 
> built into the compiler as a monolithic thing.  Perl supports several 
> different types (SV/AV/HV) which represent different concepts (scalars, 
> arrays, hashes) so baking it all together into one thing would be the wrong 
> way to map it.  In fact, the magic we need is pretty small, and seems 
> generally useful for other things. Consider a design like this:
> 
> 
> // not magic, things like Int, String and many other conform to this. 
> protocol Pythonable {
>  init?(_ : PythonObject)
>  func toPython() -> PythonObject
> }

It’s not magic unless you expect the compiler or runtime to help with 
conversion between Int/String/etc. and PythonObject, as with 
_ObjectiveCBridgeable.

> 
> // Not magic.
> struct PythonObject : /*protocols below*/ {
>   var state : UnsafePointer
> 
>   subscript(_ : Pythonable…) -> PythonObject {
> ...
>   }
> }
> 
> // Magic, must be on the struct definition.  
> // Could alternatively allow custom copy/move/… ctors like C++.
> protocol CustomValueWitnessTable {
>  static func init(..)
>  static func copy(..)
>  static func move(..)
>  static func destroy(..)
> }

Swift’s implementation model supports this. As a surface-level construct it’s 
going to be mired in UnsafeMutablePointers, and it’s not at all clear to me 
that we want this level of control there. Presumably, binding to Python is 
going to require some compiler effort—defining how it is that Python objects 
are initialized/copied/moved/destroyed seems like a reasonable part of that 
effort.

> // Magic, allows anyobject-like member lookup on a type when lookup otherwise 
> fails.
> protocol DynamicMemberLookupable {
>   associatedtype MemberLookupResultType
>   func dynamicMemberLookup(_ : String) -> MemberLookupResultType
> }

AnyObject lookup looks for an actual declaration on any type anywhere. One 
could extend that mechanism to, say, return all Python methods and assume that 
you can call any Python method with any PythonObject instance. AnyObject lookup 
is fairly unprincipled as a language feature, because there’s no natural scope 
in which to perform name lookup, and involves hacks at many levels that don’t 
always work (e.g., AnyObject lookup… sometimes… fails across multiple source 
files for hard-to-explain reasons). You’re taking on that brokenness if you 
expand AnyObject lookup to another ecosystem.

Although it doesn’t really seem like AnyObject lookup is the thing you’re 
asking for here. It seems more like you want dynamicMemberLookup(_:) to capture 
“self” and the method name, and then be a callable thing as below...

> 
> // Magic, allows “overloaded/sugared postfix ()”.
> protocol CustomCallable {
>  func call( …)
> }
> 
> The only tricky thing about this is the call part of things.  At least in the 
> case of python, we want something like this:
> 
>   foo.bar(1, 2, a: x, b: y)
> 
> to turn into:
>  foo.dynamicMemberLookup(“bar”).call(1, 2, kwargs: [“a”:x, “b”:y])
> 
> We don’t want this to be a memberlookup of a value that has “bar” as a 
> basename and “a:” and “b:” as parameter labels.

Well, I think the MemberLookupResult is going to get the name “bar”, argument 
labels “_:_:a:b:”, and arguments “1”, “2”, “x”, “y”, 

[swift-evolution] [Accepted with revisions] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

[Douglas Gregor via swift-evolution]

Hello Swift community,

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md

The review of SE-0184 "Unsafe[Mutable][Raw][Buffer]Pointer: add missing 
methods, adjust existing labels for clarity, and remove deallocation size” 
officially ran September 1…7, 2017. It was a large proposal for which most 
parts received a lot of support, while other parts were contentious. The 
proposal is accepted with revisions:

* Partial initialization/assignment will be removed from this proposal and 
discussed separataely
* Some argument labels will be changed for clarity (“bytes” -> “byteCount”, 
“alignedTo” -> “alignment”)
* The “count” argument to deallocate() will be removed entirely

The proposal has already been updated to reflect these changes. Thank you to 
the proposal author and everyone who participated in the discussion.

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

Re: [swift-evolution] Problems with generics - should be fixed for Xcode 9?

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Sep 16, 2017, at 6:32 AM, Joanna Carter via swift-evolution 
>  wrote:
> 
> Greetings
> 
> Old chestnut, sort of partially solved but still problems.
> 
> Now we can nest types in generic types, what I want is :
> 
> class Event
> {
>  class Args
>  {
>public static let empty = Args() // error : Static stored properties not 
> supported in generic types
>  }
> }
> 
> But the static let is not directly in the generic class.

It's still generic, though, because of the outer generic class, so there is a 
different static var for each specialization. For example, the following assert 
would fail:

  assert(Event.Args.empty === Event.Args.empty)



> 
> So, I end up doing another convoluted workaround in the shape of :
> 
> class Event
> {
>  class Args
>  {
>public static var empty: Args
>{
>  return Args()
>}
>  }
> }
> 
> The main difference is that I have to create a new instance on every call to 
> Args.empty instead of returning the same one.
> 
> Is this an oversight or as intended, with the hope of fixing it in a future 
> version

I'd say we consider it a bug. 

  - Doug

> 
> Joanna
> 
> --
> Joanna Carter
> Carter Consulting
> 
> ___
> 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-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0184 "Unsafe[Mutable][Raw][Buffer]Pointer: add missing 
methods, adjust existing labels for clarity, and remove deallocation size" 
begins now and runs through September 7, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.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/0184-unsafe-pointers-add-missing.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

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

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

[Douglas Gregor via swift-evolution]

> On Jun 16, 2017, at 11:21 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> The described problem might be one of the most famous itches of the language, 
> but imho the bar for new keywords* should be higher than that — and there are 
> alternatives:
> 
> First, I guess many would like to see this to be valid Swift:
> 
> protocol Foo {
>   func bar() {
>   print("Default implementation called")
>   }
> }
> 
> It's the most convenient way of avoiding typos: avoid to type ;-)

Absolutely. This is the more natural way to describe most default 
implementations; it’s more concise and eliminates the possibility of errors for 
the common case.

> Imho this might already be enough, but for a full alternative for "default", 
> I'd suggest something like this:
> 
> extension Foo {
>   func Foo.bar() {
>   print("String has its own implementation")
>   }
> }

On top of your first syntax, this would be useful when the extension is further 
constrained, e.g.,

extension Foo where Self: Comparable {
  func Foo.bar() {
print(“I use Comparable for my Foo”)
  }
}


> (to make it more familiar for those with a C++ background, "Foo::bar" could 
> be used instead ;-)

Joking aside, “Foo::bar” has one advantage if it’s applied universally: it’s 
unambiguous if we allow it in method references. For example, we could say

someString.Foo::bar()

to mean “call the function that String used to satisfy the requirement 
Foo.bar()”. If instead it were

someString.Foo.Foo.bar()

it looks like we’re referring to a member named “Foo” within String, and a 
“bar” inside that. One would end up having to write the example differently, 
e.g.,

(someString as Foo).bar()

C# has set some precedent for using “.” when declaring the function, though, 
and there are obvious advantages to not introducing a new sigil like “::” into 
Swift because it brings complexity and the potential for confusion with “.”.

> 
> Additional benefit: This wouldn't be limited to protocols — and it could 
> possibly help in weird situations when two protocols declare functions with 
> identical signature...
> 
> extension String: Foo {
>   func Foo.bar() {
>   print("String has its own implementation")
>   }
> 
>   func Foo.barr() {
>   // compiler error, Foo defines no function "barr"
>   }
> 
>   func barr() {
>   // this is fine, no connection to a protocol
>   }
> }

Absolutely.

Thanks for writing this up, Tino; I was going to send a very similar response :)

- Doug

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

Re: [swift-evolution] Preparing Swift compiler stage reentrancy in preparation for "constexpr"

[Douglas Gregor via swift-evolution]

> On Aug 19, 2017, at 12:27 PM, Daryle Walker via swift-evolution 
>  wrote:
> 
> [I’m not sure which list should cover this.]
> 
> I once thought of having a “#protocols(SomeTypeOrProtocol)” that was a type 
> alias to a composition of all protocols the given type/protocol conforms to 
> (or “Any” if none). It seems simple, but all current uses of protocols 
> requires explicit mentions by the user, while this new facility would require 
> looking back at the table of existing protocols.

This is plausible to implement at run-time by inspecting the table of protocol 
conformances. It won’t be a static result, though, because one could dlopen() a 
shared library that introduces new conformances for existing types.

> 
> It seems that implementing something like C++’s “constexpr” would have the 
> same problem. The compiler stages can’t be one way anymore; a non-literal 
> that’s needed for a compile-time context has to be deferred until its 
> components can be evaluated in compile-time contexts (down to literals). So 
> we would partially evaluate down to SIL, run the SIL in the compiler’s 
> environment to determine all the compile-time data (not a big deal for 
> discrete data, but we’ll have to ignore differences between the compiler’s 
> environment and the target platform’s environment w.r.t. floating-point 
> processing), then go back to the semantic phase to fill in the “constexpr” 
> constants and evaluate the SIL again, possibly taking several cycles 
> depending how deep “constexpr” is needed.

You’re thinking in C++ terms. In Swift, it might be more reasonable to think of 
“constexpr” as something that will be guaranteed to become a constant at some 
point in the SIL pipeline (as part of the “guaranteed” transformations we 
perform for diagnostic generation from SIL), but that the actual constexpr 
value would be kept as an abstract expression in earlier stages of the 
pipeline. John McCall made this point better than I in the earlier discussions 
of constexpr (a few weeks ago).

> 
> As an example, take a mythical function that converts a mythical 
> one-dimensional fixed-size array to a tuple:
> 
> func tuple(from: [N; T]) -> ( #dup(N ; T) )
> 
> We would have to defer the return type until each call of “tuple(from:)”, 
> where we look at the input’s type’s shape to determine N, then expand the 
> #dup, then run the semantic phase again with the final type. What if N itself 
> was based off a “constexpr” function? Then we would need (at least) two 
> passes.
> 
> Should we start preparing the compiler stages for loopback now? Or do we have 
> to figure out what exactly we want “Swift constexpr” to mean first?

The latter. We should consider that it might be absolutely fine for Swift to 
effectively be dependently-typed up until some point in the pipeline, and that 
might fit better in the language model than introducing circularity.

- Doug


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

Re: [swift-evolution] Constrained Protocol Aliases

[Douglas Gregor via swift-evolution]

> On Aug 21, 2017, at 5:51 AM, David Hart  wrote:
> 
> 
>> On 21 Aug 2017, at 13:36, Adrian Zubarev > > wrote:
>> 
>> It’s part of Generalized Existentials, but does not make it complete. I 
>> think it would be worth adding more and more functionality to existentials 
>> every year. We started first with reshaping the syntax. This year we added 
>> support for classes. I think next year would be good to have where clause 
>> support for typealiases. 
>> 
>> I understand the complexity of that particular feature, and it’s a no-go for 
>> me to help on the implementation, but I’m willing to drive the discussion 
>> and the proposal forward with other co-authors. :)
>> 
>> Hasn’t it been said that the implementation must be at least a 
>> *proof-of-concept* if the complexity is very high?
>> 
> I’d love to have this feature. But I’m not sure even a partway proposal will 
> get to review with the laser-focus on ABI Stability + Concurrency. I don’t 
> want to spend time co-authoring a proposal if it is going to be out of scope 
> anyway. Perhaps Doug (CC) can give us some ideas.

The main issue is the implementation: it’s a nontrivial feature with impact on 
the AST, type checker, SIL, IR generation, type metadata, and runtime. On the 
other hand, it’s one of these features that’s 95% testable refactoring: one can 
plumb the notion of “generalized existential” through the whole compiler as a 
generalization of the existing existential types. The core abstraction needed 
to capture the requirements on the existential (GenericSignature) is already 
there in the compiler for generics, and much of the task is to generalize (as 
appropriate) and use that machinery for existentials.

It’s not an easy feature, but there are many capable people who could do it, 
and of course we’ll be happy to give guidance/review over on swift-dev if 
someone would like to work on it. The refactoring I mentioned could be 
developed on master (incrementally) as a general improvement to the compiler, 
so the implementation of the feature itself is a small, more 
syntactically-focused separate piece.
>> And my second question is: Wouldn’t the existence of this feature reshape 
>> some parts of the standard library, isn’t that affecting some major goals of 
>> Swift 5?
>> 
> Yes. But that also true of many other language feature. But the Standard 
> Library still needs to be set in stone at some point or another.

Generalized existentials would affect some parts of the standard library (e.g., 
they’d be a better way to implement AnyCollection et al), but generalized 
existentials are not a game-changer for the design.
>> It would be nice if someone from the core team can clarify if the where 
>> clause is out of scope for Swift 5 or not.
>> 
> Agreed.

It’s not “out of scope”, but everything hinges on the implementation task.

- Doug

> 
>> 
>> Am 21. August 2017 um 12:51:48, David Hart (da...@hartbit.com 
>> ) schrieb:
>> 
>>> 
 On 21 Aug 2017, at 11:41, Adrian Zubarev > wrote:
 
 Yes, `where` clause is welcome to typealises (including generic ones) and 
 existentials in general. I would love to help on such proposal. I think 
 David Hart is also interested in this one. (cc)
>>> 
>>> Yes, this basically seems like Generalized Existentials to me and is 
>>> mentioned in the Generics Manifesto 
>>> . 
>>> It’s a feature I hold very dear but:
>>> 
>>> It’s a very difficult feature to implement and I think Doug Gregor is the 
>>> only/best person to do it
>>> I think its pretty much out of scope for Swift 5 (it’s not required for ABI 
>>> Stability)
>>> 
>>> As a result, I’d be very surprised if this topic got any discussion or 
>>> implementation time during the Swift 5 timeframe.
 Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution 
 (swift-evolution@swift.org ) schrieb:
 
> Hello, Swift community!
> 
> I'd like to start a discussion about a possibility of constrained 
> protocol aliases. The declaration would look like this:
> 
> typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
> RangeReplaceableCollection where Binary.Index == Int, Binary.Element == 
> Bool
> 
> The syntax and semantics of this declaration are exactly the same as an 
> analogous associatedtype declaration inside a protocol.
> In the example above, the type BinaryProtocol represents a logical array 
> of bits and is a generic-only protocol that is usable in any context 
> where an integer-indexed mutable range-replaceable random-access 
> collection is expected.
> Now, it can be used in a very concise and elegant way:
> 
> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Aug 9, 2017, at 10:37 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Well, if there is one, then I apologize for bothering anyone. I just assumed 
> it would be included in the proposal itself, and I couldn't find it myself.  
> ;)

This is a good point. We'll update the proposal template with a link to the 
implementation. 

  - Doug

> 
> Thank you David.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> Am 10. August 2017 um 07:30:16, David Hart (da...@hartbit.com) schrieb:
> 
>> 
>>> On 10 Aug 2017, at 07:20, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
>>> Hi there, I don’t mean to be rude or something, nor do I want to hold the 
>>> review process up from succeeding, but where is the branch with the 
>>> implementation? 
>>> 
>>> Quote: 
>>> 
>>> The proposal phase for Swift 4 is now officially over
>>> I hope that the core team does not pick proposals they like, for instance 
>>> their own ones, and just skip the restriction of an implementation. I just 
>>> want to make sure that everyone plays with the same rules, so that it will 
>>> be fair for everyone
>>> 
>> I don’t know what gave you the impression the Core Team would bend the rules 
>> or play favorites. It’s not authored from an Apple engineer and, if you have 
>> a look at the PR for the proposal, there is a link to the implementation: 
>> https://github.com/apple/swift/pull/9619
>>> To strengthen up my criticism, here is a PR of a different proposal which 
>>> didn’t made it into Swift 4 but which was asked for an implementation 
>>> yesterday: 
>>> 
>>> https://github.com/apple/swift-evolution/pull/707
>>> 
>>> Have a nice review ;)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Am 10. August 2017 um 01:15:00, Chris Lattner via swift-evolution 
>>> (swift-evolution@swift.org) schrieb:
>>> 
 And of course, the correct proposal link is:
 https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
 
 
 > On Aug 9, 2017, at 4:10 PM, Chris Lattner  wrote:
 > 
 > I forgot to mention that the implementation of this feature is available 
 > here:
 > https://github.com/apple/swift/pull/9619
 > 
 > -Chris
 > 
 >> On Aug 9, 2017, at 4:08 PM, Chris Lattner  wrote:
 >> 
 >> Hello Swift community,
 >> 
 >> The review of SE-0185 - "Synthesizing Equatable and Hashable 
 >> conformance" begins now and runs through August 15, 2017. The proposal 
 >> is available here:
 >> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.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:
 >> 
 >> 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,
 >> 
 >> Chris Lattner
 >> Review Manager
 >> 
 >> 
 > 
 > ___
 > swift-evolution-announce mailing list
 > swift-evolution-annou...@swift.org
 > https://lists.swift.org/mailman/listinfo/swift-evolution-announce
 
 ___
 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] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Douglas Gregor via swift-evolution]

> On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution 
>  wrote:
> 
> Sorry to revive this, but back on my ABI stability education:

[We’re a bit far afield of the original subject, but okay]

> 
> Swift 5 planning was announced today (woohoo!) with a primary target on ABI 
> stability. Finalising generics seems to be a major part of this, with 
> "conditional conformances", "recursive protocol requirements," and "there are 
> no known other generics enhancements needed for ABI stability" as key points.
> 
> But it seems like there's quite a bit more left in the generics manifesto 
> unimplemented.

Right. We’re not going to get to all of this in a year, or two years, and we 
don’t get to block ABI stability on all of the features therein.

> Perhaps some of what's in there is controversial, but something like 
> generalised existentials afaik *is/was* planned.. can someone explain how GE 
> doesn't affect ABI stability?

It’s an additive feature, so it doesn’t *change* the ABI per se, it extends the 
ABI to describe something it didn’t describe before. Now, there are a few 
places where we could still run into ABI-compatibility issues when adding 
something new:

* Generalized existentials are a new structural type. An old runtime will not 
understand the type metadata for these types, so we have to deal with that in 
some way. Sometimes we can “implement ahead”, providing support for a a feature 
in the runtime that isn’t surfaced in the language itself yet, or we can try to 
build in future-proof mechanisms for adding more types.

* Generalized existentials could change the way the standard library works or 
is implemented. This is mostly opportunity cost: if we don’t have the feature, 
we’ll have some suboptimal-in-retrospect APIs or implementation that’s baked 
into the standard library. For generalized existentials, we’re likely to have 
some suboptimality with struct AnyCollection, either in the implementation (it 
could wrap a “Collection where .Element == Element”) or even in the API itself 
(maybe the struct should go away and it should be a typealias for the 
corresponding generalized existential).


> To my very naive mind it's not that different from some other things said to 
> affect ABI, and to my slightly less naive mind, I believe it was going to 
> enable a protocol oriented approach to KeyPaths in the future, which seems 
> like it would affect ABI of stdlib.

Every ABI is suboptimal. Once you’ve shipped it, there are some hard limits on 
what you can change (because all of the existing binaries need to continue to 
work), but it’s still possible to make improvements. At worst, the improvements 
only be available on some future OS. Sometimes, one can do better by putting 
more work into the implementation to interoperate with other binaries, and 
often language runtime designers leave themselves hooks that allow such 
improvements in the future. We’ll do some of this in the Swift ABI, 
particularly where we expect change. Engineering trade-offs abound, and for 
generics, we feel like we can tackle what’s been proposed already… but not 
more… and that we can live with the limitations posed by that model.

> I'm quite sure I'm missing the core concept at this point, so I'd be content 
> with my examples being ignored and just pointing me towards a 
> general/educational resource on ABI vs. interface thats vaguely compatible 
> with Swift.

The ABI Dashboard (https://swift.org/abi-stability/ 
) and ABI Manifesto 
(https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md 
) 
cover some of this.

- Doug

> 
> Thanks!
> 
> On Tue, Aug 8, 2017 at 6:18 PM, Chris Lattner  > wrote:
> 
> > On Aug 7, 2017, at 11:34 PM, Elviro Rocca  > > wrote:
> >
> > I agree with everything you wrote, in particular I agree with the idea that 
> > it is more important to get the big efforts right, and that they should 
> > take priority. But I would consider a distinction:
> >
> > - big efforts that add huge new features to the language so that things 
> > that were done in userland with libraries can be done natively and 
> > idiomatically (concurrent programming, for example);
> > - more "theoretical" big efforts, that allow one, while building a single 
> > app or a big library, to "express" more things more precisely in the 
> > language, and improvements to the generics and protocols systems fall in 
> > this second realm;
> >
> > The reason why I consider the second kind of feature as more important than 
> > the first (thus, earning higher priority) is that, apart from reducing the 
> > amount of busywork to be done in many cases where the abstraction power is 
> > not good enough, it gives more tools for the 

[swift-evolution] [Core team] Addressing the SE-0110 usability regression in Swift 4

[Douglas Gregor via swift-evolution]

Hello Swift community,

Swift 3’s SE-0110 

 eliminated the equivalence between function types that accept a single type 
and function types that take multiple arguments. However, for various 
implementation reasons 
,
 the implementation of SE-0110 (as well as the elimination of tuple “splat” 
behavior in SE-0029 
)
 was not fully completed.

Swift 4 implemented more of SE-0110, which caused a fairly serious usability 
regression, particularly with closures. Here are a few simple examples 
involving closures that worked in Swift 3 but do not work in Swift 4:

// #1: Works in Swift 3, error in Swift 4
myDictionary.forEach {
  print("\($0) -> \($1)")
}

// #2: Works in Swift 3, error in Swift 4
myDictionary.forEach { key, value in
  print("\(key) -> \(value)")
}

// #3: Works in Swift 3, error in Swift 4
myDictionary.forEach { (key, value) in
  print("\(key) -> \(value)")
}

Similar issues occur with passing multi-argument functions where a tuple 
argument is expected:

// #4: Works in Swift 3, error in Swift 4
_ = zip(array1, array2).map(+)

In all of these cases, it is possible to write a closure that achieves the 
desired effect, but the result is more verbose and less intuitive:

// Works in both Swift 3 and Swift 4
myDictionary.forEach { element in
  let (key, value) = element
  print("\(key) -> \(value)")
}

The Swift core team feels that these usability regressions are unacceptable for 
Swift 4. There are a number of promising solutions that would provide a better 
model for closures and address the usability regression, but fully designing 
and implementing those are out of scope for Swift 4.  Therefore, we will “back 
out” the SE-0110 change regarding function arguments from Swift 4.

Specifically, when passing an argument value of function type (including 
closures) to a parameter of function type, a multi-parameter argument function 
can be passed to a parameter whose function type accepts a single tuple (whose 
tuple elements match the parameter types of the argument function). Practically 
speaking, all of the examples #1-#4 will be accepted in both Swift 3 and Swift 
4.

We will revisit the design in this area post-Swift 4.

- Doug

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

Re: [swift-evolution] The state and the future of function types in Swift 4

[Douglas Gregor via swift-evolution]

> On Jun 14, 2017, at 3:29 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> I do understand that core team is very busy, but I hope they'll find a minute 
> to reply in couple of words to this message. Even "we are still thinking 
> about this" would be great. Of course any other's opinion is also very 
> welcome.

It’s going to take a whole lot more than a minute to reply, but I’ll try!

> 
> I think we all need some clarification about function types in Swift 4, 
> especially in light of recent hot discussion of reverting of SE-0110, which 
> raised a couple of questions that IMO should be answered before Swift 4 is 
> released or is in final stage, and I can't see any clear answer from core 
> team regarding the subject.
> (If I missed something - sorry, please point me)
> 
> The main question I have : Will *type* of function taking a list of arguments 
> be the same as type of function taking one tuple argument?

The intent is “no”. Swift only ever had a poor approximation of this model, and 
has been moving away from it because lots of things we want for function 
parameters—inout parameters, ownership-related calling convention, 
autoclosures, non escaping function parameters, separate argument 
label/parameter names, different argument-label-matching rules, default 
arguments, variadic parameters—don’t really make sense for tuples. You can 
sorta squint at some of those and find a way to make them work generally with 
tuples, but it’s never all going to fit. They’re different notions, and they 
don’t belong together.

> Then, what code can prove/show that these *types* are different and not the 
> same ?

Here’s a simple case based on your example below:

func f(_: Int, _: Int) { } // #1
func f(_: (Int, Int)) { } // #2

f(1, 2)// calls #1
f((1, 2)) // calls #2

Amusingly, this changed behavior from Swift 3.1 to Swift 3.2 (!). Swift 3.1 
would call #1 for both cases! IIRC, earlier versions of Swift would reject the 
overloading of “f” and crash.

There are numerous other ways to show this, but calling an overloaded function 
is an easy one.

> Answers to these question can show what situation we'll have with function 
> types in Swift 4 and for very long period after Swift 4.
> Seems like strange question as we know obvious answer, but as I understand, 
> the answer is not so obvious.
> 
> As I understand, if we'll still have
> 'type(of: funcOfOneTuple) == type(of: funcOfArgList)' == true

The underlying implementation model of the compiler still makes this true, yes.

> (as we have even in current snapshot of Swift 4) - we are going to have 
> broken type system for function types for very long time(when we'll be 
> allowed for source breaking changes after Swift 4?)
> 
> I was told that Swift can have some bugs in this area currently and after 
> Swift 4 release, but don't worry, they'll be just fixed in some point of time 
> after Swift 4.

The Swift compiler *will* have bugs in this area. Yes, they will need to be 
fixed.

> But I insist, we are not talking about _bugs_, but about allowed syntax and 
> code behavior, that can't be 'just' fixed without breaking some sources(and 
> again probably in places where was not expected). Also, it's weird that these 
> long-running "bugs" will still exists in Swift 4(and so, for long period 
> after it) while SE-0066 and SE-0110 was accepted to be implemented in *Swift 
> 3*.

Yes, fixing these bugs can affect source compatibility. Compatibility modes 
(like Swift 3.2 in the Swift 4.0 compiler) and migration tools (as with 3.2 -> 
4.0) make it possible to make improvements over time. Swift 3.2 emulates Swift 
3 quite well, given that the compiler saw some major representational changes 
internally. 

> 
> I'll try to illustrate what I mean and why asking exactly that question.
> 
> Given:
>   func fooParam(_ x: Int, _ y: Int){}
>   func fooTuple(_ x: (Int, Int)) {}
> 
>   func fooEmpty() {}
>   func fooVoid(_: Void) {}
> 
> currently, in Swift 4 snapshot we have this:
> 
> * type(of: fooTuple)  // (Int,Int)->()
> * type(of:fooParam) == type(of:fooTuple)  // true
> * fooParam is ((Int,Int))->() // true
> * fooTuple is (Int,Int)->()   // true
> 
> * let foo : (Int,Int)->() = fooTuple
>  foo(1,2) // fooTuple called with 2 
> arguments
> 
> * let bar : ((Int,Int))->() = fooParam
>  bar((1,2))   // fooParam called with 1 tuple 
> arg
> 
> * type(of: fooEmpty) == type(of: fooVoid) // true
> * fooVoid is ()->()   // true
> * fooEmpty is (_: Void)->()   // true
> 
> * let foo : ()->() = fooVoid
>  foo()// fooVoid called with 
> no () arg
> 
> * let bar : (_: Void)->() = fooEmpty
>  bar(())  // fooEmpty called with () arg 
> 

Re: [swift-evolution] Introduction of OrderedSet

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Jun 13, 2017, at 6:05 AM, Maik Koslowski <maik.koslow...@me.com> wrote:
> 
> It’s definitely more effort needed than i thought at first. I can create an 
> API suggestion, but that will take a while. Since this will happen in Swift 5 
> or later, we will have enough time anyway.

Right. There are staging possibilities here... OrderedSet could exist and even 
be bridgeable with NSOrderedSet, but we wouldn't want to take a source-breaking 
change to affected Objective-C imported APIs until Swift 5 (if at all! It's 
something to discuss). 

> Does it make sense to create a proposal on GitHub or should I wait at least 
> for Swift 5 since this is out of scope for Swift 4?

We are in a bit of a dead zone while we wrap up Swift 4. It's fine to prepare a 
draft proposal for discussion, but we won't merge the proposal into the main 
Swift-evolution repo or run a review until the core team scopes post-Swift 4 
releases. 

  - Doug

> 
> - Maik
> 
>>> Am 12.06.2017 um 18:35 schrieb Douglas Gregor <dgre...@apple.com>:
>>> 
>>> 
>>> On Jun 10, 2017, at 8:42 AM, Tony Parker <anthony.par...@apple.com> wrote:
>>> 
>>> This is still something I want to do, but I suspect it will require some 
>>> coordination work with the NSOrderedSet ref type in Foundation.
>>> 
>>> Also, as Doug says, there is a larger question too of how we make source 
>>> breaking changes like this in Swift 5 (I think we’re probably out of runway 
>>> for Swift 4 at this point).
>> 
>> Definitely too late for Swift 4. 
>> 
>> Whether we should do it in Swift 5 depends on the source-compatibility 
>> story. The Swift 4 compiler has the ability to present imported types to 
>> Swift 3.2 differently from Swift 4, which we used to stage in (e.g.) 
>> subclass existentials and SDK changes. We could conceivably do the same for 
>> NSOrderedSet <-> OrderedSet bridging, suppressing bridging of NSOrderedSet 
>> in imported APIs for Swift <= 4.
>> 
>>> We would want to bridge this in from the SDK, but if it follows the pattern 
>>> of our value types, we need to make API changes from the ref type to make 
>>> it fit in correctly with Swift-only concepts like the Collection protocols.
>> 
>> Sure, we’d need to design it to fit well with the standard library and 
>> provide the APIs people expect from NSOrderedSet.
>> 
>>  - Doug
>> 
>>> - Tony
>>> 
>>>>> On Jun 9, 2017, at 4:28 PM, Douglas Gregor via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> 
>>>>> On Jun 9, 2017, at 10:19 AM, Xiaodi Wu via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> Let me try to redirect this conversation, if I may.
>>>>> 
>>>>> As far as I can tell, SE-0069 states plainly that the plan of record is 
>>>>> to offer a value type called OrderedSet in Foundation, but resources to 
>>>>> design and implement were not then available.
>>>>> 
>>>>> So, little point in having a vote as to whether one is in favor of 
>>>>> OrderedSet or not. In my view, the questions to be answered are:
>>>>> 
>>>>> For the core team–
>>>>> 
>>>>> * Is it still the plan to offer value types postponed from SE-0069 as a 
>>>>> future addition to Foundation?
>>>> 
>>>> *I* think it’s still a good idea, and I suspect that others on the core 
>>>> team will agree.
>>>> 
>>>>> * If so, is that a priority in the Swift 5 timeframe, and how can the 
>>>>> community help to bring about this addition?
>>>> 
>>>> I wouldn’t consider it a “priority”, in the sense that I can’t imagine 
>>>> anything in Swift 5 that would absolutely require us to introduce this 
>>>> functionality in that time frame. It’s a bit of a 
>>>> nice-to-have-at-any-point, noting of course that bridging NSOrderedSet in 
>>>> existing APIs is a nontrivial source-breaking change.
>>>> 
>>>> Having a proposed API and implementation on hand makes it easier to add 
>>>> this functionality, of course.
>>>> 
>>>>> If not, for the whole community–
>>>>> 
>>>>> * Is it wise to implement such a type in the standard library? Should we 
>>>>> simply bring over the native implementation from Swift Package Manager? 
>>>

Re: [swift-evolution] Introduction of OrderedSet

[Douglas Gregor via swift-evolution]

> On Jun 10, 2017, at 8:42 AM, Tony Parker <anthony.par...@apple.com> wrote:
> 
> This is still something I want to do, but I suspect it will require some 
> coordination work with the NSOrderedSet ref type in Foundation.
> 
> Also, as Doug says, there is a larger question too of how we make source 
> breaking changes like this in Swift 5 (I think we’re probably out of runway 
> for Swift 4 at this point).

Definitely too late for Swift 4. 

Whether we should do it in Swift 5 depends on the source-compatibility story. 
The Swift 4 compiler has the ability to present imported types to Swift 3.2 
differently from Swift 4, which we used to stage in (e.g.) subclass 
existentials and SDK changes. We could conceivably do the same for NSOrderedSet 
<-> OrderedSet bridging, suppressing bridging of NSOrderedSet in imported APIs 
for Swift <= 4.

> We would want to bridge this in from the SDK, but if it follows the pattern 
> of our value types, we need to make API changes from the ref type to make it 
> fit in correctly with Swift-only concepts like the Collection protocols.

Sure, we’d need to design it to fit well with the standard library and provide 
the APIs people expect from NSOrderedSet.

- Doug

> - Tony
> 
>> On Jun 9, 2017, at 4:28 PM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
>>> On Jun 9, 2017, at 10:19 AM, Xiaodi Wu via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Let me try to redirect this conversation, if I may.
>>> 
>>> As far as I can tell, SE-0069 states plainly that the plan of record is to 
>>> offer a value type called OrderedSet in Foundation, but resources to design 
>>> and implement were not then available.
>>> 
>>> So, little point in having a vote as to whether one is in favor of 
>>> OrderedSet or not. In my view, the questions to be answered are:
>>> 
>>> For the core team–
>>> 
>>> * Is it still the plan to offer value types postponed from SE-0069 as a 
>>> future addition to Foundation?
>> 
>> *I* think it’s still a good idea, and I suspect that others on the core team 
>> will agree.
>> 
>>> * If so, is that a priority in the Swift 5 timeframe, and how can the 
>>> community help to bring about this addition?
>> 
>> I wouldn’t consider it a “priority”, in the sense that I can’t imagine 
>> anything in Swift 5 that would absolutely require us to introduce this 
>> functionality in that time frame. It’s a bit of a nice-to-have-at-any-point, 
>> noting of course that bridging NSOrderedSet in existing APIs is a nontrivial 
>> source-breaking change.
>> 
>> Having a proposed API and implementation on hand makes it easier to add this 
>> functionality, of course.
>> 
>>> If not, for the whole community–
>>> 
>>> * Is it wise to implement such a type in the standard library? Should we 
>>> simply bring over the native implementation from Swift Package Manager? 
>>> What are the implications for bridging?
>> 
>> Obviously, we’d want an efficient copy-on-write, native implementation; the 
>> Swift Package Manager implementation is a bit more bare-bones than we’d 
>> want: absolute performance matters, so having a separate Set + Array in the 
>> struct probably isn’t good enough. Bridging performance matters, so we’d 
>> probably want the one-pointer representation like array uses where the 
>> pointer can be vended directly to Objective-C.
>> 
>>  - Doug
>> 
>>> On Fri, Jun 9, 2017 at 11:38 Remy Demarest via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> +1 for ordered set and dictionary, and please add ordered dictionary in 
>>> ObjC as well.
>>> 
>>> Envoyé de mon iPhone
>>> 
>>> Le 9 juin 2017 à 03:11, Robert Bennett via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>> 
>>>> +1, and would also like to see OrderedDictionary as well.
>>>> 
>>>> On Jun 9, 2017, at 12:50 AM, Jeff Kelley via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>>> I would be in favor of it; there have been a few times (including Core 
>>>>> Data, as you mentioned) where I would have used it had it been available.
>>>>> 
>>>>

Re: [swift-evolution] Introduction of OrderedSet

[Douglas Gregor via swift-evolution]

> On Jun 9, 2017, at 10:19 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Let me try to redirect this conversation, if I may.
> 
> As far as I can tell, SE-0069 states plainly that the plan of record is to 
> offer a value type called OrderedSet in Foundation, but resources to design 
> and implement were not then available.
> 
> So, little point in having a vote as to whether one is in favor of OrderedSet 
> or not. In my view, the questions to be answered are:
> 
> For the core team–
> 
> * Is it still the plan to offer value types postponed from SE-0069 as a 
> future addition to Foundation?

*I* think it’s still a good idea, and I suspect that others on the core team 
will agree.

> * If so, is that a priority in the Swift 5 timeframe, and how can the 
> community help to bring about this addition?

I wouldn’t consider it a “priority”, in the sense that I can’t imagine anything 
in Swift 5 that would absolutely require us to introduce this functionality in 
that time frame. It’s a bit of a nice-to-have-at-any-point, noting of course 
that bridging NSOrderedSet in existing APIs is a nontrivial source-breaking 
change.

Having a proposed API and implementation on hand makes it easier to add this 
functionality, of course.

> If not, for the whole community–
> 
> * Is it wise to implement such a type in the standard library? Should we 
> simply bring over the native implementation from Swift Package Manager? What 
> are the implications for bridging?

Obviously, we’d want an efficient copy-on-write, native implementation; the 
Swift Package Manager implementation is a bit more bare-bones than we’d want: 
absolute performance matters, so having a separate Set + Array in the struct 
probably isn’t good enough. Bridging performance matters, so we’d probably want 
the one-pointer representation like array uses where the pointer can be vended 
directly to Objective-C.

- Doug

> On Fri, Jun 9, 2017 at 11:38 Remy Demarest via swift-evolution 
> > wrote:
> +1 for ordered set and dictionary, and please add ordered dictionary in ObjC 
> as well.
> 
> Envoyé de mon iPhone
> 
> Le 9 juin 2017 à 03:11, Robert Bennett via swift-evolution 
> > a écrit :
> 
>> +1, and would also like to see OrderedDictionary as well.
>> 
>> On Jun 9, 2017, at 12:50 AM, Jeff Kelley via swift-evolution 
>> > wrote:
>> 
>>> I would be in favor of it; there have been a few times (including Core 
>>> Data, as you mentioned) where I would have used it had it been available.
>>> 
>>> 
>>> Jeff Kelley
>>> 
>>> slauncha...@gmail.com  | @SlaunchaMan 
>>>  | jeffkelley.org 
 On Jun 7, 2017, at 2:10 PM, Maik Koslowski via swift-evolution 
 > wrote:
 
 Hello,
 
 in the past there have been a few requests for an OrderedSet 
 implementation in Swift. In the proposal 
 https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
  
 
  was mentioned that the OrderedSet will be considered for the feature.
 
 However, since then there were a few discussions on OrderedSet but it 
 doesn’t get much attention and there wasn’t any comment about it from the 
 swift team.
 
 I want to bring up some points, why an OrderedSet is needed in the base 
 library.
 
 1. CoreData is probably the most obvious place where people would use an 
 ordered set. Especially when working with large amounts of data, 
 presorting can save a lot of time and battery life. If a bridgeable 
 ordered set was part of the standard library we could use a ordered set in 
 swift without having to use the NSOrderedSet from objective c. Which would 
 be pretty nice in my opinion. Even when using a NSOrderedSet we couldn’t 
 have a generic version of it.
 
 2. A shared datamodel between App and Server. One main advantage of having 
 web servers written in Swift is that we can share code between the server 
 and the app. For servers performance does matter a lot, since they are 
 usually working with much more data than apps. Databases are represented 
 as sets and fetching sorted data from the database can be represented as 
 an ordered set. However, since we don’t have ordered sets we have to 
 choose either a normal set or an array. Sets don’t have an order and 
 arrays can contain the same object multiple times, which makes them both a 
 less suitable choice.
 
 3. Swift has the potential to be used for education. There is a lot of 

[swift-evolution] [Accepted] SE-0174: Change filter to return an associated type

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md

Hello Swift Community,

The review of SE-0174 "Change filter to return an associated type” ran from 
April 28...May 3, 2017. The proposal is accepted. Thank you to everyone who 
participated in the review!

- Doug
Review Manager


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

Re: [swift-evolution] Replace throws with Result

[Douglas Gregor via swift-evolution]

> On May 3, 2017, at 3:31 AM, Jaden Geller via swift-evolution 
>  wrote:
> 
> To be frank, there’s no way this is happening. The rationale for Swift’s 
> error handling is documented 
> , and this 
> system was designed and implemented *after* optionals already existed in the 
> language. I don’t think there’s any evidence that this was a horrible 
> decision, especially one that requires a *majorly* source-breaking change to 
> remove.

As a core team member, let me amplify this response a bit: the current 
error-handling system will not be going away, for the reasons Jaden has stated 
above.

Maybe we will grow typed throws at some point; maybe Result will get added to 
the standard library with some nice affordances to map between throwing and 
Result-producing types; but we’re well beyond the point where we can rip out 
major features that have been generally well-received.

- Doug

> – Jaden
> 
>> On May 3, 2017, at 3:06 AM, Jose Manuel Sánchez Peñarroja via 
>> swift-evolution > > wrote:
>> 
>> There is currently a discussion open about throws, but it seems that the 
>> idea would be to add optionals to throws. In my opinion it would be much 
>> better to just get rid of all the throw error system.
>> 
>> I think an *Result* type would provide much better error handling 
>> than the current solution:
>> 
>> - It would work just like Optional. We could use ?, ??, map, all those 
>> concepts that are already in use. A Result would basically be like a missing 
>> value with an error attached. *mapError* could also be added to transform 
>> error types to the appropriate value. 
>> 
>> - We would have a specific error type. Right now throws just returns an 
>> *Error*, which is basically a glorified *Any*. Anything can go in there, and 
>> it's really hard (or impossible) to know if we are dealing with all the 
>> possible options. a Result type would enforce a specific error, so we would 
>> gain type safety and we could be sure we are dealing with all the cases.
>> 
>> - It would simplify everything. We could get rid of *try*, *try?*, *throws*, 
>> *rethrows*, *do … catch*.
>> 
>> - It could be used asynchronously by just passing the *Result* value. Right 
>> now there is a different mechanism for handling async and sync calls. The 
>> sync calls have all the *throws*, *rethrows*, must be taken care with *try* 
>> and *do … catch*, while in a callback you just send the error.
>> 
>> ___
>> 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-0174: Change `filter` to return an associated type

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0174 "Change `filter` to return an associated type" begins now 
and runs through May 3, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.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/0174-filter-range-replaceable.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-0167: Swift Encoders

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
 


The review of SE-0167 "SE-0167: Swift Encoders” ran from April 6...12, 2017. 
The proposal is accepted. Thanks to everyone who participated in the review!

- Doug
Review Manager


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

[swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
 


Hello Swift Community,

The review of SE-0166 “Swift Archival & Serialization” ran from April 6...12, 
2017. The proposal is accepted with some minor modifications. Specifically, the 
core protocols and types will be sunk down into the Swift standard library for 
more tight integration with the Swift language and compiler, and the operations 
specifically involving Foundation’s “Data” type will be removed. The proposal 
document has been updated with more detail. Thank you everyone for 
participating in this review!

- Doug
Review Manager

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

Re: [swift-evolution] [Pitch] Enum with generic cases

[Douglas Gregor via swift-evolution]

> On Apr 24, 2017, at 12:57 PM, Joshua Alvarado  
> wrote:
> 
> When would be a good time to resubmit this proposal for discussion?

Sometime in the summer we’re going to start talking about the scope of Swift 
post-4.0.

> Or can I still proceed with the review and it possibly gets deferred but at 
> least be put in the pipeline (if deferred)?

We try not to let the review process get *too* far ahead of the actual 
implementation, because detailed design review for acceptance is itself a 
time-consuming process. 

- Doug

> 
> On Mon, Apr 24, 2017 at 9:07 AM, Douglas Gregor  > wrote:
> 
>> On Apr 24, 2017, at 7:23 AM, T.J. Usiyan via swift-evolution 
>> > wrote:
>> 
>> /me Pushes implementation detail related concerns out of head
>> 
>> +1
>> 
>> 
>> I want this feature but I seriously doubt that it is feasible at the moment. 
>> There are so many 'more pressing' features that, even if this were accepted 
>> now, it wouldn't be implemented it in time for Swift 4.
> 
> Out of scope for Swift 4, certainly. It may not look like it, but this is a 
> fairly large feature. I suggest reading up on generalized algebraic data 
> types  
> (GADTs), which is the more programming-language-theoretical name for what 
> you’re describing here.
> 
>   - Doug
> 
>> 
>> That said, I would love to be incorrect. 
>> 
>> On Mon, Apr 24, 2017 at 9:57 AM, Joshua Alvarado via swift-evolution 
>> > wrote:
>> Here is my pitch on adding generics to enum cases and not to the enum type 
>> itself. Let me know if you have an improvements or modifications lets open 
>> it to discussion thank you swiftys! :)
>> 
>> Enum with generic cases
>> 
>> Proposal: SE- 
>> 
>> Authors: Joshua Alvarado 
>> Review Manager: TBD
>> Status: PITCH
>> During the review process, add the following fields as needed:
>> 
>> Decision Notes: Rationale 
>> , Additional Commentary 
>> 
>> Bugs: SR- , SR- 
>> 
>> Previous Revision: 1 
>> 
>> Previous Proposal: SE- 
>> 
>>  
>> Introduction
>> 
>> This proposal adds a change to the enumeration type that allows an enum case 
>> to cast a generic on its associated value.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal 
>> 
>>  
>> Motivation
>> 
>> Enums currently support generics, but they are added onto the type itself. 
>> This can cause adverse syntax when implementing generics for associated 
>> values to be stored along each case. The enum case holds the associated 
>> value (not the enum type itself) so should create its own value constraints.
>> 
>>  
>> Proposed
>>  solution
>> 
>> The generic is to be casted on the case of the enum and not on the enum 
>> itself.
>> 
>>  
>> Detailed
>>  design
>> 
>> Current implementation:
>> 
>> // enum with two generic types
>> enum Foo {
>> case bar(obj: T)
>> case baz(obj: U)
>> }
>> 
>> // U is to be casted but it is not even used
>> let foo: Foo = .bar(obj: "hash")
>> 
>> // Creating an optional enum, the generics have to be casted without a value 
>> set
>> // The casting is really not needed as the values should be casted not the 
>> enum
>> var foo1: Foo?
>> 
>> // Collections don’t look great either
>> var foos = [Foo]()
>> foos.append(.bar(obj:"hash"))
>> Proposed solution
>> 
>> enum Foo {
>> case bar(obj: T)
>> case baz(obj: U)
>> }
>> 
>> // generic type inferred on T
>> var foo: Foo = .bar(obj: "hash") 
>> 
>> // doesn’t need to cast the generic on the optional enum
>> // the associated value will hold the cast
>> var foo1: Foo? 
>> 
>> // This also gives better syntax with collections of enums with associated 
>> types
>> var foos = [Foo]()
>> foos.append(.bar(obj: "hey")
>>  
>> Source
>>  compatibility
>> 
>> This may cause subtle breaking changes for areas in 

Re: [swift-evolution] [Accepted] SE-0172: One-sided Ranges

[Douglas Gregor via swift-evolution]

> On Apr 25, 2017, at 9:20 AM, Tony Allevato  wrote:
> 
> 
> On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution 
> > wrote:
> While it's good that this was accepted I still feel there could be some more 
> discussion about whether the operators should be prefix/postfix or instead 
> involve a more explicit declaration of one-sidedness.
> 
> I still would very much prefer that the operator declarations were binary and 
> take Void as a second argument, this way there is very explicit indication 
> that one-sidedness was requested, rather than potentially accidental; 
> assuming many subscripts and methods that take currently closed ranges will 
> be updated to also take one-sided ranges, the distinction is very important 
> as a omitting one of the values could represent a mistake, and result in 
> one-sided behaviour with unintended consequences.
> 
> With a Void "open" argument this would look like:
> 
> func ... (lhs:T, rhs:Void) -> RangeFrom { ... }
> func ... (lhs:Void, rhs:T) -> RangeTo { ... }
> 
> let rangeFrom = 5 ... ()
> let rangeTo = () ... 5
> 
> Not the prettiest with the Void brackets, however, if we could in future get 
> underscore as another alias for Void we could refine this into:
> 
> Why would it make sense to have `_` as an alias for Void?
>  
> 
> let rangeFrom = 5 ... _
> let rangeTo = _ ... 5
> 
> This would have consistency with other uses of underscore that are used to 
> indicate that something is being ignored on purpose, which I think fits this 
> proposal very well. It would also leave the prefix/postfix ellipsis operator 
> free for use on something else with less chance of creating ambiguity.
> 
> I disagree that this proposed use of the underscore is consistent with other 
> uses.
> 
> The underscore is used as a pattern matching construct that means "I don't 
> care what actual value goes here; match and allow anything and throw it 
> away." But in the range case, not only is this not a pattern, but you also 
> *do* care very much what value is used there—not any arbitrary value is 
> acceptable. The value you want is the least or greatest possible value for 
> that range.

Right; “_” is a placeholder for “don’t care”; it shouldn’t have different 
semantic meanings in different contexts.

> Regardless, these ideas were brought up during the proposal's discussion and 
> it's probably safe to assume that the core team considered them but felt they 
> weren't a good solution.

Yes, the core team did consider the ideas around using the binary operators 
rather than introducing the new prefix/postfix operators, and felt that the 
proposal provided the clearest Swift code.

- Doug


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

[swift-evolution] [Accepted] SE-0172: One-sided Ranges

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md

Hello Swift Community,

The review of SE-0172 “One-sided Ranges” ran from April 17...23, 2017. The 
proposal is accepted for Swift 4. Thanks to everyone who participated in the 
discussion!

- Doug
Review Manager

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

Re: [swift-evolution] [Pitch] Enum with generic cases

[Douglas Gregor via swift-evolution]

> On Apr 24, 2017, at 7:23 AM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> /me Pushes implementation detail related concerns out of head
> 
> +1
> 
> 
> I want this feature but I seriously doubt that it is feasible at the moment. 
> There are so many 'more pressing' features that, even if this were accepted 
> now, it wouldn't be implemented it in time for Swift 4.

Out of scope for Swift 4, certainly. It may not look like it, but this is a 
fairly large feature. I suggest reading up on generalized algebraic data types 
 (GADTs), which 
is the more programming-language-theoretical name for what you’re describing 
here.

- Doug

> 
> That said, I would love to be incorrect. 
> 
> On Mon, Apr 24, 2017 at 9:57 AM, Joshua Alvarado via swift-evolution 
> > wrote:
> Here is my pitch on adding generics to enum cases and not to the enum type 
> itself. Let me know if you have an improvements or modifications lets open it 
> to discussion thank you swiftys! :)
> 
> Enum with generic cases
> 
> Proposal: SE- 
> 
> Authors: Joshua Alvarado 
> Review Manager: TBD
> Status: PITCH
> During the review process, add the following fields as needed:
> 
> Decision Notes: Rationale 
> , Additional Commentary 
> 
> Bugs: SR- , SR- 
> 
> Previous Revision: 1 
> 
> Previous Proposal: SE- 
> 
>  
> Introduction
> 
> This proposal adds a change to the enumeration type that allows an enum case 
> to cast a generic on its associated value.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> Enums currently support generics, but they are added onto the type itself. 
> This can cause adverse syntax when implementing generics for associated 
> values to be stored along each case. The enum case holds the associated value 
> (not the enum type itself) so should create its own value constraints.
> 
>  
> Proposed
>  solution
> 
> The generic is to be casted on the case of the enum and not on the enum 
> itself.
> 
>  
> Detailed
>  design
> 
> Current implementation:
> 
> // enum with two generic types
> enum Foo {
> case bar(obj: T)
> case baz(obj: U)
> }
> 
> // U is to be casted but it is not even used
> let foo: Foo = .bar(obj: "hash")
> 
> // Creating an optional enum, the generics have to be casted without a value 
> set
> // The casting is really not needed as the values should be casted not the 
> enum
> var foo1: Foo?
> 
> // Collections don’t look great either
> var foos = [Foo]()
> foos.append(.bar(obj:"hash"))
> Proposed solution
> 
> enum Foo {
> case bar(obj: T)
> case baz(obj: U)
> }
> 
> // generic type inferred on T
> var foo: Foo = .bar(obj: "hash") 
> 
> // doesn’t need to cast the generic on the optional enum
> // the associated value will hold the cast
> var foo1: Foo? 
> 
> // This also gives better syntax with collections of enums with associated 
> types
> var foos = [Foo]()
> foos.append(.bar(obj: "hey")
>  
> Source
>  compatibility
> 
> This may cause subtle breaking changes for areas in code with generic enum 
> cases. The compiler could help with the change by finding the associated 
> generic and updating the case with the new syntax.
> 
>  
> Alternatives
>  considered
> 
> An alternative would be to extend the associatedtype keyword to the enum type.
> 
> enum Foo {
> associatedtype T = Hashable
> case bar(obj: T)
> }
> 
> Copy of proposal can be found here Swift proposal on github 
> 
> 
> -- 
> Joshua Alvarado
> alvaradojosh...@gmail.com 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> 

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Douglas Gregor via swift-evolution]

> On Apr 20, 2017, at 7:53 PM, John McCall <rjmcc...@apple.com> wrote:
> 
>> On Apr 20, 2017, at 7:31 PM, Douglas Gregor <dgre...@apple.com 
>> <mailto:dgre...@apple.com>> wrote:
>>> On Apr 20, 2017, at 3:39 PM, John McCall <rjmcc...@apple.com 
>>> <mailto:rjmcc...@apple.com>> wrote:
>>> 
>>>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor <dgre...@apple.com 
>>>> <mailto:dgre...@apple.com>> wrote:
>>>> 
>>>> 
>>>>> On Apr 20, 2017, at 11:33 AM, Jordan Rose <jordan_r...@apple.com 
>>>>> <mailto:jordan_r...@apple.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution 
>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>> 
>>>>>> This makes the private/fileprivate distinction meaningful for 
>>>>>> extensions. I think also bans the use of "private" at global scope for 
>>>>>> non-nominal types or extensions thereof.  A clarifying update to the 
>>>>>> proposal is in order, so developers can better understand the semantics. 
>>>>> 
>>>>> Wait, hang on, then people have to write 'fileprivate' instead of 
>>>>> 'private' for top-level typealiases (and functions?). 
>>>> 
>>>> That seems like the correct behavior; private is about members with 
>>>> SE-0169. What do you think?
>>>> 
>>>> ...that seems suboptimal, given that the goal has been to make it possible 
>>>> for people to use `private` more and not less frequently. IMO, there's no 
>>>> need for `private typealias` at the global level to be prohibited.
>>> 
>>> Yeah, I see no reason for this to change the behavior of private extensions 
>>> to be more restrictive than before.
>> 
>> So you’re okay with:
>> 
>>  private extension X {
>>func foo() { }
>>  }
>> 
>> being equivalent to
>> 
>>  extension X {
>>fileprivate func foo() { }
>>  }
>> 
>> rather than
>> 
>>  extension X {
>>private func foo() { }
>>  }
>> 
>> ?
>> 
>> That seems unintuitive at best.
> 
> Perhaps, but it's existing unintuitive behavior.  Are you suggesting that 
> SE-0169 rationalizes changing it because (1) it's likely that a private 
> extension is just meant for the use of other extensions of that type in the 
> current file and (2) SE-0169 already allows such uses and so justifies the 
> stricter rule?  That is an interesting theory, but I'm not sure I believe 
> (1).  

I’m saying (2), and I suspect (1) is most often the case… but I agree that 
we’re likely to end up breaking code here.

> More importantly, though, SE-0169 didn't actually propose changing this 
> behavior, and it's a very substantial shift in behavior, and we haven't 
> actually discussed or gathered any community feedback about it, so I'm really 
> struggling to see why it wouldn't need to be a separate evolution proposal.  

I was interpreting SE-0169 to mean this, but you are correct: SE-0169 doesn’t 
spell out a change here.

> And that would be difficult because, as a wise man once said to me, the core 
> team considers the access-control matter closed for Swift 4 and will not be 
> reviewing any further proposals in this area. :)

Never put stock in charlatans or compiler writers.

- Doug


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

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

[Douglas Gregor via swift-evolution]

> On Apr 20, 2017, at 6:36 AM, Matt Whiteside <mwhiteside@gmail.com> wrote:
> 
> I do like this proposed one-sided range syntax, but a while back it was 
> pointed out that it might conflict with a candidate syntax for variadic 
> generics.  Has anything changed there?

It does conflict with the straw man syntax described in the generics manifesto:


https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics
 
<https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics>

but variadic generics are a long way off and the syntax is totally up in the 
air.

- Doug

> -Matt
> 
>> On Apr 17, 2017, at 21:40, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0172 "One-sided Ranges" begins now and runs through April 
>> 23, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md
>>  
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.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. 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/0172-one-sided-ranges.md
>>  
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md>
>> Reply text
>> Other replies
>>  
>> <https://github.com/apple/swift-evolution/pulls#what-goes-into-a-review-1>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 
>> <https://github.com/apple/swift-evolution/blob/master/process.md>
>> Thank you,
>> 
>> -Doug
>> 
>> 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

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Douglas Gregor via swift-evolution]

> On Apr 20, 2017, at 3:39 PM, John McCall <rjmcc...@apple.com> wrote:
> 
>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> On Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor <dgre...@apple.com 
>> <mailto:dgre...@apple.com>> wrote:
>> 
>> 
>>> On Apr 20, 2017, at 11:33 AM, Jordan Rose <jordan_r...@apple.com 
>>> <mailto:jordan_r...@apple.com>> wrote:
>>> 
>>> 
>>>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> This makes the private/fileprivate distinction meaningful for extensions. 
>>>> I think also bans the use of "private" at global scope for non-nominal 
>>>> types or extensions thereof.  A clarifying update to the proposal is in 
>>>> order, so developers can better understand the semantics. 
>>> 
>>> Wait, hang on, then people have to write 'fileprivate' instead of 'private' 
>>> for top-level typealiases (and functions?). 
>> 
>> That seems like the correct behavior; private is about members with SE-0169. 
>> What do you think?
>> 
>> ...that seems suboptimal, given that the goal has been to make it possible 
>> for people to use `private` more and not less frequently. IMO, there's no 
>> need for `private typealias` at the global level to be prohibited.
> 
> Yeah, I see no reason for this to change the behavior of private extensions 
> to be more restrictive than before.

So you’re okay with:

private extension X {
  func foo() { }
}

being equivalent to

extension X {
  fileprivate func foo() { }
}

rather than

extension X {
  private func foo() { }
}

?

That seems unintuitive at best.

- Doug


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

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Douglas Gregor via swift-evolution]

> On Apr 20, 2017, at 11:33 AM, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> 
>> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> This makes the private/fileprivate distinction meaningful for extensions. I 
>> think also bans the use of "private" at global scope for non-nominal types 
>> or extensions thereof.  A clarifying update to the proposal is in order, so 
>> developers can better understand the semantics. 
> 
> Wait, hang on, then people have to write 'fileprivate' instead of 'private' 
> for top-level typealiases (and functions?).

That seems like the correct behavior; private is about members with SE-0169. 
What do you think?

> Apart from whether or not that's desirable, it's not backwards-compatible.

Very true! It’s an easy thing to migrate, but it’s a source break nonetheless. 
Let’s decide if it’s desirable and bring it up with the core team.

- Doug


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

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Douglas Gregor via swift-evolution]

Sent from my iPhone
> On Apr 18, 2017, at 6:58 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> Does the acceptance of SE-0169 imply any change to rules for `private 
> extension` members, or does the core team intend such members to continue 
> defaulting to fileprivate visibility?

It does imply a change to "private extension" semantics: the members of such an 
extension would be "private", so they'd be visible to other extensions (and 
possibly the definition of) the extended type that occur in the same file. 

This makes the private/fileprivate distinction meaningful for extensions. I 
think also bans the use of "private" at global scope for non-nominal types or 
extensions thereof.  A clarifying update to the proposal is in order, so 
developers can better understand the semantics. 

Hey, and this gives me another reason why

  extension P where Self : Q { }

Might be a better spelling than

  extension P & Q { }

Despite the latter being more obvious :)

  - Doug


> 
> 
>> On Mon, Apr 17, 2017 at 19:25 Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> Proposal Link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>> 
>> Hello Swift Community,
>> 
>> The review of SE-0169 "Improve Interaction Between `private` Declarations 
>> and Extensions” ran from April 6...11, 2017. The proposal is accepted.
>> 
>> This topic has been highly controversial for a long time, both during Swift 
>> 3’s development (when SE-0025 was introduced) and during Swift 4 (including 
>> SE-0159 and other proposals). There is no solution that will make everyone 
>> happy: maintaining the status quo makes “fileprivate” too common and 
>> therefore not meaningful when it occurs in source; removing or diluting 
>> scope-level access control (as in SE-0159 and this proposal) takes away a 
>> tool that is in use by Swift developers; and adding more levels of access 
>> control complicates the language.
>> 
>> The core team feels that this proposal makes private access align more 
>> closely with the goals of the language:
>> 
>> It supports the notion that extensions are a code-organization tool: one 
>> should be able to break up a type’s definition into several extensions to 
>> improve the clarity of that code, without having to open up access or 
>> otherwise view the members in different extensions as completely-distinct 
>> entities. The core team expects future language evolution to reinforce the 
>> notion that extensions are more of a code organization tool than distinct 
>> entities, e.g., allowing stored properties to be introduced in an extension.
>> It makes private more usable as the default sub-internal access level, which 
>> supports progressive disclosure of the access control system and better 
>> matches with programmer’s expectations about what private access means.
>> It makes fileprivate more meaningful, because it is only needed for those 
>> cases where one is reaching across types (or among types and globals) within 
>> a file. It will also become more rare, which matches well with its longer, 
>> descriptive name.
>> 
>> The proposal’s acceptance includes one modification: extensions of a given 
>> type that reside in a single file that is different from the file that 
>> defines the type itself will have access to the private members of all other 
>> extensions in that file. For example:
>> 
>> // FileA.swift
>> struct A {
>>   private var aMember : Int 
>> }
>> 
>> // FileB.swift
>> extension A {
>> private func foo() {
>> bar()// ok, foo() does have access to bar()
>> }
>> }
>> 
>> extension A {
>> private func bar() {
>> aMember = 42  // not ok, private members may not be accessed outside 
>> their file.
>> }
>> }
>> 
>> The proposal has already been updated to reflect this change, which better 
>> reflects the notion that extensions are a code-organization tool.
>> 
>> The core team considers the access-control matter closed for Swift 4 and 
>> will not be reviewing any further proposals in this area.
>> 
>>  - Doug
>>  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] [Review] SE-0172: One-sided Ranges

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0172 "One-sided Ranges" begins now and runs through April 23, 
2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.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/0172-one-sided-ranges.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

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

[swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
 


Hello Swift Community,

The review of SE-0169 "Improve Interaction Between `private` Declarations and 
Extensions” ran from April 6...11, 2017. The proposal is accepted.

This topic has been highly controversial for a long time, both during Swift 3’s 
development (when SE-0025 

 was introduced) and during Swift 4 (including SE-0159 

 and other  proposals 
). There is no solution that 
will make everyone happy: maintaining the status quo makes “fileprivate” too 
common and therefore not meaningful when it occurs in source; removing or 
diluting scope-level access control (as in SE-0159 

 and this proposal) takes away a tool that is in use by Swift developers; and 
adding more levels of access control complicates the language.

The core team feels that this proposal makes private access align more closely 
with the goals of the language:

It supports the notion that extensions are a code-organization tool: one should 
be able to break up a type’s definition into several extensions to improve the 
clarity of that code, without having to open up access or otherwise view the 
members in different extensions as completely-distinct entities. The core team 
expects future language evolution to reinforce the notion that extensions are 
more of a code organization tool than distinct entities, e.g., allowing stored 
properties to be introduced in an extension.
It makes private more usable as the default sub-internal access level, which 
supports progressive disclosure of the access control system and better matches 
with programmer’s expectations about what private access means.
It makes fileprivate more meaningful, because it is only needed for those cases 
where one is reaching across types (or among types and globals) within a file. 
It will also become more rare, which matches well with its longer, descriptive 
name.

The proposal’s acceptance includes one modification: extensions of a given type 
that reside in a single file that is different from the file that defines the 
type itself will have access to the private members of all other extensions in 
that file. For example:

// FileA.swift
struct A {
  private var aMember : Int 
}

// FileB.swift
extension A {
private func foo() {
bar()// ok, foo() does have access to bar()
}
}

extension A {
private func bar() {
aMember = 42  // not ok, private members may not be accessed outside 
their file.
}
}

The proposal has already been updated to reflect this change, which better 
reflects the notion that extensions are a code-organization tool.

The core team considers the access-control matter closed for Swift 4 and will 
not be reviewing any further proposals in this area.

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

[swift-evolution] [Accepted] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
 


The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
Swift” ran April 5...9, 2017. The first review 

 established the main substance of the proposal, while the second review 
focused mostly on the more lightweight “\” syntax. The proposal is accepted 
with one clarification regarding the intersection between contextual keypaths 
(where the base type is left unspecified) and array types.

The core team felt that the leading “\” is our best option for introducing 
keypaths. It is lightweight, yet provides a visual “escape” to indicate that 
the evaluation of the entities being referenced is being delayed. As noted in 
the result of the first review 
,
 this is part of a longer-term plan to use the “\” for unapplied method 
references, bringing the two closely-related features into syntactic alignment 
over time and providing an opportunity to stage in the important but 
currently-source-breaking changes accepted in SE-0042 
.

Much discussion centered around potential ambiguities. Accessing a property of 
a key path, e.g., \Person.friends[0].firstName.someKeyPathProperty, requires 
one to parenthesize the key path as 
(\Person.friends[0].firstName).someKeyPathProperty,  which is a common way to 
disambiguate expressions in Swift (and most other programming languages) 
already. More concerning to the core team was the ambiguity between contextual 
keypaths starting with a subscript and keypaths rooted on an array type, e.g.,

\[a]?.foo // is [a]? a type rooting a keypath “.foo”
  // or is it a contextual keypath starting with a 
subscript [a]?

To resolve this ambiguity, *all* contextual keypaths will start with “\.”. The 
expression above will use the first interpretation (a type [a]? rooting a key 
path “.foo”), while the second interpretation would be written as:

\.[a]?.foo// a contextual key path starting with the subscript [a]

The core team felt that the result is more consistent: “\.” indicates a 
contextual keypath, while “\” without the “.” indicates a keypath with a 
specified root.

The authors will revise the proposal according. Thank you to everyone who 
participated in the reviews of this much-anticipated feature!

- Doug
Review Manager

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

[swift-evolution] [Accepted] SE-0164: Remove final support in protocol extensions

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md

The review of SE-0164 "Remove final support in protocol extensions” ran from 
April 5...8, 2017. Feedback was light but positive, and the proposal is 
accepted.

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

Re: [swift-evolution] [Pitch] Adding safety to arrays

[Douglas Gregor via swift-evolution]

> On Apr 13, 2017, at 5:19 AM, David Sweeris via swift-evolution 
>  wrote:
> 
>> 
>> On Apr 13, 2017, at 3:56 AM, Andrew Hart via swift-evolution 
>> > wrote:
>> 
>> Recently I’ve been considering the lack of safety around array indexes. 
>> Swift is designed with safety in mind, so this example would not compile:
>> 
>> var myString: String? = “hello”
>> myString.append(“ world!”)
>> 
>> The string is optional, not guaranteed to exist, so the last line requires a 
>> “!” to force-unwrap it.
>> 
>> 
>> 
>> public func tableView(_ tableView: UITableView, numberOfRowsInSection 
>> section: Int) -> Int {
>> let section = self.sections[section]
>> 
>> return section.items.count
>> }
>> 
>> In this example, we could provide a section number that goes beyond the 
>> bounds of the self.sections array, without any warning.
>> 
>> My suggestion is perhaps arrays should by default return an optional when 
>> given an index, and of course they’d support forced-unwrapping too. So you 
>> could then do this:
>> 
>> let section = self.sections[section]
>> if section == nil {
>> return 0
>> } else {
>> return section!.items.count
>> }
>> 
>> Or you could do this:
>> 
>> let section = self.sections[section]!
>> 
>> return section.items.count
>> 
>> Of course this would be less convenient in a lot of cases, but this is the 1 
>> place where apps seem to encounter a crash, crashing for the same reason 
>> that’s especially avoided across most of the rest of Swift.
> 
> My understanding is that we need the current behavior to meet performance 
> goals. We’ve discussed adding a “safe” subscript before, but the discussion 
> usually fizzles out when no clear winner for the argument label emerges.

Also, this discussion is common enough that it’s on the “commonly rejected” 
list:


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


- Doug


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

Re: [swift-evolution] [pitch] Comparison Reform

[Douglas Gregor via swift-evolution]

> On Apr 13, 2017, at 2:42 PM, David Hart via swift-evolution 
>  wrote:
> 
> Looking good. A few comments inline:
> 
>> On 13 Apr 2017, at 22:17, Ben Cohen via swift-evolution 
>> > wrote:
>> Comparable
>> 
>> Comparable will be changed to have a new ternary comparison method: 
>> compare(_ other: Self) -> ComparisonResult. x.compare(y) specifies where to 
>> place x relative to y. So if it yields .orderedAscending, then x comes 
>> before y. This will be considered the new “main” dispatch point of 
>> Comparable that implementors should provide.
>> 
>> Most code will continue to use < or ==, as it will be optimal for their 
>> purposes. However code that needs to make a three-way branch on comparison 
>> can use the potentially more efficient compare. Note that compare is only 
>> expected to be more efficient in this specific case. If a two-way branch is 
>> all that’s being done, < will be more efficient in many cases (if only 
>> because it’s easier for the optimizer).
>> 
>> For backwards compatibility reasons, compare will have a default 
>> implementation defined in terms of <, but to enable only using compare, < 
>> and == will also have default implementations in terms of compare.
>> 
>> The compiler will verify that either compare, or < and ==, are provided by 
>> every type that claims to conform to Comparable. This will be done in some 
>> unspecified way unavailable outside the standard library (it can be made 
>> available to in the future, but that’s an unnecessary distraction for this 
>> proposal).
>> 
> It feels weird to me to jump through all these hoops just for backwards 
> compatibility. Seeing how even big projects might only have several 
> Comparable conformances, wouldn’t it be worth removing the default 
> implementation of compare and removing < from Comparable?

The core team cares a *lot* about backwards compatibility. The engineering 
effort involved in implementing this mutually-exclusive check is very small 
compared with the benefits of maintaining compatibility.

- Doug


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

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Douglas Gregor via swift-evolution]

> On Apr 12, 2017, at 11:49 AM, Russ Bishop <rbisho...@apple.com> wrote:
> 
> Doug,
> 
> Would it be worth deferring this slightly since it relies on SE-0166? If 
> changes are made to SE-0166 as a result of review it will necessarily impact 
> this proposal.

If there are changes to SE-0166 that affect this, we can always hold off on a 
decision to make more adjustments. I don’t think we need to stagger the review 
of two closely-related proposals like this.

- Doug

> 
> 
> Russ Bishop
> 
> 
>> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
>> 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>>  
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md>
>> Note that this proposal is closely related to (and dependent on) SE-0166: 
>> Swift Archival & Serialization 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md>.
>>  Please read and review that proposal as well!
>> 
>> 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. 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/0167-swift-encoders.md
>>  
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md>
>> Reply text
>> Other replies
>>  
>> <https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>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 
>> <https://github.com/apple/swift-evolution/blob/master/process.md>
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> ___
>> 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 #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

> On Apr 6, 2017, at 9:46 PM, John McCall <rjmcc...@apple.com> wrote:
> 
>> On Apr 7, 2017, at 12:27 AM, Rick Mann <rm...@latencyzero.com> wrote:
>>> On Apr 6, 2017, at 20:37 , John McCall <rjmcc...@apple.com> wrote:
>>> 
>>>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> I tend to dislike the backslash as well, but can't suggest a good 
>>>> alternative.
>>>> 
>>>> Does any of this allow for operations within the key path? e.g. 
>>>> Department.employees.@sum.salary?
>>> 
>>> You can express things like this in the feature as proposed using 
>>> subscripts:
>>> 
>>> extension Collection {
>>> subscript(summing path: KeyPath<Element, T>) -> T {
>>>  var sum: T = 0
>>>  for let elt in self {
>>>sum += elt[keyPath: path]
>>>  }
>>>  return sum
>>> }
>>> }
>> 
>> I'm just remembering how AppKit/Cocoa lets you do things like this in a very 
>> expressive way. Your proposal seems a bit cumbersome. Maybe when we have 
>> custom annotations, they can be extended to use within key paths.
> 
> I'm not seriously endorsing this exact spelling.  It would be much better to 
> be able to write something like:
>  \Department.employees.sum(of: \.salary)
> However, since "sum" would presumably be a method on Collection, I think this 
> would have to be a future extension to the proposal, and the overall thing 
> might have to be a function rather than a key path because it would no longer 
> have identity.

Also, less clever but potentially easier to reason about:

extension Array where Element == Employee {
  var sumOfSalary: Double {
return // ...
  }
}

If you can express it in a computed property, you can refer to it via a key 
path:

\Department.employees.sumOfSalary



> Also, I do feel obliged to note that AppKit/Cocoa's "very expressive" way of 
> doing this is a small number of hard-coded operators, whereas even the 
> kindof-unfortunate subscript trick would be arbitrarily extensible.

Right.

- Doug

> John.
> 
> 
>> 
>> Thanks.
>> 
>>> 
>>> ...
>>> 
>>> \Department.employees[summing: \.salary]
>>> 
>>> That's not actually a good name for the subscript, but maybe there's one 
>>> out there.
>>> 
>>> John.
>>> 
>>>> 
>>>> Also, in this example:
>>>> 
>>>> let firstFriendsNameKeyPath = \Person.friends[0].name
>>>> let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
>>>> 
>>>> Can't we do without the keyPath: argument name? The compiler knows it's a 
>>>> keypath, it would be nicer to write
>>>> 
>>>> let firstFriend = luke[firstFriendsNameKeyPath] // "Han Solo"
>>>> 
>>>>> On Apr 5, 2017, at 16:56 , Douglas Gregor via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> Hello Swift community,
>>>>> 
>>>>> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
>>>>> Swift" begins now and runs through April 9, 2017. The revised proposal is 
>>>>> available here:
>>>>> 
>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>>>>> The core team’s feedback from the first review of this proposal can be 
>>>>> viewed at:
>>>>> 
>>>>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
>>>>> 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/0161-key-paths.md
>>>>> Reply text
>>>>> Other replies
>>>>> What goes into a review?
>>>>> 
>>>>> The goal of the review process is to improve the pro

[swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and 
Extensions" begins now and runs through April 11, 2017. The proposal is 
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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/0169-improve-interaction-between-private-declarations-and-extensions.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

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

> On Apr 6, 2017, at 1:15 PM, Michael J LeHew Jr <lehe...@apple.com> wrote:
> 
> 
>> On Apr 6, 2017, at 10:37 AM, Douglas Gregor via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Apr 6, 2017, at 10:28 AM, Ricardo Parada <rpar...@mac.com 
>>> <mailto:rpar...@mac.com>> wrote:
>>> 
>>> Do you think in the future it might be possible to convert to strings?  
>>> 
>>> For example, I am imagining a CoreData-like framework on the server (where 
>>> there is no Objective-C), where I would like to get the type of the root 
>>> object and keys forming the path.  That way I can go to an object model, 
>>> get the corresponding entity, and traversed relationships, and destination 
>>> attribute.  All that information (table name, table joins for the 
>>> relationships traversed, column names, etc.) would then be used to 
>>> construct the SQL.
>> 
>> Key-paths could be extended to allow introspection of the components along 
>> the path, in which case you would be able to map between key paths into your 
>> specific data model and the tables/columns in your database. This is not the 
> 
> ... ?  You left us hanging there Doug! :)

Eh, sorry! Making key-paths Codable could definitely make sense in the future, 
as you note. But I don’t know that a “blessed String representation” makes 
sense for key-paths.

> 
> We do mention in the proposal that support for marshalling to external 
> representation (String, Codable should that be accepted, etc) would highly 
> desirable in the future, for IB / CoreData type scenarios and more.  It is 
> one of the principle reasons we decided not to allow key paths to compose 
> with transformations (functions and closures), as while that is very powerful 
> and interesting, once you go there you're not really a key path any more. 
> 
> It's not part of this initial proposal, but could easily be brought up as a 
> follow-on in the future. 

Right.

- Doug

> 
>> 
>>  - Doug
>> 
>>> 
>>> 
>>> 
>>>> On Apr 6, 2017, at 12:37 PM, Douglas Gregor <dgre...@apple.com 
>>>> <mailto:dgre...@apple.com>> wrote:
>>>> 
>>>>> 
>>>>> On Apr 6, 2017, at 9:31 AM, Sean Heber <s...@fifthace.com 
>>>>> <mailto:s...@fifthace.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Apr 6, 2017, at 11:19 AM, Douglas Gregor <dgre...@apple.com 
>>>>>> <mailto:dgre...@apple.com>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution 
>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>> 
>>>>>>> I agree, there's an analogy between strings and key paths, and in that 
>>>>>>> regards the single quote would make sense.  I would not complain.  
>>>>>> 
>>>>>> The only analogy between strings and key-paths is that the existing 
>>>>>> Cocoa APIs for key-paths use strings. That’s not an analogy to hang 
>>>>>> language syntax on, because it’s relevance will fade quickly. 
>>>>> 
>>>>> Why would it fade quickly? Do we expect the concept of keypaths to go 
>>>>> away over time? If so, why are we even designing a syntax for keypaths?
>>>> 
>>>> The link between key-paths and strings will go away over time. The *only* 
>>>> reason anyone associates strings with keypaths is because Cocoa’s current 
>>>> key-paths are string-based. This proposal makes any string representation 
>>>> of key-paths an implementation detail that could be used for 
>>>> interoperability with Cocoa’s current system. There is no reason for a 
>>>> type-unsafe string representation to ever be in the user model.
>>>> 
>>>> 
>>>>>> The core team discussed single quotes, and decided that we want to save 
>>>>>> them for something in the string/character realm.
>>>>> 
>>>>> Are they to be saved for something specific or is this just because a lot 
>>>>> of languages use single quotes for character literals? Why is this 
>>>>> association any more sacred than an association with Cocoa string 
>>>>> keypaths?
>>>> 
>>>> 
>>>> Lots of languages use single quotes for character literals; we may want to 
>>>> bring them back for it.
>>>> 
>>>>- 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-0166: Swift Archival & Serialization

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0166 "Swift Archival & Serialization" begins now and runs 
through April 12, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.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/0166-swift-archival-serialization.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

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

[swift-evolution] [Review] SE-0167: Swift Encoders

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
Note that this proposal is closely related to (and dependent on) SE-0166: Swift 
Archival & Serialization 
.
 Please read and review that proposal as well!

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/0167-swift-encoders.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

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

> On Apr 6, 2017, at 11:01 AM, Brad Hilton  wrote:
> 
> -1. Not a huge fan of the back slash. Doesn’t make sense considering we can 
> refer to unapplied method references without the backslash. Maybe we can 
> settle on some unified syntax for both? How about Person.name.get / 
> Person.name.set for getter/setter references.

Did you read the core team’s commentary on unapplied method references?


https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
 


?
- Doug

> 
>> Hello Swift community,
>> 
>> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
>> Swift" begins now and runs through April 9, 2017. The revised proposal is 
>> available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>> The core team’s feedback from the first review of this proposal can be 
>> viewed at:
>> 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
>> 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/0161-key-paths.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
>> 
>> Review Manager
>> 
>> 

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

> On Apr 6, 2017, at 10:28 AM, Ricardo Parada  wrote:
> 
> Do you think in the future it might be possible to convert to strings?  
> 
> For example, I am imagining a CoreData-like framework on the server (where 
> there is no Objective-C), where I would like to get the type of the root 
> object and keys forming the path.  That way I can go to an object model, get 
> the corresponding entity, and traversed relationships, and destination 
> attribute.  All that information (table name, table joins for the 
> relationships traversed, column names, etc.) would then be used to construct 
> the SQL.

Key-paths could be extended to allow introspection of the components along the 
path, in which case you would be able to map between key paths into your 
specific data model and the tables/columns in your database. This is not the 

- Doug

> 
> 
> 
>> On Apr 6, 2017, at 12:37 PM, Douglas Gregor > > wrote:
>> 
>>> 
>>> On Apr 6, 2017, at 9:31 AM, Sean Heber >> > wrote:
>>> 
>>> 
 On Apr 6, 2017, at 11:19 AM, Douglas Gregor > wrote:
 
> 
> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution 
> > wrote:
> 
> I agree, there's an analogy between strings and key paths, and in that 
> regards the single quote would make sense.  I would not complain.  
 
 The only analogy between strings and key-paths is that the existing Cocoa 
 APIs for key-paths use strings. That’s not an analogy to hang language 
 syntax on, because it’s relevance will fade quickly. 
>>> 
>>> Why would it fade quickly? Do we expect the concept of keypaths to go away 
>>> over time? If so, why are we even designing a syntax for keypaths?
>> 
>> The link between key-paths and strings will go away over time. The *only* 
>> reason anyone associates strings with keypaths is because Cocoa’s current 
>> key-paths are string-based. This proposal makes any string representation of 
>> key-paths an implementation detail that could be used for interoperability 
>> with Cocoa’s current system. There is no reason for a type-unsafe string 
>> representation to ever be in the user model.
>> 
>> 
 The core team discussed single quotes, and decided that we want to save 
 them for something in the string/character realm.
>>> 
>>> Are they to be saved for something specific or is this just because a lot 
>>> of languages use single quotes for character literals? Why is this 
>>> association any more sacred than an association with Cocoa string keypaths?
>> 
>> 
>> Lots of languages use single quotes for character literals; we may want to 
>> bring them back for it.
>> 
>>  - Doug
> 

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> I agree, there's an analogy between strings and key paths, and in that 
> regards the single quote would make sense.  I would not complain.  

The only analogy between strings and key-paths is that the existing Cocoa APIs 
for key-paths use strings. That’s not an analogy to hang language syntax on, 
because it’s relevance will fade quickly. 

The core team discussed single quotes, and decided that we want to save them 
for something in the string/character realm.

- Doug


> 
> 
>> On Apr 6, 2017, at 11:08 AM, Sean Heber via swift-evolution 
>>  wrote:
>> 
 That's an interesting point. While `\` alone seems acceptable, I think 
 it's unfortunate that we'll have `(\...)` and `\(...)` both in the 
 language.
 Can we maybe consider instead:
 
let firstFriendsNameKeyPath = \Person.friends[0].name\
>>> 
>>> 'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:
>>> 
>>> // Create a key path and use it
>>> let firstFriendsNameKeyPath = 'Person.friends[0].name'
>>> luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
>>> 
>>> // or equivalently, with type inferred from context
>>> luke[keyPath: '.friends[0].name'] // "Han Solo"
>>> 
>>> // [SE-0042][SR-3550] Unapplied method references
>>> 'String.lowercased()'  // (String) -> String
>>> 'String.lowercased(with:)' // (String, Locale?) -> String
>>> 
>>> Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends 
>>> of the key path (or method reference).
>> 
>> For what it’s worth, I much rather prefer this approach and was going to 
>> suggest it today. In Objective-C, keypaths were just strings so by using a 
>> single tick, they still look *almost* like strings, but now they’re safe and 
>> checked by the compiler - magical.
>> 
>> l8r
>> Sean
>> 
>> ___
>> 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] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

> On Apr 5, 2017, at 4:55 PM, Colin Barrett  wrote:
> 
> Is the choice of backslash up for review? I think another operator,

We talked through basically everything on the keyboard, and there really aren’t 
other options that don’t stomp on existing behavior.

> perhaps backtick (`), would work better.

Backtick (`) is already taken for escaping identifiers, e.g., 

var `func` = { /* some code */ }

- Doug


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

[swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

Hello Swift community,

The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
Swift" begins now and runs through April 9, 2017. The revised proposal is 
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
 

The core team’s feedback from the first review of this proposal can be viewed 
at:

https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
 

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/0161-key-paths.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

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

[swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
 


Hello Swift community,

The review of SE-0161 “Smart KeyPaths: Better Key-Value Coding for Swift” ran 
from March 30...April 5, 2017. The proposal was very well-received *except* 
that reviewers felt that the #keyPath syntax was far too heavy for this new 
language construct, and preferred the lighter-weight syntax of the pre-review 
drafts. This proposal is returned for revision to address the syntax.

The heavyweight #keyPath syntax was requested by the core team after reviewing 
earlier drafts, which used a far lighter syntax:

// (Rejected) syntax from pre-review drafts
let firstFriendsNameKeyPath = Person.friends[0].name
print(luke[keyPath: .friends[0].name])

The core team’s specific concern was that these key path expressions (e.g., 
Person.friends[0].name) don’t make it sufficiently clear that the actual 
property accesses are being delayed, and that the contextual cues (“Person." 
vs. “luke.”) are insufficient to disambiguate for the human reader. Hence, the 
request for a different (more explicit) syntax.

Reviewers rightly point out that it is natural for key-paths to use the same 
syntax as unapplied instance method references, e.g., Person.someInstanceMethod 
produces a value of some function type with the “Self” type curried, e.g., 
(Person) -> (param-types) -> result-type. The core team agrees with this 
sentiment. The core team also felt that Swift’s existing unapplied method 
references suffer from the same clarity problems as the initial key-path 
syntax, i.e., that it isn’t sufficiently clear that the actual application of 
“self” is being delayed.

The core team has a specific proposal: use the backslash (‘\’) to as a leading 
indicator for key paths. Specifically,

// Proposed syntax for second revision
let firstFriendsNameKeyPath = \Person.friends[0].name
print(luke[keyPath: \.friends[0].name])

The backslash is a visual cue that the actual application of this chain of 
property references is delayed, eliminating ambiguities, yet is still quite 
lightweight and feels “first-class” in the language.

The core team felt that, in the future, the backslash should also be used for 
unapplied instance method references, to match the proposed syntax for key 
paths and improve clarity for this non obvious feature. This change could be 
staged in as a revision to the accepted-but-never-implemented SE-0042: 
Flattening the function type of unapplied method references 
,
 e.g.,

// Proposed future syntax for unapplied instance method references
class Person {
  func instanceMethod(_: String) -> Int { … }
}

let f1 = Person.instanceMethod   // to-be-deprecated; produces a value 
of type (Person) -> (String) -> Int
let f2 = \Person.instanceMethod  // to-be-introduced via a revised 
SE-0042: produces a value of type (Person, String) -> Int

Such an approach gives us a way to stage in SE-0042 and get to eventual 
consistency between key paths and unapplied instance method references.

- Doug
Review Manager






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

[swift-evolution] [Review] SE-0164: Remove final support in protocol extensions

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0164 "Remove final support in protocol extensions" begins now 
and runs through April 8, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.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/0164-remove-final-support-in-protocol-extensions.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

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

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Apr 5, 2017, at 1:19 AM, Víctor Pimentel  wrote:
> 
> 
> 
> Enviado desde mi iPhone
> El 4 abr 2017, a las 22:04, Douglas Gregor  escribió:
> 
>> 
>>> On Apr 4, 2017, at 12:31 PM, Víctor Pimentel Rodríguez via swift-evolution 
>>>  wrote:
>>> 
>>> Sorry to be late :/
>>> 
 On Fri, Mar 31, 2017 at 5:29 PM, Chris Lattner via swift-evolution 
  wrote:
 * What is your evaluation of the proposal?
>>> 
>>> More positive than the first one, but still some rough edges.
>>> 
>>> One concern that I still have is that if we use @objcMembers, @nonobjc 
>>> methods/properties are going to be even trickier to find.
>>> 
>>> If such modifier existed, I would like the compiler to warn me of public 
>>> methods/properties that cannot be bridged to ObjC, because I have 
>>> explicitly told the compiler that I want this object to live in the ObjC 
>>> runtime. Of course, with a fixit recommending something like explicitly 
>>> using @nonobjc.
>> 
>> @objc on extensions behaves this way; the compiler will produce an error if 
>> the entity cannot be exposed to Objective-C.
>> 
>>  - Doug
> 
> Yeah, I think you explained the behavior of extensions very well in the 
> proposal:
> 
> > If some member within that extension cannot be exposed to Objective-C, such 
> > as SwiftClass.bar(), the compiler will produce an error.
> 
> My specific question was about implicitly @nonobjc members in a @objcMembers 
> class. That is, would the compiler allow such member with no @nonobjc 
> annotation?

Yes. 

> And would extensions of such classes allow those members?

Yes. Also true for subclasses and their extensions. 

> Do I need to put @objc in every extension of a @objcMembers class to get that 
> compiler error?

Yes. 

> 
> By the way, I very much appreciate the level of care that you put into this 
> proposal and its implementation. Thank you very much!

I'm looking forward to getting feedback on how it works out in practice. I've 
had pretty good luck with my our migrations. 

  - Doug

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

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Apr 4, 2017, at 12:31 PM, Víctor Pimentel Rodríguez via swift-evolution 
>  wrote:
> 
> Sorry to be late :/
> 
> On Fri, Mar 31, 2017 at 5:29 PM, Chris Lattner via swift-evolution 
> > wrote:
> * What is your evaluation of the proposal?
> 
> More positive than the first one, but still some rough edges.
> 
> One concern that I still have is that if we use @objcMembers, @nonobjc 
> methods/properties are going to be even trickier to find.
> 
> If such modifier existed, I would like the compiler to warn me of public 
> methods/properties that cannot be bridged to ObjC, because I have explicitly 
> told the compiler that I want this object to live in the ObjC runtime. Of 
> course, with a fixit recommending something like explicitly using @nonobjc.

@objc on extensions behaves this way; the compiler will produce an error if the 
entity cannot be exposed to Objective-C.

- Doug

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

Re: [swift-evolution] Type-based ‘private’ access within a file

[Douglas Gregor via swift-evolution]

> On Apr 3, 2017, at 1:13 PM, Matthew Johnson <matt...@anandabits.com> wrote:
> 
>> 
>> On Apr 3, 2017, at 2:55 PM, Daniel Duan via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I’m concerned that we will have access control changes in a future version 
>> yet again, when light-weight modules, or other type of enforced namespace is 
>> introduced. Does the core team have any foresight on how this change would 
>> interact with such things? I had the same concern for SE-0159 as well. 
>> 
>> There’s a implicit drawback to all access control changes that 
>> migrator/fix-its cannot fix: we organize our code with tools in the 
>> language. Some colleague of mine had came up with schemes that combines file 
>> scope and Swift 3 `private` to hide details among separate protocol 
>> extensions, for example. Code ends up in certain places for a reason and 
>> updating access control invalidate those reasons.
>> 
>> I hesitate to support any changes until we have some ideas for what 
>> “ultimate glory” looks like.
> 
> +1.  
> 
> If we must make a change in Swift 4, the only change I can support for Swift 
> 4 is renaming the existing access levels.  

We don’t have to make a change in Swift 4. If there’s a change that can resolve 
this issue, great…

> That would cause some churn but can be automated and has no semantic impact.  
> I feel strongly that the semantics of access control should remain the same 
> until submodules and access control can be considered together as part of the 
> theme of a larger Swift release.  I believe the churn caused by continuing to 
> poke at the semantics of access control without addressing the broader issues 
> would be a mistake that would cause further frustration in the community.  

… but if not, then let’s shelve access control changes until some time when we 
can considered it holistically with something like submodules, as you note 
above.

> As others have already pointed out, code has been developed and organized 
> with the new scoped access model in mind.  I think the frustration over a 
> semantically neutral, fully automated migration to new names would be pretty 
> minimal 

The core team felt strongly that we couldn’t change these keywords. Source 
stability is important to Swift 4, and “don’t break source compatibility so 
much” is one of the top requests we hear from Swift developers, much more so 
than requests for specific new language features.

> and certainly much less than the frustration over the suggested semantic 
> change.  

This isn’t clear to me. There could certainly be frustration over the suggested 
semantic change, for a number of reasons:

* It’s not as “tight” a meaning of private as the current scope-based private.
* It means we have a hybrid type-based/scope-based model.
* It’s the third meaning of ‘private’ in three years.

However, it is unlikely to break code (one would need to construct an ambiguity 
between two private declarations in different extensions of the same type in 
the same file), and causes zero code churn, because it’s widening the meaning 
of “private”, not changing it.

- Doug

> 
>> 
>>> On Apr 3, 2017, at 11:34 AM, Douglas Gregor via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hello Swift Community,
>>> 
>>> In rejecting SE-0159 
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md>,
>>>  the core team described a potential direction we would like to investigate 
>>> for “private” access control that admits a limited form of type-based 
>>> access control within files. The core team is seeking some discussion here 
>>> and a motivated volunteer to put together a proposal along these lines for 
>>> review in the Swift 4 time-frame (i.e., very soon). To be clear, the core 
>>> team it’s sure this is the right direction to go… but it appears promising 
>>> and we would *love* to be able to settle the access-control issue.
>>> 
>>> The design, specifically, is that a “private” member declared within a type 
>>> “X” or an extension thereof would be accessible from:
>>> 
>>> * An extension of “X” in the same file
>>> * The definition of “X”, if it occurs in the same file
>>> * A nested type (or extension thereof) of one of the above that occurs 
>>> in the same file
>>> 
>>> This design has a number of apparent benefits:
>>> + “private” becomes the right default for “less than whole module” 
>>> visibility, 

Re: [swift-evolution] Type-based ‘private’ access within a file

[Douglas Gregor via swift-evolution]

> On Apr 3, 2017, at 12:50 PM, David Hart  wrote:
> 
> The problem I see with that is that it would introduce orthogonal access 
> levels whereas they have all been hierarchal in nature up to now.

Right. That was the motivation for “private” being restricted to 
extensions/definitions in the same source file.

- Doug

> 
>> On 3 Apr 2017, at 21:36, Charles Srstka > > wrote:
>> 
>>> On Apr 3, 2017, at 2:28 PM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> Btw, I know what I'm going to propose is a bit crazy, but how about making 
>>> private visible to extensions even outside the file but in the same module?
>> 
>> That’s actually what I suggested in my original post on the topic. My 
>> feeling was that it would allow breaking a particularly large type into 
>> separate files, thus alleviating the “huge file” problem that Swift has (and 
>> which Charlie Monroe brought up as a concern).
>> 
>> It’s still what I’d prefer personally, although I can understand why the 
>> core team might want to restrict it to files.
>> 
>> Charles
>> 
> 

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

[swift-evolution] [Rejected] SE-0159: Fix Private Access Levels

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
 


The review of ran from March 20...27, 2017. The proposal has been *rejected*.

The core team had a lengthy discussion of this proposal as well as related 
ideas that came up during (and prior to) the review [*].

SE-0159 

 specifically sought to revert the main user-facing part of SE-0025 
,
 which gave “private” lexical-scoping semantics and introduced “fileprivate”. 
The core team felt that there was sufficient evidence that 
more-restrictive-than-fileprivate access control is in use within the Swift 
community and in established patterns, such that it would be harmful to remove 
the functionality introduced by SE-0025 

 at this point.

The core team discussed the idea of renaming to keywords that was brought up in 
the thread as a way to address many of the concerns raised in SE-0159 

 while providing the same language semantics. Specifically:

* “private” -> “scoped”
* “fileprivate” -> “private”

The core team determined that such a change, while (technically) easy to 
automatically migrate, would introduce far too much churn in Swift code bases 
moving from Swift 3 to Swift 4, compromising the source stability goals set out 
for Swift 4.

Finally, the core team discussed a different potential design for “private” 
that admits a limited form of type-based access control within files. We will 
open a separate discussion thread on Swift Evolution, with the subject 
"Type-based ‘private’ access within a file", and are seeking further discussion 
there and a motivated volunteer to turn it into a new proposal for Swift 4.

- Doug Gregor
Review Manager

[*] Big thanks to Alex Martini for his excellent notes.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Type-based ‘private’ access within a file

[Douglas Gregor via swift-evolution]

Hello Swift Community,

In rejecting SE-0159 
,
 the core team described a potential direction we would like to investigate for 
“private” access control that admits a limited form of type-based access 
control within files. The core team is seeking some discussion here and a 
motivated volunteer to put together a proposal along these lines for review in 
the Swift 4 time-frame (i.e., very soon). To be clear, the core team it’s sure 
this is the right direction to go… but it appears promising and we would *love* 
to be able to settle the access-control issue.

The design, specifically, is that a “private” member declared within a type “X” 
or an extension thereof would be accessible from:

* An extension of “X” in the same file
* The definition of “X”, if it occurs in the same file
* A nested type (or extension thereof) of one of the above that occurs 
in the same file

This design has a number of apparent benefits:
+ “private” becomes the right default for “less than whole module” 
visibility, and aligns well with Swift coding style that divides a type’s 
definition into a number of extensions.
+ “fileprivate” remains for existing use cases, but now it’s use it 
more rare, which has several advantages:
+ It fits well with the "progressive disclosure” philosophy 
behind Swift: you can use public/internal/private for a while before 
encountering and having to learn about “fileprivate”   (note: we thought this 
was going to be true of SE-0025 
,
 but we were clearly wrong)
+ When “fileprivate” occurs, it means there’s some interesting 
coupling between different types in the same file. That makes fileprivate a 
useful alert to the reader rather than, potentially, something that we 
routinely use and overlook so that we can separate implementations into 
extensions.
+ “private” is more closely aligned with other programming languages 
that use type-based access control, which can help programmers just coming to 
Swift. When they reach for “private”, they’re likely to get something similar 
to what they expect—with a little Swift twist due to Swift’s heavy use of 
extensions.
+ Loosening the access restrictions on “private” is unlikely to break 
existing code.

There are likely some drawbacks:
- Developers using patterns that depend on the existing 
lexically-scoped access control of “private” may find this new interpretation 
of “private” to be insufficiently strict
- Swift’s access control would go from “entirely lexical” to “partly 
lexical and partly type-based”, which can be viewed as being more complicated

Thoughts? Volunteer?

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

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Apr 1, 2017, at 2:52 AM, Xiaodi Wu  wrote:
> 
> You're right, I had to re-read the proposal a few times to grasp fully the 
> intention there.
> 
> There was some discussion in the previous thread that this would be needed to 
> infer @objc for implementations of @objc protocol requirements, but I see 
> that this is inferred without any such annotation in this version of the 
> proposal, which IMO is definitely reasonable.

Right. We’ll infer @objc when the declaration implements a requirement of an 
@objc protocol.

> It seems @objcMembers is really geared towards introspection. That finally 
> clicked just now. Would you consider, for those of us like me who are a 
> little slower on the uptake, making this even more explicit in the spelling? 
> I'm thinking along the lines of `@introspection(objc)`, which nicely leaves 
> open the possibility of future introspection facilities that don't require 
> Objective-C. I get that "members" is meant to decribe what's going on that's 
> different from plain @objc, but for me it took a while to grasp the answer to 
> the question, "Why is this another annotation, or in other words, when would 
> I use this instead?”

Introspection is a legitimate use case, but it’s not the only use case for 
@objcMembers, and it doesn’t really convey what the attribute does—it makes the 
members @objc.

- Doug

> 
> 
> On Fri, Mar 31, 2017 at 13:30 Douglas Gregor  > wrote:
>> On Mar 31, 2017, at 9:35 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Fri, Mar 31, 2017 at 10:29 AM, Chris Lattner via swift-evolution 
>> > wrote:
>> Hello Swift community, 
>> 
>> The second review of "SE-0160: Limiting @objc inference" begins now and runs 
>> through April 2, 2017. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.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?
>> 
>> I do think this current iteration is an improvement. I have to say, though, 
>> that I prefer Doug Gregor's spelling of `@implicitobjc` over `@objcMembers`. 
>> It think the former explains the feature a little better and also happens to 
>> be subjectively nicer-looking.
> 
> I think @objcMembers is more precise: it doesn’t imply that the class itself 
> is @objc, just that the members are @objc.
> 
>   - Doug
> 

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

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Mar 31, 2017, at 11:32 AM, David Waite via swift-evolution 
>  wrote:
> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md
>>  
>> 
> 
>> * What is your evaluation of the proposal?
> 
> Mixed opinion. 
> 
> I feel the rules would be simpler if we either expected members to be objc or 
> non-objc based on the parent type, not just overrides of the parent methods. 
> I understand the space/performance optimization behind non-objc methods,   
> but @objcMember and migration issues with key paths both would go away if 
> @objc was just the default for members on an @objc class or Objective-C 
> subclass.

That’s (almost) the model we have today, except… 

> Inference that a member is not @objc solely by its signature should go away. 
> If the context expects @objc members, an incorrect signature should be an 
> error.

The effect of this is that a Swift class that derives NSObject would have to 
put “@nonobjc” on every method/property/etc. that uses Swift features that 
cannot be expressed in Objective-C. I don’t think that’s something we want.

- Doug

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

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Mar 31, 2017, at 9:35 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Fri, Mar 31, 2017 at 10:29 AM, Chris Lattner via swift-evolution 
> > wrote:
> Hello Swift community, 
> 
> The second review of "SE-0160: Limiting @objc inference" begins now and runs 
> through April 2, 2017. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.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?
> 
> I do think this current iteration is an improvement. I have to say, though, 
> that I prefer Doug Gregor's spelling of `@implicitobjc` over `@objcMembers`. 
> It think the former explains the feature a little better and also happens to 
> be subjectively nicer-looking.

I think @objcMembers is more precise: it doesn’t imply that the class itself is 
@objc, just that the members are @objc.

- Doug

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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Mar 22, 2017, at 7:50 AM, Michel Fortin via swift-evolution 
>  wrote:
> 
>> * What is your evaluation of the proposal?
> 
> Good. I'll certainly appreciate the added clarity of knowing which methods 
> are exposed to Objective-C.
> 
> Currently, Swift-only apps are bloated by unnecessary Objective-C thunks. The 
> motivation section says that this will reduce the reduce the binary sizes, 
> which is good, but should we expect not emitting those thunks will also 
> reduce by a bit the compilation times? Perhaps not by much, but I do think it 
> will.
> 
> I'm already littering some projects with plenty of `@nonobjc` annotations 
> because I don't need those thunks. This proposal would allow me to make this 
> cleaner. Perhaps the migrator should remove the `@nonobjc` attributes when 
> they become unnecessary. Actually, would the changes in this proposal make 
> the `@nonobjc` attribute irrelevant?
> 
> I'm a bit worried about the migration though.
> 
> I think it would be reasonable for the migrator to have two settings. A 
> conservative one that adds `@objc ` to all currently implicit `@objc` 
> declarations, to be used when you need to be absolutely certain everything 
> still works. Pruning of extra `@objc` would have to be done manually later, 
> if desired. And the default one that only adds `@objc` when the migrator sees 
> it as necessary.


FWIW, I’ve updated the proposal with a much more extensive discussion of the 
migration story. It incorporates “conservative” and “minimal” approaches, and 
describes how to do the “minimal” approach well. (It’s backed by a prototype 
implementation as well; see the Implementation link at the top”)

- Doug

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

[swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" 
begins now and runs through April 5, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.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/0161-key-paths.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

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

Re: [swift-evolution] Smart KeyPaths

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Mar 29, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> I would love it if we found a way to retain something as concise as that 
>>> shorthand.  I'm working on a library where users will specify a collection 
>>> of key paths pairs.  This shorthand would be a very nice piece of sugar 
>>> making the code expressing these collections (usually literals) quite a bit 
>>> more readable.
>> 
>> +1 for this.  I think it will be somewhat common to pass around arrays of 
>> these things, and a shorthand syntax of some sort would make that nicer.  
>> That said, I don’t want to slow down the proposal, since I will be using 
>> this feature the very second it becomes available.
> 
> Agreed.
> 
> One more thought on this: I don't think anyone really likes the 
> #keyPath(Type, .key1.key2)` syntax; it's just the best we've come up with. If 
> the syntax were instead this:
> 
>   #keyPath(Type).key1.key2
> 
> I think that would look cleaner and avoid drawing distinctions based on 
> subtle punctuation differences. I don't think it would clash with old-style 
> key paths since you can't have a key path to a type name anyway. And support 
> for the leading-dot syntax would fall out of it quite naturally.

To me, this reads as if you're accessing ".key1.key2" on the KeyPath instance, 
not forming a keypath. I think the whole "path" should say in the parens. 

  - Doug

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Smart KeyPaths

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution 
>>  wrote:
>> 
>> Thanks for the feedback everyone!  We have pushed a changed a bit ago to the 
>> proposal reflecting these desires.
>> 
>> https://github.com/apple/swift-evolution/pull/644/files
> 
> Quoting from the proposal:
> 
>> luke[keyPath: #keyPath(.friends[0].name)]
> 
> Really? I can understand marking one or the other, but both, even when 
> there's no ambiguity?
> 
> Let's pretend we're the type checker here. The `luke[keyPath: _]` part will 
> create a context where we know we have an `AnyKeyPath`, 
> `PartialKeyPath`, `KeyPath`, or `WritableKeyPath U>`. So if the core team's concern is about namespace clashes between 
> `Person`'s static members and key paths, why not hang the key paths off the 
> various `KeyPath` types? That is, this:
> 
>   struct Person {
>   var friends: [Person]
>   var name: String
>   }
> 
> Implies this:
> 
>   extension PartialKeyPath where Root == Person {
>   static let friends: WritableKeyPath
>   static let name: WritableKeyPath
>   }
> 
> And this:
> 
>   #keyPath(Person, .friends[0].name)
> 
> Desugars to this:
> 
>   PartialKeyPath.friends[0].name
> 
> So in a context where you already know you're passing a key path, you can 
> simply write this:
> 
>   luke[keyPath: .friends[0].name]
> 
> Which applies normal "unresolved member" logic to look it up in 
> `PartialKeyPath`.

Yes, this can be done via "unresolved member lookup". It's a little 
different---unresolved member lookup usually can't handle chaining---but the 
type checker could support it. 

> 
> The result would be that you would have to explicitly, syntactically mark key 
> paths except when the context already implied you were looking for one. In an 
> unconstrained generic context, you would not get a key path without using 
> `#keyPath` or explicitly naming a key path type. You would only need to worry 
> about clashes if a call was overloaded to accept *both* `T` and 
> `PartialKeyPath`; if we found that possibility troubling, we could 
> penalize unresolved member lookups that resolve to key paths, so type 
> inference would favor static members over key paths even in those cases.
> 
> Would that work for people? 

It's technically feasible. It makes ".foo" more contextually sensitive, which 
is probably fine. 

  - Doug

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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Mar 23, 2017, at 2:06 AM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Here’s an idea for working around the problem of the lack of static knowledge 
> during migration. Probably it’s kind of tacky and won’t get much traction in 
> it’s current form, but it might start some useful discussion at least.
> 
> Right now, @objc when applied to a _class_ is completely useless; if a class 
> ultimately inherits from NSObject, it is always implicitly @objc, and 
> applying @objc to a class not rooted in NSObject is always an error. (I think 
> at some point in the past we allowed @objc classes that _don’t_ inherit from 
> NSObject, but I don’t know if that even made it into any released version of 
> Swift, so it’s totally vestigial at this point.) We can keep this behavior in 
> Swift 3 mode, but in Swift 4 mode, change things so that @objc applied to a 
> class enables @objc inference for the members of the class, and the absence 
> of @objc enables the new, more limited inference behavior outlined in this 
> proposal.
> 
> Then the migration story can just be “slap @objc on every NSObject-derived 
> class and you’re good”. Existing mixed source bases, KVC, and so on would 
> just work. We could also say that in Swift 4 mode, @objc on an 
> NSObject-derived class produces a warning asking the developer to consider 
> making individual members @objc as necessary instead. This would allow a 
> Swift 4 migration to proceed in two phases — first fix any fallout from 
> SE-0110 or new string stuff or whatever, and get a working app that builds 
> and runs in Swift 4 mode, albeit with some warnings. Then they can deal with 
> marking individual class members as @objc later. We could still have the 
> option of making it an error to apply @objc to an entire class in a future 
> release of Swift, if we decide it is beneficial to do so.

I don’t think we should repurpose @objc to mean “infer @objc if possible”, but 
we could add a new attribute—you’d mentioned @objcMembers somewhere before, 
I’ll refer to it as @implicitobjc” here—that one could added to classes or 
extensions. The semantics could be:

* @implicitobjc added to a class implicitly makes members of that class *and 
all of its subclasses* @objc if they can be exposed to Objective-C
* @implicitobjc added to a class extension makes members of that class 
extension @objc if they can be exposed to Objective-C

This is a more elegant way to handle the XCTestCase issue—we can mark 
XCTestCase as @implicitobjc through some Clang-side attribute or API note—and 
makes it easy for class hierarchies that rely heavily on the Objective-C 
runtime to continue to get @objc inference.

- Doug

> 
> Based on feedback, the all-or-nothing nature of the Swift 2->3 migration was 
> rather painful — mixing and matching 3 and 4 modules will definitely help us 
> do better the next time around, and allowing a complex change such as this 
> one to be done piecemeal could be a further step in the right direction.
> 
> Slava
> 
>> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community, 
>> 
>> The review of "SE-0160: Limiting @objc inference" begins now and runs 
>> through March 28. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.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 
>> 
>> Thanks!
>> 
>> -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
> 

Re: [swift-evolution] Smart KeyPaths

[Douglas Gregor via swift-evolution]

> On Mar 17, 2017, at 10:04 AM, Michael LeHew via swift-evolution 
>  wrote:
> 
> Hi friendly swift-evolution folks,
> 
> The Foundation and Swift team  would like for you to consider the following 
> proposal:


The Swift core team discussed this proposal draft and had a little bit of 
pre-review feedback.

> Access and Mutation Through KeyPaths
> To get or set values for a given root and key path we effectively add the 
> following subscripts to all Swift types. 
> 
> Swift
> extension Any {
> subscript(path: AnyKeyPath) -> Any? { get }
> subscript(path: PartialKeyPath) -> Any { get }
> subscript(path: KeyPath) -> Value { get }
> subscript(path: WritableKeyPath) -> Value 
> { set, get }
> }

Swift doesn’t currently have the ability to extend Any, so this is (currently) 
pseudocode for compiler magic that one day we might be able to place. 
Additionally, the “Root: Self” constraint isn’t something we support in the 
generics system. A small note indicating that this is pseudo-code meant to get 
the point across (rather than real code to drop into the standard 
library/Foundation) would be appreciated.

More importantly, this adds an unlabeled subscript to every type, which raises 
concerns about introducing ambiguities—even if not hard ambiguities that 
prevent code from compiling (e.g., from a Dictionary)---they can 
still show up in code completion, diagnostics, etc.

The core team would prefer that this subscript distinguish itself more, e.g., 
by labeling the first parameter “keyPath” (or some better name, if there is 
one). Syntactically, that would look like:

person[keyPath: theKeyPathIHave]

> Referencing Key Paths
> 
> Forming a KeyPath borrows from the same syntax used to reference methods and 
> initializers,Type.instanceMethod only now working for properties and 
> collections. Optionals are handled via optional-chaining. Multiply dotted 
> expressions are allowed as well, and work just as if they were composed via 
> the appending methods on KeyPath.
> 
The core team was concerned about the use of the Type.instanceProperty syntax 
for a few reasons:

* It doesn’t work for forming keypaths to class/static properties (or 
is ambiguous with the existing meaning(, so we would need another syntax to 
deal with that case
* It’s quite subtle, even more so that the existing Type.instanceMethod 
syntax for currying instance methods

> There is no change or interaction with the #keyPath() syntax introduced in 
> Swift 3. 
> 
The core team felt that extending the #keyPath syntax was a better syntactic 
direction to produce key-paths.

- Doug

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

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Mar 25, 2017, at 3:46 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Mar 24, 2017, at 10:09 AM, Douglas Gregor  wrote:
>> 
>>> I'm actually not worried about methods so much as properties. KVC is 
>>> completely untyped on the Objective-C side, and there are several different 
>>> mechanisms there which use KVC with poorly validated external strings, like 
>>> bindings, sort descriptors, and predicates. Tons of migration errors are 
>>> going to escape into production if we do this,
>> 
>> We can avoid these by migrating conservatively (have the migrator add @objc 
>> everywhere it’s inferred in Swift 3).
> 
> We can do that, but personally, I really hate these kinds of conservative 
> migrations. It might be unavoidable, though.
> 
>>> Have you considered a deprecation cycle (for instance, having Swift 4 
>>> thunks log a warning that they're going away in Swift 5)?
>> 
>> I think Swift 3 -> Swift 4 is the deprecation cycle, no?
> 
> But there was no indication during Swift 3 that this feature was going away. 
> As I understand it, a deprecation cycle introduces advanced warning of a 
> change so you have time to prepare for it; that's not available here.

The deprecation cycle is however long Swift 3 compatibility mode is around: 
Swift 3 compatibility mode can start warning about uses of the deprecated @objc 
inference—both in the compiler proper and at runtime via logging.

> 
> My concern is that, because the tools are not really aware of KVC, we can't 
> count on the compiler to lead developers to missing `@objc` properties. Folks 
> are only going to find those mistakes through testing, and they're inevitably 
> going to miss a few spots. So some poor schmuck is going to migrate their 
> code to Swift 4 without realizing this is an issue at all, accidentally miss 
> a few spots in their testing, ship it, and have to deal with weird crashes 
> out of nowhere. They're going to say, "My code worked just fine before. Swift 
> 4 broke it!" And they won't be wrong.
> 
> I'd be more comfortable with a version-long deprecation cycle that gave 
> developers plenty of time to notice these bugs. Failing that, I'd at least 
> like to see them get backtraces containing a symbol name like 
> `YouCantInvokeASwiftMemberThroughTheObjectiveCRuntimeUnlessItsMarkedWithAtObjc`
>  so the nature of the problem and its solution will be more obvious. 
> (Preferably, this function would log the instance and selector, so if people 
> got both the logs and the backtrace, the diagnosis would be as simple as we 
> can make it.)

We can do logs with a backtrace. This is fantastic suggestion also made earlier.

> (Actually, I wonder if we could install a `-doesNotRecognizeSelector:` 
> override in Swift classes which looked for a matching member in the Swift 
> runtime metadata and, if it found one, called the `YouCantInvoke…` function? 
> That would be lower overhead than generating stubs at compile time, and the 
> slowness of searching the runtime metadata wouldn't matter much since it was 
> going to crash anyway. I'm not sure if it might remove useful information 
> from the backtrace, though. Maybe in Swift 5, when these bugs will be more 
> rare. Or maybe in `SwiftObject`.)

The Objective-C thunks are nontrivial code patterns that we won’t be able to 
generate at runtime without a ton of infrastructure, so we’re stuck with 
statically generating the stubs. Also, we don’t have Swift runtime metadata for 
methods now.

> 
>> Plus, inheritance from an Objective-C class is often incidental: you do it 
>> because you need an NSObjectProtocol conformance, or something else expects 
>> NSObject. I haven’t heard of developers inheriting from NSObject solely to 
>> get @objc inference for their members.
> 
> You do it because you need a particular object to interact with Objective-C. 
> In that circumstance, I don't think the compiler is wrong to assume that you 
> want to expose as many members as possible to Objective-C.

You don’t need it for a particular object to interact with Objective-C; you 
need it so that the class itself is visible to Objective-C source code. Or 
because something forced you to inherit from NSObject (e.g,, the 
NSObjectProtocol, which I mentioned in my reply to Charles).

> 
>>> you already have to specify `dynamic` to avoid optimizations;
>> 
>> Conceptually, ‘dynamic’ is orthogonal to ‘@objc’. In today’s implementation, 
>> we can only implement ‘dynamic’ via the Objective-C runtime, hence this 
>> proposal’s requirement to write both.
> 
> I understand that, but again, I think it's defensible for the compiler to 
> assume that, if you want dynamic behavior in a class where you've already 
> enabled Objective-C interop, you probably want that dynamic behavior to be 
> compatible with Objective-C.
> 
> I guess we just take different standpoints on Objective-C interop. My belief 
> is that, if you state an intention to have a type interoperate with 
> 

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Mar 26, 2017, at 8:23 PM, Charlie Monroe  wrote:
> 
>> 
>> On Mar 25, 2017, at 11:46 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> On Mar 24, 2017, at 10:09 AM, Douglas Gregor  wrote:
>>> Plus, inheritance from an Objective-C class is often incidental: you do it 
>>> because you need an NSObjectProtocol conformance, or something else expects 
>>> NSObject. I haven’t heard of developers inheriting from NSObject solely to 
>>> get @objc inference for their members.
>> 
>> You do it because you need a particular object to interact with Objective-C. 
>> In that circumstance, I don't think the compiler is wrong to assume that you 
>> want to expose as many members as possible to Objective-C.
> 
> In my experience, there are two types of projects nowadays (in regards to 
> Swift-ObjC interop):
> 
> 1) New projects that are generally pure Swift or include some ObjC files as a 
> bridge for interaction with C++ or some other stuff Swift can't currently do. 
> In such case, the NSObject inheritence is usually due to the NSObjectProtocol 
> requirement defined by most delegates in Cocoa (Touch). In such cases, you're 
> usually expecting just the delegate methods to be exposed to the ObjC runtime.

The NSObjectProtocol requirement is something that isn’t technically even 
necessary in Swift. Every Swift class already defines implementations for 
anything in NSObjectProtocol; we could, in fact, completely erase 
NSObjectProtocol (or just call it AnyObject) and it would reduce the reliance 
of Swift programs on NSObject.

> 2) Projects with mixed Swift/ObjC code, where you usually really need to 
> expose as many members to ObjC as possible. As you need to communicate with 
> your objects from ObjC, you need to indeed have most declaractions as @objc.

I do wonder about the “most” here; it implies that “most” non-private APIs that 
aren’t overrides and aren’t satisfying @objc protocol requirements are used 
from Objective-C.

> As it is, however, just the public API and it's usually just a temporary fix, 
> I'm personally fine with marking them as @objc. By "temporary fix" I mean 
> that with the future ahead, the ObjC code will eventually get rewritten to 
> Swift, so it's a fix as long as you need to expose the API to ObjC.

Even if that isn’t the future for that codebase, @objc documents the use of an 
API across languages.

> All things considered, I do agree that it's a huge change that would come too 
> quickly and would agree on deprecating this in Swift 4 and removing in Swift 
> 5.


> Please keep in mind that for a one-person team such as myself, testing of 
> e.g. 5 apps thoroughly simply takes a lot of time and as the releases of 
> Swift are usually (or have been historically) in line with releases of new OS 
> versions, there's a lot of pressure during those months leading to these 
> releases on developers and postponing this change while giving them the tools 
> (deprecation messages, breakpoint symbols) would IMHO help a lot.

Brent mentioned this desire for a longer deprecation cycle; I’ll reply to his 
message on the topic.

- Doug



> 
> 
>> 
 you already have to specify `dynamic` to avoid optimizations;
>>> 
>>> Conceptually, ‘dynamic’ is orthogonal to ‘@objc’. In today’s 
>>> implementation, we can only implement ‘dynamic’ via the Objective-C 
>>> runtime, hence this proposal’s requirement to write both.
>> 
>> I understand that, but again, I think it's defensible for the compiler to 
>> assume that, if you want dynamic behavior in a class where you've already 
>> enabled Objective-C interop, you probably want that dynamic behavior to be 
>> compatible with Objective-C.
>> 
>> I guess we just take different standpoints on Objective-C interop. My belief 
>> is that, if you state an intention to have a type interoperate with 
>> Objective-C, Swift should try to expose as many of its members to 
>> Objective-C as possible. I think you believe that Swift should expose as 
>> *little* as possible to Objective-C.
>> 
>> Because of that difference, I actually think I'd be *more* likely to support 
>> removing inference by requiring an explicit `@nonobjc` on members of 
>> Objective-C-compatible classes which aren't compatible with Objective-C. 
>> That is, writing:
>> 
>>  class Foo: NSObject {
>>  var bar: Int?
>>  }
>> 
>> Is an error; you have to write:
>> 
>>  class Foo: NSObject {
>>  @nonobjc var bar: Int?
>>  }
>> 
>> I don't really like that answer very much, but I like it more than I would 
>> like requiring `@objc` if `bar` were a plain `Int`.
>> 
 Would you like the request for bridging notarized and filed in triplicate?
>> 
>> (By the way, in reading this later, I realized this part might have sounded 
>> a little too angry. I was trying to be funny. Nobody complained, but I'm 
>> sorry if I missed the mark here.)
>> 
>> -- 
>> Brent 

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Mar 22, 2017, at 10:55 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> * What is your evaluation of the proposal?
> 
> I'm going to have to come down on the "no" side on this one.
> 
> I'm actually not worried about methods so much as properties. KVC is 
> completely untyped on the Objective-C side, and there are several different 
> mechanisms there which use KVC with poorly validated external strings, like 
> bindings, sort descriptors, and predicates. Tons of migration errors are 
> going to escape into production if we do this,

We can avoid these by migrating conservatively (have the migrator add @objc 
everywhere it’s inferred in Swift 3).

> and undetectable mistakes are going to continue on an ongoing basis. 

… but what you say above is definitely true: the error of omission of @objc 
will cause breakage for these cases. 


> Have we explored alternate implementations? For instance, when the compiler 
> can statically determine all of the call sites for an `@objc` member, could 
> we emit *only* an implementation with the Objective-C calling convention and 
> call that directly from Swift?
> 
> Could members with binary-compatible signatures share a thunk? The 
> Objective-C calling convention includes a selector parameter, so you can 
> still determine the desired message.
> 
> Could we give implicit methods and properties a different, slower 
> implementation that leverages Objective-C's dynamic features? Imagine, for 
> instance, mapping in `imp_implementationWithBlock()`-style pages of 
> general-purpose thunks at runtime to reduce code size, then installing them 
> lazily with `+resolveClassMethod:`. (Maybe this could actually be made fast 
> enough, amortized over all calls, that we could get rid of the thunks 
> entirely—I don't know.)

(Slava talked through some of these)

> Have you evaluated applying different rules to methods and properties?

For me, I’d rather reject the proposal as a whole than further complicate the 
rules for @objc inference.

> Have you considered a deprecation cycle (for instance, having Swift 4 thunks 
> log a warning that they're going away in Swift 5)?

I think Swift 3 -> Swift 4 is the deprecation cycle, no?

> Or is the real motivation that, code size issues aside, you think these 
> members ought to be explicitly marked `@objc` for philosophical reasons?

That’s certainly *a* reason. The @objc inference rules are fairly complicated 
and even experienced developers can’t easily guess whether something will be 
exposed to Objective-C or not because (e.g.) minor changes in the 
parameter/result types of a method can affect it.

> If so, how many times do you want people to say so?

Once per API that’s exposed to Objective-C.

> You already have to explicitly inherit from an `@objc` base class;

You don’t *need* to inherit from an `@objc` base class to have an @objc member, 
but @objc inference ties together the notions of 

Plus, inheritance from an Objective-C class is often incidental: you do it 
because you need an NSObjectProtocol conformance, or something else expects 
NSObject. I haven’t heard of developers inheriting from NSObject solely to get 
@objc inference for their members.

> you already have to specify `dynamic` to avoid optimizations;

Conceptually, ‘dynamic’ is orthogonal to ‘@objc’. In today’s implementation, we 
can only implement ‘dynamic’ via the Objective-C runtime, hence this proposal’s 
requirement to write both.

> now you also have to mark individual members `@objc`? Would you like the 
> request for bridging notarized and filed in triplicate?

> I can understand the impulse to require it explicitly on `public` members, 
> but on the other hand, if you *do* accidentally publish a member as `@objc`, 
> what's the harm? Is there any non-breaking change you can make to a 
> `@nonobjc` method which wouldn't be legal on an `@objc` one?

There probably are; making an Int parameter of a final method Int? isn’t 
generally source-breaking, but means that you can no longer expose an @objc 
entrypoint. That said...

> Or can you just deprecate the `@objc` version and move on?

it’s easy to leave a deprecated @objc entrypoint in place if this happened to 
you, so I don’t think “accidentally made an @objc API that I wanted to be 
@nonobjc and now I have to support it going forward” is  strong argument in 
favor of this proposal.

- Doug

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