[swift-users] Using String

[Michael Ilseman via swift-users]

Hello, I just sent an email to swift-dev titled "State of String: ABI, 
Performance, Ergonomics, and You!” at 
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20180108/006407.html, 
whose gist can be found at 
https://gist.github.com/milseman/bb39ef7f170641ae52c13600a512782f 
. It’s very 
heavy on implementation details and potential future directions, but there is a 
section that pertains to swift-users concerning the Discourse migration:

## Community
With Swift’s mailing lists [moving to 
Discourse](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171211/042127.html),
 this allows the opportunity for better community engagement and 
cross-referencing posts. We plan on starting an area under the “Using Swift” 
category focusing on idiomatic and/or performant solutions to string 
programming needs. These might be anything from simple programming problems to 
make-my-parser-faster challenges.

While this provides a community benefit by showing how best to use String, our 
ulterior motive is to mine posts looking for benchmarks, API gaps, and 
representative code that new features could improve. We’ll also, of course, 
want to bikeshed the name! My vote is for “String Dojo”, but there’s probably a 
reason I don’t normally name things.


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

Re: [swift-users] Start another program from Swift script

[Michael Ilseman via swift-users]

The “Shell Out” package’s source code shows some simple usage of Foundation’s 
Process: 
https://github.com/JohnSundell/ShellOut/blob/master/Sources/ShellOut.swift#L33. 

That package also handles stdout / stdin, but for more sophisticated uses of 
FileManager the “Files” package’s source has some nice simple usage: 
https://github.com/JohnSundell/Files/blob/master/Sources/Files.swift


> On Jan 4, 2018, at 10:31 AM, Karl Wagner via swift-users 
>  wrote:
> 
> These kinds of things live in Foundation, not the standard library:
> 
> import Foundation
> 
> let p = Process()
> p.executableURL = URL(fileURLWithPath: "/bin/ps")
> try p.run()
> 
> The Process class provides you with stdin/out/error handles for the process 
> (https://developer.apple.com/documentation/foundation/process 
> ).
> FileHandle also provides these standard streams for the current process 
> (https://developer.apple.com/documentation/foundation/filehandle 
> ).
> 
> - Karl
> 
>> On 4. Jan 2018, at 17:03, Седых Александр via swift-users 
>> > wrote:
>> 
>> Well, for example in Python we can run another program from interpreter by
>>  
>> import subprocess
>> result = subprocess.run('ruby script.rb').stdout
>>  
>> My question is next:
>> Can we do something from Swift file at runtime or maybe from terminal via 
>> REPL
>>  
>> And can you send me resource when I can read about work with stdin, stdout 
>> in Swift, because is very small info in Documentation (Standard Library I/O)
>> 
>> -
>> Alexandr
>> ___
>> 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] UnsafeMutableRawPointer to UnsafeMutablePointer: EXC_BAD_ACCESS on pointee

[Michael Ilseman via swift-users]

> On Sep 23, 2017, at 3:44 AM, nyg nyg via swift-users  
> wrote:
> 
> Hello all,
> 
> I'm trying to get an UnsafeMutablePointer from an
> UnsafeMutableRawPointer obtained using the Unmanaged structure:
> 
> class C { var foo = 42, bar = "bar" }
> let c = C()
> 
> let rawPointer = Unmanaged.passUnretained(c).toOpaque()
> 

I believe that the object “c” is effectively dead from this point onwards. Did 
you try putting a use of c later on to guarantee its lifetime? E.g. add a 
`dump(c)` at the bottom of your script?

> let pointer = rawPointer.bindMemory(to: C.self, capacity: 1)
> let pointee = pointer.pointee
> print(pointee.foo) // EXC_BAD_ACCESS
> 
> Here's some LLDB output, which looks strange to me as everything seems
> alright in pointer until I ask for its pointee:
> 
> (lldb) frame variable -L c
> scalar: (memtest2.C) c = 0x000101d00030 {
> 0x000101d00040: foo = 42
> 0x000101d00048: bar = "bar"
> }
> (lldb) frame variable -L rawPointer
> 0x0001005e2e08: (UnsafeMutableRawPointer) rawPointer = {
> scalar: _rawValue = 0x000101d00030 {
> 0x000101d00040: foo = 42
> 0x000101d00048: bar = "bar"
> }
> }
> (lldb) frame variable -L pointer
> 0x0001005e2e10: (UnsafeMutablePointer)
>pointer = 0x000101d00030
> (lldb) frame variable -L pointer._rawValue
> scalar: (memtest2.C) pointer._rawValue = 0x000101d00030 {
> 0x000101d00040: foo = 42
> 0x000101d00048: bar = "bar"
> }
> (lldb) frame variable -L pointee
> 0x0001005e2e18: (memtest2.C) pointee = 0x0001005b65d8 {
> 0x0001005b65e8: foo = 140736790071664
> 0x0001005b65f0: bar = ""
> }
> 
> I've also tried assumingMemoryBound(to:) or simply doing:
> 
> let pointer = UnsafePointer(bitPattern: Int(bitPattern: rawPointer))!
> print(pointer.pointee.foo) // EXC_BAD_ACCESS
> 
> But I always get this EXC_BAD_ACCESS error. What is going on here?
> 
> 
> Thanks for your help,
> Nick
> ___
> 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] Should I be using more catchless do blocks?

[Michael Ilseman via swift-users]

> On Jun 19, 2017, at 11:47 AM, Michael Savich  wrote:
> 
> Yeah, it's all about balance to be sure. Though one benefit of do blocks is 
> in functions that are tied to a sense of time. It seems to me that the in 
> case of something like viewDidLoad separating code into too many functions 
> can obscure the fact that the code is meant to be executed at that time.

I was referring to defining a local function inside your function that you’re 
refactoring. As in, rather than say:

func foo(...) -> … {
// some initialization
do {
… some local variables, some not local...
}

code1...

// some more scoped work
do {
… some local variables, some not local...
}

code2...

// some finalization
do {
… some local variables, some not local...
}
}

You have:

func foo(…) -> … {
func doLocalSetup(…inputs...)  {
… use explicit inputs and local variables
}
func performScopedWork(…inputs…) {
… use explicit inputs and local variables
}
func doFinalTearDown(…inputs…) {
… use explicit inputs and local variables
}

doLocalSetup(…)
defer { doFinalTearDown(…) }

code1...

performScopedWork(…)

code2...
}


That’s just one option. You also mentioned using closures, which can be less 
clear if you’re relying on implicit captures rather than explicit parameters 
(which can have labels/names). It all depends on the details.

> Closures can provide much of the same functionality but I'm pretty sure 
> inline closures have to have names and sometimes risking a bad name is worse 
> than no name at all.
> 

That might be the case. However, often such a do block is worthy of a comment 
before it, and good names make really good comments.

> Anyway, do you think that most Swift users are even aware that do can be used 
> in this fashion?
> 

