> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution > <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 > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
