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

[L. Mihalkovic]

> On May 28, 2016, at 7:49 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.
> 

IMO "Custom" evoques a general set, of which "ValuePreserving" is a subset.

> 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
> _______________________________________________
> 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/e939a01b/attachment.html>