Re: [swift-users] Migrating to Swift 3 using Xcode fails

[Marco S Hyman via swift-users]

> 6. It’s still using the old compiler and my code fails to build.

Select your target.  Click on the Build Settings Tab.  Scroll down to the Swift 
Compiler - Version group and change Use Legacy Swift Language Version from Yes 
to No.

I haven’t a clue if that will actually work.   It’s worth a try, though.

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

Re: [swift-users] Swift Playgrounds Not Included with iiOS 10.0.1 GM

[Erica Sadun via swift-users]

And for anyone still wondering -- my iPad hadn't started but aborted the 
upgrade. I was still running the beta not the GM

-- E


> On Sep 8, 2016, at 6:16 PM, Jordan Rose via swift-users 
>  wrote:
> 
> The Swift Playgrounds app is not part of the Swift Open Source project, but 
> just to clear things up: the app will be in the App Store when it goes live, 
> not shipped with the OS (as mentioned in 
> http://www.apple.com/swift/playgrounds/ 
> ). More detail than that isn't 
> really something we can talk about on this list.
> 
> Jordan
> 
> 
>> On Sep 8, 2016, at 17:09, Michael Sheaver via swift-users 
>> > wrote:
>> 
>> My iPad has. 81 GB free, so that wasn't the issue. Like Zhao, I used the OTA 
>> for this upgrade. I could test it by installing the restore image, but at 
>> this point I am not sure it is worth any more effort. What do you think?
>> 
>>> On Sep 8, 2016, at 7:53 PM, Zhao Xin >> > wrote:
>>> 
>>> It is not on mine after upgrading to GM through OTA. Mine free space is 
>>> 9.35GB.
>>> 
>>> I think it can be easily explained. It is not a system app, it appeared in 
>>> beta just because it is easily for us to test. It will appear in App Store 
>>> when iOS 10 officially released.
>>> 
>>> Zhaoxin
>>> 
>>> On Fri, Sep 9, 2016 at 7:25 AM, Erica Sadun via swift-users 
>>> > wrote:
>>> It is still on my iPad.
>>> 
>>> As far as I can tell (going by Twitter replies), if you had sufficient 
>>> space for the upgrade (I had about 3.5 gb), it was not removed.
>>> 
>>> I recommend filing a bug report at bugreport.apple.com 
>>> 
>>> 
>>> -- E
>>> 
>>> 
 On Sep 8, 2016, at 3:23 PM, Michael Sheaver via swift-users 
 > wrote:
 
 This is just a heads-up for all who might be using/enjoying/playing with 
 Swift Playgrounds on the iPad; it has apparently been removed from the GM 
 that was released yesterday. There are a couple posts about it in the 
 Apple forums, but no definitive answers have been posted as yet. I 
 searched in the App Store, and it isn't there yet either.
 
 Michael Sheaver
 
 ___
 swift-users mailing list
 swift-users@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-users 
 
>>> 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>>> 
>>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Migrating to Swift 3 using Xcode fails

[Zhao Xin via swift-users]

I
​ am confused with your situation. You said, "I’ve migrated one of my
projects to Swift 3 previously, with an earlier beta of Xcode.". Then in
Xcode should not using Swift 2.3. Assuming
​X
​code using 2.3 wrongly, you should use Xcode migration tool again, after
that Xcode will use Swift 3.0. You manually change code will not cause
Xcode using Swift 3.0 automatically.

Zhaoxin​

On Fri, Sep 9, 2016 at 10:26 AM, Saagar Jha  wrote:

