Re: [swift-users] Synthesized Equatable Bug?

[Jon Shier via swift-users]

Thanks Dmitri. Once I looked up the total ordering for points I was able to get 
proper behavior.

static func < (lhs: Point, rhs: Point) -> Bool {
return lhs.x < rhs.x || (lhs.x == rhs.x && lhs.y < rhs.y)
}


Jon

> On Jan 15, 2018, at 8:38 PM, Dmitri Gribenko <griboz...@gmail.com> wrote:
> 
> On Mon, Jan 15, 2018 at 2:30 PM, Jon Shier via swift-users
> <swift-users@swift.org> wrote:
>> This is pretty straightforward code, so am I missing something here?
> 
> Your '<' function does not define a valid strict total order.
> 
> For
> 
> let p1 = Point(1, 1)
> let p2 = Point(0, 2)
> 
> neither of 'p1 < p2', 'p2 < p1', 'p1 == p2' is true.  This is the root cause.
> 
>> static func <= (lhs: Point, rhs: Point) -> Bool {
>>   return lhs < rhs || lhs == rhs
>> }
> 
> A faster way to compute it (with only one call to a user-defined
> comparison operator) is to return '!(rhs < lhs)', which is wat the
> standard library does, which is why you see the behavior that you are
> seeing.
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <griboz...@gmail.com>*/

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

[swift-users] Synthesized Equatable Bug?

[Jon Shier via swift-users]

Swifters:
Take this simple Point type:

struct Point: Hashable {
let x: Int
let y: Int

init(_ x: Int, _ y: Int) {
self.x = x
self.y = y
}
}

Using the latest Swift 4.1 snapshot, the Hashable conformance is generated for 
me. Adding Comparable conformance like this:

extension Point: Comparable {
static func < (lhs: Point, rhs: Point) -> Bool {
return (lhs.x < rhs.x  && lhs.y <= rhs.y) || (lhs.x <= rhs.x  && lhs.y 
< rhs.y)
}
}

Once this is implemented, (0, 2) <= (1,1) bizarrely evaluates as true, despite 
both < and == evaluating as false. Manually implementing <= fixes the issue.

static func <= (lhs: Point, rhs: Point) -> Bool {
return lhs < rhs || lhs == rhs
}

This is pretty straightforward code, so am I missing something here?



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

Re: [swift-users] "Month 13 is out of bounds"

[Jon Shier via swift-users]

This is a known issue for High Sierra, and is output from a variety of 
apps during normal system usage. Just search your Console logs and you’ll see  
many instances. Unfortunately I’m not sure how to ignore the output in Xcode, 
but you don’t need to care about it. Who knows if it’ll be fixed for High 
Sierra.


Jon 

> On Jan 2, 2018, at 1:10 PM, David Wood via swift-users 
>  wrote:
> 
> In XCode, I’ve built a little …mathematical utility program for my own use. 
> It’s a Swift 4, Cocoa & Foundation-based program targeted at High Sierra. But 
> it’s doing something weird.
> 
> The title of this email, “Month 13 is out of bounds,” pops up in the log 
> exactly nine times as the main window for the app opens, and appears no other 
> time during its operation.
> 
> The problem is that nowhere in the code for this thing am I using any date or 
> time functions. None whatsoever.
> 
> I even stuck a breakpoint on the applicationDidFinishLaunching() in the 
> AppDelegate, and three of those messages are written to the log before even 
> that.
> 
> How do I track down this behavior?
> 
> 
> --David
> 
> "Do not attempt to operate heavy philosophy when taking this drug. Driving is 
> perfectly all right, as it renders you completely alert although unable to 
> put together an argument."
> 
> 
> ___
> 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.

[Jon Shier via swift-users]

I’m pretty sure JSON isn’t localized, so this isn’t a bug. Using anything but a 
. as a decimal separator isn’t valid JSON. 


Jon

> On Dec 18, 2017, at 11:51 AM, 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

[swift-users] Refining generics in classes

[Jon Shier via swift-users]

Swift Users:
I have a generics use case which has somewhat stumped me. I have two 
related protocols, JSONDecodable and CompressedDecodable, and 
CompressedDecodable inherits from JSONDecodable (though that relationship isn’t 
strictly necessary). I also have a generic function that’s overloaded for each 
of those protocols. I’m trying to write a class to make a network request 
expecting a generic response type of either JSONDecodable or 
CompressedDecodable. However, it doesn’t seem possible to write it in such a 
way that the overload I need is called. Instead, it’s always the superclass’ 
type’s overload that is called. For example:

protocol JSONDecodable { init() }
protocol CompressedDecodable: JSONDecodable { }

class NetworkRequest {

var response: T?

func doAThing() {
response = doSomething()
}
}

class CompressedNetworkRequest: NetworkRequest {

}

func doSomething() -> T {
print("One: \(T.self)")
return T()
}

func doSomething() -> T {
print("Two: \(T.self)")
return T()
}

struct Uno: JSONDecodable { }
struct Dos: CompressedDecodable { }

NetworkRequest().doAThing()
CompressedNetworkRequest().doAThing()

In a playground this prints:

One: Uno
One: Dos

Ultimately, I understand why this happens (NetworkRequest’s generic type is 
always going to be JSONDecodable, no matter if it’s actually a subtype). Is 
there any way, aside from completely duplicating the class, to call the 
overload appropriate for the type passed in a class like this? 



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

Re: [swift-users] Parsing Decimal values from JSON

[Jon Shier via swift-users]

The appropriate solution here would be for Swift to have its own native 
JSON parser that allows direct decoding into generic types without the 
intermediary of JSONSerialization. For whatever reason there seems to be 
resistance to this from the Swift team, but until we have that ability, these 
types of issues will keep coming up, and the performance overhead of 
JSONSerialization with JSONDecoder on top of it will continue to leave Swift 
without a very performant JSON solution. 
That said, I appreciate the support given Codable on this list.



Jon

> On Oct 31, 2017, at 1:07 PM, Itai Ferber via swift-users 
>  wrote:
> 
> Hi Evtim,
> 
> Just want to give some context for this.
> This is due to the fact that JSONEncoder and JSONDecoder are currently based 
> on JSONSerialization: when you go to decode some JSON data, the data is 
> deserialized using JSONSerialization, and then decoded into your types by 
> JSONDecoder. At the JSONSerialization level, however, there is no way to know 
> whether a given numeric value is meant to be interpreted as a Double or as a 
> Decimal.
> 
> There are subtle differences to decoding as either, so there is no behavior 
> that could satisfy all use cases. JSONSerialization has to make a decision, 
> so if the number could fit losslessly in a Double, it will prefer that to a 
> Decimal. This allows guaranteed precise round-tripping of all Double values 
> at the cost of different behavior when decoding a Decimal.
> 
> In practice, this might not really matter in the end based on how you use the 
> number (e.g. the loss in precision can be so minute as to be insignificant) — 
> what is your use case here? And can you give some numeric values for which 
> this is problematic for you?
> 
> As others have mentioned, one way to guarantee decoding a numeric string in a 
> specific way is to actually encode it and decode it as a String, then convert 
> into a Decimal where you need it, e.g.
> 
> import Foundation
> 
> struct Foo : Codable {
> var number: Decimal
> 
> public init(number: Decimal) {
> self.number = number
> }
> 
> private enum CodingKeys : String, CodingKey {
> case number
> }
> 
> public init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> let stringValue = try container.decode(String.self, forKey: .number)
> guard let decimal = Decimal(string: stringValue) else {
> throw DecodingError.dataCorruptedError(forKey: .number, in: 
> container, debugDescription: "Invalid numeric value.")
> }
> 
> self.number = decimal
> }
> 
> public func encode(to encoder: Encoder) throws {
> var container = encoder.container(keyedBy: CodingKeys.self)
> try container.encode(self.number.description, forKey: .number)
> }
> }
> 
> 
> let foo = Foo(number: Decimal(string: 
> "2.71828182845904523536028747135266249775")!)
> print(foo) // => Foo(number: 2.71828182845904523536028747135266249775)
> 
> let encoder = JSONEncoder()
> let data = try encoder.encode(foo)
> print(String(data: data, encoding: .utf8)!) // => 
> {"number":"2.71828182845904523536028747135266249775"}
> 
> let decoder = JSONDecoder()
> let decoded = try decoder.decode(Foo.self, from: data)
> print(decoded) // => Foo(number: 2.71828182845904523536028747135266249775)
> 
> print(decoded.number == foo.number) // => true
> — Itai
> 
> On 28 Oct 2017, at 11:23, Evtim Papushev via swift-users wrote:
> 
> Hello :)
> 
> I am trying to find a way to parse a number as Decimal without losing the 
> number's precision.
> 
> It seems that the JSON decoder parses it as Double then converts it to 
> Decimal which introduces errors in the parsing. That behavior is in fact 
> incorrect.
> 
> Does anyone know if there is a way to obtain the raw data for this specific 
> field so I can write the conversion code?
> 
> Thanks,
> Evtim
> 
> ___
> 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] Swift Version Conditionals in Objective-C?

[Jon Shier via swift-users]

In moving a hybrid project from Swift 3 to 4, I’ve run into some issues 
from my Objective-C code. I’ve been able to conditionalize my Swift code for 
both versions pretty easily, but there are APIs imported from Objective-C that 
need to change definition for Swift 4. Is there anyway, in preprocessor or at 
runtime, to detect what version of Swift the Objective-C is being imported 
into? It’s as simple as a typedef for NSAttributedString attributes 
dictionaries that needs a different generic type in Swift 3 vs. Swift 4. 
Browsing the documentation I don’t see anything, but I’m guess some such method 
exists, given Apple’s APIs can do so. This would only be a temporary situation 
until the move the Swift 4 can be completed.



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

Re: [swift-users] Swift 4 "Cannot use mutating member on immutable value: 'self' is immutable"

[Jon Shier via swift-users]

Yes, it seems to fly in the face of protocols as they exist in Swift at 
the moment. Given the inability of protocols to guarantee performance 
characteristics, breaking conformant types like this seems like a bad way to 
try and fulfill a separate axis of concern. Wouldn’t a better idea be to move 
things like popFirst(), and other methods requiring O(1) performance, to a 
separate protocol? I’m also pretty sure it’s possible to implement popFirst in 
O(1) for an Array, but Swift’s Array isn't generally very fast, at least 
compared to C / C++.



Jon

> On Sep 17, 2017, at 9:45 PM, Rick Mann via swift-users 
>  wrote:
> 
>> 
>> On Sep 17, 2017, at 03:25 , Quinn The Eskimo! via swift-users 
>>  wrote:
>> 
>> 
>> On 15 Sep 2017, at 21:35, Vladimir.S via swift-users  
>> wrote:
>> 
>>> … for me it is very strange decision to disallow a method because it is 
>>> 'expensive'.
>> 
>> That’s pretty normal for Swift standard library protocols, which define not 
>> just the behaviour of the routine but expected performance.  `popFirst()` is 
>> expected to be O(1) and that’s not possible with `Array`.
>> 
>> The rationale behind this decision is, I believe, related to generic 
>> algorithms.  If I write generic code that uses `popFirst()`, I can only 
>> guarantee the complexity of my code if I can rely on `popFirst()` being 
>> O(1).  If someone implements `popFirst()` as O(n), my generic algorithm 
>> might go from O(n^2) to O(n^3), which is quite a change.
>> 
>> On 16 Sep 2017, at 01:44, Rick Mann via swift-users  
>> wrote:
>> 
>>> Is the compiler looking at the name "pop" and adding additional constraints 
>>> (and then spewing a bogus error message)?
>> 
>> I’m not sure what’s going on here mechanically but, yes, the error message 
>> is bogus.  This is exactly what SR-5515 is talking about.
>> 
>> If I were in your shoes I’d call this method something other than 
>> `popFirst()`.  This falls under my standard “if you change the semantics, 
>> change the name” rule.  Your implementation of `popFirst()` doesn’t conform 
>> to the semantics of `popFirst()` — it’s O(n) because `removeFirst()` is O(n) 
>> — and thus you want to avoid calling it `popFirst()`.
> 
> All right, I'm happy to change the name to "safeRemoveFirst()", but I'm a bit 
> irritated that there's an implicit performance constraint based on the name 
> alone, without any obvious decorator syntax.
> 
> 
> -- 
> 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] Swift 4 "Cannot use mutating member on immutable value: 'self' is immutable"

[Jon Shier via swift-users]

Looks like this is sort of tracked in  SR-5515popFirst error message is 
silly <https://bugs.swift.org/browse/SR-5515>. I’m not sure what a good answer 
is here, since it seems like it isn’t supposed to be available if it can’t 
guarantee O(1) behavior. Still seems like Array should have it, but in any 
case, this looks like a bad error message at least.



Jon


> On Sep 14, 2017, at 11:05 AM, Jon Shier via swift-users 
> <swift-users@swift.org> wrote:
> 
>   This seems oddly similar to https://bugs.swift.org/browse/SR-5659 
> <https://bugs.swift.org/browse/SR-5659>, but [Thing] should meet the 
> appropriate criteria for popFirst to work properly. Yet the error we’re 
> seeing here is the same that was originally seen when trying to use popFirst 
> on a String. Definitely feels like some sort of Swift bug here.
> 
> 
> 
> Jon
> 
> 
>> On Sep 14, 2017, at 10:48 AM, Jon Shier via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>>  It also doesn’t explain why removeFirst would work but popFirst 
>> doesn’t. The mutation to the underlying array should be the same, the only 
>> different is that one returns the element optionally. It also doesn’t 
>> explain why popFirst doesn’t show up I the autocomplete but compiles anyway.
>> 
>> 
>> 
>> Jon
>> 
>>> On Sep 14, 2017, at 8:16 AM, Vladimir.S via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>> 
>>> On 14.09.2017 11:14, Quinn "The Eskimo!" via swift-users wrote:
>>>> On 14 Sep 2017, at 03:56, somu subscribe via swift-users 
>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>>> popFirst is not available in the Array …
>>>> Right.  This makes sense when you consider the standard setup for an 
>>>> array, namely, a variable length buffer of items.  Removing the first 
>>>> element is expensive, whereas removing the last element (`popLast()`) is 
>>>> cheap.
>>>> If you run your simplified example in Xcode 8 you get an error that hints 
>>>> at what’s going on.
>>>> var array = [1, 2, 3, 4, 5]
>>>> _ = array.popFirst()
>>>> ~~^~~~
>>>> error: 'ArraySlice' is not convertible to '[Int]'
>>> 
>>> Sorry, could you clarify, I can't understand.
>>> What should be the error message here and why at all we should have an 
>>> error here?
>>> 
>>> Are we forced to use this code to pop first element in array? :
>>> var array = [1, 2, 3, 4, 5]
>>> let x = array[0...].popFirst()
>>> print(x!) // 1
>>> print(array) // [2,3,4,5]
>>> 
>>> And why we shouldn't be allowed to have popFirst() for array? Yes, it is 
>>> expensive, but is it a right reason to disallow it totally? In many 
>>> situations we have a small arrays and don't care so much how fast the first 
>>> element will be pop'ed.
>>> I hope I'm just missing something.
>>> 
>>> Vladimir.
>>> 
>>>> Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 with 
>>>> a new command line tool project) and I get the same error there.
>>>> let mf = self.pendingFetchers.popFirst()
>>>>  ~^~~~
>>>> error: 'ArraySlice' is not convertible to '[ModelFetcher]’
>>>>*   *   *
>>>> @Rick, there’s two things in play here:
>>>> * The diagnostic is clearly bogus and you should definitely file a bug 
>>>> about that.
>>>> <https://bugs.swift.org/ <https://bugs.swift.org/>>
>>>> Please post your bug number, just for the record.
>>>> * You wrote:
>>>>> This code compiled fine in Xcode 8 …
>>>> My tests indicate that it doesn’t.  I suspect that you changed something 
>>>> else during the Swift 4 migration and that’s why you’re seeing it fail.  
>>>> Can you take another look at the original Xcode 8 code to see what’s else 
>>>> got changed?
>>>> Share and Enjoy
>>>> --
>>>> Quinn "The Eskimo!"<http://www.apple.com/developer/ 
>>>> <http://www.apple.com/developer/>>
>>>> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
>>>> ___
>>>> swift-users mailing list
>>>> swift-users@swift.org &

Re: [swift-users] Swift 4 "Cannot use mutating member on immutable value: 'self' is immutable"

[Jon Shier via swift-users]

This seems oddly similar to https://bugs.swift.org/browse/SR-5659, but 
[Thing] should meet the appropriate criteria for popFirst to work properly. Yet 
the error we’re seeing here is the same that was originally seen when trying to 
use popFirst on a String. Definitely feels like some sort of Swift bug here.



Jon


> On Sep 14, 2017, at 10:48 AM, Jon Shier via swift-users 
> <swift-users@swift.org> wrote:
> 
>   It also doesn’t explain why removeFirst would work but popFirst 
> doesn’t. The mutation to the underlying array should be the same, the only 
> different is that one returns the element optionally. It also doesn’t explain 
> why popFirst doesn’t show up I the autocomplete but compiles anyway.
> 
> 
> 
> Jon
> 
>> On Sep 14, 2017, at 8:16 AM, Vladimir.S via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> On 14.09.2017 11:14, Quinn "The Eskimo!" via swift-users wrote:
>>> On 14 Sep 2017, at 03:56, somu subscribe via swift-users 
>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>> popFirst is not available in the Array …
>>> Right.  This makes sense when you consider the standard setup for an array, 
>>> namely, a variable length buffer of items.  Removing the first element is 
>>> expensive, whereas removing the last element (`popLast()`) is cheap.
>>> If you run your simplified example in Xcode 8 you get an error that hints 
>>> at what’s going on.
>>> var array = [1, 2, 3, 4, 5]
>>> _ = array.popFirst()
>>> ~~^~~~
>>> error: 'ArraySlice' is not convertible to '[Int]'
>> 
>> Sorry, could you clarify, I can't understand.
>> What should be the error message here and why at all we should have an error 
>> here?
>> 
>> Are we forced to use this code to pop first element in array? :
>> var array = [1, 2, 3, 4, 5]
>> let x = array[0...].popFirst()
>> print(x!) // 1
>> print(array) // [2,3,4,5]
>> 
>> And why we shouldn't be allowed to have popFirst() for array? Yes, it is 
>> expensive, but is it a right reason to disallow it totally? In many 
>> situations we have a small arrays and don't care so much how fast the first 
>> element will be pop'ed.
>> I hope I'm just missing something.
>> 
>> Vladimir.
>> 
>>> Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 with 
>>> a new command line tool project) and I get the same error there.
>>> let mf = self.pendingFetchers.popFirst()
>>>  ~^~~~
>>> error: 'ArraySlice' is not convertible to '[ModelFetcher]’
>>>*   *   *
>>> @Rick, there’s two things in play here:
>>> * The diagnostic is clearly bogus and you should definitely file a bug 
>>> about that.
>>> <https://bugs.swift.org/ <https://bugs.swift.org/>>
>>> Please post your bug number, just for the record.
>>> * You wrote:
>>>> This code compiled fine in Xcode 8 …
>>> My tests indicate that it doesn’t.  I suspect that you changed something 
>>> else during the Swift 4 migration and that’s why you’re seeing it fail.  
>>> Can you take another look at the original Xcode 8 code to see what’s else 
>>> got changed?
>>> Share and Enjoy
>>> --
>>> Quinn "The Eskimo!"<http://www.apple.com/developer/ 
>>> <http://www.apple.com/developer/>>
>>> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> 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

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

