[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init<T>(_: T)

[Chris Lattner]

> On May 27, 2016, at 8:51 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello swift-evolution,
> 
> I've put together a preliminary v2 of the proposal, taking into account feedback expressed on this thread. I would appreciate any comments, suggestions, or criticisms.
> 
> https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md <https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md>
> 
> If any objections can be worked out quickly, I hope to resubmit this proposal for review early next week.

Thank you for doing this Austin!

Here are some random comments:

"which accidentally invokes this initializer by accident” -> "which accidentally invokes this initializer”


"A new protocol will be introduced: ValuePreservingStringConvertible. “ -> Thanks for adding the init requirement.  It might be worth mentioning up at top that an alternative name to consider is “LosslessStringConvertible”.  

"protocol ValuePreservingStringConvertible {“ -> "protocol ValuePreservingStringConvertible : CustomStringConvertible {"

" var stringRepresentation : String { get }"

Just speaking for my opinion, but I think this is better to keep as description.  We don’t want multiple different string forms, because at the end of the day string literal interpolation and print need to do “something”, and description should be that default form.  If that form isn’t lossless, then the type shouldn’t have access to the labelless string initializer.

  init?(stringRepresentation: String)

Since this is a lossless conversion when it succeeds, it should be unlabeled.

"The standard library will be audited."

This is prescriptive statement: the proposal should include the actual list of types in the stdlib.

"The Foundation SDK overlay will be audited in the same manner.”

-> Foundation is handled separately, it should be left out of the proposal.



"If they conform to CustomStringConvertible and their existing description is value-preserving, stringRepresentation will simply return description."

With the structure above, this isn’t necessary.


Thank you for driving this forward Austin!

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160528/f1b018be/attachment.html>