Re: [swift-users] Cannot pass immutable value as inout argument

[Jordan Rose via swift-users]

Oh no, you're right, I'm sorry. You can only do that with arrays at the moment. 
We do have a bug for this already.

Jordan


> On Jan 16, 2018, at 16:37, Roderick Mann  wrote:
> 
> Xcode can't properly parse the C header to show me the Swift signature, but 
> if I try calling it like this:
> 
>let p = lgs_notify_params_t(notify: lgs_notify_did_enter_background)
>lgs_notify(self.ctx, p)
> 
> I get this error:
> 
> Cannot convert value of type 'lgs_notify_params_t' to expected argument type 
> 'UnsafePointer!'
> 
> 
>> On Jan 16, 2018, at 13:22 , Jordan Rose  wrote:
>> 
>> You can do this if you don't write '&', which incorporates the caveat that 
>> you're not passing a stable address. But please file a bug anyway, because 
>> the diagnostic should tell you that!
>> 
>> Jordan
>> 
>> 
>>> On Jan 16, 2018, at 13:10, Rick Mann via swift-users 
>>>  wrote:
>>> 
>>> Is it not possible for Swift to treat C API const pointers as something 
>>> that can take let arguments?
>>> 
>>> 
>>> LGS_EXPORT bool lgs_notify(struct lgs_context_t* ctx, const 
>>> lgs_notify_params_t* params);
>>> .
>>> .
>>> .
>>> let p = lgs_notify_params_t(...)
>>> lgs_notify(self.ctx, )
>>>^Cannot pass immutable value as inout argument: 'p' is a 
>>> 'let' constant
>>> 
>>> 
>>> Why isn't the "const" in the C declaration enough to let Swift know it's 
>>> const and just allow it to be a let?
>>> 
>>> -- 
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>>> ___
>>> 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] Cannot pass immutable value as inout argument

[Jordan Rose via swift-users]

You can do this if you don't write '&', which incorporates the caveat that 
you're not passing a stable address. But please file a bug anyway, because the 
diagnostic should tell you that!

Jordan


> On Jan 16, 2018, at 13:10, Rick Mann via swift-users  
> wrote:
> 
> Is it not possible for Swift to treat C API const pointers as something that 
> can take let arguments?
> 
> 
> LGS_EXPORT bool lgs_notify(struct lgs_context_t* ctx, const 
> lgs_notify_params_t* params);
> .
> .
> .
> let p = lgs_notify_params_t(...)
> lgs_notify(self.ctx, )
> ^Cannot pass immutable value as inout argument: 'p' is a 
> 'let' constant
> 
> 
> Why isn't the "const" in the C declaration enough to let Swift know it's 
> const and just allow it to be a let?
> 
> -- 
> 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] TWISt-shout Newsletter 2018-01-15

[Jordan Rose via swift-users]

For posterity, I object to the phrasing "Swift arrays are not thread safe". The 
problem was that "globals are not (automatically) thread-safe". Arrays are no 
less thread safe than class references here.

Jordan


> On Jan 15, 2018, at 13:09, Kenny Leung via swift-users 
>  wrote:
> 
> Hi All.
> 
> Here is your TWISt-shout Newsletter for the week of 2018-01-08 to 2018-01-14
> 
> https://github.com/pepperdog/TWISt-shout/blob/master/2018/TWISt-shout-2018-01-15.md
>  
> 
> 
> Enjoy!
> 
> -Kenny
> 
> 
> ___
> 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] Override Lazy Stored Property

[Jordan Rose via swift-users]

Ah, to be clear, it's not that stored properties can't be overridden, it's that 
the override can't introduce new storage. (I think you got that, but didn't 
want a passerby to be confused.)

Jordan


> On Jan 12, 2018, at 09:09, John Buckley  wrote:
> 
> Hi Jordan,
> 
> Thanks for the explanation - much appreciated.
> 
> It's a shame stored properties can't be overridden, but I can see how there 
> are issues around observers etc.
> 
> For now I've switched to a private backing property and a factory method, 
> similar to what you suggested.
> 
> John
> 
> On Thu, 11 Jan 2018 at 18:51 Jordan Rose  > wrote:
> This isn’t supposed to be supported, and you get a warning for it in Swift 
> 4.1 (see SR-6165 ). I mentioned this 
> in the fix:
> 
>> Arguably we could allow overriding with a stored property. The original 
>> concerns were that you could accidentally end up with extra storage you 
>> didn't need, and that observing accessors would behave differently based on 
>> whether or not the property was overriding. But there's at least no 
>> ambiguity for 'lazy', which can't have observing accessors today.
> 
> If you want to get this behavior, you can make a second private lazy 
> property, and override the public property with a getter that just forwards 
> to the lazy property.
> 
> Sorry for the confusion!
> Jordan
>> On Jan 11, 2018, at 02:56, John Buckley via swift-users 
>> > wrote:
>> 
> 
>> I'm interested to know if overriding a lazy stored property in a sub-class 
>> is recommended or not. For example:
>> 
>> class CustomSegue: NSStoryboardSegue {
>> lazy var animator: CustomAnimator()
>> 
>> override func prepare() {
>>  
>> }
>> }
>> 
>> class CustomSlideRightSegue: CustomSegue {
>>  override lazy var animator: CustomAnimator(.slideRight)
>> }
>> 
>> This works fine and the compiler does not complain. However:
>> 
>> 1. Why is overriding lazy stored properties supported, while overriding a 
>> non-lazy stored property is not.
>> 
>> 2. Is this behaviour intended and/or recommended.
>> 
>> 3. I realise you can achieve the same result by overriding init in the 
>> sub-class and assigning to a non-lazy property, however often this reduces 
>> clarity and introduces un-necessary boiler-plate code (especially if init 
>> takes a number of args).
>> 
>> Thanks!
>> 
>> John
> 
>> ___
>> 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] KeyPaths and PartialKeyPaths - when can you leave out the class?

[Jordan Rose via swift-users]

I'm not sure whether it was supposed to be supported or not, but either way 
it's a reasonable feature request. Please file at bugs.swift.org.

Jordan


> On Jan 11, 2018, at 14:41, Kenny Leung via swift-users 
>  wrote:
> 
> Hi All.
> 
> I’d like to be lazy and leave out the classname on a key path whenever 
> possible. I thought that if PartialKeyPath was specified as the argument 
> type, that meant the compiler should be able to figure out what the class is, 
> but this does not seem to be the case.
> 
> Here’s an example that works.
> 
> class ThePath {
> var isWinding:Bool?
> }
> 
> func walk(aPath:T, forKey:PartialKeyPath) {
> }
> 
> func walkThePath(aPath:ThePath, forKey:PartialKeyPath) {
> }
> 
> func test() {
> let path = ThePath()
> walkThePath(aPath:path, forKey:\ThePath.isWinding)
> walk(aPath:path, forKey:\ThePath.isWinding)
> }
> 
> If you do this then it complains:
> 
> func test() {
> let path = ThePath()
> walkThePath(aPath:path, forKey:\.isWinding) // Expression type '()' is 
> ambiguous without more context
> walk(aPath:path, forKey:\.isWinding)// Type of expression is 
> ambiguous without more context
> }
> 
> Should I be able to do this?
> 
> Thanks!
> 
> -Kenny
> 
> ___
> 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] Override Lazy Stored Property

[Jordan Rose via swift-users]

This isn’t supposed to be supported, and you get a warning for it in Swift 4.1 
(see SR-6165 ). I mentioned this in the 
fix:

> Arguably we could allow overriding with a stored property. The original 
> concerns were that you could accidentally end up with extra storage you 
> didn't need, and that observing accessors would behave differently based on 
> whether or not the property was overriding. But there's at least no ambiguity 
> for 'lazy', which can't have observing accessors today.

If you want to get this behavior, you can make a second private lazy property, 
and override the public property with a getter that just forwards to the lazy 
property.

Sorry for the confusion!
Jordan


> On Jan 11, 2018, at 02:56, John Buckley via swift-users 
>  wrote:
> 
> I'm interested to know if overriding a lazy stored property in a sub-class is 
> recommended or not. For example:
> 
> class CustomSegue: NSStoryboardSegue {
> lazy var animator: CustomAnimator()
> 
> override func prepare() {
>  
> }
> }
> 
> class CustomSlideRightSegue: CustomSegue {
>  override lazy var animator: CustomAnimator(.slideRight)
> }
> 
> This works fine and the compiler does not complain. However:
> 
> 1. Why is overriding lazy stored properties supported, while overriding a 
> non-lazy stored property is not.
> 
> 2. Is this behaviour intended and/or recommended.
> 
> 3. I realise you can achieve the same result by overriding init in the 
> sub-class and assigning to a non-lazy property, however often this reduces 
> clarity and introduces un-necessary boiler-plate code (especially if init 
> takes a number of args).
> 
> Thanks!
> 
> John
> ___
> 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] defaultCalendarForNewEvents is defined as optional however can't use optional binding to check if it's nil

[Jordan Rose via swift-users]

Nothing specific. A lot of minor issues were corrected in the Xcode 9 release 
with a nod towards maintaining source compatibility, and most of them weren't 
release-noted.

Jordan


> On Jan 10, 2018, at 10:21, Filiz Kurban <filiz.kur...@gmail.com> wrote:
> 
> Thanks for your response. I will check that now! In the meantime, is there a 
> release note that states this? I have a stackover flow question on this and 
> would love to resolve it.
> 
> On Wed, Jan 10, 2018 at 10:13 AM, Jordan Rose via swift-users 
> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
> Hi, Filiz. Are you sure you're using Swift 4 and not the Swift 3 
> compatibility mode? 'defaultCalendarForNewEvents' was marked non-optional in 
> Swift 3 by accident and that was fixed in Swift 4.
> 
> Jordan
> 
> 
>> On Jan 10, 2018, at 08:59, Filiz Kurban via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> Hello,
>> 
>> I'm adding a new functionality in my app, which is the ability to add an 
>> event in the default calendar set up on the phone. In the implementation, I 
>> get the permission and am ready to add the event. I check to see if there is 
>> an actual default calendar through the use of optional binding, but I get 
>> the error:
>> 
>> Initializer for conditional binding must have Optional type, not 'EKCalendar'
>> 
>> Now, defaultCalendarForNewEvents is an Optional (see declaration below) and 
>> it should be perfectly fine to use optional binding to check if it's nil or 
>> not. What am I missing?
>> 
>> defaultCalendarForNewEvents definition in EKEventStore.h:
>> 
>> open var defaultCalendarForNewEvents: EKCalendar? { get }
>> 
>> I'm using Swift 4 on iOS11.2
>> 
>> if let defaultCalendar = eventStore.defaultCalendarForNewEvents { <-- error 
>> line
>> newEvent.title = "Some Event Name"
>> newEvent.startDate = Date()
>> newEvent.endDate = Date()
>> }
>> 
>> Thank you for your help in advance.
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users 
>> <https://lists.swift.org/mailman/listinfo/swift-users>
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users 
> <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] defaultCalendarForNewEvents is defined as optional however can't use optional binding to check if it's nil

[Jordan Rose via swift-users]

Hi, Filiz. Are you sure you're using Swift 4 and not the Swift 3 compatibility 
mode? 'defaultCalendarForNewEvents' was marked non-optional in Swift 3 by 
accident and that was fixed in Swift 4.

Jordan


> On Jan 10, 2018, at 08:59, Filiz Kurban via swift-users 
>  wrote:
> 
> Hello,
> 
> I'm adding a new functionality in my app, which is the ability to add an 
> event in the default calendar set up on the phone. In the implementation, I 
> get the permission and am ready to add the event. I check to see if there is 
> an actual default calendar through the use of optional binding, but I get the 
> error:
> 
> Initializer for conditional binding must have Optional type, not 'EKCalendar'
> 
> Now, defaultCalendarForNewEvents is an Optional (see declaration below) and 
> it should be perfectly fine to use optional binding to check if it's nil or 
> not. What am I missing?
> 
> defaultCalendarForNewEvents definition in EKEventStore.h:
> 
> open var defaultCalendarForNewEvents: EKCalendar? { get }
> 
> I'm using Swift 4 on iOS11.2
> 
> if let defaultCalendar = eventStore.defaultCalendarForNewEvents { <-- error 
> line
> newEvent.title = "Some Event Name"
> newEvent.startDate = Date()
> newEvent.endDate = Date()
> }
> 
> Thank you for your help in advance.
> 
> 
> ___
> 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 4.0 bug in concurrent array access

[Jordan Rose via swift-users]

> On Jan 8, 2018, at 11:47, ⁨‫Fadi Botros‬ ‫⁩ <⁨botros_f...@yahoo.com⁩> wrote:
> 
> 1st: How to invoke the thread sanitizer?

Check out this article on developer.apple.com: 
https://developer.apple.com/documentation/code_diagnostics/thread_sanitizer/enabling_the_thread_sanitizer

> 2nd: I think making something like ConcurrentModificationException of Java 
> should be a little better experience (if it will not make, or make a small 
> performance penalty, also if it makes performance penalty, it would be 
> activated only when you make a debug version or non-optimized version)

I don't exactly disagree, but my understanding is that the work to do such a 
thing is nearly equivalent to having thread sanitizer on all the time. But 
maybe there's a simpler model that we could still turn on in debug builds. Can 
you file a bug report requesting this now that bugs.swift.org is back up?

Thanks!
Jordan



> 
> 
> من: Jordan Rose 
> إلى: ‫Fadi Botros‬ ‫  
> نسخة كربونية: "swift-users@swift.org" 
> تاريخ الإرسال: الإثنين 8 يناير، 2018‏ 9:14 م
> الموضوع: Re: [swift-users] Swift 4.0 bug in concurrent array access
> 
> That sounds expected to me. While Array values are thread-safe, writing to 
> the global variable 'array' from two different threads would be a race. You 
> can see this properly diagnosed if you enable Thread Sanitizer.
> 
> Jordan
> 
> P.S. bugs.swift.org  should be back up now, if you 
> find any other issues.
> 
> 
>> On Jan 8, 2018, at 11:02, ⁨‫Fadi Botros‬ ‫ via swift-users⁩ 
>> <⁨swift-users@swift.org ⁩> wrote:
>> 
>> I'm on macOS Sierra 10.12.6, and using Swift 4.0
>> Tried to access the array concurrently to see whether is it synchronized or 
>> no
>> import Foundation let global = DispatchQueue.global() var array: [Int] = [ - 
>> Pastebin.com 
>> 
>> 
>> import Foundation let global = DispatchQueue.global() var array: [Int...
>>  
>> 
>> When tried to run it using the terminal
>> This crash happened
>> 
>> swift(69836,0x72dc2000) malloc: *** error for object 0x7ffe4be237e0: 
>> pointer - Pastebin.com 
>> 
>> 
>> swift(69836,0x72dc2000) malloc: *** error for object 0x7ffe4be237e0: 
>> po...
>>  
>> 
>> Avoided this crash using Serial Dispatch Queue
>> 
>> let otherDispatch = DispatchQueue(label: "another.dispatch.com 
>> ",
>>   qos: .default)
>> func appending(_ i: Int) {
>>   otherDispatch.sync { array.append(i) }
>> }
>> 
>> 
>> 
>> Also tried to file this issue on bugs.swift.org , 
>> and it appears your site is down (under maintainence)
>> 
>> Sorry
>> ___
>> 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 4.0 bug in concurrent array access

[Jordan Rose via swift-users]

That sounds expected to me. While Array values are thread-safe, writing to the 
global variable 'array' from two different threads would be a race. You can see 
this properly diagnosed if you enable Thread Sanitizer.

Jordan

P.S. bugs.swift.org should be back up now, if you find any other issues.


> On Jan 8, 2018, at 11:02, ⁨‫Fadi Botros‬ ‫ via swift-users⁩ 
> <⁨swift-users@swift.org⁩> wrote:
> 
> I'm on macOS Sierra 10.12.6, and using Swift 4.0
> Tried to access the array concurrently to see whether is it synchronized or no
> import Foundation let global = DispatchQueue.global() var array: [Int] = [ - 
> Pastebin.com 
> 
> 
> import Foundation let global = DispatchQueue.global() var array: [Int...
>  
> 
> When tried to run it using the terminal
> This crash happened
> 
> swift(69836,0x72dc2000) malloc: *** error for object 0x7ffe4be237e0: 
> pointer - Pastebin.com 
> 
> 
> swift(69836,0x72dc2000) malloc: *** error for object 0x7ffe4be237e0: po...
>  
> 
> Avoided this crash using Serial Dispatch Queue
> 
> let otherDispatch = DispatchQueue(label: "another.dispatch.com",
>   qos: .default)
> func appending(_ i: Int) {
>   otherDispatch.sync { array.append(i) }
> }
> 
> 
> 
> Also tried to file this issue on bugs.swift.org, and it appears your site is 
> down (under maintainence)
> 
> Sorry
> ___
> 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] I ve found a serious Bug in JSONEncoder (SR-6131) and would like to fix it.

[Jordan Rose via swift-users]

(moving to more relevant list)

> On Dec 18, 2017, at 08:51, Benoit Pereira da silva via swift-users 
>  wrote:
> 
> Dear all
> 
> I've found a serious Bug in JSONEncoder SR-6131 
>  and would like to fix it.
> This bug cause JSON encoding issues on Double when using a local that does 
> not use dot as decimal separator e.g « fr_FR » (we use a coma)
> 
> Demonstration of the issue : 
> 
> import Foundation
> 
> // Required to call setLocale
> import Darwin
> 
> // Let's set to french
> setlocale(LC_ALL,"fr_FR")
>  
> struct Shot:Codable{
> let seconds:Double
> }
>  
> let shot = Shot(seconds: 1.1)
>  
> do{
> let data = try JSONEncoder().encode(shot)
> if let json =  String(data:data, encoding:.utf8){
> // the result is : "{"seconds":1,1001}"
> // The decimal separator should not be "," but "."
> print(json)
> }
> }catch{
> print("\(error)")
> }
>  
> exit(EX_OK)
> 
> 
> 
> 
> I would like to propose my fix, test it and, but i’m not mastering the 
> contribution mechanism.
> 
> Where should i start? 
> 
> I ve forked 
> https://github.com/benoit-pereira-da-silva/swift-corelibs-foundation 
> 
> I have a very simple Unit test that demonstrates the issue.
> 
> How can i test my 
> 
> 
> Thanks
> 
> 
> 
> 
> 
> Benoit Pereira da Silva
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com 
> 
> 
> 
> 
> 
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of this 
> information for any purpose is prohibited without agreement of the sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
> des informations contenues dans ce message sont interdits sans agrément 
> préalable de l'expéditeur.
> 
> 
> 
> ___
> 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] UINavigationController subclass leaks member variable memory

[Jordan Rose via swift-users]

> On Dec 13, 2017, at 23:05, 吴君恺 via swift-users  wrote:
> 
> Hello community, 
> 
>   I just encountered a pretty weird behavior when I subclass  
> `UINavigationController` without overriding any initializers.
> 
> Simple Code:
> 
> import UIKit
> 
> class MyViewController: UINavigationController {
>   
>   let value: Int = {
> print("member init")
> return 3
>   }()
> }
> 
> let _ = MyViewController(rootViewController: UIViewController())
> 
> output is:
> 
> member init
> member init
> 
> In fact any member variables declared in this subclass is initialized twice 
> but deinitialized only once.
> This phenomenon only appears when using `init(rootViewController:)`. 
> 
> CMIW, It looks like Swift somehow treat this initializer as a designated 
> initializer, rather than a convenience one. 
> 
> Any Ideas?

Your analysis is correct. The problem is that UINavigationController's header 
file doesn't properly declare which initializers are designated and which are 
convenience. Fortunately, you're not the first to notice this; it's tracked by 
the UIKit folks as rdar://problem/27255526. I'll poke them about it.

Thanks for bringing it up!
Jordan

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

Re: [swift-users] Tuple of two or more instances to withExtendedLifetime

[Jordan Rose via swift-users]

Good question and good thought! I believe the answer is yes, this will work as 
intended, but I'd like to get someone more versed in SIL than me to verify 
that. Andy?

Jordan


> On Dec 13, 2017, at 01:28, Jens Persson via swift-users 
>  wrote:
> 
> There are no restrictions on the type of the first argument to 
> withExtendedLiftetime, even though it makes sense only for reference types.
> 
> So both the below variants will compile, and my question is if the first one 
> will work as expected (extending the lifetime of both a and b) or if the 
> second variant must be used instead.
> 
> 1:
> withExtendedLifetime((a, b)) {
> ...
> }
> 
> 2:
> withExtendedLifetime(a) {
> withExtendedLifetime(b) {
> ...
> }
> }
> 
> /Jens
> 
> ___
> 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's method dispatch

[Jordan Rose via swift-users]

Consider this example:

protocol P {
associatedtype T
func f() // *
}
extension P {
func f() { print("T is unknown") }
}
extension P where T == Int {
func f() { print("T is Int") }
}

struct X : P {
func f() { print("this one is actually best") }
}

struct Y where U: P, U.T == Int {
typealias T = U.T
var a: U
func g() { a.f() }
}

let x = X()
x.f() // "this one is actually best"

let y = Y(a: X())
y.g() // "this one is actually best"

I can't think of any other choice for 'a.f()' that would preserve this 
behavior, which means we're doing the best thing: prefer dynamic dispatch over 
static dispatch when operating on a generic value. (Or at least the "least bad" 
thing.) And of course this reasoning has to be local; Y.g can't look and say 
"oh, I know nothing else conforms to P, and X {does, doesn't} have a custom 
implementation, so I should pick the constrained extension instead".

The real answer might be "we should have had a different syntax for default 
implementations vs. mixin operations", but that's a much bigger can of worms.

Jordan


> On Dec 8, 2017, at 13:07, Jens Persson via swift-users 
>  wrote:
> 
> Thanks Slava and Greg,
> 
> (
> I'm aware that it prints "T is Int" from both calls if I remove func f() from 
> P itself, that's why I wrote "... unless * is commented out." in the comment 
> of the last line
> Note that the "U.T == Int"-part of 
>   struct Y where U: P, U.T == Int {
> is key here. If it had been only
>   struct Y where U: P {
> then I hadn't been surprised that it printed "T is unknown".
> )
> 
> Filed https://bugs.swift.org/browse/SR-6564 
>  since I think it is just strange that 
> the compiler should not use its knowledge of U.T == Int when choosing between 
> the two f()-implementations.
> I think I will be a little disappointed if the solution is to deem it an 
> ambiguity
> : )
> 
> /Jens
> 
> 
> 
> On Fri, Dec 8, 2017 at 9:19 PM, Greg Parker  > wrote:
> Evidence in favor of Slava's analysis: if you remove `func f()` from P 
> itself, leaving it in the extensions only, then you get "T is Int" from both 
> calls.
> 
> 
> > On Dec 8, 2017, at 12:12 PM, Slava Pestov via swift-users 
> > > wrote:
> >
> > Hi Jens,
> >
> > I think the problem is that overload ranking always prefers a protocol 
> > requirement to a protocol extension member, because usually you want the 
> > dynamic dispatch through the requirement instead of calling the default 
> > implementation. But it appears that this heuristic does not take into 
> > account the fact that the protocol extension member could be more 
> > constrained than the requirement.
> >
> > Please file a bug, but it is unclear what the desired behavior actually is 
> > here. Perhaps it should just diagnose an ambiguity.
> >
> > Slava
> >
> >> On Dec 8, 2017, at 6:25 AM, Jens Persson via swift-users 
> >> > wrote:
> >>
> >> Hi all!
> >>
> >> Can someone please explain the rationale behind the last line printing
> >> "T is unknown"
> >> rather than (what I would expect):
> >> "T is Int"
> >> in the following program?
> >>
> >>
> >> protocol P {
> >>associatedtype T
> >>func f() // *
> >> }
> >> extension P {
> >>func f() { print("T is unknown") }
> >> }
> >> extension P where T == Int {
> >>func f() { print("T is Int") }
> >> }
> >>
> >> struct X : P {}
> >>
> >> struct Y where U: P, U.T == Int {
> >>// NOTE: The compiler/type-checker knows that U.T == Int here so ...
> >>typealias T = U.T
> >>var a: U
> >>func g() { a.f() } // ... how/why could this print anything but "T is 
> >> Int"?
> >> }
> >>
> >> let x = X()
> >> x.f() // Prints "T is Int", no matter if * is commented out or not.
> >>
> >> let y = Y(a: X())
> >> y.g() // Prints "T is unknown" unless * is commented out. Why?
> >>
> >>
> >> IMHO this looks like the compiler simply ignores that struct Y has the 
> >> constraint  U.T == Int.
> >> How else to explain this behavior?
> >> /Jens
> >>
> >> ___
> >> 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

Re: [swift-users] what is the use of "-frontend" argument to swift?

[Jordan Rose via swift-users]

Ah, got it. Sorry for being brusque—the question coming in on swift-users 
rather than swift-dev threw me off. If you need help with tests feel free to 
ask! (…but probably on swift-dev)

Jordan


> On Dec 5, 2017, at 22:09, Atul Sowani via swift-users  
> wrote:
> 
> Thanks Kyle and Jordan! That's the information I was looking for. Anyway I am 
> not using these options explicitly, but found that they are invoked while 
> Swift test suite is run. A few test cases are failing for me on ppc64le and 
> while analyzing it I came across these options. Thanks for the info!
> 
> Best regards,
> Atul.
> 
> On Wed, Dec 6, 2017 at 4:16 AM, Jordan Rose  > wrote:
> -c is an alias for -emit-object. -frontend is "magically start talking to 
> Swift's implementation details" and you shouldn't use it. More info in 
> docs/Driver.md .
> 
> Jordan
> 
> 
>> On Dec 5, 2017, at 14:23, Kyle Murray via swift-users > > wrote:
>> 
>> Looks like it's an alias for -emit-object:
>> 
>> https://github.com/apple/swift/blob/master/include/swift/Option/Options.td#L576
>>  
>> 
>> 
>> ...which will give an object file as output rather than the default, an 
>> executable. 
>> 
>> -Kyle
>> 
>>> On Dec 5, 2017, at 1:49 AM, Atul Sowani via swift-users 
>>> > wrote:
>>> 
>>> Hi,
>>> 
>>> What is the purpose of "-frontend -c" arguments of swift? I tried "swift 
>>> --help" but that does not mention it. Also I couldn't find it easily in any 
>>> swift documents. Can somebody kindly let me know the purpose of these 
>>> arguments?
>>> 
>>> Thanks,
>>> Atul.
>>> ___
>>> 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] Data races with copy-on-write

[Jordan Rose via swift-users]

> On Dec 5, 2017, at 16:24, Romain Jacquinot  wrote:
> 
>> Ah, it's a Swift bug in the SynchronizedArray / MyClass cases
> 
> If I remove the intermediate copy in the myArray getter, should it — without 
> Swift bug — also return a unique copy?
> 
> public var myArray: Array {
> lock.lock()
> defer { lock.unlock() }
> _myArray
> }

Yes. As soon as you treat it as a value (including returning it), it should be 
independent. The assignment to a local variable doesn't really add anything 
interesting, and the optimizer will throw it out.

> By the way, here is a simpler sample code where TSan also detects a race 
> condition:
> 
> // Code sample A
> 
> var array: [Int] = [1, 2, 3]
> 
> let iterations = 1_000_000
> 
> var copy1 = array
> q1.async {
> for i in 0.. copy1.append(i)
> }
> }
> 
> var copy2 = array
> q2.async {
> for i in 0.. copy2.append(i)
> }
> }
> 
> var copy3 = array
> q3.async {
> for i in 0.. copy3.append(i)
> }
> }
> 
> for i in 0.. array.append(i)
> }
> 
> q1.sync {}
> q2.sync {}
> q3.sync {}
> NSLog("done")

