Swift 5 Exclusivity Enforcement

https://swift.org/blog/swift-5-exclusivity/

by return_0e • 7 years ago

115 61 7 years ago

zaksoup• 7 years ago

I'm not totally versed in Swift. In the example provided is it ambiguous because the closure captures `count` and count itself is being modified by the method calling the block?

I don't understand why this is an example of an unsafe operation. Wouldn't clearly defined behavior of closures clarify the "3 or 4" question?

saagarjha7• 7 years ago

I don't understand why this is an example of an unsafe operation. Wouldn't clearly defined behavior of closures clarify the "3 or 4" question?

I believe that it's possible to specify this, and that's basically the behavior we had before SE-0176 was implemented. The issue with this is that it was slower for a dubious benefit (the semantics are obscure and non-obvious), so it was decided that it's just better to disallow this and get the benefit of clear behavior and better optimization opportunities, at the cost of removing this somewhat uncommon and not-all-that-hard to-rewrite-for-clarity pattern.

duneroadrunner• 7 years ago

it was slower for a dubious benefit

Isn't this kind of arguable? The benefit is that it avoids the need to make unnecessary copies in some cases, as is basically acknowledged in the article:

The exclusivity violation can be avoided by copying any values that need to be available within the closure

Right? And in addition to the local cost of the extra copy, there's also the more ubiquitous cost of these run-time checks. Yes, there's the potential benefit of better optimization due to the non-aliasing guarantee, but I think it's far from clear that it's an overall performance win.

While I think it's reasonable to adopt a universal "exclusivity of mutable references" policy in order to achieve memory safety and address a fear of a (vaguely-defined) notion of "mutable state and action at a distance" (referred to in the article), particularly for a language like Swift, I think it would be improper to dismiss the associated costs, or even to imply that the costs are well understood at this point. Or to imply that this policy is, at this point, known to be an optimal solution for achieving memory (or any other kind of code) safety.

saagarjha7• 7 years ago

I'm assuming that -Ounchecked also removes the runtime diagnostic?

atrick6• 7 years ago

Yes, it removes exclusivity checks and bounds checks.

kris-s• 7 years ago

I put Swift into the category of "almost memory managed" languages and it's never fully clicked in my brain. Thinking about strong/weak/unowned references is more difficult in my opinion than when to malloc/free something. Following the examples in the article just reinforced that maybe Swift's approach is a little too complex.

giornogiovanna7• 7 years ago

Right. This is one of the things I don't like about automatic reference counting, that it's almost a complete solution, but cycles require more thought (but less cases) to deal with than manual memory management itself.

mamcx2• 7 years ago

But how many times the problem truly happened? Is in my experience so rare that the experience is alike with a GC.

dfgdghdf• 7 years ago

It would be interesting to compare the cognitive load of the Swift way and the Rust way. Rust gives you better guarantees, but you must annotate your code.

favorited• 7 years ago

You can add a cycle collector on top of a reference-counted language. It's been discussed for Swift, but there are downsides which might make it not worth adding.

saagarjha7• 7 years ago

The benefit being that you only have to deal with this issue rarely, rather than all the time with manual memory management.

fauigerzigerk3• 7 years ago

I find it extremely dangerous if issues arise rarely but not rarely enough stop thinking about them and not as rarely as you would think. Look at this terrifying example from [1]. How long do you have to look at this code to tell if there is a reference cycle or not?

    class ServiceLayer {
        // ...
        private var task: URLSessionDataTask?

        func foo(url: URL) {
            task = URLSession.shared.dataTask(with: url) { data, response, error in
                let result = // process data
                DispatchQueue.main.async { [weak self] in
                    self?.handleResult(result)
                }
            }
            task?.resume()
        }

        deinit {
            task?.cancel()
        }
    }

[1] http://marksands.github.io/2018/05/15/an-exhaustive-look-at-...

bsaul2• 7 years ago

The examples are complex to follow because Swift model works just fine for all the normal cases. It only becomes problematic in some edge cases that regular programmer rarely meet.

And with all the help that the compiler now provides (even before swift 5), it's becoming really really hard to shoot yourself in the foot.

ken• 7 years ago

I must be specially talented in this area, because I still run into memory issues fairly often. Just a couple days ago, I had a weak reference which was turning nil (Swift weak references are zeroing), and I couldn't figure out why. Both objects were still live. Property observers don't report the nil change, apparently. I couldn't figure out how to get the debugger or Instruments to provide any help, either.

Eventually I just gave up and added an extra 'parent:' argument to an interface, for the one place it was actually needed. It's a bit more awkward than just keeping parent references in the tree nodes, but not too bad.

For situations with multiple queues or threads, the situation is even worse. I wrap a lot of my GCD code in extra locks, which by my reading of the documentation shouldn't be necessary. Without them, it occasionally crashes with strange memory errors that are impossible to figure out.

I felt like I wasted a few hours trying to track down my issue, the other day, and then come up with an alternative solution, while in any other modern language I could just have used a normal reference and counted on the GC to clean up the cycles when I'm done.

Backwards compatibility with Objective-C obviously has tremendous value to Apple, and ARC is smaller and faster than tracing GC, but I feel like I'm paying for it over and over. In most HLLs, once I get past the low-level parts, I'm using a language specifically designed for my task, and I never have to touch the low-level parts again. Swift feels more like fancy C, in that I don't think I'll ever be able to stop thinking about subtle memory management issues.

diegoperini• 7 years ago

Looking from a distance, what Swift does is actually taking best practices from modern C++ (14+) and incorporating them on the language level instead of introducing new library tools.

If you regularly code C++, the "fuck, yes!" moment is there when you learn Swift.

zozbot1235• 7 years ago

You're actually describing what Rust is doing, more than anything. Swift has a lot more in common with Objective-C than C++, even though it does move away from the most challenging parts of Objective-C itself.

gurkendoktor• 7 years ago

The flip side is that Swift has copied some bad parts of C++ as well: ridiculous compile times, value-type performance traps, ever-increasing complexity, mediocre IDE support, no ABI (I know, coming soon).

Either way, to me Swift feels much closer to C++ than to Objective-C in spirit. I don't think it's a coincidence that there are at least two C++ committee veterans among its contributors :)

Teknoman117• 7 years ago

And here I thought this was going to be something about enforcing some exclusivity of swift to apple devices...

jake_the_third• 7 years ago

With their recent attempt at patenting programming-language concepts, you'd be excused to think so. I thought the same.

Temasik• 7 years ago

How do you use swift on ubuntu

saagarjha7• 7 years ago

You should be able to download a toolchain from here for your version of Ubuntu and have it work: https://swift.org/download/

hnbroseph• 7 years ago

neat. maybe by swift 10 they will have windows builds and i can check it out.

Swift 5 Exclusivity Enforcement

Related Stories