Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[David Sweeris via swift-evolution]

> On May 12, 2017, at 19:29, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of revisions to SE-0176: Enforce Exclusive Access to Memory begins 
> now and runs through May 17, 2017.
> 
> Most of this proposal was previously accepted.  An implementation issue has 
> been discovered with the use of dynamic enforcement on inout parameters.  The 
> proposal implementors suggest adopting a stronger rule governing the use of 
> non-escaping closures which will also allow Swift to make firm guarantees 
> about the use of static enforcement when a variable does not escape.  The 
> core team tentatively supports this new rule but believes it is a substantial 
> enough revision that it requires a separate review period.
> The proposal is available here: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
> 

This subject is a bit over my head, but from what I do understand, +1

- Dave Sweeris ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Christopher Kornher via swift-evolution]

https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
 

What is your evaluation of the proposal?
+1 It seems to be a carefully considered and balanced approach to simultaneous 
memory access in single threaded code.
Is the problem being addressed significant enough to warrant a change to Swift?
It sure seems to be.
Does this proposal fit well with the feel and direction of Swift?
Absolutely. Safety is one of the paramount goals of Swift and the ‘gotchas’ 
listed in the document can lead to subtle bugs, with potentially fatal 
consequences.
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
variants of `memcpy()` and similar C functions. Complex manipulation of data 
structures  in C, and C++ could lead to similar issues, I suppose, but the 
simple memory model of these languages puts developers on guard against 
simultaneous memory access. I certainly was not aware of these issues is Swift, 
but I am very cautious around mutating value types.  I expect that many Swift 
developers coming from classical OO languages are similarly wary of mutating 
value types, or should be. Fixing these issues will give me more confidence 
when dealing with mutating value types.
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I read through the proposal. It is very well written.  While I did not 
carefully study each case, I feel that I have a good understanding of the 
problem and the philosophy behind the solution. I feel confident that this will 
be a big improvement to the safety of Swift.

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

[swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Ben Cohen via swift-evolution]

Hello Swift community,

The review of revisions to SE-0176: Enforce Exclusive Access to Memory begins 
now and runs through May 17, 2017.

Most of this proposal was previously accepted.  An implementation issue has 
been discovered with the use of dynamic enforcement on inout parameters.  The 
proposal implementors suggest adopting a stronger rule governing the use of 
non-escaping closures which will also allow Swift to make firm guarantees about 
the use of static enforcement when a variable does not escape.  The core team 
tentatively supports this new rule but believes it is a substantial enough 
revision that it requires a separate review period.
The proposal is available here: 
https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
 

Since this is a review of revisions only, you may find these two relevant 
commits easier:
https://github.com/apple/swift-evolution/commit/d61c07df2f02bee6c00528e73fbe33738288179a
 

https://github.com/apple/swift-evolution/commit/5205a61f9cdca918d896269521bf89cb11e4aa12
 


Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at:
https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
 


Reply text

Other replies
What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[T.J. Usiyan via swift-evolution]

- What is your evaluation of the proposal? +1
- Is the problem being addressed significant enough to warrant a change to
Swift?Yes
- Does this proposal fit well with the feel and direction of Swift?I think
so.
- If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?I have only looked into
rust's ability to track a similar attribute and I prefer Swift's approach
on the face of it.
- How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

On Tue, May 2, 2017 at 4:07 PM, Ben Cohen via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of SE-0176: "Enforce Exclusive Access to Memory" begins now
> and runs through May 8, 2017.
>
> The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0176-enforce-exclusive-access-to-memory.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at:
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> When replying, please try to keep the proposal link at the top of the
> message:
>
> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0176-enforce-exclusive-access-to-memory.md
> Reply text
>
> Other replies
>
> 
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at:
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thanks,
> Ben Cohen
> Review Manager
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[John McCall via swift-evolution]

