<div dir="ltr">Oh, to more directly answer your question: I don't like having to create a UInt (UInt64) value when all my bit manipulaton code happens in UInt32 (for Float) for example.<div><br></div><div>The most probable context for using these computed properties and types of BinaryFloatingPoint is one in which specific fixed width types really matters a lot (look at the name of the protocol and the properties and assocated types we are talking about).</div><div><br></div><div>/Jens</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 27, 2016 at 1:15 AM, Jens Persson <span dir="ltr"><<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Reason for asking is that I have this:<div><br><div><div>extension Double {</div><div> init(<wbr>unitRangeFromRawSignificand s: RawSignificand) {</div><div> let bitPattern = s | (1023 << 52)</div><div> self = unsafeBitCast(bitPattern, to: Double.self) - 1.0</div><div> }</div><div>}</div><div>extension Float {</div><div> init(<wbr>unitRangeFromRawSignificand s: RawSignificand) {</div><div> let bitPattern = s | (127 << 23)</div><div> self = unsafeBitCast(bitPattern, to: Float.self) - 1.0</div><div> }</div><div>}</div></div><div><br></div><div>But they would be better as:</div><div>extension BinaryFloatingPoint {</div><div> init(<wbr>unitRangeFromRawSignificand s: RawSignificand) {</div><div> ... problems here, have to try casting things into RawSignificand's type ...</div><div> }</div><div>}</div><div><br></div></div><div>Please have a go at that and perhaps you see what I mean or you will come up with a nice solution that I have missed. (Speed is very important btw.)</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>/Jens</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 27, 2016 at 1:02 AM, Stephen Canon <span dir="ltr"><<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> On Aug 26, 2016, at 6:06 PM, Jens Persson via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<br>
><br>
> I can understand why<br>
> Double.RawSignificand is UInt64<br>
> and<br>
> Float.RawSignificand is UInt32<br>
><br>
> But I can't understand why both<br>
> Double.RawExponent<br>
> and<br>
> Float.RawExponent<br>
> should be UInt.<br>
><br>
> Why aren't they also just UInt64 and UInt32, resp.?<br>
<br>
</span>Let me flip the question: why would they be UInt64 and UInt32? Absent a reason to prefer a specific fixed-with type, Swift integers should generally default to being [U]Int (and ideally Int, but RawExponent is Unsigned).<br>
<br>
– Steve</blockquote></div><br></div>
</div></div></blockquote></div><br></div>