> I am aware that there were new proposals, and I’ve been following along
> and manually migrating. The errors are due to Xcode using the Swift 2.3
> compiler, which doesn’t like the new Swift 3 syntax (for example, it’s
> complaining that it can’t find the new types that have the NS- prefix
> dropped). I’m just looking for the flag in build settings that switches the
> compilers.
>
> Saagar Jha
>
>
>
> On Sep 8, 2016, at 16:47, Zhao Xin  wrote:
>
> ​I think you can just use Xcode's tool that you upgrade to Swift 3.0.
> However, I suggest you do a backup of your project first in case this is
> not helpful.
>
> Also, the errors you saw were probably not because of Xcode converted you
> code to 2.3 automatically. It wouldn't do that. The real reason is that in
> Xcode 6 beta6, a lot of Swift 3.0 accepted proposals were implemented and
> released, which made the Swift 3.0 far more different from the previous
> 3.0.
>
> Xcode's migration tool is closed sourced and is not part of Swift. ​If you
> have further questions, I suggest you to ask it in Apple's developer forum.
>
> Zhaoxin
>
> On Fri, Sep 9, 2016 at 5:01 AM, Saagar Jha via swift-users <
> swift-users@swift.org> wrote:
>
>> Hi,
>>
>> I’ve migrated one of my projects to Swift 3 previously, with an earlier
>> beta of Xcode. However, after downloading the GM seed, hundreds of errors
>> pop up in my code, since it appears that Xcode has somehow reverted the
>> compiler back to 2.3. Manually migrating using Edit>Convert>To Current
>> Swift Syntax… always fails, due to the fact that the code had been
>> previously migrated. Is there any way to “manually” migrate the code (i.e.
>> change the compiler settings?)
>>
>> Thanks,
>> Saagar Jha
>>
>>
>>
>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Migrating to Swift 3 using Xcode fails

[Saagar Jha via swift-users]

I am aware that there were new proposals, and I’ve been following along and 
manually migrating. The errors are due to Xcode using the Swift 2.3 compiler, 
which doesn’t like the new Swift 3 syntax (for example, it’s complaining that 
it can’t find the new types that have the NS- prefix dropped). I’m just looking 
for the flag in build settings that switches the compilers.

Saagar Jha



> On Sep 8, 2016, at 16:47, Zhao Xin  wrote:
> 
> ​I think you can just use Xcode's tool that you upgrade to Swift 3.0. 
> However, I suggest you do a backup of your project first in case this is not 
> helpful.
> 
> Also, the errors you saw were probably not because of Xcode converted you 
> code to 2.3 automatically. It wouldn't do that. The real reason is that in 
> Xcode 6 beta6, a lot of Swift 3.0 accepted proposals were implemented and 
> released, which made the Swift 3.0 far more different from the previous 3.0. 
> 
> Xcode's migration tool is closed sourced and is not part of Swift. ​If you 
> have further questions, I suggest you to ask it in Apple's developer forum.
> 
> Zhaoxin
> 
> On Fri, Sep 9, 2016 at 5:01 AM, Saagar Jha via swift-users 
> > wrote:
> Hi,
> 
> I’ve migrated one of my projects to Swift 3 previously, with an earlier beta 
> of Xcode. However, after downloading the GM seed, hundreds of errors pop up 
> in my code, since it appears that Xcode has somehow reverted the compiler 
> back to 2.3. Manually migrating using Edit>Convert>To Current Swift Syntax… 
> always fails, due to the fact that the code had been previously migrated. Is 
> there any way to “manually” migrate the code (i.e. change the compiler 
> settings?)
> 
> Thanks,
> Saagar Jha
> 
> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
> 
> 

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

