[swift-users] Assigning [Int] to [Any] crashes Swift 2.2

[Jens Alfke via swift-users]

Just ran into a weird crash with Swift 2.2 in Xcode 7.3. It reproduces in a 
playground:

import Foundation
let a = [88]
let b: [Any] = a   // CRASH

In my real program, the top of the crash backtrace is:

* thread #1: tid = 0x460b62, 0x00010669988b 
libswiftCore.dylib`swift_unknownRetain + 27, queue = 'com.apple.main-thread', 
stop reason = EXC_BAD_ACCESS (code=1, address=0x58)
frame #0: 0x00010669988b libswiftCore.dylib`swift_unknownRetain + 27
frame #1: 0x000106488565 
libswiftCore.dylib`Swift._arrayConditionalBridgeElements  
(Swift.Array) -> Swift.Optional + 1029
frame #2: 0x0001064875a7 libswiftCore.dylib`Swift._arrayForceCast  (Swift.Array) -> Swift.Array + 263

It’s interesting that the memory address causing the crash is 0x58, which in 
decimal is 88, the first item in the array. If you change the first item of the 
array to a different number, the crash address changes to match. So it’s 
misinterpreting the integer as a pointer.

Also interestingly, if you remove “import Foundation”, it no longer compiles — 
the last line gets an error “Cannot convert value of type ‘[Int]’ to expected 
argument type ‘[Any]’”. Is boxing of integers really dependent on Obj-C 
bridging?

—Jens

PS: Should I file the bug report with Apple or at swift.org?___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Latest development code fails to build

[Jordan Rose via swift-users]

They come out roughly biweekly, although it depends on how stable the build is. 
If you hadn't seen already, there are older snapshots 
 at the bottom of the page.

Jordan


> On Apr 13, 2016, at 16:45, Charles Lane  wrote:
> 
> Excellent! Thanks, I thought I was going crazy since I didn’t see any other 
> reports about this. I assume we’ll see a new snapshot posted at some point 
> then?
> 
> Regards,
> Chuck Lane
> 

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

Re: [swift-users] Latest development code fails to build

[Jordan Rose via swift-users]

Drat, that's me. I was hoping to get out of the business of knowing 
UIApplicationMain's exact signature, but I guess that doesn't always work? I'll 
ask around for a better solution.

My apologies,
Jordan

> On Apr 13, 2016, at 16:15, Charles Lane via swift-users 
>  wrote:
> 
> Actually, you don’t have to write any code. Just make a new project using a 
> single view application and try to build it. I’ve re-downloaded the developer 
> build and even downloaded Xcode again from the App store.
> 
> Here is the error that Xcode reports:
> 
> CompileSwift normal x86_64 
> /Users/charleslane/SWDev/SwiftFiles/MiscProjects/iosTestforJGroff/iosTestforJGroff/AppDelegate.swift
> cd /Users/charleslane/SWDev/SwiftFiles/MiscProjects/iosTestforJGroff
> 
> /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a.xctoolchain/usr/bin/swift
>  -frontend -c 
> /Users/charleslane/SWDev/SwiftFiles/MiscProjects/iosTestforJGroff/iosTestforJGroff/ViewController.swift
>  -primary-file 
> /Users/charleslane/SWDev/SwiftFiles/MiscProjects/iosTestforJGroff/iosTestforJGroff/AppDelegate.swift
>  -target x86_64-apple-ios9.3 -enable-objc-interop -sdk 
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.3.sdk
>  -I 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Products/Debug-iphonesimulator
>  -F 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Products/Debug-iphonesimulator
>  -enable-testing -g -module-cache-path 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/ModuleCache 
> -serialize-debugging-options -Xcc 
> -I/Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Intermediates/iosTestforJGroff.build/Debug-iphonesimulator/iosTestforJGroff.build/swift-overrides.hmap
>  -Xcc -iquote -Xcc 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Intermediates/iosTestforJGroff.build/Debug-iphonesimulator/iosTestforJGroff.build/iosTestforJGroff-generated-files.hmap
>  -Xcc 
> -I/Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Intermediates/iosTestforJGroff.build/Debug-iphonesimulator/iosTestforJGroff.build/iosTestforJGroff-own-target-headers.hmap
>  -Xcc 
> -I/Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Intermediates/iosTestforJGroff.build/Debug-iphonesimulator/iosTestforJGroff.build/iosTestforJGroff-all-target-headers.hmap
>  -Xcc -iquote -Xcc 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Intermediates/iosTestforJGroff.build/Debug-iphonesimulator/iosTestforJGroff.build/iosTestforJGroff-project-headers.hmap
>  -Xcc 
> -I/Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Products/Debug-iphonesimulator/include
>  -Xcc 
> -I/Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Intermediates/iosTestforJGroff.build/Debug-iphonesimulator/iosTestforJGroff.build/DerivedSources/x86_64
>  -Xcc 
> -I/Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Intermediates/iosTestforJGroff.build/Debug-iphonesimulator/iosTestforJGroff.build/DerivedSources
>  -Xcc -DDEBUG=1 -Xcc 
> -working-directory/Users/charleslane/SWDev/SwiftFiles/MiscProjects/iosTestforJGroff
>  -emit-module-doc-path 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Intermediates/iosTestforJGroff.build/Debug-iphonesimulator/iosTestforJGroff.build/Objects-normal/x86_64/AppDelegate~partial.swiftdoc
>  -Onone -module-name iosTestforJGroff -emit-module-path 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Intermediates/iosTestforJGroff.build/Debug-iphonesimulator/iosTestforJGroff.build/Objects-normal/x86_64/AppDelegate~partial.swiftmodule
>  -serialize-diagnostics-path 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Intermediates/iosTestforJGroff.build/Debug-iphonesimulator/iosTestforJGroff.build/Objects-normal/x86_64/AppDelegate.dia
>  -emit-dependencies-path 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/iosTestforJGroff-faanxccoissojpdbyetnddefzcpz/Build/Intermediates/iosTestforJGroff.build/Debug-iphonesimulator/iosTestforJGroff.build/Objects-normal/x86_64/AppDelegate.d
>  -emit-reference-dependencies-path 
> 

