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.
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.