Yes, this would be failing for the same reason (didn't test it). The mutations 
are operating on different Array variables, but they start off sharing the same 
storage, and that means we can get into the same situation where one queue 
thinks it can modify the storage in place while another queue is still copying 
the initial contents.


> I can avoid the race condition to occur by using a capture list:
> 
> // Code sample B
> 
> var array: [Int] = [1, 2, 3]
> 
> let iterations = 1_000_000
> 
> q1.async { [array] in
> for i in 0.. var copy = array
> copy.append(i)
> }
> }
> 
> q2.async { [array] in
> for i in 0.. var copy = array
> copy.append(i)
> }
> }
> 
> q3.async { [array] in
> for i in 0.. var copy = array
> copy.append(i)
> }
> }
> 
> for i in 0.. array.append(i)
> }
> 
> q1.sync {}
> q2.sync {}
> q3.sync {}
> NSLog("done")
> 
> or by using a constant copy, which, if I’m not wrong, should behave the same 
> way than the capture list:
> 
> // Code sample C
> 
> var array: [Int] = [1, 2, 3]
> 
> let iterations = 1_000_000
> 
> let copy1 = array
> q1.async {
> var copy1 = copy1
> for i in 0.. copy1.append(i)
> }
> }
> 
> 
> let copy2 = array
> q2.async {
> var copy2 = copy2
> for i in 0.. copy2.append(i)
> }
> }
> 
> let copy3 = array
> q3.async {
> var copy3 = copy3
> for i in 0.. copy3.append(i)
> }
> }
> 
> for _ in 0.. array.append(array.count)
> }
> 
> q1.sync {}
> q2.sync {}
> q3.sync {}
> NSLog("done")

Yep, these two are equivalent, at least as far as this issue goes. This dodges 
the issue because the capture or the 'let' keeps an extra reference to the 
original array at all times, meaning that none of the mutations are ever done 
in-place.

Thank you again for catching this! (It's also possible we've already fixed it 
on master, but it's still worth having a bug report so we can add a regression 
test.)

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

Re: [swift-users] Data races with copy-on-write

[Jordan Rose via swift-users]

Ah, it's a Swift bug in the SynchronizedArray / MyClass cases, and your bug in 
the very first example with the global (since access to the global itself is 
not synchronized). The case I actually tested myself was with your most recent 
example ("Yet, data race can occur here").

Jordan


> On Dec 5, 2017, at 15:53, Romain Jacquinot  wrote:
> 
> Hi Jordan,
> 
> For which specific code sample(s) do you think it’s a bug? In the previous 
> code samples, are there cases where you think a data race is to be expected?
> 
> Thanks.
> 
>> On Dec 6, 2017, at 12:05 AM, Jordan Rose > > wrote:
>> 
>> I'm seeing the race too when compiling with -O (and TSan enabled). I'm 95% 
>> sure this should be valid Swift code without any further synchronization, so 
>> please file a bug at https://bugs.swift.org . (But 
>> I'm only 95% sure because concurrency is hard.)
>> 
>> Looking at the backtraces, it looks like one thread thinks it has exclusive 
>> ownership of the buffer while the other thread is still copying things out 
>> of it. This is a bug on Swift's side; this code should work. I'm pretty sure 
>> this is actually a situation I was just talking about with Michael I from 
>> the stdlib team a few days ago, so it's good to have a test case for it.
>> 
>> Jordan
>> 
>> 
>>> On Dec 5, 2017, at 14:23, Romain Jacquinot via swift-users 
>>> > wrote:
>>> 
>>> Also, on the official Swift blog 
>>> (https://developer.apple.com/swift/blog/?id=10 
>>> ), it is stated that:
>>> 
>>> "One of the primary reasons to choose value types over reference types is 
>>> the ability to more easily reason about your code. If you always get a 
>>> unique, copied instance, you can trust that no other part of your app is 
>>> changing the data under the covers. This is especially helpful in 
>>> multi-threaded environments where a different thread could alter your data 
>>> out from under you.
>>> […]
>>> In Swift, Array, String, and Dictionary are all value types. They behave 
>>> much like a simple int value in C, acting as a unique instance of that 
>>> data. You don’t need to do anything special — such as making an explicit 
>>> copy — to prevent other code from modifying that data behind your back. 
>>> Importantly, you can safely pass copies of values across threads without 
>>> synchronization. In the spirit of improving safety, this model will help 
>>> you write more predictable code in Swift.”
>>> 
>>> Yet, data race can occur here:
>>> 
>>> public class MyClass {
>>> 
>>> private var _myArray: Array = []
>>> private var _lock = NSLock()
>>> 
>>> public var myArray: Array {
>>> lock.lock()
>>> defer {
>>> lock.unlock()
>>> }
>>> let copy = _myArray
>>> return copy
>>> }
>>> 
>>> public func doSomethingThatMutatesArray() {
>>> _lock.lock()
>>> _myArray.append(1) // data race here: write of size 8 by thread 1
>>> _lock.unlock()
>>> }
>>> }
>>> 
>>> 
>>> let myClass = MyClass()
>>> 
>>> func mutateArray() {
>>> myClass.doSomethingThatMutatesArray()
>>> var arrayCopy = myClass.myArray
>>> arrayCopy.append(2) // data race here: read of size 8 by thread 10
>>> }
>>> 
>>> let q1 = DispatchQueue(label: "testQ1")
>>> let q2 = DispatchQueue(label: "testQ2")
>>> let q3 = DispatchQueue(label: "testQ3")
>>> 
>>> let iterations = 100_000
>>> 
>>> q1.async {
>>> for _ in 0..>> mutateArray()
>>> }
>>> }
>>> 
>>> q2.async {
>>> for _ in 0..>> mutateArray()
>>> }
>>> }
>>> 
>>> q3.async {
>>> for _ in 0..>> mutateArray()
>>> }
>>> }
>>> 
>>> for _ in 0..>>  mutateArray()
>>> }
>>> 
>>> q1.sync {}
>>> q2.sync {}
>>> q3.sync {}
>>> NSLog("done")
>>> 
>>> It also can occur for instance if I replace the mutateArray() function with 
>>> the following method:
>>> 
>>> func enumerateArray() {
>>> myClass.doSomethingThatMutatesArray()
>>> for element in myClass.myArray {  // data race here: read of size 8 by 
>>> thread 5
>>> let _ = element
>>> }
>>> }
>>> 
>>> How can I return a “predictable” copy from the MyClass.myArray getter, so 
>>> that I can later mutate the copy without synchronization like in the 
>>> mutateArray() function?
>>> 
 On Dec 5, 2017, at 9:23 PM, Romain Jacquinot via swift-users 
 > wrote:
 
 Hi Jens,
 
 In the SynchronizedArray class, I use a lock to perform mutating 
 operations on the array. However, my questions concern the case where an 
 array is exposed as a public property of a thread-safe class, like this:
 
 public class MyClass {
 
private var _myArray: Array = []
private var _lock = NSLock()
 
public var myArray: Array {

Re: [swift-users] Data races with copy-on-write

[Jordan Rose via swift-users]

I'm seeing the race too when compiling with -O (and TSan enabled). I'm 95% sure 
this should be valid Swift code without any further synchronization, so please 
file a bug at https://bugs.swift.org. (But I'm only 95% sure because 
concurrency is hard.)

Looking at the backtraces, it looks like one thread thinks it has exclusive 
ownership of the buffer while the other thread is still copying things out of 
it. This is a bug on Swift's side; this code should work. I'm pretty sure this 
is actually a situation I was just talking about with Michael I from the stdlib 
team a few days ago, so it's good to have a test case for it.

Jordan


> On Dec 5, 2017, at 14:23, Romain Jacquinot via swift-users 
>  wrote:
> 
> Also, on the official Swift blog 
> (https://developer.apple.com/swift/blog/?id=10 
> ), it is stated that:
> 
> "One of the primary reasons to choose value types over reference types is the 
> ability to more easily reason about your code. If you always get a unique, 
> copied instance, you can trust that no other part of your app is changing the 
> data under the covers. This is especially helpful in multi-threaded 
> environments where a different thread could alter your data out from under 
> you.
> […]
> In Swift, Array, String, and Dictionary are all value types. They behave much 
> like a simple int value in C, acting as a unique instance of that data. You 
> don’t need to do anything special — such as making an explicit copy — to 
> prevent other code from modifying that data behind your back. Importantly, 
> you can safely pass copies of values across threads without synchronization. 
> In the spirit of improving safety, this model will help you write more 
> predictable code in Swift.”
> 
> Yet, data race can occur here:
> 
> public class MyClass {
> 
> private var _myArray: Array = []
> private var _lock = NSLock()
> 
> public var myArray: Array {
> lock.lock()
> defer {
> lock.unlock()
> }
> let copy = _myArray
> return copy
> }
> 
> public func doSomethingThatMutatesArray() {
> _lock.lock()
> _myArray.append(1) // data race here: write of size 8 by thread 1
> _lock.unlock()
> }
> }
> 
> 
> let myClass = MyClass()
> 
> func mutateArray() {
> myClass.doSomethingThatMutatesArray()
> var arrayCopy = myClass.myArray
> arrayCopy.append(2) // data race here: read of size 8 by thread 10
> }
> 
> let q1 = DispatchQueue(label: "testQ1")
> let q2 = DispatchQueue(label: "testQ2")
> let q3 = DispatchQueue(label: "testQ3")
> 
> let iterations = 100_000
> 
> q1.async {
> for _ in 0.. mutateArray()
> }
> }
> 
> q2.async {
> for _ in 0.. mutateArray()
> }
> }
> 
> q3.async {
> for _ in 0.. mutateArray()
> }
> }
> 
> for _ in 0..  mutateArray()
> }
> 
> q1.sync {}
> q2.sync {}
> q3.sync {}
> NSLog("done")
> 
> It also can occur for instance if I replace the mutateArray() function with 
> the following method:
> 
> func enumerateArray() {
> myClass.doSomethingThatMutatesArray()
> for element in myClass.myArray {  // data race here: read of size 8 by 
> thread 5
> let _ = element
> }
> }
> 
> How can I return a “predictable” copy from the MyClass.myArray getter, so 
> that I can later mutate the copy without synchronization like in the 
> mutateArray() function?
> 
>> On Dec 5, 2017, at 9:23 PM, Romain Jacquinot via swift-users 
>> > wrote:
>> 
>> Hi Jens,
>> 
>> In the SynchronizedArray class, I use a lock to perform mutating operations 
>> on the array. However, my questions concern the case where an array is 
>> exposed as a public property of a thread-safe class, like this:
>> 
>> public class MyClass {
>> 
>>  private var _myArray: Array = []
>>  private var _lock = NSLock()
>> 
>>  public var myArray: Array {
>>  _lock.lock()
>>  defer { _lock.unlock() }
>>  return _myArray
>>  }
>> 
>>  public func doSomethingThatMutatesArray() {
>>  _lock.lock()
>>  _myArray.append(1)
>>  _lock.unlock()
>>  }
>> }
>> 
>> Arrays are implemented as structs in Swift. This is a value type, but 
>> because Array implements copy-on-write, there is an issue if you do 
>> something like this from multiple threads:
>> 
>> let myClass = MyClass()
>> 
>> func callFromMultipleThreads() {
>>  let arrayCopy = myClass.myArray
>>  arrayCopy.append(2) // race condition here
>> }
>> 
>> This is quite problematic, because the user of MyClass shouldn’t have to 
>> worry about side-effects when using a copy of the value from myArray.
>> 
>>> On Dec 5, 2017, at 8:22 PM, Jens Alfke >> > wrote:
>>> 
>>> 
>>> 
 On Dec 5, 2017, at 6:24 AM, Michel Fortin via swift-users 
 

Re: [swift-users] Passing variadic C args through?

[Jordan Rose via swift-users]

Sure. I'm not sure we have a good idea for how to catch the bug—what if you 
really meant to pass the array as an NSArray?—but it's worth recording 
somewhere. Thanks, Rick.

Jordan


> On Nov 14, 2017, at 18:00, Rick Mann  wrote:
> 
> I tried to find an alternative init() to use, but couldn't (despite dozens of 
> releases, Xcode's code completion still fails much of the time). Thanks for 
> pointing me to the right one!
> 
> Should I file a bug?
> 
>> On Nov 14, 2017, at 17:47 , Jordan Rose  wrote:
>> 
>> Heh, it would be nice to catch this. You're collecting a bunch of arguments 
>> in an Array, and then passing that array straight on as a single argument 
>> itself, which means it gets passed as either an NSArray or a pointer (not 
>> sure which). Use 'init(format:arguments:)' instead.
>> 
>> Jordan
>> 
>> 
>>> On Nov 14, 2017, at 17:19, Rick Mann via swift-users 
>>>  wrote:
>>> 
>>> I've had a long-working `debugLog()` method that looks like this:
>>> 
>>> ```
>>> func
>>> debugLog(_ inMsg: T, file inFile : String = #file, line inLine : Int = 
>>> #line)
>>> {
>>> let file = (inFile as NSString).lastPathComponent
>>> let s = "\(file):\(inLine)\(inMsg)"
>>> print(s)
>>> }
>>> ```
>>> 
>>> I wanted to add a version that works like `String(format:)`:
>>> 
>>> ```
>>> func
>>> debugLog(format inFormat: String, file inFile : String = #file, line inLine 
>>> : Int = #line, _ inArgs: CVarArg...)
>>> {
>>> let s = String(format: inFormat, inArgs)
>>> debugLog(s, file: inFile, line: inLine)
>>> }
>>> 
>>> ```
>>> 
>>> While this compiles and executes, all of the values are zero for this 
>>> example:
>>> 
>>> ```
>>> let xc = CGFloat(1.0)
>>> let yc = CGFloat(0.0)
>>> let len = CGFloat(282.1364917907643)
>>> 
>>> debugLog(format: "Pixel %f, %f length too far %f", xc, yc, len)
>>> ```
>>> 
>>> Output:
>>> 
>>> ```
>>> FisheyeImageRenderer.swift:108Pixel 0.00, 0.00 length too far 
>>> 0.00
>>> ```
>>> 
>>> Something is being misinterpreted in the passing of `inArgs: CVarArg...`
>>> 
>>> TIA,
>>> 
>>> -- 
>>> Rick Mann
>>> rm...@latencyzero.com
>>> 
>>> 
>>> 
>>> ___
>>> 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] Passing variadic C args through?

[Jordan Rose via swift-users]

Heh, it would be nice to catch this. You're collecting a bunch of arguments in 
an Array, and then passing that array straight on as a single argument itself, 
which means it gets passed as either an NSArray or a pointer (not sure which). 
Use 'init(format:arguments:)' instead.

Jordan


> On Nov 14, 2017, at 17:19, Rick Mann via swift-users  
> wrote:
> 
> I've had a long-working `debugLog()` method that looks like this:
> 
> ```
> func
> debugLog(_ inMsg: T, file inFile : String = #file, line inLine : Int = 
> #line)
> {
>   let file = (inFile as NSString).lastPathComponent
>   let s = "\(file):\(inLine)\(inMsg)"
>   print(s)
> }
> ```
> 
> I wanted to add a version that works like `String(format:)`:
> 
> ```
> func
> debugLog(format inFormat: String, file inFile : String = #file, line inLine : 
> Int = #line, _ inArgs: CVarArg...)
> {
>   let s = String(format: inFormat, inArgs)
>   debugLog(s, file: inFile, line: inLine)
> }
> 
> ```
> 
> While this compiles and executes, all of the values are zero for this example:
> 
> ```
> let xc = CGFloat(1.0)
> let yc = CGFloat(0.0)
> let len = CGFloat(282.1364917907643)
> 
> debugLog(format: "Pixel %f, %f length too far %f", xc, yc, len)
> ```
> 
> Output:
> 
> ```
> FisheyeImageRenderer.swift:108Pixel 0.00, 0.00 length too far 
> 0.00
> ```
> 
> Something is being misinterpreted in the passing of `inArgs: CVarArg...`
> 
> TIA,
> 
> -- 
> 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] .apinotesc file placement?

[Jordan Rose via swift-users]

Yep, you can! In fact, you don't even need to compile it. You can just put the 
apinotes file itself into the Headers/ directory and it will work, as long as

- the file has the same name as the framework, i.e. "MyKit.apinotes"
- the framework has a proper module map

(I have a task on me to write up documentation on this but haven't gotten 
around to it. It's not something most people need to do, but adapting an 
existing library is one of the more likely cases.)

Jordan


> On Oct 30, 2017, at 18:31, Rick Mann via swift-users  
> wrote:
> 
> I'm using a third-party C library shoehorned into a Framework. It does not 
> have proper ENUM macros nor an apinotes file. I'd like to add one. I'm using 
> Xcode 9. 
> 
> • Can I put the .apinotesc file in the Framework somewhere?
> • Can I make Xcode automatically compile it?
> 
> Thanks.
> 
> -- 
> 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] Using eg @_specialize in apps submitted to the AppStore?

[Jordan Rose via swift-users]

It doesn't count as "using private APIs", but we assume no liability if your 
app is miscompiled. Also, we will not feel sorry for you when we change the 
syntax and your code doesn't compile any more. ;-)

(Good question, worth asking.)

Jordan


> On Nov 1, 2017, at 02:33, Jens Persson via swift-users 
>  wrote:
> 
> Hi!
> 
> Is it OK to use internal attributes such as @_specialize in apps submitted to 
> the App Store?
> 
> /Jens
> ___
> 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] Re-initializing lazy vars

[Jordan Rose via swift-users]

It's not directly related to property behaviors. It was a bug that only worked 
with ImplicitlyUnwrappedOptional properties; we patched the type checker bug 
that led to it being allowed and didn't even notice until someone brought it up 
(SR-5172 ).

It would be possible to introduce this as an actual language feature even 
without the full property behaviors model, but we wouldn't want to just spell 
it 'lazy'. Maybe 'lazy_resettable' or something. And even though I say this, 
it's probably unlikely that such a proposal would get through swift-evolution 
in the Swift 5 timeframe.

Meanwhile, it's always possible to implement it by hand, though I can see how 
that'd be annoying if you were relying on this and previously got it with a 
single '!'.

class LazyResettableTest {
  private func fooInitial() -> String { return "initial value" }
  private var fooStorage: String?
  var foo: String! {
get {
  if fooStorage == nil { fooStorage = fooInitial() }
  return fooStorage
}
set {
  fooStorage = newValue
}
  }
}

Jordan


