[swift-users] Swift and Threads

This function works flawlessly in Release build: func markAndTell( talk: Bool, number: Int) { let nbrOfThreads = 8 let step = 2 let itemsPerThread = number * step let bitLimit = nbrOfThreads * itemsPerThread var bitfield = [Bool](count: bitLimit, repeatedVal

Re: [swift-users] Stored Property on Protocol Extension

There's no good way of using extensions to expand the storage of an external module's type unless you're using Associated Objects underneath, but that has heavy performance implications (especially in threaded cases, which would require global locks on the associated object store). At most, I'd

Re: [swift-users] Stored Property on Protocol Extension

​I don't know why the limit exists. Technical or on purpose. I hope someone inside can answer this. Zhaoxin​ On Mon, Sep 12, 2016 at 11:55 PM, Daniel Dunbar via swift-users < swift-users@swift.org> wrote: > > > On Sep 11, 2016, at 6:12 PM, Tanner Nelson via swift-users < > swift-users@swift.org>

Re: [swift-users] Issues with UITableView*

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

Re: [swift-users] Issues with UITableView*

> 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

Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

Hi Jens and mailing list members, I hope that Chris Lattner and the Swift team can move to that goal very quickly by following the trend of Go and Rust that have already gone through that process. Most of the documentation from different publishers is going to be outdated very quickly if the synt

Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

> On Sep 12, 2016, at 3:03 PM, Shyamal Chandra via swift-users > wrote: > > Instead of moving onto Swift 3, 4, and 5 (with different syntax), why don't > you standardize the library and language operations and functions for the > different package and frameworks included with Xcode That is t

Re: [swift-users] Issues with UITableView*

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? —fish (Adam Stoller) > On Sep 12, 2016, at 18:08, Ole Begemann wrote: > > > The c

Re: [swift-users] Issues with UITableView*

> The current version of my code seems to satisfy points #1-3, but crashes > when attempting to deal with #4 - and I’m not sure that what I’ve done > is “good” or “correct” in terms of satisfying the first three points. I haven't looked at all of your code, but one thing that could definitely ca

[swift-users] Swift and Xcode along with Playgrounds is full of bugs

Hi all, Hope you are doing well! Swift is very volatile language that keeps on changing with every new version of Xcode. When you are trying to run old code with different syntax, you run into problems because the code is no longer compatible. Instead of moving onto Swift 3, 4, and 5 (with diffe

[swift-users] Issues with UITableView*

I’m trying to do something that I thought would be rather simple: Display a list of information in rows of a table (in this case, each row would contain a ‘name’ and a ‘location’ label)If clicked on once, the row should become selected (highlighted and checked)If clicked on again (same row), the ro

Re: [swift-users] Closure typing changed in Swift 3

> On Sep 9, 2016, at 8:05 PM, Rick Mann via swift-users > wrote: > > I figured it out. The real problem is that .json accepts AnyObject, and the > Dictionary is not AnyObject (not sure what this change is, since it worked in > Swift 2). Anyway, that confused the type inference, which resulted

Re: [swift-users] Canonical way to cast C structs

On 12 Sep 2016, at 20:39, Bouke Haarsma via swift-users wrote: > So the question remains on how to perform the casts using Swift? In general it’s best to avoid special casing your network protocols. The best option for doing that is and calls. Specifically, with `getnameinfo`, if you sp

Re: [swift-users] Canonical way to cast C structs

Sorry for all the pings, but it appears that the code below doesn’t work after all; > fatal error: can't unsafeBitCast between types of different sizes So the question remains on how to perform the casts using Swift? — Bouke > On 12 sep. 2016, at 21:37, Bouke Haarsma wrote: > > > Sorry, mis

Re: [swift-users] Canonical way to cast C structs

Sorry, missed the first line when copying: let generic = unsafeBitCast(CFDataGetBytePtr(data), to: sockaddr.self) switch generic.sa_family { case sa_family_t(AF_INET): let ipv4 = unsafeBitCast(generic, to: sockaddr_in.self) //... case sa_family_t(AF_INET6): let ipv6 = unsafeBitCast(ge

Re: [swift-users] Canonical way to cast C structs

Ah the missing part of the puzzle appears to be unsafeBitCast(:to:), so the Swift version becomes this: switch generic.sa_family { case sa_family_t(AF_INET): let ipv4 = unsafeBitCast(generic, to: sockaddr_in.self) //... case sa_family_t(AF_INET6): let ipv6 = unsafeBitCast(generic, to:

Re: [swift-users] Provide native Decimal data type

> On Sep 12, 2016, at 1:26 PM, Jens Alfke via swift-users > wrote: > >> On Sep 12, 2016, at 10:10 AM, Teej . via swift-users > > wrote: >> >> …in spite of the CPU’s quirks in handling floating point numbers in a >> maddening inaccurate manner. > > Well, in

Re: [swift-users] Provide native Decimal data type

I agree on your point — base-10 notation is not compatible with a base-2 infrastructure. However, that is just exposing the reality of the floating point data type. It still does not answer my question on why we can’t just provide a decimal data type. I am aware of the NSDecimalNumber class

Re: [swift-users] Provide native Decimal data type

> On Sep 12, 2016, at 10:10 AM, Teej . via swift-users > wrote: > > …in spite of the CPU’s quirks in handling floating point numbers in a > maddening inaccurate manner. Well, in the CPU’s defense, it’s only inaccurate because the puny humans insist on dividing their currency into fract

[swift-users] Provide native Decimal data type

Please forgive me if this have already been hashed out. Google and DuckDuckGo have not been helpful in my research, and the archives do not have a search functionality. I am new to Swift, and starting from 3.0 beta. I am aware that the language is not stabilized, so I feel thi

Re: [swift-users] Stored Property on Protocol Extension

> On Sep 11, 2016, at 6:12 PM, Tanner Nelson via swift-users > wrote: > > Hey Swift Users, > > I was wondering how you all work around not being able to add stored > properties in extensions (especially protocol extensions). > > I ran into an issue recently where I needed an internal stored

[swift-users] Stored Property on Protocol Extension

Hey Swift Users, I was wondering how you all work around not being able to add stored properties in extensions (especially protocol extensions). I ran into an issue recently where I needed an internal stored variable for a protocol, but I didn't want the conformer to worry about implementing th

Re: [swift-users] UnsafeMutablePointer Swift 3 conversion

Andy - yes thanks for the guidance and great job on your guide. There's a lot to absorb there. I think the metal samples are another great use case for your new apis. I have a small side project in mind to analyze its impact on performance, comparing the swift 3 compliant "safe" implementation v

Re: [swift-users] Lazy expression is ambiguous?

> On Sep 12, 2016, at 03:02 , Quinn The Eskimo! via swift-users > wrote: > > > On 12 Sep 2016, at 09:20, Rick Mann wrote: > >> I've always wondered why that was the case. > > Implementing `dispatch_once` so that it’s fast on all CPU architectures, > including those with a weak memory model

Re: [swift-users] Lazy expression is ambiguous?

On 12 Sep 2016, at 09:20, Rick Mann wrote: > I've always wondered why that was the case. Implementing `dispatch_once` so that it’s fast on all CPU architectures, including those with a weak memory model, requires that ‘once token’: * be initialised to 0 before `dispatch_once` sees it * not m

Re: [swift-users] Lazy expression is ambiguous?

> On Sep 12, 2016, at 00:53 , Quinn The Eskimo! via swift-users > wrote: > > > On 12 Sep 2016, at 08:46, Rick Mann wrote: > >> I had assumed lazy worked like static, which I understand uses dispatch_once >> under the hood. > > Correct. > > [I’m not sure if it actually /uses/ `dispatch_onc

Re: [swift-users] Lazy expression is ambiguous?

On 12 Sep 2016, at 08:53, Quinn The Eskimo! via swift-users wrote: > On 12 Sep 2016, at 08:46, Rick Mann wrote: > >> I had assumed lazy worked like static, which I understand uses dispatch_once >> under the hood. > > Correct. Re-reading the above I realise that it was ambiguous. Let’s try

Re: [swift-users] Lazy expression is ambiguous?

On 12 Sep 2016, at 08:46, Rick Mann wrote: > I had assumed lazy worked like static, which I understand uses dispatch_once > under the hood. Correct. [I’m not sure if it actually /uses/ `dispatch_once` specifically, but it has the same semantics.] > Would that be a reasonable thing for lazy

Re: [swift-users] Lazy expression is ambiguous?

On 12 Sep 2016, at 08:28, Zhao Xin wrote: > It is not a bug. I disagree. > You must explicitly specify the variable's type if you use `lazy` keyword. No, that’s not the case in general. For example, the following code compiles just fine. import Dispatch func queueMaker() -> Dispatch

Re: [swift-users] Lazy expression is ambiguous?

> On Sep 12, 2016, at 00:02 , Quinn The Eskimo! via swift-users > wrote: > > > On 12 Sep 2016, at 06:40, Jacob Bandes-Storch via swift-users > wrote: > >> I'd recommend filing a bug at bugs.swift.org. > > Agreed. Done. https://bugs.swift.org/browse/SR-2616 > Also, you can work around thi

Re: [swift-users] Lazy expression is ambiguous?

Done. https://bugs.swift.org/browse/SR-2616 > On Sep 11, 2016, at 22:40 , Jacob Bandes-Storch wrote: > > This problem seems to occur when using an initializer with some default > argument values. The following code also exhibits the issue: > > struct Bar { > init(x: Int, y: Int? = 42) { } >

Re: [swift-users] Lazy expression is ambiguous?

It is not a bug. You must explicitly specify the variable's type if you use `lazy` keyword. `lazy` means the variable will be initialized later, but the compiler needs its type right now. Zhaoxin On Mon, Sep 12, 2016 at 3:02 PM, Quinn "The Eskimo!" via swift-users < swift-users@swift.org> wrote:

Re: [swift-users] Lazy expression is ambiguous?

On 12 Sep 2016, at 06:40, Jacob Bandes-Storch via swift-users wrote: > I'd recommend filing a bug at bugs.swift.org. Agreed. Also, you can work around this by adding a type. lazy var myQ: DispatchQueue = DispatchQueue(label: "Op", attributes: .concurrent) Also, with regards this specific