[swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

[Xiaodi Wu]

On Tue, Jan 16, 2018 at 5:39 PM, Rick Mann <rmann at latencyzero.com> wrote:

>
>
> > On Jan 16, 2018, at 15:32 , Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > On Jan 16, 2018, at 14:30 , Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> That only works for numbers which don’t overflow the integer literals
> though. If we want a really large or small value then we have to split it
> in pieces:
> >>
> >> func moles <T: FloatingPoint> (particles: T) -> T {
> >>     let avogadroNumber: T = 6_022_140_857 * 100_000_000_000_000
> >>     return particles / avogadroNumber
> >> }
> >>
> >> It would be much nicer to write “let avogadroNumber: T =
> 6.022140857e23”.
> >>
> >
> > You could write:
> >
> > func moles<T : FloatingPoint & LosslessStringConvertible>(particles: T)
> -> T {
> >   let N_A = T("6.02214085774e+23")!
> >   return particles / N_A
> > }
>
> You're not seriously proposing this alternative, are you? I'm with Nevin
> on this: “let avogadroNumber: T = 6.022140857e23”.
>

I'm quite serious. You'll recall above that I mentioned one possible design
for an alternative protocol is one that initializes via a string
representation of the literal. The alternative given above uses the same
functionality in a spelling that's already available. All binary
floating-point types already do support converting from a string, and any
future IEEE-compliant decimal floating-point type will necessarily have the
logic that supports it. This alternative allows Nevin to use scientific
notation as he desires, and it allows him to write generic algorithms
constrained to FloatingPoint (which, still, I don't understand why; that
protocol makes very few useful guarantees and there isn't much you can do
with it in practice--we may in fact be better off getting rid of it
altogether; in the meantime, one simple improvement would be to make
FloatingPoint refine LosslessStringConvertible, as some integer protocols
now do).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180116/36d90e4a/attachment.html>