> On Oct 19, 2017, at 19:59, David Sweeris via swift-users 
>  wrote:
> 
> I don't know. IIRC (big if), though, there was talk of adding support for 
> "property behaviors"(?). Resetting lazy vars probably would've been one of 
> them, and if so, it probably got pulled so that we wouldn't risk breaking 
> source compatibility later by adding a consistent syntax for other behaviors. 
> I think. I wish I could remember who'd brought up the idea... they'd probably 
> know straight away if that's what happened.
> 
> - Dave Sweeris
> 
>> On Oct 19, 2017, at 5:40 PM, Rick Mann via swift-users 
>>  wrote:
>> 
>> Googling for the answer, it seemed some versions of Swift supported setting 
>> a lazy var property to nil, such that the next time it's accessed, the 
>> initializer would be run again.
>> 
>> But I just tried this in a playground in Swift 4 and it doesn't work.
>> 
>> It sure seems to me like it should work. What's the reasoning for the 
>> current behavior?
>> 
>> -- 
>> 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] How do you declare a custom NSAttributedStringKey in Objective-C for Swift use?

[Jordan Rose via swift-users]

Oh, whoops! Good catch, Martin. I guess I was working from outdated information 
here. The Radar I mentioned is something else; this one is 
 Generated interface for import-as-member doesn't 
include context.

Jordan


> On Sep 27, 2017, at 11:45, Martin R via swift-users  
> wrote:
> 
> Could it be that this is (just) a problem of the generated interface _view_ ? 
> With
> 
>extern NSAttributedStringKey ODRolloverTokenAttributeName;
> 
> in an Objective-C header the "Generated Interface" is displayed as
> 
>   public static let ODRolloverTokenAttributeName: NSAttributedStringKey
> 
> as you noticed, but I can use it from Swift as
> 
>   let key = NSAttributedStringKey.ODRolloverTokenAttributeName
> 
> so it is actually a property of NSAttributedStringKey, not a global variable. 
> And with
> 
>   extern NSAttributedStringKey ODRolloverTokenAttributeName 
> NS_SWIFT_NAME(rolloverToken);
> 
> in the Objective-C header I can use it from Swift as
> 
>   let key = NSAttributedStringKey.rolloverToken
> 
> So – unless I am misunderstanding something – the 
> ODRolloverTokenAttributeName defined in the Objective-C header file is 
> actually imported to Swift as an extension to NSAttributedStringKey, even if 
> the generated interface view in Xcode displays it as a global variable.
> 
> Regards, Martin
> 
> 
>> Am 27.09.2017 um 16:07 schrieb Marco Masser via swift-users 
>> :
>> 
>> Hi,
>> 
>> Swift 4 and the macOS 10.13 SDK added a new NSAttributedStringKey type for 
>> the keys that NSAttributedStrings use. The keys are then defined in an 
>> extension of NSAttributedStringKey, essentially like this in AppKit:
>> 
>> // AppKit/NSAttributedString.h (Objective-C)
>> extern NSAttributedStringKey NSFontAttributeName;
>> 
>> // Generated Swift Interface
>> extension NSAttributedStringKey {
>>public static let font: NSAttributedStringKey
>> }
>> 
>> 
>> How do I get my own custom NSAttributedStringKeys to be imported this way? 
>> When I do it like AppKit, it doesn’t seem to work:
>> 
>> // My Objective-C header
>> extern NSAttributedStringKey ODRolloverTokenAttributeName;
>> 
>> // Generated Swift Interface
>> static let ODRolloverTokenAttributeName: NSAttributedStringKey
>> 
>> 
>> That is obviously not the same. I tried using the NS_SWIFT_NAME macro, but 
>> that results in the symbol disappearing in Swift completely:
>> 
>> // My Objective-C header
>> extern NSAttributedStringKey ODRolloverTokenAttributeName 
>> NS_SWIFT_NAME(NSAttributedStringKey.rolloverToken);
>> 
>> 
>> I also tried to use the swift_name attribute that is used by the 
>> NS_SWIFT_NAME macro and that is even mentioned in SE-0044 for exactly this 
>> purpose, but the symbol still disappears:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md#swift_name-attribute
>> 
>> extern const NSAttributedStringKey ODRolloverTokenAttributeName 
>> __attribute__((swift_name("NSAttributedStringKey.rolloverToken")));
>> 
>> 
>> What works is to manually define it in an extension like this, but that’s no 
>> fun:
>> 
>> // My Objective-C header
>> extern NSAttributedStringKey ODRolloverTokenAttributeName 
>> NS_REFINED_FOR_SWIFT;
>> 
>> extension NSAttributedStringKey {
>>static let rolloverToken = 
>> NSAttributedStringKey(__ODRolloverTokenAttributeName.rawValue)
>> }
>> 
>> 
>> Is there no way to import this automatically? Was this functionality removed 
>> before release even though it was mentioned in SE-0044?
>> 
>> Cheers,
>> 
>> Marco
>> ___
>> 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] How do you declare a custom NSAttributedStringKey in Objective-C for Swift use?

[Jordan Rose via swift-users]

Hi, Marco. The limitation here is that you can’t use swift_name (or 
NS_SWIFT_NAME) to add members to someone else’s type (more precisely, a type 
not declared in your module’s headers). You’re not the first to be dissatisfied 
with this restriction, though, particularly since as you point out you can just 
add a Swift-side extension to do the same thing. Within Apple, 
rdar://problem/31877728  tracks making the feature 
more general.

Similarly, the automatic import-as-member feature for 
NS_EXTENSIBLE_STRING_ENUMs is also only enabled for constants in the same 
module as the type. I’m not sure we want to rock the boat on that one.

Jordan


> On Sep 27, 2017, at 07:07, Marco Masser via swift-users 
>  wrote:
> 
> Hi,
> 
> Swift 4 and the macOS 10.13 SDK added a new NSAttributedStringKey type for 
> the keys that NSAttributedStrings use. The keys are then defined in an 
> extension of NSAttributedStringKey, essentially like this in AppKit:
> 
> // AppKit/NSAttributedString.h (Objective-C)
> extern NSAttributedStringKey NSFontAttributeName;
> 
> // Generated Swift Interface
> extension NSAttributedStringKey {
> public static let font: NSAttributedStringKey
> }
> 
> 
> How do I get my own custom NSAttributedStringKeys to be imported this way? 
> When I do it like AppKit, it doesn’t seem to work:
> 
> // My Objective-C header
> extern NSAttributedStringKey ODRolloverTokenAttributeName;
> 
> // Generated Swift Interface
> static let ODRolloverTokenAttributeName: NSAttributedStringKey
> 
> 
> That is obviously not the same. I tried using the NS_SWIFT_NAME macro, but 
> that results in the symbol disappearing in Swift completely:
> 
> // My Objective-C header
> extern NSAttributedStringKey ODRolloverTokenAttributeName 
> NS_SWIFT_NAME(NSAttributedStringKey.rolloverToken);
> 
> 
> I also tried to use the swift_name attribute that is used by the 
> NS_SWIFT_NAME macro and that is even mentioned in SE-0044 for exactly this 
> purpose, but the symbol still disappears:
> https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md#swift_name-attribute
>  
> 
> 
> extern const NSAttributedStringKey ODRolloverTokenAttributeName 
> __attribute__((swift_name("NSAttributedStringKey.rolloverToken")));
> 
> 
> What works is to manually define it in an extension like this, but that’s no 
> fun:
> 
> // My Objective-C header
> extern NSAttributedStringKey ODRolloverTokenAttributeName 
> NS_REFINED_FOR_SWIFT;
> 
> extension NSAttributedStringKey {
> static let rolloverToken = 
> NSAttributedStringKey(__ODRolloverTokenAttributeName.rawValue)
> }
> 
> 
> Is there no way to import this automatically? Was this functionality removed 
> before release even though it was mentioned in SE-0044?
> 
> Cheers,
> 
> Marco
> ___
> 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] NSRange error in docker

[Jordan Rose via swift-users]

That's not how extensions in Swift work. All of those functions are definitely 
available.

Barbara, can you post your source somewhere? And can you check that your Docker 
image is actually new enough, using `swift --version`? (The Swift project 
doesn't publish an official Docker image, so unless you made it yourself from a 
package at swift.org  you could easily be using something 
out-of-date.)

Jordan


> On Sep 25, 2017, at 15:06, Людвиг Вальда Васкес via swift-users 
>  wrote:
> 
> Interesting, those extensions aren't public for some reason which prevents 
> their usage from outside of Foundation module. I’m curious if that was 
> intentional due to unfinished work or something or they just forgot to export 
> them.
> 
> Best regards,
> Ludwig
> 
>> 25 сент. 2017 г., в 16:40, Barbara Reichart via swift-users 
>> > написал(а):
>> 
>> Hi,
>> 
>> I am using swift in a docker container. Now I wanted to use NSRange, which 
>> according to the page is already fully implemented for linux.
>> However when I try to use 'lowerBound' or 'upperBound' it gives me the 
>> following error:
>> 
>> error: value of type 'NSRange' (aka '_NSRange') has no member 'lowerBound'
>> 
>> I have looked into the implementation of NSRange in corelibs-foundation 
>> ,
>>  where I can see that both properties have been defined in an extension.
>> Unfortunately, it seems that I can only use things defined on _NSRange and 
>> not on its alias NSRange. Do you guys have any idea, what I am doing wrong?
>> 
>> Best regards,
>> Barbara
>> ___
>> 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] Segmentation fault when running binary executable compiled from LLVM bitcode on Linux

[Jordan Rose via swift-users]

Hm, I don’t see any inherent problems with splitting compilation like this, 
although it’s not something we test. The only thing I could think of is that 
Swift uses a custom calling convention on some platforms, but I would expect 
clang++ to refuse to compile the bc file at all if that were the issue. Mind 
filing a bug at https://bugs.swift.org  ?

Thanks,
Jordan


> On Sep 21, 2017, at 13:42, Jeffrey W via swift-users  
> wrote:
> 
> Hi swift team,
> 
> I download the prebuilt swift 4.0 from here 
> 
>  and try to do some work on the generated LLVM BC. However, I got a seg fault 
> when running the binary executable compiled from bitcode as shown below:
> 
> $ cat hello.swift
> print("Hello World")
> $ swiftc hello.swift -emit-bc -o hello.bc
> $ clang++ hello.bc -c -o hello.o
> $ swiftc hello.o -o hello
> $ ./hello
> Segmentation fault (core dumped)
> 
> It works fine if no bitcode file is involved here.
> 
> $ swiftc hello.swift -c -o hello.o
> $ swiftc hello.o -o hello
> $ ./hello
> Hello World
> 
> I am running Ubuntu 14.04.3 (kernel 4.8.0). I also encountered the same seg 
> fault if I use the prebuilt swift 3.1.1
> 
> Is it the right way to compile the bitcode generated from swift? Or is it a 
> bug in swift ?
> 
> Thanks a lot in advance!
> 
> Best regards,
> Jeffrey
> 
> ___
> 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] "Unavailable instance method... used to satisfy a requirement of protocol"

[Jordan Rose via swift-users]

Hi, James. The trick here is that the name you’ll get in Swift for these 
methods is probably 'compareQuery(_:toQuery:)', because the Swift compiler 
detects that the “result” is redundant with the type name. In Xcode 8 the 
compiler didn’t check if you were using the “old" name to satisfy a protocol, 
but Xcode 9 now does (for unrelated reasons).

Since this is a source-breaking change, can you file an issue at 
https://bugs.swift.org  ? At the very least we should 
make the diagnostic better.

You can always tell the Swift compiler you know better by using the 
NS_SWIFT_NAME annotation to provide an alternate name, using Swift function 
name syntax.

Jordan


> On Sep 15, 2017, at 12:45, James Dempsey via swift-users 
>  wrote:
> 
> I am updating from Xcode 8 to Xcode 9, still using Swift 3.
> 
> In my project I am getting warnings of the pattern:
> 
> Unavailable instance method ‘compareQueryResult(_:toQueryResult:)’ was used 
> to satisfy a requirement of protocol ‘ResultComparable’.
> 
> My project uses an Obj-C++ framework to wrap C++ and expose it in Obj-C.
> 
> The instance method in question is declared and implemented in a number of 
> Obj-C classes in this framework.
> 
> @interface DocumentQuery: Query {
>- (ComparisonResult)compareQueryResult:(DocumentResult *)result1 
> toQueryResult:(DocumentResult *)result2;
> }
> @end
> 
> @interface GroupQuery: Query {
>- (ComparisonResult)compareQueryResult:(GroupResult *)result1 
> toQueryResult:(GroupResult *)result2;
> }
> @end
> 
> 
> 
> Another framework imports the Obj-C++ framework. In this framework the 
> protocol is defined in Swift with an associated type:
> 
> public protocol ResultComparable
> {
> associatedtype ResultType
> func compareQueryResult(_ r1: ResultType, toQueryResult r2: ResultType) 
> -> ComparisonResult
> }
> 
> And conformance is declared:
> 
> extension DocumentQuery: ResultComparable {}
> extension GroupQuery: ResultComparable {}
> 
> 
> This compiled without warnings in Xcode 8 / Swift 3, but they appear in Xcode 
> 9 / Swift 3. Any help in understanding the issue and how to fix it would be 
> greatly appreciated.
> 
> James
> 
> ___
> 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] Memory Address of value types and reference types

[Jordan Rose via swift-users]

> On Sep 12, 2017, at 10:20, Andrew Trick via swift-users 
>  wrote:
> 
>> 
>> On Sep 12, 2017, at 9:55 AM, somu subscribe via swift-users 
>>  wrote:
>> 
>> Hi Quinn,
>> 
>> Thanks for the reply,
>> 
>> It is an iOS Swift project (uses Foundation, UIKit, CloudKit and other 
>> native frameworks) in which I would like to check the memory address for 
>> debugging (and out of enthusiasm). There is no C code I am using.
>> 
>> I have some asynchronous call back functions from CloudKit frameworks which 
>> return CKUserIdentity objects.
>> 
>> So thought it would be nice if I could print the memory address of 
>> CKUserIdentity objects and to check if it was unique.
>> 
>> And there are some other custom Swift Structs which I would like to know the 
>> memory address of.
>> 
>> Thanks and regards,
>> Muthu
> 
> For classes, use the Unmanaged API as Quinn’s suggested.

If you really just want a unique value and don't want to do anything with that 
value, ObjectIdentifier is even easier to use.

Jordan


> 
> Your structs, tuples, and enums only have an address during mutation. So, for 
> example, if you wrap all of your code in a function that takes the variable 
> `inout`, you’ll see a consistent address within a single call to that 
> function. There’s an implicit cast from `inout` to Unsafe[Mutable]Pointer 
> arguments, so you can inspect the pointer value...
> 
> func foo(p: Unsafe[Mutable]Pointer) { print(p) }
> 
> foo()
> 
> As you noticed, between calls to `foo` you could see a different address.
> 
> If you really want to give your structs an “identity” you would need to wrap 
> them in a class.
> 
> -Andy
> 
>>> On 12 Sep 2017, at 10:35 PM, Quinn The Eskimo! via swift-users 
>>>  wrote:
>>> 
>>> 
>>> On 12 Sep 2017, at 13:44, somu subscribe via swift-users 
>>>  wrote:
>>> 
 1. Is the above shown the correct way to get reference type memory address 
 ?
 2. What Is it the correct way to get value type memory address ?
>>> 
>>> It’s hard to answer that without knowing how you’re intended to use these 
>>> techniques.  If you can explain more about where you’re going with this, I 
>>> should be able to make some specific recommendations.
>>> 
>>> For example, if you’re goal were to pass a Swift object to a C API that 
>>> takes a callback function pointer and a ‘cookie’ value, and hen calls that 
>>> function with that cookie (like the `qsort_r` function), the to/from opaque 
>>> mechanism provider by `Unmanaged` is the recommended way to pass a Swift 
>>> object through such a cookie value.
>>> 
 3. Is it possible to get the memory address of immutable value type 
 (declared as let)
>>> 
>>> No, because such values don’t necessarily exist in memory.
>>> 
>>> 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
>> 
>> ___
>> 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] Custom operators from a module

[Jordan Rose via swift-users]

I just tried it myself with a framework and app target and it worked. Can you 
reproduce what you’re seeing in a simple project and file a bug report at 
https://bugs.swift.org  ?

Sorry for the trouble!
Jordan


> On Sep 6, 2017, at 13:35, Howard Lovatt  wrote:
> 
> I have a custom operator defined in a module and in my XCTest I import that 
> module. In the tests the compiler says that the operator isn't defined. If I 
> define the operator manually in the tests then it works. 
> 
> So what is going on?
> 
> -- Howard. 
> 
> On 7 Sep 2017, at 3:45 am, Jordan Rose  > wrote:
> 
>> It's actually the other way around: all operator declarations are exported 
>> from a module, all the time, even if the functions that implement them 
>> aren't. This is probably a model we should improve, but it's been that way 
>> since Swift 1.
>> 
>> Jordan
>> 
>> 
>>> On Sep 6, 2017, at 02:08, Howard Lovatt via swift-users 
>>> > wrote:
>>> 
>>> Hi All,
>>> 
>>> I am trying to use a custom operator imported from a module, unfortunately 
>>> you can't add public to the operators definition and therefore it isn't 
>>> exported from the module.
>>> 
>>> I can manually redefine the operator in the module where the operator is 
>>> used, but that isn't very satisfactory - is there a better way?
>>> 
>>> Thanks in advance,
>>> 
>>>   -- Howard.
>>> ___
>>> 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] Custom operators from a module

[Jordan Rose via swift-users]

It's actually the other way around: all operator declarations are exported from 
a module, all the time, even if the functions that implement them aren't. This 
is probably a model we should improve, but it's been that way since Swift 1.

Jordan


> On Sep 6, 2017, at 02:08, Howard Lovatt via swift-users 
>  wrote:
> 
> Hi All,
> 
> I am trying to use a custom operator imported from a module, unfortunately 
> you can't add public to the operators definition and therefore it isn't 
> exported from the module.
> 
> I can manually redefine the operator in the module where the operator is 
> used, but that isn't very satisfactory - is there a better way?
> 
> Thanks in advance,
> 
>   -- Howard.
> ___
> 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] Foundation bug or indended?

[Jordan Rose via swift-users]

It's semi-intended. When the compiler imports (NS)Operation into Swift, it uses 
the Swift naming convention…but it also declares a property with the old name, 
'executing', in order to give better error messages if someone tries to use the 
Objective-C name. That's what's colliding with your private 'executing' 
property.

We should improve this experience on the compiler side, either by having a 
'nonoverride' attribute or similar, or just by noting that you wouldn't try to 
override something with a private property not declared 'override' in the first 
place. But since the workaround is so simple it hasn't been a priority.

Sorry for the trouble,
Jordan


> On Sep 4, 2017, at 05:01, Adrian Zubarev via swift-users 
>  wrote:
> 
> Hi there,
> 
> before filing a new issue I would like to ask if this is intended behaviour 
> or a bug:
> 
> The Foundation class Operation which has it’s roots in Objective-C has a few 
> readonly properties like the following one:
> 
> @available(iOS 2.0, *)
> open class Operation : NSObject {
> ...
> open var isExecuting: Bool { get }
> ...
> }
> On the other hand the Objective-C header looks like this:
> 
> NS_CLASS_AVAILABLE(10_5, 2_0)
> @interface NSOperation : NSObject {
> ...
> @property (readonly, getter=isExecuting) BOOL executing;
> ...
> @end
> Now I want to create a custom subclass of Operation and override isExecuting, 
> everything works fine until I try to create a private stored property named 
> executing:
> 
> final class TransitionOperation : Operation {
> // error: cannot override with a stored property 'executing'
> private var executing = false
> 
> override var isExecuting: Bool {
> ...
> }
> }
> I’m a little bit confused here:
> 
> Is this intended behaviour or a bug?
> The Foundation implemented in Swift is not used for iOS deployment, instead 
> the Obj-C one is used right?
> 
> 
> 
> 
> ___
> 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] Is it possible to install Swift 4 on El Capitan with Xcode 8?

[Jordan Rose via swift-users]

> On Sep 4, 2017, at 20:06, Mr Bee via swift-users  
> wrote:
> 
> 
> 2017-09-05 3:47 GMT+07:00 Fritz Anderson via swift-users 
> >:
> 
> In your position, I’d go to the Downloads part of Swift.org 
>  and fetch the latest build of the Swift 4 toolchain for 
> Mac. (It’s still in flux, but it’ll probably be promoted to latest/stable 
> this month.)
> 
> Install the toolchain. This adds a Toolchains tab to the Components section 
> of the Preferences window. Select Swift 4.0 Snapshot.
> 
> Ok, I'll try it out once Swift 4 is officially released. So, that means Swift 
> 4 will work on Xcode 8, I suppose.

Unfortunately this will only work for pure Swift apps; the support libraries 
for Foundation, UIKit, etc are built against the Xcode 9 SDKs and will not work 
with Xcode 8. I'm afraid you're stuck with Swift 3 if you want to make Cocoa or 
Cocoa Touch apps, at least officially.

Jordan

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

Re: [swift-users] Can't convert to the latest version of Swift because can't find framework module

[Jordan Rose via swift-users]

Hi, Bill. I'm afraid I don't have much to help you because this is just 
supposed to work, and indeed it has worked for a number of projects we've 
tested locally. You should be able to open the workspace, select the scheme 
with the application, and convert both targets at once.

Is this a project you're able to share? If so, please file a bug at 
https://bugreport.apple.com  and attach both 
projects and the workspace. (The migrator is considered part of Xcode for now, 
so we'd rather have bugs go to Apple's bug tracker).

Sorry for the trouble!
Jordan


> On Aug 28, 2017, at 10:37, Bill Cheeseman via swift-users 
>  wrote:
> 
> I have a small macOS application with an embedded framework, both written in 
> Swift. Each has its own Xcode project in separate locations on my Mac, and I 
> use an Xcode workspace to develop and build both at once. I do not use 
> CocoaPods or Carthage. My application and framework build and run 
> successfully.
> 
> When I try to convert to the latest version of Swift using the Xcode 
> conversion command, it fails with a "no such module" error for the framework.
> 
> My online research shows that "no such module" errors have been plaguing 
> developers who use embedded frameworks for several years. A dozen or more 
> solutions have been suggested online, and they apparently work in some 
> contexts but not in others. None of them work for me.
> 
> Has anybody successfully run the Xcode Swift conversion command with an 
> embedded framework and everything written in Swift? If so, can you spell out 
> the key setup features that made it work for you?
> 
> -- 
> 
> Bill Cheeseman - wjcheese...@comcast.net 
> ___
> 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 Compilation - Reaching ARG_MAX limit causing Xcode build failure

[Jordan Rose via swift-users]

You're not the only person to run into this. rdar://problem/33635183 
 tracks the issue within Apple, and since it would 
need Xcode-side changes as well there's no point in having a report at 
bugs.swift.org . I'm afraid we don't have a workaround 
right now other than what you've mentioned.

Jordan


