<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 Aug 19, 2016, at 2:04 PM, Jordan Rose 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=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">We have an old Radar about this, <a href="rdar://problem/16754935" class="">rdar://problem/16754935</a>. It's probably just a case we're missing in enum layout. My guess is that it's because we don't have a whole spare bit in a RawPointer, but we should be able to pick some up either from alignment or from ABI knowledge.</div><div class=""><br class=""></div><div class="">Jordan</div></div></div></blockquote><div><br class=""></div><div>Hi Jordan,</div><div><br class=""></div><div>I asked about a related issue, which is that RawPointer only has 1 extra inhabitant instead of 4096. You guys said you wanted non-zero integers to round-trip through RawPointer. It seems that declaring the high bits of a RawPointer as spare bits would cause the same problem as allowing more extra inhabitants.</div><div><br class=""></div><div>Also I don’t think alignment is the answer here, RawPointer should be able to represent a char *, where you have no low spare bits.</div><div><br class=""></div><div>Slava</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 19, 2016, at 13:30, Ole Begemann 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="">The Character type is essentially defined like this [1]:<br class=""><br class="">struct Character {<br class=""> enum Representation {<br class=""> // A _StringBuffer whose first grapheme cluster is self.<br class=""> // NOTE: may be more than 1 Character long.<br class=""> case large(_StringBuffer._Storage)<br class=""> case small(Builtin.Int63)<br class=""> }<br class=""><br class=""> var _representation: Representation<br class="">}<br class=""><br class="">Note the type of the associated value for `case .small`, `Builtin.Int63`. Presumably, this is so that the type fits into a single word, including the single bit that is needed for the enum case.<br class=""><br class="">However, `MemoryLayout<Character>.size` returns 9. Given the above, I would have expected 8 bytes.<br class=""><br class="">Why? Is this a potential optimization that hasn't been implemented? Or am I missing something?<br class=""><br class="">Thanks<br class="">Ole<br class=""><br class="">[1]: <a href="https://github.com/apple/swift/blob/master/stdlib/public/core/Character.swift" class="">https://github.com/apple/swift/blob/master/stdlib/public/core/Character.swift</a><br class="">_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a><br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></body></html>