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

[Jacob Bandes-Storch]

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/55d6be21/attachment.html>