[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init<T>(_: T)

[Xiaodi Wu]

I'd hope not. You can't guarantee String -> Double -> String roundtripping,
but Double -> String -> Double should be lossless.
On Sat, May 28, 2016 at 00:11 Jacob Bandes-Storch <jtbandes at gmail.com>
wrote:

> Does "lossless" preclude floating-point numbers from being printed in
> decimal unless they are exactly representable?
>
> On Fri, May 27, 2016 at 9:04 PM Austin Zheng via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Thanks, I like "Lossless" too. Further suggestions on naming would be
>> appreciated from anyone.
>>
>> Austin
>>
>>
>> On May 27, 2016, at 9:03 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> This looks good. I like your use of the term "lossless"; perhaps we can
>> use it consistently, i.e. LosslessStringConvertible. The implication by
>> comparison would be that CustomStringConvertible makes no guarantee of
>> losslessness.
>> On Fri, May 27, 2016 at 23:52 Austin Zheng via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> Hello swift-evolution,
>>>
>>> I've put together a preliminary v2 of the proposal, taking into account
>>> feedback expressed on this thread. I would appreciate any comments,
>>> suggestions, or criticisms.
>>>
>>>
>>> https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md
>>>
>>> If any objections can be worked out quickly, I hope to resubmit this
>>> proposal for review early next week.
>>>
>>> Best,
>>> Austin
>>>
>>>
>>> On Fri, May 27, 2016 at 7:50 PM, Patrick Smith via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> Is there any possibility we can break from this? Especially as:
>>>>
>>>> 1. ValuePreservingStringConvertible expects its description to be value
>>>> preserving, but current Cocoa implementations are not.
>>>> 2. ‘Description’ doesn’t really convey the meaning of ‘value
>>>> preserving’ in my mind, but is a valuable name for many other use cases.
>>>> 3. Swift 3 has a wide range of breaking changes for the better.
>>>> 4. With the presence of ValuePreservingStringConvertible,
>>>> CustomStringConvertible doesn’t seem to provide much value over
>>>> CustomDebugStringConvertible?
>>>>
>>>> For string interpolation, I imagine the standard library could fall
>>>> back to a ‘description’ method for NSObject subclasses.
>>>>
>>>> Thanks,
>>>>
>>>> Patrick
>>>>
>>>> > On 28 May 2016, at 7:49 AM, Dave Abrahams via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>> >
>>>> >
>>>> > on Thu May 26 2016, Patrick Smith <swift-evolution at swift.org> wrote:
>>>> >
>>>> >>> On 27 May 2016, at 2:40 PM, Austin Zheng via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>> >>>
>>>> >>> Any of the NSObject subclass candidates may require their
>>>> >>> `description`s to be altered to meet the semantics, which may or may
>>>> >>> not be an acceptable breaking change.
>>>> >>
>>>> >> Do you think it might be worth changing `description` to be named
>>>> >> something else? Something more clear, less likely to conflict with
>>>> >> ‘real’ properties — ‘description’ doesn’t seem to portray something
>>>> >> that is value-preserving. What is the reason for calling it
>>>> >> ‘description’?
>>>> >
>>>> > The main reason was backward compatibility with Cocoa, which already
>>>> has
>>>> > a “description” property.
>>>> >
>>>> >> Especially if NSObject subclasses won’t fit, then why not have a
>>>> >> different method that can be strictly value preserving? (Then
>>>> >> `description` can stay being an NSObject thing.)
>>>> >
>>>> > --
>>>> > Dave
>>>> >
>>>> > _______________________________________________
>>>> > swift-evolution mailing list
>>>> > swift-evolution at swift.org
>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160528/0e68c4d6/attachment.html>