<div dir="ltr">On Mon, Jan 15, 2018 at 20:37 Nevin Brackett-Rozinsky &lt;<a href="mailto:nevin.brackettrozinsky@gmail.com" target="_blank">nevin.brackettrozinsky@gmail.<wbr>com</a>&gt; wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 15, 2018 at 8:51 PM, Xiaodi Wu <span>&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><span>On Mon, Jan 15, 2018 at 19:20 Nevin Brackett-Rozinsky &lt;<a href="mailto:nevin.brackettrozinsky@gmail.com" target="_blank">nevin.brackettrozinsky@gmail.<wbr>com</a>&gt; wrote:<br></span><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div>All I’m saying is the current situation seems semantically wrong. As in, how can a type claim to be a floating point number, if it *literally* cannot be represented by a floating point number?</div></div></blockquote><div dir="auto"><br></div></span><div dir="auto">Again, you can think of it that way, but what I’m saying is that “FloatLiteral” is a misnomer: semantically, a conforming type is specifically claiming that it is expressible by a _binary_ floating point number.</div></div></div></blockquote><div><br></div></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div> I strongly disagree. To say that it is a “misnomer” implies that the semantics are correct and the problem is with the name.</div><div><br></div><div>However, in Swift a floating point literal consists of certain patterns of characters in source code, as specified by the language grammar. Thus it is meaningful and correct to say that certain types can be expressed as floating point literals. We have a protocol for exactly that purpose: to indicate that conforming types can be written as floating point literals.</div><div></div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">I understand that you disagree with the current semantics, but they aren&#39;t arbitrary. You know, I’m sure, that we can write integer literals in any of several bases. For example, `0xffff` is an integer literal which represents the same value as `65535`:</div><div dir="auto"><br></div><div>  0xffff == 65535 // true</div><div><br></div><div dir="auto">It doesn’t matter in which base you write the literal, it represents some particular _binary integer_ up to a maximum of 2048 (binary) digits.</div><div dir="auto"><br></div><div>Likewise, we can write floating-point literals in any of several bases. For example:</div><div><br></div><div>  0x1.5bf0a8b145769p1 == 2.7182818284590451 // true</div><div><br></div><div>It doesn&#39;t matter in which base you write the literal, it represents some particular _binary floating-point value_ up to a maximum of 63 or 52 fractional bits, depending on the platform.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_extra" dir="auto"><div class="gmail_quote"><div>That protocol is spelled ExpressibleByFloatLiteral, which reflects the meaning that we want and should have. The name is correct, the problem is with the implementation.</div></div></div></blockquote><div><br></div><div>I get that you want float literals to have semantics other than what they have. Again, that&#39;s a different conversation. I&#39;m simply explaining that the current semantics are not by accident, and that the implementation isn&#39;t a buggy execution of the semantics you think they should have, but an exact execution of semantics you may not agree with but nonetheless deliberately chosen.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_extra" dir="auto"><div class="gmail_quote"><div>If you want to argue that, after we fix the buggy implementation of ExpressibleByFloatLiteral, then we should introduce a new protocol named ExpressibleByBinaryFloatLitera<wbr>l, that might be a discussion worth having. But for the existing protocol, renaming it would not solve the underlying issue.</div></div></div></blockquote></div></div>