I wouldn’t think it would be obvious to new Swift programmers, but might be 
familiar to programmers coming from other languages that use scopes heavily. 

It probably depends on your team specifics. As you mentioned, you only recently 
learned of this behavior, so your experience might be a useful proxy for 
whether others are or are not familiar.

> Sent from my iPad
> 
> On Jun 19, 2017, at 2:33 PM, Michael Ilseman  > wrote:
> 
>> Introducing scope to manage lifetimes of local variables is a useful and 
>> valuable practice. Note that it might also be an opportunity to refactor the 
>> code. Any do block you want to introduce could also be a local function 
>> definition that you call later. Alternatively, it could be generalized and 
>> extracted into a utility component. Long function bodies with many do blocks 
>> could be a code smell.
>> 
>> 
>>> On Jun 18, 2017, at 7:07 PM, Michael Savich via swift-users 
>>> > wrote:
>>> 
>>> So, something I did not know until recently is that do blocks in Swift are 
>>> for more than just error handling, they can also be used to tighten scope. 
>>> 
>>> I'm wondering, why not use a ton of do blocks? Like, if I have a 
>>> ViewController lifecycle method like viewDidLoad, I could segment it into 
>>> out a do block for creating subviews, a do block for loading data into 
>>> them, and a do block for adding them to the view itself. This seems like it 
>>> would enforce grouping code tightly together.
>>> 
>>> Yes I could adopt a functional style of programming, but that has its 
>>> downsides too, namely reading any functional code involves trawling through 
>>> a long sequence of function calls. What I'm saying is, do blocks seem like 
>>> a way to get many of the benefits of functional programming while 
>>> maintaining the readability of imperative code. (Sorry functional 
>>> programmers, I promise I love Haskell too!)
>>> 
>>> So I guess what I'm saying is… somebody talk me down from this ledge. Is 
>>> there a reason I shouldn't refactor my projects to be full of do blocks? 
>>> And can this usage of do really be considered idiomatic Swift? Or will most 
>>> people reading my code be left wondering where all the try and catch 
>>> statements are?
>>> 
>>> Sent from my iPad
>>> ___
>>> 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] Should I be using more catchless do blocks?

[Michael Ilseman via swift-users]

Introducing scope to manage lifetimes of local variables is a useful and 
valuable practice. Note that it might also be an opportunity to refactor the 
code. Any do block you want to introduce could also be a local function 
definition that you call later. Alternatively, it could be generalized and 
extracted into a utility component. Long function bodies with many do blocks 
could be a code smell.


> On Jun 18, 2017, at 7:07 PM, Michael Savich via swift-users 
>  wrote:
> 
> So, something I did not know until recently is that do blocks in Swift are 
> for more than just error handling, they can also be used to tighten scope. 
> 
> I'm wondering, why not use a ton of do blocks? Like, if I have a 
> ViewController lifecycle method like viewDidLoad, I could segment it into out 
> a do block for creating subviews, a do block for loading data into them, and 
> a do block for adding them to the view itself. This seems like it would 
> enforce grouping code tightly together.
> 
> Yes I could adopt a functional style of programming, but that has its 
> downsides too, namely reading any functional code involves trawling through a 
> long sequence of function calls. What I'm saying is, do blocks seem like a 
> way to get many of the benefits of functional programming while maintaining 
> the readability of imperative code. (Sorry functional programmers, I promise 
> I love Haskell too!)
> 
> So I guess what I'm saying is… somebody talk me down from this ledge. Is 
> there a reason I shouldn't refactor my projects to be full of do blocks? And 
> can this usage of do really be considered idiomatic Swift? Or will most 
> people reading my code be left wondering where all the try and catch 
> statements are?
> 
> Sent from my iPad
> ___
> 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] Importing C system libraries

[Michael Ilseman via swift-users]

This is into uncharted territory for me, but it seems you’re building with 
SwiftPM. You’ll probably want to configure extra compiler flags if that’s 
possible. You could also bite the bullet and build your C libraries with 
SwiftPM as well. Hopefully someone on swift-build-dev can help you out.

CC-ing Ankit


> On Mar 28, 2017, at 5:09 PM, Kelvin Ma  wrote:
> 
> How do I compile a project with many modules? My tree looks like this:
> 
> 
> ​
> 
> On Tue, Mar 28, 2017 at 12:47 PM, Michael Ilseman  > wrote:
> Sure! In this example, I have built libgit2. I have a directory called Git, 
> and inside that I have the following module map:
> 
> module Git [system] {
>header "/libgit2/include/git2.h"
>export *
> }
> 
> When I run, I use:
> 
> swift -I  -L  -lgit2 foo.swift
> 
> inside foo.swift I can:
> 
> import Git
> // … use libGit2
> 
> 
> Read more about how to write a more appropriate module.map file for your 
> purposes at https://clang.llvm.org/docs/Modules.html 
> . For example, you might be able to 
> define link flags inside the module.map, use umbrella directories, 
> submodules, etc.
> 
> 
> 
>> On Mar 28, 2017, at 6:27 AM, Kelvin Ma > > wrote:
>> 
>> Can you give an example?
>> 
>> On Mon, Mar 27, 2017 at 3:59 PM, Michael Ilseman > > wrote:
>> Sure. At a low level, you can create a module.map file and use -L/-l flags 
>> in your invocation of Swift. If you want to do so at a higher level, then 
>> perhaps SwiftPM can. CCing swift-build-dev for the SwiftPM part.
>> 
>> 
>> > On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users 
>> > > wrote:
>> >
>> > Idk if this has been asked before, but is there a way to import C 
>> > libraries into a Swift project without creating a local git repo? 
>> > Preferably something similar to C where you can just `#include` headers 
>> > and then specify the link flags (in Package.swift?)
>> >
>> > It’s getting very cumbersome to make a bunch of empty git repos just to 
>> > use libglfw or libcairo.
>> > ___
>> > 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] Asynchronous error recovering with RecoverableError

[Michael Ilseman via swift-users]

New start task: https://bugs.swift.org/browse/SR-4405 
 Add @escaping to 
RecoverableError.attemptRecovery