Re: [swift-users] Swift 4 "Cannot use mutating member on immutable value: 'self' is immutable"

[Jon Shier via swift-users]

It also doesn’t explain why removeFirst would work but popFirst 
doesn’t. The mutation to the underlying array should be the same, the only 
different is that one returns the element optionally. It also doesn’t explain 
why popFirst doesn’t show up I the autocomplete but compiles anyway.



Jon

> On Sep 14, 2017, at 8:16 AM, Vladimir.S via swift-users 
>  wrote:
> 
> On 14.09.2017 11:14, Quinn "The Eskimo!" via swift-users wrote:
>> On 14 Sep 2017, at 03:56, somu subscribe via swift-users 
>> > wrote:
>>> popFirst is not available in the Array …
>> Right.  This makes sense when you consider the standard setup for an array, 
>> namely, a variable length buffer of items.  Removing the first element is 
>> expensive, whereas removing the last element (`popLast()`) is cheap.
>> If you run your simplified example in Xcode 8 you get an error that hints at 
>> what’s going on.
>> var array = [1, 2, 3, 4, 5]
>> _ = array.popFirst()
>> ~~^~~~
>> error: 'ArraySlice' is not convertible to '[Int]'
> 
> Sorry, could you clarify, I can't understand.
> What should be the error message here and why at all we should have an error 
> here?
> 
> Are we forced to use this code to pop first element in array? :
> var array = [1, 2, 3, 4, 5]
> let x = array[0...].popFirst()
> print(x!) // 1
> print(array) // [2,3,4,5]
> 
> And why we shouldn't be allowed to have popFirst() for array? Yes, it is 
> expensive, but is it a right reason to disallow it totally? In many 
> situations we have a small arrays and don't care so much how fast the first 
> element will be pop'ed.
> I hope I'm just missing something.
> 
> Vladimir.
> 
>> Notably, I put Rick’s code into Xcode 8 (Xcode 8.3.3 on macOS 10.12.6 with a 
>> new command line tool project) and I get the same error there.
>> let mf = self.pendingFetchers.popFirst()
>>  ~^~~~
>> error: 'ArraySlice' is not convertible to '[ModelFetcher]’
>>*   *   *
>> @Rick, there’s two things in play here:
>> * The diagnostic is clearly bogus and you should definitely file a bug about 
>> that.
>> 
>> Please post your bug number, just for the record.
>> * You wrote:
>>> This code compiled fine in Xcode 8 …
>> My tests indicate that it doesn’t.  I suspect that you changed something 
>> else during the Swift 4 migration and that’s why you’re seeing it fail.  Can 
>> you take another look at the original Xcode 8 code to see what’s else got 
>> changed?
>> 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

Re: [swift-users] Swift 4 "Cannot use mutating member on immutable value: 'self' is immutable"

[Jon Shier via swift-users]

I think there’s something strange with popFirst. It doesn’t show up in 
the autocomplete in Xcode, but it compiles, and popLast doesn’t throw the same 
error. removeFirst doesn’t either, though it’s unsafe. Weird.



Jon


> On Sep 13, 2017, at 9:47 PM, Zhao Xin via swift-users  
> wrote:
> 
> I begin to think it is related to how you `popFirst()` implemented. Check it 
> or post it here.
> 
> Zhao Xin
> 
> On Thu, Sep 14, 2017 at 9:36 AM, Roderick Mann  > wrote:
> Yeah, that's not it. I made the change you suggested, I get the same error.
> 
> > On Sep 13, 2017, at 18:11 , Zhao Xin  > > wrote:
> >
> > Change `self` to `ModelFetcher`. You are calling a class static property, 
> > not a class instance property.
> >
> > Zhao Xin
> >
> > On Thu, Sep 14, 2017 at 8:37 AM, Rick Mann via swift-users 
> > > wrote:
> > Moving to Swift 4, I'm running into an issue for which I can't seem to find 
> > an answer in google:
> >
> > "Cannot use mutating member on immutable value: 'self' is immutable"
> >
> > The code looks like:
> >
> > class
> > ModelFetcher : NSObject, URLSessionDelegate
> > {
> > ...
> > static  let managerDispatchQueue=   
> > DispatchQueue(label: "Model Download Manager Queue")
> > static  var pendingFetchers =   
> > [ModelFetcher]()
> > static  var currentFetcher: ModelFetcher?
> >
> > class
> > func
> > startNextFetcher()
> > {
> > self.managerDispatchQueue.async
> > {
> > guard
> > self.currentFetcher == nil,
> > let mf = self.pendingFetchers.popFirst()
> >   ^ error: cannot 
> > use mutating member on immutable value: 'self' is immutable
> > else
> > {
> > return
> > }
> >
> > self.currentFetcher = mf
> > mf.start()
> > }
> > }
> > ...
> > }
> >
> > This code compiled fine in Xcode 8, or in Xcode 9/Swift 3.2 as a monolithic 
> > app (the error shows up when this code is factored into a framework). Other 
> > mutating references to self seem to compile okay (e.g. "self.currentFetcher 
> > = nil" or "self.pendingFetchers.remove(at: idx)"). Not sure what's special 
> > about this one.
> >
> >
> > --
> > 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

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

[swift-users] No Generic Decoders?

[Jon Shier via swift-users]

Swift Users:
I’ve been exploring the creation of Decodable response serializers for 
Alamofire. However, there doesn’t actually seem to be any way to express the 
notion of a generic decoder. The Decoder protocol itself doesn’t require a 
`decode(type:from:)` method, and neither JSONDecoder or PropertyListDecoder 
conform to Decoder in the first place. Were these facts conscious choices or 
oversights? It certainly seems very useful to be able to treat decoders 
generically.



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

Re: [swift-users] Still can't derive from a generic class

[Jon Shier via swift-users]

This works fine for me in a playground in the latest Xcode 9 beta:

class Test { }

class Base { }

class Sub: Base { }

let sub = Sub()



Jon


> On Aug 29, 2017, at 1:04 PM, Joanna Carter via swift-users 
>  wrote:
> 
> Hi
> 
> I would have hoped by now that it should be possible to do :
> 
> class BaseObject
> {
> }
> 
> class Test : BaseObject
> {
> }
> 
> All compiles well but, at runtime, when calling let test = Test(), I get a 
> "EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)" error.
> 
> This is something I have been able to do in C# for many a year. Why oh why 
> can I still not do it in Swift ?
> 
> Joanna
> 
> --
> Joanna Carter
> Carter Consulting
> 
> ___
> 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] What is up with names not being Strings any more in Swift 4?

[Jon Shier via swift-users]

I'd agree with that. Fortunately there are tools out there that can parse such 
things and generate the constants for us already. Waiting for Xcode to 
implement such common sense quality of life improvements probably won't end. 
I'll file bugs in the meantime though. 


Jon

> On Jul 18, 2017, at 1:38 PM, Hooman Mehr via swift-users 
>  wrote:
> 
> I think this should be a feature of Xcode to automatically generate / 
> maintain these constants: When you add assets or create interface builder 
> files, a plug-in could take care of generating / updating such constants and 
> you would get auto-complete and type safety for free.
> 
>> On Jul 18, 2017, at 3:56 AM, Manfred Schubert via swift-users 
>>  wrote:
>> 
>> 
>>> Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users 
>>> :
>>> 
>>> 
 On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users 
  wrote:
 
 Could / should these types be ExpressibleByStringLiteral?
>>> 
>>> They should not. We are deliberately discouraging the string literal of the 
>>> name. The string literal should be in only one place: the definition of the 
>>> name constant. Everything else should use the constant. The compiler can 
>>> provide autocompletion and typo detection of the constant. The string 
>>> literal doesn't get that.
>> 
>> The thing is, with Notification.Name, you have to use them at least twice. 
>> So everybody is creating a constant. And typos in the String that defines 
>> the constant don't matter. So this solves the problem. With NSNib however, 
>> the default case is to use the name only once. And I would say with NSImage 
>> it's probably the same. I don't think people have been defining constants 
>> for these when they are only used once. It makes the code unnecessarily 
>> longer and more complicated. And a typo in the String that defines the 
>> constant matter just as much as a typo in the String literal. So in the 
>> default case this doesn't solve a problem.
>> 
>> 
>> Kind regards,
>> 
>> Manfred
>> ___
>> 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] Printing Enums?

[Jon Shier via swift-users]

Certain Objective-C enums don’t print a useful debug description. I 
usually work around this by implementing CustomStringConvertible (or the debug 
version) for the type myself. You probably want to file a bug with Apple.


Jon


> On Jul 17, 2017, at 6:15 PM, Michael Rogers via swift-users 
>  wrote:
> 
> Hi, All:
> 
> Can someone please enlighten me as to why the first enum works as expected, 
> giving me Melbourne, but the second gives UIModalPresentationStyle rather 
> than fullScreen? 
> 
> 
> enum City {
> case Melbourne, Chelyabinsk, Bursa
> }
> let city = City.Bursa
> 
> print(city)
> // prints "Melbourne"
> 
> let cityName = "\(city)"   // or `let cityName = String(city)`
> // cityName contains "Melbourne"
> 
> // Why doesn't the following work?
> 
> let presStyle = UIModalPresentationStyle.fullScreen
> 
> print(presStyle) // prints UIModalPresentationStyle
> 
> let presStyleName = "\(presStyle)"
> 
> 
> I have an ugly work-around using String UIPresentationStyle tuples, but I'd 
> rather not use it if possible.
> 
> Thanks,
> 
> Michael
> ---
> Dr. Michael P. Rogers
> Associate Professor, Northwest Missouri State University
> Tinkerer-in-Chief and Angel Flight Pilot
> Twitter & Google+:  mprog...@mac.com ;  Skype: 
> mprogersatmac.com ; Facebook: mprogers
> Phone:  309-825-6454 (H);  660-562-1551 (W)
> 
> Thank you, thank you, thank you, and I'd like to thank all the little people 
> -- Tom Thumb, Ant-Man, and, of course, all the Lilliputians -- who made this 
> award possible 
> 
> ___
> 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] What is up with names not being Strings any more in Swift 4?

[Jon Shier via swift-users]

Making them an extension on String makes them visible everywhere String 
is used, unless you limit the visibility in some way, which impacts the 
performance of autocomplete and fills it with random constants. Like I said, 
part of the reason for this is to separate the constants.



Jon

> On Jul 17, 2017, at 12:04 PM, Manfred Schubert  wrote:
> 
> 
>> Am 17.07.2017 um 17:47 schrieb Joe Groff :
>> 
>> Yeah, this is the intended use pattern for these namespaced constant. You 
>> don't need the `rawValue:` label, though:
>> 
>> extension NSImage.Name {
>> static let myImage = Name("myImage")
>> }
> 
> It would be possible to do the same thing as an extension to String without 
> making the default/simple case more complicated. So I would have said this is 
> overkill, but I'm fine with it.
> 
> What remains is the question whether it is possible to create NSBindingNames 
> in a safe way, like from #selector().
> 
> 
> Kind regards,
> 
> Manfred

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

Re: [swift-users] What is up with names not being Strings any more in Swift 4?

[Jon Shier via swift-users]

Like Notification.Name, I believe those types are supposed to help you 
namespace your string constants when you access them. I’d recommend using a 
code gen tool to generate them from your image assets, like:

extension NSImage.Name {
static let customImage = NSImage.Name(rawValue: “customImage”)
}

Which can then be used like: NSImage(named: .customImage). That’s the ultimate 
use goal. It does make the old code awkward and a pain to migrate though.


Jon

> On Jul 17, 2017, at 11:20 AM, Manfred Schubert via swift-users 
>  wrote:
> 
> Why are names no longer Strings any more in Swift 4? I am all for type 
> safety, but now things like
> 
> NSImage(named: "Icon.png")
> 
> become
> 
> NSImage(named: NSImage.Name(rawValue: "Icon.png"))
> 
> and
> 
> NSWindowController(windowNibName: "Window")
> 
> becomes
> 
> NSWindowController(windowNibName: NSNib.Name(rawValue: "Window").
> 
> What does this contrived way of wrapping a String into something else gain in 
> me in safety in exchange for this longer and more difficult to read code? For 
> me a "name" is a prime example of a String. If a name isn't one, then nothing 
> is.
> 
> One place where this makes a lot of sense to have is binding, and there is 
> now NSBindingName. But how do I create a binding name for a property in a way 
> that the compiler can check for validity? I only see the constructor from 
> rawValue (String), but if I only create the binding name from a String I gain 
> nothing in security.
> 
> 
> Kind regards,
> 
> Manfred
> ___
> 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] extension on UISlider breaks interface builder??

[Jon Shier via swift-users]

In my experience, yes, it started with Xcode 8, though I don’t 
specifically remember extending types I was using in IB in Xcode 7.



Jon

> On Jul 14, 2017, at 11:54 PM, David Baraff <davidbar...@gmail.com> wrote:
> 
>> 
>> On Jul 14, 2017, at 8:53 PM, Jon Shier via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>>  Yep, known issue, fixed in Xcode 9 beta 3 according to the release 
>> notes. Hugely annoying, but comment out the extension, connect the outlet, 
>> and comment it back it and should work fine. 
> 
> thank you!  Just to clarify, this isn’t new breakage in xcode 9, but 
> something broken in xcode 8, yes?
> all the more reason to want swift 4 and xcode 9 then...
>> 
>> 
>> Jon
>> 
>>> On Jul 14, 2017, at 11:51 PM, David Baraff via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>> TL;DR
>>> Add an extension to UISlider and interface builder in xcode will no longer 
>>> believe it has *any* actions.
>>> Is this a known issue?
>>> 
>>> 
>>> 1. I added a UISlider to a storyboard in xcode.  I right clicked on it, and 
>>> saw the usual set of things, particularly, actions (sent events):
>>> 
>>> 
>>> 
>>> Next, I wrote this:
>>> 
>>> public protocol ModelDataValuedUIControl: class {
>>>   var xxcontrolValue:Any {
>>>   get set
>>>   }
>>> }
>>> 
>>> extension UISlider : ModelDataValuedUIControl {
>>>   public var xxcontrolValue:Any {
>>>   get {
>>>   return self.value
>>>   }
>>> 
>>>   set(newValue) {
>>>   self.value = newValue as! Float
>>>   }
>>>   }
>>> }
>>> 
>>> 
>>> Lo and behold, after compiling, interface builder *hates* sliders, because 
>>> now the rightclick menu looks like this:
>>> 
>>> 
>>> ___
>>> swift-users mailing list
>>> swift-users@swift.org
>>> 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] Swift 4 thread sanitizer more sensitive?

[Jon Shier via swift-users]

Thanks Kuba! I have a PR already that adds a lock around the task, which seems 
to make the sanitizer happy. 



Jon

