[swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

[Dave Abrahams]

on Fri Nov 18 2016, Karl <razielim-AT-gmail.com> wrote:

>> On 16 Nov 2016, at 18:06, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> 
>>> On Nov 12, 2016, at 4:19 PM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>
>>> 
>>>> On Nov 10, 2016, at 12:39 PM, Stephen Canon via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>>> On Nov 10, 2016, at 1:30 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> What worries me is that if systems programmers are trying to get static
>>>>> guarantees that there's no ARC traffic, they won't be willing to handle
>>>>> a copyable thing that carries ownership.
>>>> 
>>>> FWIW, we (frequently) only need a static guarantee of no ARC
>>>> traffic *within a critical section*. If we can guarantee that
>>>> whatever ARC operations need to be done happen in a
>>>> precisely-controlled manner at a known interface boundary, that’s
>>>> often good enough.
>>> 
>>> “Critical section” is a phrase I normally associate with multi-threaded code… Do we need to start talking about concurrency to move this topic forward?
>> 
>> In a sense, yeah, ARC traffic is concurrent to the
>> explicitly-written behavior of the program, since the compiler does
>> not make strong guarantees about when exactly retains and releases
>> occur. Releases in particular can trigger arbitrary code execution
>> through deinitializers. The analogy to a critical section for not
>> wanting an arbitrary deinitializer to run within a region seems apt.
>> 
>> -Joe
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> This seems similar to the reasoning for _fixLifetime, isn’t it?
> (there’s no documentation about what _fixLifetime does or when you
> need it, but when I use it it’s to basically create a barrier, before
> which deinitialisers aren’t allowed to run)

You never need it; things beginning with underscores are not for public
consumption and only exposed publicly for internal reasons (e.g. for
testing because the standard library can't use @testable).  The public
facility is called withExtendedLifetime.

HTH,

-- 
-Dave