The issue here is that lossless strings aren’t a text safe encoding - E.g code trying to parse an array of strings wouldn’t know if a comma was emitted by it or one of its Elements
Right, there is no limit on what the lossless string to which a value is converted may contain, so no way to ensure that any delimiter (e.g., commas, "...", etc.) doesn't appear in the lossless string representation of the bound of a range or an element of an array in a way that is distinguishable from the delimiter. It is perfectly valid for me to create a custom type where the lossless string representation of a value is ,,,....
Good question. It is strange, because Array<T: Decodable> can be decoded. For example, Array can be decoded from json string "[1, 2, 3]", So, for now it is possible to init an Array from String, though making it using JsonDecoder. Seems that Array<T: LosslessStringConvertible> should also be LosslessStringConvertible by itself.
Of course we can't simply join the lossless string representations of the elements (in the case of Array) with a separator like ,. But we should be able to escape the lossless string representations of the elements, for example by replacing occurrences of \ with \\ and , with \,, and then join those.
Wouldn't that require changing the .description / CustomStringConvertible-conformance of Array or its Element (and [Closed]Range or its Bound)?
I mean, since:
public protocol LosslessStringConvertible : CustomStringConvertible {
/// Instantiates an instance of the conforming type from a string
/// representation.
init?(_ description: String)
}
My bad, I thought LosslessStringConvertible consisted of an additional string property that we could use without changing the semantics of description and debugDescription.
I wonder why it doesn't / if that wouldn't be better. Ie, how does the benefits of letting LosslessStringConvertible inherit from CustomStringConvertible outweigh any potential confusion / trouble / limitations caused by that entanglement?
Seems to me like LosslessStringConvertible is more "critical" than CustomStringConvertible, yet the former is based on the latter.
CustomStringConvertible's documentation even states that:
Accessing a type’s description property directly or using CustomStringConvertible as a generic constraint is discouraged.