> On Jul 6, 2017, at 11:39 AM, Kuba Mracek <mra...@apple.com> wrote:
> 
> Looks like a real race.  It seems irrelevant whether it's run under Swift 3.2 
> or Swift 4 mode, but TSan only detects the issue sometimes.  Most likely 
> that's either because:
> 
> 1) the order of the async callbacks (via DispatchQueue.utility.async, etc.) 
> can be "okay" in some program runs, or
> 2) the racy accesses just happen to be done on the same thread (even when 
> they're on different queues).
> 
> In any case, the SessionManager.retry method seems to be modifying the 
> request and that's not synchronized with the main thread using the request.  
> Again, looks like a real race that needs fixing.
> 
> Kuba
> 
>> On 2 Jul 2017, at 16:53, Jon Shier <j...@jonshier.com> wrote:
>> 
>>  Investigating this now more thoroughly and it appears my initial 
>> concern was wrong, as it’s detected the threading issues in Swift 3.2 mode 
>> as well. I’m not sure whether this was an Xcode 9b1 issue, a product of 
>> switching the Swift version back and forth while make Alamofire compatible 
>> with Swift 3.2 and 4 or what, but the issue does appear now in both 3.2 and 
>> 4. I’m tracking the issue in 
>> https://github.com/Alamofire/Alamofire/issues/2189 but it seems to be a 
>> legit issue. Thanks!
>> 
>> 
>> 
>> Jon
>> 
>>>> On Jun 26, 2017, at 1:54 PM, Joe Groff <jgr...@apple.com> wrote:
>>>> 
>>>> 
>>>>> On Jun 26, 2017, at 10:33 AM, Joe Groff via swift-users 
>>>>> <swift-users@swift.org> wrote:
>>>>> 
>>>>> 
>>>>> On Jun 25, 2017, at 3:56 PM, Jon Shier via swift-users 
>>>>> <swift-users@swift.org> wrote:
>>>>> 
>>>>>   Running Alamofire through the thread sanitizer and the thread sanitizer 
>>>>> finds issues in Swift 4 mode but not Swift 3.2. Does Swift 4 add 
>>>>> additional threading instrumentation that you don’t get under other 
>>>>> versions? Or is there some other runtime difference that explains it?
>>>> 
>>>> Would you be able to file bugs for specific issues so we can investigate 
>>>> whether the behavior changes are intentional?
>>> 
>>> cc'ing Anna, Devin, and Kuba who worked on improving TSan support for Swift.
>>> 
>>> -Joe
>> 
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Disable "indexing while building" in Xcode9 (unknown argument: `-index-store-path`)

[Jon Shier via swift-users]

It had to be merged from Apple’s upstream changes, as pointed out at 
the start of this thread, so the feature requires compiler integration. It’s 
likely the same work was done in clang/llvm for the C-based language side of 
things. Even if it’s an Apple-only feature (as this index format seems Apple 
specific, according to the comments in the merged PR), once it touches the 
compiler, development should be done in the open and not as upstream dumps, 
IMO. Otherwise things can get out of sync pretty badly.



Jon

> On Jul 4, 2017, at 11:21 PM, Jonathan Prescott <jprescot...@icloud.com> wrote:
> 
> I think the indexing while building is really part of Xcode and not Swift 
> since it also works on C, C++, Obj-C and Obj-C++.  It’s not just for Swift.
> Jonathan
> 
>> On Jul 4, 2017, at 11:18 PM, Jon Shier <j...@jonshier.com 
>> <mailto:j...@jonshier.com>> wrote:
>> 
>>  The feature this thread is about, indexing while building. I’m of the 
>> opinion that, if a feature needs to be integrated with the Swift compiler, 
>> as this one was, development of that integration should be done in the open. 
>> Perhaps I misunderstand how this feature is separated between the compiler 
>> and higher level tools, but avoiding a month long mismatch between the open 
>> source and Apple versions, one which prevents open source snapshots from 
>> working in Xcode at all, is a good thing, no?
>> 
>> 
>> 
>> Jon
>> 
>>> On Jul 4, 2017, at 11:14 PM, Jonathan Prescott <jprescot...@icloud.com 
>>> <mailto:jprescot...@icloud.com>> wrote:
>>> 
>>> I’m curious what Swift features you think Apple is developing internally 
>>> that is not being done concurrently as part of, or totally within, the 
>>> open-source project.  To me, everything that is the compiler(s), debugger, 
>>> standard librarIes, package manager are all being constructed completely 
>>> within the open-source community (both LLVM/CLang and Swift).  All of the 
>>> Xcode pieces you explicitly mentioned (the source code editor, the build 
>>> system, for example) are all part of the Xcode application, and should be 
>>> developed by Apple as part of their product offering to whatever level of 
>>> privacy they desire.  And, the iPad Playgrounds Application is 
>>> Apple-proprietary as well.
>>> 
>>> What components/Swift features are you concerned about?
>>> 
>>> Just asking.
>>> 
>>> Jonathan
>>> 
>>>> On Jul 4, 2017, at 9:20 PM, Jon Shier via swift-users 
>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>> 
>>>>Xcode 9 fixes my biggest complaint about Xcode, which was the text 
>>>> editor. The new one, based off the one used in the Playgrounds iPad app, 
>>>> is far better in pretty much every way than the old one. It’s still 
>>>> missing features (which should be added by release) but I use it as much 
>>>> as I can. It still suffers from some of the same issues as the old editor, 
>>>> namely that its functionality breaks almost completely when SourceKit 
>>>> crashes, which is really annoying for stuff like syntax highlighting and 
>>>> auto indentation, since it seems like that stuff shouldn’t break when that 
>>>> happens. But it recovers a bit better now from those situations. The new 
>>>> build system is also really nice, though largely invisible.
>>>>I do find it concerning that Apple is developing Swift features 
>>>> internally, which is rather antithetical to open source development and 
>>>> leads to painful transition periods like this where Apple’s version and 
>>>> the open source version are out of sync. It really doesn’t seem necessary 
>>>> for these features to be developed privately. I would hope the Swift 
>>>> project takes a more WebKit-like approach to these features, where all 
>>>> features are developed in the open source branch, with only the SPI 
>>>> integration private to Apple. Features like the content filters shipped 
>>>> last year were fully visible in the open source tree long before WWDC. It 
>>>> would be better for Swift to develop all of these features in the open.
>>>> 
>>>> 
>>>> 
>>>> Jon
>>>> 
>>>>> On Jul 4, 2017, at 9:05 PM, David Baraff via swift-users 
>>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>>> 
>>>>> How is xcode9 b

Re: [swift-users] Disable "indexing while building" in Xcode9 (unknown argument: `-index-store-path`)

[Jon Shier via swift-users]

Xcode 9 fixes my biggest complaint about Xcode, which was the text 
editor. The new one, based off the one used in the Playgrounds iPad app, is far 
better in pretty much every way than the old one. It’s still missing features 
(which should be added by release) but I use it as much as I can. It still 
suffers from some of the same issues as the old editor, namely that its 
functionality breaks almost completely when SourceKit crashes, which is really 
annoying for stuff like syntax highlighting and auto indentation, since it 
seems like that stuff shouldn’t break when that happens. But it recovers a bit 
better now from those situations. The new build system is also really nice, 
though largely invisible.
I do find it concerning that Apple is developing Swift features 
internally, which is rather antithetical to open source development and leads 
to painful transition periods like this where Apple’s version and the open 
source version are out of sync. It really doesn’t seem necessary for these 
features to be developed privately. I would hope the Swift project takes a more 
WebKit-like approach to these features, where all features are developed in the 
open source branch, with only the SPI integration private to Apple. Features 
like the content filters shipped last year were fully visible in the open 
source tree long before WWDC. It would be better for Swift to develop all of 
these features in the open.



Jon

> On Jul 4, 2017, at 9:05 PM, David Baraff via swift-users 
>  wrote:
> 
> How is xcode9 beta going in general?  I would dearly love to start using the 
> new Codable stuff, and I don’t have to really worry about swift 3 
> compatability — it’s just a question of the xcode 9 beta being safe enough to 
> get work done.
> 
> (The fact that “yank” was broken makes it a non-starter for me but i’m kind 
> of hoping it gets fixed soon.)
> 
> 
>> On Jul 4, 2017, at 6:02 PM, Anders Hasselqvist via swift-users 
>> > wrote:
>> 
>> Hi,
>> 
>> I've been trying to use the swift4 snapshot toolchains with Xcode9 beta with 
>> little success.
>> 
>> When building I get the error:
>> "
>> :0: error: unknown argument: '-index-store-path'
>> Command 
>> /Library/Developer/Toolchains/swift-4.0-DEVELOPMENT-SNAPSHOT-2017-06-29-a.xctoolchain/usr/bin/swiftc
>>  failed with exit code 1
>> "
>> 
>> I believe that this because of missing "indexing while building" support in 
>> the open source swift in the currently available snapshots. (The feature was 
>> merged just a few days ago: https://github.com/apple/swift/pull/10726 
>> )
>> 
>> Is there a way to disable "indexing while building" in Xcode9?
>> 
>> Thanks,
>> Anders
>> 
>> ___
>> 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 4 thread sanitizer more sensitive?

[Jon Shier via swift-users]

Investigating this now more thoroughly and it appears my initial 
concern was wrong, as it’s detected the threading issues in Swift 3.2 mode as 
well. I’m not sure whether this was an Xcode 9b1 issue, a product of switching 
the Swift version back and forth while make Alamofire compatible with Swift 3.2 
and 4 or what, but the issue does appear now in both 3.2 and 4. I’m tracking 
the issue in https://github.com/Alamofire/Alamofire/issues/2189 
<https://github.com/Alamofire/Alamofire/issues/2189> but it seems to be a legit 
issue. Thanks!



Jon

> On Jun 26, 2017, at 1:54 PM, Joe Groff <jgr...@apple.com> wrote:
> 
> 
>> On Jun 26, 2017, at 10:33 AM, Joe Groff via swift-users 
>> <swift-users@swift.org> wrote:
>> 
>> 
>>> On Jun 25, 2017, at 3:56 PM, Jon Shier via swift-users 
>>> <swift-users@swift.org> wrote:
>>> 
>>> Running Alamofire through the thread sanitizer and the thread sanitizer 
>>> finds issues in Swift 4 mode but not Swift 3.2. Does Swift 4 add additional 
>>> threading instrumentation that you don’t get under other versions? Or is 
>>> there some other runtime difference that explains it?
>> 
>> Would you be able to file bugs for specific issues so we can investigate 
>> whether the behavior changes are intentional?
> 
> cc'ing Anna, Devin, and Kuba who worked on improving TSan support for Swift.
> 
> -Joe

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

Re: [swift-users] Swift Documentation question

[Jon Shier via swift-users]

swiftdoc.org  should be integrated into swift.org 
 and be kept officially up to date. Unfortunately it doesn’t 
have Swift 4 coverage yet, which is a shame, as I like that documentation 
format more than Apple’s official one. 


Jon

> On Jul 1, 2017, at 12:04 PM, Marco S Hyman via swift-users 
>  wrote:
> 
>> but what I am looking for is something that lists the various protocols and 
>> types that make up the standard library with links to the reference pages 
>> for the types and protocols. Does documentation like this exist? I thought I 
>> have seen this documentation before but for the life of me I have not been 
>> able to find it.
> 
> http://swiftdoc.org
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

[swift-users] Swift 4 thread sanitizer more sensitive?

[Jon Shier via swift-users]

Running Alamofire through the thread sanitizer and the thread sanitizer 
finds issues in Swift 4 mode but not Swift 3.2. Does Swift 4 add additional 
threading instrumentation that you don’t get under other versions? Or is there 
some other runtime difference that explains it?



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

Re: [swift-users] intercept fatalError() or other termination messages from swift?

[Jon Shier via swift-users]

Crashlytics can pick up these strings just fine. I thought they were part of 
the full crash dump. 

> On Jun 24, 2017, at 12:13 AM, David Baraff via swift-users 
>  wrote:
> 
> I realize this is slightly centric to iOS, but it irks me that both Apple’s 
> crash report logs and popular platforms like PLCrashReporter can do the hard 
> stuff like give you a stack trace, but are *completely* unable to display the 
> error message from terminating a program via fatalError(), or the error 
> message from, e.g. dying with a bad optional.
> 
> Is there *any* to intercept the error messages that from fatalError() and 
> similar like things in swift (bad optionals, invalid array accesses, 
> assertions)?  I would think that some sort of a “hook” into these standard 
> error routines would be a good thing.
> 
> In my case, if I could simply save that darn error string in a file, i could 
> pick it up when the app next launches and report it along with the rest of 
> the info like the stack/signal, etc.
> 
> I’ve been looking through the code in stdlib/public/runtime/Errors.cpp but 
> haven’t found anything promising that lets me jump in there.  In my code, I’m 
> likely to write things like
>guard let x = … else {
>fatalError(“Data type has payload  but is hooked to UI control with 
> intrinsic type ”)
>}
> 
> and having that exact string tells me precisely what’s going, far simpler 
> than a stack trace.
> 
> 
> ___
> 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] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[Jon Shier via swift-users]

Itai:

No need to apologize, I do appreciate the difficulties of designing this entire 
feature as quickly and completely as was required. 

An intermediate JSON type would be a great fix, though most useful if it exists 
outside of JSONDecoder so it's useful for encoding as well. As long as it can 
be initialize from outside and decoded on its own, I think it could solve much 
of that issue. 


Jo 

> On Jun 23, 2017, at 12:54 PM, Itai Ferber <ifer...@apple.com> wrote:
> 
> Hi Jon,
> 
> I just joined this mailing list and have tried to catch up on the history of 
> this thread, so please excuse me if I’ve missed something.
> 
> I’m sorry the Codable API at the moment does not answer your needs — you’re 
> clearly not the only one who’s run into this, so let’s see how we can work 
> together to make the API better for everyone.
> For one thing, in the case of grabbing a subtree of JSON as "unevaluated" or 
> "unmapped" (as it appears to be in the metadata case), it should be fairly 
> simple to add a JSONDecoder.UnevaluatedJSON type that will allow you to 
> essentially decode that part of the tree as an Any. JSONDecoder would have 
> knowledge of this type and would be able to return the subtree inside of it — 
> you’d decode a property as JSONDecoder.UnevaluatedJSON.self and access the 
> contents through var value: Any?, or something similar. This would be simple 
> additive API, which although might not make it in the upcoming betas, should 
> be fairly simple introduce. Would this solve that use case?
> 
> We’re also working on improving NSISO8601DateFormatter. I don’t think I saw 
> it in any of your emails — what specific use case are you looking for that it 
> doesn’t at the moment support?
> 
> — Itai
> 
> On 23 Jun 2017, at 9:24, Jon Shier via swift-users wrote:
> 
> David:
>   I never called the design silly (though I think it’s inadequate for 
> some important usage and makes some strange decisions), I was referring to 
> the fact that the (apparent) official solution can’t actually decode all of 
> the JSON people use. It’s the same reason I brought up 
> NSISO8601DateFormatter. After years of using third party libraries or writing 
> your own, limited, implementation, finally, finally there was an official 
> solution from Apple. The official 8601 date formatter. Only, come to find 
> out, it doesn’t actually handle all of 8601 and those third party libraries 
> or custom implementations are still required if you venture outside supported 
> scenarios. I’m concerned about the same thing happening here. Now, if 
> JSONDecoder isn’t actually intended to serve as a general JSON parsing 
> solution, which I think would be surprising to a lot people, then fair 
> enough. Apple and the Swift team just need to be far more clear that that’s 
> the case, rather letting everyone believe otherwise. And frankly, if that’s 
> the case, I think a huge opportunity has been missed. At the same time, if / 
> when an official solution for JSON parsing comes out, or an actual JSON 
> representation, how will it interact with the previous implementation?
>   These concerns, and the general concerns I expressed during the 
> evolution review (which still exist) aside, this is fixable, if the Swift 
> team is interested in doing so. However, if the limitations of JSONDecoder 
> aren’t even seen as limitations, or interest in fixing them aren’t there, 
> then there’s little point to continuing the discussion. Something as simple 
> as an additional decode(_ type: from: Any) on JSONDecoder would solve the 
> issues with decoding partially deserialized blobs or representations from 
> other APIs. Something to help represent Any in Codable types might be useful, 
> though I recognize that there isn’t any way to currently differentiate 
> between Codable types and those just used by JSON. 
>   All of that said, my concerns mainly lie within the JSON realm. Codable 
> works great for serialization to disk or other scenarios where I can just 
> deal with the Data result and not have to worry about weakly typed 
> intermediate results. I’ll certainly be using it everywhere I can. And I’m 
> super happy that conformance is generated by the compiler rather than 
> manually, like we had to do with Objective-C for over a decade. Even the JSON 
> side is useful if I can control both sides of the API, which makes Swift on 
> the server very powerful.
>   So if I seem overly strident in my expression here it’s because I 
> experience the pain of consuming poorly designed JSON in Swift on practically 
> a daily basis and had hoped that a native implementation would alleviate 
> that. That it doesn’t, for me and others, currently, is very disappointing. 
> That the Swift team

Re: [swift-users] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[Jon Shier via swift-users]

Your gist is extremely interesting to me. I had tried something similar 
with Argo’s existing JSON enum, but was somewhat stymied by trying to decode it 
from an unkeyed container. I suppose I still don’t have a good grasp on all of 
the existing container types.



Jon