> On May 7, 2017, at 10:41 AM, Paul Cantrell  wrote:
> 
> 
>> On May 7, 2017, at 6:01 AM, Jean-Daniel > > wrote:
>> 
>>> 
>>> Le 7 mai 2017 à 03:54, Paul Cantrell via swift-evolution 
>>> > a écrit :
>>> 
>>> 
 On May 6, 2017, at 12:36 PM, John McCall via swift-evolution 
 > wrote:
 
 
> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution 
> > wrote:
> 
> Concern: `swap` is quoted a lot for a method that would break under this 
> rule, but as it happens, `swap` with the same value on both sides is 
> (should be) a no-op. Is there a way to not trip the static or dynamic 
> checkers in well-defined cases like that one? Is there any way to check 
> that two inout parameters refer to the same value?
 
 
 The only reasonable way to do this is statically, and why would you call 
 'swap' statically with the same l-value for both arguments?
>>> 
>>> When static analysis can determine that a swap is always a noop, I can’t 
>>> see any reason not to flag it as an error.
>>> 
>>> But Félix’s question was also about the runtime case. And he has a good 
>>> point.
>>> 
>>> Here’s a compelling example where allowing the noop swap would make sense:
>>> 
>>> extension Array {
>>>   mutating func shuffle() {
>>> for i in indices {
>>>   let j = i + Int(arc4random_uniform(UInt32(count - i)))
>>>   swap([i], [j])
>>> }
>>>   }
>>> }
>>> 
>> 
>> Isn’t this issue already solved by the introduction of swapAt ? 
> 
> Ah, indeed, you’re quite right: I see that SE-0173 removes the “different 
> elements” precondition for swapAt().
> 
> It’s not hard to imagine analogous situations involving data structures other 
> than arrays, so presumably Félix’s point still stands in principle for the 
> original swap().

swapAt is an operation on MutableCollection, not just on Array.

The key thing I think you may be missing here is that swapAt is needed because 
enforcement will otherwise prohibit two mutating accesses to the containing 
data structure.  We can't reliably poke a hole in that just for swap.

John.

> But I notice that SE-0173 says swap() will be deprecated & removed in the 
> future?! Surprising, but well of topic: SE-0176 would allow the 
> implementation of swapAt-like methods for other data structures, so no new 
> concerns about this proposal as it stands.
> 
> Cheers, P
> 

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

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Nevin Brackett-Rozinsky via swift-evolution]

On Sun, May 7, 2017 at 2:04 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Actually, `swapAt` does have a precondition that the elements differ.


Looking at the source code
,
the “swapAt” method is documented to have no effect when the indices are
equal:

/// Exchange the values at indices `i` and `j`.
///
/// Has no effect when `i` and `j` are equal.
mutating func swapAt(_ i: Index, _ j: Index)

Furthermore, the default implementation simply returns early when given the
same index twice:

extension MutableCollection {
  @_inlineable
  public mutating func swapAt(_ i: Index, _ j: Index) {
guard i != j else { return }
let tmp = self[i]
self[i] = self[j]
self[j] = tmp
  }
}

Contrast that with “swap” (found here
)
which is documented with “Precondition: `a` and `b` do not alias each
other.” And the implementation enforces that (at least in debug builds)
with:

_debugPrecondition(p1 != p2, "swapping a location with itself is not
supported")

So it looks like the precondition is only found on “swap”, and “swapAt”
should work properly (by doing nothing) when asked to exchange a single
index with itself.

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

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Xiaodi Wu via swift-evolution]