> On Mar 28, 2017, at 3:31 PM, Douglas Gregor  wrote:
> 
> 
>> On Mar 28, 2017, at 11:21 AM, Michael Ilseman > > wrote:
>> 
>> CC Doug Gregor, who git blame tells me wrote this part.
>> 
>> Doug, this slightly predates noescape-by-default. Is this a bug or as 
>> intended?
> 
> It’s a bug; the point here is that we can do recovery asynchronously, so it 
> should be @escaping. We missed the annotation when noescape-by-default landed.
> 
>   - Doug
> 
>> 
>> 
>>> On Mar 28, 2017, at 8:49 AM, Elia Cereda via swift-users 
>>> > wrote:
>>> 
>>> Hi Dennis,
>>> 
>>> Thanks for your answer. I can see that my message needs some more context: 
>>> RecoverableError is a protocol in the standard library that can be 
>>> implemented to opt in to the error recovery mechanism available on macOS. 
>>> attemptRecovery(optionIndex, resultHandler:) is one of the methods that 
>>> have to be implemented to conform to the protocol.
>>> 
>>> Here you can find the other ones:
>>> 
>>> /// Describes an error that may be recoverable by presenting several
>>> /// potential recovery options to the user.
>>> public protocol RecoverableError : Error {
>>> 
>>> /// Provides a set of possible recovery options to present to the user.
>>> public var recoveryOptions: [String] { get }
>>> 
>>> /// Attempt to recover from this error when the user selected the
>>> /// option at the given index. This routine must call handler and
>>> /// indicate whether recovery was successful (or not).
>>> ///
>>> /// This entry point is used for recovery of errors handled at a
>>> /// "document" granularity, that do not affect the entire
>>> /// application.
>>> public func attemptRecovery(optionIndex recoveryOptionIndex: Int, 
>>> resultHandler handler: (Bool) -> Swift.Void)
>>> 
>>> /// Attempt to recover from this error when the user selected the
>>> /// option at the given index. Returns true to indicate
>>> /// successful recovery, and false otherwise.
>>> ///
>>> /// This entry point is used for recovery of errors handled at
>>> /// the "application" granularity, where nothing else in the
>>> /// application can proceed until the attempted error recovery
>>> /// completes.
>>> public func attemptRecovery(optionIndex recoveryOptionIndex: Int) -> 
>>> Bool
>>> }
>>> 
>>> As you can see, there are two attemptRecovery methods. In my mind the first 
>>> one was meant to be used for asynchronous operations, where you run some 
>>> recovering code in background and then report its result back to the caller.
>>> 
>>> The problem is that the handler is not marked as @escaping and as such it 
>>> can only be used inside the body of attemptRecovery. I was wondering if 
>>> this was an oversight from the stdlib team or if this was a deliberate 
>>> design decision.
>>> 
>>> I just saw that the method is still not marked as @escaping in master 
>>> (https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift#L105
>>>  
>>> ),
>>>  so I’d like to know what its intended use case is, since the obvious one 
>>> (asynchronous recovery) is prevented by the missing annotation.
>>> 
>>> Thanks,
>>> Elia Cereda
>>> 
 Il giorno 28 mar 2017, alle ore 17:33, Dennis Weissmann 
 > ha scritto:
 
 Hey Elia,
 
 I'm currently on mobile and don't really know what you're talking about 
 (what is RecoverableError?) but you say it's a block, and if the closure 
 is optional, it is @escaping by default.
 
 Did you see 
 https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003185.html
  
 
 
 - Dennis
 
 Sent from my iPhone
 
 On 23. Mar 2017, at 10:07 AM, Elia Cereda via swift-users 
 > wrote:
 
> I'd like to bump this issue, since it has been some time and it hasn't 
> been addressed.
> 
> Thanks,
> Elia Cereda
> 
> Il giorno 03 mar 2017, alle ore 21:33, Elia Cereda  > ha scritto:
> 
>> I’m wondering why the resultHandler block on 
>> RecoverableError.attemptRecovery(optionIndex, resultHandler:) is not 
>> marked @escaping?
>> 
>> I’m trying to invoke some recovering code that executes asynchronously, 
>> then reports if it was successful or not and I thought that this was the 
>> right strategy. As far as I can tell, without 

Re: [swift-users] Asynchronous error recovering with RecoverableError

[Michael Ilseman via swift-users]

CC Doug Gregor, who git blame tells me wrote this part.

Doug, this slightly predates noescape-by-default. Is this a bug or as intended?


> On Mar 28, 2017, at 8:49 AM, Elia Cereda via swift-users 
>  wrote:
> 
> Hi Dennis,
> 
> Thanks for your answer. I can see that my message needs some more context: 
> RecoverableError is a protocol in the standard library that can be 
> implemented to opt in to the error recovery mechanism available on macOS. 
> attemptRecovery(optionIndex, resultHandler:) is one of the methods that have 
> to be implemented to conform to the protocol.
> 
> Here you can find the other ones:
> 
> /// Describes an error that may be recoverable by presenting several
> /// potential recovery options to the user.
> public protocol RecoverableError : Error {
> 
> /// Provides a set of possible recovery options to present to the user.
> public var recoveryOptions: [String] { get }
> 
> /// Attempt to recover from this error when the user selected the
> /// option at the given index. This routine must call handler and
> /// indicate whether recovery was successful (or not).
> ///
> /// This entry point is used for recovery of errors handled at a
> /// "document" granularity, that do not affect the entire
> /// application.
> public func attemptRecovery(optionIndex recoveryOptionIndex: Int, 
> resultHandler handler: (Bool) -> Swift.Void)
> 
> /// Attempt to recover from this error when the user selected the
> /// option at the given index. Returns true to indicate
> /// successful recovery, and false otherwise.
> ///
> /// This entry point is used for recovery of errors handled at
> /// the "application" granularity, where nothing else in the
> /// application can proceed until the attempted error recovery
> /// completes.
> public func attemptRecovery(optionIndex recoveryOptionIndex: Int) -> Bool
> }
> 
> As you can see, there are two attemptRecovery methods. In my mind the first 
> one was meant to be used for asynchronous operations, where you run some 
> recovering code in background and then report its result back to the caller.
> 
> The problem is that the handler is not marked as @escaping and as such it can 
> only be used inside the body of attemptRecovery. I was wondering if this was 
> an oversight from the stdlib team or if this was a deliberate design decision.
> 
> I just saw that the method is still not marked as @escaping in master 
> (https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift#L105
>  
> ),
>  so I’d like to know what its intended use case is, since the obvious one 
> (asynchronous recovery) is prevented by the missing annotation.
> 
> Thanks,
> Elia Cereda
> 
>> Il giorno 28 mar 2017, alle ore 17:33, Dennis Weissmann 
>> > ha scritto:
>> 
>> Hey Elia,
>> 
>> I'm currently on mobile and don't really know what you're talking about 
>> (what is RecoverableError?) but you say it's a block, and if the closure is 
>> optional, it is @escaping by default.
>> 
>> Did you see 
>> https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003185.html
>>  
>> 
>> 
>> - Dennis
>> 
>> Sent from my iPhone
>> 
>> On 23. Mar 2017, at 10:07 AM, Elia Cereda via swift-users 
>> > wrote:
>> 
>>> I'd like to bump this issue, since it has been some time and it hasn't been 
>>> addressed.
>>> 
>>> Thanks,
>>> Elia Cereda
>>> 
>>> Il giorno 03 mar 2017, alle ore 21:33, Elia Cereda >> > ha scritto:
>>> 
 I’m wondering why the resultHandler block on 
 RecoverableError.attemptRecovery(optionIndex, resultHandler:) is not 
 marked @escaping?
 
 I’m trying to invoke some recovering code that executes asynchronously, 
 then reports if it was successful or not and I thought that this was the 
 right strategy. As far as I can tell, without @escaping that method loses 
 all it’s purpose and becomes essentially equivalent to 
 attemptRecovery(optionIndex:).
 
 So, I’d like to ask.
 1. Is it a bug or that method is non-escaping on purpose?
 2. If it is a bug, is there a workaround that can be applied pending a fix 
 in a future version of Swift?
 3. If it was a deliberate decision, what's the supported method of 
 asynchronously invoking error recovery code?
 
 Seeing that this wasn’t changed in Xcode 8.3b2, I think it unlikely that 
 this was an oversight.
 
 Thanks,
 Elia Cereda
 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org 
