[swift-evolution] SE-184 Improved Pointers

[Taylor Swift]

On Mon, Aug 21, 2017 at 6:11 PM, Michael Ilseman <milseman at apple.com> wrote:

>
> On Aug 21, 2017, at 2:07 PM, Andrew Trick via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Aug 20, 2017, at 6:03 PM, Taylor Swift <kelvin13ma at gmail.com> 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170821/8223c664/attachment.html>