Ken Ferry

@kongtomorrow @pilky it’d make sense to me that the compiler would implicitly optionalize a non-optional type

@SteveStreza @kongtomorrow Still seems a little weird. As much as I dislike strong typing, my gut feeling is that should be an error

@pilky @kongtomorrow a non-optional T fully satisfies the requirements of optional T. The compiler should infer that and autobox it up.

@kongtomorrow @SteveStreza @pilky Any reason why you use (Int?) instead of Int? in the definition of foo? Both work but still less () > ∞

@ozaed @stevestreza @pilky wanted to be clear that it wasn't the function itself that was optional, given that that's what we're focusing on

@kongtomorrow @SteveStreza @pilky But you run into different semantics with additional (), see the Swift book about multiple return values

@kongtomorrow Maybe T is a subtype of T? ?

@optshiftk @kongtomorrow Swift silently upconverts T into T? so that you can pass non-optionals into optional arguments.

@airspeedswift @optshiftk can't very well reach inside of the closure to do it, though. Must allocate a wrapping closure.

@kongtomorrow @airspeedswift Actually, the compiler might even be choosing some printlnHelper(_: Int?) based on the *call site*.

@optshiftk @airspeedswift it'd have to do that _everywhere_ though if that was the case. It's not hard for caller to wrap in a closure…