Re: [swift-evolution] [Pitch/plea] Recursive protocol constraints

[Douglas Gregor via swift-evolution]

> On Jan 2, 2017, at 1:03 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Mon Jan 02 2017, Austin Zheng  > wrote:
>> Anyone who wants to help, by the way, is more than welcome to; I'm happy to
>> take PRs or just even a message describing what needs to change, and I'd of
>> course add you to the authors list...
>> 
>> Regarding "valid" recursive constraints breaking the compiler: it was a
>> reference to something Doug said in his original email:
>> 
>>> I also have a nagging feeling that we will need some form of
>>> restrictions on this feature for implementation reasons, e.g.,
>>> because some recursive constraints will form unsolvable systems.
> 
> I wouldn't concern myself much with such vague fears-and-doubts if I
> were you.  Consider that unsolvable systems would be a *fundamental*
> reason for needing restrictions, rather than an implementation reason.
> If we discover such a scenario, we'll deal with it.  My intuition is
> that any such unsolvable systems will fall under the rubric of
> ambiguities, so the restriction will be something like “don't make
> something ambiguous.”


Yeah, Dave’s right about my vague fears. If they are actual problems, we can 
amend the proposal with any additional restrictions that come up. My apologies 
if I sent you down a wrong path!

Thank you for working on this! I left a few comments on the commits as well, 
but the proposal is looking good!

- Doug

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

Re: [swift-evolution] Enhanced Existentials

[David Sweeris via swift-evolution]

> On Jan 4, 2017, at 21:28, Douglas Gregor  wrote:
> 
>> On Jan 4, 2017, at 9:19 PM, David Sweeris  wrote:
>> 
>> On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>>> Yeah. I'm less sure about the other enhancements to existentials fitting 
>>> into Swift 4, e.g., the creation of existentials for protocols with 
>>> associated types. Although important, it's a big feature that will take a 
>>> bunch of design and implementation time, and I'm leery of accepting 
>>> something that we might not actually be able to achieve.
>> 
>> If it's a feature we know we want, it seems that nailing the syntax down, 
>> even if we know there isn't time to actually fully implement it in 4.0, 
>> would be beneficial simply to prevent it from being a source-breaking change 
>> in 4.1.
> 
> Well, there is an opportunity cost to designing something that you know won’t 
> get implemented. That said, I won’t try to actually stop anyone from 
> discussing such a much-needed feature; I just might not participate much.

That's not a bad point. Ideally we'll either have the time to completely 
implement it for 4.0, or "prove" it can be implemented later without risking 
source-compatibility.

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

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Jan 4, 2017, at 9:36 PM, Charlie Monroe  wrote:
> 
> I'm personally coming back and forth on this - my code is now 99% pure Swift, 
> so I don't really need @objc declarations aside for:
> 
> - CoreData - which is fairly obvious and @NSManaged will scream if the type 
> isn't @objc-compatible
> 
> - UI - and this is a big part. Unfortunately, I've relied on @objc inference 
> in multiple cases when it comes to binding (macOS). Or to be more precise 
> @objc implied dynamic. So for NSObject subclasses
> 
> var foo: String = ""
> 
> is without further annotations usable with bindings (though IB screams that 
> NSString is expected and it found String). And who has previously dealt with 
> them knows that this change will be hell to debug and discover all the places 
> since Interface Builder usually isn't very helpful in this matter.
> 
> In order for the migration to go smoothly, it would require the IB to do some 
> kind of keyPath validations and add annotations to those places as well. 
> Without it, I can't imagine the transition... IB has been a source of great 
> deal of ObjC -> Swift headaches, I wish there weren't any more.

>From a migration standpoint, Timothy Wood’s suggestion would properly migrate 
>such code to Swift 4. However, my proposal could make *authoring* such code 
>harder, because you would have to remember to write the @objc… and debugging 
>the failures at runtime could be painful. Maybe there’s some trick in the 
>runtime we could do to provide a better failure when things do go badly here.

- Doug

> 
> 
>> On Jan 5, 2017, at 1:50 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> Here’s a draft proposal to limit inference of @objc to only those places 
>> where we need it for consistency of the semantic model. It’s in the realm of 
>> things that isn’t *needed* for ABI stability, but if we’re going to make the 
>> source-breaking change here we’d much rather do it in the Swift 4 time-frame 
>> than later. Proposal is at:
>> 
>>  
>> https://github.com/DougGregor/swift-evolution/blob/objc-inference/proposals/-objc-inference.md
>>  
>> 
>> 
>> Introduction
>> 
>> One can explicitly write @objc on any Swift declaration that can be 
>> expressed in Objective-C. As a convenience, Swift also infers @objc in a 
>> number of places to improve interoperability with Objective-C and eliminate 
>> boilerplate. This proposal scales back the inference of @objc to only those 
>> cases where the declaration must be available to Objective-C to maintain 
>> semantic coherence of the model, e.g., when overriding an @objc method or 
>> implementing a requirement of an @objcprotocol. Other cases currently 
>> supported (e.g., a method declared in a subclass of NSObject) would no 
>> longer infer @objc, but one could continue to write it explicitly to produce 
>> Objective-C entry points.
>> 
>> Swift-evolution thread: here 
>> 
>>  
>> Motivation
>> 
>> There are several observations motivating this proposal. The first is that 
>> Swift's rules for inference of @objc are fairly baroque, and it is often 
>> unclear to users when @objc will be inferred. This proposal seeks to make 
>> the inference rules more straightforward. The second observation is that it 
>> is fairly easy to write Swift classes that inadvertently cause Objective-C 
>> selector collisions due to overloading, e.g.,
>> 
>> class MyNumber : NSObject {
>>   init(_ int: Int) { }
>>   init(_ double: Double) { } // error: initializer 'init' with Objective-C 
>> selector 'init:' 
>>   // conflicts with previous declaration with the same Objective-C 
>> selector
>> }
>> The example above also illustrates the third observation, which is that code 
>> following the Swift API Design Guidelines 
>>  will use Swift 
>> names that often translate into very poor Objective-C names that violate the 
>> Objective-C Coding Guidelines for Cocoa 
>> .
>>  Specifically, the Objective-C selectors for the initializers above should 
>> include a noun describing the first argument, e.g., initWithInteger: and 
>> initWithDouble:, which requires explicit @objc annotations anyway:
>> 
>> class MyNumber : NSObject {
>>   @objc(initWithInteger:) init(_ int: Int) { }
>>   @objc(initWithDouble:) init(_ double: Double) { }
>> }
>> The final observation is that there is a cost for each Objective-C entry 
>> point, because the Swift compiler must create a "thunk" method that maps 
>> from the Objective-C 

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Douglas Gregor via swift-evolution]

> On Jan 4, 2017, at 9:44 PM, Saagar Jha  wrote:
> 
> So, then this should have a warning? I’m still not getting one.
> 
> func foo(a: () -> (), b: (() -> ())? = nil, c: Int) {
>   a()
>   b?()
> }
> 
> foo(a: {
>   print(“Bar”)
> }, c: 0)
> 

If you give “c” a default value (e.g., “= 0”), it will give a warning.

I’m happy for the warning to get more eager, so long as it also gets a Fix-It 
at the same time.

- Doug

> Saagar Jha
> 
> 
> 
>> On Jan 4, 2017, at 9:34 PM, Douglas Gregor > > wrote:
>> 
>> 
>>> On Jan 4, 2017, at 9:32 PM, Saagar Jha >> > wrote:
>>> 
>>> 
>>> 
>>> Saagar Jha
>>> 
>>> 
>>> 
 On Jan 4, 2017, at 8:35 PM, Douglas Gregor > wrote:
 
 
 On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution 
 > wrote:
 