Actually, `swapAt` does have a precondition that the elements differ.
On Sun, May 7, 2017 at 09:41 Paul Cantrell via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On May 7, 2017, at 6:01 AM, Jean-Daniel  wrote:
>
>
> Le 7 mai 2017 à 03:54, Paul Cantrell via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
>
> On May 6, 2017, at 12:36 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Concern: `swap` is quoted a lot for a method that would break under this
> rule, but as it happens, `swap` with the same value on both sides is
> (should be) a no-op. Is there a way to not trip the static or dynamic
> checkers in well-defined cases like that one? Is there any way to check
> that two inout parameters refer to the same value?
>
>
> The only reasonable way to do this is statically, and why would you call
> 'swap' statically with the same l-value for both arguments?
>
>
> When static analysis can determine that a swap is *always* a noop, I
> can’t see any reason not to flag it as an error.
>
> But Félix’s question was also about the runtime case. And he has a good
> point.
>
> Here’s a compelling example where allowing the noop swap would make sense:
>
> extension Array {
>   mutating func shuffle() {
> for i in indices {
>   let j = i + Int(arc4random_uniform(UInt32(count - i)))
>   swap([i], [j])
> }
>   }
> }
>
>
> Isn’t this issue already solved by the introduction of swapAt ?
>
>
> Ah, indeed, you’re quite right: I see that SE-0173 removes the “different
> elements” precondition for swapAt().
>
> It’s not hard to imagine analogous situations involving data structures
> other than arrays, so presumably Félix’s point still stands in principle
> for the original swap(). But I notice that SE-0173 says swap() will be
> deprecated & removed in the future?! Surprising, but well of topic: SE-0176
> would allow the implementation of swapAt-like methods for other data
> structures, so no new concerns about this proposal as it stands.
>
> Cheers, P
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Paul Cantrell via swift-evolution]

> On May 7, 2017, at 6:01 AM, Jean-Daniel  wrote:
> 
>> 
>> Le 7 mai 2017 à 03:54, Paul Cantrell via swift-evolution 
>> > a écrit :
>> 
>> 
>>> On May 6, 2017, at 12:36 PM, John McCall via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution 
 > wrote:
 
 Concern: `swap` is quoted a lot for a method that would break under this 
 rule, but as it happens, `swap` with the same value on both sides is 
 (should be) a no-op. Is there a way to not trip the static or dynamic 
 checkers in well-defined cases like that one? Is there any way to check 
 that two inout parameters refer to the same value?
>>> 
>>> 
>>> The only reasonable way to do this is statically, and why would you call 
>>> 'swap' statically with the same l-value for both arguments?
>> 
>> When static analysis can determine that a swap is always a noop, I can’t see 
>> any reason not to flag it as an error.
>> 
>> But Félix’s question was also about the runtime case. And he has a good 
>> point.
>> 
>> Here’s a compelling example where allowing the noop swap would make sense:
>> 
>> extension Array {
>>   mutating func shuffle() {
>> for i in indices {
>>   let j = i + Int(arc4random_uniform(UInt32(count - i)))
>>   swap([i], [j])
>> }
>>   }
>> }
>> 
> 
> Isn’t this issue already solved by the introduction of swapAt ? 

Ah, indeed, you’re quite right: I see that SE-0173 removes the “different 
elements” precondition for swapAt().

It’s not hard to imagine analogous situations involving data structures other 
than arrays, so presumably Félix’s point still stands in principle for the 
original swap(). But I notice that SE-0173 says swap() will be deprecated & 
removed in the future?! Surprising, but well of topic: SE-0176 would allow the 
implementation of swapAt-like methods for other data structures, so no new 
concerns about this proposal as it stands.

Cheers, P

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

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Jean-Daniel via swift-evolution]

> Le 7 mai 2017 à 03:54, Paul Cantrell via swift-evolution 
>  a écrit :
> 
> 
>> On May 6, 2017, at 12:36 PM, John McCall via swift-evolution 
>> > wrote:
>> 
>> 
>>> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution 
>>> > wrote:
>>> 
>>> Concern: `swap` is quoted a lot for a method that would break under this 
>>> rule, but as it happens, `swap` with the same value on both sides is 
>>> (should be) a no-op. Is there a way to not trip the static or dynamic 
>>> checkers in well-defined cases like that one? Is there any way to check 
>>> that two inout parameters refer to the same value?
>> 
>> 
>> The only reasonable way to do this is statically, and why would you call 
>> 'swap' statically with the same l-value for both arguments?
> 
> When static analysis can determine that a swap is always a noop, I can’t see 
> any reason not to flag it as an error.
> 
> But Félix’s question was also about the runtime case. And he has a good point.
> 
> Here’s a compelling example where allowing the noop swap would make sense:
> 
> extension Array {
>   mutating func shuffle() {
> for i in indices {
>   let j = i + Int(arc4random_uniform(UInt32(count - i)))
>   swap([i], [j])
> }
>   }
> }
> 

