[swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral
Nevin Brackett-Rozinsky
nevin.brackettrozinsky at gmail.com
Mon Jan 15 20:37:08 CST 2018
On Mon, Jan 15, 2018 at 8:51 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> On Mon, Jan 15, 2018 at 19:20 Nevin Brackett-Rozinsky <
> nevin.brackettrozinsky at gmail.com> wrote:
>
>> 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?
>>
>
> 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.
>
I strongly disagree. To say that it is a “misnomer” implies that the
semantics are correct and the problem is with the name.
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.
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.
If you want to argue that, after we fix the buggy implementation of
ExpressibleByFloatLiteral, then we should introduce a new protocol named
ExpressibleByBinaryFloatLiteral, that might be a discussion worth having.
But for the existing protocol, renaming it would not solve the underlying
issue.
Nevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180115/4d534aca/attachment.html>
More information about the swift-evolution
mailing list