<div dir="ltr">This would be an excellent solution to the issue.<div>Do you know if there are any existing plans for something like the DecimalLiteralConvertible?</div><div><br></div><div>Another thought:</div><div>Would it make sense to have the compiler warn about float literal precision issues?</div><div>Initialization of two different variables with the exact same literal value could yield different precision results if one had a FloatLiteralType aliased to Float80 and the other aliased to Float.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, May 6, 2016 at 6:46 PM Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 6, 2016, at 9:42 AM, Stephen Canon <<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>> wrote:<br>
><br>
><br>
>> On May 6, 2016, at 12:41 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>>><br>
>>> On May 6, 2016, at 2:24 AM, Morten Bek Ditlevsen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>> Currently, in order to conform to FloatLiteralConvertible you need to implement<br>
>>> an initializer accepting a floatLiteral of the typealias: FloatLiteralType.<br>
>>> However, this typealias can only be Double, Float, Float80 and other built-in<br>
>>> floating point types (to be honest, I do not know the exact limitation since I have<br>
>>> not been able to read find this in the documentation).<br>
>>><br>
>>> These floating point types have precision limitations that are not necessarily<br>
>>> present in the type that you are making FloatLiteralConvertible.<br>
>>><br>
>>> Let’s imagine a CurrencyAmount type that uses an NSDecimalNumber as the<br>
>>> representation of the value:<br>
>>><br>
>>><br>
>>> public struct CurrencyAmount {<br>
>>> public let value: NSDecimalNumber<br>
>>> // .. other important currency-related stuff ..<br>
>>> }<br>
>>><br>
>>> extension CurrencyAmount: FloatLiteralConvertible {<br>
>>> public typealias FloatLiteralType = Double<br>
>>><br>
>>> public init(floatLiteral amount: FloatLiteralType) {<br>
>>> print(amount.debugDescription)<br>
>>> value = NSDecimalNumber(double: amount)<br>
>>> }<br>
>>> }<br>
>>><br>
>>> let a: CurrencyAmount = 99.99<br>
>>><br>
>>><br>
>>> The printed value inside the initializer is 99.989999999999995 - so the value<br>
>>> has lost precision already in the intermediary Double representation.<br>
>>><br>
>>> I know that there is also an issue with the NSDecimalNumber double initializer,<br>
>>> but this is not the issue that we are seeing here.<br>
>>><br>
>>><br>
>>> One suggestion for a solution to this issue would be to allow the<br>
>>> FloatLiteralType to be aliased to a String. In this case the compiler should<br>
>>> parse the float literal token: 99.99 to a String and use that as input for the<br>
>>> FloatLiteralConvertible initializer.<br>
>>><br>
>>> This would mean that arbitrary literal precisions are allowed for<br>
>>> FloatLiteralConvertibles that implement their own parsing of a String value.<br>
>>><br>
>>> For instance, if the CurrencyAmount used a FloatLiteralType aliased to String we<br>
>>> would have:<br>
>>><br>
>>> extension CurrencyAmount: FloatLiteralConvertible {<br>
>>> public typealias FloatLiteralType = String<br>
>>><br>
>>> public init(floatLiteral amount: FloatLiteralType) {<br>
>>> value = NSDecimalNumber(string: amount)<br>
>>> }<br>
>>> }<br>
>>><br>
>>> and the precision would be the same as creating an NSDecimalNumber from a<br>
>>> String:<br>
>>><br>
>>> let a: CurrencyAmount = 1.00000000000000000000000000000000001<br>
>>><br>
>>> print(a.value.debugDescription)<br>
>>><br>
>>> Would give: 1.00000000000000000000000000000000001<br>
>>><br>
>>><br>
>>> How does that sound? Is it completely irrational to allow the use of Strings as<br>
>>> the intermediary representation of float literals?<br>
>>> I think that it makes good sense, since it allows for arbitrary precision.<br>
>>><br>
>>> Please let me know what you think.<br>
>><br>
>> Like Dmitri said, a String is not a particularly efficient intermediate representation. For common machine numeric types, we want it to be straightforward for the compiler to constant-fold literals down to constants in the resulting binary. For floating-point literals, I think we could achieve this by changing the protocol to "deconstruct" the literal value into integer significand and exponent, something like this:<br>
>><br>
>> // A type that can be initialized from a decimal literal such as<br>
>> // `1.1` or `2.3e5`.<br>
>> protocol DecimalLiteralConvertible {<br>
>> // The integer type used to represent the significand and exponent of the value.<br>
>> typealias Component: IntegerLiteralConvertible<br>
>><br>
>> // Construct a value equal to `decimalSignificand * 10**decimalExponent`.<br>
>> init(decimalSignificand: Component, decimalExponent: Component)<br>
>> }<br>
>><br>
>> // A type that can be initialized from a hexadecimal floating point<br>
>> // literal, such as `0x1.8p-2`.<br>
>> protocol HexFloatLiteralConvertible {<br>
>> // The integer type used to represent the significand and exponent of the value.<br>
>> typealias Component: IntegerLiteralConvertible<br>
>><br>
>> // Construct a value equal to `hexadecimalSignificand * 2**binaryExponent`.<br>
>> init(hexadecimalSignificand: Component, binaryExponent: Component)<br>
>> }<br>
>><br>
>> Literals would desugar to constructor calls as follows:<br>
>><br>
>> 1.0 // T(decimalSignificand: 1, decimalExponent: 0)<br>
>> 0.123 // T(decimalSignificand: 123, decimalExponent: -3)<br>
>> 1.23e-2 // same<br>
>><br>
>> 0x1.8p-2 // T(hexadecimalSignificand: 0x18, binaryExponent: -6)<br>
><br>
> This seems like a very good approach to me.<br>
<br>
It occurs to me that "sign" probably needs to be an independent parameter, to be able to accurately capture literal -0 and 0:<br>
<br>
// A type that can be initialized from a decimal literal such as<br>
// `1.1` or `-2.3e5`.<br>
protocol DecimalLiteralConvertible {<br>
// The integer type used to represent the significand and exponent of the value.<br>
typealias Component: IntegerLiteralConvertible<br>
<br>
// Construct a value equal to `decimalSignificand * 10**decimalExponent * (isNegative ? -1 : 1)`.<br>
init(decimalSignificand: Component, decimalExponent: Component, isNegative: Bool)<br>
}<br>
<br>
// A type that can be initialized from a hexadecimal floating point<br>
// literal, such as `0x1.8p-2`.<br>
protocol HexFloatLiteralConvertible {<br>
// The integer type used to represent the significand and exponent of the value.<br>
typealias Component: IntegerLiteralConvertible<br>
<br>
// Construct a value equal to `hexadecimalSignificand * 2**binaryExponent * (isNegative ? -1 : 1)`.<br>
init(hexadecimalSignificand: Component, binaryExponent: Component, isNegative: Bool)<br>
}<br>
<br>
-Joe</blockquote></div>