Isn’t this issue already solved by the introduction of swapAt ? 

> In this code:
> 
> It’s necessary to allow j to sometimes equal i to get a uniform distribution 
> of random permutations.
> Static analysis can’t determine that the noop occurs sometimes but not always.
> Adding a check for i == j adds a branch condition to a tight loop. More 
> importantly, it’s easy to forget this check since static analysis won’t flag 
> it. It’s just a hidden land mine, which seems contrary to Swift’s “safety 
> first” aesthetic.
> 
> Putting all that together, it would probably be more Swift-like to have 
> swap() be safe, and if necessary add an unsafeSwap() func that fails on the 
> noop case and thus avoids the cost of the check in optimized code.
> 
> Note that the code above fails even under Swift 3, which explicitly disallows 
> swapping with a runtime check (“fatal error: swapping a location with itself 
> is not supported”). So nothing here to undermine the SE-0176; the proposal 
> isn’t introducing a problem that doesn’t already exist.
> 
> Cheers, P
> 
> 
>> John.
>> 
>>> 
 Le 2 mai 2017 à 13:07, Ben Cohen via swift-evolution 
 > a écrit :
 
 Hello Swift community,
 
 The review of SE-0176: "Enforce Exclusive Access to Memory" begins now and 
 runs through May 8, 2017.
 
 The proposal is available here:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
  
 
 Reviews are an important part of the Swift evolution process. All reviews 
 should be sent to the swift-evolution mailing list at:
 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
 or, if you would like to keep your feedback private, directly to the 
 review manager. 
 
 When replying, please try to keep the proposal link at the top of the 
 message:
 
 Proposal link:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
  
 
 Reply text
 
 Other replies
 
  
 What goes into a review?
 
 The goal of the review process is to improve the proposal under review 
 through constructive criticism and, eventually, determine the direction of 
 Swift. When writing your review, here are some questions you might want to 
 answer in your review:
 
 What is your evaluation of the proposal?
 Is the problem being addressed significant enough to warrant a change to 
 Swift?
 Does this proposal fit well with the feel and direction of Swift?
 If you have used other languages or libraries with a similar feature, how 
 do you feel that this proposal compares to those?
 How much effort did you put into your review? A glance, a quick reading, 
 or an in-depth study?
 More information about the Swift evolution process is available at:
 
 https://github.com/apple/swift-evolution/blob/master/process.md 
 
 
 Thanks,
 Ben Cohen
 Review Manager
 
 

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Paul Cantrell via swift-evolution]

> On May 6, 2017, at 12:36 PM, John McCall via swift-evolution 
> > wrote:
> 
> 
>> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution 
>> > wrote:
>> 
>> Concern: `swap` is quoted a lot for a method that would break under this 
>> rule, but as it happens, `swap` with the same value on both sides is (should 
>> be) a no-op. Is there a way to not trip the static or dynamic checkers in 
>> well-defined cases like that one? Is there any way to check that two inout 
>> parameters refer to the same value?
> 
> 
> The only reasonable way to do this is statically, and why would you call 
> 'swap' statically with the same l-value for both arguments?

When static analysis can determine that a swap is always a noop, I can’t see 
any reason not to flag it as an error.

But Félix’s question was also about the runtime case. And he has a good point.

Here’s a compelling example where allowing the noop swap would make sense:

extension Array {
  mutating func shuffle() {
for i in indices {
  let j = i + Int(arc4random_uniform(UInt32(count - i)))
  swap([i], [j])
}
  }
}

In this code:

It’s necessary to allow j to sometimes equal i to get a uniform distribution of 
random permutations.
Static analysis can’t determine that the noop occurs sometimes but not always.
Adding a check for i == j adds a branch condition to a tight loop. More 
importantly, it’s easy to forget this check since static analysis won’t flag 
it. It’s just a hidden land mine, which seems contrary to Swift’s “safety 
first” aesthetic.