> On Aug 16, 2017, at 03:17, bhargav gurlanka via swift-users 
>  wrote:
> 
> We have moderately complex Swift project with around 2,000 Swift files in a 
> single module.
> 
> Most of the Swift source files are deeply nested inside directories and 90% 
> of these files have absolute paths with more than 150 characters (assuming 
> project is in "/Volumes/Macintosh HD2/Project" folder)
> 
> Because Swift compiler (Xcode 8.3.2) takes the absolute paths of all source 
> files while compiling, the ARG_MAX limit is reached and build fails with:
> 
> Build operation failed without specifying any errors. Individual build tasks 
> may have failed for unknown reasons.
> 
> One possible cause is if there are too many (possibly zombie) processes; in 
> this case, rebooting may fix the problem.
> 
> Some individual build task failures (up to 12) may be listed below.
> 
> 
> 
> Have anybody experienced this issue before?
> 
> We temporarily fixed this issue by renaming longer folder names to shorter 
> ones.
> 
> I'm assuming that breaking this monolithic module into smaller ones might fix 
> the issue, but are there any other better solutions?
> 
> ___
> 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] Using defer in Swift Playgrounds

[Jordan Rose via swift-users]

Either way is fine. I suspect this is a bug with the transformation the Swift 
compiler performs when compiling for a playground, rather than with the 
machinery that goes with running the playground, but I haven’t looked into it.

Jordan


> On Aug 7, 2017, at 13:22, Joe DeCapo  wrote:
> 
> Since it's Playground bug, should I file it in Apple's bug reporter rather 
> than Swift's?
> 
>> On Aug 7, 2017, at 3:12 PM, Jordan Rose  wrote:
>> 
>> I’d say that’s a bug! Mind filing it at https://bugs.swift.org ?
>> 
>> Thanks,
>> Jordan
>> 
>>> On Aug 4, 2017, at 12:41, Joe DeCapo via swift-users 
>>>  wrote:
>>> 
>>> Hi everyone,
>>> 
>>> I'm not sure if there's a more appropriate place to ask this question, but 
>>> I figured at the very least I could get pointed in the right direction. 
>>> I've tried searching online and haven't been able to find anything 
>>> addressing this.
>>> 
>>> I was trying to use the `defer` statement in a Playground, and was 
>>> surprised to find that it never prints anything in the preview pane on the 
>>> side. I was expecting the evaluation of the code in the `defer` statement 
>>> to show up in line with the statements, even though they're executed after 
>>> the last line in the function. I made a very simple playground that 
>>> modifies a global variable and prints the value in the `defer` statement, 
>>> and when I print the global variable after calling my function it shows the 
>>> correct updated value, so the code in the `defer` statement is getting run 
>>> as expected. Here's my sample code with the Playground output in comments 
>>> on the side:
>>> 
>>> var x = 3   // 3
>>> func doSomething() {
>>>  print(1)   // "1\n"
>>>  defer {
>>>  x += 1
>>>  print(x)
>>>  }
>>>  print(2)   // "2\n"
>>> }
>>> doSomething()
>>> print(x)// "4\n"
>>> 
>>> I was expecting something like this:
>>> 
>>> var x = 3   // 3
>>> func doSomething() {
>>>  print(1)   // "1\n"
>>>  defer {
>>>  x += 1 // 4
>>>  print(x)   // "4\n"
>>>  }
>>>  print(2)   // "2\n"
>>> }
>>> doSomething()
>>> print(x)// "4\n"
>>> 
>>> Is there some deep reason why code in `defer` statements doesn't show 
>>> anything in the preview pane in Playgrounds?
>>> 
>>> -Joe
>>> 
>>> 
>>> 
>>> ___
>>> 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] Using defer in Swift Playgrounds

[Jordan Rose via swift-users]

I’d say that’s a bug! Mind filing it at https://bugs.swift.org 
 ?

Thanks,
Jordan

> On Aug 4, 2017, at 12:41, Joe DeCapo via swift-users  
> wrote:
> 
> Hi everyone,
> 
> I'm not sure if there's a more appropriate place to ask this question, but I 
> figured at the very least I could get pointed in the right direction. I've 
> tried searching online and haven't been able to find anything addressing this.
> 
> I was trying to use the `defer` statement in a Playground, and was surprised 
> to find that it never prints anything in the preview pane on the side. I was 
> expecting the evaluation of the code in the `defer` statement to show up in 
> line with the statements, even though they're executed after the last line in 
> the function. I made a very simple playground that modifies a global variable 
> and prints the value in the `defer` statement, and when I print the global 
> variable after calling my function it shows the correct updated value, so the 
> code in the `defer` statement is getting run as expected. Here's my sample 
> code with the Playground output in comments on the side:
> 
> var x = 3 // 3
> func doSomething() {
>   print(1)// "1\n"
>   defer {
>   x += 1
>   print(x)
>   }
>   print(2)// "2\n"
> }
> doSomething()
> print(x)  // "4\n"
> 
> I was expecting something like this:
> 
> var x = 3 // 3
> func doSomething() {
>   print(1)// "1\n"
>   defer {
>   x += 1  // 4
>   print(x)// "4\n"
>   }
>   print(2)// "2\n"
> }
> doSomething()
> print(x)  // "4\n"
> 
> Is there some deep reason why code in `defer` statements doesn't show 
> anything in the preview pane in Playgrounds?
> 
> -Joe
> 
> 
> 
> ___
> 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] Overriding properties with limited availability

[Jordan Rose via swift-users]

Oops, I didn't notice that my own deployment target was already set to iOS 11. 
I see what you're seeing now. Can you file a bug for this at 
https://bugs.swift.org  ?

Workaround: put the override in an extension, and put the availability on the 
extension declaration. That seems to work for me.

Sorry for the trouble!
Jordan


> On Aug 2, 2017, at 14:12, Rod Brown  wrote:
> 
> Jordan,
> 
> So sorry, my snippet really wasn’t helpful there! Gah.  I realise the 
> extension wasn’t right! Sorry *facepalm*.
> 
> So I have a project. Its deployment target is iOS 10 (because we need 10.0 
> compatibility for the foreseeable future).
> 
> If I add the following code I get errors when it builds:
> 
> class MyViewControllerSubclass: UIViewController {
> 
> @available(iOS, introduced: 11.0)
> override var additionalSafeAreaInsets: UIEdgeInsets {
> didSet {
> // Need to do work here
> }
> }
> 
> }
> 
> 
> 
> My only solution at this stage is currently to KVO on the 
> AdditionalSafeAreaInsets property, which works, but this seems to point out a 
> language deficiency.
> 
> 
> Thanks
> 
> 
>> On 3 Aug 2017, at 3:24 am, Jordan Rose > > wrote:
>> 
>> I'm not sure why you're using 'override' in an extension. Did you mean to 
>> put that in a subclass? It seems to work for me there.
>> 
>> Yes, Swift will not let you replace existing methods/properties using an 
>> extension if it can statically see that the method/property already exists. 
>> (It's not even safe to do that in Objective-C, but the language doesn't stop 
>> you.)
>> 
>> Jordan
>> 
>> 
>>> On Aug 1, 2017, at 22:46, Rod Brown via swift-users >> > wrote:
>>> 
>>> Looks like this is a duplicate of this issue:
>>> 
>>> https://bugs.swift.org/browse/SR-1486 
>>> 
>>> 
>>> I’m curious if anyone knows whether that is actually a bug, or a 
>>> behavioural choice on Swift’s part?
>>> 
>>> 
 On 2 Aug 2017, at 10:31 am, Rod Brown via swift-users 
 > wrote:
 
 Hi everyone,
 
 Something I’ve come across in iOS 11 is that you can’t override properties 
 that are only available on iOS 11 when deploying with a deployment target 
 less than the current target.
 
 For example the following code is invalid:
 
 extension UIViewController {
 
 @available(iOS, introduced: 11.0)
 open override var additionalSafeAreaInsets: UIEdgeInsets {
 didSet {
 // Do work here only relevant to iOS 11
 }
 }   
 }
 
 This would be easily overridden in Obj-C, but I can’t do it in Swift. Is 
 there any reason why this limitation exists?
 
 Thanks,
 
 Rod
 ___
 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] Overriding properties with limited availability

[Jordan Rose via swift-users]

I'm not sure why you're using 'override' in an extension. Did you mean to put 
that in a subclass? It seems to work for me there.

Yes, Swift will not let you replace existing methods/properties using an 
extension if it can statically see that the method/property already exists. 
(It's not even safe to do that in Objective-C, but the language doesn't stop 
you.)

Jordan


> On Aug 1, 2017, at 22:46, Rod Brown via swift-users  
> wrote:
> 
> Looks like this is a duplicate of this issue:
> 
> https://bugs.swift.org/browse/SR-1486 
> 
> I’m curious if anyone knows whether that is actually a bug, or a behavioural 
> choice on Swift’s part?
> 
> 
>> On 2 Aug 2017, at 10:31 am, Rod Brown via swift-users > > wrote:
>> 
>> Hi everyone,
>> 
>> Something I’ve come across in iOS 11 is that you can’t override properties 
>> that are only available on iOS 11 when deploying with a deployment target 
>> less than the current target.
>> 
>> For example the following code is invalid:
>> 
>> extension UIViewController {
>> 
>> @available(iOS, introduced: 11.0)
>> open override var additionalSafeAreaInsets: UIEdgeInsets {
>> didSet {
>> // Do work here only relevant to iOS 11
>> }
>> }   
>> }
>> 
>> This would be easily overridden in Obj-C, but I can’t do it in Swift. Is 
>> there any reason why this limitation exists?
>> 
>> Thanks,
>> 
>> Rod
>> ___
>> 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] matching a protocol value in multiple patterns is not yet supported; use separate cases instead

[Jordan Rose via swift-users]

> On Jul 18, 2017, at 18:17, Zhao Xin via swift-users  
> wrote:
> 
> I encounter this error today. "matching a protocol value in multiple patterns 
> is not yet supported; use separate cases instead"
> 
> Sample code:
> 
> import Foundation
> 
> protocol NameProtocol {
> var name:String { get }
> }
> 
> struct Cat:NameProtocol {
> let name:String
> }
> 
> struct Dog:NameProtocol {
> let name: String
> }
> 
> enum AnimalType {
> case catType(cat:NameProtocol)
> case dogType(dog:NameProtocol)
> }
> 
> struct Animal {
> let type:AnimalType
> 
> func printName() {
> switch type {
> case .catType(let animal), // matching a protocol value in multiple 
> patterns is not yet supported; use separate cases instead
> .dogType(let animal):
> print(animal.name)
> }
> }
> }
> 
> let cat = Cat(name: "kitty")
> let catType = AnimalType.catType(cat: cat)
> let animal = Animal(type: catType)
> animal.printName()
> 
> 
> I am wondering which proposal this is? And will it be implemented in Swift 
> 4.0? I search the error as keywords, but didn't get the expected results.

It’s mostly just a bug. In Swift 3.1 this code was accepted but did the wrong 
thing at run-time. So we put in the error message until we can get around to 
fixing that, which at this point is unlikely to happen for Swift 4. There’s no 
new proposal needed, just more time to work on it.

Sorry for the inconvenience,
Jordan

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

Re: [swift-users] Unsubscribe

[Jordan Rose via swift-users]

Oops, thought the mailing list software was supposed to catch this. 
Unsubscribed you, Howard; sorry for the spurious message, everyone else.

-Jordan


> On Jul 14, 2017, at 10:03, Howard Perlman via swift-users 
>  wrote:
> 
> Unsubscribe
> 
> 
> From: "swift-users-requ...@swift.org" 
> To: swift-users@swift.org 
> Sent: Friday, July 14, 2017 12:57 PM
> Subject: swift-users Digest, Vol 20, Issue 13
> 
> Send swift-users mailing list submissions to
> swift-users@swift.org 
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
> or, via email, send a message with subject or body 'help' to
> swift-users-requ...@swift.org 
> 
> You can reach the person managing the list at
> swift-users-ow...@swift.org 
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of swift-users digest..."
> 
> 
> Today's Topics:
> 
>   1. Swift 4 emulating Decoder behaviour (Joanna Carter)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 13 Jul 2017 20:46:20 +0200
> From: Joanna Carter  >
> To: swift-users@swift.org 
> Subject: [swift-users] Swift 4 emulating Decoder behaviour
> Message-ID:
>  >
> Content-Type: text/plain; charset=utf-8
> 
> Greetings
> 
> I notice that, with Swift 4, I can decode an object like this :
> 
> • let retrievedSpot = try decoder.decode(ParkingSpot.self, from: 
> retrievedData)  
> 
> And that will return a ParkingSpot, as expected, into retrievedSpot.
> 
> However, I thought I would try the same technique with one of my pet projects…
> 
> I have a protocol  and an implementing struct :
> 
> • public protocol PropertyProtocol  
> • {  
> •  static var propertyType: Any.Type { get }  
> •  
> •  var untypedValue: Any? { get }  
> • }  
> •  
> • public struct Property : 
> PropertyProtocol  
> • {  
> •  public static var propertyType: Any.Type  
> •  {  
> •return valueT.self  
> •  }  
> •  
> •  public var untypedValue: Any?  
> •  {  
> •return value  
> •  }  
> •  
> •  public var value = valueT()  
> • }  
> 
> Now, I want to be able to use a "factory" method to create an instance of 
> Property, bound to its parameter type. So, I followed the same principal 
> as Decoder :
> 
> • struct PropertyFactory  
> • {  
> •  static func createProperty(_ type: T.Type) -> PropertyProtocol 
> where T : DefaultValueProvider  
> •  {  
> •return type.createProperty()  
> •  }  
> • }  
> 
> DefaultValueProvider is defined as follows and String is extended to conform 
> to it :
> 
> • public protocol DefaultValueProvider  
> • {  
> •  init()  
> • }  
> •  
> • extension String : DefaultValueProvider { }  
> 
> Now, this works fine if I pass a known type :
> 
> • let pproperty = PropertyFactory.createProperty(String.self)  
> 
> But, if I hold the type to be passed in in an Any.Type or 
> DefaultValueProvider.Type variable, then doing this :
> 
> •let type: Any.Type = String.self  
> •  
> •if let propertyType = type as? DefaultValueProvider.Type  
> •{  
> •  let p = PropertyFactory.createProperty(propertyType)  
> •  
> •  …  
> 
> Fails to compile with the message : Cannot invoke 'createProperty' with an 
> argument list of type '(DefaultValueProvider.Type)'
> 
> Likewise Decoder.decode(…) will not accept storing the type in an Any.Type or 
> Decodable.Type variable.
> 
> I find this odd and perplexing. Is this a known issue or has nobody yet 
> realised that this could be useful ?
> 
> Joanna
> 
> --
> Joanna Carter
> Carter Consulting
> 
> --
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
> 
> 
> End of swift-users Digest, Vol 20, Issue 13
> ***
> 
> 
> ___
> 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 Array's `append(_)` function cause `didSet`?

[Jordan Rose via swift-users]

> On Jul 7, 2017, at 22:50, Marco S Hyman via swift-users 
>  wrote:
> 
> 
>> On Jul 7, 2017, at 9:48 PM, Zhao Xin  wrote:
>> 
>> Thank you very much Marco. But What is  “outside of an initializer” really 
>> bothers me. **Both** `func bar(keysAndValues:Dictionary)` 
>> works now. **Are they really outside ?**
> 
> Uhhh, that is certainly not the results I’d have expected.  Perhaps one of 
> the  swift language lawyers can explain.

The goal is that once the initializer is completed all accesses will go through 
the setter and therefore trigger willSet/didSet behavior. Since a local 
function can be assigned to a property or something and get called later, it 
has to go through the setter as well. So the rules only apply to what's 
directly in the body of the initializer, not anything nested. (This includes 
closures, even.) It might be worth a bug against us at Apple to make this more 
explicit in the documentation, https://bugreport.apple.com 
.

We also have a bug where 'defer' can trigger willSet and didSet behavior as 
well, SR-1437 . But that really is just 
a bug.

Jordan

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

Re: [swift-users] Should Array's `append(_)` function cause `didSet`?

[Jordan Rose via swift-users]

It definitely should. Can you show the code where it wasn’t being called?

Thanks!
Jordan


> On Jul 7, 2017, at 00:31, Zhao Xin via swift-users  
> wrote:
> 
> Should Array's `append(_)` functions cause the array's `didSet`?
> In my own test, it did call `didSet` in Playground. But in .swift files, it 
> didn't call.
> 
> Is this a known bug or something? Which is correct?
> 
> Xcode Version 9.0 beta 2 (9M137d)​
> 
> swift --version
> Apple Swift version 4.0 (swiftlang-900.0.45.6 clang-900.0.26)
> Target: x86_64-apple-macosx10.9
> 
> 
> Zhao Xin
> ___
> 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] cascaded do/catch bug?

[Jordan Rose via swift-users]

That does sound like a bug to me. Can you make a self-contained test case and 
file at https://bugs.swift.org/  ?

Thanks!
Jordan


> On Jun 29, 2017, at 14:00, Marco S Hyman via swift-users 
>  wrote:
> 
> This macOS code in Xcode 8.3.3:
> 
>if !fileManager.fileExists(atPath: (saveFileURL.path)) {
>do {
> 1 ==>   try fileManager.linkItem(atPath: url.path, toPath: 
> saveFileURL.path)
> 2 ==>   } catch {
>// couldn't create hard link, copy file instead
>do {
> 3 ==>   try fileManager.copyItem(at: url, to: saveFileURL)
>} catch let error as NSError {
>unexpected(error: error,
>   "Cannot copy \(url.path) to 
> \(saveFileURL.path)\n\nReason: ")
>return false
>}
>}
>}
>return true
> 
> 
> lldb tells me the code at 1 fails.  That was expected.  The app is sandboxed 
> and the security bookmark code that gives access to the destination is in 
> flux.  lldb says control transfers to 2 then falls into the do block 
> containing 3.
> 
> The code at 3 fails for the same reason.  This is when the unexpected 
> occurred.  lldb says that control transferred to 2 then to the end of the if 
> statement where the function returns true.  The catch following the do 
> containing the function “unexpected” is not entered.
> 
> Is that a bug?
> 
> As for why 1 uses path instead of URL an older version of the code had this 
> note.
> 
> // linkItemAtURL fails trying to link foo.jpg_original to somedir/foo.jpg.
> 
> 
> ___
> 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] KVC - KeyPath in Operation

[Jordan Rose via swift-users]

Hi, Muthu. This is a longstanding issue with Operation—the Objective-C name of 
the property is just "executing", but the KVO keys that the implementors used 
is "isExecuting". Swift isn't set up to deal with this difference.

Fortunately, the base implementation of Operation already knows how to send the 
KVO notifications, so you shouldn't have to override these properties at all. 
If you still want to for some other reason, you can call super instead of 
storing to a private property.

Hope that helps,
Jordan


> On Jun 13, 2017, at 06:40, somu subscribe via swift-users 
>  wrote:
> 
> Hi,
> 
> I am having trouble using KeyPath to KVC (Key Value Code) in Swift 4.
> 
> I have a subclass of Operation and I am overriding the isFinished and 
> isExecuting property.
> 
> Problem:
> - When I use KeyPath, the completionBlock of the operation is not invoked.
> - However when I use String instead of KeyPath, the completionBlock is 
> invoked.
> 
> Questions:
> - Am I missing something ? 
> - Is there a way to fix it using KeyPath ?
> 
> Code:
> 
> override var isExecuting : Bool {
> 
> get {
> return _executing //property in the class
> }
> 
> set {
> willChangeValue(for: \.isExecuting)
> _executing = newValue
> didChangeValue(for: \.isExecuting)
> }
> }
> 
> override var isFinished : Bool {
> 
> get {
> return _finished //property in the class
> }
> 
> set {
> willChangeValue(for: \.isFinished)
> _finished = newValue
> didChangeValue(for: \.isFinished)
> }
> }
> 
> 
> Configuration:
> - Xcode - 9.0 beta (9M136h) 
> - Tested on Simulator (iOS 11)
> - macOS Sierra - 10.12.5 (16F73)
> 
> 
> Thanks and Regards,
> Muthu
> ___
> 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] Mysterious “Will never be executed” warning

[Jordan Rose via swift-users]

Sure looks like one to me. In particular, it looks like SR-2729 
.

(I suspect this is because calling the method through the protocol generates a 
bit of wrapper code that then calls the original method; that wrapper code 
doesn’t have a location of its own.)

Sorry for the trouble,
Jordan


> On Jun 2, 2017, at 08:48, Rudolf Adamkovič via swift-users 
>  wrote:
> 
> I'm trying to understand "Will never be executed" warning here:
> 
> protocol FatalErrorReporterInterface {
> 
> func fail(_ message: String) -> Never
> 
> }
> 
> final class FatalErrorReporter: FatalErrorReporterInterface {
> 
> // This line emits "Will never be executed" warning
> func fail(_ message: String) -> Never {
> fatalError(message)
> }
> 
> }
> Yet another compiler bug?
> 
> https://stackoverflow.com/questions/44332850/mysterious-will-never-be-executed-warning
>  
> 
> 
> R+
> ___
> 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] Why inout protocol parameter in function work with strange

[Jordan Rose via swift-users]

I think you're missing the underlying semantic problem here:

func transform(item: inout Position) {
  item = Airplane()
}

var car = Car(x: 50)
var pos: Position = car
move(item: ) // this works, but 'pos' is now an Airplane
move(item: ) // this doesn't work because 'car' has to stay a Car

Dave Abrahams likes to phrase this lesson as "generics preserve type 
information, while protocol values erase it". In this case your Car needs to 
stay a Car, so you need the type information to be preserved.

Hope that helps,
Jordan


> On May 27, 2017, at 03:07, Zhao Xin via swift-users  
> wrote:
> 
> Because generic uses `Car` instead of `Position` when running the code, so 
> there is no casting as `car as Position` as in your original code. The 
> `T:Position` part restricts that the type conforms `Position`, but it won't 
> use `Position`, it uses the type.
> 
> Zhaoxin
> 
> On Sat, May 27, 2017 at 4:58 PM, Седых Александр via swift-users 
> > wrote:
> Thanks. Why generic function don not require memory allocate for inout 
> variable, even if it is protocol type?
> 
> 
> Пятница, 26 мая 2017, 19:35 +03:00 от Guillaume Lessard 
> >:
> 
> In your example, the compiler needs a parameter of type Position. Car is a 
> type of Position, but they are not interchangeable. See below:
> 
> > On May 26, 2017, at 00:33, Седых Александр via swift-users 
> > > wrote:
> > 
> > protocol Position {
> > var x: Double { getset }
> > }
> > 
> > struct Car: Position {
> > var x: Double
> > }
> > 
> > func move(item: inout Position) {
> > item.x += 1
> > }
> > 
> > var car = Car(x: 50)
> 
> var pos: Position = car
> 
> move(item: ) // this works.
> assert(pos.x == 51) // works
> 
> The move function as you wrote it requires the memory representation of a 
> Position variable, which Car does not have; when you assign it to a Position 
> variable, the Car struct gets accessed through an indirection layer. (There 
> was a WWDC talk about this last year or the year before.)
> 
> You may want a generic function instead:
> 
> func move(item: inout P) {
>   item.x += 1
> }
> 
> move(item: ) // this works, since it’s now calling the generic function.
> assert(car.x == 51) // works
> 
> Cheers,
> Guillaume Lessard
> 
> 
> 
> ___
> 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] override-like keyword for default implementations

[Jordan Rose via swift-users]

