> On Oct 5, 2017, at 18:34, Jordan Rose <jordan_r...@apple.com> wrote:
>
>
>
>> On Oct 5, 2017, at 15:23, David Zarzycki <d...@znu.io <mailto:d...@znu.io>>
>> wrote:
>>
>>
>>
>>> On Oct 5, 2017, at 18:08, Jordan Rose <jordan_r...@apple.com
>>> <mailto:jordan_r...@apple.com>> wrote:
>>>
>>>
>>>
>>>> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev
>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> As an experiment, I’d like to force the exclusivity checking logic to
>>>> always error at compile time, rather than a mix of compile time and run
>>>> time. Near as I can tell, there is no built in debugging logic to do this
>>>> (not even to warn when dynamic checks are added). Am I missing something?
>>>> Where would be the best place in the code to make the dynamic checker
>>>> error/warning at compile time? Would a warning be useful to others? Or
>>>> should I just keep this on a throwaway branch?
>>>
>>> It's worth noting that this is impossible in the general case:
>>>
>>> // Library.swift
>>> public class Foo {
>>> public var x: Int = 0
>>> public init() {}
>>> }
>>> public func testExclusivity(_ a: Foo, _ b: Foo, by callback: (inout Int,
>>> inout Int) -> Void) {
>>> callback(&a.x, &b.x)
>>> }
>>>
>>> // Client.swift, compiled as a separate target
>>> let foo = Foo()
>>> testExclusivity(foo, foo) { $0 = 42; $1 = 8192 }
>>>
>>> That doesn't necessarily mean there aren't improvements to be made, but it
>>> might change your goals.
>>
>>
>> Hi Jordan,
>>
>> Thanks for writing the above code. Just to be clear, are you pointing out
>> that exclusivity checking through opaque code (like a library) is
>> problematic? Or that classes introduce their own aliasing challenges? Or
>> both? Or something else entirely?
>
> The former, really. Classes are just the most convenient way to get
> coincidental aliasing.
>
>
>> If we set aside resiliency for a second, couldn't the exclusivity checker
>> dynamically crash in the above scenario if two or more InOutExprs end up
>> resolving to the same address? If not, then why not?
>
> "If we set aside resiliency" isn't something that works today. Local builds
> don't actually have access to the SIL of any of their dependencies at the
> moment (for a handful of reasons). Opaque code really does have to be treated
> as opaque.
>
> (If this isn't convincing, then consider 'a' and 'b' coming directly from
> Objective-C code, where there's no exclusivity checking logic at all.)
Right, that make sense.
Let’s step back for a second. How comprehensive is the exclusivity checker
within a single/pure Swift module? As long as external modules aren’t involed,
is the model exhaustive? Or can some scenarios slip through both the static and
dynamic checking? (Again, just within a single pure Swift module.)
This has been very helpful. Thanks,
Dave
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