Re: [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping

[Shawn Erickson via swift-users]

Michael any ideas about how to deal with the following? It seems like at
least a bug in the fix-it.

I assume I should open a bug on this?

-Shawn

On Wed, Sep 7, 2016 at 9:16 PM Shawn Erickson  wrote:

> I seem to have hit a possibly related @escaping issue...
>
> The following code worked without issue under Swift 2.x and earlier
> variants of Swift 3 but after the @escaping change (fairly sure that is
> what is at fault) it no longer compiles.
>
> protocol Foo {
> // Happy
> func visitValues(visitors: [(key: String, body: (T) throws ->
> Void)]) throws
>
> // Happy
> func visitValues(throwOnWrongType: Bool, visitors: [(key: String,
> body: (T) throws -> Void)]) throws
> }
>
> protocol FooBar { // IGNORE ME - NOT PART OF ORIGINAL CODE
> // Unhappy - this is appearntly expected given prior emails in this
> thread
> // @escaping may only be applied to parameters of function type
> func visitValues(visitors: [(key: String, body: @escaping (T)
> throws -> Void)]) throws
>
> // Unhappy - this is appearntly expected given prior emails in this
> thread
> // @escaping may only be applied to parameters of function type
> func visitValues(throwOnWrongType: Bool, visitors: [(key: String,
> body: @escaping (T) throws -> Void)]) throws
> }
>
> // Provide a default implementation for the simple visitor version
> extension Foo {
> // Happy
> func visitValues(visitors: [(String, body: (T) throws -> Void)])
> throws {
> try self.visitValues(throwOnWrongType: false, visitors: visitors)
> }
> }
>
> // Unhappy
> // error: type 'RealFoo' does not conform to protocol 'Foo'
> struct RealFoo : Foo {
> // Happy
> func visitValues(throwOnWrongType: Bool, visitors: [(key: String,
> body: (T) throws -> Void)]) throws {
> // do stuff...
> }
>
> // error: MyPlayground.playground:23:8: error: type 'RealFoo' does not
> conform to protocol 'Foo'
> //struct RealFoo : Foo {
> //^
> //
> //MyPlayground.playground:16:10: note: candidate has non-matching
> type ' (visitors: [(String, body: (T) throws -> Void)]) throws ->
> ()' (aka '<τ_0_0, τ_1_0> (visitors: Array<(String, body: (τ_1_0) throws ->
> ())>) throws -> ()')
> //func visitValues(visitors: [(String, body: (T) throws ->
> Void)]) throws {
>
> // The fix-it suggestion for "error: type 'RealFoo' does not conform
> to protocol 'Foo'" inserts the following which makes
> // the "not conform" error go away however it doesn't compile because
> of @escaping
> // Unhappy
> // @escaping may only be applied to parameters of function type
> internal func visitValues(visitors: [(key: String, body: @escaping
> (T) throws -> Void)]) throws { // NOT PART OF ORIGINAL CODE
> }
> // The above shouldn't be needed since an implementation is provided
> via an extension on protocol Foo right?
> }
>
> On Wed, Sep 7, 2016 at 8:06 PM Shawn Erickson  wrote:
>
>> To more completely state what I find it a little strange.
>>
>> The default was moved to be non-escaping since that is the better default
>> (for various reason) with @escaping being used to both inform the compiler
>> that something is intentionally escaping (yeah I meant to do that) and to
>> me it seem also helpful as a way to inform the user of the API that the
>> closure they are providing is escaping so they better understand the
>> requirements placed on that closure (e.g. it may not be called before the
>> called function returns, possible retain cycle issues, etc.).
>>
>> So when using APIs I would look for @escaping as a way to know I need to
>> think a little more about the behavior of the closure and the func taking
>> the closure that I am calling. If I don't see it I may incorrectly assume
>> it isn't escaping when intact it may have be implicitly escaping.
>>
>> Anyway my thoughts on this...
>>
>> -Shawn
>>
>>
>>
>> On Wed, Sep 7, 2016 at 7:08 PM Shawn Erickson  wrote:
>>
>>> It just seems a little strange that @escaping only shows up once in the
>>> following example (real) function of mine yet both of them are escaping.
>>> This fixit message should maybe imply that @escaping isn't needed since the
>>> optional one is already implicitly considered escaping? ...it is kinda
>>> confusing when first jumping over to Swift if at one point you are told you
>>> need to added @escaping (the non-optional one) yet you are told @escaping
>>> isn't valid for the optional one despite it needing to be escaping (e.g.
>>> the fixit doesn't really explain that is already escaping).
>>>
>>> func httpGet(path: String, parameters: [String:String] = [:],
>>> needsAuth: Bool = true, queue: DispatchQueue =
>>> DispatchQueue.main,
>>> completion: ObjectFetchCallback?, importer:
>>> @escaping HttpImporterCallback)
>>>
>>> -Shawn
>>>
>>> On Wed, Sep 7, 2016 at 6:51 PM Jacob Bandes-Storch 

Re: [swift-users] Swift Playgrounds Not Included with iiOS 10.0.1 GM

[Jordan Rose via swift-users]

