[SE-0089] [in progress] Rename string reflection init

[frootloops]

Hello @gribozavr

I just started work on the proposal and if you could please help me with it. Because I don't really understand how to implement LosslessStringConvertible protocol for String.* (String.UTF8View, String.UTF16View...) and for FloatingPoint and Integer.

Thanks for any help :)

[gribozavr]

Thank you for working on this!

I'm not actually sure if LosslessStringConvertible is implementable for String.UTF8View and String.UTF16View. The reason is that the UTF-8 and UTF-16 views can be extracted from a string at arbitrary code unit boundaries, and String.init?(_: String.UTF8View) and String.init?(_: String.UTF16View) initializers are failable for that reason.

var s = "a\u{0301}"
String(s.utf8[s.utf8.index(s.utf8.startIndex, offsetBy: 2)..<s.utf8.endIndex]) // nil

@austinzheng @brentdax

[dabrahams]

No, it shouldn't be implemented for those types. There should be explicit separate constructors for lossless one-way conversions.

[gribozavr]

I think the intent of the LosslessStringConvertible protocol is that T(String(someInstanceOfT)) == someInstanceOfT. That is, this initializer should parse back what String initializer returns.

(swift) var c: UnicodeScalar = "a"
// c : UnicodeScalar = "a"
(swift) c.description
// r0 : String = "\"a\""

[gribozavr]

Still relevant.

[gribozavr]

@frootloops For FloatingPoint and Integer, just change the protocols to refine LosslessStringConvertible.

For String.CharacterView and String.UnicodeScalarView just implement the new initializer by taking the requested view from the string.

extension String.CharacterView : LosslessStringConvertible {
  public init?(_ description: String) {
    self = description.characters
  }
}

[beccadax]

It's quite possible that UTF8View and UTF16View can't be done. Sorry about that—guess I wasn't thinking when I added them.

All existing FloatingPoint types already conform to CustomStringConvertible and offer a failable init(_: String) initializer. In the future, we might consider providing our own conversion in an extension on FloatingPoint so that "big float" packages don't have to provide one, but there's no need for that today.

As for Integer, all existing integer types support an init?(_:radix:) initializer, but it's not formalized by SE-0104. I've sent an email about that in the review thread. If it were added to Integer, we could provide a Lossless-compatible init?(_:) that called through to it.

[gribozavr]

Here, as a strength reduction, we can directly query .description, since we are in the same type:

return Mirror(reflecting: description)

[moiseev]

Superseded by #3574.