> On Nov 2, 2016, at 15:50, Dave Abrahams via swift-users
> <swift-users@swift.org> wrote:
>
>
> on Wed Nov 02 2016, Andrew Trick <atrick-AT-apple.com
> <http://atrick-at-apple.com/>> wrote:
>
>>> On Nov 2, 2016, at 12:58 PM, Dave Abrahams via swift-users
>>> <swift-users@swift.org> wrote:
>>>
>>>> At the top of the migration guide is a link to the memory model
>>>> explanation:
>>>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#memory-model-explanation
>>>>
>>
>>>> "A memory location's bound type is an abstract, dynamic property of the
>>>> memory used to formalize
>>>> type safety.”
>>>>
>>>> I’m not sure I like the “prepares the memory” language myself. Binding
>>>> memory communicates to the compiler that the memory locations are safe
>>>> for typed access. Nothing happens at runtime--until someone writes a
>>>> type safety sanitizer.
>>>
>>> Well, that's a slight overstatement IMO. Sanitizers aside, the main
>>> reason for these binding operations is that if you leave them out,
>>> something different *will* happen at runtime... something that will make
>>> your code do the wrong thing.
>>>
>>> What I would say is that binding the memory has no immediate runtime
>>> cost... but it's absolutely required if you want your program to behave
>>> (and sometimes behaving correctly is a little slower than misbehaving).
>>
>> Good clarification. I really did not mean to imply that binding memory
>> to a type has no effect on runtime behavior. Taken out of context,
>> “nothing happens at runtime” is quite an understatement.
>>
>> The original poster seemed to have the impression that the operation
>> of binding memory itself might affect program state,
>
> Formally speaking, it does!
>
>> independent of any compiler optimization. I want to make it clear that
>> a call to bindMemory(to:capacity:) has no observable runtime side
>> effects at the point of the call.
>
> Only because you can't observe what memory is bound to.
>
>> But I need to throw in an exemption for future sanitizers.
>
> I don't think you do; sanitizer actions are allowed under undefined
> behavior.
I think the difference here is that sanitizers affect program characteristics
even for correct programs. Introducing a sanitizer can reduce optimization
opportunities, changing an algorithm’s complexity. And of course, there’s
always a bit of bookkeeping code being executed that wouldn’t be there
otherwise.
Jordan
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
