> On Oct 5, 2017, at 20:28, John McCall <rjmcc...@apple.com> wrote: > > >> On Oct 5, 2017, at 6:34 PM, Jordan Rose via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> 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. > > 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 >> swift-dev@swift.org <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