> On May 16, 2017, at 10:44, Charles Srstka via swift-users 
>  wrote:
> 
>> On May 16, 2017, at 12:32 PM, Nevin Brackett-Rozinsky via swift-users 
>> > wrote:
>> 
>> There is not.
>> 
>> At some point in the future, I believe the plan is to eventually allow 
>> default implementations to be written in-line within the protocol 
>> declaration itself. In other words, the fact that default implementations 
>> currently must appear in extensions, is a temporary limitation that has not 
>> yet been a priority to address.
>> 
>> Once we gain the ability to define default implementations within protocols 
>> themselves, rather than extensions, then your use-case will “just work” (at 
>> least as long as you control the protocol anyway). I wouldn’t hold my breath 
>> though, as that behavior will not appear this year, and the plans for next 
>> year have not been hashed out yet.
> 
> Even that won’t completely solve the problem, though, because:
> 
> protocol P {
>   func foo() {
>   // default implementation
>   }
> }
> 
> struct S: P {
>   func foo() {
>   // overriden implementation
>   }
> }
> 
> If foo is refactored here, S will start getting the wrong implementation of 
> it, silently, with no warning.
> 
> People have tried to bring up proposals to add some sort of “override”-like 
> keyword for protocols on swift-evolution a bunch of times, but it always gets 
> shouted down by certain members of the group, so we’re probably permanently 
> stuck with this situation where a supposedly “protocol-oriented” language is 
> not safe to use with protocols.

I object to this characterization. People have tried to bring up such 
proposals, and it is invariably pointed out (usually by the same group of us) 
that these proposals don't discuss retroactive modeling, and then the thread 
dies. I can't remember a case where the proposal author actually incorporates 
this feedback into their proposal to handle retroactive modeling, or extension 
members of one protocol being used as the default implementation of another 
protocol.

(This just means the problem space is more difficult than the proposer 
initially thought, and they're not going to take that on right now, which is 
fine. It's a learning experience; designing features that interact well with 
the whole language is not easy! We should probably add this to the "commonly 
proposed" list, though, so that we don't keep retreading that initial ground.)

Jordan

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

Re: [swift-users] How to reference a generic function when a concrete version also exists?

[Jordan Rose via swift-users]

> On May 2, 2017, at 16:53, David Sweeris via swift-users 
>  wrote:
> 
>> 
>> On May 2, 2017, at 4:39 PM, Nevin Brackett-Rozinsky via swift-users 
>> > wrote:
>> 
>> If I write a generic function like this:
>> 
>> func f(_ x: T) { print("Generic: \(x)") }
>> 
>> I can pass it to another function like this:
>> 
>> func g(_ fn: (Int) -> Void) { fn(0) }
>> g(f)// Prints “Generic: 0”
>> 
>> However if I *also* write a non-generic function like this:
>> 
>> func f(_ x: Int) { print("Int: \(x)") }
>> 
>> Then when I make the same call as before:
>> 
>> g(f)// Prints “Int: 0”
>> 
>> It passes in the new, non-generic version.
>> 
>> Is there something I can do, with both versions of f defined, to pass the 
>> generic f into g?
> 
> Not that I know of. Once the code path gets to g(), the compiler knows that 
> the function is specifically an (Int)->Void, as opposed to the generic 
> (T)->Void, and it’ll always go for the most specific overload. AFAIK, anyway.

You can always throw away infromation by making a new generic context:

func callF(_ x: T) -> Void {
  f(x)
}
g(callF)

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

Re: [swift-users] [swift-dev] Guarantees of Tuples as Fixed Sized (stack allocated) Arrays

[Jordan Rose via swift-users]

> On Apr 28, 2017, at 16:28, John McCall via swift-users 
>  wrote:
> 
>> On Apr 28, 2017, at 7:03 AM, Johannes Weiss via swift-dev 
>> > wrote:
>> Hi swift-users,
>> 
>> (sorry for the cross post to swift-dev, but wasn't sure where it belongs)
>> 
>> I tried to find guarantees about the memory layout Swift tuples but couldn't 
>> find anything. The reason I ask is because I'd like to use them as fixed 
>> sized (stack allocated) arrays. I'm pretty sure they're actually not 
>> guaranteed to be stack allocated but highly likely I assume :).
> 
> Tuples are guaranteed to use a standard C-style layout wherever that layout 
> is ABI-observable, e.g. when you construct an UnsafePointer to one.

Ah, is this true for non-homogeneous tuples? I thought we only guaranteed it 
for homogeneous ones.

Jordan

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

Re: [swift-users] Are all extensions from all modules exported on mass?

[Jordan Rose via swift-users]

It's a longstanding bug, but a bug we can't fix easily, and one whose fix would 
probably break user code. It's tracked by SR-3908 
. (The description's a little different 
but it's the same underlying issue.)

Jordan


> On Apr 19, 2017, at 22:13, Howard Lovatt via swift-users 
>  wrote:
> 
> Hi,
> 
> If I have the *same* extension in two *different* modules, ModuleA and 
> ModuleB, and ModuleC uses both modules, but in *seperate* files, then there 
> is still ambiguity about which extension to call:
> 
> ModuleA
> A.swift
> public protocol P {
> func m() -> String
> }
> extension Int: P {
> public func m() -> String { return "AP.m" }
> }
> ModuleB
> B.swift
> public protocol P {
> func m() -> String
> }
> extension Int: P {
> public func m() -> String { return "BP.m" }
> }
> ModuleC
> A.swift
> import ModuleA
> func am(_ i: Int) -> String { return i.m() }
> B.swift
> import ModuleB
> func bm(_ i: Int) -> String { return i.m() }
> main.swift
> let i = 0
> print(am(i))
> print(bm(i))
> 
> Gives the following errors when built:
> 
> sunzero-ln:ModuleC lov080$ swift build
> Fetching /Users/lov080/Google Drive/Swift/Examples/Example Module 
> Clashes/ModuleA
> Fetching /Users/lov080/Google Drive/Swift/Examples/Example Module 
> Clashes/ModuleB
> Cloning /Users/lov080/Google Drive/Swift/Examples/Example Module 
> Clashes/ModuleA
> Resolving /Users/lov080/Google Drive/Swift/Examples/Example Module 
> Clashes/ModuleA at 1.0.0
> Cloning /Users/lov080/Google Drive/Swift/Examples/Example Module 
> Clashes/ModuleB
> Resolving /Users/lov080/Google Drive/Swift/Examples/Example Module 
> Clashes/ModuleB at 1.0.0
> Compile Swift Module 'ModuleB' (1 sources)
> Compile Swift Module 'ModuleA' (1 sources)
> Compile Swift Module 'ModuleC' (3 sources)
> /Users/lov080/Google Drive/Swift/Examples/Example Module 
> Clashes/ModuleC/Sources/B.swift:3:38: error: ambiguous use of 'm()'
> func bm(_ i: Int) -> String { return i.m() }
>  ^
> ModuleA.Int:2:17: note: found this candidate
> public func m() -> String
> ^
> ModuleB.Int:2:17: note: found this candidate
> public func m() -> String
> ^
> /Users/lov080/Google Drive/Swift/Examples/Example Module 
> Clashes/ModuleC/Sources/A.swift:3:38: error: ambiguous use of 'm()'
> func am(_ i: Int) -> String { return i.m() }
>  ^
> ModuleA.Int:2:17: note: found this candidate
> public func m() -> String
> ^
> ModuleB.Int:2:17: note: found this candidate
> public func m() -> String
> ^
> :0: error: build had 1 command failures
> error: exit(1): 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-build-tool
>  -f /Users/lov080/Google\ Drive/Swift/Examples/Example\ Module\ 
> Clashes/ModuleC/.build/debug.yaml
> 
> Is this the expected behaviour or a bug?
> 
> Thanks in advance for any help,
> 
>   -- Howard.
> ___
> 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] Can't access Swift class from Objective-C

[Jordan Rose via swift-users]

Hey, Rick. I think we'd need a bit more information to really diagnose this—in 
particular, the class declaration in Swift—but here are some possibilities:

- Classes that don't inherit from NSObject are not exposed to Objective-C
- Classes with any generic ancesters are not exposed to Objective-C, even if 
they themselves are not generic. (There's an implementation reason for this; 
it's not just the compiler being capricious.)
- In frameworks, only public and open classes are included in the generated 
header, since it's part of your framework's public interface.

Are you in any of these situations?

Jordan


> On Apr 17, 2017, at 20:18, Rick Mann via swift-users  
> wrote:
> 
> My Objective-C file is importing "Module-Swift.h", and that file has some of 
> my other Swift classes, but not the one I just wrote. I've tried making the 
> class public, but I didn't need to do that on any of the others.
> 
> I've tried cleaning the build folder of my Xcode project, but I get the same 
> result.
> 
> Any suggestions? Thanks!
> 
> -- 
> 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] withoutActuallyEscaping example question

[Jordan Rose via swift-users]

> On Mar 26, 2017, at 01:14, 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.

It seems like we could just not take escaping-ness into account at all, and 
only diagnose if it mismatches. We'd have to decide if we want that behavior, 
though.

Jordan

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

Re: [swift-users] Quick Question about ExpressibleByStringLiteral

[Jordan Rose via swift-users]

Andrew Bennett is two steps ahead of you. :-) 
https://github.com/apple/swift/pull/7125 


Jordan

> On Mar 9, 2017, at 17:59, David Sweeris via swift-users 
>  wrote:
> 
> If my type doesn’t know/care about the difference between a normal “String" 
> and an “ExtendedClusterScalarGraphemeLiteralUnicodeTypeCluster” (or whatever 
> those other literal types are called), is there anything wrong with doing 
> this?
> public protocol EasilyExpressibleByStringLiteral : ExpressibleByStringLiteral 
> {
> typealias StringLiteralType = String
> }
> extension EasilyExpressibleByStringLiteral where StringLiteralType == String {
> public init(unicodeScalarLiteral value: String.UnicodeScalarLiteralType) {
> self.init(stringLiteral: String(describing: value))
> }
> public init(extendedGraphemeClusterLiteral value: 
> String.ExtendedGraphemeClusterLiteralType) {
> self.init(stringLiteral: String(describing: value))
> }
> }
> because then I only have to write the one init function:
> public struct MyType : EasilyExpressibleByStringLiteral {
> public init(stringLiteral value: StringLiteralType) {...}
> }
> and the compiler will stop complaining about my type not conforming to the 
> other two protocols. Because I’ve scanned the docs, and I can’t even figure 
> out how to create an ExtendedGraphemeClusterLiteral, let alone come up with a 
> reason why I’d want to treat it differently than a regular String when using 
> it to initialize an instance of MyType.
> 
> - Dave Sweeris
> ___
> 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] Confusing Error localizedDescription output

[Jordan Rose via swift-users]

'localizedDescription' isn't a requirement of the Error protocol, which means 
it's not a customization point. You need to actually conform to LocalizedError 
and provide a valid 'errorDescription' instead.

(It's too bad that your second test works at all, since MyError doesn't conform 
to LocalizedError. Unfortunately NSError does conform to LocalizedError, and 
all Errors can be bridged to NSError.)

If you're interested, you can find more information about the design in its 
proposal, SE-0112 
.

Hope this helps,
Jordan


> On Feb 28, 2017, at 12:54, Jon Shier via swift-users  
> wrote:
> 
> Swifters:
>   I have a custom error enum:
> 
> enum MyError: Error {
> 
>case network(error: Error)
>case json(error: Error)
>case value(error: Error)
> 
>var localizedDescription: String {
>switch self {
>case let .network(error): return error.localizedDescription
>case let .json(error): return error.localizedDescription
>case let .value(error): return error.localizedDescription
>}
>}
> 
> }
> 
> However, the localizedDescription output is odd to me. When the value is 
> treated as:
> 
> Error:  po error.localizedDescription
> "The operation couldn’t be completed. (MyApp.MyError error 1.)”
> 
> LocalizedError:  po (error as! LocalizedError).localizedDescription
> "The operation couldn’t be completed. (MyApp.MyError error 1.)”
> 
> MyError: Error:  po (error as! MyError).localizedDescription
> "JSON could not be serialized because of error:\nThe data couldn’t be read 
> because it isn’t in the correct format."
> 
> Shouldn’t my implementation of localizedDescription take precedence in all 
> cases here? (This is Xcode 8.3b3).
> 
> 
> 
> Jon
> ___
> 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] Postponing owned object deinitialization

[Jordan Rose via swift-users]

> On Feb 27, 2017, at 10:53, Ole Begemann via swift-users 
>  wrote:
> 
> On 27/02/2017 19:34, Nate Chandler via swift-users wrote:
>> Hi Ole,
>> 
>> A quick follow-up--are you suggesting calling withExtendedLifetime
>> inside the closure passed to async, as below?
>> 
>> class AsyncHandle {
>> 
>>let handle: Handle
>> 
>>deinit {
>>let handle: Handle = self.handle
>>q.async {
>>withExtendedLifetime(handle) {}
>>}
>>}
>> }
> 
> Yes, that's what I'm suggesting. Sorry I didn't make that clear before. Since 
> you mentioned that you couldn't use the stdlib's _fixLifetime function, I 
> just wanted to point out that there is a public function in the stdlib for 
> this purpose.
> 
>> If so, it seems that that may be a final answer to (3).  It does raise
>> an additional question, however:
>> 
>> (6) Would we expect calling withExtendedLifetime to have different
>> behavior from calling an @inline(never) function from a closure enqueued
>> async from deinit?
> 
> Yeah, I don't know the answer, sorry.

I'm not an optimizer person, but expecting '@inline(never)' to mean anything 
other than "don't inline this" is probably set for failure. The optimizer is 
still allowed to look at the body of the function. withExtendedLifetime is 
implemented more carefully to prevent eliding the capture.

That said, if you're not on when the outer deinit gets called 'q', you still 
have a race—it's possible that 'q' will execute the block you give it before 
the deinitializer exits! I don't think there's a good way to avoid this other 
than to make 'handle' optional (or ImplicitlyUnwrappedOptional) and explicitly 
set it to nil before enqueuing the "deallocation block".

Jordan

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

Re: [swift-users] Ambiguous reference to members of FileHandle

[Jordan Rose via swift-users]

#selector(FileHandle.readToEndOfFileInBackgroundAndNotify as (FileHandle) -> 
(Void) -> Void)

Sorry. :-(
Jordan


> On Feb 22, 2017, at 09:13, Dmitry Shevchenko via swift-users 
>  wrote:
> 
> #selector(FileHandle.readToEndOfFileInBackgroundAndNotify) throws an error:
>   Ambiguous use of 'readToEndOfFileInBackgroundAndNotify'
> 
> So I've tried to specify it a bit more (notice the parens):
> #selector(FileHandle.readToEndOfFileInBackgroundAndNotify())
>   Ambiguous reference to member 
> 'readToEndOfFileInBackgroundAndNotify(forModes:)'
> 
> So I've tried to cast it to a Void -> Void func:
> #selector(FileHandle.readToEndOfFileInBackgroundAndNotify as (Void) -> Void)
>   Ambiguous reference to member 
> 'readToEndOfFileInBackgroundAndNotify(forModes:)'
> 
> How do I settle this one?
> 
> Method signatures in the generated header are:
> open func readToEndOfFileInBackgroundAndNotify(forModes modes: [RunLoopMode]?)
> open func readToEndOfFileInBackgroundAndNotify()
> ___
> 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] Associativity of && and || operator

[Jordan Rose via swift-users]

Remember too that in Swift the operator is decoupled from its implementation. 
Plenty of people are using && for things like constraint or predicate DSLs, 
where it doesn't short-circuit. Of course, a non-associative version of && 
would be quite surprising, so even a custom implementation probably shouldn't 
rely on the left-associativity.

There's one other reason to prefer this way, though, and that's complexity in 
the AST. Recall that the RHS of the standard && (and ||, and ??) is an 
auto-closure—Swift's way to avoid the eager evaluation of the argument. 
Right-associativity would result in heavily-nested autoclosures, and even 
though they'll all be flattened as part of compilation, the AST representation 
still has to model them that way. So purely from a compiler-implementation 
perspective left-associativity has a small edge.

I think you're right that we should have picked right-associativity anyway, but 
at this point I'm not sure it's worth changing it.

Jordan


> On Feb 17, 2017, at 01:03, Saagar Jha via swift-users  
> wrote:
> 
> Left associativity is most likely just a holdover from the C family–not 
> conforming with it would break expectations for programmers coming from these 
> languages. And as you mentioned, the compiler will short-circuit the 
> condition and stop evaluating as soon as it encounters a false condition, so 
> there’s no measurable benefit.
> 
> Saagar Jha
> 
>> On Feb 17, 2017, at 12:54 AM, rintaro ishizaki via swift-users 
>> > wrote:
>> 
>> Hello all,
>> 
>> Why the associativity of Logical{Conjunction,Disjunction}Precedence is 
>> "left"?
>> 
>> If you write: A && B && C, it's grouped as (A && B) && C.
>> This means that the && function is always called twice: (&&)((&&)(A, B), C).
>> I feel "right" associativity is more natural:  (&&)(A, (&&)(B, C)),
>> because the && function is called only once if A is false.
>> 
>> I know that redundant && calls are optimized away in most cases.
>> I also know C and C++ standard says: "The && operator groups left-to-right", 
>> and most programming languages follow that.
>> 
>> But why not "right" associativity?
>> What is the difference between logical operators and ?? operator that has 
>> "right" associativity?
>> 
>> ___
>> 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] ambiguous minus operator

[Jordan Rose via swift-users]

> As usual the candidates are unknown.

Just on this particular note, this is a terrible presentation issue and totally 
something we Apple people need to fix in Xcode, but you can usually see what 
the candidates were in the build log.

Jordan


> On Feb 16, 2017, at 07:56, J.E. Schotsman via swift-users 
>  wrote:
> 
> Hello,
> 
> I am trying to define an operator that subtracts dispatch times:
> 
> #import Dispatch
> 
> func -( time1: DispatchTime, time2: DispatchTime ) -> DispatchTimeInterval
>   {
>   return DispatchTimeInterval.nanoseconds( time2.uptimeNanoseconds - 
> time1.uptimeNanoseconds )
>   }
> 
> Compiler says: Ambiguous use of operator ‘-'
> Found this candidate
> Found this candidate
> 
> As usual the candidates are unknown.
> 
> What am I doing wrong?
> 
> Jan E.
> ___
> 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] Custom operators in a framework

[Jordan Rose via swift-users]

Interesting. I actually see two errors:

/Users/jrose/Desktop/SwifterJSON/App/AppDelegate.swift:19:18: error: ambiguous 
operator declarations found for operator
json["root"] &= 4
 ^
:0: note: found this matching operator declaration
:0: note: found this matching operator declaration
/Users/jrose/Desktop/SwifterJSON/App/AppDelegate.swift:19:18: error: operator 
is not a known binary operator
json["root"] &= 4
 ^

which actually seems correct in retrospect: '&=' is already a valid operator in 
the 'Swift' library, and you're redefining it rather than just reusing that 
definition. It works if I either remove your `infix operator &=` declaration 
(and leave all the implementations in place), or if I change to an operator 
that isn't already defined. Can you file a bug at bugs.swift.org 
 for the lousy diagnostics, at least?

Jordan


> On Feb 3, 2017, at 11:34, Rien  wrote:
> 
> This is the “defining” package/module:
> 
> https://github.com/Balancingrock/SwifterJSON 
> 
> 
> For the consuming package simply generate a new executable and put the 
> following in main.swift:
> 
> 
> import SwifterJSON
> 
> 
> // Note: Error disappears when the line below is un-commented
> 
> // infix operator &=
> 
> var json = VJson()
> 
> json["root"] &= 4
> 
> print(json.code)
> 
> 
> (seems I have hit a snag with github, otherwise I would create a new repo for 
> the executable… sorry for that.)
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl 
> Blog: http://swiftrien.blogspot.com 
> Github: http://github.com/Balancingrock 
> Project: http://swiftfire.nl 
> 
> 
> 
> 
> 
>> On 03 Feb 2017, at 18:36, Jordan Rose > > wrote:
>> 
>> The operator itself. If you’re not seeing that behavior, that’s a bug! Do 
>> you have a small test case that reproduces it? (I guess it would take two 
>> modules regardless, so either a SwiftPM package or an Xcode project would do 
>> it.)
>> 
>> Jordan
>> 
>>> On Feb 3, 2017, at 09:34, Rien >> > wrote:
>>> 
>>> Are you referring to the definition of the operator (infix…) or the 
>>> availability of the function that defines the operator?
>>> 
>>> The functions are available, but I have to repeat the “infix…" everywhere I 
>>> need them.
>>> 
>>> I.e. I have a:
>>> 
>>> infix operator &=
>>> 
>>> And when I use that from another module I get “Operator is not a known 
>>> binary operator”
>>> 
>>> Once I repeat the "infix operator &=“ at the start of the file it works 
>>> fine.
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl 
>>> Blog: http://swiftrien.blogspot.com 
>>> Github: http://github.com/Balancingrock 
>>> Project: http://swiftfire.nl 
>>> 
>>> 
>>> 
>>> 
>>> 
 On 03 Feb 2017, at 18:14, Jordan Rose > wrote:
 
 Operator declarations are actually public all the time, not internal. 
 That’s itself probably a bug, but not the world-limiting one you’re 
 concerned about.
 
 Jordan
 
 
> On Feb 3, 2017, at 01:18, Rien via swift-users  > wrote:
> 
> It is possible to define custom operators in a framework, but it is not 
> possible to assign access levels to them.
> 
> As a consequence they are module internal and cannot be used outside the 
> framework.
> 
> Each project needs to redefine the custom operators in order to use them 
> in that project.
> 
> What is the rationale behind that?
> 
> Or is it a bug?
> 
> Are there other ways to accomplish this?
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl 
> Blog: http://swiftrien.blogspot.com 
> Github: http://github.com/Balancingrock 
> Project: http://swiftfire.nl 
> 
> 
> 
> 
> 
> ___
> 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] Custom operators in a framework

[Jordan Rose via swift-users]

Operator declarations are actually public all the time, not internal. That’s 
itself probably a bug, but not the world-limiting one you’re concerned about.

Jordan


> On Feb 3, 2017, at 01:18, Rien via swift-users  wrote:
> 
> It is possible to define custom operators in a framework, but it is not 
> possible to assign access levels to them.
> 
> As a consequence they are module internal and cannot be used outside the 
> framework.
> 
> Each project needs to redefine the custom operators in order to use them in 
> that project.
> 
> What is the rationale behind that?
> 
> Or is it a bug?
> 
> Are there other ways to accomplish this?
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
> ___
> 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] Non-escaping closure not allowed to do let initialization?

[Jordan Rose via swift-users]

Hi, Shawn. "Non-escaping" doesn't mean "guaranteed to be called at least once", 
nor "guaranteed to be called at most once". You'd need both of those conditions 
to make this okay.

There's been some discussion on the swift-evolution list about adding such an 
annotation, but nothing's been seriously proposed yet. As an additive change to 
Swift, it isn't something that needs to happen now, just an improvement we 
could make.

Jordan


