<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">First, a general +1 to these, thanks for proposing them.<div class=""><br class=""></div><div class="">In SE-0067 we spelled these “exactly” rather than “exact”.</div><div class=""><pre style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; padding: 16px; overflow: auto; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-wrap: normal; word-break: normal; color: rgb(51, 51, 51);" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">init</span>?<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);"><</span>Source: Integer<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">></span>(exactly value: Source)</pre><div class=""><br class=""></div></div><div class="">As for –0, Int(exactly: -0.0) should *not* fail. My rationale for this is as follows:</div><div class=""><br class=""></div><div class="">- While information (the signbit) is lost, the essential property is that `Double(Int(exactly: -0.0)) == -0.0`.</div><div class="">- If we instead adopted “no information loss” as a criteria, we would back ourselves into a corner w.r.t decimal floating-point types, which have multiple representations of most values (1.0 can be encoded as 1e0 or 10e-1 or 100e-2 …). The result would be that these initializers would always fail for decimal fp inputs.</div><div class=""><br class=""></div><div class="">– Steve</div></body></html>