> 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 <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution >>> <swift-evolution@swift.org <mailto: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(&self[i], &self[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 >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>>> >>>> <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 >>>> <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 >>>> >>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md> >>>> Reply text >>>> >>>> Other replies >>>> >>>> <https://github.com/apple/swift-evolution#what-goes-into-a-review-1> >>>> 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 >>>> <https://github.com/apple/swift-evolution/blob/master/process.md> >>>> >>>> Thanks, >>>> Ben Cohen >>>> Review Manager >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