> On Jun 23, 2017, at 11:46 AM, Randy Eckenrode via swift-users 
>  wrote:
> 
>> 
>> On Jun 17, 2017, at 10:07 PM, Chris Anderson via swift-users 
>> > wrote:
>> 
>> Say I have a JSON object such as:
>> 
>>   {
>> "id": "4yq6txdpfadhbaqnwp3",
>> "email": "john@example.com ",
>> "name":"John Doe",
>> "metadata": {
>>   "link_id": "linked-id",
>>   "buy_count": 4
>> }
>>   }
>> 
>> And with a struct of:
>> 
>> struct User: Codable {
>>   var id: String
>>   var email: String
>>   var name: String
>> }
>> 
>> How can I decode the `metadata` field into a Dictionary?
>> 
>> I’ve tried doing things such as, in my struct,
>> 
>> var metadata: Dictionary
>> 
>> or
>> 
>> var metadata: [String: Any]
>> 
>> But I get the error 
>> 
>> MyPlayground.playground:3:7: note: cannot automatically synthesize 
>> 'Encodable' because '<>' does not conform to 'Encodable'
>>   var metadata: Dictionary 
>> 
>> A meta or metadata field on many APIs (such as www.stripe.com 
>> ) can contain whatever you want, and I still want to 
>> be able to process it on the Swift end. How can I store that meta data field 
>> into a Dictionary that I can parse apart manually after?
> 
> It’s possible, but you have to do most of the work yourself because you the 
> compiler can’t create implementations for you. See below for a possible 
> implementation. Note that I just ignore types I don’t handle. I also took a 
> stab at doing something general in this gist 
> (https://gist.github.com/kenada/069e121371eb8db41231edfcd4bd14a8 
> ), but it 
> doesn’t implement very robust error handling or support encoding. It also 
> doesn’t flatten down to Any/[Any]/[String: Any] (leaving it up to the user to 
> destructure the enum).
> 
> import Foundation
> 
> struct User: Codable {
> var id: String
> var email: String
> var name: String
> var metadata: [String: Any]
> 
> init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: StaticCodingKeys.self)
> self.id = try container.decode(String.self, forKey: .id)
> self.email = try container.decode(String.self, forKey: .email)
> self.name = try container.decode(String.self, forKey: .name)
> self.metadata = try User.decodeMetadata(from: 
> container.superDecoder(forKey: .metadata))
> }
> 
> func encode(to encoder: Encoder) throws {
> var container = encoder.container(keyedBy: StaticCodingKeys.self)
> try container.encode(self.id, forKey: .id)
> try container.encode(self.email, forKey: .email)
> try container.encode(self.name, forKey: .name)
> try encodeMetadata(to: container.superEncoder(forKey: .metadata))
> }
> 
>static func decodeMetadata(from decoder: Decoder) throws -> [String: Any] {
> let container = try decoder.container(keyedBy: DynamicCodingKeys.self)
> var result: [String: Any] = [:]
> for key in container.allKeys {
> if let double = try? container.decode(Double.self, forKey: key) {
> result[key.stringValue] = double
> } else if let string = try? container.decode(String.self, forKey: 
> key) {
> result[key.stringValue] = string
> }
> }
> return result
> }
> 
> func encodeMetadata(to encoder: Encoder) throws {
> var container = encoder.container(keyedBy: DynamicCodingKeys.self)
> for (key, value) in metadata {
> switch value {
> case let double as Double:
> try container.encode(double, forKey: 
> DynamicCodingKeys(stringValue: key)!)
> case let string as String:
> try container.encode(string, forKey: 
> DynamicCodingKeys(stringValue: key)!)
> default:
> fatalError("unexpected type")
> }
> }
> }
> 
> private enum StaticCodingKeys: String, CodingKey {
> case id, email, name, metadata
> }
> 
> private struct DynamicCodingKeys: CodingKey {
> var stringValue: String
> 
> init?(stringValue: String) {
> self.stringValue = stringValue
> }
> 
> var intValue: Int?
> 
> init?(intValue: Int) {
> self.init(stringValue: "")
> self.intValue = intValue
> }
> }
> }
> 
> let userJson = """
>   {
> "id": "4yq6txdpfadhbaqnwp3",
> "email": "john@example.com ",
> "name":"John Doe",
> 

Re: [swift-users] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[Jon Shier via swift-users]

David:
I never called the design silly (though I think it’s inadequate for 
some important usage and makes some strange decisions), I was referring to the 
fact that the (apparent) official solution can’t actually decode all of the 
JSON people use. It’s the same reason I brought up NSISO8601DateFormatter. 
After years of using third party libraries or writing your own, limited, 
implementation, finally, finally there was an official solution from Apple. The 
official 8601 date formatter. Only, come to find out, it doesn’t actually 
handle all of 8601 and those third party libraries or custom implementations 
are still required if you venture outside supported scenarios. I’m concerned 
about the same thing happening here. Now, if JSONDecoder isn’t actually 
intended to serve as a general JSON parsing solution, which I think would be 
surprising to a lot people, then fair enough. Apple and the Swift team just 
need to be far more clear that that’s the case, rather letting everyone believe 
otherwise. And frankly, if that’s the case, I think a huge opportunity has been 
missed. At the same time, if / when an official solution for JSON parsing comes 
out, or an actual JSON representation, how will it interact with the previous 
implementation?
These concerns, and the general concerns I expressed during the 
evolution review (which still exist) aside, this is fixable, if the Swift team 
is interested in doing so. However, if the limitations of JSONDecoder aren’t 
even seen as limitations, or interest in fixing them aren’t there, then there’s 
little point to continuing the discussion. Something as simple as an additional 
decode(_ type: from: Any) on JSONDecoder would solve the issues with decoding 
partially deserialized blobs or representations from other APIs. Something to 
help represent Any in Codable types might be useful, though I recognize that 
there isn’t any way to currently differentiate between Codable types and those 
just used by JSON. 
All of that said, my concerns mainly lie within the JSON realm. Codable 
works great for serialization to disk or other scenarios where I can just deal 
with the Data result and not have to worry about weakly typed intermediate 
results. I’ll certainly be using it everywhere I can. And I’m super happy that 
conformance is generated by the compiler rather than manually, like we had to 
do with Objective-C for over a decade. Even the JSON side is useful if I can 
control both sides of the API, which makes Swift on the server very powerful.
So if I seem overly strident in my expression here it’s because I 
experience the pain of consuming poorly designed JSON in Swift on practically a 
daily basis and had hoped that a native implementation would alleviate that. 
That it doesn’t, for me and others, currently, is very disappointing. That the 
Swift team doesn’t seem to see the current limitations as important or at all 
is doubly so, since it seems like these issues will never be fixed.  



Jon


> On Jun 23, 2017, at 4:34 AM, David Hart <da...@hartbit.com> wrote:
> 
> 
> On 23 Jun 2017, at 03:45, Jon Shier via swift-users <swift-users@swift.org 
> <mailto:swift-users@swift.org>> wrote:
> 
>>  I’m sorry, are you complaining about my use of Codable instead of more 
>> precisely referring to the JSON endcode/decode functionality based on it in 
>> Foundation, or are you honestly trying to say that said functionality was 
>> never intended to be a general purpose JSON solution? If it’s not actually 
>> intended to handle all JSON you should probably call it something else.
> 
> Hi Jon,
> 
> First of all, I'd like to point out that I've found your tone to be quite 
> rude. Calling the design of Codable, that has gotten a lot of work from Apple 
> and swift-evolution, as silly is insulting and can leave people hurt. If you 
> have found it lacking, please say so: we're all here to discuss any feedback 
> people have had with Swift. But please do so with respect for the people and 
> the work behind it.
> 
> Now, concerning Codable, I find its name quite apt. It was never intended to 
> be used a full JSON parser but as a strongly-typed Swift equivalent of 
> Objective-C's NSCoding, which is nothing more than a framework for 
> serializing and deserializing types into different file formats.
> 
> David.
> 
>> Jon
>> 
>>> On Jun 22, 2017, at 9:42 PM, Greg Parker <gpar...@apple.com 
>>> <mailto:gpar...@apple.com>> wrote:
>>> 
>>> 
>>>> On Jun 22, 2017, at 6:00 PM, Jon Shier via swift-users 
>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>> 
>>>>My main concern here is that, as Swift’s official JSON parsing method, 
>>>> Codable should be able to handle any JS

Re: [swift-users] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[Jon Shier via swift-users]

I’m sorry, are you complaining about my use of Codable instead of more 
precisely referring to the JSON endcode/decode functionality based on it in 
Foundation, or are you honestly trying to say that said functionality was never 
intended to be a general purpose JSON solution? If it’s not actually intended 
to handle all JSON you should probably call it something else.


Jon

> On Jun 22, 2017, at 9:42 PM, Greg Parker <gpar...@apple.com> wrote:
> 
> 
>> On Jun 22, 2017, at 6:00 PM, Jon Shier via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>>  My main concern here is that, as Swift’s official JSON parsing method, 
>> Codable should be able to handle any JSON representation and use and it 
>> doesn’t.
> 
> Is this true? Is Codable intended to be Swift's official JSON parsing system? 
> Is Codable intended to be a general-purpose JSON parsing system? 
> 
> My understanding was that Codable was designed to serialize Swift types, not 
> to be able to import arbitrary JSON text into Swift nor to interoperate with 
> every existing JSON API.
> 
> 
> -- 
> Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime 
> Wrangler
> 
> 

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

Re: [swift-users] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[Jon Shier via swift-users]

Tony:
My main concern here is that, as Swift’s official JSON parsing method, 
Codable should be able to handle any JSON representation and use and it 
doesn’t. In fact, it can’t. If that’s considered okay by the designers of the 
library and Apple itself, then fine. I think it’s silly (just like I think it’s 
silly that, after years of waiting, NSISO8601DateFormatter doesn’t actually 
support the full ISO 8601 standard) and does a disservice to developers, but 
fine. For example, many JSON APIs (from the very worst to some of the best) use 
a common reply structure:

{
“value” : { } or null
“error” : { } or null
}

Having implemented a few of these using Argo, I usually follow a common pattern:

struct APIResponse: Argo.Decodable {
let value: JSON?
let error: APIError?
}

I then decode the response, check to see which of the parts is non-null, and 
continue decoding based on that result. I decode the value based on the generic 
type passed in, usually in an Alamofire response serializer. Codable can sort 
of represent this, with this:

struct APIResponse: Decodable {
let value: T?
let error: String? // String as I haven’t defined an error type.
}

This works, AFAICT, but loses the rather important ability to inspect 
the decoding result before attempting to decode the generic value. Codable 
would be perfectly happy to return me an APIResponse with two nil values, which 
is an invalid state for this API and should be an error. (As an aside, 
defaulting all errors for optional values to nil is poor practice and we lose 
some error fidelity there.) This is really just a symptom of Foundation not 
having a real JSON limitation. But it’s doubly concerning that the JSON 
representation it does have, Any, can’t be parsed by it’s own JSON decoder. 
Dealing with data also limits Codable’s use for JSON to only things 
that have data representation. For example, push notifications can contain 
custom JSON payloads. On Apple platforms the push handler automatically decodes 
this JSON before passing the result to the delegates in the app. In the past 
I’ve been able to use the same JSON representations to parse the Any returned 
by the push delegates as I do in my networking API, which gives me exactly the 
same parsing for both methods. Codable can’t be used here. 
In addition, Codable’s cumbersome API for custom APIs is rather painful 
to deal with, and the official recommended solution to use *Raw types that come 
from your API and are used to initialize your “real” types is untenable (on one 
project, every type I got in a response wouldn’t have required this, forcing me 
to maintain 60 types, manually). Add to that the manual nature of any sort of 
transform or validation, and Codable for real JSON decoding becomes rather 
painful.
For me, this means that I’ll likely stick to libraries like Argo for 
actual JSON decoding (greater fidelity and flexibility in far less code) and 
use Codable for disk and other transfer representations (I look forward to 
writing my watch communication using it) only, in all but the most ideal 
circumstances (if I design the JSON API I can optimize it around Codable).


Jon Shier


> On Jun 22, 2017, at 7:10 PM, Tony Parker <anthony.par...@apple.com> wrote:
> 
> Hi Jon,
> 
> Usually this boils down to a question of: what are you going to do with the 
> Any?
> 
> If you intended to cast it to a dictionary and get at its values using string 
> keys, then writing a struct with the properties you care about is the way we 
> recommend doing this. You don’t have to include every possible key.
> 
> There are some more dynamic behaviors possible with the Any, but the point of 
> this API was to try to move a lot of the parsing into a place where the 
> compiler could help you not only to generate the boilerplate but catch errors 
> at compile time.
> 
> The omission of an API to just get the rest of the data as some kind of Any 
> is both for reasons of abstraction (not every data format is JSON, and the 
> Any truly could be anything in other formats), and a statement of intent of 
> how we believe this API is best used.
> 
> - Tony
> 
>> On Jun 18, 2017, at 7:23 PM, Jon Shier via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> Given that, per his description, “metadata” can be anything, creating a 
>> struct doesn’t really help.
>> 
>> 
>> 
>> Jon Shier
>> 
>>> On Jun 18, 2017, at 9:00 PM, somu subscribe <somu.subscr...@gmail.com 
>>> <mailto:somu.subscr...@gmail.com>> wrote:
>>> 
>>> Create a struct for Metadata and conform to Coding
>>> 
>>> Code:
>>> 
>>> let string = """
>>> {
>>>   "id&q

Re: [swift-users] Extensions on Typealiased Existential Protocols

[Jon Shier via swift-users]

What I usually do here is:
typealias CProtocol = A & B
protocol C: CProtocol { } // or just A & B directly, I think
extension C {}

So it’s a bit silly to me.


Jon


> On Jun 19, 2017, at 3:44 PM, Slava Pestov via swift-users 
>  wrote:
> 
> Hi Steven,
> 
>> On Jun 19, 2017, at 11:44 AM, Steven Brunwasser via swift-users 
>> > wrote:
>> 
>> Is this error intentional, or a bug?
> 
> It’s intentional. We could add support for this as an extra bit of sugar, but 
> note that
> 
>> Since extension A where Self: B is the same as extension B where Self: A,
> 
> This is not quite true.
> 
> Slava
> 
> ___
> 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] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[Jon Shier via swift-users]

Given that, per his description, “metadata” can be anything, creating a struct 
doesn’t really help.



Jon Shier

> On Jun 18, 2017, at 9:00 PM, somu subscribe <somu.subscr...@gmail.com> wrote:
> 
> Create a struct for Metadata and conform to Coding
> 
> Code:
> 
> let string = """
> {
>   "id": "4yq6txdpfadhbaqnwp3",
>   "email": "john@example.com <mailto:john@example.com>",
>   "name":"John Doe",
>   "metadata": {
> "link_id": "linked-id",
> "buy_count": 4
>   }
> }
> """
> 
> let data = string.data(using: .utf8)! //Force unwrapping just for ease of 
> explanation, use guard instead
> 
> struct User: Codable {
> 
> //Struct to handle the nested JSON
> struct Metadata : Codable {
> var linkID   : String
> var buyCount : Int
> 
> //Customisation, if you want if you want your properties to be 
> different from the JSON key
> private enum CodingKeys : String, CodingKey {
> case linkID = "link_id"
> case buyCount   = "buy_count"
> }
> }
> 
> var id: String
> var email: String
> var name : String
> var metadata : Metadata
> }
> 
> let decoder = JSONDecoder()
> 
> do {
> let user = try decoder.decode(User.self, from: data)
> print(user)
> }
> catch {
> print("error:\(error)")
> }
> 
> Reference:
> 
> https://developer.apple.com/videos/play/wwdc2017/212/ 
> <https://developer.apple.com/videos/play/wwdc2017/212/>
> 
> 
> Regards,
> Muthu
> 
> 
> 
>> On 19 Jun 2017, at 3:29 AM, Jon Shier via swift-users <swift-users@swift.org 
>> <mailto:swift-users@swift.org>> wrote:
>> 
>>  The more I use Codable, the less suited to networking it becomes. In 
>> reading a variety of blog posts about implementing custom Decodable support 
>> from JSON, I kept running across the same pattern. Basically, users had 
>> started implementing their own decoding protocols which wrap Decodable 
>> types, and have a type that represents the JSON representation and then 
>> their real type, with an initializer connecting the two. But apparently this 
>> is Apple’s official solution, which is rather terrible since it would be 
>> completely unnecessary if the Decodable APIs were more flexible or we could 
>> access keys by key path rather than nesting full containers. I can’t image 
>> how much code I would have to add to decode the nasty JSON APIs I’ve used 
>> Argo to parse before. Every type would need an underlying raw representation 
>> that, at the very least, would need custom keys, lest I pollute even those 
>> models with the terrible keys the JSON actually has. Not to mention the 
>> various transforms I needed. Once I hit any reasonably complex API, Argo is 
>> far far simpler to implement in fewer lines of code.
>>  In trying to make Argo’s JSON enum Decodable itself, I can’t seem to 
>> find a way to access the Any representation of the raw JSON. In fact, it 
>> appears there’s no way to represent an Any value in Codable at all, which 
>> makes Codable rather useless for the scenarios like the one that prompted 
>> this thread. Without such an ability it’s impossible to actually use Codable 
>> with all of the JSON out there, where other solutions work just fine. Argo’s 
>> JSON type is decodable by Argo, so you can use it to represent a blob of 
>> JSON just fine. Other existing JSON frameworks have similar solutions. 
>> 
>> 
>> 
>> Jon
>> 
>>> On Jun 18, 2017, at 3:21 AM, Rien via swift-users <swift-users@swift.org 
>>> <mailto:swift-users@swift.org>> wrote:
>>> 
>>> Dang, hit send too soon. Sorry.
>>> 
>>> This does not address your question, so please ignore… (foot in mouth)!
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl <http://balancingrock.nl/>
>>> Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/>
>>> Github: http://github.com/Balancingrock <http://github.com/Balancingrock>
>>> Project: http://swiftfire.nl <http://swiftfire.nl/> - An HTTP(S) web server 
>>> framework in Swift
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On 18 Jun 2017, at 09:19, Rien <r...@balancingrock.nl 
>>>> <mailto:r...@balancingrock.nl>>

Re: [swift-users] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[Jon Shier via swift-users]

The more I use Codable, the less suited to networking it becomes. In 
reading a variety of blog posts about implementing custom Decodable support 
from JSON, I kept running across the same pattern. Basically, users had started 
implementing their own decoding protocols which wrap Decodable types, and have 
a type that represents the JSON representation and then their real type, with 
an initializer connecting the two. But apparently this is Apple’s official 
solution, which is rather terrible since it would be completely unnecessary if 
the Decodable APIs were more flexible or we could access keys by key path 
rather than nesting full containers. I can’t image how much code I would have 
to add to decode the nasty JSON APIs I’ve used Argo to parse before. Every type 
would need an underlying raw representation that, at the very least, would need 
custom keys, lest I pollute even those models with the terrible keys the JSON 
actually has. Not to mention the various transforms I needed. Once I hit any 
reasonably complex API, Argo is far far simpler to implement in fewer lines of 
code.
In trying to make Argo’s JSON enum Decodable itself, I can’t seem to 
find a way to access the Any representation of the raw JSON. In fact, it 
appears there’s no way to represent an Any value in Codable at all, which makes 
Codable rather useless for the scenarios like the one that prompted this 
thread. Without such an ability it’s impossible to actually use Codable with 
all of the JSON out there, where other solutions work just fine. Argo’s JSON 
type is decodable by Argo, so you can use it to represent a blob of JSON just 
fine. Other existing JSON frameworks have similar solutions. 



Jon

> On Jun 18, 2017, at 3:21 AM, Rien via swift-users  
> wrote:
> 
> Dang, hit send too soon. Sorry.
> 
> This does not address your question, so please ignore… (foot in mouth)!
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
> 
> 
> 
> 
> 
> 
> 
>> On 18 Jun 2017, at 09:19, Rien  wrote:
>> 
>> Are you looking for a general purpose JSON interpreter / API ?
>> 
>> There are many of them around, and in fact I do have my own: 
>> https://github.com/Balancingrock/VJson
>> 
>> With VJson I would write:
>> 
>> let json = VJson.parse(… your json object…)
>> 
>> and then access the metadata as:
>> 
>> let buyCount = (json | ”metadata” | ”buy_count”)?.intValue
>> 
>> or:
>> 
>> var buyCount: Int &= json | “metadata” | “buy_count”
>> 
>> To loop over the content of metadata:
>> 
>> for item in (json | “metadata”) ?? [ ] {
>>  print (item.nameValue)
>>  switch item.type {
>>  case .object: …
>>  case .number: …
>>  case .string: …
>>  etc...
>>  }
>> }
>> 
>> Obviously I am plugging my own code here, but there are many others around, 
>> I understand that SwiftyJSON is quite popular but I have not used that 
>> myself.
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 18 Jun 2017, at 04:07, Chris Anderson via swift-users 
>>>  wrote:
>>> 
>>> Say I have a JSON object such as:
>>> 
>>> {
>>>   "id": "4yq6txdpfadhbaqnwp3",
>>>   "email": "john@example.com",
>>>   "name":"John Doe",
>>>   "metadata": {
>>> "link_id": "linked-id",
>>> "buy_count": 4
>>>   }
>>> }
>>> 
>>> And with a struct of:
>>> 
>>> struct User: Codable {
>>> var id: String
>>> var email: String
>>> var name: String
>>> }
>>> 
>>> How can I decode the `metadata` field into a Dictionary?
>>> 
>>> I’ve tried doing things such as, in my struct,
>>> 
>>> var metadata: Dictionary
>>> 
>>> or
>>> 
>>> var metadata: [String: Any]
>>> 
>>> But I get the error 
>>> 
>>> MyPlayground.playground:3:7: note: cannot automatically synthesize 
>>> 'Encodable' because '<>' does not conform to 'Encodable'
>>> var metadata: Dictionary 
>>> 
>>> A meta or metadata field on many APIs (such as www.stripe.com) can contain 
>>> whatever you want, and I still want to be able to process it on the Swift 
>>> end. How can I store that meta data field into a Dictionary that I can 
>>> parse apart manually after?
>>> 
>>> Thanks!
>>> 
>>> Chris Anderson
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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] Decode a JSON object of unknown format into a Dictionary with Decodable in Swift 4

[Jon Shier via swift-users]

Your issue here is Any, which will likely never be Decodable. You’ll 
need an actual type to contain the raw JSON. Hilariously, I have to wonder if 
Argo’s JSON enum could be made Decodable, as it can represent every valid JSON 
type typically contained in the Any returned by JSONSerialization. Yet another 
reason why Swift needs a real JSON serialization.


Jon Shier

> On Jun 17, 2017, at 10:07 PM, Chris Anderson via swift-users 
>  wrote:
> 
> Say I have a JSON object such as:
> 
>   {
> "id": "4yq6txdpfadhbaqnwp3",
> "email": "john@example.com ",
> "name":"John Doe",
> "metadata": {
>   "link_id": "linked-id",
>   "buy_count": 4
> }
>   }
> 
> And with a struct of:
> 
> struct User: Codable {
>   var id: String
>   var email: String
>   var name: String
> }
> 
> How can I decode the `metadata` field into a Dictionary?
> 
> I’ve tried doing things such as, in my struct,
> 
> var metadata: Dictionary
> 
> or
> 
> var metadata: [String: Any]
> 
> But I get the error 
> 
> MyPlayground.playground:3:7: note: cannot automatically synthesize 
> 'Encodable' because '<>' does not conform to 'Encodable'
>   var metadata: Dictionary 
> 
> A meta or metadata field on many APIs (such as www.stripe.com 
> ) can contain whatever you want, and I still want to 
> be able to process it on the Swift end. How can I store that meta data field 
> into a Dictionary that I can parse apart manually after?
> 
> Thanks!
> 
> Chris Anderson
> 
>   
> 
> 
> 
> ___
> 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] Linux equivalent of macOS/iOS run loop, aka libdispatch/Dispatch on Linux

[Jon Shier via swift-users]

Dispatch equivalent should be dispatchMain(), unless that’s not available on 
Linux for some reason.



Jon

> On Apr 5, 2017, at 4:28 PM, Rick Mann via swift-users  
> wrote:
> 
> I've got Swift and libdispatch installed and linking under Ubuntu 16.04, but 
> I'm not sure how to set up the Linux equivalent of the macOS run loop in 
> order to service all the dispatch queues.
> 
> I'm having a hard time finding an example of how to do this. Some GCD C code 
> calls dispatch_main() from the main thread after initial program setup. I 
> couldn't find an equivalent in the Dispatch package, when looking through the 
> sources.
> 
> Can anyone tell me how to do this, or point me at an example?
> 
> 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] Swift 3.1 String(

[Jon Shier via swift-users]

This was something that sounded like a good change but is extremely 
annoying in use. Once I get time I’m going to try writing an extension on 
Optional that generates a logDescription property so I don’t have to use that 
awful String(describing:) API.



Jon Shier


> On Apr 5, 2017, at 10:35 AM, Shawn Erickson via swift-users 
>  wrote:
> 
> Avoid using optionals in string interpolation or make it explicit as the 
> fix-it suggests.
> 
> On Wed, Apr 5, 2017 at 7:27 AM Maxim Veksler via swift-users 
> > wrote:
> Hi,
> 
> Swift 3.1 compiler seems to introduces a new complier warning regarding 
> String(describing: )
> 
> So this line:
> Log.info("Update name for user \(fbUser)")
> 
> Produces the warning: "note: use 'String(describing:)' to silence this 
> warning"
> 
> and becomes this line
> Log.info("Update name for user \(String(describing: fbUser))")
> 
> This new syntax is not very sexy, especially for logging. Any suggestions, 
> possibility on the API end of Log to make this warning go away? or write it 
> differently.
> ___
> 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] Improving compilation times?

[Jon Shier via swift-users]

That setting breaks incremental compilation, so you're getting clean build 
speed at the expense of incremental builds. 



Jon

> On Mar 28, 2017, at 7:35 AM, Bartłomiej Nowak via swift-users 
>  wrote:
> 
> I’ve had the same issue and adding a user-defined setting 
> `SWIFT_WHOLE_MODULE_OPTIMIZATION = YES` seemed to fix this. Down from 12 
> minutes to 2.5 after clean -> build.
> 
> The question is why do we have to set such flags in Xcode ourselves, when it 
> most probably should be the default setting?
> 
> 
>>> Wiadomość napisana przez Mark Lacey via swift-users  
>>> w dniu 23.03.2017, o godz. 18:06:
>>> 
>>> 
>>> On Mar 23, 2017, at 10:02 AM, piotr gorzelany  
>>> wrote:
>>> 
>>> I tried using it with the latest Xcode release (version 8.2).
>> 
>> That was released prior to the addition of the new option. Recent snapshot 
>> builds from https://swift.org/download/#snapshots as well as the more recent 
>> Xcode 8.3 betas have it.
>> 
>> Mark
>> 
>>> W dniu czw., 23.03.2017 o 17:57 Mark Lacey  
>>> napisał(a):
> On Mar 23, 2017, at 1:58 AM, piotr gorzelany  
> wrote:
> 
> Hi Mark,
> 
> Thanks for the answer, its great to know that somebody is working on it!
> 
> I tried to add the -Xfrontend -debug-time-expression-type-checking in 
> Xcode in the Other Swift Flags section but that gives me an error when 
> compiling 
> 
> :0: error: unknown argument: 
> '-debug-time-expression-type-checking'
> 
> Should I rather compile it on the command line using this option?
 
 I added this to the compiler within the last couple months so you need to 
 be using a recent build in order to use this command-line option. Where 
 did the compiler that you tried it with come from?
 
 Mark
 
> 
> Regards,
> Piotr
> 
> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users 
>  napisał:
> 
> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users 
> >  wrote:
> >
> >
> >> On 23 Mar 2017, at 08:27, David Hart  wrote:
> >>
> >> Yes, it's best to avoid concatenating strings with +. Not only for 
> >> performance reasons, but it's also less readable than string 
> >> interpolation:
> >>
> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? 
> >> "?")\n”
> >
> > Concatenation may cause the increase, but this solved it too:
> >
> >let (clientIpOrNil, serviceOrNil) = 
> > sockaddrDescription(info.pointee.ai_addr)
> >let clientIp = clientIpOrNil ?? "?"
> >let service = serviceOrNil ?? "?"
> >str += "No: \(count), HostIp: " + clientIp + " at port: " + 
> > service + "\n”
> 
> To make a long story short, expressions combining the results of 
> nil-coalescing with other operators tend to be very slow to type check at 
> the moment. I’m working on fixing this (really the more general issue as 
> it is not specific to ?? but I’ve seen several bug reports that involve 
> that operator).
> 
> I added another command-line option to help track issues like this down 
> (at the expression level, rather than function level):
>   -Xfrontend -debug-time-expression-type-checking
> 
> If you use that you’ll see a line for every expression that is 
> type-checked, with source location information, and the time to type 
> check the expression. In some cases we may not have valid source 
> information (I believe this generally happens for things the compiler 
> synthesizes rather than user code), and you’ll see ‘’ rather 
> than the file/line/column info.
> 
> Mark
> 
> 
> >
> > Regards,
> > Rien.
> >
> >
> >>
> >> On 23 Mar 2017, at 08:11, Rien via swift-users  
> >> wrote:
> >>
> >>> Thanks for that link, used it to track down the worst compile time 
> >>> offender:
> >>>
> >>> This piece of code:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
> >>> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) = 
> >>> sockaddrDescription(info.pointee.ai_addr)
> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at 
> >>> port: " + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Took 38 seconds to compile.
> >>>
> >>> Removing 

Re: [swift-users] Improving compilation times?

[Jon Shier via swift-users]

It’s a rather severe regression from Objective-C, where equivalent 
amounts of code could be compiled in 2 - 3 minutes. I think we all understand 
why swiftc is so much slower than clang, but it’s concerning that, with all of 
the talk of new features or changes for Swift 4, there’s no comment on the 
degree of effort being put into improving build times or diagnostics. I’m 
pretty sure the answer is “ongoing” but given that performance and diagnostics 
both seemed to regress from Swift 2 - 3, some in the community are concerned 
about ongoing progress and priority. Personally, I’d much rather have better 
performance, stability, and diagnostics over enhancements to the Dictionary 
API, but that’s just personal opinion.
Does Swift, in any area, have any guiding performance, stability, or 
diagnostic principles? In the early days of WebKit, and I believe still to this 
day, they had a guiding principle of no performance regressions, even for 
increased correctness. Performance losses for correctness or new features had 
to be offset by performance gains elsewhere. AFAIK, Swift has no such official 
policy. I think the community would appreciate such a commitment. I would, at 
least.



Jon Shier


> On Mar 22, 2017, at 5:59 PM, Jan Neumüller via swift-users 
>  wrote:
> 
> I may be old - But what is abnormal at 10mins compilation time? Looks 
> perfectly fine to me - I still remember hours of compilation…
> 
> Jan
> 
>> On 22 Mar 2017, at 21:03, piotr gorzelany via swift-users 
>>  wrote:
>> 
>> Hi, I hope I reached the right mailing list to ask a question about tooling.
>> 
>> Can somebody from the compiler or Xcode team share some tips on how to 
>> improve compilation times of larger Swift projects?
>> 
>> I am an iOS developer and the largest issue my team has with Swift so far is 
>> that when the project gets semi large (~30 000 lines) the compilation times 
>> start to be high (~10 minutes from clean). This is a MAJOR downside since 
>> iOS development oftentimes requires rapid changes to UI or logic. Every 
>> person of my team compiles a project at least 10 times a day to test new 
>> features or functionalities. When compilation times start to be higher than 
>> 10 minutes that gets us to ~1.5h a day of developer time spend just on 
>> compiling. Not to mention the focus lost when this is happening.
>> 
>> I know the Swift Evolution list is buzzing with new ideas and features but 
>> from my experience the compilation times is a CRITICAL thing to improve in 
>> the next Swift release since it cost real money to waste all those developer 
>> hours. Just think of all the hours lost on compiling across all Swift devs 
>> worldwide and you will get to probably dozens of thousand of dev hours a day.
>> 
>> Is the core compiler team going to address compilation performance in the 
>> next release?
>> 
>> Maybe there is an existing solution to long compilation times that we don't 
>> know of? It would be great if anybody could share.
>> I was thinking maybe of dividing the app into multiple frameworks since I 
>> think frameworks are compiled only once only on change?
>> 
>> Regards,
>> Piotr
>> ___
>> 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-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Jon Shier via swift-users]

Sorry, didn’t see the other threads about this. Sooner is better but I’m glad 
to know it’s at least planned.



Jon

> On Mar 20, 2017, at 12:39 PM, Jon Shier  wrote:
> 
>   So when is this transition happening? The sooner the better, as Mail 
> can’t really handle threads with large messages, like the recent evolution 
> threads about Foundation serialization and decoding. It just stops rendering 
> messages. Discourse would help a lot for these sorts of discussions.
> 
> 
> 
> Jon
> 
>> On Feb 22, 2017, at 3:18 PM, Gavin Eadie via swift-evolution 
>> > wrote:
>> 
>> I've been participating on email lists and forums for forty-ish years and 
>> this dichotomy has been an ever present cloud hanging over that activity, 
>> sometimes, sadly, to the extent that the list-v-forum debate has swamped the 
>> desired topic of conversation .. I've seen it reach language-war proportions.
>> 
>> I'll express my ignorance before I go further .. I have not tracked the 
>> progress of recent (typically web-based) computer aided communications 
>> products so don't bite my head off .. what follows is a position I've held 
>> for a long time, a plea for a product that may well exist now.
>> 
>> I'm a big 'delayed binding' fan which, in this context, could mean 
>> separating the storage of the content from the display of the content.  
>> Surely there are stores that can be accessed by IMAP (for those that want 
>> the 'mailing list' experience and the Eudora interface), and by other 
>> methods SQL, REST, JSON (for those who want a more expressive web-app 
>> experience)?
>> 
>> This would seem to be in the same spirit of Markdown .. expressive when 
>> rendered, but quite readable in its raw form.
>> 
>> I'm sure you get the idea .. doesn't any such thing exist?
>> 
>> 
>> On Sun, Feb 19, 2017 at 4:41 PM, Lane Schwartz via swift-users 
>> > wrote:
>> 
>> Is there a plan to enable an integrated mailing list functionality so that 
>> those of us who prefer that modality can continue to participate via email? 
>> Other forum software that I've been asked to use in the past (sorry, I can't 
>> remember the name) had this functionality, and it made a huge difference for 
>> me.
>> 
>> 
>> On Wed, Feb 8, 2017 at 6:03 PM, Ted kremenek via swift-users 
>> > wrote:
>> 
>> [...] Specifically, there are those who really value using email for 
>> participation on swift-evolution and swift-users, and the goal is to get the 
>> forum setup to allow those people to continue to feel effective when using 
>> email for discussions on these "lists".
>> ___
>> swift-evolution mailing list
>> swift-evolut...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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

Re: [swift-users] [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Jon Shier via swift-users]

So when is this transition happening? The sooner the better, as Mail 
can’t really handle threads with large messages, like the recent evolution 
threads about Foundation serialization and decoding. It just stops rendering 
messages. Discourse would help a lot for these sorts of discussions.



Jon

> On Feb 22, 2017, at 3:18 PM, Gavin Eadie via swift-evolution 
>  wrote:
> 
> I've been participating on email lists and forums for forty-ish years and 
> this dichotomy has been an ever present cloud hanging over that activity, 
> sometimes, sadly, to the extent that the list-v-forum debate has swamped the 
> desired topic of conversation .. I've seen it reach language-war proportions.
> 
> I'll express my ignorance before I go further .. I have not tracked the 
> progress of recent (typically web-based) computer aided communications 
> products so don't bite my head off .. what follows is a position I've held 
> for a long time, a plea for a product that may well exist now.
> 
> I'm a big 'delayed binding' fan which, in this context, could mean separating 
> the storage of the content from the display of the content.  Surely there are 
> stores that can be accessed by IMAP (for those that want the 'mailing list' 
> experience and the Eudora interface), and by other methods SQL, REST, JSON 
> (for those who want a more expressive web-app experience)?
> 
> This would seem to be in the same spirit of Markdown .. expressive when 
> rendered, but quite readable in its raw form.
> 
> I'm sure you get the idea .. doesn't any such thing exist?
> 
> 
> On Sun, Feb 19, 2017 at 4:41 PM, Lane Schwartz via swift-users 
> > wrote:
> 
> Is there a plan to enable an integrated mailing list functionality so that 
> those of us who prefer that modality can continue to participate via email? 
> Other forum software that I've been asked to use in the past (sorry, I can't 
> remember the name) had this functionality, and it made a huge difference for 
> me.
> 
> 
> On Wed, Feb 8, 2017 at 6:03 PM, Ted kremenek via swift-users 
> > wrote:
> 
> [...] Specifically, there are those who really value using email for 
> participation on swift-evolution and swift-users, and the goal is to get the 
> forum setup to allow those people to continue to feel effective when using 
> email for discussions on these "lists".
> ___
> swift-evolution mailing list
> swift-evolut...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-users] Confusing Error localizedDescription output

[Jon Shier via swift-users]

Guh, second version should be this (Discourse save me).

enum MyError: Error {

case network
case json
case value

var localizedDescription: String {
switch self {
case .network: return "first"
case .json: return "second"
case .value: return "third"
}
}

}

extension MyError: LocalizedError { }

print((MyError.value as Error).localizedDescription)


> On Feb 28, 2017, at 4:36 PM, Jon Shier <j...@jonshier.com> wrote:
> 
> Something strange I just observed. This version of MyError properly prints 
> its localized description (in a Playground). 
> 
> enum MyError: Error {
> 
> case network
> case json
> case value
> 
> var localizedDescription: String {
> switch self {
> case .network: return "first"
> case .json: return "second"
> case .value: return "third"
> }
> }
> 
> var errorDescription: String? { return localizedDescription }
> 
> }
> 
> extension MyError: LocalizedError { }
> 
> print((MyError.value as Error).localizedDescription): third
> 
> However, this version does not:
> 
> enum MyError: Error {
> 
> case network
> case json
> case value
> 
> var localizedDescription: String {
> switch self {
> case .network: return "first"
> case .json: return "second"
> case .value: return "third"
> }
> }
> 
> var errorDescription: String? { return localizedDescription }
> 
> }
> 
> extension MyError: LocalizedError { }
> 
> print((MyError.value as Error).localizedDescription): The operation couldn’t 
> be completed. (__lldb_expr_103.MyError error 2.)
> 
> Surely that’s a bug?
> 
> 
> 
> Jon
> 
>> On Feb 28, 2017, at 4:32 PM, Jon Shier <j...@jonshier.com 
>> <mailto:j...@jonshier.com>> wrote:
>> 
>> Sorry, I forgot that part; MyError does conform to LocalizedError. However, 
>> even if it didn’t, Error has a localizedDescription property, so my question 
>> was why my implementation of that property wasn’t used in favor of the 
>> generated one. Or is that not the case for properties that aren’t required 
>> by the protocol? Even with the conformance, treating MyError as Error or 
>> LocalizedError doesn’t return the correct value for the property. 
>> localizedDescription seems to work fine when talking to Error instances 
>> backed by NSError though. This behavior doesn’t seem to be correct, 
>> otherwise there’s no way to get a useful description out of a custom Error 
>> without also implementing LocalizedError and treating the value as that type 
>> instead.
>> 
>> 
>> 
>> Jon
>> 
>> 
>>> On Feb 28, 2017, at 4:10 PM, Jordan Rose <jordan_r...@apple.com 
>>> <mailto:jordan_r...@apple.com>> wrote:
>>> 
>>> '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 
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md>.
>>> 
>>> Hope this helps,
>>> Jordan
>>> 
>>> 
>>>> On Feb 28, 2017, at 12:54, Jon Shier via swift-users 
>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> 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
>>>>}
>>>>}
>>>> 
>>>> }
>>>> 
>>>> 

Re: [swift-users] Confusing Error localizedDescription output

[Jon Shier via swift-users]

Something strange I just observed. This version of MyError properly prints its 
localized description (in a Playground). 

enum MyError: Error {

case network
case json
case value

var localizedDescription: String {
switch self {
case .network: return "first"
case .json: return "second"
case .value: return "third"
}
}

var errorDescription: String? { return localizedDescription }

}

