[swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

Tim Hawkins tim.thawkins at gmail.com
Tue Apr 19 19:50:35 CDT 2016


"NaN" with the shown capitalisation is the standard way of showing this
constant in every other language that I know of, changing it to "Nan" would
cause confusion and risks people not recognising it for what it is.  The
form is reasonable given that it is the acronym for "Not a Number".
On Apr 20, 2016 6:12 AM, "Daniel Vollmer via swift-evolution" <
swift-evolution at swift.org> wrote:

>
> > On 19 Apr 2016, at 23:16, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Hello Swift community,
> >
> > The review of "SE-0067: Enhanced Floating Point Protocols" begins now
> and runs through April 25. The proposal is available here:
> >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md
>
> This looks pretty nice, but I have to admit I’m unaware of pretty much
> anything about the current floating-point protocols.
>
> A question, if I may:
> > /// A signalling NaN (not-a-number).
> > @warn_unused_result
> > static fun signalingNaN: Self { get }
>
> Why is this a static func compared to a static var for nan? Representation
> only known at run-time? Why is the second N in NaN capitalised?
>
>         Daniel.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160420/56f5caea/attachment.html>


More information about the swift-evolution mailing list