>>> 

Re: [swift-users] Importing C system libraries

[Michael Ilseman via swift-users]

Sure! In this example, I have built libgit2. I have a directory called Git, and 
inside that I have the following module map:

module Git [system] {
   header "/libgit2/include/git2.h"
   export *
}

When I run, I use:

swift -I  -L  -lgit2 foo.swift

inside foo.swift I can:

import Git
// … use libGit2


Read more about how to write a more appropriate module.map file for your 
purposes at https://clang.llvm.org/docs/Modules.html 
. For example, you might be able to 
define link flags inside the module.map, use umbrella directories, submodules, 
etc.



> On Mar 28, 2017, at 6:27 AM, Kelvin Ma  wrote:
> 
> Can you give an example?
> 
> On Mon, Mar 27, 2017 at 3:59 PM, Michael Ilseman  > wrote:
> Sure. At a low level, you can create a module.map file and use -L/-l flags in 
> your invocation of Swift. If you want to do so at a higher level, then 
> perhaps SwiftPM can. CCing swift-build-dev for the SwiftPM part.
> 
> 
> > On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users 
> > > wrote:
> >
> > Idk if this has been asked before, but is there a way to import C libraries 
> > into a Swift project without creating a local git repo? Preferably 
> > something similar to C where you can just `#include` headers and then 
> > specify the link flags (in Package.swift?)
> >
> > It’s getting very cumbersome to make a bunch of empty git repos just to use 
> > libglfw or libcairo.
> > ___
> > 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] Importing C system libraries

[Michael Ilseman via swift-users]

I don’t know what you’re referring to, but my solution also works for 
pre-open-source versions of Swift.

> On Mar 27, 2017, at 2:10 PM, Jan Neumüller <na...@slayers.de> wrote:
> 
> Is it just me, or is Swift moving to much in a command line direction since 
> the open sourcing? I feel being left behind as an Xcode user...
> 
> Jan
> 
>> On 27 Mar 2017, at 22:59, Michael Ilseman via swift-users 
>> <swift-users@swift.org> wrote:
>> 
>> Sure. At a low level, you can create a module.map file and use -L/-l flags 
>> in your invocation of Swift. If you want to do so at a higher level, then 
>> perhaps SwiftPM can. CCing swift-build-dev for the SwiftPM part.
>> 
>> 
>>> On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>> Idk if this has been asked before, but is there a way to import C libraries 
>>> into a Swift project without creating a local git repo? Preferably 
>>> something similar to C where you can just `#include` headers and then 
>>> specify the link flags (in Package.swift?) 
>>> 
>>> It’s getting very cumbersome to make a bunch of empty git repos just to use 
>>> libglfw or libcairo.
>>> ___
>>> 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] Importing C system libraries

[Michael Ilseman via swift-users]

Sure. At a low level, you can create a module.map file and use -L/-l flags in 
your invocation of Swift. If you want to do so at a higher level, then perhaps 
SwiftPM can. CCing swift-build-dev for the SwiftPM part.


> On Mar 26, 2017, at 3:20 PM, Kelvin Ma via swift-users 
>  wrote:
> 
> Idk if this has been asked before, but is there a way to import C libraries 
> into a Swift project without creating a local git repo? Preferably something 
> similar to C where you can just `#include` headers and then specify the link 
> flags (in Package.swift?) 
> 
> It’s getting very cumbersome to make a bunch of empty git repos just to use 
> libglfw or libcairo.
> ___
> 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] Airbnb's Swift 3 Migration Blog

[Michael Ilseman via swift-users]

> On Feb 7, 2017, at 4:58 PM, Chengyin Liu  wrote:
> 
> Thanks for the feedback! 
> 
> > This is probably source-compatibility that you want, not necessarily ABI 
> > compatibility.
> 
> You are right. Thank you for the correction.
> 
> > BTW, are you mixed-source? If so, were you able to try out PCH for bridging 
> > headers as identified here: https://swift.org/blog/bridging-pch/? 
> > 
> 
> We are. We are excited with PCH but currently compiler fails with segfault 
> using Xcode 8.3b2 for us. We are still investigating to provide the best info 
> there.
> 
> > If you can produce a test case that repros the blowup, can you put that in 
> > a JIRA?
> 
> Filed: http://bugs.swift.org/browse/SR-3892 
> . Notably this function builds even 
> slower with 3.1. (2.3: 0.6s → 3.0: 12s → 3.1: 22s)
> 

Thanks. It seems like it’s the closure argument to map specifically that needs 
an annotation (see comment in SR).

> > “Near misses” on Optional Protocol Method Implementations
> 
> I don't think those are actual bugs. From a compiler standpoint, the code is 
> fine. We did hit another issue with protocol near miss that may count as a 
> compiler issue. I will try to create a reproducible case.
> 

They’re not bugs, but near-miss detection is a major quality-of-life 
improvement that the compiler should be better at. It falls under the general 
category of having better and more helpful diagnostics.

> On Tue, Feb 7, 2017 at 2:44 PM Michael Ilseman  > wrote:
> Comments:
> 
> > Since the Swift ABI changed between versions 2 and 3, even correct Swift 3 
> > code that imports Swift 2 libraries will not compile. This incompatibility 
> > made it difficult to parallelize code conversion.
> 
> This is probably source-compatibility that you want, not necessarily ABI 
> compatibility. Even if the ABI was stable, you still want to use the decls 
> from the other module, and thus you’d still be in a rough spot. But, with 
> source compatibility in Swift 4, the other modules could remain written in an 
> older syntax/semantics while being compiled with the new compiler (and thus 
> the new ABI). This would mean a gentle module-by-module incremental 
> conversion regardless of the ABI for a Swift 3 to Swift 4 conversion.
> 
> > Debug Build Time
> 
> BTW, are you mixed-source? If so, were you able to try out PCH for bridging 
> headers as identified here: https://swift.org/blog/bridging-pch/? 
> 
> 
> > However, we did find a function...
> 
> If you can produce a test case that repros the blowup, can you put that in a 
> JIRA?
> 
> > So, to complete the Swift 3 migration we strongly encouraged the entire 
> > team (minus the ones doing the migration) to really, truly take a Saturday 
> > off work .
> 
> Sounds like some good came of it after all!
> 
> > “Near misses” on Optional Protocol Method Implementations
> 
> These are great JIRA fodder too!
> 
> 
> 
> 
> 
>> On Feb 7, 2017, at 1:35 PM, Chengyin Liu via swift-users 
>> > wrote:
>> 
> 
>> Hi all,
>> 
>> At Airbnb we recently migrated to Swift 3, just in time for Xcode 8.3. We 
>> waited as long as possible because our codebase is massive. We have hundreds 
>> thousands lines of Swift.
>> 
>> In the end we were able to migrate without a code freeze. 3 engineers worked 
>> on it for 3 weeks without disrupting the normal development.
>> 
>> We shared our experience in this blog post: 
>> https://medium.com/airbnb-engineering/getting-to-swift-3-at-airbnb-79a257d2b656#.j800yp6l8
>>  
>> 
>> 
>> Feel free to reach out if you have any questions!
>> -- 
>> Chengyin
> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
> 
> -- 
> Chengyin

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

