On Mon, Aug 21, 2017 at 6:11 PM, Michael Ilseman <[email protected]> wrote:
> > On Aug 21, 2017, at 2:07 PM, Andrew Trick via swift-evolution < > [email protected]> wrote: > > > On Aug 20, 2017, at 6:03 PM, Taylor Swift <[email protected]> wrote: > > New draft of the proposal is up here: <https://github.com/kelvin13/ > swift-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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
