<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 5, 2017, at 15:23, David Zarzycki <<a href="mailto:dave@znu.io" class="">dave@znu.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline"><br class=""><blockquote type="cite" class=""><div class="">On Oct 5, 2017, at 18:08, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 5, 2017, at 13:42, David Zarzycki via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello,<br class=""><br class="">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?<br class=""></div></div></blockquote></div><br class=""><div class="">It's worth noting that this is impossible in the general case:</div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;">// Library.swift</blockquote><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">public class Foo {</div><div class=""> public var x: Int = 0</div><div class=""> public init() {}</div><div class="">}</div><div class="">public func testExclusivity(_ a: Foo, _ b: Foo, by callback: (inout Int, inout Int) -> Void) {</div><div class=""> callback(&a.x, &b.x)</div><div class="">}</div></blockquote><br class=""><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">// Client.swift, compiled as a separate target</div><div class="">let foo = Foo()</div><div class="">testExclusivity(foo, foo) { $0 = 42; $1 = 8192 }</div></blockquote><div class=""><br class=""></div>That doesn't necessarily mean there aren't improvements to be made, but it might change your goals.</div></div></blockquote></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Hi Jordan,</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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?</div></div></blockquote><div><br class=""></div><div>The former, really. Classes are just the most convenient way to get coincidental aliasing.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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?</div></blockquote><br class=""></div><div>"If we set aside resiliency" isn't something that works today. Local builds don't actually have access to the SIL of <i class="">any</i> of their dependencies at the moment (for a handful of reasons). Opaque code really does have to be treated as opaque.</div><div><br class=""></div><div>(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.)</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>