> On Oct 3, 2016, at 2:12 PM, Harlan Haskins <har...@harlanhaskins.com> wrote: > > If you don't think this needs a proposal
Well, that’s not up to me, so let’s wait until someone else chimes in. :) Mark > , then Robert has an implementation almost done. We could submit a PR later > today. > > - Harlan > > On Oct 3, 2016, at 4:06 PM, Mark Lacey via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >>> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>>> On Oct 3, 2016, at 11:02 AM, Robert Widmann <devteam.cod...@gmail.com >>>> <mailto:devteam.cod...@gmail.com>> wrote: >>>> >>>> Because the initializer here doesn’t take Any, it takes <T>. >>> >>> I think there's a case to be made to generalize the 'Any' warning to >>> Optional implicitly being deduced as a type variable binding in any >>> unconstrained context. What exactly constitutes 'implicit' and >>> 'unconstrained' is up for debate, though, and probably needs some >>> experimentation to figure out what feels good. For instance, explicitly >>> constructing an optional is a signal the optionality intentional. >>> Potentially, having multiple Optional parameters binding the same type >>> variable also increases the likelihood it's intended, for example: >>> >>> func foo<T>(x: T, y: T) {} >>> >>> var x: Int? = 1 >>> var y: Int = 2 >>> foo(x, y) // One Optional isn't unwrapped, forcing the other to promote. >>> Maybe a mistake? >>> var z: Int? = 3 >>> foo(x, z) // Two T parameters are Optional. Probably intentional? >>> >>> Regardless of whether there's a more general principle we can base a >>> warning on, string interpolation and String(describing:) are common enough >>> pitfalls that they may just deserve special case treatment. >> >> I think string interpolation could be handled pretty easily with a warning >> by extending the existing warning for Any. We just need to look at >> interpolation expressions and if any of the segments are optional-typed emit >> a warning unless they are explicitly casted to the optional type. The fixit >> can suggest explicit casting or using the debugDescription. >> >> I’m not sure we really need an evolution proposal for that. >> >> As for the more general topic of trickiness around optional injection into >> unconstrained generics: Yes, we should review that at some point as well. I >> recall seeing at least one concrete complaint about surprising behavior >> resulting from doing this in generic functions, but I cannot find the bug at >> the moment. >> >> Mark >> >> >>> >>> -Joe >>> >>>> ~Robert Widmann >>>> >>>>> On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> Unfortunately, Optional-to-Any does not currently hit this case because >>>>> IIRC it doesn't promote to Any in an interpolation segment. I tested this >>>>> with a ToT build yesterday. >>>>> >>>>> - Harlan >>>>> >>>>> On Oct 3, 2016, at 1:57 PM, Joe Groff <jgr...@apple.com >>>>> <mailto:jgr...@apple.com>> wrote: >>>>> >>>>>> We now emit a warning whenever an optional is used as an Any. I disagree >>>>>> that this should be an error, but it seems reasonable to warn (if we >>>>>> don't already thanks to the 'Any' warning). >>>>>> >>>>>> -Joe >>>>>> >>>>>>> On Oct 3, 2016, at 10:52 AM, 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 <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
