I assume you meant that as a reply to me? The problem is twofold:
1. Printing the value without adornment, or "nil" for nil, is a very common thing to want to do and we shouldn't have to write code like `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it. 2. Due to the changes made to IUOs, if you use a IUO in a string interpolation, previously it would print as desired (either the value or the string `"nil"`) but now it prints as Optional (e.g. with the `"Optional(…)"` wrapper). -Kevin On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote: > Under our proposal you can return to the old semantics of printing > nil with an explicit optional cast - one which we will offer to > insert for you. > > Otherwise if you actually intend for a default value that value would > have type Int, not String. Under the current regime if you want to > print something custom the for nil the way you've got it now you're > going to have to go through the reflecting initializer anyway so I > don't see a problem here. > > ~Robert Widmann > > 2016/10/03 19:25、Charlie Monroe via swift-evolution <swift- > evolut...@swift.org> のメッセージ: >> I've already suggested this quite some time back and was told that >> this doesn't need to go through evolution. It's filed here: >> https://bugs.swift.org/browse/SR-1882 >> >> Unfortunately, I haven't had time to look into it myself and I'm >> unlikely to have the time anytime soon... >> >>> On Oct 3, 2016, at 7:52 PM, Harlan Haskins via swift-evolution <swift- >>> evolut...@swift.org> wrote: >>> >>> >>> Hey all, >>> >>> Julio Carrettoni, Robert Widmann, and I have been working on a >>> proposal to mitigate something that's burned us all since Swift 1. >>> We'd love some feedback! >>> >>> It's available here: >>> https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd >>> >>> I've posted the current draft below. >>> >>> Thanks, >>> Harlan Haskins >>> >>> Disallow Optionals in String Interpolation Segments >>> * Proposal: SE-NNNN[1] >>> * Authors: Harlan Haskins[2], Julio Carrettoni[3], Robert >>> Widmann[4] >>> * Review Manager: TBD >>> * Status: Awaiting revie >>> Introduction >>> Swift developers frequently use string interpolation as a >>> convenient, concise syntax for interweaving variable values with >>> strings. The interpolation machinery, however, has surprising >>> behavior in one specific case: Optional<T>. If a user puts an >>> optional value into a string interpolation segment, it will insert >>> either "Optional("value")" or "nil" in the resulting string. Neither >>> of these is particularly desirable, so we propose a warning and fix- >>> it to surface solutions to these potential mistakes. >>> Swift-evolution thread: Discussion thread topic for that proposal[5] >>> Motivation >>> *The Swift Programming Language* defines string interpolation >>> segments as "a way to construct a new String value from a mix of >>> constants, variables, literals, and expressions". There is one type >>> that runs counter to this definition: Optional. The .none case in >>> particular is used to indicate the absence of a value. Moreover, its >>> inclusion in interpolation segments leads to the dreaded "nil" in >>> output that is often fed to UI elements. Even barring that, >>> interpolating a non-nil optional value yields "Optional("value")", a >>> result that is not useful even in logged output. >>> Given that the Optional type is never fit for display to the end >>> user, and can often be a surprising find in the console, we propose >>> that requesting an Optional's debug description be an explicit act. >>> This proposal now requires a warning when using an expression of >>> Optional type within a string interpolation segment. >>> Proposed solution >>> The user will be warned after attempting to use an expression with >>> type Optional<T> in a string interpolation segment. They will then >>> be offered a fixit suggesting they explicitly request the >>> debugDescription of the Optional value instead. >>> Detailed design >>> Semantic analysis currently does not do much but guarantee the well- >>> formedness of expressions in interpolation segments. These are then >>> fed directly to String.init(stringInterpolationSegment:) and are run >>> through the runtime reflection system to generate a description. >>> Semantic analysis will be tweaked to inspect the result of solving >>> an interpolation segment for an Optional and will offer a fixit in >>> that case. >>> Impact on existing code >>> As this is a warning, code written before this proposal will >>> continue to compile and run with the same semantics as before. >>> Authors of code that makes use of this unsafe pattern will be >>> offered a migration path to the safer, more explicit form. >>> Alternatives considered >>> * A fixit that suggests a default value be inserted would be >>> entirely appropriate (following the style of the fixit introduced >>> in SE-0140[6]). >>> * Forbidding this pattern by hard error would make this proposal a >>> breaking change that is out of scope for this stage of Swift's >>> development. >>> * A fixit that introduces a force-unwrapping would technically work >>> as well, however it would be fixing a dangerous operation with >>> yet another dangerous operation. >>> >>> >>> Sent from my iPad >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _________________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution Links: 1. https://gist.github.com/harlanhaskins/NNNN-filename.md 2. https://github.com/harlanhaskins 3. https://github.com/Julioacarrettoni 4. https://github.com/CodaFi 5. https://lists.swift.org/pipermail/swift-evolution/ 6. https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution