StringProtocol - Do not declare new conformances?

Where I work we are writing a C library for cross platform development on
iOS, Android, and Ubuntu. Part of what I do with this library is wrap it in
Swift. We have a string type that should conform to StringProtocol. The
issue is that the StringProtocol has this statement for its documentation
overview:

"Do not declare new conformances to StringProtocol. Only the String and
Substring types of the standard library are valid conforming types."

While I don't think many people will/should conform to StringProtocol, I
feel like discouraging the usage of the protocol in the rare cases is is
applicable takes away a very powerful tool from the language.

Are there specific implementation details in the standard library that make
it so other types cannot safely conform to StringProtocol? If not is there
a compelling reason for this statement to be on the protocol?

Out of curiosity, how are your other string types different from Swift String?

···

On Sep 19, 2017, at 3:34 PM, Braden Scothern via swift-evolution <swift-evolution@swift.org> wrote:

Where I work we are writing a C library for cross platform development on iOS, Android, and Ubuntu. Part of what I do with this library is wrap it in Swift. We have a string type that should conform to StringProtocol. The issue is that the StringProtocol has this statement for its documentation overview:

"Do not declare new conformances to StringProtocol. Only the String and Substring types of the standard library are valid conforming types."

While I don't think many people will/should conform to StringProtocol, I feel like discouraging the usage of the protocol in the rare cases is is applicable takes away a very powerful tool from the language.

Are there specific implementation details in the standard library that make it so other types cannot safely conform to StringProtocol? If not is there a compelling reason for this statement to be on the protocol?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

AIUI, this warning is there because we did not have time to finalize the design of the protocol for Swift 4, so it may be a source compatibility liability if code outside the standard library tries to conform to it and we change the design in Swift 5.

-Joe

···

On Sep 19, 2017, at 3:34 PM, Braden Scothern via swift-evolution <swift-evolution@swift.org> wrote:

Where I work we are writing a C library for cross platform development on iOS, Android, and Ubuntu. Part of what I do with this library is wrap it in Swift. We have a string type that should conform to StringProtocol. The issue is that the StringProtocol has this statement for its documentation overview:

"Do not declare new conformances to StringProtocol. Only the String and Substring types of the standard library are valid conforming types."

While I don't think many people will/should conform to StringProtocol, I feel like discouraging the usage of the protocol in the rare cases is is applicable takes away a very powerful tool from the language.

Are there specific implementation details in the standard library that make it so other types cannot safely conform to StringProtocol? If not is there a compelling reason for this statement to be on the protocol?