> On Feb 2, 2017, at 12:33, Shawn Erickson via swift-users 
>  wrote:
> 
> I attempted the following code which involves passing a closure – one that 
> doesn't escape obviously – but the compiler complains that I need to make 
> formHeaders and formStream vars.
> 
> public func finish() throws -> ([String:String],InputStream) {
> let formHeaders: [String:String]
> let formStream: InputStream
> try finish({ (fh, fs, _) in
> formHeaders = fh
> formStream = fs
> })
> return (formHeaders, formStream)
> }
> 
> If I have code like this however the use of let is ok.
> 
> public func finish() throws -> ([String:String],InputStream) {
> let formHeaders: [String:String]
> let formStream: InputStream
> if self.finalized.get() {
> formHeaders = ["foo":"bar"]
> //formStream = ...
> }
> else {
> formHeaders = [:]
> //formStream = ...
> // or throw something here
> }
> return (formHeaders, formStream)
> }
> 
> If the closure is non-escaping and the code as structured the compiler should 
> be able to reason about the initialization correctness of those lets...? 
> ...or am I missing something?
> 
> -Shawn
> ___
> 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] Static type when expecting dynamic type

[Jordan Rose via swift-users]

Seems like a bug, and moreover it seems like a regression from Swift 3.0. Mind 
filing a report at bugs.swift.org ?

Thanks!
Jordan

> On Feb 1, 2017, at 20:49, Howard Lovatt via swift-users 
>  wrote:
> 
> Hi All,
> 
> Anyone know what is going on here:
> 
> //: Closure picks up static type not dynamic
> 
> class MutableReference {
> init() {
> guard type(of: self) != MutableReference.self else {
> fatalError("MutableReference is an abstract class; create a 
> derrivative of MutableReference")
> }
> }
> var value: T {
> get {
> fatalError("Calculated property value getter should be 
> overridden")
> }
> set {
> fatalError("Calculated property value setter should be 
> overridden")
> }
> }
> }
> 
> class DefaultMutableReference: MutableReference {
> private var _value: T
> override var value: T {
> get {
> return _value
> }
> set {
> _value = newValue
> }
> }
> init(_ value: T) {
> _value = value
> }
> }
> 
> let e: (MutableReference<[Int]>, Int) -> Void = { $0.value.append($1) }
> let dmr = DefaultMutableReference([2])
> dmr.value // [2]
> e(dmr, 2) // fatal error: Calculated property value getter should be 
> overridden
> dmr.value // Expect [2, 2]  
> If I change `e` to:
> 
> let e: (DefaultMutableReference<[Int]>, Int) -> Void = { 
> $0.value.append($1) }
> It works fine.
> 
> IE the closure is using the static type of its first argument and not 
> dynamically dispatching.
> 
> Am I doing something wrong? Is there a way round where I can still use the 
> base class for `e`?
> 
> 
> 
> Thanks for any help in advance,
> 
> -- Howard.
> 
> ___
> 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] Initializers

[Jordan Rose via swift-users]

> On Jan 27, 2017, at 11:04, Slava Pestov via swift-users 
>  wrote:
> 
>> 
>> On Jan 27, 2017, at 10:39 AM, tuuranton--- via swift-users 
>> > wrote:
>> 
>> Yes, but why?
>> 
>> What's the rationale for this?
>> 
>> What would be so bad about allowing overriding a non-failable initializer 
>> with a failable initializer?
> 
> If the non-failable initializer witnesses a non-failable protocol 
> requirement, and the subclass overrides it, what should be the runtime 
> behavior if the subclass initializer returns nil? The caller won’t expect it, 
> since the caller is calling a non-failable initializer.

This particular objection only applies to 'required' initializers, though.


> 
> For similar reasons, you cannot override a method that returns a non-optional 
> value with a method returning an optional value.

Yes, this is true.

Jordan

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

Re: [swift-users] SPM & Library with bridging header

[Jordan Rose via swift-users]

Hi, Rien. Libraries don’t support bridging headers because the client of the 
library has to be able to import the header, and arbitrary bridging headers may 
conflict. (This is actually the primary purpose of modules for Objective-C: to 
declare a group of headers that are self-contained—besides what other modules 
they import—and can therefore be imported earlier or later without difficulty.) 
The compiler will mildly try to stop you from doing this if it can figure out 
you’re building a library, but it’s a bad idea no matter what. Even if 
everything appears to compile fine, it’s likely you’ll get inscrutable errors 
when trying te debug anything that uses your library.

The particular difference between Xcode-created frameworks and 
SwiftPM-generated libraries is that Xcode frameworks are set up to be 
mixed-source, using the Objective-C public umbrella header in place of a 
bridging header. SwiftPM doesn’t support mixed-source targets. (Since I don’t 
work on SwiftPM myself I don’t know if there are any public plans to do so.)

The recommended solution is to group your Objective-C headers into modules 
(usually just frameworks) and import them that way, rather than to jam them in 
via a bridging header.

Sorry for the trouble,
Jordan


> On Jan 20, 2017, at 08:49, Rien via swift-users  wrote:
> 
> I noticed something strange about Xcode and SPM concerning the capability to 
> generate Libraries.
> 
> When I try to create a Library in Xcode and then want to add an Objective-C 
> bridging header, that is denied. It claims that bridging is not supported for 
> Libraries.
> 
> When I create an Xcode project through the SPM (with “swift package 
> generate-xcodeproj”) then I can use bridging headers, even though the end 
> result is a library.
> 
> Question: Is this a viable work around? or are there hidden dangers that 
> might not be immediately apparent?
> 
> As a side note: SPM complains about multiple languages and currently only 
> supports pure Swift modules.
> This creates the strange situation that I now use SPM to create an xcode 
> project and then use Xcode to create bridged mixed language libraries.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
> 
> 
> 
> 
> ___
> 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 struct from C API (FUSE) with member init

[Jordan Rose via swift-users]

Hey, Dennis. You should be able to use backticks to escape Swift keywords, 
including this one. However, that doesn't actually work yet, due to SR-1660 
. There's been some progress towards 
fixing this, but it's not ready to go into a release yet.

If you can modify the header, the easiest answer is to add a swift_name 
attribute (`__attribute__((swift_name("initOp")))`). If you can't, the next 
best thing is probably to write a static inline wrapper function in C, 
unfortunately.

Sorry for the inconvenience,
Jordan

> On Jan 8, 2017, at 01:11, Dennis Schafroth via swift-users 
>  wrote:
> 
> 
> Is there any solutions to importing structs from C API where there is a 
> member init.
> 
> The fuse_operations is a struct with callbacks functions and one is called 
> init 
> 
> struct fuse_operations {
> 
>   void *(*init) (struct fuse_conn_info *conn);
> }
> 
> This seems to collide with the Swift init method on imported C struct
> 
> 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] unsafe memory model questions

[Jordan Rose via swift-users]

Hi, Ray. Most of the pointer model is covered in the original proposal for the 
UnsafeRawPointer type, SE-0107 
.
 That's a good place to find answers to pointer- and memory-related questions 
in general.

The short forms are "yes, binding memory to types is mostly about communication 
with the optimizer, but it may also be checkable at run-time some day", and 
"it's okay to skip 'deinitialize' and use assignment instead of 'initialize' if 
and only if the element type is trivial 
".

Additionally, as far as I know, mutation through UnsafeMutableRawBufferPointer 
doesn't count as binding any type to the memory, but Andy will have to check me 
on that.

Best,
Jordan


> On Dec 11, 2016, at 14:51, Ray Fix via swift-users  
> wrote:
> 
> Hello,
> 
> So bindMemory is part of the memory model and memory can only bind to one 
> type at a time to avoid aliasing. But what does binding actually do? Is it 
> somehow communicating with the optimizer?
> 
> A tangentially related second question, in the following example:
> 
>   let count = 3
>   let mutablePointer = UnsafeMutablePointer.allocate(capacity: count)
>   defer {
> mutablePointer.deallocate(capacity: count)
>   }
> 
>   mutablePointer.initialize(to: 1234, count: count)
>   defer {
> mutablePointer.deinitialize(count: count)  // must I do this?
>   }
> 
> Is it bad form if I don’t deinitialize and go straight to deallocate?  I can 
> see where it is important for ref types (to update ref counts, etc).  Is it 
> one of those things that the optimizer can remove for the case of value types?
> 
> Finally, if I initalize with some other means, such as with a raw buffer 
> pointer subscript, is there any need to deinitialize?  Can such memory be 
> considered initialized if I bind it with a type?
> 
>   // 1
>   let pointer = malloc(byteCount)
>   defer {
> free(pointer)
>   }
> 
>   let mutableRawBufferPointer = UnsafeMutableRawBufferPointer(start: pointer, 
> count: byteCount)
>   
>   for index in mutableRawBufferPointer.indices {
> mutableRawBufferPointer[index] = 42 + UInt8(index)
>   }
> 
> Perhaps there is a document or proposal somewhere that talks about these 
> things. Sorry if I missed it.
> 
> Thanks as always,
> 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

Re: [swift-users] Module not found in Test-Swift.h

[Jordan Rose via swift-users]

:-( I can't think of one, sorry. Mixed-source unit test targets have been a 
lower priority, especially importing the Swift side into Objective-C.

Jordan


> On Dec 9, 2016, at 10:20, David Catmull  wrote:
> 
> Done: https://bugs.swift.org/browse/SR-3381 
> 
> 
> Any suggestions for a workaround? Or should I watch the bug report for that?
> 
> On Fri, Dec 9, 2016 at 10:59 AM, Jordan Rose  > wrote:
> Hm, it definitely shouldn't be importing the app (since there's not a real 
> Objective-C module there). This might be a known issue, but I'm not sure 
> offhand. Can you file an issue at bugs.swift.org ?
> 
>> On Dec 9, 2016, at 09:10, David Catmull via swift-users 
>> > wrote:
>> 
>> In my test target, when I include the Test-Swift.h file, there is a line 
>> that says "@import MyAppName" which yields the error "Module 'MyAppName' not 
>> found". Turning on the Defines Module setting for my app target didn't help. 
>> So why is that import there, and what is required for it to be found?
>> ___
>> 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] Module not found in Test-Swift.h

[Jordan Rose via swift-users]

Hm, it definitely shouldn't be importing the app (since there's not a real 
Objective-C module there). This might be a known issue, but I'm not sure 
offhand. Can you file an issue at bugs.swift.org ?

> On Dec 9, 2016, at 09:10, David Catmull via swift-users 
>  wrote:
> 
> In my test target, when I include the Test-Swift.h file, there is a line that 
> says "@import MyAppName" which yields the error "Module 'MyAppName' not 
> found". Turning on the Defines Module setting for my app target didn't help. 
> So why is that import there, and what is required for it to be found?
> ___
> 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] Accessing the bundle of the call-site

[Jordan Rose via swift-users]

> On Dec 2, 2016, at 15:36, Rick Aurbach  wrote:
> 
> Greg,
> 
> This is looking quite strange, because I didn’t see anything like what I 
> expected.
> 
> Here’s the code that I’ve been using to test #dsohandle:
> 
> public extension String {
>   
>   public func localized(dsoHandle : UnsafeRawPointer = #dsohandle) {
>   var dlInformation : dl_info = dl_info()
>   let _ = dladdr(dsoHandle, )
>   let path = String(describing: dlInformation.dli_fname!)

^ You asked for a string describing a pointer and you got one. :-) Try 
String(cString:) instead.



>   let bundle = Bundle(path: path)
>   }
> }
> 
> which is consistent with the following excerpt from the header file:
> 
> /*
>  * Structure filled in by dladdr().
>  */
> public struct dl_info {
> 
> public var dli_fname: UnsafePointer! /* Pathname of shared object */
> 
> public var dli_fbase: UnsafeMutableRawPointer! /* Base address of shared 
> object */
> 
> public var dli_sname: UnsafePointer! /* Name of nearest symbol */
> 
> public var dli_saddr: UnsafeMutableRawPointer! /* Address of nearest 
> symbol */
> 
> public init()
> 
> public init(dli_fname: UnsafePointer!, dli_fbase: 
> UnsafeMutableRawPointer!, dli_sname: UnsafePointer!, dli_saddr: 
> UnsafeMutableRawPointer!)
> }
> public typealias Dl_info = dl_info
> 
> public func dladdr(_: UnsafeRawPointer!, _: UnsafeMutablePointer!) 
> -> Int32
> /* not POSIX */
> 
> 
> I would have expected path to look something like a URL. However, here is 
> what the debugger says (with a breakpoint on the “let bundle…” line:
> 
> 
> 
> As you can see, dli_fname doesn’t look anything like the “pathname of the 
> shared object”. Instead it looks more like the address where it was loaded. 
> Which, unfortunately, doesn’t get me any further along.
> 
> Thoughts?
> 
> Has this gotten hairy (and time consuming) enough that I should handle this 
> as a Technical Incident??
> 
> Cheers,
> 
> Rick Aurbach
> 
>> On Dec 2, 2016, at 3:08 PM, Greg Parker > > wrote:
>> 
>> On Darwin #dsohandle points to a Mach-O file header. You can pass that 
>> address to dyld but I don't see an easy way to pass it to NSBundle.
>> 
>> This might work:
>> 1. Pass #dsohandle to dladdr()
>> 2. Pass the dli_fname returned by dladdr() to NSBundle(path:).
>> 
>> 
>>> On Dec 2, 2016, at 12:50 PM, Rick Aurbach >> > wrote:
>>> 
>>> Jordan,
>>> 
>>> I agree — #dsohandle is, indeed, little known. In fact, I’m having a devil 
>>> of a time figuring out what it is and what I can do with it. It is clearly 
>>> an UnsafeRawPointer, but to what?? 
>>> 
>>> Can you offer either a reference or a few lines of code that can help me 
>>> get the information I need from it? [recall that I want the framework’s 
>>> bundle so I can find it’s localized.strings file].
>>> 
>>> Cheers,
>>> 
>>> Rick Aurbach
>>> 
 On Dec 2, 2016, at 12:56 PM, Jordan Rose > wrote:
 
 On Apple platforms, we'd probably prefer you use the little-known 
 #dsoHandle, a magic pointer that's unique to the current dylib. Parsing 
 out a module name seems incredibly brittle; the form of #function is not 
 guaranteed to be stable or useful across Swift versions.
 
 Jordan
> 
> 

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

Re: [swift-users] Accessing the bundle of the call-site

[Jordan Rose via swift-users]

Heh, we probably should document it somewhere. It is an opaque 
UnsafeRawPointer, and maybe you can't really get from there to a Bundle. The 
dladdr function can get you from an address to a particular dylib, and it's 
supposed to have the path, and maybe you could then turn that into a URL to get 
to the bundle…

As far as I know no one has done this yet in Swift, though Mike Ash has an 
example using dladdr for unrelated purposes. 
https://www.mikeash.com/pyblog/friday-qa-2014-08-29-swift-memory-dumping.html

Jordan


> On Dec 2, 2016, at 12:50, Rick Aurbach  wrote:
> 
> Jordan,
> 
> I agree — #dsohandle is, indeed, little known. In fact, I’m having a devil of 
> a time figuring out what it is and what I can do with it. It is clearly an 
> UnsafeRawPointer, but to what?? 
> 
> Can you offer either a reference or a few lines of code that can help me get 
> the information I need from it? [recall that I want the framework’s bundle so 
> I can find it’s localized.strings file].
> 
> Cheers,
> 
> Rick Aurbach
> 
>> On Dec 2, 2016, at 12:56 PM, Jordan Rose > > wrote:
>> 
>> On Apple platforms, we'd probably prefer you use the little-known 
>> #dsoHandle, a magic pointer that's unique to the current dylib. Parsing out 
>> a module name seems incredibly brittle; the form of #function is not 
>> guaranteed to be stable or useful across Swift versions.
>> 
>> Jordan
>> 
>> 
>>> On Dec 2, 2016, at 10:35, Rick Aurbach via swift-users 
>>> > wrote:
>>> 
>>> That’s clever! Thank you; I’d probably never have thought of that.
>>> 
>>> Cheers,
>>> 
>>> Rick Aurbach
>>> 
 On Dec 2, 2016, at 12:25 PM, Greg Parker > wrote:
 
> 
> On Dec 2, 2016, at 9:44 AM, Rick Aurbach via swift-users 
> > wrote:
> 
> Does anyone know if it is possible to do the following in Swift 3.x? 
> (I’ll describe the issue abstractly first, then give the use-case.)
> 
> Consider two modules: A and B. A could be either the main module of an 
> application or an embedded framework. B is a different embedded framework.
> 
> Now A contains an public extension of class X which contains a function 
> f(). Inside B, there is a reference to X.f(). Now what I want to do in 
> f() is to access information (a module name or bundle name or bundle ID 
> or something) that allows me to construct a Bundle object referring to B, 
> without f() having any external knowledge of the organization of the 
> application.
> 
> The use-case I’m thinking about is a localization extension of String 
> that works in a multi-framework application architecture without 
> requiring the caller to specify the name of the framework and/or module.
> 
> I.e., I want to write
> 
>   extension String {
>   func locate() -> String {…}
>   }
> 
> and put this extension into framework “A”. Then, from framework “B”, I 
> want to use this function from within a function f() and [somehow] figure 
> out from the runtime what the bundle of “B” is, so that I can use it’s 
> localized strings file.
> 
> I understand that from within the locate() method, I can use #function 
> and from it, parse out the module name of “A” and then use the 
> correspondence between module names and framework names to figure out the 
> bundle of “A”. BUT what I want here is the bundle resource for “B”, not 
> “A”.
 
 You should be able to use a trick similar to the one that assert() uses to 
 collect file and line numbers:
 
 func locate(caller: StaticString = #function) {
 // `caller` is the caller's #function
 }
 
 
 -- 
 Greg Parker gpar...@apple.com  Runtime 
 Wrangler
>>> 
>>> ___
>>> 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] Accessing the bundle of the call-site

[Jordan Rose via swift-users]

On Apple platforms, we'd probably prefer you use the little-known #dsoHandle, a 
magic pointer that's unique to the current dylib. Parsing out a module name 
seems incredibly brittle; the form of #function is not guaranteed to be stable 
or useful across Swift versions.

Jordan


> On Dec 2, 2016, at 10:35, Rick Aurbach via swift-users 
>  wrote:
> 
> That’s clever! Thank you; I’d probably never have thought of that.
> 
> Cheers,
> 
> Rick Aurbach
> 
>> On Dec 2, 2016, at 12:25 PM, Greg Parker > > wrote:
>> 
>>> 
>>> On Dec 2, 2016, at 9:44 AM, Rick Aurbach via swift-users 
>>> > wrote:
>>> 
>>> Does anyone know if it is possible to do the following in Swift 3.x? (I’ll 
>>> describe the issue abstractly first, then give the use-case.)
>>> 
>>> Consider two modules: A and B. A could be either the main module of an 
>>> application or an embedded framework. B is a different embedded framework.
>>> 
>>> Now A contains an public extension of class X which contains a function 
>>> f(). Inside B, there is a reference to X.f(). Now what I want to do in f() 
>>> is to access information (a module name or bundle name or bundle ID or 
>>> something) that allows me to construct a Bundle object referring to B, 
>>> without f() having any external knowledge of the organization of the 
>>> application.
>>> 
>>> The use-case I’m thinking about is a localization extension of String that 
>>> works in a multi-framework application architecture without requiring the 
>>> caller to specify the name of the framework and/or module.
>>> 
>>> I.e., I want to write
>>> 
>>> extension String {
>>> func locate() -> String {…}
>>> }
>>> 
>>> and put this extension into framework “A”. Then, from framework “B”, I want 
>>> to use this function from within a function f() and [somehow] figure out 
>>> from the runtime what the bundle of “B” is, so that I can use it’s 
>>> localized strings file.
>>> 
>>> I understand that from within the locate() method, I can use #function and 
>>> from it, parse out the module name of “A” and then use the correspondence 
>>> between module names and framework names to figure out the bundle of “A”. 
>>> BUT what I want here is the bundle resource for “B”, not “A”.
>> 
>> You should be able to use a trick similar to the one that assert() uses to 
>> collect file and line numbers:
>> 
>> func locate(caller: StaticString = #function) {
>> // `caller` is the caller's #function
>> }
>> 
>> 
>> -- 
>> Greg Parker gpar...@apple.com  Runtime 
>> Wrangler
> 
> ___
> 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] Protocol Initializer Inheritance

[Jordan Rose via swift-users]

I think this is a known issue. You can work around it by jumping through 
another function:

import Foundation
protocol MyProtocol {
 init(foo: Int, bar: String)
}

class MyOperation: Operation, MyProtocol {
 required init(foo: Int, bar: String) {
 super.init()
 }
}

private func makeMyProtoHelper() -> T {
 return T(foo: 0, bar: "bar")
}

func makeMyProto() -> T where T: Operation {
  return makeMyProtoHelper()
}

Jordan


> On Nov 18, 2016, at 16:45, Bradley Zeller via swift-users 
>  wrote:
> 
> I am trying to construct an object that conforms to a protocol `A` and also 
> sublclasses object `B`. Protocol `A` requires an initializer that will be 
> used to construct it. Xcode will attempt to autocomplete the initializer but 
> then ultimately gives the following error: 
> 
> `error: argument passed to call that takes no arguments`
> 
> Here is some sample code:
> 
> ```
> protocol MyProtocol {
>  init(foo: Int, bar: String)
> }
> 
> class MyOperation: Operation, MyProtocol {
>  required init(foo: Int, bar: String) {
>  super.init()
>  }
> }
> 
> func makeMyProto() -> T where T: Operation {
>  return T(foo: 0, bar: "bar")
> }
> 
> ```
> 
> It’s worth noting that this only fails when subclassing `Operation`. 
> Subclassing `NSObject` or several other objects seems to work. Hopefully 
> there is a way to do this. Ultimately, I just want this generic method to 
> construct a thing that is both an `Operation` and conforms to a protocol.
> 
> Any help here would be greatly appreciated. Thanks!
> -Bradley
> ___
> 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] Misleading? cannot subscript a value of type 'inout [PathPoint]' with optional field

[Jordan Rose via swift-users]

Hi, Rick. The error seems to be a little better in master:

:20:11: error: cannot convert value of type 'CGPoint?' to expected 
argument type 'inout CGPoint'
points[0].anchorPt += dv
~~^~~~

but that's still not great. So, yes, please do file a bug at bugs.swift.org 
.

Thank you!
Jordan

> On Nov 11, 2016, at 13:29, Rick Mann via swift-users  
> wrote:
> 
> I think the error I'm getting here is misleading. Should I file a bug?
> 
> import CoreGraphics
> 
> func
> +=(inLHS : inout CGPoint, inRHS : CGPoint)
> {
>inLHS.x += inRHS.x
>inLHS.y += inRHS.y
> }
> 
> struct
> PathPoint
> {
>varanchorPt:CGPoint?
> }
> 
> var points = [PathPoint()]
> 
> let dv = CGPoint(x: 0, y: 0)
> points[0].anchorPt = dv
> points[0].anchorPt += dv
> 
> 
> Playground execution failed: error: MyPlayground.playground:17:7: error: 
> cannot subscript a value of type 'inout [PathPoint]' (aka 'inout 
> Array')
> points[0].anchorPt += dv
> ~~^
> 
> 
> 
> -- 
> 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] wishing I could cast (sort of) to protocol, with associated type

[Jordan Rose via swift-users]