Re: [swift-users] Airbnb's Swift 3 Migration Blog

[Michael Ilseman via swift-users]

Comments:

> Since the Swift ABI changed between versions 2 and 3, even correct Swift 3 
> code that imports Swift 2 libraries will not compile. This incompatibility 
> made it difficult to parallelize code conversion.

This is probably source-compatibility that you want, not necessarily ABI 
compatibility. Even if the ABI was stable, you still want to use the decls from 
the other module, and thus you’d still be in a rough spot. But, with source 
compatibility in Swift 4, the other modules could remain written in an older 
syntax/semantics while being compiled with the new compiler (and thus the new 
ABI). This would mean a gentle module-by-module incremental conversion 
regardless of the ABI for a Swift 3 to Swift 4 conversion.

> Debug Build Time

BTW, are you mixed-source? If so, were you able to try out PCH for bridging 
headers as identified here: https://swift.org/blog/bridging-pch/?

> However, we did find a function...

If you can produce a test case that repros the blowup, can you put that in a 
JIRA?

> So, to complete the Swift 3 migration we strongly encouraged the entire team 
> (minus the ones doing the migration) to really, truly take a Saturday off 
> work .

Sounds like some good came of it after all!

> “Near misses” on Optional Protocol Method Implementations

These are great JIRA fodder too!




> On Feb 7, 2017, at 1:35 PM, Chengyin Liu via swift-users 
>  wrote:
> 
> Hi all,
> 
> At Airbnb we recently migrated to Swift 3, just in time for Xcode 8.3. We 
> waited as long as possible because our codebase is massive. We have hundreds 
> thousands lines of Swift.
> 
> In the end we were able to migrate without a code freeze. 3 engineers worked 
> on it for 3 weeks without disrupting the normal development.
> 
> We shared our experience in this blog post: 
> https://medium.com/airbnb-engineering/getting-to-swift-3-at-airbnb-79a257d2b656#.j800yp6l8
>  
> 
> 
> Feel free to reach out if you have any questions!
> -- 
> Chengyin
> ___
> 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] FUSE module for swift

[Michael Ilseman via swift-users]

To pass in the option to Clang, use -Xcc instead of -Xswiftc, like:

swift test -Xswiftc -DFUSE_USE_VERSION=25 -Xcc -D_FILE_OFFSET_BITS=64

As far as in the module map file, I don’t know if that’s supported[1]. You 
might be able to make your own header that defines it before including fuse.h, 
and use that for your module.

[1] http://clang.llvm.org/docs/Modules.html

> On Jan 5, 2017, at 3:30 PM, Dennis Schafroth via swift-users 
>  wrote:
> 
> I am having trouble using this C API due to use of some build defines, but I 
> could be doing it wrong.
> 
> Current trying to compile a test it on macOS with the following modules.map:
> 
> module CFuseLinux [system] {
> header "/usr/include/fuse.h"
> link "fuse"
> export *
> }
> 
> module COSXFuse [system] {
> header "/usr/local/include/fuse.h"
> link "libfuse"
> export *
> }
> 
> module CFuseBrew [system] {
> header "/usr/local/include/fuse/fuse.h"
> link "libfuse"
> export *
> }
> 
> 
> Having a test case that simply tries to import the CFuseBrew one:
> 
> #if os(Linux) 
> import CFuseLinux
> #else
> import CFuseBrew
> #endif
> 
> using the following command:
> 
> swift test -Xswiftc -DFUSE_USE_VERSION=25 -Xswiftc -D_FILE_OFFSET_BITS=64
> 
> But it does not seem that the defines has the effect I want since it fails 
> with: 
> 
> :1:9: note: in file included from :1:
> #import "/usr/local/include/fuse/fuse.h"
> ^
> /usr/local/include/fuse/fuse.h:26:10: note: in file included from 
> /usr/local/include/fuse/fuse.h:26:
> #include "fuse_common.h"
>  ^
> /usr/local/include/fuse/fuse_common.h:32:2: error: Please add 
> -D_FILE_OFFSET_BITS=64 to your compile flags!
> #error Please add -D_FILE_OFFSET_BITS=64 to your compile flags!
>  ^
> :1:9: note: in file included from :1:
> #import "/usr/local/include/fuse/fuse.h"
> ^
> /usr/local/include/fuse/fuse.h:26:10: note: in file included from 
> /usr/local/include/fuse/fuse.h:26:
> #include "fuse_common.h"
>  ^
> /usr/local/include/fuse/fuse_common.h:271:8: error: On Darwin API version 25 
> or greater must be used
> #error On Darwin API version 25 or greater must be used
>  ^
> /Users/dennis/Projects/cfuse/Tests/CFuseTests/first.swift:5:8: error: could 
> not build Objective-C module 'CFuseBrew'
> import CFuseBrew
> 
> What am I doing wrong? Is it possible to define build options in modules.map? 
> The project can be found at https://github.com/schafdog/cfuse 
> 
> 
> cheers,
> :-Dennis
> ___
> 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] Updating C-wrapper to Swift 3

[Michael Ilseman via swift-users]

> On Sep 28, 2016, at 10:03 AM, John Brownie via swift-users 
>  wrote:
> 
> Thanks for the pointers. Good reading, but I'm still confused. I think that 
> the first issue is clear to me now, but I don't know what I have to do to 
> make the closure be seen as satisfying the type of the function pointer. It 
> worked in Swift 2.2 as
> 
> XML_SetEndElementHandler(parser) { (userData: 
> UnsafeMutablePointer, name: UnsafePointer) -> Void in
> 
> All that's changed is making the UnsafeMutablePointer into 
> UnsafeMutableRawPointer, unless it's the unwrapped nature of the parameter in 
> the error message:
> 
> Cannot convert value of type '(UnsafeMutableRawPointer, 
> UnsafePointer) -> Void' to expected argument type 
> 'XML_EndElementHandler!' 
> 
> I don't know what I need to do next. Any help is much appreciated.


