<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 22, 2016, at 12:58, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Jun 22, 2016, at 11:20 AM, Timothy J. Wood via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class="">Currently, APIs that get imported with COpaquePointer make Swift *less* safe than C. Fixing this seems like a breaking change, since it would change the meaning of existing code that uses COpaquePointer.<span class="Apple-converted-space"> </span><br class=""><br class="">As a motivating example consider:<br class=""><br class="">import Darwin<br class=""><br class="">var state = copyfile_state_alloc()<br class="">print("state = \(state.dynamicType) \(state)")<br class=""><br class="">let acl = acl_init(1)<br class="">print("acl = \(acl.dynamicType) \(acl)")<br class=""><br class="">state = acl<br class="">print("state = \(state.dynamicType) \(state)")<br class=""><br class="">I’m just using these types since they use opaque structs and are easy to create in this sample, but this pattern is fairly common in other C APIs that try to encapsulate their implementation.<br class=""><br class="">This compiles and builds, silently accepting the bogus code:<br class=""><br class="">DEVELOPER_DIR=/Applications/Xcode-8.0b1.app/Contents/Developer swift c-unsafety.swift<br class="">state = Optional<OpaquePointer> Optional(0x00007f9db481b3d0)<br class="">acl = Optional<OpaquePointer> Optional(0x00007f9db2944c00)<br class="">state = Optional<OpaquePointer> Optional(0x00007f9db2944c00)<br class=""><br class="">The equivalent C version:<br class=""><br class="">copyfile_state_t state = state = copyfile_state_alloc();<br class="">acl_t acl = acl_init(1);<br class="">state = acl;<br class=""><br class="">produces a warning:<br class=""><br class="">c-unsafety.c:10:8: warning: incompatible pointer types assigning to 'copyfile_state_t' (aka 'struct _copyfile_state *') from 'acl_t' (aka 'struct _acl *')<br class=""><br class=""><br class="">Would it be feasible to import these sorts of pointers in a safe(r) way by making COpaquePointer generic and faking up a struct tag type? So, these might get imported with something equivalent to:<br class=""><br class="">struct _acl {}<br class="">typealias acl_t = COpaquePointer<_acl><br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">We should be able to synthesize opaque types as structs with inaccessible initializers, and use the existing UnsafePointer types. That would work better in situations where you have some modules that can see the implementation of '_acl', and some that can’t.</span></div></blockquote><br class=""></div><div>Right. The concern we’ve had here is that you’ll start off with an opaque struct and then import something else that <i class="">does</i> have the definition. I think this only comes up in the REPL, though, and maybe it’s rare enough that we could just ignore it or disallow using the type as a value in that case.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>