ps the implementation in pr 11464 <https://github.com/apple/swift/pull/11464> has been updated with documentation comments and changes in the latest version of the proposal
On Mon, Aug 21, 2017 at 9:19 PM, Taylor Swift <kelvin1...@gmail.com> wrote: > > > On Mon, Aug 21, 2017 at 6:11 PM, Michael Ilseman <milse...@apple.com> > wrote: > >> >> On Aug 21, 2017, at 2:07 PM, Andrew Trick via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> On Aug 20, 2017, at 6:03 PM, Taylor Swift <kelvin1...@gmail.com> wrote: >> >> New draft of the proposal is up here: <https://github.com/kelvin13/s >> wift-evolution/blob/patch-3/proposals/0184-improved-pointers.md> >> >> Important changes start here >> <https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md#proposed-solution> >> . >> >> >> This should be brought to the attention of swift-evolution: >> >> The old `deallocate(capacity:)` method should be marked >> as `unavailable` since it currently encourages dangerously incorrect code. >> This avoids misleading future users, forces current users to address this >> potentially catastrophic memory bug, and leaves the possibility open for us >> to add a `deallocate(capacity:)` method in the future, or perhaps even >> a `reallocate(toCapacity:)` method. >> >> >> I can’t defend breaking existing source without having seen real code >> that was actually written incorrectly. I don’t see the downside of using >> the same deprecation strategy as the other changes. I expect code that was >> already written to be correct and future code to not call the deprecated >> API. >> >> >> It would have to be deprecated in Swift 4 mode. For beyond-4 mode, are >> you arguing it should remain deprecated or can it become obsoleted? >> > > I mean I just thought that it would be best to get rid of this as quickly > and harshly as possible because a lot of people might think their code was > correct when in fact it wasn’t (the example in the document is biased to > segfault but if the lengths are smaller, a segfault might not occur, even > though invalid access is still being done.) > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution