[swift-users] Importing C system libraries

[Kelvin Ma via swift-users]

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

Re: [swift-users] withoutActuallyEscaping example question

[Ray Fix via swift-users]

Wow.  Thanks for the explanation! I didn’t realize I was toggling between 
different overloads but that makes sense now.

Thanks again,
Ray

PS: It is sort of a strange example in the first place (being lazy and then 
immediately eager.)  I don’t think it is a use case that is compelling enough 
to consider overload resolution rules over.

> On Mar 26, 2017, at 1:21 AM, Slava Pestov  wrote:
> 
> Here’s another fun one: the following type checks despite the literal 
> closure; we’ve constrained the return type of filter() to [Int], and not 
> LazyFilterCollection, so again the type checker picks the overload that 
> takes the non-escaping closure:
> 
> func myFilter(array: [Int], predicate: (Int) -> Bool) -> [Int] {
>   return array.lazy.filter { predicate($0) }
> }
> 
> Slava
> 
>> On Mar 26, 2017, at 1:14 AM, Slava Pestov via swift-users 
>> > wrote:
>> 
>> Hi Ray,
>> 
>> There are two overloads of filter() available on ‘array.lazy’; the version 
>> that takes an escaping closure and returns a LazyFilterCollection, and the 
>> version that takes a non-escaping closure and returns [Int].
>> 
>> In the first example, we pick the LazyFilterCollection-returning overload, 
>> because the literal closure { predicate($0) } can be coerced to both an 
>> escaping or a non-escaping closure type, and in the absence of additional 
>> constraints we go with the overload from a concrete type over an overload in 
>> a protocol extension. After the overload has been picked we validate the 
>> body of the closure, and notice that it is invalid because whole the closure 
>> is already known to be @escaping, it references the non-@escaping 
>> ‘predicate’.
>> 
>> In the second example, ‘predicate’ is known to be non-@escaping, which rules 
>> out the first overload completely, so we go with the second overload and 
>> perform a non-lazy filter.
>> 
>> I would argue this is somewhat confusing, but it might be difficult to 
>> change the overload resolution rules in a way where the first overload is 
>> always chosen.
>> 
>> Slava
>> 
>>> On Mar 26, 2017, at 12:13 AM, Ray Fix via swift-users 
>>> > wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> One of the motivating examples for withoutActuallyEscaping looks like the 
>>> following.  This predictably  doesn’t work because "use of non-escaping 
>>> parameter 'predicate' may allow it to escape"
>>> 
>>> func myFilter(array: [Int], predicate: (Int) -> Bool) -> [Int] {
>>>   return Array(array.lazy.filter { predicate($0) })
>>> }
>>> 
>>> The solution is to use withoutActuallyEscaping.  This works and produces 
>>> the expected results.
>>> 
>>> func myFilter(array: [Int], predicate: (Int) -> Bool) -> [Int] {
>>>   return withoutActuallyEscaping(predicate) { predicate in
>>> Array(array.lazy.filter({predicate($0)}))
>>>   }
>>> }
>>> 
>>> What I find puzzling is the below example compiles and runs correctly. It 
>>> seems like it should be the same compiler error as in the first example.
>>> 
>>> func myFilter(array: [Int], predicate: (Int) -> Bool) -> [Int] {
>>>   return Array(array.lazy.filter(predicate))
>>> }
>>> 
>>> If you understand why this is so, it would be very helpful.
>>> 
>>> Thank you and best wishes,
>>> Ray
>>> ___
>>> 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] Why does this leak?

[Rick Aurbach via swift-users]

I have a situation where I have a leak that I do not understand. I would be 
very grateful if someone could explain it to me and offer an idea of how I can 
make the pattern work without leaking:

Consider two code snippets, the first of which leaks, while the second does not.

Case 1: This example leaks 2 32-byte objects..

in FontSelectorDialog.swift:
override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
switch segue.identifier! {
< ... >

case "ChooseTextColor" :
let target = segue.destination as! ColorChooser
target.textChooserType = .text  // <===
< ... >
}

case "ChooseBackgroundColor" :
let target = segue.destination as! ColorChooser
target.textChooserType = .bkgnd // <===
< ... >
}

default : break
}

in ColorChooser.swift:

internal enum ColorCat {// <===
case: .text // <===
case: .bkgnd// <===
}   // <===

internal class ColorChooser : UITableViewController {
internal var textChooserType : ColorCat = .text // <===
< ... >
}

Case 2: This example does not leak...

in FontSelectorDialog.swift:
override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
switch segue.identifier! {
< ...>

case "ChooseTextColor" :
let target = segue.destination as! ColorChooser
target.textChooserType = true   // <===
< ... >
}

case "ChooseBackgroundColor" :
let target = segue.destination as! ColorChooser
target.textChooserType = false  // <===
< ... >
}

default : break
}

in ColorChooser.swift:

internal class ColorChooser : UITableViewController {
internal var textChooserType : Bool = true  // <===
< ... >
}

Can someone explain why? And how can I implement this using an enum. I want to 
use an enum here because:
(a) it is easier to read and understand and seems more “swiftly”
(b) Someday, I may want to add additional options, which would be easy with an 
enum but difficult using the current (Bool) implementation.

Cheers,

Rick Aurbach

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