> On Jun 29, 2016, at 3:51 PM, Erica Sadun <er...@ericasadun.com> wrote: > > On Jun 29, 2016, at 2:33 PM, Daniel Dunbar via swift-users > <swift-users@swift.org> wrote: >> >> I would like some clarification regarding the expected role of >> `CustomStringConvertible` for types which have a natural, lossless, string >> representation. > > And this is why we started down the road towards clarifying that it wasn't > convertible but a lossy representation. What you really want is a protocol > that > represents an isomorphic relationship. RawRepresentable is about as close as > you can get right now. > > And "representation" in RawRepresentable actually means "isomorphic conversion > between types". (ish.) > > -- E, paging Matthew Johnson to the SE-0041 courtesy phone
RawRepresentable does not require isomorphism and in fact conforming types *cannot* express isomorphm through conformances to this protocol due to the failable initializer. RawRepresentable expresses an injective conversion making the inverse a partial function which is why the initializer is failable (https://en.wikipedia.org/wiki/Injective_function). RawRepresentable conformance with a String `RawValue` is exactly the right way to express a lossless String representation in Swift. Isomorphic relationships require a precise one-to-one correspondence between values of two types (sets in mathematics). They are usually bijective (I didn’t know they aren’t always bijective until I consulted wikipedia!). https://en.wikipedia.org/wiki/Isomorphism https://en.wikipedia.org/wiki/Bijection A good example of an isomorphism in Swift is CGFloat and Double on platforms where CGFloat is a Double. For any value of one you can convert to the other and convert back to the original type without losing any information in either direction. > > p.s. > https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md > > >> I don't have good terminology to use here, but is the expectation that the >> "textual string representation" is a readable description of the object? >> This seems to correspond to the synthesized (?) default definition for >> struct types, as well as some of the uses for Foundation types without >> natural string representations (i.e. `Foundation.Notification` reports >> something like "name = foo, object = ..., userInfo = ..."). >> >> Or, is the expectation that it provide a string *representation* of the >> object, for objects where that makes sense. This corresponds to the use in >> `Foundation.UUID`, or the example of `Point.description` from the stdlib's >> `CustomStringConvertible` documentation. >> >> Another way of phrasing this question is: for types which have a reversible >> string representation, should I expect `CustomStringConvertible.description` >> to give me a string I could use to reconstruct an instance _without_ knowing >> its type? >> >> And another way (my actual question) is, given a `struct Path` object which >> contains a path string, what should `print(Path("a"))` print? >> >> - Daniel >> >> _______________________________________________ >> swift-users mailing list >> swift-users@swift.org >> https://lists.swift.org/mailman/listinfo/swift-users > _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