Putting all that together, it would probably be more Swift-like to have swap() 
be safe, and if necessary add an unsafeSwap() func that fails on the noop case 
and thus avoids the cost of the check in optimized code.

Note that the code above fails even under Swift 3, which explicitly disallows 
swapping with a runtime check (“fatal error: swapping a location with itself is 
not supported”). So nothing here to undermine the SE-0176; the proposal isn’t 
introducing a problem that doesn’t already exist.

Cheers, P


> John.
> 
>> 
>>> Le 2 mai 2017 à 13:07, Ben Cohen via swift-evolution 
>>> > a écrit :
>>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0176: "Enforce Exclusive Access to Memory" begins now and 
>>> runs through May 8, 2017.
>>> 
>>> The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>>>  
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at:
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager. 
>>> 
>>> When replying, please try to keep the proposal link at the top of the 
>>> message:
>>> 
>>> Proposal link:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>>>  
>>> 
>>> Reply text
>>> 
>>> Other replies
>>> 
>>>  
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>> What is your evaluation of the proposal?
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>>> Does this proposal fit well with the feel and direction of Swift?
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>>> More information about the Swift evolution process is available at:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/process.md 
>>> 
>>> 
>>> Thanks,
>>> Ben Cohen
>>> Review Manager
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> 

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Félix Cloutier via swift-evolution]

I guess that the example doesn't make a lot of sense outside of collections, 
and the proposal already says that swap needs to be implemented on collections, 
but consider the Fisher-Yates shuffle:
-- To shuffle an array a of n elements (indices 0..n-1):
for i from n−1 downto 1 do
 j ← random integer such that 0 ≤ j ≤ i
 exchange a[j] and a[i]
I can come up with other contrived ways to force this into a dynamic analysis 
situation (but I am not convinced that I would ever see them in real code).

Also, I'm not too solid on how inout works, especially for properties without 
"physical storage". My understanding is that in some cases, Swift will get a 
direct pointer to what needs to be modified, and in others, it'll get a pointer 
to a temporary value and then call a setter with that temporary as the value 
argument. Does that sound right?

> Le 6 mai 2017 à 10:36, John McCall  a écrit :
> 
>> 
>> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution 
>> > wrote:
>> 
>> I have one concern and one general comment.
>> 
>> General comment: there's a switch to turn off overflow checks for 
>> performance reasons. It seems to me that this check is going to be much more 
>> expensive than an overflow check, and it's certainly not much more likely to 
>> trigger in a release build after some amount of testing, so my opinion would 
>> be that there should be a way to turn it off globally. To me, the checking 
>> is UBSan behavior more than a language feature.
> 
> -Ounchecked should disable this check, yes.  As for "UBSan" vs. language, the 
> general policy in Swift is to enforce its language rules by default, except 
> in the cases of race conditions (where it would be prohibitive) and 
> explicitly unsafe features (which are intended in part to allow things that 
> are not possible under the normal language rules).
> 
>> Concern: `swap` is quoted a lot for a method that would break under this 
>> rule, but as it happens, `swap` with the same value on both sides is (should 
>> be) a no-op. Is there a way to not trip the static or dynamic checkers in 
>> well-defined cases like that one? Is there any way to check that two inout 
>> parameters refer to the same value?
> 
> The only reasonable way to do this is statically, and why would you call 
> 'swap' statically with the same l-value for both arguments?
> 
> John.
> 
>> 
>>> Le 2 mai 2017 à 13:07, Ben Cohen via swift-evolution 
>>> > a écrit :
>>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0176: "Enforce Exclusive Access to Memory" begins now and 
>>> runs through May 8, 2017.
>>> 
>>> The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>>>  
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at:
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager. 
>>> 
>>> When replying, please try to keep the proposal link at the top of the 
>>> message:
>>> 
>>> Proposal link:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>>>  
>>> 
>>> Reply text
>>> 
>>> Other replies
>>> 
>>>  
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>> What is your evaluation of the proposal?
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>>> Does this proposal fit well with the feel and direction of Swift?
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>>> More information about the Swift evolution process is available at:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/process.md 
>>> 
>>> 
>>> Thanks,
>>> Ben Cohen
>>> Review Manager
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[John McCall via swift-evolution]

> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> I have one concern and one general comment.
> 
> General comment: there's a switch to turn off overflow checks for performance 
> reasons. It seems to me that this check is going to be much more expensive 
> than an overflow check, and it's certainly not much more likely to trigger in 
> a release build after some amount of testing, so my opinion would be that 
> there should be a way to turn it off globally. To me, the checking is UBSan 
> behavior more than a language feature.

-Ounchecked should disable this check, yes.  As for "UBSan" vs. language, the 
general policy in Swift is to enforce its language rules by default, except in 
the cases of race conditions (where it would be prohibitive) and explicitly 
unsafe features (which are intended in part to allow things that are not 
possible under the normal language rules).

> Concern: `swap` is quoted a lot for a method that would break under this 
> rule, but as it happens, `swap` with the same value on both sides is (should 
> be) a no-op. Is there a way to not trip the static or dynamic checkers in 
> well-defined cases like that one? Is there any way to check that two inout 
> parameters refer to the same value?

The only reasonable way to do this is statically, and why would you call 'swap' 
statically with the same l-value for both arguments?

John.

> 
>> Le 2 mai 2017 à 13:07, Ben Cohen via swift-evolution 
>> > a écrit :
>> 
>> Hello Swift community,
>> 
>> The review of SE-0176: "Enforce Exclusive Access to Memory" begins now and 
>> runs through May 8, 2017.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>>  
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at:
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. 
>> 
>> When replying, please try to keep the proposal link at the top of the 
>> message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>>  
>> 
>> Reply text
>> 
>> Other replies
>> 
>>  
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at:
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> 
>> Thanks,
>> Ben Cohen
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Félix Cloutier via swift-evolution]

I have one concern and one general comment.

General comment: there's a switch to turn off overflow checks for performance 
reasons. It seems to me that this check is going to be much more expensive than 
an overflow check, and it's certainly not much more likely to trigger in a 
release build after some amount of testing, so my opinion would be that there 
should be a way to turn it off globally. To me, the checking is UBSan behavior 
more than a language feature.

Concern: `swap` is quoted a lot for a method that would break under this rule, 
but as it happens, `swap` with the same value on both sides is (should be) a 
no-op. Is there a way to not trip the static or dynamic checkers in 
well-defined cases like that one? Is there any way to check that two inout 
parameters refer to the same value?

> Le 2 mai 2017 à 13:07, Ben Cohen via swift-evolution 
>  a écrit :
> 
> Hello Swift community,
> 
> The review of SE-0176: "Enforce Exclusive Access to Memory" begins now and 
> runs through May 8, 2017.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. 
> 
> When replying, please try to keep the proposal link at the top of the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>  
> 
> Reply text
> 
> Other replies
> 
>  
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thanks,
> Ben Cohen
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Xiaodi Wu via swift-evolution]

The proposal looks good in general. Like some others, my chief concerns are
around dynamic enforcement. If it's not certain to be cheap enough to be
enabled without per-member opt-out and possibly build settings to turn it
off, perhaps the way to go is to add static enforcement now and prototype
what the cost will be for dynamic enforcement before designing all of these
knobs and switches.


On Tue, May 2, 2017 at 15:08 Ben Cohen via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of SE-0176: "Enforce Exclusive Access to Memory" begins now
> and runs through May 8, 2017.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at:
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> When replying, please try to keep the proposal link at the top of the
> message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
> Reply text
>
> Other replies
>
> 
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at:
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thanks,
> Ben Cohen
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Michel Fortin via swift-evolution]

> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md

> What is your evaluation of the proposal?

It's a bit hard to evaluate without experience. But I would summarize the 
benefits like this:

1. Clearer semantics inside functions. Variables that can alias each other 
makes things hard to reason about. Generally, this we just disregard the 
possibility of this happening. Having the language guard against this is going 
to make it easier to reason about the effects of the code.

