Definitely right about that, the implementation <https://github.com/CodaFi/swift/commit/43a582ef0fb108369f3df955f617b77b71cbd45e#diff-9124ea1eb6021a3c7323d7a07fd85c1eR2409> took all of 10 minutes after extending the OptionalToAnyCoercionWalker. If you’ve got any comments, please let me know there.
~Robert Widmann > On Oct 3, 2016, at 4:06 PM, Mark Lacey <mark.la...@apple.com> wrote: > >> >> 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> >>> 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> 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> 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> 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 >>>>>> • Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann >>>>>> • 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 >>>>>> >>>>>> 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). >>>>>> >>>>>> • 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution