> On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution > <swift-evolution@swift.org> wrote: > > 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.
My point is before you were unable to do this without the ‘uglyness’ presented here anyway [you would have gotten “Optional(“value”)”], so I don’t see the point of raising this concern. If you want the old behavior, just ask for it with an explicit cast or `.debugDescription`. > 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). IUOs are not in the scope for this proposal, but I get your point. > > -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-evolution@swift.org <mailto:swift-evolution@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 >>> <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-evolution@swift.org <mailto:swift-evolution@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 >>>> <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 <https://gist.github.com/harlanhaskins/NNNN-filename.md> >>>> Authors: Harlan Haskins <https://github.com/harlanhaskins>, Julio >>>> Carrettoni <https://github.com/Julioacarrettoni>, Robert Widmann >>>> <https://github.com/CodaFi> >>>> Review Manager: TBD >>>> Status: Awaiting revie >>>> >>>> <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#introduction>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 >>>> <https://lists.swift.org/pipermail/swift-evolution/> >>>> >>>> <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#motivation>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. >>>> >>>> >>>> <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#proposed-solution>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. >>>> >>>> >>>> <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#detailed-design>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. >>>> >>>> >>>> <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#impact-on-existing-code>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. >>>> >>>> >>>> <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#alternatives-considered>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 >>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md>). >>>> >>>> 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 <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