2. Better optimizations. Variable that can alias each other force the optimizer 
to be pessimistic. All that to support cases that probably weren't well though 
out when the code was written because the semantics are hard to follow.

I find the first point about clearer semantics most interesting.


> Is the problem being addressed significant enough to warrant a change to 
> Swift?

Looks like something that should be done. Swift already disallows that I think, 
but it only checks for the obvious cases.

Providing guaranties about exclusivity opens the road to a lot of useful things 
for future evolution of the language.


> Does this proposal fit well with the feel and direction of Swift?

Given that the alternative option to dynamic checking is to have a complex set 
of annotations to track everything statically, I think the proposed approach 
makes sense.

If I understand well however, allowing the optimizer to be more optimistic 
about exclusivity is going to be make memory corruption more likely in cases 
the exclusivity rule is violated for types that contain pointers. I'm thus a 
bit weary of the idea of disabling the runtime checks in production by default 
while at the same time enabling the optimizations that depends on this 
unverified exclusivity.


> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

This reminds me of `restrict` in C, which can be dangerous if used incorrectly. 
Having a checking mechanism for exclusivity removes those concerns.
https://en.wikipedia.org/wiki/Restrict


> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Read the ownership manifesto, the proposal, the discussion about the proposal.


-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[John McCall via swift-evolution]

> On May 2, 2017, at 6:44 PM, Jon Shier via swift-evolution 
>  wrote:
>   I’m not a language or memory expert, so I think the proposal could use 
> a few more examples of the code it would disallow. Perhaps examples from real 
> world projects? Without being an expert I’m having a hard time seeing the 
> full impact of the proposed rules. 

We hope that there will not be any widespread examples from real-world projects 
that run afoul of the rule.  If the examples seem a little contrived, that's 
good; we believe the rule is almost always already followed.

>   Also, the @exclusivity syntax doesn’t seem fully defined. Is there a 
> @exclusivity(checked) counterpart?

Yes, which would be the default (on class properties and global variables).

> Would subclasses be allowed to mark inherited properties more or less 
> strictly?

No.  The rule has to be established by the place which creates the storage.

> Also, is the logic for @ attributes and keyword attributes documented 
> anywhere? Otherwise it seems like exclusive / nonexclusive would be an option.

The guidelines about when to use an @ attribute and when to use a keyword 
attribute are always a bit uncertain, but in this case I think they clearly 
point us towards an @ attribute.  This is an attribute which opts in to unsafe 
behavior for performance reasons; it is not expected to be important enough to 
warrant a keyword.

John.

> 
> 
> 
> Jon
> 
>> On May 2, 2017, at 4:07 PM, Ben Cohen via swift-evolution 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0176: "Enforce Exclusive Access to Memory" begins now and 
>> runs through May 8, 2017.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>>  
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at:
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. 
>> 
>> When replying, please try to keep the proposal link at the top of the 
>> message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>>  
>> 
>> Reply text
>> 
>> Other replies
>> 
>>  
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at:
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> 
>> Thanks,
>> Ben Cohen
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[Jon Shier via swift-evolution]

I’m not a language or memory expert, so I think the proposal could use 
a few more examples of the code it would disallow. Perhaps examples from real 
world projects? Without being an expert I’m having a hard time seeing the full 
impact of the proposed rules. 
Also, the @exclusivity syntax doesn’t seem fully defined. Is there a 
@exclusivity(checked) counterpart? Would subclasses be allowed to mark 
inherited properties more or less strictly? Also, is the logic for @ attributes 
and keyword attributes documented anywhere? Otherwise it seems like exclusive / 
nonexclusive would be an option.



Jon

> On May 2, 2017, at 4:07 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0176: "Enforce Exclusive Access to Memory" begins now and 
> runs through May 8, 2017.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. 
> 
> When replying, please try to keep the proposal link at the top of the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>  
> 
> Reply text
> 
> Other replies
> 
>  
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thanks,
> Ben Cohen
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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