[swift-users] Clarification on the role of `CustomStringConvertible`

[Matthew Johnson]

> On Jun 29, 2016, at 3:51 PM, Erica Sadun <erica at ericasadun.com> wrote:
> 
> On Jun 29, 2016, at 2:33 PM, Daniel Dunbar via swift-users <swift-users at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>