> On Nov 3, 2016, at 11:07, has  wrote:
> 
> Robert Nikander wrote:
>> Cc:"swift-users@swift.org"  
>> Subject: Re: [swift-users] wishing I could cast (sort of) to protocol
>>  with associated type
>> Message-ID:
>> Content-Type: text/plain; charset="utf-8"
>> 
>> The only real way to do this today is to have two layers of protocol:
>> 
>> protocol SpecialControllerBase {
>>   var currentValueBase: SpecialValue? { get }
>> }
>> protocol SpecialController: SpecialControllerBase {
>>   associatedtype SpecialValueType : SpecialValue
>>   var currentValue: SpecialValueType? { get }
>> }
>> extension SpecialController {
>>   var currentValueBase: SpecialValue? { return self.currentValue }
>> }
> 
> One other option may be to put a typealias in an extension instead of 
> declaring an associated type:
> 
> // The almost-a-generic protocol:
> 
> protocol AssProtocol {
>var xxx: AssType { get }
> }
> 
> extension AssProtocol {
>typealias AssType = Any
> }
> 
> // My concrete classes:
> 
> class MyClass1: AssProtocol {
>typealias AssType = Int
>var xxx: AssProtocol.AssType { return 1 }
> }
> 
> class MyClass2: AssProtocol {
>typealias AssType = String
>var xxx: AssProtocol.AssType { return "two" }
> }
> 
> // A generic function that uses the aforementioned protocol:
> 
> func doit(_ v: T) where T: AssProtocol.AssType {
>print(v, type(of: v))
> }
> 
> // The rare sweet joy that is 0 compiler errors AND 0 runtime crashes:
> 
> let res1 = MyClass1().xxx
> let res2 = MyClass2().xxx
> 
> doit(res1) // 1 Int.Type
> doit(res2) // two String.Type
> 
> 
> Needless to say my head is screeching "probable undefined behavior" even as I 
> type this, so caveat emptor, E, don't blame me when it eats your cat and 
> marries your wife, etc. [1] But it did finally get me out of an unspeakably 
> intractable problem with the Swift type system, thus preserving what precious 
> few last shreds of sanity I still possess. Who knows, now that I only have a 
> myriad of all-but-intractable problems left to work through, one day I might 
> even release!

To see what this is actually doing, try this instead:

func doit(_ v: T) where T: AssProtocol.AssType {
   print(T.self)
}

(and compare it with a true associated type rather than a typealias)

Associated types preserve static type information. The compiler refuses to let 
you perform operations on protocols with associated types that would throw that 
information away. You can't get around that check in today's language.

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

Re: [swift-users] What is "binding" memory?

[Jordan Rose via swift-users]

> On Nov 2, 2016, at 15:50, Dave Abrahams via swift-users 
>  wrote:
> 
> 
> on Wed Nov 02 2016, Andrew Trick  > wrote:
> 
>>> On Nov 2, 2016, at 12:58 PM, Dave Abrahams via swift-users 
>>>  wrote:
>>> 
 At the top of the migration guide is a link to the memory model 
 explanation:
 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#memory-model-explanation
 
>> 
 "A memory location's bound type is an abstract, dynamic property of the 
 memory used to formalize
 type safety.”
 
 I’m not sure I like the “prepares the memory” language myself. Binding
 memory communicates to the compiler that the memory locations are safe
 for typed access. Nothing happens at runtime--until someone writes a
 type safety sanitizer. 
>>> 
>>> Well, that's a slight overstatement IMO.  Sanitizers aside, the main
>>> reason for these binding operations is that if you leave them out,
>>> something different *will* happen at runtime... something that will make
>>> your code do the wrong thing.
>>> 
>>> What I would say is that binding the memory has no immediate runtime
>>> cost... but it's absolutely required if you want your program to behave
>>> (and sometimes behaving correctly is a little slower than misbehaving).
>> 
>> Good clarification. I really did not mean to imply that binding memory
>> to a type has no effect on runtime behavior. Taken out of context,
>> “nothing happens at runtime” is quite an understatement.
>> 
>> The original poster seemed to have the impression that the operation
>> of binding memory itself might affect program state, 
> 
> Formally speaking, it does!
> 
>> independent of any compiler optimization. I want to make it clear that
>> a call to bindMemory(to:capacity:) has no observable runtime side
>> effects at the point of the call. 
> 
> Only because you can't observe what memory is bound to.
> 
>> But I need to throw in an exemption for future sanitizers.
> 
> I don't think you do; sanitizer actions are allowed under undefined
> behavior.

I think the difference here is that sanitizers affect program characteristics 
even for correct programs. Introducing a sanitizer can reduce optimization 
opportunities, changing an algorithm’s complexity. And of course, there’s 
always a bit of bookkeeping code being executed that wouldn’t be there 
otherwise.

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

Re: [swift-users] wishing I could cast (sort of) to protocol with associated type

[Jordan Rose via swift-users]

The only real way to do this today is to have two layers of protocol:

protocol SpecialControllerBase {
  var currentValueBase: SpecialValue? { get }
}
protocol SpecialController: SpecialControllerBase {
  associatedtype SpecialValueType : SpecialValue
  var currentValue: SpecialValueType? { get }
}
extension SpecialController {
  var currentValueBase: SpecialValue? { return self.currentValue }
}

Supporting this natively is the feature called generalized existentials, 
described in the “Generics Manifesto 
”
 of potential future Swift features. This has a lot of design and 
implementation considerations, so it’s not planned to happen right away, but 
it’s definitely a heavily-requested feature.

Jordan


> On Nov 2, 2016, at 12:31, Robert Nikander via swift-users 
>  wrote:
> 
> Hi,
> 
> In the following code, I want to test if x is a `SpecialController`. If it 
> is, I want to get the `currentValue` as a `SpecialValue`. How do you do this? 
> If not with a cast, then some other technique.
> 
> I understand the error, and that SpecialController by itself is not a simple 
> type to cast to. But it seems like what I’m saying is logically consistent 
> and not that complicated. Is there really no way to *say* it in Swift?
> 
>protocol SpecialController {
>associated type SpecialValueType : SpecialValue
>var currentValue: SpecialValueType? { get }
>}
>...
>var x: AnyObject = ...
>if let sc = x as? SpecialController {  // does not compile
> 
> Rob
> ___
> 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] Autoreleasepool for Ubuntu

[Jordan Rose via swift-users]

> On Nov 2, 2016, at 13:36, Joe Groff via swift-users  
> wrote:
> 
>> 
>> On Nov 2, 2016, at 1:16 PM, Bernardo Breder via swift-users 
>> > wrote:
>> 
>> In my http server i want to manager the memory all the time that we close a 
>> socket, like the example of manager in this link: 
>> http://stackoverflow.com/questions/25860942/is-it-necessary-to-use-autoreleasepool-in-a-swift-program
>>  
>> 
>> 
>> Algorithm that show the ideia:
>> 
>> func request(content) { ... }
>> 
>> let server = myserver()
>> while let client = server.accept() {
>>   autoreleasepool {
>> client.send(request(client.read()))
>> client.close()
>>   }
>> }
> 
> Is `client` really getting autoreleased somewhere? autoreleasepool shouldn't 
> normally be necessary. The client will be released when you go out of scope.

The problem is that on Apple platforms, the Foundation APIs used to implement 
the client autorelease things all over the place, so you need an autorelease 
pool somewhere to clean up the mess intermediate objects returned at +0.

Jordan

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Jordan Rose via swift-users]

I don’t know, this isn’t really a good Swift API either. Some of the other bare 
pointer cases we changed to return arrays instead for this reason, like 
String’s version of cString(using:). 
https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSStringAPI.swift#L413

I am actually in favor of having a minimal shim, but I’d rather it do nothing 
like Joe’s case than to start allowing arbitrarily-delayed deinitialization 
like this.

Jordan


> On Nov 2, 2016, at 13:00, Philippe Hausler  wrote:
> 
> See:
> 
> https://github.com/apple/swift-corelibs-foundation/blob/d015466450b2675037c6f1ace8e17e73050ccfb9/Foundation/NSURL.swift#L561
>  
> 
> 
> This is far and few between of cases that it would be useful but there are a 
> few APIs that we have not been able to express without being able to 
> autorelease items. Most of which we have either forbidden in Linux or 
> redesigned because they were sub-par swift experiences. However it seems 
> reasonable to have a minimal shim to provide cross platform code 
> compatibility even if it does next to nothing. That way trivial code as the 
> original issue showed can easily be directly compiled on either platform 
> without littering gnarly #ifdefs about.
> 
>> On Nov 2, 2016, at 12:55 PM, Jordan Rose > > wrote:
>> 
>> I’m confused about this. Shouldn’t you be able to get away with using +1 
>> convention everywhere? What needs to have arbitrary lifetime-extension in an 
>> ARC-ified language?
>> 
>> Jordan
>> 
>>> On Nov 2, 2016, at 12:23, Philippe Hausler >> > wrote:
>>> 
>>> So there are issues we have in swift-corelibs that suffer(leak) because we 
>>> don't have ARPs on Linux. It would be super nice to have a retain until 
>>> scope end concept for swift core libs where autorelease would be an 
>>> accessor in unmanaged that would retain the object until the arp ends scope.
>>> 
>>> Sent from my iPhone
>>> 
>>> On Nov 2, 2016, at 10:17 AM, Jordan Rose >> > wrote:
>>> 
 
> On Nov 2, 2016, at 09:42, Joe Groff via swift-users 
> > wrote:
> 
>> 
>> On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users 
>> > wrote:
>> 
>> Hello,
>> 
>> I want to create a mini http server project and execute at Ubuntu 15. 
>> The Xcode compile and access the function "autoreleasepool", but when i 
>> compile the same code at Ubuntu, this function not found
>> 
>> For example, i can compile the code above at Xcode:
>> 
>> while true {
>>autoreleasepool {
>>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
>> 1\r\n\r\na".data(using: .utf8)!
>>}
>> }
>> 
>> But when i try to compile at Ubuntu:
>> 
>> git@breder:~$ cat main.swift 
>> import Foundation
>> 
>> while true {
>>autoreleasepool {
>>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
>> 1\r\n\r\na".data(using: .utf8)!
>>}
>> }
>> 
>> git@breder:~$ swiftc main.swift 
>> main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
>>autoreleasepool {
>>^~~
> 
> Autoreleasepools are an ObjC compatibility feature. They aren't necessary 
> in standalone Swift.
 
 But they are necessary in Swift programs on Apple platforms (that don’t 
 use RunLoop, anyway). Philippe, what do you think? What’s the right way to 
 write cross-platform code that doesn’t use RunLoop or dispatch_main for an 
 implicit autorelease pool?
 
 (/me remembers +[NSAutoreleasePool drain] from the ObjC-GC days)
 
 Jordan
>> 
> 

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Jordan Rose via swift-users]

I’m confused about this. Shouldn’t you be able to get away with using +1 
convention everywhere? What needs to have arbitrary lifetime-extension in an 
ARC-ified language?

Jordan

> On Nov 2, 2016, at 12:23, Philippe Hausler  wrote:
> 
> So there are issues we have in swift-corelibs that suffer(leak) because we 
> don't have ARPs on Linux. It would be super nice to have a retain until scope 
> end concept for swift core libs where autorelease would be an accessor in 
> unmanaged that would retain the object until the arp ends scope.
> 
> Sent from my iPhone
> 
> On Nov 2, 2016, at 10:17 AM, Jordan Rose  > wrote:
> 
>> 
>>> On Nov 2, 2016, at 09:42, Joe Groff via swift-users >> > wrote:
>>> 
 
 On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users 
 > wrote:
 
 Hello,
 
 I want to create a mini http server project and execute at Ubuntu 15. The 
 Xcode compile and access the function "autoreleasepool", but when i 
 compile the same code at Ubuntu, this function not found
 
 For example, i can compile the code above at Xcode:
 
 while true {
autoreleasepool {
var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
 1\r\n\r\na".data(using: .utf8)!
}
 }
 
 But when i try to compile at Ubuntu:
 
 git@breder:~$ cat main.swift 
 import Foundation
 
 while true {
autoreleasepool {
var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
 1\r\n\r\na".data(using: .utf8)!
}
 }
 
 git@breder:~$ swiftc main.swift 
 main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
autoreleasepool {
^~~
>>> 
>>> Autoreleasepools are an ObjC compatibility feature. They aren't necessary 
>>> in standalone Swift.
>> 
>> But they are necessary in Swift programs on Apple platforms (that don’t use 
>> RunLoop, anyway). Philippe, what do you think? What’s the right way to write 
>> cross-platform code that doesn’t use RunLoop or dispatch_main for an 
>> implicit autorelease pool?
>> 
>> (/me remembers +[NSAutoreleasePool drain] from the ObjC-GC days)
>> 
>> Jordan

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

Re: [swift-users] Autoreleasepool for Ubuntu

[Jordan Rose via swift-users]

> On Nov 2, 2016, at 09:42, Joe Groff via swift-users  
> wrote:
> 
>> 
>> On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users 
>>  wrote:
>> 
>> Hello,
>> 
>> I want to create a mini http server project and execute at Ubuntu 15. The 
>> Xcode compile and access the function "autoreleasepool", but when i compile 
>> the same code at Ubuntu, this function not found
>> 
>> For example, i can compile the code above at Xcode:
>> 
>> while true {
>>autoreleasepool {
>>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
>> 1\r\n\r\na".data(using: .utf8)!
>>}
>> }
>> 
>> But when i try to compile at Ubuntu:
>> 
>> git@breder:~$ cat main.swift 
>> import Foundation
>> 
>> while true {
>>autoreleasepool {
>>var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 
>> 1\r\n\r\na".data(using: .utf8)!
>>}
>> }
>> 
>> git@breder:~$ swiftc main.swift 
>> main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
>>autoreleasepool {
>>^~~
> 
> Autoreleasepools are an ObjC compatibility feature. They aren't necessary in 
> standalone Swift.

But they are necessary in Swift programs on Apple platforms (that don’t use 
RunLoop, anyway). Philippe, what do you think? What’s the right way to write 
cross-platform code that doesn’t use RunLoop or dispatch_main for an implicit 
autorelease pool?

(/me remembers +[NSAutoreleasePool drain] from the ObjC-GC days)

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

Re: [swift-users] Segfault: 11 only when running tests (XCode 8, Swift 2.3)

[Jordan Rose via swift-users]

Can you double-check that all of your Utilities headers are Public or Private 
headers (not Project)? You can check this under the Build Phases tab for the 
framework target.

If that doesn't do it, we can probably help more with a bug report, if you're 
willing to share your project.

Jordan


> On Oct 6, 2016, at 6:47, Thomas Abend via swift-users  
> wrote:
> 
> Since moving a mixed Swift and Objective-c project to XCode 8 with Swift 2.3, 
> I have been getting a "Command failed due to signal: Segmentation fault: 11" 
> error every time I run my tests after making a change in any of the test 
> files.
> 
> When I click on the error for more information I see:
> 
> :1:9: note: in file included from :1: 
> #import "Headers/Utilities.h"
> ^
> /Users/.../Utilities.framework/Headers/Utilities.h:18:9: error: include of 
> non-modular header inside framework module 'Utilities'
> #import 
> ^
> And basically just a bunch of similar errors following that ending in:
> 
> :0: error: could not build Objective-C module 'Utilities'
> Utilities in this case is a framework that I made. All of the headers in the 
> Utilities.h file are imported with angle brackets and the headers are marked 
> as public.
> 
> After it segfaults, it will run properly until I make a change to the test 
> file. It only has this issue when testing, not when building or running.
> 
> Other things I've tried:
> 
> Changing the framework and tests to allow non modular includes
> Enabling/disabling bitcode
> Any help would be appreciated.
> 
> ___
> 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] NSInvocation equivalent

[Jordan Rose via swift-users]

> On Oct 5, 2016, at 14:43, Jens Alfke via swift-users  
> wrote:
> 
> 
>> On Oct 5, 2016, at 1:50 PM, Bob Miller via swift-users 
>>  wrote:
>> 
>>  This is a Swift3 newbie question that I’ve not found a solution to. Has 
>> there been any consensus reached on an equivalent approach to the AppKit 
>> class NSInvocation ? Here’s a simple objC example.
> 
> Swift doesn’t have an equivalent because the language simply isn’t as dynamic 
> as Objective-C: there is no mechanism to invoke a method at runtime given its 
> name.
> 
> If you’re on an Apple platform, and the method you want to call, and its 
> class, are @objc — then you can literally use NSInvocation from Swift to do 
> this. But not otherwise.

However, there are usually better answers than NSInvocation (both in Swift and 
Objective-C). What are you actually trying to do?

Jordan

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

Re: [swift-users] Swift migration bug

[Jordan Rose via swift-users]

Ha, sorry to get to these in the wrong order. The real rule is "is the feature 
part of the Swift Open Source project", but certainly a normal Xcode user isn't 
thinking about whether the command they just used "came from Xcode" or "came 
from Swift".

Radars will always get to Apple Swift people if it turns out to be a Swift 
issue, but bugs.swift.org has fewer communication restrictions and allows 
non-Apple people to help. If it's not clearly a Swift issue ("the compiler 
crashed") or an Xcode issue ("I can't open my project"), it's a toss-up. But no 
harm done (and thanks for reporting the bug in the first place).

Jordan

P.S. Why did I ask you to file the bug at bugreport.apple.com yourself? Because 
if I did it then you'd never hear when it was fixed, and wouldn't get the 
chance to test it on your own code and say "no, you fixed the wrong thing". :-)


> On Oct 3, 2016, at 10:12, Nate Birkholz via swift-users 
>  wrote:
> 
> Then Jordan Rose closed it as not a Swift bug. :)
> 
> On Mon, Oct 3, 2016 at 2:03 AM, Alex Blewitt  > wrote:
>> On 30 Sep 2016, at 19:30, Nate Birkholz via swift-users 
>> > wrote:
>> 
>> I found a bug in Swift 2.3 migration in the XCUITests, not sure if the bug 
>> goes to swift.org  or to Apple.
>> 
>> UI test generator uses the syntax (XCUIElement).children(matching: .other) 
>> but the compiler only recognizes childrenMatchingType(.Other), and you have 
>> to manually change the instances. Makes generating UI Tests a pain!
> 
> Please open a bug at https://bugs.swift.org  and 
> then it can be re-routed if necessary. If you can attach the snippet of code 
> with before/after that would help.
> 
> Thanks!
> 
> Alex
> 
> 
> 
> 
> -- 
> Nate Birkholz
> ___
> 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] RawRepresentable bug or intended?

[Jordan Rose via swift-users]

> On Sep 28, 2016, at 23:00, Adrian Zubarev via swift-users 
>  wrote:
> 
> struct B : RawRepresentable {
>  
> let rawValue: Int
>  
> //  init?(rawValue: Int) {
> //
> //  self.rawValue = rawValue
> //  }
>  
> static let c: B = B(rawValue: 0)
> static let d: B = B(rawValue: 1)
> }
> It seems to me that the memberwise initializer init(rawValue: Int) ignores 
> the failable initializer init?(rawValue: Int) from RawRepresentable and is 
> even able to satisfy RawRepresentable in that case.
> 

Yep, that's correct. A non-failable initializer is considered a valid subtype 
of a failable initializer, in that you can always provide the former where the 
latter is expected. The compiler doesn't handle all forms of subtyping when it 
does protocol conformance checks (and there are bugs on this), but it does 
handle this one.

Jordan

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

Re: [swift-users] xcode8 segmentation fault help

[Jordan Rose via swift-users]

> On Sep 27, 2016, at 03:37, Vladimir.S via swift-users  
> wrote:
> 
> On 27.09.2016 12:51, Luis Ferro via swift-users wrote:
>> let string = "a simple test"
>> if (string.characters.count > 0) {
>>let words = string.components(separatedBy: " ")
>>let headline = words.map { (var word) -> String in
>>let firstCharacter = word.remove(at: word.startIndex)
>>return "\(String(firstCharacter).uppercased())\(word)"
>>}.joined(separator: " ")
>> }
> 
> Swift 3.0 does not support `var` in function/closure parameter list. For some 
> reason Swift parser didn't catch this as syntax error, I'd suggest you to 
> report a bug on bugs.swift.org.

This particular bug has been fixed already on the master branch of Swift, so no 
need to report it. :-)

Jordan

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

Re: [swift-users] Double pointer in ObjC function signature importing incorrectly in Swift 3?

[Jordan Rose via swift-users]

C represents pointers the other way around; that declaration says only the 
outer pointer is nullable. There are two things going on here:

- Swift 2 made all pointers implicitly nullable, without using an optional 
type. Swift 3 makes that explicit.
- Swift 2 had a bug that assumed that all pointers-to-references were optional, 
instead of just those without nullability annotations. Swift 3 "fixes" that…but 
that reveals places where headers used _Nonnull to mean "always produces a 
nonnull pointer", forgetting that it also applies to input.

If this is an API in CloudKit itself, please file a Radar at 
bugreport.apple.com. If it's a third-party library built on CloudKit, you'll 
have to report the issue to them.

Sorry for the trouble!
Jordan


> On Sep 20, 2016, at 10:32, Michael Gardner via swift-users 
>  wrote:
> 
> I'm using an Objective-C library that has me provide a callback that takes a 
> double-pointer parameter like this, where only the inner pointer is nullable:
> 
> CKRecord *_Nonnull *_Nullable inOutRecordPtr
> 
> Swift 2 imported this as an AutoreleasingUnsafeMutablePointer, as 
> expected. However, Swift 3 is importing it as 
> AutoreleasingUnsafeMutablePointer?, which breaks the library's API 
> since there's no way to return a new record.
> 
> Is this a Swift 3 bug, or am I missing something?
> ___
> 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

[Jordan Rose via swift-users]