The Swift Playgrounds app is not part of the Swift Open Source project, but 
just to clear things up: the app will be in the App Store when it goes live, 
not shipped with the OS (as mentioned in 
http://www.apple.com/swift/playgrounds/). More detail than that isn't really 
something we can talk about on this list.

Jordan


> On Sep 8, 2016, at 17:09, Michael Sheaver via swift-users 
>  wrote:
> 
> My iPad has. 81 GB free, so that wasn't the issue. Like Zhao, I used the OTA 
> for this upgrade. I could test it by installing the restore image, but at 
> this point I am not sure it is worth any more effort. What do you think?
> 
>> On Sep 8, 2016, at 7:53 PM, Zhao Xin > > wrote:
>> 
>> It is not on mine after upgrading to GM through OTA. Mine free space is 
>> 9.35GB.
>> 
>> I think it can be easily explained. It is not a system app, it appeared in 
>> beta just because it is easily for us to test. It will appear in App Store 
>> when iOS 10 officially released.
>> 
>> Zhaoxin
>> 
>> On Fri, Sep 9, 2016 at 7:25 AM, Erica Sadun via swift-users 
>> > wrote:
>> It is still on my iPad.
>> 
>> As far as I can tell (going by Twitter replies), if you had sufficient space 
>> for the upgrade (I had about 3.5 gb), it was not removed.
>> 
>> I recommend filing a bug report at bugreport.apple.com 
>> 
>> 
>> -- E
>> 
>> 
>>> On Sep 8, 2016, at 3:23 PM, Michael Sheaver via swift-users 
>>> > wrote:
>>> 
>>> This is just a heads-up for all who might be using/enjoying/playing with 
>>> Swift Playgrounds on the iPad; it has apparently been removed from the GM 
>>> that was released yesterday. There are a couple posts about it in the Apple 
>>> forums, but no definitive answers have been posted as yet. I searched in 
>>> the App Store, and it isn't there yet either.
>>> 
>>> Michael Sheaver
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-users 
>>> 
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
>> 
>> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Swift Playgrounds Not Included with iiOS 10.0.1 GM

[Michael Sheaver via swift-users]

My iPad has. 81 GB free, so that wasn't the issue. Like Zhao, I used the OTA 
for this upgrade. I could test it by installing the restore image, but at this 
point I am not sure it is worth any more effort. What do you think?

> On Sep 8, 2016, at 7:53 PM, Zhao Xin  wrote:
> 
> It is not on mine after upgrading to GM through OTA. Mine free space is 
> 9.35GB.
> 
> I think it can be easily explained. It is not a system app, it appeared in 
> beta just because it is easily for us to test. It will appear in App Store 
> when iOS 10 officially released.
> 
> Zhaoxin
> 
> On Fri, Sep 9, 2016 at 7:25 AM, Erica Sadun via swift-users 
> > wrote:
> It is still on my iPad.
> 
> As far as I can tell (going by Twitter replies), if you had sufficient space 
> for the upgrade (I had about 3.5 gb), it was not removed.
> 
> I recommend filing a bug report at bugreport.apple.com 
> 
> 
> -- E
> 
> 
>> On Sep 8, 2016, at 3:23 PM, Michael Sheaver via swift-users 
>> > wrote:
>> 
>> This is just a heads-up for all who might be using/enjoying/playing with 
>> Swift Playgrounds on the iPad; it has apparently been removed from the GM 
>> that was released yesterday. There are a couple posts about it in the Apple 
>> forums, but no definitive answers have been posted as yet. I searched in the 
>> App Store, and it isn't there yet either.
>> 
>> Michael Sheaver
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
> 
> 

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

Re: [swift-users] Swift Playgrounds Not Included with iiOS 10.0.1 GM

[Zhao Xin via swift-users]

It is not on mine after upgrading to GM through OTA. Mine free space is
9.35GB.

I think it can be easily explained. It is not a system app, it appeared in
beta just because it is easily for us to test. It will appear in App Store
when iOS 10 officially released.

Zhaoxin

On Fri, Sep 9, 2016 at 7:25 AM, Erica Sadun via swift-users <
swift-users@swift.org> wrote:

> It is still on my iPad.
>
> As far as I can tell (going by Twitter replies), if you had sufficient
> space for the upgrade (I had about 3.5 gb), it was not removed.
>
> I recommend filing a bug report at bugreport.apple.com
>
> -- E
>
>
> On Sep 8, 2016, at 3:23 PM, Michael Sheaver via swift-users <
> swift-users@swift.org> wrote:
>
> This is just a heads-up for all who might be using/enjoying/playing with
> Swift Playgrounds on the iPad; it has apparently been removed from the GM
> that was released yesterday. There are a couple posts about it in the Apple
> forums, but no definitive answers have been posted as yet. I searched in
> the App Store, and it isn't there yet either.
>
> Michael Sheaver
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift Playgrounds Not Included with iiOS 10.0.1 GM

[Erica Sadun via swift-users]

It is still on my iPad.

As far as I can tell (going by Twitter replies), if you had sufficient space 
for the upgrade (I had about 3.5 gb), it was not removed.

I recommend filing a bug report at bugreport.apple.com 


-- E


> On Sep 8, 2016, at 3:23 PM, Michael Sheaver via swift-users 
>  wrote:
> 
> This is just a heads-up for all who might be using/enjoying/playing with 
> Swift Playgrounds on the iPad; it has apparently been removed from the GM 
> that was released yesterday. There are a couple posts about it in the Apple 
> forums, but no definitive answers have been posted as yet. I searched in the 
> App Store, and it isn't there yet either.
> 
> Michael Sheaver
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

[swift-users] Swift Playgrounds Not Included with iiOS 10.0.1 GM

[Michael Sheaver via swift-users]

This is just a heads-up for all who might be using/enjoying/playing with Swift 
Playgrounds on the iPad; it has apparently been removed from the GM that was 
released yesterday. There are a couple posts about it in the Apple forums, but 
no definitive answers have been posted as yet. I searched in the App Store, and 
it isn't there yet either.

Michael Sheaver

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

[swift-users] Migrating to Swift 3 using Xcode fails

[Saagar Jha via swift-users]

Hi,

I’ve migrated one of my projects to Swift 3 previously, with an earlier beta of 
Xcode. However, after downloading the GM seed, hundreds of errors pop up in my 
code, since it appears that Xcode has somehow reverted the compiler back to 
2.3. Manually migrating using Edit>Convert>To Current Swift Syntax… always 
fails, due to the fact that the code had been previously migrated. Is there any 
way to “manually” migrate the code (i.e. change the compiler settings?)

Thanks,
Saagar Jha



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

Re: [swift-users] Weak references in generic types

[Jens Alfke via swift-users]

> On Sep 8, 2016, at 6:28 AM, Karl Wagner via swift-users 
>  wrote:
> 
> It is in some sense a language limitation that we cant express what you're 
> talking about. If we weren't using mailing lists it would be easier to search 
> for "protocol self-conformance" on swift-evo and to read the earlier 
> discussion about it. 



…or if we were using some modern mailing list host like Google Groups or 
groups.io, that also offers a web view.


—Jens___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping

[Michael Ilseman via swift-users]

> On Sep 7, 2016, at 6:50 PM, Jacob Bandes-Storch  wrote:
> 
> On Wed, Sep 7, 2016 at 5:54 PM, Michael Ilseman via swift-users 
> > wrote:
> I implemented a better (i.e. correct) diagnostic message for this at 
> https://github.com/apple/swift/pull/4670 
> . I want to also do a better 
> diagnostic specifically for aggregate parameters to functions (e.g. optional 
> closures), but that requires more work in the type checker.
> 
> Basically, @escaping is valid only on closures in function parameter 
> position. The noescape-by-default rule only applies to these closures at 
> function parameter position, otherwise they are escaping. Aggregates, such as 
> enums with associated values (e.g. Optional), tuples, structs, etc., if they 
> have closures, follow the default rules for closures that are not at function 
> parameter position, i.e. they are escaping.
> 
> Shouldn't it be possible to allow distinguishing @escaping/@noescape for 
> aggregates like these, at least for the simple case of Optional?  (I handled 
> optionals in https://github.com/apple/swift/pull/4438 
>  for imported function types; see 
> comment .)
>  

Yes it is possible (but *not* in time for Swift 3) to address this. Optional at 
the very least would be the highest bang for our buck, along with other 
single-type aggregate structures. A general solution would require some kind of 
aggregate liveness solution, but we can get something very good with a bit 
less: we could express such things with the ‘@escaping’ still being at the 
immediate function parameter position, and applying it throughout aggregate 
types in a principled fashion. E.g.:

func foo(_ a: @escaping ((Int) -> Int)?) {}
func foo(_ a: @escaping (Int, (Int) -> Int)) {}
func foo(_ a: @escaping ((Int) -> Int, (Int) -> Int)) {} // both are escaping
func foo(_ a: @escaping [(Int) -> Int]? {} // they are all escaping

Struct aggregate members and protocol associated types would not be impacted by 
this, as their member types are not listed in their signature, only tuples and 
generic type parameters (modulo sugar).

This would re-enforce that it’s about the parameter position specifically being 
a special case. Also, I don’t think there’s any practical benefit to finer 
grained escapability, e.g. some tuple elements are escaping and some are not. 
Though, at this point, maybe it makes more sense being a parameter attribute, 
rather than a type attribute…

Any solution should be discussed further on swift-evolution.



> 
> It would be a post-Swift-3 addition to the language to be able to support 
> more robust liveness tracking here. There may be interesting directions to 
> take this, with optional closures being the most common beneficiary. 
> 
>> On Sep 7, 2016, at 3:33 PM, Shawn Erickson via swift-users 
>> > wrote:
>> 
>> I see https://bugs.swift.org/browse/SR-2324 
>>  and 
>> https://bugs.swift.org/browse/SR-2444 
>>  which looks related to this issue 
>> and may explain the error I saw on "the other side" of this.
>> 
>> 
>> 
>> On Wed, Sep 7, 2016 at 3:28 PM Shawn Erickson > > wrote:
>> Yeah I actually have a few of those myself that I can no longer do.
>> 
>> On Wed, Sep 7, 2016 at 3:26 PM Jon Shier > > wrote:
>> Perhaps relatedly, it no longer seems possible to mark typealiased closures 
>> as @escaping. That was quite handy when you know that closures will always 
>> be used asynchronously.
>> 
>> 
>> Jon
>> 
>> 
>> 
>>> On Sep 7, 2016, at 6:15 PM, Shawn Erickson via swift-users 
>>> > wrote:
>>> 
>> 
>>> I should note that this issue also appeared in an earlier variant of Swift 
>>> after the addition of @escaping but I was on vacation so didn't get a 
>>> chance to report it then. It isn't new with the Xcode 8 GM.
>>> 
>>> On Wed, Sep 7, 2016 at 3:08 PM Shawn Erickson >> > wrote:
>>> I like and fully supported the change to @escaping away from @noescape 
>>> however in a body of code that I am porting to the latest Swift 3 variant 
>>> (as found in Xcode 8 GM) I am hitting an issue for methods that take an 
>>> optional completion closure. If optional is involved I can't find a way to 
>>> apply @escape to the escaping closure. See the following for an basic 
>>> example...
>>> 
>>> Is their a way to do what I need and/or is this an edge case in the 
>>> implementation of @escaping?
>>> 
>>> typealias MyCallback = (String)->()
>>> 
>>> // Happy
>>> func foo1(bar: String, completion: ((String)->())) {
>>> completion(bar)

Re: [swift-users] Weak references in generic types

[Karl Wagner via swift-users]

  
  
What I'm trying to say is that P is a protocol and not a class, so it does not 
conform to AnyObject.   P does not conform to P.
  

  
It is in some sense a language limitation that we cant express what you're 
talking about. If we weren't using mailing lists it would be easier to search 
for "protocol self-conformance" on swift-evo and to read the earlier discussion 
about it.   
  

  

  
  
>   
> On Sep 2, 2016 at 1:04 am,  mailto:howard.lov...@gmail.com)>  
> wrote:
>   
>   
> @Karl,  
>
>   
> You say "In the second example, you’re creating WeakReference. P does not 
> conform to P or to AnyObject.", but P does conform to AnyObject.
>   
>
>   
> I suspect it is a compiler limitation/ bug.   
>   
>
>   
>   -- Howard.   
>
>  On Thursday, 1 September 2016, Karl   (mailto:razie...@gmail.com)>  wrote:
>   
> >   
> >
> >   
> >   
> > >   
> > > On 1 Sep 2016, at 03:23, Howard Lovatt via swift-users  
> > >  > > (javascript:_e(%7B%7D,'cvml','swift-users@swift.org');)>  wrote:
> > >   
> > >   
> > >   
> > > Playing around I found that if you make the protocol @objc instead of 
> > > AnyObject then it works :). EG:  
> > >
> > >   
> > > >   
> > > > struct WeakReference  {
> > > >   
> > > >weak var value: T?
> > > >   
> > > > }
> > > >   
> > > > @objc protocol P { // Note @objc, class or AnyObject does not work
> > > >   
> > > >var i: Int { get }
> > > >   
> > > > }
> > > >   
> > > > class CP: P {
> > > >   
> > > >var i: Int = 0
> > > >   
> > > > }
> > > >   
> > > > let weakPs: [WeakReference] = [WeakReference(value: cP)] // Note 
> > > > typed as `[WeakReference]`
> > > >   
> > > > print("P: \(weakPs[0].value!.i)") // 0
> > > >   
> > >   
> > >   
> > >
> > > Not a 'pure' Swift solution :(, but OK in my case.
> > >
> > >   
> > >   
> > >   
> > >
> > >   
> > >   
> > >-- Howard.
> > > 
> > >   
> > > On 29 August 2016 at 16:21, Howard Lovatt   > > (javascript:_e(%7B%7D,'cvml','howard.lov...@gmail.com');)>  wrote:
> > >   
> > > >   
> > > > Hi,  
> > > >
> > > >   
> > > > I am wanting to use weak references in generic data structures; in the 
> > > > example below Array, but in general any generic type. I can almost get 
> > > > it to work :(
> > > >   
> > > >
> > > >   
> > > > My experiments started off well; the following works:
> > > >   
> > > >
> > > >   
> > > > >   
> > > > > // Array of weak references OK
> > > > >   
> > > > > struct WeakReference  {
> > > > >   
> > > > >weak var value: T?
> > > > >   
> > > > > }
> > > > >   
> > > > > class C {
> > > > >   
> > > > >var i: Int = 0
> > > > >   
> > > > > }
> > > > >   
> > > > > let c = C() // Strong reference to prevent collection
> > > > >   
> > > > > let weakCs = [WeakReference(value: c)] // OK
> > > > >   
> > > > > print("C: \(weakCs[0].value!.i)") // 0
> > > > >   
> > > >   
> > > >  I can add a protocol:  
> > > >
> > > >   
> > > > >   
> > > > > // Array of weak references that implements a protocol OK
> > > > >   
> > > > > protocol P: AnyObject { // Note AnyObject
> > > > >   
> > > > >var i: Int { get }
> > > > >   
> > > > > }
> > > > >   
> > > > > class CP: P {
> > > > >   
> > > > >var i: Int = 0
> > > > >   
> > > > > }
> > > > >   
> > > > > let cP = CP() // Strong reference to prevent collection
> > > > >   
> > > > > let weakCPs = [WeakReference(value: cP)] // OK
> > > > >   
> > > > > print("CP: \(weakCPs[0].value!.i)") // 0
> > > > >   
> > > >   
> > > >   
> > > >
> > > >   
> > > > But when I want an array of weak references to the protocol I get an 
> > > > error:
> > > >   
> > > >
> > > > 
> > > > >   
> > > > > // Array of weak references of a protocol not OK
> > > > >   
> > > > > let weakPs: [WeakReference] = [WeakReference(value: cP)] // Using 
> > > > > 'P' as a concrete type conforming to protocol 'AnyObject' is not 
> > > > > supported
> > > > >   
> > > > > print("P: \(weakPs[0].value!.i)") // 0
> > > > >   
> > > >   
> > > >   
> > > >
> > > >   
> > > > Is there something I have missed?
> > > >   
> > > >
> > > >   
> > > > The error message, "Using 'P' as a concrete type conforming to protocol 
> > > > 'AnyObject' is not supported", implies that it is a temporary 
> > > > limitation of the compiler; is this going to be fixed? Should I lodge a 
> > > > bug report?
> > > >   
> > > >
> > > >   
> > > > Thanks in advance for any advice,
> > > >   
> > > >
> > > >   
> > > >   
> > > >-- Howard.
> > > >   
> > >  ___
> > >  swift-users mailing list
> > >   swift-users@swift.org 
> > > (javascript:_e(%7B%7D,'cvml','swift-users@swift.org');)
> > >   https://lists.swift.org/mailman/listinfo/swift-users
> > > 
> >   
> > Your problem is protocol self-conformance. In the first example, you’re 
> > creating WeakReference. CP conforms to P and to AnyObject. In the 
> > 

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

[Gerard Iglesias via swift-users]

Andrew,

Thank you for the compliment ;)

And thank you for the 2 advices

And the question about use of size or stride ? I understand that the 
underlaying float data are aligned in this specific case, but I wonder in fact 
if the shader compiler align memory the same way the swift compiler do, I 
suppose yes unless it would be a nightmare, but murphy’s principle says me … 
take care ;)

Thanks in advance

Gerard

> On 8 Sep 2016, at 07:21, Andrew Trick  wrote:
> 
>> 
>> On Sep 3, 2016, at 6:03 PM, Gerard Iglesias via swift-users 
>> > wrote:
>> 
>> This is my funny version… I succeeded and I didn’t come back to find an 
>> other way…
>> 
>> // Grab a pointer to the constant buffer's data store
>> // Since we are using Swift, it is easier to cast the pointer to the 
>> ShadowPass type to fill the constant buffer
>> // We need to make a copy of these so the block captures the correct data
>> 
>> //let shadowPtr = 
>> UnsafeMutablePointer(constantBufferForFrame.contents())
>> let shadowPtr = constantBufferForFrame.contents().assumingMemoryBound(to: 
>> ShadowPass.self)
>> shadowPtr.pointee = shadowPassData[0]
>>  
>> //More Swift specific stuff - advance pointer and cast to MainPass
>> 
>> //let mainPtr = UnsafeMutablePointer(shadowPtr.advanced(by: 1))
>> let mainPtr = constantBufferForFrame.contents().advanced(by: 
>> MemoryLayout.size).assumingMemoryBound(to: MainPass.self)
>> mainPtr.pointee = mainPassFrameData
>>  
>> //Advance and cast to ObjectData
>> 
>> //var ptr = UnsafeMutablePointer(mainPtr.advanced(by: 1))
>> var ptr = constantBufferForFrame.contents().advanced(by: 
>> MemoryLayout.size + 
>> MemoryLayout.size).assumingMemoryBound(to: ObjectData.self)
> 
> Gerard,
> 
> I like your code. A couple of things to consider:
> 
> 1. If the memory has never been bound to a type (i.e. it's straight from 
> MTLBuffer.newBuffer), then rather than “assuming” memory is bound to these 
> types, you should just bind it here (substitute all your 
> assumingMemoryBound(to: _) with bindMemory(to: _, capacity: 1). Think of it 
> as two-phase initialization of the memory. First declare the memory's type 
> (e.g. some structure that holds a bunch of floats), then write individual 
> float values into the memory.
> 
> 2. If you want the compiler to compute byte offsets for you like the original 
> code, then can be done as follows:
> 
>   let mainPtr = UnsafeMutableRawPointer(shadowPtr + 1).bindMemory(
> to: MainPass.self, capacity: 1)
>   mainPtr.pointee = mainPassFrameData
>   ...
> 
> However, your approach of computing byte offsets is more explicit.
> 
> My migration guide landed on swift.org  today! I think it 
> will be a big help.
> https://swift.org/migration-guide/se-0107-migrate.html 
> 
> 
> -Andy
> 
>>> On 3 Sep 2016, at 19:22, Patrice Kouame >> > wrote:
>>> 
>>> Gerard- 
>>> 
>>> Excellent!  Looking forward to seeing your fix (hoping you get your book 
>>> back soon ;-) )
>>> 
>>> I think Xcode/Swift gags on the last ptr advance to objectData.  I recently 
>>> tried another variant using withUnsafeMutablePointer like this:
>>> 
>>> var ptr : UnsafeMutablePointer  = 
>>> withUnsafeMutablePointer(to: ) {
>>> $0.withMemoryRebound(to: ObjectData.self, capacity: 
>>> objectsToRender) {
>>> $0.pointee = renderables[0].objectData
>>> }
>>> }
>>> 
>>> ..but still crashes with no hints.
>>> 
>>> My bug report also mentions that the Xcode migration/conversion tool is 
>>> incomplete.  
>>> It handles the “simpler" UnsafeMutableRawPointer to 
>>> UnsafeMutablePonter with bindMemory cases correctly (one still has to 
>>> mind the capacity value though)
>>> In all fairness, migrating/converting automagically in these cases is 
>>> always a little bit tricky - the proposed Xcode fixes should always be 
>>> reviewed by a human...
>>> 
>>> Patrice
>>> 
 On Sep 3, 2016, at 1:05 PM, Gerard Iglesias via swift-users 
 > wrote:
 
 Ok
 
 For the record I succeeded this transformation phase last week
 
 I remember the tedious stuff to advance pointer from one struct to the 
 other kind of struct... it worked
 
 But I don't have my MacBook with me, only the phone, the six :)
 
 Gérard 
 
 Le 3 sept. 2016 à 18:22, Patrice Kouame > a écrit :
 
> Indeed. There is a difference between stride and size, but I interpreted 
> capacity incorrectly for my purposes.  It should indicate the number of 
>  elements (not their size - right?) and the snippets below should work.
> 
> Still, compiler crashes and Xcode IDE is left in inconsistent state.  So 
> I filed this Apple radar