[swift-dev] Exclusivity checker hacking?

[David Zarzycki]

> On Oct 5, 2017, at 18:08, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
> 
>> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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?

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?

Thanks,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171005/cbea73b4/attachment.html>