On May 26, 2016, at 9:40 PM, Austin Zheng via swift-evolution
<[email protected]> wrote:
>> Some remaining open questions:
>>
>> - Exactly what types should conform to ValuePreservingStringConvertible. It
>> seems clear that integer, floating point types, and Character can and should
>> conform. What other types should?
>
> Like Brent mentioned, there are some types that are natural candidates,
> including Foundation types whose conformance could go into the overlays.
> NSURL, NSUUID, NSIndexPath. NSData is a borderline candidate, and probably
> not a good fit in the end (what encoding to use? what happens if you get the
> .description of a 100 MB NSData? etc). Same with NSDate. Maybe some of the
> CGStructs, although maybe the fact that CGFloat differs between platforms
> will sink that idea.
Yes, there definitely are Foundation types that could adopt this. However, we
don’t have a swift-evolution process at the moment to propose Foundation API
extensions, so these would have to go through bugreporter.apple.com.
>> - Do we need the ValuePreservingStringConvertible at all, or is the existing
>> CustomStringConvertible enough? We already have a few protocols for
>> handling string convertibility, it would be great to avoid adding another
>> one.
>
> This is a good question.
>
> Since a ValuePreservingStringConvertible is, by definition, a type that can
> be represented as a string in a lossless and unambiguous manner, would it be
> worth requiring a reverse conversion in the form of a failable initializer
> taking a string? Some of the proposed ValuePreservingStringConvertible types
> already have such functionality today. It would give the protocol a little
> more of a reason to exist, as well as encouraging proper conformance.
Yes, this would be really great. Perhaps obvious, but this could/should be
expressed an initializer requirement in ValuePreservingStringConvertible.
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
