-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 <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