extension MyError: LocalizedError { }

print((MyError.value as Error).localizedDescription): third

However, this version does not:

enum MyError: Error {

case network
case json
case value

var localizedDescription: String {
switch self {
case .network: return "first"
case .json: return "second"
case .value: return "third"
}
}

var errorDescription: String? { return localizedDescription }

}

extension MyError: LocalizedError { }

print((MyError.value as Error).localizedDescription): The operation couldn’t be 
completed. (__lldb_expr_103.MyError error 2.)

Surely that’s a bug?



Jon

> On Feb 28, 2017, at 4:32 PM, Jon Shier <j...@jonshier.com> wrote:
> 
> Sorry, I forgot that part; MyError does conform to LocalizedError. However, 
> even if it didn’t, Error has a localizedDescription property, so my question 
> was why my implementation of that property wasn’t used in favor of the 
> generated one. Or is that not the case for properties that aren’t required by 
> the protocol? Even with the conformance, treating MyError as Error or 
> LocalizedError doesn’t return the correct value for the property. 
> localizedDescription seems to work fine when talking to Error instances 
> backed by NSError though. This behavior doesn’t seem to be correct, otherwise 
> there’s no way to get a useful description out of a custom Error without also 
> implementing LocalizedError and treating the value as that type instead.
> 
> 
> 
> Jon
> 
> 
>> On Feb 28, 2017, at 4:10 PM, Jordan Rose <jordan_r...@apple.com 
>> <mailto:jordan_r...@apple.com>> wrote:
>> 
>> '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 
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md>.
>> 
>> Hope this helps,
>> Jordan
>> 
>> 
>>> On Feb 28, 2017, at 12:54, Jon Shier via swift-users <swift-users@swift.org 
>>> <mailto:swift-users@swift.org>> 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 <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] Confusing Error localizedDescription output

[Jon Shier via swift-users]

Sorry, I forgot that part; MyError does conform to LocalizedError. However, 
even if it didn’t, Error has a localizedDescription property, so my question 
was why my implementation of that property wasn’t used in favor of the 
generated one. Or is that not the case for properties that aren’t required by 
the protocol? Even with the conformance, treating MyError as Error or 
LocalizedError doesn’t return the correct value for the property. 
localizedDescription seems to work fine when talking to Error instances backed 
by NSError though. This behavior doesn’t seem to be correct, otherwise there’s 
no way to get a useful description out of a custom Error without also 
implementing LocalizedError and treating the value as that type instead.



Jon


> On Feb 28, 2017, at 4:10 PM, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> '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 
> <https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md>.
> 
> Hope this helps,
> Jordan
> 
> 
>> On Feb 28, 2017, at 12:54, Jon Shier via swift-users <swift-users@swift.org 
>> <mailto:swift-users@swift.org>> 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 <mailto: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] Confusing Error localizedDescription output

[Jon Shier via swift-users]

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

Re: [swift-users] The case of broken polymorphism or "Cannot convert value of type to expected argument type"?

[Jon Shier via swift-users]

Also possibly related is the covariance in protocol requirements. The following 
example doesn’t compile without casting the arrays or single values to the 
exact types required in the protocols, despite being covariant through protocol 
conformance or subclass.

protocol HasViews {

var views: [UIView]!

}

protocol Updateable { }

extension UIView: Updateable { }

protocol HasProtocols {

var updateables: [Updateable]!

}

class ViewController: UIViewController {

@IBOutlet var views: [UIButton]!
@IBOutlet var updateables: [UIButton]!

}

extension ViewController: HasViews { } // fails without casting
extension ViewController: HasProtocols { } // fails without casting



Jon


> On Feb 20, 2017, at 7:07 PM, Howard Lovatt via swift-users 
>  wrote:
> 
> It is confusing in Swift what can be covariant and what is invariant, 
> consider:
> 
> // Covarant arrays work
> class A {}
> class B: A {}
> let a = A() // A
> let b = B() // B
> var arrayA = [a] // Array
> arrayA[0] = b // OK
> 
> // And arrays of arrays
> var arrayArrayA = [arrayA] // Array
> arrayArrayA[0][0] = b // OK
> let arrayB = [b] // Array
> arrayArrayA[0] = arrayB // OK, works out that an Array is a Array
> 
> // Covariant homebrew-collections work
> class C { 
> var e: T
> init(_ e: T) { self.e = e }
> }
> var cA = C(a) // C
> cA.e = b // OK
> 
> // But not quite for homebrew-collections of homebrew-collections
> var cCA = C(cA) // C
> cCA.e.e = b // OK
> let cB = C(b) // C
> // cCA.e = cB // Error - cannot work out that a C is a C but can do 
> so for arrays
> 
> It is weird that the last line fails and the equivalent Array line doesn't. I 
> suspect that there is some special typing going on for arrays, probably to 
> make them play nice with Objective-C. However it would be simpler if 
> everything was covariant when safe to be covariant, i.e. The last line should 
> work.
> 
>  -- Howard.
> 
> On Mon, 20 Feb 2017 at 8:38 pm, Isaac Rivera via swift-users 
> > wrote:
> I can see it is a (counter-intuitive) language design decision for type 
> safety… but then why, in the code below I can:
> 
> class OtherThing: Something {
>   override func start(_ completion: SomeCallback? = nil) {
>   // implementation details...
>   }
> }
> 
> let firstThing = OtherThing(viewController: UINavigationController())
> 
> OtherThing extends Something… but I can instantiate it with 
> the subtype…
> 
> Ok you will say, UINavigationController is a subtype of UIViewController, but 
> that still does not make Something a subtype of 
> Something. 
> 
> Fair enough, but:
> 
> let c1: Something = Something(viewController: 
> UINavigationController())
> // c1 is of type "Something"
> 
> let c2 = Something(viewController: UINavigationController())
> // c1 is of type "Something”
> 
> So it appears Something can be cast to type 
> Something…
> 
> Yet this is illegal?
> 
> let somethings: [Something] = [c1, c2]
> 
> I dont know, something seems inconsistent.
> 
> 
>> On Feb 16, 2017, at 10:59 PM, Slava Pestov > > wrote:
>> 
>> Hi Isaac,
>> 
>> This is not about associated types. Rather, the issue is that a ‘Thing’ is a 
>> ‘Something’, but you are casting it to 
>> ‘Something’. The two types are not related; in general, if 
>> A is a subtype of B, then G is not a subtype of G.
>> 
>> https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
>>  
>> 
>> 
>> Slava
>> 
>>> On Feb 16, 2017, at 9:05 AM, Isaac Rivera via swift-users 
>>> > wrote:
>>> 
>>> Hello, list!
>>> 
>>> I am trying to find my way around Swift’s protocol limitations. It appears 
>>> that in general, any protocol with declared associatedtype will break 
>>> polymorphism?
>>> 
>>> Take the case below which does not compile. All "Thing” instances are 
>>> "Something” but they can’t be passed around or 
>>> coerced as so.
>>> 
>>> How is it that I can legally write the code:
>>> 
>>> class Thing: Something { }
>>> 
>>> and instantiate it, but it is not the very thing it implements? 
>>> 
>>> All Thing instances conform to the public interfaces of 
>>> Something so why can’t they be recognized as such and 
>>> coerced as such?
>>> 
>>> What is the work-around of this break in Polymorphism?
>>> 
>>> import UIKit
>>> 
>>> protocol Anything: class, NSObjectProtocol {
>>> 
>>> associatedtype ViewControllerType: UIViewController
>>> 
>>> var viewController: ViewControllerType { get }
>>> 
>>> init(viewController: ViewControllerType)
>>> 
>>> func addAnything(anything: Something) -> Bool
>>> }
>>> 
>>> class Something: NSObject, 

Re: [swift-users] ambiguous minus operator

[Jon Shier via swift-users]

I’ve had good luck with being able to click the candidates in cases 
like this so Xcode will navigate to those bits of code. However, in this case I 
think the issue is that the candidates weren’t from user code but from the 
standard library, which Xcode has all sorts of issues navigating within, 
seemingly at random.
As an aside, it would be really cool if, instead of seeing the standard 
library as a compiled module, Xcode could navigate to the relevant source code 
(perhaps optionally). Otherwise I’m stuck either looking at documentation 
(Apple’s docs or swiftdocs) and if that doesn’t help, trying to navigate to the 
relevant code in GitHub. This is especially true for things like finding out 
what the default values defined for functions are, as the documentation just 
shows default, which is useless.


Jon

> On Feb 16, 2017, at 1:16 PM, Jordan Rose via swift-users 
>  wrote:
> 
>> 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

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

Re: [swift-users] Rational behind having 2 different behaviors for flatMap?

[Jon Shier via swift-users]

According to the compiler, the closure argument for flatMap is not optional or 
defaulted, so it’s always required. I think it should default to { $0 }, but 
whatever.


Jon

> On Feb 13, 2017, at 8:26 PM, Saagar Jha via swift-users 
>  wrote:
> 
> flatMap was designed to work this way. How I rationalize it is that flatMap 
> “extracts” the value from an array’s elements and expands it. For an Array, 
> this is just taking out the individual Elements, but for an Optional, which a 
> “wrapper” around one value, it just takes this value out. Optionals with no 
> value (the .none case, or nil as it’s more commonly known) have nothing to 
> contribute and thus are filtered out.
> 
> Saagar Jha
> 
> P.S. You can call flatMap without a closure: deep.flatMap().flatMap()
> 
>> On Feb 13, 2017, at 4:31 PM, Maxim Veksler via swift-users 
>> > wrote:
>> 
>> Hi everyone,
>> 
>> I've discovered today that Swift will actually choose 2 very differently 
>> behaving types of flatMap implementation based on the input signature. 
>> 
>> For a Sequence of options it will call a flatMap that filters out nil's. For 
>> a Sequence of Sequence's it will call a flattening function, without 
>> filtering.
>> 
>> Leading to code that (IMHO) reads very not inconsistency, and unexpected. 
>> Sometime even looking a bit funny such as collection.flatMap.flatMap:
>> 
>>   5> let deep = [["1989", nil], [nil, "Red"], [nil, nil]]
>> deep: [[String?]] = 3 values {
>>   [0] = 2 values {
>> [0] = "1989"
>> [1] = nil
>>   }
>>   [1] = 2 values {
>> [0] = nil
>> [1] = "Red"
>>   }
>>   [2] = 2 values {
>> [0] = nil
>> [1] = nil
>>   }
>> }
>>   6> deep.flatMap { $0 }
>> $R1: [String?] = 6 values {
>>   [0] = "1989"
>>   [1] = nil
>>   [2] = nil
>>   [3] = "Red"
>>   [4] = nil
>>   [5] = nil
>> }
>>   7> deep.flatMap { $0 }.flatMap { $0 }
>> $R2: [String] = 2 values {
>>   [0] = "1989"
>>   [1] = "Red"
>> }
>> I wonder why it was implemented this way?
>> 
>> 
>> ___
>> 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] Crash with swift_weakLoadStrong in the stack

[Jon Shier via swift-users]

These crashes are uploaded from device, namely an iPad 4 (running the app in 
compatibility mode) uploaded through Crashlytics and then downloaded from 
there. I haven’t been able to reproduce the crash and so I haven’t seen a raw 
dump. Here’s the full crash stack, redacted, from an iPad 4 running iOS 10.1.1 
(this is an iOS 10+ app).

#0. Crashed: com.apple.main-thread
0  App  0x665ac 
Controller.handleSomeNotification(SomeNotification) -> () (Controller.swift:92)
1  libswiftCore.dylib   0x131854f swift_unknownWeakLoadStrong + 
10
2  App  0x65cfc 
Controller.handleFinishSomeNotification(Notification) -> () (Controller.swift)
3  App  0x65dd8 @objc 
Controller.handleSomeOtherNotification(Notification) -> () + 437720
4  CoreFoundation   0x1bafa761 
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 10
5  CoreFoundation   0x1bafa09d _CFXRegistrationPost + 386
6  CoreFoundation   0x1baf9e81 
___CFXNotificationPost_block_invoke + 40
7  CoreFoundation   0x1bb5581d -[_CFXNotificationRegistrar 
find:object:observer:enumerator:] + 1188
8  CoreFoundation   0x1ba5a09d _CFXNotificationPost + 540
9  App  0x15b004 specialized specialized 
NotificationCenter.post (A, forName : NSNotification.Name) -> () 
(Notifications.swift)
10 App  0x8d6f4 
SomeListener.(post(SomeNotification : SomeNotification) -> ()).(closure #1) 
(SomeNotificationHandler.swift)
11 App  0x96318 partial apply for 
SomeListener.(post(SomeNotification : SomeNotification) -> ()).(closure #1) 
(SomeNotificationHandler.swift)
12 libdispatch.dylib0x1b1f5097 
_dispatch_call_block_and_release + 10
13 libdispatch.dylib0x1b1f5083 _dispatch_client_callout + 22
14 libdispatch.dylib0x1b1f95fd 
_dispatch_main_queue_callback_4CF + 890
15 CoreFoundation   0x1bb0aa17 
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
16 CoreFoundation   0x1bb08cff __CFRunLoopRun + 1422
17 CoreFoundation   0x1ba58073 CFRunLoopRunSpecific + 486
18 CoreFoundation   0x1ba57e81 CFRunLoopRunInMode + 104
19 GraphicsServices 0x1d204bfd GSEventRunModal + 156
20 UIKit0x20c0c82f -[UIApplication 
_run] + 574
21 UIKit0x20c06f61 UIApplicationMain + 
150
22 App  0x4bc38 main (AppDelegate.swift:12)
23 libdispatch.dylib0x1b22250b (Missing)

Essentially I have a listener waiting on a background queue for a push 
notification to come in, which then repackages the payload into a Notification 
using a generic convenience method I wrote, and posted onto the main queue. 
Controller is listening for this two separate notifications, one of which is 
the SomeNotification. But the @objc method in there is the selector for the 
other notification, SomeOther. There should be no path between 3 and 2 in the 
stack, and there are no weak references I can see, except perhaps the implicit 
ones from NotificationCenter. Badly resymbolicated log? Is that even possible?


Jon

> On Feb 13, 2017, at 6:52 PM, Greg Parker <gpar...@apple.com> wrote:
> 
>> 
>> On Feb 13, 2017, at 12:18 PM, Jon Shier via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> Swift Users:
>>  I’m currently seeing a crash in my iOS app that has no apparent cause, 
>> but a bit of Swift runtime machinery in the stack has me confused.
>> 
>> #0. Crashed: com.apple.main-thread
>> 0  App0x665ac 
>> Controller.handleOtherNotification(Notification) -> () (Controller.swift:92)
>> 1  libswiftCore.dylib 0x131854f swift_unknownWeakLoadStrong + 10
>> 2  App0x65cfc Controller.handleFinish(Notification) 
>> -> () (Controller.swift)
>> 3  App0x65dd8 @objc 
>> Controller.handleNotification(Notification) -> () + 437720
>> 
>> Controller.swift: 92 is a call to a custom UIView subclass method that takes 
>> an optional date contained extracted from the notification. Any idea what 
>> the core callout would be due to? There are no weak or unknown values being 
>> used here. Once the notification observers are called it’s all internal to 
>> Controller.
>> 
>> One thing I just noticed is that the line at 3 is the selector for a 
>> different notification, which should lead down the path see from 2 onward. 
>> It’s redacted and so not easy to s

Re: [swift-users] Debugger woes

[Jon Shier via swift-users]

This is pretty normal debugger behavior for me. Issues with printing 
variables clearly in scope, using types or operators from other modules, and 
poor performance happen every time I try to debug Swift under Xcode. I’ve never 
found anything that works reliably. 


Jon

> On Jan 31, 2017, at 1:54 PM, Maury Markowitz via swift-users 
>  wrote:
> 
> I hope this is the right place to ask this:
> 
> I'm using Xcode Version 8.2.1 (8C1002) and I'm trying to find out what's 
> going wrong in my Swift3 app. Here's the code:
> 
>   let background = sceneView.snapshot().cgImage!
>   let cropped = background.cropping(to: overlayView.frame)
>   UIGraphicsBeginImageContextWithOptions(overlayView.frame.size, 
> false, 1.0)
> 
> I have a breakpoint on the first line. When it trips I F6 to the next line 
> and examine background:
> 
> (lldb) p background
> (CGImage) $R0 = 0x0001741d4370 {}
> Printing description of background:
> 
>   < (kCGColorSpaceICCBased; 
> kCGColorSpaceModelRGB; sRGB IEC61966-2.1)>
>   width = 640, height = 998, bpc = 8, bpp = 32, row bytes = 2560 
> 
> Now I hit F6 again and do the same thing:
> 
> (lldb) p background
> error: :3:1: error: use of unresolved identifier 'background'
> background
> ^~
> 
> This happens to pretty much every variable in the app, after running another 
> line or two, it apparently disappears. This is particularly annoying in this 
> case, because QuickLook fails almost every time, which makes debugging image 
> work somewhat difficult.
> 
> I've cleaned and rebooted and it keeps coming back. Any suggestions?
> ___
> 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] Documentation for Linux Development

[Jon Shier via swift-users]

http://swiftdoc.org  is a good online reference, though 
not always completely up to date (just mostly).


Jon

> On Dec 18, 2016, at 9:44 PM, Steven Harms via swift-users 
>  wrote:
> 
> Hi,
> 
> I've been playing with Swift in Linux contexts, but I was wondering, how is 
> one meant to consult reference work?
> 
> The Swift language book is written in iBooks...so I don't have access to that 
> in Linux. I'd love for there to be a PDF equivalent that I could leave on the 
> Linux environment to work with.
> 
> Alternatively, is there a rich HTML download of the API? I'm used to Perl and 
> Ruby which shipped rich HTML pages that allowed you to research the API sans 
> network connection. 
> 
> I hate to think an IDE is required to use a language e.g. XCode. Surely we 
> should be able to code without an IDE's completion. I may be tempting the 
> nursing home by thinking vim and good docs should cut it :blush:.
> 
> Thanks,
> 
> Steven
> 
> 
> 
> 
> ___
> 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] Bool to Int

[Jon Shier via swift-users]

Except in that case true isn’t a Bool but an NSNumber, which is why you can 
initialize an Int from it. It seems trivially easy to add an Int extension to 
do what you want though.


Jon