Re: [swift-users] Latest development code fails to build

[Joe Groff via swift-users]

> On Apr 13, 2016, at 10:27 AM, Charles Lane via swift-users 
>  wrote:
> 
> Every time I try to build any app in Xcode 7.3 with the latest development 
> snapshot (Apr 12), the build fails with this error:  `Command failed due to 
> signal: Illegal instruction: 4`
> Anyone else seeing this? The default and the 2.2.1 snapshot works fine.

Can you file a bug with your code that's causing the crash?

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

[swift-users] IBM and Swift on the Server

[Alex Blewitt via swift-users]

At QCon London earlier this year, IBM came to speak about their work with Swift 
on the server and their use on Linux. I interviewed them afterwards about it, 
and now both the presentation and interview write-up are available on InfoQ, in 
case you’re interested:

http://www.infoq.com/presentations/swift-server
http://www.infoq.com/articles/Ibm-swift

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

[swift-users] Latest development code fails to build

[Charles Lane via swift-users]

Every time I try to build any app in Xcode 7.3 with the latest development 
snapshot (Apr 12), the build fails with this error:  `Command failed due to 
signal: Illegal instruction: 4`
Anyone else seeing this? The default and the 2.2.1 snapshot works fine.

Regards,
Chuck Lane
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-evolution] What about a VBA style with Statement?

[Sean Heber via swift-users]

> On Apr 13, 2016, at 10:08 AM, Erica Sadun  wrote:
> 
> 
>> On Apr 13, 2016, at 8:25 AM, Sean Heber via swift-evolution 
>>  wrote:
>> 
>> This pair works pretty well, too, if you don’t mind free functions:
>> 
>> func with(inout this: T, @noescape using: inout T->Void) { using() }
>> func with(this: T, @noescape using: T->Void) { using(this) }
>> 
>> It works either with classes or mutable structs if you call it correctly and 
>> the type doesn’t matter.
>> 
>> l8r
>> Sean
> 
> My current version is this:
> 
> func with(item: T, @noescape update: (inout T) -> Void) -> T {
> var this = item; update(); return this
> }
> 
> Used, for example:
> 
> struct Foo { var (a, b, c) = ("a", "b", "c") }
> class Bar: DefaultReflectable { var (a, b, c) = ("a", "b", 2.5) }
> var f = with(Foo()) { $0.a = "X" }
> var b = with(Bar()) { $0.a = "X" }
> print(f) // Foo(a: "X", b: "b", c: "c")
> print(b) // Bar(a=X, b=b, c=c)
> 
> Is there an advantage to having a pair of functions?

I don’t know if it’s a huge advantage or not, but with warnings on unused 
results, using a with() that has a return with a class instance would mean 
you’d have to discard the return result explicitly or pointlessly reassign the 
results to your instance (thus meaning not using a let) just to avoid the 
warning. If you annotated the with() to allow discarding the result, then it’d 
be error-prone for structs. It seemed “safer” to me to have a pair.

l8r
Sean

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

Re: [swift-users] [swift-evolution] What about a VBA style with Statement?

[Erica Sadun via swift-users]

> On Apr 13, 2016, at 9:26 AM, Sean Heber  wrote:
> 
>> On Apr 13, 2016, at 10:08 AM, Erica Sadun  wrote:
>> 
>> 
>>> On Apr 13, 2016, at 8:25 AM, Sean Heber via swift-evolution 
>>>  wrote:
>>> 
>>> This pair works pretty well, too, if you don’t mind free functions:
>>> 
>>> func with(inout this: T, @noescape using: inout T->Void) { using() }
>>> func with(this: T, @noescape using: T->Void) { using(this) }
>>> 
>>> It works either with classes or mutable structs if you call it correctly 
>>> and the type doesn’t matter.
>>> 
>>> l8r
>>> Sean
>> 
>> My current version is this:
>> 
>> func with(item: T, @noescape update: (inout T) -> Void) -> T {
>>var this = item; update(); return this
>> }
>> 
>> Used, for example:
>> 
>> struct Foo { var (a, b, c) = ("a", "b", "c") }
>> class Bar: DefaultReflectable { var (a, b, c) = ("a", "b", 2.5) }
>> var f = with(Foo()) { $0.a = "X" }
>> var b = with(Bar()) { $0.a = "X" }
>> print(f) // Foo(a: "X", b: "b", c: "c")
>> print(b) // Bar(a=X, b=b, c=c)
>> 
>> Is there an advantage to having a pair of functions?
> 
> I don’t know if it’s a huge advantage or not, but with warnings on unused 
> results, using a with() that has a return with a class instance would mean 
> you’d have to discard the return result explicitly or pointlessly reassign 
> the results to your instance (thus meaning not using a let) just to avoid the 
> warning. If you annotated the with() to allow discarding the result, then 
> it’d be error-prone for structs. It seemed “safer” to me to have a pair.
> 
> l8r
> Sean
> 

If you want to call

>> let f = with(Foo()) { $0.a = "X" }
>> let b = with(Bar()) { $0.a = "X" }

with constant assignment and an initializer, I'm not sure how yours would work. 
Could they?

-- E, trying right now in the playground

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

Re: [swift-users] Generators vs. errors

[Brent Royal-Gordon via swift-users]

> On Apr 12, 2016, at 11:53 AM, Jens Alfke via swift-users 
>  wrote:
> 
> What should one do, when implementing a Generator, if the underlying data 
> source can experience errors? Generator.next isn’t allowed to throw, only to 
> return nil at the end of the sequence.
> 
> The only idea I can think of is to add an `error` property to my Generator 
> implementation, and request that the caller check it after the iteration 
> ends, and/or a `checkForError()` method that can throw an error if there is 
> one:
>   var q: Query = db.query(…)
>   for (row in q) { … }
>   q.checkForError()
> 
> As the example implies, this problem comes up when creating Swift bindings 
> for database iterators/cursors. Generator is the obvious protocol to 
> implement, especially since without it you don’t get the idiomatic for/in 
> loop, but the `next` method does have to hit the database, so it has the 
> possibility of I/O errors.

What I might do is use a block to make sure you can't forget the 
`checkForError()` method:

let query = db.query(…)
try query.withResults { results in
// `results` is a SequenceType you can iterate over.
// You can only get at it by calling `withResults` on a Query, 
and it becomes invalid once 
// `withResults` returns.
// If `results` encounters an error, it terminates early.
for row in results {
// Use your row
}
}

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-users] Trouble constraining a generic type in an extension

[Brent Royal-Gordon via swift-users]

> I *think* the feature you’re trying to use is on the todo list for Swift 3, 
> but the last time I said that, I was completely wrong. The swift-evolution 
> mailing list probably has more information.

I think it's on the list of things they'd like to do to generics in the future, 
but it's a very long list and they might not get to that particular one.

In short, though, my understanding is that there is no principled reason for 
this limitation; it simply isn't supported yet.

-- 
Brent Royal-Gordon
Architechies

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