Thanks! The PR I submitted earlier should have an updated version of the proposal which takes most of your feedback into account. I'll amend it later to address the rest.
Sent from my iPhone > On May 28, 2016, at 1:33 PM, Chris Lattner <[email protected]> wrote: > > >> On May 27, 2016, at 8:51 PM, Austin Zheng via swift-evolution >> <[email protected]> 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 >> >> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
