16 ms·

Swift 5 Exclusivity Enforcement

115 points by return_0e 8y ago

zaksoup 8y 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?
- saagarjha 8y 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 8y 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.
    - saagarjha 8y ago
      I'm going to refer you to the proposal, which explains the rationale behind the change better than I possibly could: https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md https://github.com/apple/swift-evolution/blob/master/proposa...
- deleted 8y ago
  [deleted]
saagarjha 8y ago
I'm assuming that -Ounchecked also removes the runtime diagnostic?
- atrick6 8y ago
  Yes, it removes exclusivity checks and bounds checks.
kris-s 8y 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.
- giornogiovanna 8y 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.
  - mamcx 8y ago
    But how many times the problem truly happened? Is in my experience so rare that the experience is alike with a GC.
    - giornogiovanna 8y ago
      - Doubly linked lists. - Cocoa delegates that keep references to some parent of the objects that they're delegates of. - Some event listeners (in the same way as delegates). I wouldn't say it's "rare". It popped up pretty often for me when I was writing Objective C.
      - azinman2 8y ago
        What’s not solved with weak refs?
        giornogiovanna 8y ago
        It can always be solved with weak references.
        8y ago
Teknoman117 8y ago
And here I thought this was going to be something about enforcing some exclusivity of swift to apple devices...
- jake_the_third 8y ago
  With their recent attempt at patenting programming-language concepts, you'd be excused to think so. I thought the same.
Temasik 8y ago
How do you use swift on ubuntu
- saagarjha 8y ago
  You should be able to download a toolchain from here for your version of Ubuntu and have it work: https://swift.org/download/ https://swift.org/download/
hnbroseph 8y ago
neat. maybe by swift 10 they will have windows builds and i can check it out.

115 points by return_0e 8y 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?

saagarjha 8y 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 8y 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.
  - saagarjha 8y ago
    I'm going to refer you to the proposal, which explains the rationale behind the change better than I possibly could: https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md https://github.com/apple/swift-evolution/blob/master/proposa...
deleted 8y ago
[deleted]

saagarjha 8y ago

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

atrick6 8y ago
Yes, it removes exclusivity checks and bounds checks.

kris-s 8y 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.

giornogiovanna 8y 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.
- mamcx 8y ago
  But how many times the problem truly happened? Is in my experience so rare that the experience is alike with a GC.
  - giornogiovanna 8y ago
    - Doubly linked lists. - Cocoa delegates that keep references to some parent of the objects that they're delegates of. - Some event listeners (in the same way as delegates). I wouldn't say it's "rare". It popped up pretty often for me when I was writing Objective C.
    - azinman2 8y ago
      What’s not solved with weak refs?
      - giornogiovanna 8y ago
        It can always be solved with weak references.
        8y ago

Teknoman117 8y ago

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

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

Temasik 8y ago

How do you use swift on ubuntu

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

hnbroseph 8y ago

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