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.
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).
/Jens
On Sat, Aug 27, 2016 at 1:15 AM, Jens Persson <j...@bitcycle.com> wrote:
> Reason for asking is that I have this:
>
> extension Double {
> init(unitRangeFromRawSignificand s: RawSignificand) {
> let bitPattern = s | (1023 << 52)
> self = unsafeBitCast(bitPattern, to: Double.self) - 1.0
> }
> }
> extension Float {
> init(unitRangeFromRawSignificand s: RawSignificand) {
> let bitPattern = s | (127 << 23)
> self = unsafeBitCast(bitPattern, to: Float.self) - 1.0
> }
> }
>
> But they would be better as:
> extension BinaryFloatingPoint {
> init(unitRangeFromRawSignificand s: RawSignificand) {
> ... problems here, have to try casting things into
> RawSignificand's type ...
> }
> }
>
> 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.)
>
> /Jens
>
>
> On Sat, Aug 27, 2016 at 1:02 AM, Stephen Canon <sca...@apple.com> wrote:
>
>> > On Aug 26, 2016, at 6:06 PM, Jens Persson via swift-dev <
>> swift-dev@swift.org> wrote:
>> >
>> > I can understand why
>> > Double.RawSignificand is UInt64
>> > and
>> > Float.RawSignificand is UInt32
>> >
>> > But I can't understand why both
>> > Double.RawExponent
>> > and
>> > Float.RawExponent
>> > should be UInt.
>> >
>> > Why aren't they also just UInt64 and UInt32, resp.?
>>
>> 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).
>>
>> – Steve
>
>
>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
