<div dir="ltr">On Tue, Jan 16, 2018 at 5:39 PM, Rick Mann <span dir="ltr"><<a href="mailto:rmann@latencyzero.com" target="_blank">rmann@latencyzero.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Jan 16, 2018, at 15:32 , Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> On Jan 16, 2018, at 14:30 , Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> 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:<br>
<span class="">>><br>
>> func moles <T: FloatingPoint> (particles: T) -> T {<br>
>> let avogadroNumber: T = 6_022_140_857 * 100_000_000_000_000<br>
>> return particles / avogadroNumber<br>
>> }<br>
>><br>
>> It would be much nicer to write “let avogadroNumber: T = 6.022140857e23”.<br>
>><br>
><br>
> You could write:<br>
><br>
> func moles<T : FloatingPoint & LosslessStringConvertible>(<wbr>particles: T) -> T {<br>
> let N_A = T("6.02214085774e+23")!<br>
> return particles / N_A<br>
> }<br>
<br>
</span>You're not seriously proposing this alternative, are you? I'm with Nevin on this: “let avogadroNumber: T = 6.022140857e23”.<br></blockquote><div><br></div><div>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).</div><div><br></div></div></div></div>