Xcode and migration aren't part of the Swift open source project, but this is 
something I've heard other people complaining about. Can you please file a 
Radar if you haven't already (bugreport.apple.com) and include your project 
file, then send me the bug number? (For this particular issue, I think we can 
get away with just the xcodeproj rather than the entire project sources that 
we'd usually need.)

Thanks,
Jordan


> On Sep 8, 2016, at 19:51, Saagar Jha via swift-users  
> wrote:
> 
> Ok, here’s what happened:
> 
> 1. I had a project that used Swift 2.3 with Xcode 7.
> 2. I downloaded Xcode 8 beta 1 and used the migrator to migrate to Swift 3 
> (successfully).
> 3. I downloaded the Xcode 8 betas, fixing errors as they cropped up due to 
> new proposals.
> 4. I downloaded Xcode 8 GM, and the project now fails to build due to it 
> reverting back to the 2.3 compiler when I right when opened it (I have no 
> idea how this happened).
> 5. I trigger the migrator manually, which warns that the project is already 
> on Swift 3. I force it to go through anyways, hoping to have it swap the 
> compiler. It proposes no source changes (since I’ve already done this in 
> previous betas) and it then “fails” for whatever reason.
> 6. It’s still using the old compiler and my code fails to build.
> 
> Saagar Jha
> 
> 
> 
>> On Sep 8, 2016, at 19:33, Zhao Xin > > wrote:
>> 
>> 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 
>>> > 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

___
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

[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] Can we `override var hashValue`?

[Jordan Rose via swift-users]

As I’ve said before, this doesn’t work.

let x: Fruit = Apple(“a”, shape: .medium)
let y: Fruit = Apple(“a”, shape: .big)
print(x == y) // will print true

If you want == to behave differently for subclasses, it needs to call a method 
that can be overridden. Static overloads will not produce the same behavior.

Jordan



> On Sep 2, 2016, at 18:42, Zhao Xin via swift-users  
> wrote:
> 
> The key is how to write the `==` function. It should compare the` 
> dynamicType`(or `type(of:)` in Swift 3.0) if the class is not a final class.
> 
> func ==(lhs: Fruit, rhs: Fruit) -> Bool {
> 
> print(lhs.hashValue)
> print(rhs.hashValue)
> 
> return type(of:lhs) == type(of:rhs) && lhs.name == rhs.name
> }
> 
> func ==(lhs: Apple, rhs: Apple) -> Bool {
> return type(of:lhs) == type(of:rhs) && lhs.name == rhs.name && lhs.shape 
> == rhs.shape
> }
> 
> func ==(lhs: Banana, rhs: Banana) -> Bool {
> return type(of:lhs) == type(of:rhs) && lhs.name == rhs.name && lhs.shape 
> == rhs.shape
> }
> 
> 
> class Fruit:Hashable {
> let name:String
> 
> var hashValue: Int {
> return 0
> }
> 
> init(_ name:String = "common fruit") {
> self.name = name
> }
> }
> 
> enum FruitShape:Int {
> case small = 1000
> case medium = 2000
> case big = 3000
> }
> 
> class Apple:Fruit {
> let shape:FruitShape
> 
> override var hashValue: Int {
> return 5
> }
> 
> required init(_ name:String = "common fruit", shape:FruitShape = .medium) 
> {
> self.shape = shape
> super.init(name)
> }
> }
> 
> class Banana:Fruit {
> let shape:FruitShape
> 
> override var hashValue: Int {
> return 10
> }
> 
> required init(_ name:String = "common fruit", shape:FruitShape = .medium) 
> {
> self.shape = shape
> super.init(name)
> }
> }
> 
> let apple = Apple()
> let banana = Banana()
> 
> print(apple == banana)
> /*
>  5
>  10
>  false
> */
> 
> I got the idea from book "Core Java", mine is version 8, the latest is the 
> version 10. I learnt how to writing Object oriented code from it. I am glad 
> it is still useful.
> 
> Zhaoxin
> 
> On Sat, Sep 3, 2016 at 9:14 AM, Zhao Xin  > wrote:
> There is no reason to compare the shape, it is a constant in each of
> these types.  (So I am not sure what your point is.)
> 
> Sorry. The `let shape` should be `var shape`. I just wanted to make the 
> subclass to be something more than the super class.
> 
> If two values are equal, their hash values should be equal.  As long
> as your override implementation guarantees this, you can override
> hashValue.
> 
> But the question is how? If this must be guaranteed by the subclass, how to 
> writing the override? Or it just can't be done?
> 
> You should also understand that the ==(Apple, Apple) and ==(Banana,
> Banana) are not overrides for ==(Fruit, Fruit), and they would not be
> called through dynamic dispatch when you have, for example, two apples
> typed as fruits.
> 
> In fact, in my example code, `apple` and `banana` is instance of `Apple` and 
> `Banana`. They are not using `let apple:Fruit = Apple()`. The `==` used the 
> `Fruit` version as it was the only appropriate one. My big question is, since 
> they used the `Fruit` version, and the `Fruit` version of `hashValue` could 
> guarantee the `hashValue` equality, isn't that enough?
> 
> Zhaoxin
>  
> 
> On Sat, Sep 3, 2016 at 7:02 AM, Dmitri Gribenko  > wrote:
> On Sat, Sep 3, 2016 at 1:31 AM, Zhao Xin via swift-users
> > wrote:
> > func ==(lhs: Apple, rhs: Apple) -> Bool {
> > return lhs.name  == rhs.name  && 
> > lhs.shape == rhs.shape
> > }
> >
> > func ==(lhs: Banana, rhs: Banana) -> Bool {
> > return lhs.name  == rhs.name  && 
> > lhs.shape == rhs.shape
> > }
> 
> There is no reason to compare the shape, it is a constant in each of
> these types.  (So I am not sure what your point is.)
> 
> > My question is, apple equals banana, but their hashValues (in their own
> > types)  don't. What's wrong here? Is that means we shouldn't override
> > hashValue in subclass in Swift?
> 
> This means you should not override hashValue in this particular way.
> If two values are equal, their hash values should be equal.  As long
> as your override implementation guarantees this, you can override
> hashValue.
> 
> You should also understand that the ==(Apple, Apple) and ==(Banana,
> Banana) are not overrides for ==(Fruit, Fruit), and they would not be
> called through dynamic dispatch when you have, for example, two apples
> typed as fruits.
> 
> Dmitri
> 
> --
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko  

Re: [swift-users] Function to unsafe pointer and back

[Jordan Rose via swift-users]

> On Sep 1, 2016, at 13:48, Andrew Trick via swift-users 
>  wrote:
> 
> 
>> On Sep 1, 2016, at 12:37 PM, Lou Zell via swift-users > > wrote:
>> 
>> As to your real question, what’s your high-level goal?  Swift doesn’t really 
>> do pointers to functions [1] but it does provide lots of other excellent 
>> ‘treat code as data’ features.  If you can explain more about your goal, 
>> perhaps we can direct you to a better path.
>> ​
>> Curiosity got the better of me on this one - there's no higher level goal 
>> other than improved understanding.  I was playing around with function 
>> currying in the repl and that's what lead me to those experiments.  
>> 
>> The article, and the preceding one in the series, has plenty for me to work 
>> with.  Thank you!
> 
> That’s an awesome article, but I don’t think you need to understand any of 
> it! I’m not an expert in this either, but here’s what I can see from your 
> code...
> 
> It looks like you’re trying to capture the address of a function that was 
> JIT’d for the purpose of evaluating a statement in the repl. That address 
> might not be valid in the next statement.
> 
> Also, in the first case the UnsafePointer points to local memory that holds 
> the function value. In the second case, you’re trying to load a function 
> value from the address of the function body. So a level of indirection is 
> missing.
> 
> You can’t take an address to a function in Swift. You can assign a variable 
> to the function, as you did in the first case:
> 
> var x = doNothing
> 
> And view the address of that variable as an argument, only for the duration 
> of the call, as you did in the first case:
> 
> call()

I feel like there’s still one last piece missing here, which is that in Swft a 
"function-typed value” is not the same as a “function pointer” in C. Because a 
function value might have come from a closure, it might include captured 
state…so the representation of a closure is not the same as a representation of 
a plain function.

Because of that, the address you’re seeing isn’t the address of the function in 
memory; it’s the address of the temporary allocation used to represent “this 
global function and no associated state”. That’s why you can’t just form a 
pointer with that bit-pattern and expect it to work.

If you really need something compatible with a C function, you can use the type 
'@convention(c) () -> Void’ (or whatever). Note the lack of UnsafePointer 
here—the reference-ness is baked in in Swift. Even then, though, you can’t rely 
on the function having the same address every time you run the program (at 
least on macOS), because of address space randomization—the offset at which 
your code is loaded will be different on each run. There shouldn’t be any need 
to do this anyway.

(One place we are still weak is in converting between C function references and 
UnsafeRawPointer—there’s no dedicated API to do this. I’m not sure we have a 
recommendation in the rare cases when this is necessary. Andy?)

Hope you’ve gotten some useful information between the three of us. :-)
Jordan

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

Re: [swift-users] Subtract a set of a subclass?

[Jordan Rose via swift-users]

> On Sep 1, 2016, at 15:44, Zhao Xin via swift-users  
> wrote:
> 
> Hi Nick,
> 
> Glad to help.
> 
> but when using third party classes I don’t know if the hash values are 
> comparable
> 
> You can create an extension with a convenient init(:), which creates a new 
> instance of  the super class basing on the instance of the sub class. That 
> will guarantee the subtraction. Below code works in Xcode 7.3.1 with Swift 
> 2.2.
> 
> import Foundation
> 
> func ==(lhs: Foo, rhs: Foo) -> Bool {
> return lhs.id == rhs.id
> }
> 
> class Foo:Hashable {
> let id:Int
> var hashValue: Int {
> return id
> }
> 
> required init(_ id:Int) {
> self.id = id
> }
> }
> 
> class Bar:Foo {
> override var hashValue: Int {
> return id * 5
> }
> }
> 
> var fooSet:Set = [Foo(10), Foo(9), Foo(8), Foo(7)]
> var barSet:Set = [Bar(8), Bar(7), Bar(6), Bar(5)]
> 
> //fooSet.subtract(barSet) // error: cannot invoke 'subtract' with an argument 
> list of type '(Set)'
> fooSet = fooSet.subtract(barSet as Set) // works, but not what we want
> fooSet.forEach { print("\($0.dynamicType), id:\($0.id)") }
> /*
>  Foo, id:7
>  Foo, id:10
>  Foo, id:9
> */

This isn't really a sensible thing to do. The rules for Hashable require that 
`a == b` implies `a.hashValue == b.hashValue`, and `a.hashValue != b.hashValue` 
implies `a != b`. If you break these rules you're going to have problems no 
matter what static types you're using.

Upcasting from Set to Set is the most concise way to solve this 
problem.

Jordan

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

Re: [swift-users] DWARF without DSYM

[Jordan Rose via swift-users]

I suppose it can, but in theory the module that goes into the dSYM wouldn't be 
the same as the one that gets used by clients of a library. (Example: the one 
in the dSYM needs to have info about private types.) Sean can probably explain 
better than I can.

Jordan


> On Aug 26, 2016, at 9:36, Dmitry Shevchenko  wrote:
> 
> I see. I thought LLDB can import modules independently of sources, isn't that 
> what target.swift-module-search-paths option is for?
> 
> On Thu, Aug 25, 2016 at 4:15 PM Jordan Rose  > wrote:
> Plain DWARF isn't sufficient to debug a Swift program (we actually stuff the 
> entire swiftmodule into the dSYM), but if you just want to trace execution 
> you should be able to use -gline-tables-only.
> 
> Jordan
> 
> 
> > On Aug 25, 2016, at 13:10, Dmitry Shevchenko via swift-users 
> > > wrote:
> >
> > Can swiftc generate debug info without a separate dSYM bundle? -g option 
> > looks to always generate a dSYM.
> > ___
> > 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] Implicitly type conversion ?

[Jordan Rose via swift-users]

It's mainly to support heterogeneous dictionary literals. There's not usually a 
need to upcast to AnySequence regularly, since most things that take sequences 
should be using generics, but heterogeneity and generics don't play well 
together.

Jordan


> On Aug 19, 2016, at 9:00, Tim Vermeulen via swift-users 
> > wrote:
> 
> Any idea why Swift supports implicit casting to AnyHashable, but not to, say, 
> AnySequence?
> 
>>> On Aug 18, 2016, at 9:54 AM, Adel Zhang via 
>>> swift-users>wrote:
>>> 
>>> Any other situation when implicit type casting works?
>> I don't know if there's a comprehensive list anywhere. Here are the ones I 
>> can think of:
>> 
>> 1. A subtype can be used where a supertype is expected; for instance, you 
>> can pass an `Int` to a parameter typed `Any` without a cast. The same is 
>> true of superclasses: `NSString` can be used where `NSObject` is expected. 
>> Obvious, but worth mentioning.
>> 
>> 2. Swift 3's `AnyHashable` isn't *really* a supertype of `Hashable` types, 
>> but it's sort of treated as one.
>> 
>> 3. The built-in `Array`, `Dictionary`, `Set`, and `Optional` types can be 
>> implicitly converted to the same data structure, but with supertypes of its 
>> generic parameters. For instance, an `Array` can be passed to a 
>> parameter of type `Array`. This is not a general feature of 
>> generics—it's special-cased for these types.
>> 
>> 4. As you noticed, a type can be implicitly made more `Optional`; that is, 
>> `Int` converts to `Optional`, `Optional`, and so on.
>> 
>> 5. In Swift 2, importing Foundation activates many implicit conversions 
>> between Foundation and Standard Library types, including conversions to 
>> AnyObject. Many (perhaps all?) are gone in Swift 3. (However, Foundation 
>> still has plenty of magical `as` casts.)
>> 
>> Hope this helps,
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> 
>> 
>> 
> ___
> 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] Two Obj-C visible functions no longer overload?

[Jordan Rose via swift-users]

It’s always been possing to make arrays of Error, but exposing those arrays 
back to Objective-C may or may not have worked correctly (as you noticed).

And yes, your solutions are either adding different labels, or using the ‘objc’ 
attribute to explicitly specify a selector for one or the other.

Jordan


> On Aug 8, 2016, at 16:35, Jon Shier  wrote:
> 
> Jordan:
>   Could you expand on allowing making arrays of errors? AFAIK, making 
> arrays of ErrorProtocol/ErrorType/Error has always been possible. And 
> somewhat coincidentally I ran into a runtime issue with the same library, 
> fixed in the latest Swift trunk package, that would result in a crash when 
> attempting to access an array of Errors through an intermediate derived 
> property, but only in Objective-C derived classes. Perhaps that’s related?
>   In any event, if we wished to maintain Objective-C visibility here, I 
> would expect adding different external labels to fix the issue, right?
> 
> 
> Jon
> 
>> On Aug 8, 2016, at 5:04 PM, Jordan Rose > > wrote:
>> 
>> I would definitely expect these two to conflict, so if they previously 
>> compiled happily I would guess that’s a bug we fixed. The most likely 
>> possibility is that we didn’t allow making arrays of errors and now we do.
>> 
>> Jordan
>> 
>> 
>>> On Aug 5, 2016, at 14:57, Jon Shier via swift-users >> > wrote:
>>> 
>>> Swifters:
>>> I’m attempting to update some library code to beta 4 and I’ve run into 
>>> something that’s either a bug or a deliberate change. In a class that’s a 
>>> Foundation.Operation subclass, there are two finish() functions:
>>> 
>>> final func finish(_ receivedErrors: [Error] = []) {
>>> _finish(receivedErrors, fromCancel: false)
>>> }
>>> 
>>> /// Convenience method to simplify finishing when there is only one error.
>>> final func finish(_ receivedError: Error?) {
>>> finish(receivedError.map { [$0]} ?? [])
>>> }
>>> 
>>> Prior to beta 4 these functions lived side by side quite happily. In beta 
>>> 4, however, their existence produces this error:
>>> 
>>> method 'finish' with Objective-C selector 'finish:' conflicts with previous 
>>> declaration with the same Objective-C selector
>>> 
>>> Now, if I mark one of the functions @nonobjc, it compiles. So is this a bug 
>>> or change in behavior?
>>> 
>>> 
>>> 
>>> Jon Shier
>>> ___
>>> 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] SCNetworkReachabilityFlags beta 4 issue

[Jordan Rose via swift-users]

In master I’m seeing it at least be consistent, warning about both members and 
not just ‘isLocalAddress’. Since it seems to be a compiler issue I think just 
filing it at bugs.swift.org is fine, though I’ll warn you that since there’s an 
easy workaround it might not get prioritized.

Jordan


> On Aug 5, 2016, at 15:09, Jon Shier via swift-users  
> wrote:
> 
> Swifters:
>   I’m attempting to port a library to Xcode 8 beta 4 and have run into a 
> peculiar issue with SCNetworkReachabilityFlags. Prior to beta 4, this 
> extension on SCNetworkReachabilityFlags which provided convenience Bool 
> properties worked just fine:
> 
> extension SCNetworkReachabilityFlags {
> var isLocalAddress: Bool {
> return contains(.isLocalAddress)
> }
> 
> var isDirect: Bool {
> return contains(.isDirect)
> }
> }
> 
> Now, it throws an error:
> 
> instance member 'isLocalAddress' cannot be used on type 
> ‘SCNetworkReachabilityFlags’
> 
> Now, this is rather peculiar, since other OptionSets I create with options 
> and properties of the same name work fine. There must be something peculiar 
> about SCNetworkReachabilityFlags. If I change the properties to no longer 
> match the option values, it builds fine. Is this a bug? If it is, I’m 
> assuming it’s better to report it to Apple rather than swift.org 
> , or should I do both?
> 
> 
> 
> Jon Shier
> ___
> 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] Two Obj-C visible functions no longer overload?

[Jordan Rose via swift-users]

I would definitely expect these two to conflict, so if they previously compiled 
happily I would guess that’s a bug we fixed. The most likely possibility is 
that we didn’t allow making arrays of errors and now we do.

Jordan


> On Aug 5, 2016, at 14:57, Jon Shier via swift-users  
> wrote:
> 
> Swifters:
>   I’m attempting to update some library code to beta 4 and I’ve run into 
> something that’s either a bug or a deliberate change. In a class that’s a 
> Foundation.Operation subclass, there are two finish() functions:
> 
> final func finish(_ receivedErrors: [Error] = []) {
> _finish(receivedErrors, fromCancel: false)
> }
> 
> /// Convenience method to simplify finishing when there is only one error.
> final func finish(_ receivedError: Error?) {
> finish(receivedError.map { [$0]} ?? [])
> }
> 
> Prior to beta 4 these functions lived side by side quite happily. In beta 4, 
> however, their existence produces this error:
> 
> method 'finish' with Objective-C selector 'finish:' conflicts with previous 
> declaration with the same Objective-C selector
> 
> Now, if I mark one of the functions @nonobjc, it compiles. So is this a bug 
> or change in behavior?
> 
> 
> 
> Jon Shier
> ___
> 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] non-mutating func that still mutates a struct, compiler not aware

[Jordan Rose via swift-users]

Those UnsafeMutablePointer(…) calls aren’t correct. When an array is 
implicitly converted to a pointer in Swift, the pointer is only valid for the 
immediate call that it’s being passed to. In this case, that’s the 
UnsafeMutablePointer initializer, and after that the pointer is invalid. So 
it’s possible that either the same space is being reused for both pointers, or 
that it’s not uniquing the array because it thinks it only has to make an 
UnsafePointer, or both.

As Brent says, passing the arrays directly to the method using inout semantics 
(&) should get you the behavior you want.

(Yes, there should be a diagnostic for this. I’m pretty sure we have a bug 
already, so no need to file. The Swift 3 pointer APIs make this a little harder 
to do by accident, too.)

Jordan


> On Aug 5, 2016, at 08:14, Raphael Sebbe via swift-users 
>  wrote:
> 
> Do you see a reason why the copy isn't happening in this specific case? Is it 
> a bug, or a mistake in my code?
> 
> Thank you,
> 
> Raphael
> 
> On Thu, Aug 4, 2016 at 4:18 PM Brent Royal-Gordon  > wrote:
> > On Aug 4, 2016, at 1:25 AM, Raphael Sebbe via swift-users 
> > > wrote:
> >
> > My understanding is that the compiler doesn't make a real copy in the acopy 
> > =  self instruction, and then provides that contents to the mx_gels_ 
> > function which modifies the memory contents.
> >
> >
> > public func solve(rhs b: Matrix) -> Matrix? {
> >   // ...
> >   var acopy = self
> >   // ...
> >
> >   T.mx_gels_(, , , , 
> > UnsafeMutablePointer(acopy.values), , 
> > UnsafeMutablePointer(x.values), , 
> > UnsafeMutablePointer(workspace), , );
> >
> >   // ...
> >   }
> >
> >
> > Is this expected? I mean, I can force a real copy of course, but value 
> > semantics would suggest the code above is correct and wouldn't need that. 
> > Shouldn't the cast trigger the copy somehow? Or is there a better way of 
> > expressing this operation? Thx.
> 
> The `acopy = self` line only copies the reference to the internal buffer. 
> However, converting the array into a pointer will—or at least, if done 
> properly, *should*—force the array to create and switch to using a unique 
> copy of its buffer in preparation for writes through the 
> UnsafeMutablePointer. I believe that happens here: 
>   
> >
> 
> (I say "should" because I'm not sure you're actually creating those pointers 
> correctly. I believe you ought to be able to just say `` and 
> ``, and that should be a more reliable way to do it.)
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] AttributedString gone in Xcode 8 beta 4?

[Jordan Rose via swift-users]

That was pretty much the rationale for restoring “NS". :-)

> On Aug 1, 2016, at 14:46, Dave Reed via swift-users  
> wrote:
> 
> Ah, I thought there was already a value type AttributedString that I was now 
> using.
> 
> Thanks,
> Dave Reed
> 
>> On Aug 1, 2016, at 5:35 PM, Shawn Erickson wrote:
>> 
>> I believe the removal of NS from some foundation types was reversed after 
>> feedback and further consideration.
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md
>> &&
>> https://github.com/apple/swift-evolution/commit/bea5eab614b954775754639fb83a957a180152e1#diff-e260ca20577a1e205ea0b72456a21b7f
>> 
>> On Mon, Aug 1, 2016 at 2:23 PM Dave Reed via swift-users 
>>  wrote:
>> I was updating my project from beta 3 to beta 4 today and it seems 
>> AttributedString disappeared. Changing it to NSAttributedString fixed it.
>> 
>> I don't see anything in the Release Notes about AttributedString.
>> 
>> Is it gone permanently? Or am I doing something wrong?
>> 
>> Thanks,
>> Dave Reed
> 
> ___
> 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] Are value semantics really appropriate in a diagramming app?

[Jordan Rose via swift-users]

I happen to agree with Jens, though Dave Abrahams (and Crusty) might disagree 
with me. The number one consideration for choosing between a value type and a 
reference type is “do I want value semantics or reference semantics?” If I want 
to talk about a particular shape, talk about “that one”, I can only do that if 
there’s some notion of identity. So yes, if that’s part of my app, I would 
start with reference types.

Now, that doesn’t have to apply to rendering. As shown in the presentation, if 
you’re generating the shapes, there’s no need to refer to a particular shape 
afterwards…especially if the shapes are immutable. Any individual shape is just 
data to be rendered. But if I want a command like “change the color of that 
square”, then I need a way to know what “that square” refers to, and an object 
with persistent identity—a class instance—is one way to do it.

You can get a notion of “identity” in ways other than reference semantics—say, 
by generating unique IDs that go with a particular shape, and then looking them 
up later. But it’s a perfectly fine choice to make your model use reference 
semantics.

All of that said, reference semantics do have traps: mutation makes things 
harder to test in isolation, and mutation with shared state makes things not 
thread-safe. So you have to decide what trade-off you want to make in your app.

Jordan


> On Aug 1, 2016, at 19:18, Jack Lawrence via swift-users 
>  wrote:
> 
> Jens: Why? There are significant benefits to value semantics for this type of 
> problem, for the reasons laid out in the WWDC videos. It would be helpful to 
> know why you disagree in this case—maybe there are solutions to the issues 
> you’re thinking of.
> 
> Rick: I’d think that value semantics would be the right choice here. When you 
> do a mutation, you would copy the state of the entire diagram. It should be 
> efficient via COW, but if not you can implement you own more fine-grained COW 
> types with isUniquelyReferenced(). This would allow you to easily support 
> things like undo.
> 
> Jack
>> On Aug 1, 2016, at 4:32 PM, Jens Alfke via swift-users 
>> > wrote:
>> 
>> 
>>> On Aug 1, 2016, at 1:19 AM, Rick Mann via swift-users 
>>> > wrote:
>>> 
>>> It seems like reference semantics are more appropriate here.
>> 
>> Yes, they are. (Just because structs exist doesn’t mean you have to use them 
>> everywhere.)
>> 
>> —Jens
>> ___
>> 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