> On Oct 5, 2017, at 20:28, John McCall <[email protected]> wrote: > > >> On Oct 5, 2017, at 6:34 PM, Jordan Rose via swift-dev <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >>> On Oct 5, 2017, at 15:23, David Zarzycki <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>> >>> >>>> On Oct 5, 2017, at 18:08, Jordan Rose <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>>> On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev >>>>> <[email protected] <mailto:[email protected]>> 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. > > The important point here is that the "conservatively emit static errors for > every exclusivity check we can't resolve statically" rule is basically > equivalent to "disallow mutable class properties", because we do not have any > language support for the sort of unique-right-to-access rules that would be > necessary to ever resolve any of those statically.
Thanks John! > > John. > > >> >> >>> 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.) >> >> Jordan >> >> _______________________________________________ >> swift-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-dev >
_______________________________________________ swift-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-dev
