[swift-evolution] SE-184 Improved Pointers

[Taylor Swift]

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 <kelvin13ma at gmail.com> wrote:

>
>
> 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/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.)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170821/1912d833/attachment.html>