The documentation for CustomStringConvertible says:
Accessing a type's description property directly or using CustomStringConvertible as a generic constraint is discouraged.
But this is never elaborated upon. Why is it discouraged to write aThing.description?
Since this is also a requirement of LosslessStringConvertible, it seems more straightforward to me that aThing.description matches with ThingType.init?(_ description: String) (i.e. I got a string directly from the object, so I expect the object also knows how to parse that String).
Using String(describing: aThing) seems too indirect for my liking. Is String doing anything other than returning the description? I don't know. Neither does the object who expects to parse this string again.
The reason for this rule is that every value in Swift is convertible to a string , regardless of a type’s conformance to one or both of these protocols. The protocols only exist to allow customization of a type’s textual representation. In particular, don’t ever use these protocols as types or generic constraints.
I understand that, but it seems like, for LosslessStringConvertible types in particular (see edited post above), that it's doing more than just customising its textual representation; it's actually serialising the data in a specific format and expects exactly that format back.
EDIT: Ok, you do mention that in your post.
When you rely on LosslessStringConvertible semantics, you should absolutely access the description property directly, despite the above advice to the contrary.