Could you share the generated interface for these functions, so that we can see 
how they are being imported into Swift? Also, do you know exactly what version 
of the Swift compiler you’re using (I ask because there have been recent 
improvements in error messages)?
>> Quinn "The Eskimo!" via swift-users   28 
>> September 2016 at 11:26
>> 
>> I recommend reading the whole “Migrating to Swift 2.3 or Swift 3 from Swift 
>> 2.2” doc, but for this specific issue you should start with the 
>> “UnsafeRawPointer Migration” doc that it links to.
>> 
>>  
>> 
>>  
>> 
>> 
>> Share and Enjoy
>> --
>> Quinn "The Eskimo!"   
>> 
>> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> 
>> John Brownie   28 September 2016 at 9:29
>> I have a Swift wrapper for the expat XML parser, and I just went through the 
>> update to Swift 3, and I'm thrown a series of errors that mostly appear to 
>> be of two types. Here is a representative function of the first type: 
>> 
>> func parse() throws { 
>> var done = false 
>> while !done { 
>> let buffer: UnsafeMutablePointer = XML_GetBuffer(parser, 
>> Int32(bufsize)) 
>> if buffer == nil { 
>> let errorCode = XML_GetErrorCode(parser) 
>> throw ExpatError(reason: "Error \(errorCode), 
>> \(XML_ErrorString(errorCode))") 
>> } 
>> let bytesRead = readData(UnsafeMutablePointer(buffer), 
>> bufferLength: bufsize) 
>> done = bytesRead < bufsize 
>> if XML_ParseBuffer(parser, Int32(bytesRead), Int32(done ? 1 : 
>> 0)) != XML_STATUS_OK { 
>> let errorCode = XML_GetErrorCode(parser) 
>> throw ExpatError(reason: "Error \(errorCode), 
>> \(XML_ErrorString(errorCode))") 
>> } 
>> } 
>> } 
>> 
>> Xcode 8's migrator changed the declaration of buffer to 
>> UnsafeMutableRawPointer?, but the readData call gives an error: 
>> 
>> Cannot invoke initializer for type 'UnsafeMutablePointer' with an 
>> argument list of type '(UnsafeMutableRawPointer?)' 
>> Pointer conversion restricted: use '.assumingMemoryBound(to:)' or 
>> '.bindMemory(to:capacity:)' to view memory as a type. 
>> Overloads for 'UnsafeMutablePointer' exist with these partially 
>> matching parameter lists: (RawPointer), (OpaquePointer), (OpaquePointer?), 
>> (UnsafeMutablePointer), (UnsafeMutablePointer?) 
>> 
>> Where can I read up on how to make the conversion? My initial effort is: 
>> 
>> let bytesRead = readData(buffer!.bindMemory(to: UInt8.self, 
>> capacity: bufsize), bufferLength: bufsize) 
>> 
>> That's more or less thrashing around with no real understanding. 
>> 
>> The second type is turning a closure into the appropriate C function 
>> pointer. For example: 
>> 
>> XML_SetEndElementHandler(parser) { (userData: 
>> UnsafeMutableRawPointer, name: UnsafePointer) -> Void in 
>> let theParser = unsafeBitCast(userData, to: ExpatSwift.self) 
>> let theName = ExpatSwift.getString(name) 
>> theParser.endElement(theName) 
>> } 
>> 
>> This gets an error: 
>> 
>> Cannot convert value of type '(UnsafeMutableRawPointer, 
>> UnsafePointer) -> Void' to expected argument type 
>> 'XML_EndElementHandler!' 
>> 
>> XML_EndElementHandler is defined as: 
>> 
>> typedef void (XMLCALL *XML_EndElementHandler) (void *userData, 
>>const XML_Char *name); 
>> 
>> Here I have no real clue as to how to fix it. 
>> 
>> So, 

Re: [swift-users] @escaping may only be applied to parameters of function type

[Michael Ilseman via swift-users]

> On Sep 13, 2016, at 8:16 PM, Michael Ilseman via swift-users 
> <swift-users@swift.org> wrote:
> 
> 
>> On Sep 13, 2016, at 8:14 PM, Rick Mann <rm...@latencyzero.com> wrote:
>> 
>> But the Apple declaration (accessible via Xcode) of the method it's based on 
>> looks like this:
>> 
>> open func enumerator(at url: URL,
>>   includingPropertiesForKeys keys: [URLResourceKey]?,
>>   options mask: FileManager.DirectoryEnumerationOptions = [],
>>   errorHandler handler: (@escaping (URL, Error) -> Bool)? = nil)
>>   -> FileManager.DirectoryEnumerator?
>> 
>> handler is optional, but has @escaping. Is this an artifact of how Xcode 
>> presents system header files?
>> 
> 
> That’s certainly funky. Might be that or a bug in the AST printer.
> 

Definitely a bug in the AST printer

>> 
>>> On Sep 13, 2016, at 20:11 , Michael Ilseman <milse...@apple.com> wrote:
>>> 
>>> TL;DR: The optional is already escaping, due to the fact that “T?" is sugar 
>>> for Optional, and the noescape-by-default rule only applies to types in 
>>> immediate parameter position. Current Swift master has much better 
>>> diagnostics for this case.
>>> 
>>> There is not currently a general solution involving escapability of closure 
>>> types used a generic parameters or tuple members, though such a thing would 
>>> be useful in Swift 4.
>>> 
>>>> On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users 
>>>> <swift-users@swift.org> wrote:
>>>> 
>>>> The following is the earlier thread I was talking about. 
>>>> 
>>>> [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping 
>>>> 
>>>> -Shawn
>>>> 
>>>> On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson <shaw...@gmail.com> wrote:
>>>> I hit this issue as well. I had an early email on this list regarding do 
>>>> this topic, not in a situation to search for it. It is a short coming in 
>>>> how escaping can be applied to things like optional closures.
>>>> 
>>>> I was in the process of authoring an email for swift evolution about it 
>>>> and haven't yet gotten around to filing a defect about it.
>>>> 
>>>> -Shawn
>>>> On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users 
>>>> <swift-users@swift.org> wrote:
>>>> I'm trying to write this function. The errorHandler: parameter is modeled 
>>>> after the NSFileManager enumerate() function. If I include the @escaping 
>>>> you see there, I get the error "@escaping may only be applied to 
>>>> parameters of function type".
>>>> 
>>>> The second parameter, iterator:, seems to have no problems with @escaping.
>>>> 
>>>> func
>>>> iterate(directory inURL: URL?,
>>>>   includingPropertiesForKeys: [URLResourceKey]? = nil,
>>>>   options: FileManager.DirectoryEnumerationOptions = [],
>>>>   errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? = nil,
>>>>   iterator inIterator: (@escaping (URL) throws -> ())) rethrows
>>>> {
>>>> }
>>>> 
>>>> I'm not sure why I can't apply @escaping here. Can anyone enlighten me? 
>>>> Thank you.
>>>> 
>>>> --
>>>> Rick Mann
>>>> rm...@latencyzero.com
>>>> 
>>>> 
>>>> ___
>>>> 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
>>> 
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
> 
> ___
> 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] @escaping may only be applied to parameters of function type

[Michael Ilseman via swift-users]

> On Sep 13, 2016, at 8:37 PM, Shawn Erickson  wrote:
> 
> I am in the process of updating to Xcode 8 release so I can't confirm at the 
> moment but I am fairly sure I hit a situation with being asked to implement a 
> func from a protocol that got autocompleted with @escape nested as shown. It 
> would then of course complain that wasn't valid. If I fixed it I don't think 
> it was considered being implemented (it could only be an issue as noted in my 
> prior thread related to default implementation not being picked up).
> 
> I will start a discussion about @escaping on the evolution list (hopefully 
> soon). The main issue I see – beyond quirks like this – is that the proposal 
> stated that closures would become noescape by default.

Link for those following along at home: 
https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md

Practically every occurrence of the word “closure” is immediately proceeded by 
“argument” or “argument to function”. Thus, it does not apply to stored members 
of structs, enum payloads, etc. I don’t like this either, but that is the 
current situation. Additionally, withoutActuallyEscaping is not implemented yet 
either, though I am looking into that.

This gets muddy and non-intuitive very quickly, especially with syntactic sugar 
and the overall prevalence of optionals (especially when importing from ObjC!). 
In a pure Swift world, the most effective workaround (though I haven’t tested 
this myself) if one wants non-escaping optional closure arguments, is to use 
function overloading for the interface, but that’s not particularly fun 
(although withoutActuallyEscaping could help a tiny bit). In a mixed world, 
there is outright breakage around the seams, and I’m investigating what all the 
issues there are (I suspect many are compiler bugs, rather than language bugs).

I would be in favor (and can help you champion) an escaping rule that 
propagates through generic parameters and non-nominal-type members. 

> I had existing code that applied @noescape against optional closures as well 
> as tuples with closures, etc. which was happy and appeared to honor 
> @noescape. I had expected closures in all "constructs" to be considered 
> noescape after this change (what I got from reading the proposal) however in 
> some situations they are considered escaping now when in fact in the past 
> @noescape was able to be applied to state otherwise. It is possible that 
> @noescape wasn't actually doing anything in those cases but it seemed like it 
> was working to me.
> 
> So now I have code that I can't make work since it was meant to be noescape 
> yet it is now considered escaping implicitly. If I try to fix this code I get 
> complaints about things expected to escape and/or things needed to not escape 
> (hard to explain with examples). I can likely rework the code to get it 
> working again but expect to lose some of the desired implementation.
> 
> -Shawn
> 
> On Tue, Sep 13, 2016 at 8:16 PM Michael Ilseman  > wrote:
> 
> > On Sep 13, 2016, at 8:14 PM, Rick Mann  > > wrote:
> >
> > But the Apple declaration (accessible via Xcode) of the method it's based 
> > on looks like this:
> >
> > open func enumerator(at url: URL,
> >includingPropertiesForKeys keys: [URLResourceKey]?,
> >options mask: FileManager.DirectoryEnumerationOptions = [],
> >errorHandler handler: (@escaping (URL, Error) -> Bool)? = nil)
> >-> FileManager.DirectoryEnumerator?
> >
> > handler is optional, but has @escaping. Is this an artifact of how Xcode 
> > presents system header files?
> >
> 
> That’s certainly funky. Might be that or a bug in the AST printer.
> 
> >
> >> On Sep 13, 2016, at 20:11 , Michael Ilseman  >> > wrote:
> >>
> >> TL;DR: The optional is already escaping, due to the fact that “T?" is 
> >> sugar for Optional, and the noescape-by-default rule only applies to 
> >> types in immediate parameter position. Current Swift master has much 
> >> better diagnostics for this case.
> >>
> >> There is not currently a general solution involving escapability of 
> >> closure types used a generic parameters or tuple members, though such a 
> >> thing would be useful in Swift 4.
> >>
> >>> On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users 
> >>> > wrote:
> >>>
> >>> The following is the earlier thread I was talking about.
> >>>
> >>> [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping
> >>>
> >>> -Shawn
> >>>
> >>> On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson  >>> > wrote:
> >>> I hit this issue as well. I had an early email on this list regarding do 
> >>> this topic, not in a situation to search for it. It is a short coming in 
> >>> how escaping can be applied 

Re: [swift-users] @escaping may only be applied to parameters of function type

[Michael Ilseman via swift-users]

> On Sep 13, 2016, at 8:14 PM, Rick Mann  wrote:
> 
> But the Apple declaration (accessible via Xcode) of the method it's based on 
> looks like this:
> 
> open func enumerator(at url: URL,
>includingPropertiesForKeys keys: [URLResourceKey]?,
>options mask: FileManager.DirectoryEnumerationOptions = [],
>errorHandler handler: (@escaping (URL, Error) -> Bool)? = nil)
>-> FileManager.DirectoryEnumerator?
> 
> handler is optional, but has @escaping. Is this an artifact of how Xcode 
> presents system header files?
> 

That’s certainly funky. Might be that or a bug in the AST printer.

> 
>> On Sep 13, 2016, at 20:11 , Michael Ilseman  wrote:
>> 
>> TL;DR: The optional is already escaping, due to the fact that “T?" is sugar 
>> for Optional, and the noescape-by-default rule only applies to types in 
>> immediate parameter position. Current Swift master has much better 
>> diagnostics for this case.
>> 
>> There is not currently a general solution involving escapability of closure 
>> types used a generic parameters or tuple members, though such a thing would 
>> be useful in Swift 4.
>> 
>>> On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users 
>>>  wrote:
>>> 
>>> The following is the earlier thread I was talking about. 
>>> 
>>> [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping 
>>> 
>>> -Shawn
>>> 
>>> On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson  wrote:
>>> I hit this issue as well. I had an early email on this list regarding do 
>>> this topic, not in a situation to search for it. It is a short coming in 
>>> how escaping can be applied to things like optional closures.
>>> 
>>> I was in the process of authoring an email for swift evolution about it and 
>>> haven't yet gotten around to filing a defect about it.
>>> 
>>> -Shawn
>>> On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users 
>>>  wrote:
>>> I'm trying to write this function. The errorHandler: parameter is modeled 
>>> after the NSFileManager enumerate() function. If I include the @escaping 
>>> you see there, I get the error "@escaping may only be applied to parameters 
>>> of function type".
>>> 
>>> The second parameter, iterator:, seems to have no problems with @escaping.
>>> 
>>> func
>>> iterate(directory inURL: URL?,
>>>includingPropertiesForKeys: [URLResourceKey]? = nil,
>>>options: FileManager.DirectoryEnumerationOptions = [],
>>>errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? = nil,
>>>iterator inIterator: (@escaping (URL) throws -> ())) rethrows
>>> {
>>> }
>>> 
>>> I'm not sure why I can't apply @escaping here. Can anyone enlighten me? 
>>> Thank you.
>>> 
>>> --
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>>> ___
>>> 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
>> 
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 

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

Re: [swift-users] @escaping may only be applied to parameters of function type

[Michael Ilseman via swift-users]

TL;DR: The optional is already escaping, due to the fact that “T?" is sugar for 
Optional, and the noescape-by-default rule only applies to types in 
immediate parameter position. Current Swift master has much better diagnostics 
for this case.

There is not currently a general solution involving escapability of closure 
types used a generic parameters or tuple members, though such a thing would be 
useful in Swift 4.

> On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users 
>  wrote:
> 
> The following is the earlier thread I was talking about. 
> 
> [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping  
> 
> 
> -Shawn
> 
> On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson  > wrote:
> I hit this issue as well. I had an early email on this list regarding do this 
> topic, not in a situation to search for it. It is a short coming in how 
> escaping can be applied to things like optional closures.
> 
> I was in the process of authoring an email for swift evolution about it and 
> haven't yet gotten around to filing a defect about it.
> 
> -Shawn
> On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users 
> > wrote:
> I'm trying to write this function. The errorHandler: parameter is modeled 
> after the NSFileManager enumerate() function. If I include the @escaping you 
> see there, I get the error "@escaping may only be applied to parameters of 
> function type".
> 
> The second parameter, iterator:, seems to have no problems with @escaping.
> 
> func
> iterate(directory inURL: URL?,
> includingPropertiesForKeys: [URLResourceKey]? = nil,
> options: FileManager.DirectoryEnumerationOptions = [],
> errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? = nil,
> iterator inIterator: (@escaping (URL) throws -> ())) rethrows
> {
> }
> 
> I'm not sure why I can't apply @escaping here. Can anyone enlighten me? Thank 
> you.
> 
> --
> Rick Mann
> rm...@latencyzero.com 
> 
> 
> ___
> 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 3 (Xcode 8 GM) issue with @escaping

[Michael Ilseman via swift-users]

> On Sep 7, 2016, at 6:50 PM, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
> 
> On Wed, Sep 7, 2016 at 5:54 PM, Michael Ilseman via swift-users 
> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
> I implemented a better (i.e. correct) diagnostic message for this at 
> https://github.com/apple/swift/pull/4670 
> <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 
> <https://github.com/apple/swift/pull/4438> for imported function types; see 
> comment <https://github.com/apple/swift/pull/4438#issuecomment-243645367>.)
>  

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 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> I see https://bugs.swift.org/browse/SR-2324 
>> <https://bugs.swift.org/browse/SR-2324> and 
>> https://bugs.swift.org/browse/SR-2444 
>> <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 <shaw...@gmail.com 
>> <mailto:shaw...@gmail.com>> 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 <j...@jonshier.com 
>> <mailto:j...@jonshier.com>> 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 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> 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 <shaw...@gmail.com 
>>> <mailto:shaw...@gmail.com>> 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

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

[Michael Ilseman via swift-users]

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.

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)
>> }
>> 
>> // Happy
>> func foo2(bar: String, completion: MyCallback) {
>> completion(bar)
>> }
>> 
>> // Happy
>> func foo3(bar: String, completion: ((String)->())? = nil) {
>> completion?(bar)
>> }
>> 
>> // Happy
>> func foo4(bar: String, completion: MyCallback? = nil) {
>> completion?(bar)
>> }
>> 
>> // Happy
>> func foo5(bar: String, completion: Optional = nil) {
>> completion?(bar)
>> }
>> 
>> // Happy
>> func foo6(bar: String, completion: @escaping (String)->()) {
>> completion(bar)
>> }
>> 
>> // Happy
>> func foo7(bar: String, completion: @escaping MyCallback) {
>> completion(bar)
>> }
>> 
>> // Unhappy...
>> // "@escaping attribute only applies to function types"
>> func foo8(bar: String, completion: @escaping ((String)->())? = nil) {
>> completion?(bar)
>> }
>> 
>> // Unhappy...
>> // "@escaping attribute only applies to function types"
>> func foo9(bar: String, completion: @escaping MyCallback? = nil) {
>> completion?(bar)
>> }
>> 
>> // Unhappy...
>> // "@escaping attribute only applies to function types"
>> func foo10(bar: String, completion: (@escaping ((String)->()))? = nil) {
>> completion?(bar)
>> }
>> 
>> // Unhappy...
>> // "@escaping attribute only applies to function types"
>> func foo11(bar: String, completion: (@escaping MyCallback)? = nil) {
>> completion?(bar)
>> }
>> 
>> // Unhappy...
>> // "@escaping attribute only applies to function types"
>> func foo12(bar: String, completion: Optional<@escaping MyCallback> = nil) {
>> completion?(bar)
>> }
> 
>> ___
>> 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] Generate Swift interface from Objective-C file using clang

[Michael Ilseman via swift-users]

The best way I know of is the swift-ide-test tool, and you’ll see it being 
invoked by many of the ClangImporter tests.

> On Jul 6, 2016, at 10:45 AM, Ryan Wilson via swift-users 
>  wrote:
> 
> Hi everyone,
> 
> In Xcode, I can generate a Swift interface for an Objective-C file by using 
> the assistant editor and selecting "Generated Interface" from the menu of 
> what to display.  How would I go about generating this using the tools in the 
> Swift repo from GitHub? I've been digging around the code and have seen 
> ClangImporter but not sure if I'm looking for the right thing.
> 
> Thanks,
> Ryan
> ___
> 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] An OpenGL math library in pure Swift