> On Nov 20, 2016, at 10:48 PM, Rick Mann via swift-users 
>  wrote:
> 
> It seems I can't do this:
> 
> let r = Int(a > b)
> 
> but I can do it with a literal:
> 
> let r = Int(true)
> 
> I'd like to do this to implement signum without branching, but perhaps that's 
> not possible.
> 
> -- 
> 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] Reducing Array to OptionSet

[Jon Shier via swift-users]

Yes indeed! Apparently union works with the generic but insert did not. 
Strange. Anyway, I ended up here:

func reducedOptions(_ options: [T]) -> T {
return options.reduce(T()) { return $0.union($1) }
}

Thanks!

Jon

> On Nov 3, 2016, at 9:56 PM, Erica Sadun <er...@ericasadun.com> wrote:
> 
> How about
> 
> func joinOptionSets(_ sets: [OS]) -> OS {
> return sets.reduce([] as OS) {
> (result, set) in return result.union(set)
> }
> }
> 
> joinOptionSets(sets).rawValue
> 
> 
> -- E
> 
>> On Nov 3, 2016, at 7:48 PM, Erica Sadun via swift-users 
>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>> 
>> Like this?
>> 
>> let sets: [MyOptionSet] = [MyOptionSet(strings: ["one"]), 
>> MyOptionSet(strings: ["two"]), MyOptionSet(strings: ["one", "two"])]
>> let unioned = sets.reduce(MyOptionSet(rawValue: 0)) {
>> (result, set) in return result.union(set)
>> }
>> unioned.rawValue
>> 
>> 
>>> On Nov 3, 2016, at 7:44 PM, Jon Shier <j...@jonshier.com 
>>> <mailto:j...@jonshier.com>> wrote:
>>> 
>>> Thanks Erica. I’ve been able to transform arrays of strings into arrays of 
>>> my OptionSets using an enum approach like you describe. I was looking more 
>>> for a generic approach that I could apply to all of the various OptionSets 
>>> I have to decode from JSON. I suppose whether it’s from an array of strings 
>>> or array of the OptionSet is less important, but getting to the array of 
>>> the OptionSet itself is something I can already do. 
>>> 
>>> 
>>> Thanks,
>>> 
>>> Jon
>>> 
>>>> On Nov 3, 2016, at 9:37 PM, Erica Sadun <er...@ericasadun.com 
>>>> <mailto:er...@ericasadun.com>> wrote:
>>>> 
>>>> Maybe something like this? Or you could just bitwise || individual sets. 
>>>> Or you could use a dictionary to lookup [string: rawValue]. etc.
>>>> 
>>>> public struct MyOptionSet: OptionSet {
>>>> public static let one = MyOptionSet(rawValue: 1 << 0)
>>>> public static let two = MyOptionSet(rawValue: 1 << 1)
>>>> public static let three = MyOptionSet(rawValue: 1 << 2)
>>>> 
>>>> public var rawValue: Int { return _rawValue }
>>>> public init(rawValue: Int) { self._rawValue = rawValue }
>>>> private let _rawValue: Int
>>>> 
>>>>     private enum StringEnum: String { case one, two, three }
>>>> public init(strings: [String]) {
>>>> var set = MyOptionSet()
>>>> strings.flatMap({ StringEnum(rawValue: $0) })
>>>> .flatMap({ MyOptionSet(rawValue: 1 << $0.hashValue) })
>>>> .forEach { set.insert($0) }
>>>> _rawValue = set.rawValue
>>>> }
>>>> }
>>>> 
>>>> let stringArray: [String] = ["one", "three"]
>>>> let stringOptions = MyOptionSet(strings: stringArray)
>>>> stringOptions.rawValue
>>>> 
>>>>> On Nov 3, 2016, at 7:09 PM, Jon Shier via swift-users 
>>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>>> 
>>>>> Swifters:
>>>>>   I’m dealing with a JSON API where sets of options are returned as 
>>>>> arrays of strings. Representing these as OptionSets seems ideal. I can 
>>>>> decode the arrays of strings into an array of individual OptionSet 
>>>>> values, but I’ve run into a dead end when trying generically reduce the 
>>>>> array of OptionSets to a single OptionSet value. I’ve tried variety of 
>>>>> ways of definition a Collection extension, even tried defining a global 
>>>>> function, but I can’t seem to use the OptionSet sequence initializer or 
>>>>> reduce itself (cannot invoke insert with argument of type (OptionSet) (or 
>>>>> T)). Any guidance here? 
>>>>>   Here’s what I’ve tried:
>>>>> 
>>>>> extension Collection where Iterator.Element == OptionSet {
>>>>> 
>>>>>func reduced() -> Iterator.Element {
>>>>>return reduce(Iterator.Element()) {
>>>>>var newResult = $0
>>>>>newResult.insert($1)
>>>>>return newResult
>>>>>}
>>>>>   

Re: [swift-users] Reducing Array to OptionSet

[Jon Shier via swift-users]

Yes, just in a generic fashion. I don’t have so many OptionSets to 
decode that writing the typed reduce code over and over again is terrible, I 
just hoped there would be a way to write it generically. I just can’t seem to 
get the types to work out. I’m just missing the final step, generically 
reducing an array of OptionSet values to a single OptionSet value.


Jon

> On Nov 3, 2016, at 9:48 PM, Erica Sadun <er...@ericasadun.com> wrote:
> 
> Like this?
> 
> let sets: [MyOptionSet] = [MyOptionSet(strings: ["one"]), 
> MyOptionSet(strings: ["two"]), MyOptionSet(strings: ["one", "two"])]
> let unioned = sets.reduce(MyOptionSet(rawValue: 0)) {
> (result, set) in return result.union(set)
> }
> unioned.rawValue
> 
> 
>> On Nov 3, 2016, at 7:44 PM, Jon Shier <j...@jonshier.com 
>> <mailto:j...@jonshier.com>> wrote:
>> 
>> Thanks Erica. I’ve been able to transform arrays of strings into arrays of 
>> my OptionSets using an enum approach like you describe. I was looking more 
>> for a generic approach that I could apply to all of the various OptionSets I 
>> have to decode from JSON. I suppose whether it’s from an array of strings or 
>> array of the OptionSet is less important, but getting to the array of the 
>> OptionSet itself is something I can already do. 
>> 
>> 
>> Thanks,
>> 
>> Jon
>> 
>>> On Nov 3, 2016, at 9:37 PM, Erica Sadun <er...@ericasadun.com 
>>> <mailto:er...@ericasadun.com>> wrote:
>>> 
>>> Maybe something like this? Or you could just bitwise || individual sets. Or 
>>> you could use a dictionary to lookup [string: rawValue]. etc.
>>> 
>>> public struct MyOptionSet: OptionSet {
>>> public static let one = MyOptionSet(rawValue: 1 << 0)
>>> public static let two = MyOptionSet(rawValue: 1 << 1)
>>> public static let three = MyOptionSet(rawValue: 1 << 2)
>>> 
>>> public var rawValue: Int { return _rawValue }
>>> public init(rawValue: Int) { self._rawValue = rawValue }
>>> private let _rawValue: Int
>>> 
>>> private enum StringEnum: String { case one, two, three }
>>> public init(strings: [String]) {
>>> var set = MyOptionSet()
>>> strings.flatMap({ StringEnum(rawValue: $0) })
>>> .flatMap({ MyOptionSet(rawValue: 1 << $0.hashValue) })
>>> .forEach { set.insert($0) }
>>> _rawValue = set.rawValue
>>> }
>>> }
>>> 
>>> let stringArray: [String] = ["one", "three"]
>>> let stringOptions = MyOptionSet(strings: stringArray)
>>> stringOptions.rawValue
>>> 
>>>> On Nov 3, 2016, at 7:09 PM, Jon Shier via swift-users 
>>>> <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>> 
>>>> Swifters:
>>>>I’m dealing with a JSON API where sets of options are returned as 
>>>> arrays of strings. Representing these as OptionSets seems ideal. I can 
>>>> decode the arrays of strings into an array of individual OptionSet values, 
>>>> but I’ve run into a dead end when trying generically reduce the array of 
>>>> OptionSets to a single OptionSet value. I’ve tried variety of ways of 
>>>> definition a Collection extension, even tried defining a global function, 
>>>> but I can’t seem to use the OptionSet sequence initializer or reduce 
>>>> itself (cannot invoke insert with argument of type (OptionSet) (or T)). 
>>>> Any guidance here? 
>>>>Here’s what I’ve tried:
>>>> 
>>>> extension Collection where Iterator.Element == OptionSet {
>>>> 
>>>>func reduced() -> Iterator.Element {
>>>>return reduce(Iterator.Element()) {
>>>>var newResult = $0
>>>>newResult.insert($1)
>>>>return newResult
>>>>}
>>>>}
>>>> 
>>>> }
>>>> 
>>>> extension Collection where Iterator.Element == OptionSet {
>>>> 
>>>>func reduced() -> T {
>>>>return reduce(T()) {
>>>>var newResult = $0
>>>>newResult.insert($1)
>>>>return newResult
>>>>}
>>>>}
>>>> 
>>>> }
>>>> 
>>>> 
>>>> extension Collection where Iterator.Element == OptionSet {
>>>>func reduced() -> Iterator.Element {
>>>>return Iterator.Element(self)
>>>>}
>>>> }
>>>> 
>>>> func reduced(_ options: [T]) -> T {
>>>>return options.reduce(T()) {
>>>>var newResult = $0
>>>>newResult.insert($1)
>>>> 
>>>>return newResult
>>>>}
>>>> }
>>>> 
>>>> Jon Shier
>>>> ___
>>>> 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] Reducing Array to OptionSet

[Jon Shier via swift-users]

Thanks Erica. I’ve been able to transform arrays of strings into arrays of my 
OptionSets using an enum approach like you describe. I was looking more for a 
generic approach that I could apply to all of the various OptionSets I have to 
decode from JSON. I suppose whether it’s from an array of strings or array of 
the OptionSet is less important, but getting to the array of the OptionSet 
itself is something I can already do. 


Thanks,

Jon

> On Nov 3, 2016, at 9:37 PM, Erica Sadun <er...@ericasadun.com> wrote:
> 
> Maybe something like this? Or you could just bitwise || individual sets. Or 
> you could use a dictionary to lookup [string: rawValue]. etc.
> 
> public struct MyOptionSet: OptionSet {
> public static let one = MyOptionSet(rawValue: 1 << 0)
> public static let two = MyOptionSet(rawValue: 1 << 1)
> public static let three = MyOptionSet(rawValue: 1 << 2)
> 
> public var rawValue: Int { return _rawValue }
> public init(rawValue: Int) { self._rawValue = rawValue }
> private let _rawValue: Int
> 
> private enum StringEnum: String { case one, two, three }
> public init(strings: [String]) {
> var set = MyOptionSet()
> strings.flatMap({ StringEnum(rawValue: $0) })
> .flatMap({ MyOptionSet(rawValue: 1 << $0.hashValue) })
> .forEach { set.insert($0) }
> _rawValue = set.rawValue
> }
> }
> 
> let stringArray: [String] = ["one", "three"]
> let stringOptions = MyOptionSet(strings: stringArray)
> stringOptions.rawValue
> 
>> On Nov 3, 2016, at 7:09 PM, Jon Shier via swift-users <swift-users@swift.org 
>> <mailto:swift-users@swift.org>> wrote:
>> 
>> Swifters:
>>  I’m dealing with a JSON API where sets of options are returned as 
>> arrays of strings. Representing these as OptionSets seems ideal. I can 
>> decode the arrays of strings into an array of individual OptionSet values, 
>> but I’ve run into a dead end when trying generically reduce the array of 
>> OptionSets to a single OptionSet value. I’ve tried variety of ways of 
>> definition a Collection extension, even tried defining a global function, 
>> but I can’t seem to use the OptionSet sequence initializer or reduce itself 
>> (cannot invoke insert with argument of type (OptionSet) (or T)). Any 
>> guidance here? 
>>  Here’s what I’ve tried:
>> 
>> extension Collection where Iterator.Element == OptionSet {
>> 
>>func reduced() -> Iterator.Element {
>>return reduce(Iterator.Element()) {
>>var newResult = $0
>>newResult.insert($1)
>>return newResult
>>}
>>}
>> 
>> }
>> 
>> extension Collection where Iterator.Element == OptionSet {
>> 
>>func reduced() -> T {
>>return reduce(T()) {
>>var newResult = $0
>>newResult.insert($1)
>>return newResult
>>}
>>}
>> 
>> }
>> 
>> 
>> extension Collection where Iterator.Element == OptionSet {
>>func reduced() -> Iterator.Element {
>>return Iterator.Element(self)
>>}
>> }
>> 
>> func reduced(_ options: [T]) -> T {
>>return options.reduce(T()) {
>>var newResult = $0
>>newResult.insert($1)
>> 
>>return newResult
>>}
>> }
>> 
>> Jon Shier
>> ___
>> swift-users mailing list
>> swift-users@swift.org <mailto: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] Reducing Array to OptionSet

[Jon Shier via swift-users]

Swifters:
I’m dealing with a JSON API where sets of options are returned as 
arrays of strings. Representing these as OptionSets seems ideal. I can decode 
the arrays of strings into an array of individual OptionSet values, but I’ve 
run into a dead end when trying generically reduce the array of OptionSets to a 
single OptionSet value. I’ve tried variety of ways of definition a Collection 
extension, even tried defining a global function, but I can’t seem to use the 
OptionSet sequence initializer or reduce itself (cannot invoke insert with 
argument of type (OptionSet) (or T)). Any guidance here? 
Here’s what I’ve tried:

extension Collection where Iterator.Element == OptionSet {

func reduced() -> Iterator.Element {
return reduce(Iterator.Element()) {
var newResult = $0
newResult.insert($1)
return newResult
}
}

}

extension Collection where Iterator.Element == OptionSet {

func reduced() -> T {
return reduce(T()) {
var newResult = $0
newResult.insert($1)
return newResult
}
}

}


extension Collection where Iterator.Element == OptionSet {
func reduced() -> Iterator.Element {
return Iterator.Element(self)
}
}

func reduced(_ options: [T]) -> T {
return options.reduce(T()) {
var newResult = $0
newResult.insert($1)

return newResult
}
}

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

Re: [swift-users] Segmentation fault: 11 after updating codebase to Swift 3.0

[Jon Shier via swift-users]

If you haven’t tried it yet, perhaps commenting out the content of the 
Row file will prevent the crash and let the build fail with normal errors? Then 
you can comment in parts of the file and see where the crash is occurring. 
As to the overall stability of the compiler, stuff like this has always 
been part of being an Apple developer, but is certainly worse now in the Swift 
age, where it’s not just Xcode that crashes a lot.



Jon 


> On Oct 24, 2016, at 5:25 PM, Evan Maloney  wrote:
> 
> I'm a bit depressed to report that our codebase still crashes the Swift 
> compiler in the version of Xcode released today. And since we're not using 
> ObjC generics, the issue isn't related to the radar below.
> 
> Do I have any other option other than (1) spending who knows how long 
> attempting to rewrite our codebase of hundreds of files until the Swift 
> compiler hopefully doesn't crash, or (2) waiting who knows how long for 
> another version of Xcode that may still crash anyway (like this one)?
> 
> It is very frustrating that Apple is encouraging developers to adopt the 
> latest version of Swift, and when we spend considerable time and effort 
> updating, only to end up completely dead in the water after doing so. We're 
> an online retailer hoping to update our app for the holiday season, and all 
> the Swift 3 work that we've done since August is basically a waste. At this 
> point, I don't know how we ship in time, since I am familiar enough with 
> Apple's Xcode release cadence to assume that there will not be another Xcode 
> release that fixes this problem before mid-November, which is when we'd need 
> to submit our app to have it ready in time.
> 
> I should note that we've hit some variation of this problem with virtually 
> every major Xcode beta cycle since Swift 2.0, where our code crashes the 
> Swift compiler. I've always diligently filed radars, and the problems have 
> gotten fixed. (Joe, you may recall that you even helped me with this exact 
> sort of problem at WWDC this year.) But every time it happens, it's a 
> nerve-wracking experience because I just have to wait and hope that Apple 
> fixes it before our submission deadline. In the past, we've gotten lucky, and 
> Apple has fixed the problem in time.
> 
> I guess we finally got unlucky this time.
> 
> I have to say, I've dealt with many different platforms and compilers over 
> the years, from MPW to CodeWarrior, to Microsoft Visual C++, to various Java 
> IDEs, and I've never coded on a platform where the compiler crashes so 
> regularly. I'm beginning to wonder whether my enthusiasm about Swift is 
> misplaced. I was never beholden to Apple's bugfix schedule when shipping 
> Objective-C apps.
> 
> Are we just having really bad luck with the Swift compiler, or is this 
> happening to other people as well?
> 
> 
> 
>> On Oct 21, 2016, at 5:29 PM, Joe Groff > > wrote:
>> 
>> We discovered a problem recently where we would miscompile when imported 
>> ObjC lightweight generic classes are extended to conform to Swift protocols. 
>> This is being tracked by Apple as rdar://problem/28873860 
>> , for reference, and should be release noted in 
>> upcoming Xcode seeds. If you happen to be extending any ObjC generic classes 
>> to conform to Swift protocols, there are a couple of workarounds that may 
>> work:
>> 
>> - making the protocol @objc, if possible, or
>> - wrapping the ObjC class reference in a generic struct, and making that 
>> struct conform to the protocol instead of the class.
>> 
>> Does that help at all?
>> 
>> -Joe
>> 
>>> On Oct 21, 2016, at 9:44 AM, Evan Maloney via swift-users 
>>> > wrote:
>>> 
>>> This is definitely not my first time hitting Swift compiler crashes :)
>>> 
>>> In the past, the stack traces have been helpful, pointing to what code the 
>>> compiler was working on when it crashed. Unfortunately, this latest crash 
>>> doesn't fall into that category:
>>> 
>>> CompileSwift normal x86_64 
>>> /Users/emaloney/Documents/Code/CleanroomProject/AppleTart/Sources/iOS/FormBuilder/Row.swift
>>> cd /Users/emaloney/Documents/Code/CleanroomProject/AppleTart
>>> 
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift
>>>  -frontend -c -filelist 
>>> /var/folders/gn/gt76_ktx7w1010xg4v68p3txynz8ws/T/sources-a27d97 
>>> -primary-file 
>>> /Users/emaloney/Documents/Code/CleanroomProject/AppleTart/Sources/iOS/FormBuilder/Row.swift
>>>  -target x86_64-apple-ios9.0 -enable-objc-interop -sdk 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator10.0.sdk
>>>  -I 
>>> /Users/emaloney/Library/Developer/Xcode/DerivedData/AppleTart-gydtadecugkemlbxcybcwsxuynku/Build/Products/Debug-iphonesimulator
>>>  -F 
>>> 

