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

[L. Mihalkovic]

-1   I like the original design for the fact that it does not give "description", which nobody would have proposed Swift had started as a blank slate, center stage: promoting it to protocol membership would perpetuate something that people should no longer be focussing on. So although I do prefer definition over convention, this is an exception I do not mind making.

-1   for Lossless. ValuePreserving is clear as to WHAT it does, LossLess describes HOW it operates, relegating the value preservation to being a side effect that people have to infer themselves: "if this thing operates in a loss less manner, then I must be getting back what I put in".


On May 28, 2016, at 6:36 AM, 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