<p dir="ltr">"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". </p>
<div class="gmail_quote">On Apr 20, 2016 6:12 AM, "Daniel Vollmer via swift-evolution" <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 19 Apr 2016, at 23:16, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Hello Swift community,<br>
><br>
> The review of "SE-0067: Enhanced Floating Point Protocols" begins now and runs through April 25. The proposal is available here:<br>
><br>
> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md</a><br>
<br>
This looks pretty nice, but I have to admit I’m unaware of pretty much anything about the current floating-point protocols.<br>
<br>
A question, if I may:<br>
> /// A signalling NaN (not-a-number).<br>
> @warn_unused_result<br>
> static fun signalingNaN: Self { get }<br>
<br>
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?<br>
<br>
Daniel.<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>