Re: [swift-users] Segmentation fault: 11 after updating codebase to Swift 3.0

[Jon Shier via swift-users]

With Swift 3 I’ve found these crashes to be indicative of an underlying source 
issue rather than something random in the compiler. When you get the crash, can 
you get the backtrace in the Xcode build log? Sometimes that has clues about 
what it was doing when it crashed. A lot of the time when the crash is during 
the parsing or SIL generation for one of your functions, it will note it and 
you can take a look, as there may be a type mismatch. 



Jon

> On Oct 21, 2016, at 12:26 PM, Evan Maloney via swift-users 
>  wrote:
> 
> After a gargantuan effort updating our entire codebase to Swift 3.0, we are 
> now being greeted with "Segmentation fault: 11" compiler crash whenever 
> attempting to build.
> 
> The issue seems to be related to generics, and sounds similar to this issue:
> 
>   
> http://stackoverflow.com/questions/39426535/segmentation-fault-11-xcode-8-swift-3-after-using-notificationcenter/39426812
> 
> I've filed a bug report that includes our project codebase, which triggers 
> the issue 100% of the time:
> 
>   rdar://problem/28890409
> 
> The usual work-around of turning off Whole Module Optimization (which has 
> gotten around a lot of compiler crashes in the past) does not work here.
> 
> Unfortunately, this code is in such a tangle of generics that undoing it is 
> not going to be simple. Until a new version of Xcode ships, we're pretty much 
> blocked from using Swift 3.0 unless another work-around is possible.
> ___
> 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] Generic type for a generic type?

[Jon Shier via swift-users]

Swifters:
I’m running into a type inference problem when attempting to pass a 
generic type which is generic to a generic type to a function which expects a 
generic type. I’ll explain:

I have a function:
func add(observer: Observer) where 
Observer.Procedure == Procedure

Which I’m sending a parameter of type:

struct BlockObserver: ProcedureObserver

Which has been provided a type through this function:

func networkProcedureProgressViewObserver() -> BlockObserver> where U == U.DecodedType

However, calling add(observer: networkProcedureProgressViewObserver()) results 
in the error: Generic parameter ‘Observer’ could not be inferred. I’ve tried 
everything I can think of to help the inference but nothing works. Am I correct 
in thinking this is a limitation of the current generics system not being able 
to propagate the type information from NetworkProcedure to 
BlockObserver> to the function?



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

Re: [swift-users] Issues with UITableView*

[Jon Shier via swift-users]

UITableView already has the notion of “selected rows” built in, so I’d suggest 
starting there.


Jon

> On Sep 12, 2016, at 6:41 PM, Ole Begemann via swift-users 
>  wrote:
> 
> > Hmm - interesting to know.  Unfortunately, if I do that, then I get
> > NO indication of selection when I click on ANY row.  Perhaps I need
> > to make some other changes to account for the change in how I get the
> > cell?
> 
> You also need to store your cells' selection state someplace outside of the 
> cells themselves. The cells should not be the "source of truth" for the 
> selection state. Otherwise, when you scroll a cell off screen and then scroll 
> it back, it will lose its state.
> 
> So you should store the selection state of each table row somewhere alongside 
> your `locationList` array. Maybe as an array of pairs like this:
> 
>var locationList: [(location: LocationObject, selected: Bool)] = [
>(
>location: LocationObject(name: "name-1", address: "addr-1", phone: 
> "phone-1", latitude: 40.0, longitude: -80.1),
>selected: false
>),
>(
>location: LocationObject(name: "name-2", address: "addr-2", phone: 
> "phone-2", latitude: 40.0, longitude: -80.1),
>selected: false
>)
>]
> 
> There may be better ways to structure your model data, but this should 
> suffice for now.
> 
> Then:
> 
> 1. In `tableView(_:cellForRowAtIndexPath:)`, use the current value of 
> `item.selected` to configure the cell's selection state:
> 
>override func tableView(tableView: UITableView, cellForRowAtIndexPath 
> indexPath: NSIndexPath) -> UITableViewCell {
>let cell = tableView.dequeueReusableCellWithIdentifier("resultCell", 
> forIndexPath: indexPath) as! ExistingLocationTableViewCell
>let item = locationList[indexPath.row]
> 
>cell.nameLabel.text = item.location.name
>cell.locationLabel.text = item.location.address
> 
>cell.accessoryType = item.selected ? .Checkmark : .None
> 
>return cell
>}
> 
> One note: on iOS, the convention for table views is that rows should 
> generally not remain selected after the user lifts their finger. Adding the 
> checkmark should be enough to show a cell's selection state. I would only set 
> the checkmark and leave `cell.selected` as is (I left it out in the code 
> above).
> 
> 2. In `didSelectRow...`, toggle the selection state in your model data:
> 
>override func tableView(tableView: UITableView, didSelectRowAtIndexPath 
> indexPath: NSIndexPath) {
> 
>// Update model
>let row = indexPath.row
>locationList[row].selected = !locationList[row].selected
> 
> To update the UI, you now have two choices. Either ask the table view for the 
> cell at the index path and modify the cell directly:
> 
>// Either do this:
>if let cell = tableView.cellForRowAtIndexPath(indexPath) {
>cell.accessoryType = locationList[row].selected ? .Checkmark : 
> .None
>}
> 
> If you do that, I don't think you need to reload the cell explicitly. 
> Alternatively, tell the table view to reload the cell as you are doing now. 
> It will then call `tableView(_:cellForRowAtIndexPath:)` again, which in turn 
> will configure the cell with your model data:
> 
>// Or this:
>tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: .None)
> 
> Finally, fade out the cell selection:
> 
>tableView.deselectRowAtIndexPath(indexPath, animated: true)
>}
> 
> 3. If you are okay with keeping the cells deselected unless the user's finger 
> is onscreen, you don't need to implement `didDeselectRow...` at all.
> 
> (I typed this mostly without help from the compiler as I don't have a Swift 
> 2.x handy, so there may be some errors in the code above.)
> 
> Ole
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

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

[Jon Shier via swift-users]

Perhaps relatedly, it no longer seems possible to mark typealiased closures as 
@escaping. That was quite handy when you know that closures will always be used 
asynchronously.


Jon


> On Sep 7, 2016, at 6:15 PM, Shawn Erickson via swift-users 
>  wrote:
> 
> I should note that this issue also appeared in an earlier variant of Swift 
> after the addition of @escaping but I was on vacation so didn't get a chance 
> to report it then. It isn't new with the Xcode 8 GM.
> 
> On Wed, Sep 7, 2016 at 3:08 PM Shawn Erickson  > wrote:
> I like and fully supported the change to @escaping away from @noescape 
> however in a body of code that I am porting to the latest Swift 3 variant (as 
> found in Xcode 8 GM) I am hitting an issue for methods that take an optional 
> completion closure. If optional is involved I can't find a way to apply 
> @escape to the escaping closure. See the following for an basic example...
> 
> Is their a way to do what I need and/or is this an edge case in the 
> implementation of @escaping?
> 
> typealias MyCallback = (String)->()
> 
> // Happy
> func foo1(bar: String, completion: ((String)->())) {
> completion(bar)
> }
> 
> // Happy
> func foo2(bar: String, completion: MyCallback) {
> completion(bar)
> }
> 
> // Happy
> func foo3(bar: String, completion: ((String)->())? = nil) {
> completion?(bar)
> }
> 
> // Happy
> func foo4(bar: String, completion: MyCallback? = nil) {
> completion?(bar)
> }
> 
> // Happy
> func foo5(bar: String, completion: Optional = nil) {
> completion?(bar)
> }
> 
> // Happy
> func foo6(bar: String, completion: @escaping (String)->()) {
> completion(bar)
> }
> 
> // Happy
> func foo7(bar: String, completion: @escaping MyCallback) {
> completion(bar)
> }
> 
> // Unhappy...
> // "@escaping attribute only applies to function types"
> func foo8(bar: String, completion: @escaping ((String)->())? = nil) {
> completion?(bar)
> }
> 
> // Unhappy...
> // "@escaping attribute only applies to function types"
> func foo9(bar: String, completion: @escaping MyCallback? = nil) {
> completion?(bar)
> }
> 
> // Unhappy...
> // "@escaping attribute only applies to function types"
> func foo10(bar: String, completion: (@escaping ((String)->()))? = nil) {
> completion?(bar)
> }
> 
> // Unhappy...
> // "@escaping attribute only applies to function types"
> func foo11(bar: String, completion: (@escaping MyCallback)? = nil) {
> completion?(bar)
> }
> 
> // Unhappy...
> // "@escaping attribute only applies to function types"
> func foo12(bar: String, completion: Optional<@escaping MyCallback> = nil) {
> completion?(bar)
> }
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Linux Swift: Strange bug found in a simple arithmetic

[Jon Shier via swift-users]

It’s related to this: 
http://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html


Jon

> On Sep 7, 2016, at 11:32 AM, Lou Zell via swift-users  
> wrote:
> 
> Also hoping someone more knowledgeable can explain why these seemingly simple 
> cases do in fact take so long! :)
> ___
> 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] Capturing difference with typealias

[Jon Shier via swift-users]

Another general question I have is how the self requirement in general has 
changed. I’m noticing several instances where my previous @noescape closures, 
which of course had that attribute removed, are now requiring self when they 
didn’t before and aren’t marked @escaping either. So I guess my question is, 
should there ever be an instance where a closure not marked @escaping requires 
the use of self?


Jon

> On Aug 19, 2016, at 5:46 PM, Jon Shier  wrote:
> 
> Users:
>   I’m updating more code to beta 6 and have noticed a strange difference 
> when calling functions with closure parameters where that closure is declared 
> with a typealias. Take this class:
> 
> typealias Closure = () -> Void
> 
> class Thing {
>var array: [String] = []
> 
>func doClosure(closure: Closure) {
>array.append("closure")
>}
> 
>func doManualClosure(manualClosure: () -> Void) {
>array.append("manualClosure")
>}
> 
>func append() {
>doClosure {
>doClosure {
> 
>}
>}
>}
> 
>func appendManual() {
>doManualClosure {
>doManualClosure {
> 
>}
>}
>}
> }
> 
> There’s an error triggered by the doClosure call inside a doClosure call 
> saying that I need an explicit self capture. However, the same pattern in 
> appendManual() builds just fine. I’m guessing this is a bug?
> 
> 
> 
> Jon

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

[swift-users] Capturing difference with typealias

[Jon Shier via swift-users]

Users:
I’m updating more code to beta 6 and have noticed a strange difference 
when calling functions with closure parameters where that closure is declared 
with a typealias. Take this class:

typealias Closure = () -> Void

class Thing {
var array: [String] = []

func doClosure(closure: Closure) {
array.append("closure")
}

func doManualClosure(manualClosure: () -> Void) {
array.append("manualClosure")
}

func append() {
doClosure {
doClosure {

}
}
}

func appendManual() {
doManualClosure {
doManualClosure {

}
}
}
}

There’s an error triggered by the doClosure call inside a doClosure call saying 
that I need an explicit self capture. However, the same pattern in 
appendManual() builds just fine. I’m guessing this is a bug?



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

Re: [swift-users] ProcessInfo arguments when running as a script?

[Jon Shier via swift-users]

Jordan:
You’re quite right. I knew something had been renamed but between 
Process and ProcessInfo I lost my way.


Jon

> On Aug 18, 2016, at 11:05 PM, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> I’d be surprised if the behavior of ProcessInfo has actually changed. 
> Swift.CommandLine (formerly Swift.Process, unrelated to ProcessInfo) should 
> have the script arguments only.
> 
> Jordan
> 
> 
>> On Aug 18, 2016, at 19:14, Jon Shier via swift-users <swift-users@swift.org> 
>> wrote:
>> 
>> Swift Users:
>>  I’m trying to parse the command-line arguments of a Swift 3 script 
>> using Xcode 8 beta 6. However, ProcessInfo’s arguments array now contains 
>> all of the swift compiler arguments as well as the command itself. For 
>> example, this script:
>> 
>> #!/usr/bin/env swift
>> 
>> import Foundation
>> 
>> print(ProcessInfo.processInfo.arguments)
>> 
>> now prints:
>> 
>> ["/Users/jshier/Downloads/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift”,
>>  
>> "-frontend”, 
>> "-interpret”, 
>> "./processInfo.swift”,
>> "-target”,
>> "x86_64-apple-macosx10.9”,
>> "-enable-objc-interop”, 
>> "-sdk”, 
>> "/Users/jshier/Downloads/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk”,
>> "-color-diagnostics”,
>> "-module-name”,
>> "processInfo"]
>> 
>> (arguments broken into lines for readability)
>> 
>> Is this a bug (and if so, does it need to be reported) or is it an 
>> intentional change (if so, how are we supposed to parse arguments now?)?
>> 
>> 
>> 
>> 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

[swift-users] ProcessInfo arguments when running as a script?

[Jon Shier via swift-users]

Swift Users:
I’m trying to parse the command-line arguments of a Swift 3 script 
using Xcode 8 beta 6. However, ProcessInfo’s arguments array now contains all 
of the swift compiler arguments as well as the command itself. For example, 
this script:

#!/usr/bin/env swift

import Foundation

print(ProcessInfo.processInfo.arguments)

now prints:

["/Users/jshier/Downloads/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift”,
 
"-frontend”, 
"-interpret”, 
"./processInfo.swift”,
 "-target”,
 "x86_64-apple-macosx10.9”,
 "-enable-objc-interop”, 
"-sdk”, 
"/Users/jshier/Downloads/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk”,
"-color-diagnostics”,
 "-module-name”,
 "processInfo"]

(arguments broken into lines for readability)

Is this a bug (and if so, does it need to be reported) or is it an intentional 
change (if so, how are we supposed to parse arguments now?)?



Jon

___
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?

[Jon Shier via swift-users]

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 <jordan_r...@apple.com> 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 <swift-users@swift.org 
>> <mailto:swift-users@swift.org>> 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 <mailto: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] SCNetworkReachabilityFlags beta 4 issue

[Jon Shier via swift-users]

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

Re: [swift-users] Date and Data

[Jon Shier via swift-users]

If you think Date and Data look similar at a glance, wouldn’t NSDate and 
NSData? Or are you comparing this against your old Array type?

> On Aug 3, 2016, at 6:33 PM, Travis Griggs via swift-users 
>  wrote:
> 
> I realize this ship has probably sailed a long while ago. I really like the 
> way the Foundation library is shaping up. With the changes in Swift3, I’ve 
> been moving any of my Array cases to using Data. A handful of handy 
> extensions to Data have made working with it nice. It’s much easier to figure 
> out how to extend Data than Array. And of course, the UIKit/Cocoa 
> libraries love Data things.
> 
> That said, one minor nit I’ve noticed, especially with the inclusion of Date 
> and the dropping of the NS prefixes, is that when I’m scanning code, Date and 
> Data look a lot a like. Where Swift tries so hard to be expressive, this ends 
> up being a dissapointment. My particular app uses quite a bit of both.
> 
> Of late, I’ve added a
> 
> typealias Bytes = Data
> 
> and begun replacing Data references with Bytes.
> 
> It’s too early to tell if its a good replacement or not. I recognize this is 
> a minor issue, rooted in the history of NSData and who knows what else. But I 
> thought I’d shared the feedback anyway.
> ___
> 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] Serial DispatchQueue and documentation?

[Jon Shier via swift-users]

Is it? I can’t tell by either the generated interface (default is not a useful 
value to expose) or a brief read of the Queue.swift file for it. 


Jon

> On Aug 1, 2016, at 6:52 PM, Brent Royal-Gordon <br...@architechies.com> wrote:
> 
>> On Aug 1, 2016, at 3:15 PM, Jon Shier via swift-users 
>> <swift-users@swift.org> wrote:
>> 
>> Swifters:
>>  It seems that in Xcode 8 beta 4, DispatchQueueAttributes was refactored 
>> to be DispatchQueue.Attributes but in the process lost the .serial 
>> attribute. How are we to create serial queues now? On a related note, where 
>> can we find the latest documentation for the Dispatch overlay? The Apple 
>> docs don’t have any actual usage information yet, so is there any 
>> documentation actually generated from code, like swiftdoc.org does for the 
>> standard library? 
>>  Here’s a link to the Apple dev forum regarding the same DispatchQueue 
>> issue: https://forums.developer.apple.com/thread/53270
> 
> Isn't `serial` the default? If so, you should just be able to pass an empty 
> array literal (`[]`) or omit the `attributes` parameter entirely.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

[swift-users] Serial DispatchQueue and documentation?

[Jon Shier via swift-users]

Swifters:
It seems that in Xcode 8 beta 4, DispatchQueueAttributes was refactored 
to be DispatchQueue.Attributes but in the process lost the .serial attribute. 
How are we to create serial queues now? On a related note, where can we find 
the latest documentation for the Dispatch overlay? The Apple docs don’t have 
any actual usage information yet, so is there any documentation actually 
generated from code, like swiftdoc.org does for the standard library? 
Here’s a link to the Apple dev forum regarding the same DispatchQueue 
issue: https://forums.developer.apple.com/thread/53270



Jon Shier

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

[swift-users] Generic type metadata pattern not found?

[Jon Shier via swift-users]

Swift Users:
In preparation for an upcoming iOS app project I’m trying out some new 
project layout strategies. One of which is putting my network layer and custom 
UI elements in frameworks separate from my main app. I’ve done this with 
frameworks in my project, and then used CocoaPods to install the dependencies 
for these frameworks (just the Networking framework at the moment). However, 
I’m getting the following build error when the app tries to link:

Undefined symbols for architecture x86_64:
  "generic type metadata pattern for Alamofire.Response", referenced from:
  type metadata accessor for Alamofire.Response in ViewController.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This occurs despite the Response type being visible to autocomplete in Xcode 
and there being no compilation errors at build time. Is there anything I can do 
to fix this or is this some sort of Xcode / Swift linker bug or limitation? It 
seems like my options are to link Alamofire directly against by app target or 
wrap the Response type in something of my own in my Networking framework. I’d 
prefer not to have to import Alamofire directly, as part of hiding all of the 
network stuff in a single framework was to limit those sorts of dependencies.



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