[Michael Ilseman via swift-users]

> On Jan 4, 2016, at 7:11 PM, David Turnbull via swift-users 
>  wrote:
> 
> I've been working on a math library for SwiftGL. It's looking good. Vector2, 
> Vector3, Vector4, Matrix2x2, Matrix3x3, Matrix4x4 are implemented with all 
> arithmetic. You can even swizzle just like GLSL.
> 
> var myVec = vec4(1, 2, 3, 4)
> myVec.ab = vec2(99, 98)
> print(myVec) //=> (1, 2, 98, 99)
> 

This is pretty cool!

> There's still a lot to do. I hope to have feature parity with GLSL done this 
> week. But it's ready to set free and get feedback.
> 

What all is mean by “feature parity” with GLSL, given that GLSL is for 
authoring shaders intended to be ran on device (texture units, interpolation, 
fuzzy floating point math semantics, etc) and your library presumably is 
running on host? Do you plan on synthesizing shaders (warning: this may be a 
little bit tricker than it seems)?

> https://github.com/AE9RB/SwiftGL 
> 
> And a couple questions. Is there any way to make import SwiftGL.Math work? 
> Note the dot. Also, is there anything reasonable I can do to improve the 
> compile time? 3.5 minutes for 2000 lines of code can't be right.
> 
> -David "Expression was too complex to be solved" Turnbull
> 
>  ___
> 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