> Check out this thread 
> –it’s
>  very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to 
> this as well as the ability to use multiple trailing closures like so:
> 
> animate(identifier: “”, duration: 0, update: {
>   // update
> }, completion: {
>   // completion
> }
> 
> Saagar Jha
> 
> 
> 
>> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution 
>> > wrote:
>> 
>> When you have a function with a closure and then another optional 
>> default = nil closure at the end, like this:
>> 
>> open static func animate(identifier: String,
>>  duration: Double,
>>  update: @escaping AnimationUpdate,
>>  completion: AnimationCompletion? = nil) {
>> You can’t use trailing closure syntax for the update argument when 
>> leaving the completion argument out/default.
>> 
>> This kind of breaks one of the benefits of default arguments, which is 
>> that you can add them to existing released functions without breaking 
>> the calling code. This means you have to add a separate convenience 
>> function without the extra argument, which is annoying and inelegant.
>> 
 Why not simply add the "completion" parameter before the trailing closure? 
 That would still allow existing callers to work, without having to change 
 the language. 
 
>> Another annoying thing is that you can easily miss this error if you 
>> happen to not use trailing closure syntax in your tests or other usage, 
>> because adding the extra default argument compiles fine for code that 
>> uses normal syntax.
>> 
 The Swift compiler warns when a parameter written as a closure type isn't 
 the last parameter. The warning is actually disabled in the specific case 
 above because you've written it using a typealias... maybe we should warn 
 on such cases (it's worth a bug report). Regardless, in the majority of 
 instances, you'll get a warning, so it won't be silent on disabling 
 trailing closure syntax. 
>>> 
>>> Tried this out in the playground:
>>> 
>>> func foo(a: () -> (), b: (() -> ())? = nil) {
>>> a()
>>> b?()
>>> }
>>> 
>>> foo(a: {
>>> print(“Bar”)
>>> })
>>> 
>>> and didn’t receive a warning for it, either.
>> 
>> We don’t warn here because ‘foo’ does have a trailing closure… it’s for the 
>> second parameter. I guess we could still warn about ‘a’ (maybe lump it into 
>> the same bug about the typealias case).
>> 
>>  - Doug
>> 
> 

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

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Saagar Jha via swift-evolution]

So, then this should have a warning? I’m still not getting one.

func foo(a: () -> (), b: (() -> ())? = nil, c: Int) {
a()
b?()
}

foo(a: {
print(“Bar”)
}, c: 0)

Saagar Jha



> On Jan 4, 2017, at 9:34 PM, Douglas Gregor  wrote:
> 
> 
>> On Jan 4, 2017, at 9:32 PM, Saagar Jha > > wrote:
>> 
>> 
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Jan 4, 2017, at 8:35 PM, Douglas Gregor >> > wrote:
>>> 
>>> 
>>> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution 
>>> > wrote:
>>> 
 Check out this thread 
 –it’s
  very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to 
 this as well as the ability to use multiple trailing closures like so:
 
 animate(identifier: “”, duration: 0, update: {
// update
 }, completion: {
// completion
 }
 
 Saagar Jha
 
 
 
> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution 
> > wrote:
> 
> When you have a function with a closure and then another optional default 
> = nil closure at the end, like this:
> 
> open static func animate(identifier: String,
>  duration: Double,
>  update: @escaping AnimationUpdate,
>  completion: AnimationCompletion? = nil) {
> You can’t use trailing closure syntax for the update argument when 
> leaving the completion argument out/default.
> 
> This kind of breaks one of the benefits of default arguments, which is 
> that you can add them to existing released functions without breaking the 
> calling code. This means you have to add a separate convenience function 
> without the extra argument, which is annoying and inelegant.
> 
>>> Why not simply add the "completion" parameter before the trailing closure? 
>>> That would still allow existing callers to work, without having to change 
>>> the language. 
>>> 
> Another annoying thing is that you can easily miss this error if you 
> happen to not use trailing closure syntax in your tests or other usage, 
> because adding the extra default argument compiles fine for code that 
> uses normal syntax.
> 
>>> The Swift compiler warns when a parameter written as a closure type isn't 
>>> the last parameter. The warning is actually disabled in the specific case 
>>> above because you've written it using a typealias... maybe we should warn 
>>> on such cases (it's worth a bug report). Regardless, in the majority of 
>>> instances, you'll get a warning, so it won't be silent on disabling 
>>> trailing closure syntax. 
>> 
>> Tried this out in the playground:
>> 
>> func foo(a: () -> (), b: (() -> ())? = nil) {
>>  a()
>>  b?()
>> }
>> 
>> foo(a: {
>>  print(“Bar”)
>> })
>> 
>> and didn’t receive a warning for it, either.
> 
> We don’t warn here because ‘foo’ does have a trailing closure… it’s for the 
> second parameter. I guess we could still warn about ‘a’ (maybe lump it into 
> the same bug about the typealias case).
> 
>   - Doug
> 

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

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

[Douglas Gregor via swift-evolution]

> On Jan 4, 2017, at 8:59 PM, Timothy Wood  wrote:
> 
> 
> 
> 
>> On Jan 4, 2017, at 4:50 PM, Douglas Gregor via swift-evolution 
>> > wrote:
> 
> 
> 
>> A Swift 3-to-4 migrator is the hardest part of the story. Ideally, the 
>> migrator to only add @objc in places where it is needed, so that we see some 
>> of the expected benefits of code-size reduction. However, there are two 
>> problems with doing so:
>> 
>> Some of the uses that imply the need to add @objc come from Objective-C 
>> code, so a Swift 3-to-4 migrator would also need to compile the Objective-C 
>> code (possibly with a modified version of the Objective-C compiler) and 
>> match up the "deprecated" warnings mentioned in the Swift 3 compatibility 
>> mode bullet with Swift declarations.
>> 
>> The migrator can't reason about dynamically-constructed selectors or the 
>> behavior of other tools that might directly use the Objective-C runtime, so 
>> failing to add a @objc will lead to migrated programs that compile but fail 
>> to execute correctly.
>> 
> This seems fairly worrisome, but I’m sure how much so. I personally would 
> probably prefer a guaranteed non-breaking migrator (since Swift 4 isn’t 
> supposed to break stuff…) that adds the @objc where it was previously 
> inferred. Sure, this won’t make existing code smaller/faster, but more 
> importantly it won’t break it. The developer than then opt to remove the 
> unneeded annotations over time (allowing for incremental testing and later 
> bisection if a problem crops up).

It’s the conservative thing for the migrator to do, although it’ll potentially 
make a mess of migrated source code by littering it with 
potentially-unnecessary @objc’s.

>> Proposal add-on: @objc annotations on class definitions and extensions
>> 
>> If the annotation burden of @objc introduced by this proposal is too high, 
>> we could make @objc on a class definition or extension thereof imply @objc 
>> on those members that can be exposed to Objective-C. For example:
>> 
>> @objc extension MyClass {
>>   // implicitly @objc
>>   func f() { }
>> 
>>   // Cannot be exposed to Objective-C because tuples aren't representable in 
>> Objective-C
>>   func g() -> (Int, Int) { return (1, 2) }
>> }
> This seems like it goes counter to cleaning up the confusion by 
> re-introducting silent non-exposure due to use of Swift-only types. It also 
> seems odd that @objc would cascade to members when `public` and other access 
> levels don’t (though it could do the same inference based on the access level 
> of the types involved.

Yeah, I tend to agree with you that this add-on is likely not worth doing. I 
put it into the draft this way to provoke discussion, because this has come up 
before.

- Doug


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

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

[Charlie Monroe via swift-evolution]

I'm personally coming back and forth on this - my code is now 99% pure Swift, 
so I don't really need @objc declarations aside for:

- CoreData - which is fairly obvious and @NSManaged will scream if the type 
isn't @objc-compatible

- UI - and this is a big part. Unfortunately, I've relied on @objc inference in 
multiple cases when it comes to binding (macOS). Or to be more precise @objc 
implied dynamic. So for NSObject subclasses

var foo: String = ""

is without further annotations usable with bindings (though IB screams that 
NSString is expected and it found String). And who has previously dealt with 
them knows that this change will be hell to debug and discover all the places 
since Interface Builder usually isn't very helpful in this matter.

In order for the migration to go smoothly, it would require the IB to do some 
kind of keyPath validations and add annotations to those places as well. 
Without it, I can't imagine the transition... IB has been a source of great 
deal of ObjC -> Swift headaches, I wish there weren't any more.


> On Jan 5, 2017, at 1:50 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Here’s a draft proposal to limit inference of @objc to only those places 
> where we need it for consistency of the semantic model. It’s in the realm of 
> things that isn’t *needed* for ABI stability, but if we’re going to make the 
> source-breaking change here we’d much rather do it in the Swift 4 time-frame 
> than later. Proposal is at:
> 
>   
> https://github.com/DougGregor/swift-evolution/blob/objc-inference/proposals/-objc-inference.md
>  
> 
> 
> Introduction
> 
> One can explicitly write @objc on any Swift declaration that can be expressed 
> in Objective-C. As a convenience, Swift also infers @objc in a number of 
> places to improve interoperability with Objective-C and eliminate 
> boilerplate. This proposal scales back the inference of @objc to only those 
> cases where the declaration must be available to Objective-C to maintain 
> semantic coherence of the model, e.g., when overriding an @objc method or 
> implementing a requirement of an @objcprotocol. Other cases currently 
> supported (e.g., a method declared in a subclass of NSObject) would no longer 
> infer @objc, but one could continue to write it explicitly to produce 
> Objective-C entry points.
> 
> Swift-evolution thread: here 
> 
>  
> Motivation
> 
> There are several observations motivating this proposal. The first is that 
> Swift's rules for inference of @objc are fairly baroque, and it is often 
> unclear to users when @objc will be inferred. This proposal seeks to make the 
> inference rules more straightforward. The second observation is that it is 
> fairly easy to write Swift classes that inadvertently cause Objective-C 
> selector collisions due to overloading, e.g.,
> 
> class MyNumber : NSObject {
>   init(_ int: Int) { }
>   init(_ double: Double) { } // error: initializer 'init' with Objective-C 
> selector 'init:' 
>   // conflicts with previous declaration with the same Objective-C 
> selector
> }
> The example above also illustrates the third observation, which is that code 
> following the Swift API Design Guidelines 
>  will use Swift names 
> that often translate into very poor Objective-C names that violate the 
> Objective-C Coding Guidelines for Cocoa 
> .
>  Specifically, the Objective-C selectors for the initializers above should 
> include a noun describing the first argument, e.g., initWithInteger: and 
> initWithDouble:, which requires explicit @objc annotations anyway:
> 
> class MyNumber : NSObject {
>   @objc(initWithInteger:) init(_ int: Int) { }
>   @objc(initWithDouble:) init(_ double: Double) { }
> }
> The final observation is that there is a cost for each Objective-C entry 
> point, because the Swift compiler must create a "thunk" method that maps from 
> the Objective-C calling convention to the Swift calling convention and is 
> recorded within Objective-C metadata. This increases the size of the binary 
> (preliminary tests on some Cocoa[Touch] apps found that 6-8% of binary size 
> was in these thunks alone, some of which are undoubtedly unused), and can 
> have some impact on load time (the dynamic linker has to sort through the 
> Objective-C metadata for these thunks).
> 
>  
> Proposed
>  solution
> 
> The proposed solution is to limit the inference of @objc to only those places 
> where it is required for 

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Douglas Gregor via swift-evolution]

> On Jan 4, 2017, at 9:32 PM, Saagar Jha  wrote:
> 
> 
> 
> Saagar Jha
> 
> 
> 
>> On Jan 4, 2017, at 8:35 PM, Douglas Gregor > > wrote:
>> 
>> 
>> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution 
>> > wrote:
>> 
>>> Check out this thread 
>>> –it’s
>>>  very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to 
>>> this as well as the ability to use multiple trailing closures like so:
>>> 
>>> animate(identifier: “”, duration: 0, update: {
>>> // update
>>> }, completion: {
>>> // completion
>>> }
>>> 
>>> Saagar Jha
>>> 
>>> 
>>> 
 On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution 
 > wrote:
 
 When you have a function with a closure and then another optional default 
 = nil closure at the end, like this:
 
 open static func animate(identifier: String,
  duration: Double,
  update: @escaping AnimationUpdate,
  completion: AnimationCompletion? = nil) {
 You can’t use trailing closure syntax for the update argument when leaving 
 the completion argument out/default.
 
 This kind of breaks one of the benefits of default arguments, which is 
 that you can add them to existing released functions without breaking the 
 calling code. This means you have to add a separate convenience function 
 without the extra argument, which is annoying and inelegant.
 
>> Why not simply add the "completion" parameter before the trailing closure? 
>> That would still allow existing callers to work, without having to change 
>> the language. 
>> 
 Another annoying thing is that you can easily miss this error if you 
 happen to not use trailing closure syntax in your tests or other usage, 
 because adding the extra default argument compiles fine for code that uses 
 normal syntax.
 
>> The Swift compiler warns when a parameter written as a closure type isn't 
>> the last parameter. The warning is actually disabled in the specific case 
>> above because you've written it using a typealias... maybe we should warn on 
>> such cases (it's worth a bug report). Regardless, in the majority of 
>> instances, you'll get a warning, so it won't be silent on disabling trailing 
>> closure syntax. 
> 
> Tried this out in the playground:
> 
> func foo(a: () -> (), b: (() -> ())? = nil) {
>   a()
>   b?()
> }
> 
> foo(a: {
>   print(“Bar”)
> })
> 
> and didn’t receive a warning for it, either.

We don’t warn here because ‘foo’ does have a trailing closure… it’s for the 
second parameter. I guess we could still warn about ‘a’ (maybe lump it into the 
same bug about the typealias case).

- Doug

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

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Saagar Jha via swift-evolution]

Saagar Jha



> On Jan 4, 2017, at 8:35 PM, Douglas Gregor  wrote:
> 
> 
> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution 
> > wrote:
> 
>> Check out this thread 
>> –it’s
>>  very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to 
>> this as well as the ability to use multiple trailing closures like so:
>> 
>> animate(identifier: “”, duration: 0, update: {
>>  // update
>> }, completion: {
>>  // completion
>> }
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution 
>>> > wrote:
>>> 
>>> When you have a function with a closure and then another optional default = 
>>> nil closure at the end, like this:
>>> 
>>> open static func animate(identifier: String,
>>>  duration: Double,
>>>  update: @escaping AnimationUpdate,
>>>  completion: AnimationCompletion? = nil) {
>>> You can’t use trailing closure syntax for the update argument when leaving 
>>> the completion argument out/default.
>>> 
>>> This kind of breaks one of the benefits of default arguments, which is that 
>>> you can add them to existing released functions without breaking the 
>>> calling code. This means you have to add a separate convenience function 
>>> without the extra argument, which is annoying and inelegant.
>>> 
> Why not simply add the "completion" parameter before the trailing closure? 
> That would still allow existing callers to work, without having to change the 
> language. 
> 
>>> Another annoying thing is that you can easily miss this error if you happen 
>>> to not use trailing closure syntax in your tests or other usage, because 
>>> adding the extra default argument compiles fine for code that uses normal 
>>> syntax.
>>> 
> The Swift compiler warns when a parameter written as a closure type isn't the 
> last parameter. The warning is actually disabled in the specific case above 
> because you've written it using a typealias... maybe we should warn on such 
> cases (it's worth a bug report). Regardless, in the majority of instances, 
> you'll get a warning, so it won't be silent on disabling trailing closure 
> syntax. 

Tried this out in the playground:

func foo(a: () -> (), b: (() -> ())? = nil) {
a()
b?()
}

foo(a: {
print(“Bar”)
})

and didn’t receive a warning for it, either.

> 
>>> Are there any issues/gotchas if the trailing closure syntax were to work 
>>> for the last specified argument rather than the last definedargument?
>>> 
> The main gotcha, and the reason the rule is the way it is, is that it means 
> you'd lose trailing closure syntax if the caller wanted to specify an 
> argument for the last parameter.
> 
>- 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 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhanced Existentials

[Douglas Gregor via swift-evolution]

> On Jan 4, 2017, at 9:19 PM, David Sweeris  wrote:
> 
> 
> On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> Yeah. I'm less sure about the other enhancements to existentials fitting 
>> into Swift 4, e.g., the creation of existentials for protocols with 
>> associated types. Although important, it's a big feature that will take a 
>> bunch of design and implementation time, and I'm leery of accepting 
>> something that we might not actually be able to achieve.
> 
> If it's a feature we know we want, it seems that nailing the syntax down, 
> even if we know there isn't time to actually fully implement it in 4.0, would 
> be beneficial simply to prevent it from being a source-breaking change in 4.1.

Well, there is an opportunity cost to designing something that you know won’t 
get implemented. That said, I won’t try to actually stop anyone from discussing 
such a much-needed feature; I just might not participate much.

- Doug


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

Re: [swift-evolution] Enhanced Existentials

[David Sweeris via swift-evolution]

> On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Yeah. I'm less sure about the other enhancements to existentials fitting into 
> Swift 4, e.g., the creation of existentials for protocols with associated 
> types. Although important, it's a big feature that will take a bunch of 
> design and implementation time, and I'm leery of accepting something that we 
> might not actually be able to achieve.

If it's a feature we know we want, it seems that nailing the syntax down, even 
if we know there isn't time to actually fully implement it in 4.0, would be 
beneficial simply to prevent it from being a source-breaking change in 4.1.

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

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Jan 4, 2017, at 8:40 PM, Derrick Ho  wrote:
> 
> So could we add a @trailing or @nontrailing to the block argument to toggle 
> on and off the feature?

 But... why? That's a nontrivial amount of complexity for a fairly limited use 
case. 

  - Doug

> 
> 
>> On Wed, Jan 4, 2017 at 8:35 PM Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>>> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution 
>>>  wrote:
>>> 
>>> Check out this thread–it’s very similar to what you proposed, but it didn’t 
>>> go anywhere. FWIW +1 to this as well as the ability to use multiple 
>>> trailing closures like so:
>>> 
>>> animate(identifier: “”, duration: 0, update: {
>>> // update
>>> }, completion: {
>>> // completion
>>> }
>>> 
>>> Saagar Jha
>>> 
>>> 
>>> 
 On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution 
  wrote:
 
 When you have a function with a closure and then another optional default 
 = nil closure at the end, like this:
 
 open static func animate(identifier: String,
  duration: Double,
  update: @escaping AnimationUpdate,
  completion: AnimationCompletion? = nil) {
 You can’t use trailing closure syntax for the update argument when leaving 
 the completion argument out/default.
 
 This kind of breaks one of the benefits of default arguments, which is 
 that you can add them to existing released functions without breaking the 
 calling code. This means you have to add a separate convenience function 
 without the extra argument, which is annoying and inelegant.
 
>> 
>> Why not simply add the "completion" parameter before the trailing closure? 
>> That would still allow existing callers to work, without having to change 
>> the language. 
>> 
 Another annoying thing is that you can easily miss this error if you 
 happen to not use trailing closure syntax in your tests or other usage, 
 because adding the extra default argument compiles fine for code that uses 
 normal syntax.
 
>> 
>> The Swift compiler warns when a parameter written as a closure type isn't 
>> the last parameter. The warning is actually disabled in the specific case 
>> above because you've written it using a typealias... maybe we should warn on 
>> such cases (it's worth a bug report). Regardless, in the majority of 
>> instances, you'll get a warning, so it won't be silent on disabling trailing 
>> closure syntax. 
>> 
 Are there any issues/gotchas if the trailing closure syntax were to work 
 for the last specified argument rather than the last defined argument?
 
>> 
>> The main gotcha, and the reason the rule is the way it is, is that it means 
>> you'd lose trailing closure syntax if the caller wanted to specify an 
>> argument for the last parameter.
>> 
>>- 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
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

[Timothy Wood via swift-evolution]

> On Jan 4, 2017, at 4:50 PM, Douglas Gregor via swift-evolution 
>  wrote:



> A Swift 3-to-4 migrator is the hardest part of the story. Ideally, the 
> migrator to only add @objc in places where it is needed, so that we see some 
> of the expected benefits of code-size reduction. However, there are two 
> problems with doing so:
> 
> Some of the uses that imply the need to add @objc come from Objective-C code, 
> so a Swift 3-to-4 migrator would also need to compile the Objective-C code 
> (possibly with a modified version of the Objective-C compiler) and match up 
> the "deprecated" warnings mentioned in the Swift 3 compatibility mode bullet 
> with Swift declarations.
> 
> The migrator can't reason about dynamically-constructed selectors or the 
> behavior of other tools that might directly use the Objective-C runtime, so 
> failing to add a @objc will lead to migrated programs that compile but fail 
> to execute correctly.
> 
This seems fairly worrisome, but I’m sure how much so. I personally would 
probably prefer a guaranteed non-breaking migrator (since Swift 4 isn’t 
supposed to break stuff…) that adds the @objc where it was previously inferred. 
Sure, this won’t make existing code smaller/faster, but more importantly it 
won’t break it. The developer than then opt to remove the unneeded annotations 
over time (allowing for incremental testing and later bisection if a problem 
crops up).

> Proposal add-on: @objc annotations on class definitions and extensions
> 
> If the annotation burden of @objc introduced by this proposal is too high, we 
> could make @objc on a class definition or extension thereof imply @objc on 
> those members that can be exposed to Objective-C. For example:
> 
> @objc extension MyClass {
>   // implicitly @objc
>   func f() { }
> 
>   // Cannot be exposed to Objective-C because tuples aren't representable in 
> Objective-C
>   func g() -> (Int, Int) { return (1, 2) }
> }
This seems like it goes counter to cleaning up the confusion by re-introducting 
silent non-exposure due to use of Swift-only types. It also seems odd that 
@objc would cascade to members when `public` and other access levels don’t 
(though it could do the same inference based on the access level of the types 
involved.

Overall this looks pretty appealing!

-tim

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

Re: [swift-evolution] Enhanced Existentials

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Jan 3, 2017, at 10:08 PM, Rod Brown via swift-evolution 
>  wrote:
> 
>> On 3 Jan 2017, at 11:33 pm, David Hart via swift-evolution 
>>  wrote:
>> 
>> Hello Mailing-list,
>> 
>> I remember we discussed enhanced existentials heavily during the Swift 3 
>> timeframe but postponed it. I was wondering if we need to bring back for 
>> discussion during Phase 1 or Phase 2? For reference, here is the proposal 
>> which Austin Zhend wrote which represented the culmination of the 
>> discussions:
>> 
>> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md#nested-typealias-existential
>> 
>> Regards,
>> David.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> I'm a big proponent of this - it's a limitation that is actually more capable 
> in Obj-C than it is in Swift, and considering Swift's increased focus on 
> Protocols, this seems rather baffling!

Yes. My personal feeling on this is that the ability to create an existential 
type with both superclass and protocol constraints is something we should 
address in Swift 4, because Objective-C APIs that use the feature (e.g., have a 
type like UIController) get weakened when they come into 
Swift. Fixing it is a source-breaking change, and I want to get it out of the 
way in Swift 4. 


> 
> Would love to see this come forward into discussion.

Yeah. I'm less sure about the other enhancements to existentials fitting into 
Swift 4, e.g., the creation of existentials for protocols with associated 
types. Although important, it's a big feature that will take a bunch of design 
and implementation time, and I'm leery of accepting something that we might not 
actually be able to achieve. 

  - Doug

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

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

[thislooksfun via swift-evolution]

I think the way it is now works just fine. The only use-case I could see for 
this would be for having multiple closures, but in that case I think defining 
them before the function call is clearer anyway.

-thislooksfun (tlf)

> On Jan 4, 2017, at 10:40 PM, Derrick Ho via swift-evolution 
>  wrote:
> 
> So could we add a @trailing or @nontrailing to the block argument to toggle 
> on and off the feature?
> 
> 
> On Wed, Jan 4, 2017 at 8:35 PM Douglas Gregor via swift-evolution 
> > wrote:
> 
> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution 
> > wrote:
> 
>> Check out this thread 
>> –it’s
>>  very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to 
>> this as well as the ability to use multiple trailing closures like so:
>> 
>> animate(identifier: “”, duration: 0, update: {
>>  // update
>> }, completion: {
>>  // completion
>> }
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution 
>>> > wrote:
>>> 
>>> When you have a function with a closure and then another optional default = 
>>> nil closure at the end, like this:
>>> 
>>> open static func animate(identifier: String,
>>>  duration: Double,
>>>  update: @escaping AnimationUpdate,
>>>  completion: AnimationCompletion? = nil) {
>>> You can’t use trailing closure syntax for the update argument when leaving 
>>> the completion argument out/default.
>>> 
>>> This kind of breaks one of the benefits of default arguments, which is that 
>>> you can add them to existing released functions without breaking the 
>>> calling code. This means you have to add a separate convenience function 
>>> without the extra argument, which is annoying and inelegant.
>>> 
> 
> Why not simply add the "completion" parameter before the trailing closure? 
> That would still allow existing callers to work, without having to change the 
> language.
> 
>>> Another annoying thing is that you can easily miss this error if you happen 
>>> to not use trailing closure syntax in your tests or other usage, because 
>>> adding the extra default argument compiles fine for code that uses normal 
>>> syntax.
>>> 
> 
> The Swift compiler warns when a parameter written as a closure type isn't the 
> last parameter. The warning is actually disabled in the specific case above 
> because you've written it using a typealias... maybe we should warn on such 
> cases (it's worth a bug report). Regardless, in the majority of instances, 
> you'll get a warning, so it won't be silent on disabling trailing closure 
> syntax.
> 
>>> Are there any issues/gotchas if the trailing closure syntax were to work 
>>> for the last specified argument rather than the last defined argument?
>>> 
> 
> The main gotcha, and the reason the rule is the way it is, is that it means 
> you'd lose trailing closure syntax if the caller wanted to specify an 
> argument for the last parameter.
> 
>- 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 
>> 
> ___
> 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



signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Derrick Ho via swift-evolution]

So could we add a @trailing or @nontrailing to the block argument to toggle
on and off the feature?


On Wed, Jan 4, 2017 at 8:35 PM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Check out this thread
> –it’s
> very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to
> this as well as the ability to use multiple trailing closures like so:
>
> animate(identifier: “”, duration: 0, update: {
> // update
> }, completion: {
> // completion
> }
>
> Saagar Jha
>
>
>
> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> When you have a function with a closure and then another optional default =
> nil closure at the end, like this:
>
> open static func animate(identifier: String,
>  duration: Double,
>  update: @escaping AnimationUpdate,
>  completion: AnimationCompletion? = nil) {
>
> You can’t use trailing closure syntax for the update argument when
> leaving the completion argument out/default.
>
> This kind of breaks one of the benefits of default arguments, which is
> that you can add them to existing released functions without breaking the
> calling code. This means you have to add a separate convenience function
> without the extra argument, which is annoying and inelegant.
>
> Why not simply add the "completion" parameter before the trailing closure?
> That would still allow existing callers to work, without having to change
> the language.
>
> Another annoying thing is that you can easily miss this error if you
> happen to not use trailing closure syntax in your tests or other usage,
> because adding the extra default argument compiles fine for code that uses
> normal syntax.
>
> The Swift compiler warns when a parameter written as a closure type isn't
> the last parameter. The warning is actually disabled in the specific case
> above because you've written it using a typealias... maybe we should warn
> on such cases (it's worth a bug report). Regardless, in the majority of
> instances, you'll get a warning, so it won't be silent on disabling
> trailing closure syntax.
>
> Are there any issues/gotchas if the trailing closure syntax were to work
> for the last *specified* argument rather than the last *defined* argument?
>
> The main gotcha, and the reason the rule is the way it is, is that it
> means you'd lose trailing closure syntax if the caller wanted to specify an
> argument for the last parameter.
>
>- 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
>
> ___
> 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] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Douglas Gregor via swift-evolution]

> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution 
>  wrote:
> 
> Check out this thread–it’s very similar to what you proposed, but it didn’t 
> go anywhere. FWIW +1 to this as well as the ability to use multiple trailing 
> closures like so:
> 
> animate(identifier: “”, duration: 0, update: {
>   // update
> }, completion: {
>   // completion
> }
> 
> Saagar Jha
> 
> 
> 
>> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution 
>>  wrote:
>> 
>> When you have a function with a closure and then another optional default = 
>> nil closure at the end, like this:
>> 
>> open static func animate(identifier: String,
>>  duration: Double,
>>  update: @escaping AnimationUpdate,
>>  completion: AnimationCompletion? = nil) {
>> You can’t use trailing closure syntax for the update argument when leaving 
>> the completion argument out/default.
>> 
>> This kind of breaks one of the benefits of default arguments, which is that 
>> you can add them to existing released functions without breaking the calling 
>> code. This means you have to add a separate convenience function without the 
>> extra argument, which is annoying and inelegant.
>> 
Why not simply add the "completion" parameter before the trailing closure? That 
would still allow existing callers to work, without having to change the 
language. 

>> Another annoying thing is that you can easily miss this error if you happen 
>> to not use trailing closure syntax in your tests or other usage, because 
>> adding the extra default argument compiles fine for code that uses normal 
>> syntax.
>> 
The Swift compiler warns when a parameter written as a closure type isn't the 
last parameter. The warning is actually disabled in the specific case above 
because you've written it using a typealias... maybe we should warn on such 
cases (it's worth a bug report). Regardless, in the majority of instances, 
you'll get a warning, so it won't be silent on disabling trailing closure 
syntax. 

>> Are there any issues/gotchas if the trailing closure syntax were to work for 
>> the last specified argument rather than the last defined argument?
>> 
The main gotcha, and the reason the rule is the way it is, is that it means 
you'd lose trailing closure syntax if the caller wanted to specify an argument 
for the last parameter.

   - 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Xiaodi Wu via swift-evolution]

The only difference between your proposed spelling and not using trailing
closures at all is the placement of the closing parenthesis, which is not
at all a clear enough win sufficient to justify having two spellings for
the same thing.

I'm of the same opinion that was expressed by Erica Sadun and Jordan Rose
last summer, that where a function takes more than one closure
argument--defaulted to nil or no--it's arguable that we ought to prohibit
trailing closures altogether for the sake of clarity.
On Wed, Jan 4, 2017 at 21:48 Saagar Jha via swift-evolution <
swift-evolution@swift.org> wrote:

> Check out this thread
> –it’s
> very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to
> this as well as the ability to use multiple trailing closures like so:
>
> animate(identifier: “”, duration: 0, update: {
> // update
> }, completion: {
> // completion
> }
>
> Saagar Jha
>
>
>
> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> When you have a function with a closure and then another optional default =
> nil closure at the end, like this:
>
> open static func animate(identifier: String,
>  duration: Double,
>  update: @escaping AnimationUpdate,
>  completion: AnimationCompletion? = nil) {
>
> You can’t use trailing closure syntax for the update argument when
> leaving the completion argument out/default.
>
> This kind of breaks one of the benefits of default arguments, which is
> that you can add them to existing released functions without breaking the
> calling code. This means you have to add a separate convenience function
> without the extra argument, which is annoying and inelegant. Another
> annoying thing is that you can easily miss this error if you happen to not
> use trailing closure syntax in your tests or other usage, because adding
> the extra default argument compiles fine for code that uses normal syntax.
>
> Are there any issues/gotchas if the trailing closure syntax were to work
> for the last *specified* argument rather than the last *defined* argument?
> ​
> ___
> 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] [Proposal draft] Limiting @objc inference

[Shawn Erickson via swift-evolution]

+1. Yeah well thought out and explained. All for consistency and favor
being explicit.

On Wed, Jan 4, 2017 at 7:01 PM Micah Hainline via swift-evolution <
swift-evolution@swift.org> wrote:

+1. Well thought out, it's bothered me too.





> On Jan 4, 2017, at 7:34 PM, Rick Mann via swift-evolution <
swift-evolution@swift.org> wrote:


>


> +1


>


>> On Jan 4, 2017, at 16:50 , Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:


>>


>> Hi all,


>>


>> Here’s a draft proposal to limit inference of @objc to only those places
where we need it for consistency of the semantic model. It’s in the realm
of things that isn’t *needed* for ABI stability, but if we’re going to make
the source-breaking change here we’d much rather do it in the Swift 4
time-frame than later. Proposal is at:


>>


>>
https://github.com/DougGregor/swift-evolution/blob/objc-inference/proposals/-objc-inference.md


>>


>> Introduction


>>


>> One can explicitly write @objc on any Swift declaration that can be
expressed in Objective-C. As a convenience, Swift also infers @objc in a
number of places to improve interoperability with Objective-C and eliminate
boilerplate. This proposal scales back the inference of @objc to only those
cases where the declaration must be available to Objective-C to maintain
semantic coherence of the model, e.g., when overriding an @objc method or
implementing a requirement of an @objcprotocol. Other cases currently
supported (e.g., a method declared in a subclass of NSObject) would no
longer infer @objc, but one could continue to write it explicitly to
produce Objective-C entry points.


>>


>> Swift-evolution thread: here


>>


>> Motivation


>>


>> There are several observations motivating this proposal. The first is
that Swift's rules for inference of @objc are fairly baroque, and it is
often unclear to users when @objc will be inferred. This proposal seeks to
make the inference rules more straightforward. The second observation is
that it is fairly easy to write Swift classes that inadvertently cause
Objective-C selector collisions due to overloading, e.g.,


>>


>> class MyNumber : NSObject


>> {


>>


>> init(_ int: Int


>> ) { }


>>


>> init(_ double: Double) { } // error: initializer 'init' with Objective-C
selector 'init:'


>>  // conflicts with previous declaration with the same Objective-C
selector


>> }


>> The example above also illustrates the third observation, which is that
code following the Swift API Design Guidelines will use Swift names that
often translate into very poor Objective-C names that violate the
Objective-C Coding Guidelines for Cocoa. Specifically, the Objective-C
selectors for the initializers above should include a noun describing the
first argument, e.g., initWithInteger: and initWithDouble:, which requires
explicit @objc annotations anyway:


>>


>> class MyNumber : NSObject


>> {


>>


>> @objc(initWithInteger:) init(_ int: Int


>> ) { }


>>


>> @objc(initWithDouble:) init(_ double: Double


>> ) { }


>> }


>>


>> The final observation is that there is a cost for each Objective-C entry
point, because the Swift compiler must create a "thunk" method that maps
from the Objective-C calling convention to the Swift calling convention and
is recorded within Objective-C metadata. This increases the size of the
binary (preliminary tests on some Cocoa[Touch] apps found that 6-8% of
binary size was in these thunks alone, some of which are undoubtedly
unused), and can have some impact on load time (the dynamic linker has to
sort through the Objective-C metadata for these thunks).


>>


>> Proposed solution


>>


>> The proposed solution is to limit the inference of @objc to only those
places where it is required for semantic consistency of the programming
model.


>>


>> Constructs that (still) infer @objc


>>


>> Specifically, @objc will continue to be inferred for a declaration when:


>>


>>• The declaration is an override of an @objc declaration, e.g.,


>>


>> class Super


>> {


>>


>> @objc func foo


>> () { }


>> }


>>


>>


>> class Sub : Super


>> {


>>


>> /* inferred @objc */


>>


>>


>> override func foo


>> () { }


>> }


>>


>> This inference is required so that Objective-C callers to the method
Super.foo() will appropriately invoke the overriding method Sub.foo().


>>


>>• The declaration satisfies a requirement of an @objc protocol, e.g.,


>>


>> @objc protocol MyDelegate


>> {


>>


>> func bar


>> ()


>> }


>>


>>


>> class MyClass : MyDelegate


>> {


>>


>> /* inferred @objc */


>>


>>


>> func bar


>> () { }


>> }


>>


>> This inference is required because anyone calling MyDelegate.bar(),
whether from Objective-C or Swift, will do so via an Objective-C message
send, so conforming to the protocol requires an Objective-C entry point.


>>


>>• The declaration has the @IBAction or @IBOutlet attribute. This
inference is required because the interaction with 

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

[Saagar Jha via swift-evolution]

Check out this thread 
–it’s
 very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to this 
as well as the ability to use multiple trailing closures like so:

animate(identifier: “”, duration: 0, update: {
// update
}, completion: {
// completion
}

Saagar Jha



> On Jan 4, 2017, at 6:25 PM, Jay Abbott via swift-evolution 
>  wrote:
> 
> When you have a function with a closure and then another optional default = 
> nil closure at the end, like this:
> 
> open static func animate(identifier: String,
>  duration: Double,
>  update: @escaping AnimationUpdate,
>  completion: AnimationCompletion? = nil) {
> You can’t use trailing closure syntax for the update argument when leaving 
> the completion argument out/default.
> 
> This kind of breaks one of the benefits of default arguments, which is that 
> you can add them to existing released functions without breaking the calling 
> code. This means you have to add a separate convenience function without the 
> extra argument, which is annoying and inelegant. Another annoying thing is 
> that you can easily miss this error if you happen to not use trailing closure 
> syntax in your tests or other usage, because adding the extra default 
> argument compiles fine for code that uses normal syntax.
> 
> Are there any issues/gotchas if the trailing closure syntax were to work for 
> the last specified argument rather than the last defined argument?
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

[Micah Hainline via swift-evolution]

+1. Well thought out, it's bothered me too.

> On Jan 4, 2017, at 7:34 PM, Rick Mann via swift-evolution 
>  wrote:
> 
> +1
> 
>> On Jan 4, 2017, at 16:50 , Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> Here’s a draft proposal to limit inference of @objc to only those places 
>> where we need it for consistency of the semantic model. It’s in the realm of 
>> things that isn’t *needed* for ABI stability, but if we’re going to make the 
>> source-breaking change here we’d much rather do it in the Swift 4 time-frame 
>> than later. Proposal is at:
>> 
>>
>> https://github.com/DougGregor/swift-evolution/blob/objc-inference/proposals/-objc-inference.md
>> 
>> Introduction
>> 
>> One can explicitly write @objc on any Swift declaration that can be 
>> expressed in Objective-C. As a convenience, Swift also infers @objc in a 
>> number of places to improve interoperability with Objective-C and eliminate 
>> boilerplate. This proposal scales back the inference of @objc to only those 
>> cases where the declaration must be available to Objective-C to maintain 
>> semantic coherence of the model, e.g., when overriding an @objc method or 
>> implementing a requirement of an @objcprotocol. Other cases currently 
>> supported (e.g., a method declared in a subclass of NSObject) would no 
>> longer infer @objc, but one could continue to write it explicitly to produce 
>> Objective-C entry points.
>> 
>> Swift-evolution thread: here
>> 
>> Motivation
>> 
>> There are several observations motivating this proposal. The first is that 
>> Swift's rules for inference of @objc are fairly baroque, and it is often 
>> unclear to users when @objc will be inferred. This proposal seeks to make 
>> the inference rules more straightforward. The second observation is that it 
>> is fairly easy to write Swift classes that inadvertently cause Objective-C 
>> selector collisions due to overloading, e.g.,
>> 
>> class MyNumber : NSObject 
>> {
>> 
>> init(_ int: Int
>> ) { }
>> 
>> init(_ double: Double) { } // error: initializer 'init' with Objective-C 
>> selector 'init:' 
>>  // conflicts with previous declaration with the same Objective-C 
>> selector
>> }
>> The example above also illustrates the third observation, which is that code 
>> following the Swift API Design Guidelines will use Swift names that often 
>> translate into very poor Objective-C names that violate the Objective-C 
>> Coding Guidelines for Cocoa. Specifically, the Objective-C selectors for the 
>> initializers above should include a noun describing the first argument, 
>> e.g., initWithInteger: and initWithDouble:, which requires explicit @objc 
>> annotations anyway:
>> 
>> class MyNumber : NSObject 
>> {
>> 
>> @objc(initWithInteger:) init(_ int: Int
>> ) { }
>> 
>> @objc(initWithDouble:) init(_ double: Double
>> ) { }
>> }
>> 
>> The final observation is that there is a cost for each Objective-C entry 
>> point, because the Swift compiler must create a "thunk" method that maps 
>> from the Objective-C calling convention to the Swift calling convention and 
>> is recorded within Objective-C metadata. This increases the size of the 
>> binary (preliminary tests on some Cocoa[Touch] apps found that 6-8% of 
>> binary size was in these thunks alone, some of which are undoubtedly 
>> unused), and can have some impact on load time (the dynamic linker has to 
>> sort through the Objective-C metadata for these thunks).
>> 
>> Proposed solution
>> 
>> The proposed solution is to limit the inference of @objc to only those 
>> places where it is required for semantic consistency of the programming 
>> model. 
>> 
>> Constructs that (still) infer @objc
>> 
>> Specifically, @objc will continue to be inferred for a declaration when:
>> 
>>• The declaration is an override of an @objc declaration, e.g.,
>> 
>> class Super
>> {
>> 
>> @objc func foo
>> () { }
>> }
>> 
>> 
>> class Sub : Super 
>> {
>> 
>> /* inferred @objc */
>> 
>> 
>> override func foo
>> () { }
>> }
>> 
>> This inference is required so that Objective-C callers to the method 
>> Super.foo() will appropriately invoke the overriding method Sub.foo().
>> 
>>• The declaration satisfies a requirement of an @objc protocol, e.g.,
>> 
>> @objc protocol MyDelegate
>> {
>> 
>> func bar
>> ()
>> }
>> 
>> 
>> class MyClass : MyDelegate 
>> {
>> 
>> /* inferred @objc */
>> 
>> 
>> func bar
>> () { }
>> }
>> 
>> This inference is required because anyone calling MyDelegate.bar(), whether 
>> from Objective-C or Swift, will do so via an Objective-C message send, so 
>> conforming to the protocol requires an Objective-C entry point.
>> 
>>• The declaration has the @IBAction or @IBOutlet attribute. This 
>> inference is required because the interaction with Interface Builder occurs 
>> entirely through the Objective-C runtime, and therefore depends on the 
>> existence of an Objective-C entrypoint.
>> 
>>• The declaration 

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

[Rick Mann via swift-evolution]

+1

> On Jan 4, 2017, at 16:50 , Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Here’s a draft proposal to limit inference of @objc to only those places 
> where we need it for consistency of the semantic model. It’s in the realm of 
> things that isn’t *needed* for ABI stability, but if we’re going to make the 
> source-breaking change here we’d much rather do it in the Swift 4 time-frame 
> than later. Proposal is at:
> 
>   
> https://github.com/DougGregor/swift-evolution/blob/objc-inference/proposals/-objc-inference.md
> 
> Introduction
> 
> One can explicitly write @objc on any Swift declaration that can be expressed 
> in Objective-C. As a convenience, Swift also infers @objc in a number of 
> places to improve interoperability with Objective-C and eliminate 
> boilerplate. This proposal scales back the inference of @objc to only those 
> cases where the declaration must be available to Objective-C to maintain 
> semantic coherence of the model, e.g., when overriding an @objc method or 
> implementing a requirement of an @objcprotocol. Other cases currently 
> supported (e.g., a method declared in a subclass of NSObject) would no longer 
> infer @objc, but one could continue to write it explicitly to produce 
> Objective-C entry points.
> 
> Swift-evolution thread: here
> 
> Motivation
> 
> There are several observations motivating this proposal. The first is that 
> Swift's rules for inference of @objc are fairly baroque, and it is often 
> unclear to users when @objc will be inferred. This proposal seeks to make the 
> inference rules more straightforward. The second observation is that it is 
> fairly easy to write Swift classes that inadvertently cause Objective-C 
> selector collisions due to overloading, e.g.,
> 
> class MyNumber : NSObject 
> {
>   
> init(_ int: Int
> ) { }
>   
> init(_ double: Double) { } // error: initializer 'init' with Objective-C 
> selector 'init:' 
>   // conflicts with previous declaration with the same Objective-C 
> selector
> }
> The example above also illustrates the third observation, which is that code 
> following the Swift API Design Guidelines will use Swift names that often 
> translate into very poor Objective-C names that violate the Objective-C 
> Coding Guidelines for Cocoa. Specifically, the Objective-C selectors for the 
> initializers above should include a noun describing the first argument, e.g., 
> initWithInteger: and initWithDouble:, which requires explicit @objc 
> annotations anyway:
> 
> class MyNumber : NSObject 
> {
>   
> @objc(initWithInteger:) init(_ int: Int
> ) { }
>   
> @objc(initWithDouble:) init(_ double: Double
> ) { }
> }
> 
> The final observation is that there is a cost for each Objective-C entry 
> point, because the Swift compiler must create a "thunk" method that maps from 
> the Objective-C calling convention to the Swift calling convention and is 
> recorded within Objective-C metadata. This increases the size of the binary 
> (preliminary tests on some Cocoa[Touch] apps found that 6-8% of binary size 
> was in these thunks alone, some of which are undoubtedly unused), and can 
> have some impact on load time (the dynamic linker has to sort through the 
> Objective-C metadata for these thunks).
> 
> Proposed solution
> 
> The proposed solution is to limit the inference of @objc to only those places 
> where it is required for semantic consistency of the programming model. 
> 
> Constructs that (still) infer @objc
> 
> Specifically, @objc will continue to be inferred for a declaration when:
> 
>   • The declaration is an override of an @objc declaration, e.g.,
> 
> class Super
>  {
>   
> @objc func foo
> () { }
> }
> 
> 
> class Sub : Super 
> {
>   
> /* inferred @objc */
> 
>   
> override func foo
> () { }
> }
> 
> This inference is required so that Objective-C callers to the method 
> Super.foo() will appropriately invoke the overriding method Sub.foo().
> 
>   • The declaration satisfies a requirement of an @objc protocol, e.g.,
> 
> @objc protocol MyDelegate
>  {
>   
> func bar
> ()
> }
> 
> 
> class MyClass : MyDelegate 
> {
>   
> /* inferred @objc */
> 
>   
> func bar
> () { }
> }
> 
> This inference is required because anyone calling MyDelegate.bar(), whether 
> from Objective-C or Swift, will do so via an Objective-C message send, so 
> conforming to the protocol requires an Objective-C entry point.
> 
>   • The declaration has the @IBAction or @IBOutlet attribute. This 
> inference is required because the interaction with Interface Builder occurs 
> entirely through the Objective-C runtime, and therefore depends on the 
> existence of an Objective-C entrypoint.
> 
>   • The declaration has the @NSManaged attribute. This inference is 
> required because the interaction with CoreData occurs entirely through the 
> Objective-C runtime, and therefore depends on the existence of an Objective-C 
> entrypoint.
> 
> The list above describes 

[swift-evolution] [Proposal draft] Limiting @objc inference

[Douglas Gregor via swift-evolution]

Hi all,

Here’s a draft proposal to limit inference of @objc to only those places where 
we need it for consistency of the semantic model. It’s in the realm of things 
that isn’t *needed* for ABI stability, but if we’re going to make the 
source-breaking change here we’d much rather do it in the Swift 4 time-frame 
than later. Proposal is at:


https://github.com/DougGregor/swift-evolution/blob/objc-inference/proposals/-objc-inference.md
 


Introduction

One can explicitly write @objc on any Swift declaration that can be expressed 
in Objective-C. As a convenience, Swift also infers @objc in a number of places 
to improve interoperability with Objective-C and eliminate boilerplate. This 
proposal scales back the inference of @objc to only those cases where the 
declaration must be available to Objective-C to maintain semantic coherence of 
the model, e.g., when overriding an @objc method or implementing a requirement 
of an @objcprotocol. Other cases currently supported (e.g., a method declared 
in a subclass of NSObject) would no longer infer @objc, but one could continue 
to write it explicitly to produce Objective-C entry points.

Swift-evolution thread: here 

 
Motivation

There are several observations motivating this proposal. The first is that 
Swift's rules for inference of @objc are fairly baroque, and it is often 
unclear to users when @objc will be inferred. This proposal seeks to make the 
inference rules more straightforward. The second observation is that it is 
fairly easy to write Swift classes that inadvertently cause Objective-C 
selector collisions due to overloading, e.g.,

class MyNumber : NSObject {
  init(_ int: Int) { }
  init(_ double: Double) { } // error: initializer 'init' with Objective-C 
selector 'init:' 
  // conflicts with previous declaration with the same Objective-C selector
}
The example above also illustrates the third observation, which is that code 
following the Swift API Design Guidelines 
 will use Swift names 
that often translate into very poor Objective-C names that violate the 
Objective-C Coding Guidelines for Cocoa 
.
 Specifically, the Objective-C selectors for the initializers above should 
include a noun describing the first argument, e.g., initWithInteger: and 
initWithDouble:, which requires explicit @objc annotations anyway:

class MyNumber : NSObject {
  @objc(initWithInteger:) init(_ int: Int) { }
  @objc(initWithDouble:) init(_ double: Double) { }
}
The final observation is that there is a cost for each Objective-C entry point, 
because the Swift compiler must create a "thunk" method that maps from the 
Objective-C calling convention to the Swift calling convention and is recorded 
within Objective-C metadata. This increases the size of the binary (preliminary 
tests on some Cocoa[Touch] apps found that 6-8% of binary size was in these 
thunks alone, some of which are undoubtedly unused), and can have some impact 
on load time (the dynamic linker has to sort through the Objective-C metadata 
for these thunks).

 
Proposed
 solution

The proposed solution is to limit the inference of @objc to only those places 
where it is required for semantic consistency of the programming model. 

 
Constructs
 that (still) infer @objc

Specifically, @objc will continue to be inferred for a declaration when:

The declaration is an override of an @objc declaration, e.g.,

class Super {
  @objc func foo() { }
}

class Sub : Super {
  /* inferred @objc */
  override func foo() { }
}
This inference is required so that Objective-C callers to the method 
Super.foo() will appropriately invoke the overriding method Sub.foo().

The declaration satisfies a requirement of an @objc protocol, e.g.,

@objc protocol MyDelegate {
  func bar()
}

class MyClass : MyDelegate {
  /* inferred @objc */
  func bar() { }
}
This inference is required because anyone calling MyDelegate.bar(), whether 
from Objective-C or Swift, will do so via an Objective-C message send, so 
conforming to the protocol requires an Objective-C entry point.

The declaration has the @IBAction or @IBOutlet attribute. This inference is 
required because the interaction with Interface Builder occurs entirely through 
the Objective-C runtime, and therefore depends on the existence of an 
Objective-C entrypoint.

The declaration has the @NSManaged attribute. This inference is required 

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

[Derrick Ho via swift-evolution]

The underline can be omitted. To remain more consistent.

enum City: String {
case NewYork = "New York"
}

typedef NSString * City;
static City const CityNewYork = @"New York";



On Wed, Jan 4, 2017 at 2:22 PM Rod Brown  wrote:

> I'm not part of the core team, of course, but I like this change in
> principle.
>
> My one concern in this case would be choosing a naming convention for the
> back port that makes sense both ways. The naming convention you propose (
> EnumName_EnumCase) seems inconsistent with the current import of strings
> from Obj-C to Swift. Could we find a way to unify them?
>
> On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm trying to revive an old thread. I'd like to hear from the community.
>
> Can we make a swift enum string interoperable with Objective-C?
>
> Currently NS_STRING_ENUM ports from objective-c to swift but not the other
> way around.
>
> I feel that if you can go one direction you should be able to go back.
>
> @objc
> enum City: String {
> case NewYork = "New York"
> }
>
> Make this available as a global string in objective -c ?
> On Wed, Nov 23, 2016 at 5:55 AM Derrick Ho  wrote:
>
> I think enum strings should gain better interoperability with swift.
> Something like this: enum City: String { case NewYork = "New York" }
> This can be ported over to Objective-c like this: typedef NSString * City;
> static City const City_NewYork = @"New York";
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

[Rod Brown via swift-evolution]

I'm not part of the core team, of course, but I like this change in principle.

My one concern in this case would be choosing a naming convention for the back 
port that makes sense both ways. The naming convention you propose ( 
EnumName_EnumCase) seems inconsistent with the current import of strings from 
Obj-C to Swift. Could we find a way to unify them?

> On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution 
>  wrote:
> 
> I'm trying to revive an old thread. I'd like to hear from the community.
> 
> Can we make a swift enum string interoperable with Objective-C?
> 
> Currently NS_STRING_ENUM ports from objective-c to swift but not the other 
> way around.
> 
> I feel that if you can go one direction you should be able to go back.
> 
> @objc
> enum City: String {
> case NewYork = "New York"
> } 
> 
> Make this available as a global string in objective -c ?
>> On Wed, Nov 23, 2016 at 5:55 AM Derrick Ho  wrote:
>> I think enum strings should gain better interoperability with swift. 
>> Something like this:
>> 
>> enum City: String {
>>case NewYork = "New York"
>> } 
>> 
>> This can be ported over to Objective-c like this:
>> 
>> typedef NSString * City;
>> static City const City_NewYork = @"New York";
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

[Tony Parker via swift-evolution]

Hi Andy, everyone,

The short answer is that fixing struct Data requires a source breaking change 
(the enum for the deallocator has to change to use the raw buffer type), so I 
do not want to introduce it until Swift 4 provides a better transition path for 
this kind of change.

- Tony

> On Jan 4, 2017, at 2:12 PM, Andrew Trick  wrote:
> 
> 
>> On Dec 27, 2016, at 12:16 AM, Karl via swift-evolution 
>> > wrote:
>> 
>> Looking for feedback before submitting a PR: 
>> https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/-corelibs-unsafebytes.md
>>  
>> 
>> 
>> —
>> 
>> Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer
>> 
>> Proposal: SE- 
>> 
>> Authors: Karl Wagner 
>> Review Manager: TBD
>> Status: Awaiting review
>> 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
>> 
>> The standard library's Array and ContiguousArray types expose the method 
>> withUnsafeBytes, which allows you to view their contents as a contiguous 
>> collection of bytes. The core libraries Foundation and Dispatch contain 
>> types which wrap some allocated data, but their withUnsafeBytes method only 
>> allows you to view the contents as a pointer to a contiguous memory location 
>> of a given type.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal 
>> 
>>  
>> Motivation
>> 
>> The current situation makes it awkward to write generic code. Personally, I 
>> use the following extension in my projects to sort the naming confusion out:
>> 
>> protocol ContiguousByteCollection {
>>   func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> T) 
>> rethrows -> T
>> }
>> 
>> // stdlib types are fine.
>> extension Array: ContiguousByteCollection {}
>> extension ArraySlice: ContiguousByteCollection {}
>> extension ContiguousArray: ContiguousByteCollection {}
>> 
>> // corelibs types give us a pointer, should be: { pointer, count }
>> #if canImport(Dispatch)
>>   import Dispatch
>> 
>>   extension DispatchData : ContiguousByteCollection {
>> func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> T) 
>> rethrows -> T {
>>   return try withUnsafeBytes { try body(UnsafeRawBufferPointer(start: 
>> $0, count: count)) }
>> }
>>   }
>> #endif
>> 
>> #if canImport(Foundation)
>>   import Foundation
>> 
>>   extension Data : ContiguousByteCollection {
>> func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> T) 
>> rethrows -> T {
>>   return try withUnsafeBytes { try body(UnsafeRawBufferPointer(start: 
>> $0, count: count)) }
>> }
>>   }
>> #endif
>> Conceptually, the corelibs types are untyped regions of memory, and it would 
>> make sense for them to adopt the UnsafeRawBufferPointer model.
>> 
>>  
>> Proposed
>>  solution
>> 
>> The proposed solution would be to deprecate the current methods on 
>> (Dispatch)Data (with 2 generic parameters), and replace them with methods 
>> with identical signatures to Array (with 1 generic parameter).
>> 
>> To be deprecated:
>> 
>> public func withUnsafeBytes(_ body: 
>> (UnsafePointer) throws -> ResultType) rethrows -> ResultType
>> Replaced with:
>> 
>> public func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> R) 
>> rethrows -> R
>>  
>> 
> Thanks Karl. Good observation.
> 
> I proposed exactly this API along with a few other UnsafeRawBufferPointer 
> compatibility API’s during SE-0183. Look for Tony to follow up on this.
> 
> -Andy

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Proposal] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

[Andrew Trick via swift-evolution]

> On Dec 27, 2016, at 12:16 AM, Karl via swift-evolution 
>  wrote:
> 
> Looking for feedback before submitting a PR: 
> https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/-corelibs-unsafebytes.md
>  
> 
> 
> —
> 
> Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer
> 
> Proposal: SE- 
> 
> Authors: Karl Wagner 
> Review Manager: TBD
> Status: Awaiting review
> 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
> 
> The standard library's Array and ContiguousArray types expose the method 
> withUnsafeBytes, which allows you to view their contents as a contiguous 
> collection of bytes. The core libraries Foundation and Dispatch contain types 
> which wrap some allocated data, but their withUnsafeBytes method only allows 
> you to view the contents as a pointer to a contiguous memory location of a 
> given type.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> The current situation makes it awkward to write generic code. Personally, I 
> use the following extension in my projects to sort the naming confusion out:
> 
> protocol ContiguousByteCollection {
>   func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> T) 
> rethrows -> T
> }
> 
> // stdlib types are fine.
> extension Array: ContiguousByteCollection {}
> extension ArraySlice: ContiguousByteCollection {}
> extension ContiguousArray: ContiguousByteCollection {}
> 
> // corelibs types give us a pointer, should be: { pointer, count }
> #if canImport(Dispatch)
>   import Dispatch
> 
>   extension DispatchData : ContiguousByteCollection {
> func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> T) 
> rethrows -> T {
>   return try withUnsafeBytes { try body(UnsafeRawBufferPointer(start: $0, 
> count: count)) }
> }
>   }
> #endif
> 
> #if canImport(Foundation)
>   import Foundation
> 
>   extension Data : ContiguousByteCollection {
> func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> T) 
> rethrows -> T {
>   return try withUnsafeBytes { try body(UnsafeRawBufferPointer(start: $0, 
> count: count)) }
> }
>   }
> #endif
> Conceptually, the corelibs types are untyped regions of memory, and it would 
> make sense for them to adopt the UnsafeRawBufferPointer model.
> 
>  
> Proposed
>  solution
> 
> The proposed solution would be to deprecate the current methods on 
> (Dispatch)Data (with 2 generic parameters), and replace them with methods 
> with identical signatures to Array (with 1 generic parameter).
> 
> To be deprecated:
> 
> public func withUnsafeBytes(_ body: 
> (UnsafePointer) throws -> ResultType) rethrows -> ResultType
> Replaced with:
> 
> public func withUnsafeBytes(_ body: (UnsafeRawBufferPointer) throws -> R) 
> rethrows -> R
>  
> 
Thanks Karl. Good observation.

I proposed exactly this API along with a few other UnsafeRawBufferPointer 
compatibility API’s during SE-0183. Look for Tony to follow up on this.

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

Re: [swift-evolution] Move placement of 'throws' statement

[Erica Sadun via swift-evolution]

I too am happy with the status quo.

As a reminder,  structured markup supports "- throws:" annotation

-- E

> On Jan 4, 2017, at 5:10 AM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
>> 
>> On 3 Jan 2017, at 16:29, John McCall via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> I'm sorry if people dislike the placement of "throws", but that ship has 
>> sailed,
>> and any attempt to "fix" it at this point is just going to cause problems for
>> negligible benefit.
>> 
>> As I see it, the current syntax has one mild deficiency, called out 
>> previously
>> in this thread: a reader has to recognize that "throws -> X" does not mean
>> that the function throws an X, but instead that it either throws or returns 
>> an X.
>> It's always nice when something is immediately obvious and doesn't have to
>> be explicitly learned, and I appreciate and mourn that my design may have
>> fallen short of that standard here. However, overall I still do think the 
>> syntax
>> is much cleaner than the alternatives, especially as return types grow more
>> complicated, and that this small rule is not at all difficult to master.
> 
> I’m going to stand up for the way it is now. I do not think the design falls 
> short or is deficient. 

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

Re: [swift-evolution] Move placement of 'throws' statement

[thislooksfun via swift-evolution]

As I originally mentioned, once you are familiar with the facts that A) 
`throws` takes no parameters, and B) that `->` is returns, then I agree that 
iit is perfectly clear.

My original (and still continuing, but getting better) confusion might make 
more sense after seeing the following translated into Java (which was my 
original language)

//Swift:
func getData() throws -> Int {
  ...
}

//Java:
int getData() throws NumberFormatException {
  ...
}

Once again, after you're used to the Swift way, it makes perfect sense (and I 
kind of like it better than Java), but the initial switch-over from any 
statically defined thrown type language can be somewhat confusing.

I still personally prefer the `throwing` prefix, but the way it currently is 
also works just fine, I'll just have to adjust.

-thislooksfun (tlf)

> On Jan 4, 2017, at 6:10 AM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
>> 
>> On 3 Jan 2017, at 16:29, John McCall via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> I'm sorry if people dislike the placement of "throws", but that ship has 
>> sailed,
>> and any attempt to "fix" it at this point is just going to cause problems for
>> negligible benefit.
>> 
>> As I see it, the current syntax has one mild deficiency, called out 
>> previously
>> in this thread: a reader has to recognize that "throws -> X" does not mean
>> that the function throws an X, but instead that it either throws or returns 
>> an X.
>> It's always nice when something is immediately obvious and doesn't have to
>> be explicitly learned, and I appreciate and mourn that my design may have
>> fallen short of that standard here. However, overall I still do think the 
>> syntax
>> is much cleaner than the alternatives, especially as return types grow more
>> complicated, and that this small rule is not at all difficult to master.
> 
> I’m going to stand up for the way it is now. I do not think the design falls 
> short or is deficient. Bearing in mind that “->” actually means “returns”, I 
> honestly can’t see why anybody would think
> 
>func foo() throws -> Int
> 
> could possibly be a function that throws an Int, especially if they have any 
> knowledge of how the throw mechanism works in Swift (or any other language, 
> for that matter).
> 
> If it had been decided to put throws at the end, we’d probably be having an 
> argument now that
> 
>func foo() -> Int throws
> 
> appears to return an Int that throws, an argument with much more validity, as 
> pointed out upthread, because
> 
>func foo() -> () -> Int throws
> 
> really is ambiguous.
> 
> 
>> 
>> For what it's worth, this visual ambiguity is precisely why I would insist 
>> that
>> any typed-throws addition be spelled "throws(X)" instead of "throws X".
>> 
>> John.
>> 
>> 
>>> 
 which work inconsistently and surprisingly in some cases.
 
 Here is a different way of looking at this: The predictable case is
 the one we already have now (and we wouldn’t take it away).  Is your
 beef with the current syntax so great that you think it is worth
 adding complexity to the language to privilege some special cases?
>>> 
>>> Not really, no.
>>> 
>>> --
>>> -Dave
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 


signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Move placement of 'throws' statement

[Jeremy Pereira via swift-evolution]

> On 3 Jan 2017, at 16:29, John McCall via swift-evolution 
>  wrote:
> 
> 
> 
> I'm sorry if people dislike the placement of "throws", but that ship has 
> sailed,
> and any attempt to "fix" it at this point is just going to cause problems for
> negligible benefit.
> 
> As I see it, the current syntax has one mild deficiency, called out previously
> in this thread: a reader has to recognize that "throws -> X" does not mean
> that the function throws an X, but instead that it either throws or returns 
> an X.
> It's always nice when something is immediately obvious and doesn't have to
> be explicitly learned, and I appreciate and mourn that my design may have
> fallen short of that standard here. However, overall I still do think the 
> syntax
> is much cleaner than the alternatives, especially as return types grow more
> complicated, and that this small rule is not at all difficult to master.

I’m going to stand up for the way it is now. I do not think the design falls 
short or is deficient. Bearing in mind that “->” actually means “returns”, I 
honestly can’t see why anybody would think 

func foo() throws -> Int

could possibly be a function that throws an Int, especially if they have any 
knowledge of how the throw mechanism works in Swift (or any other language, for 
that matter). 

If it had been decided to put throws at the end, we’d probably be having an 
argument now that 

func foo() -> Int throws

appears to return an Int that throws, an argument with much more validity, as 
pointed out upthread, because 

func foo() -> () -> Int throws

really is ambiguous.


> 
> For what it's worth, this visual ambiguity is precisely why I would insist 
> that
> any typed-throws addition be spelled "throws(X)" instead of "throws X".
> 
> John.
> 
> 
>> 
>>> which work inconsistently and surprisingly in some cases.
>>> 
>>> Here is a different way of looking at this: The predictable case is
>>> the one we already have now (and we wouldn’t take it away).  Is your
>>> beef with the current syntax so great that you think it is worth
>>> adding complexity to the language to privilege some special cases?
>> 
>> Not really, no.
>> 
>> -- 
>> -Dave
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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