Yep, this has transformed from an evolution question to a how-to answer. exit(1).
Thanks Jack and Jaden for pointing out the retrospectively obvious. Just couldn’t see my own nose. I liked Jeff’s Optional gambit though. Félix, je regrette that your name doesn’t start with ‘J’. > On 3 Jan, 2016, at 20:36, Félix Cloutier <[email protected]> > wrote: > > IMO, this is the best way to approach it. > > Félix > >> Le 3 janv. 2016 à 22:54:17, Jack Lawrence via swift-evolution >> <[email protected]> a écrit : >> >> You could also use type inference on the return type: >> >> 1> func returnsNil<T>(errCode: Int) -> T? { >> 2. print(errCode) >> 3. return nil >> 4. } >> 5> func returnsAnOptional() -> Int? { >> 6. return returnsNil(5) >> 7. } >> >> >>> On Jan 3, 2016, at 7:51 PM, Jeff Kelley via swift-evolution >>> <[email protected]> wrote: >>> >>> Just spit-balling here, but couldn’t you do this with a generic extension >>> on Optional? >>> >>>> extension Optional { >>>> func returnsNil(errorCode: Int) -> Wrapped? { >>>> logError(errorCode) >>>> return nil >>>> } >>>> } >>> >>> >>> Jeff Kelley >>> >>> [email protected] | @SlaunchaMan | jeffkelley.org >>> >>>> On Jan 3, 2016, at 10:43 PM, Andrew Duncan via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> It should be possible to declare a function that returns only nil, and >>>> have its return type be substitutable for any function that returns and >>>> Optional. This is something like having a bottom type but not really. What >>>> I mean is: >>>> >>>> func returnsNil(errCode:Int) -> nil { >>>> logError(errCode) // A side-effect. Not FP, sosumi. >>>> return nil >>>> } >>>> >>>> func returnAOptional() -> A? { >>>> // Bla bla. We discover an error so we decide to bail and return nil. >>>> return returnsNil(errCode) // Would be legal. >>>> } >>>> func returnsBOptional() -> B? { >>>> // Bla bla. We discover an error so we decide to bail and return nil. >>>> return returnsNil(errCode) // Would also be legal. >>>> } >>>> >>>> I seek a return type that conforms to any Optional -- I think that implies >>>> it *must* (or correct me here) be nil. >>>> >>>> Now perhaps this is already possible with wizardry from the Next Level. >>>> (There always is one.) >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
