> On May 28, 2016, at 7:49 AM, Xiaodi Wu via swift-evolution > <swift-evolution@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@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
