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

[Xiaodi Wu]

I don't recall whether it was in this thread or another that this point was
made by the core team, but if I'm remembering correctly: it was shared that
the protocol is now called CustomStringConvertible because conforming types
provide a *custom* description, not merely an ordinary description.

If we follow that reasoning, ValuePreservingStringConvertible should *not*
conform to CustomStringConvertible, because whether the description is
value-preserving is orthogonal to whether it has been customized.

But I share your concern that attempting to delete description from Swift
will only increase interoperability headaches rather than freeing the name
for other uses.

On Sat, May 28, 2016 at 00:36 Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> >
> https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md
>
> I prefer the more conservative and backwards-compatible option of using
> `description` and conforming `ValuePreservingStringConvertible` to
> `CustomStringConvertible`.
>
> This is for three reasons:
>
> * ValuePreservingStringConvertible really is a refinement of
> CustomStringConvertible's semantic; a value-preserving `description` should
> always be acceptable as an ordinary `description`.
>
> * You should not call `description` directly anyway; you should call
> `String.init(_:)`. That makes the arguably non-descriptive name a lot less
> important.
>
> * Changing the name of this property now will not actually make
> `description` available for the uses you want to put it to in most code. No
> amount of monkeying with the Swift standard library in 2016 can change the
> fact that the OpenStep specification took that name in 1994, and we need to
> interoperate with that heritage. You might free up the name `description`
> in value types and Linux-only code, but only at the cost of
> interoperability headaches. I don't think that's worth it.
>
> I also think that, if we're serious about
> ValuePreservingStringConvertible's initializer restoring the full state of
> the instance, then it is a full-width conversion and doesn't need a label.
>
> So, here's what I suggest:
>
>         protocol CustomStringConvertible {
>                 var description: String { get }
>         }
>         protocol ValuePreservingStringConvertible: CustomStringConvertible
> {
>                 init?(_ description: String)
>         }
>         extension String {
>                 init<Value: ValuePreservingStringConvertible>(_ value:
> Value) { ... }
>                 init<Value>(describing value: Value) { ... }
>         }
>
> Actually, I'd *like* to see `String.init(describing:)` constrained to
> CustomStringConvertible, but I've lost that argument before.
>
> ("Lossless" instead of "ValuePreserving" is fine too, perhaps even
> slightly better.)
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> 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/73f4d522/attachment.html>