> On Oct 5, 2017, at 18:08, Jordan Rose <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?
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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
