Ok, I see - though I find myself using occasionally IUOs in Swift as well -
e.g. when you can't use the default values because they depend on self, etc.
Eliminating it just from method signatures IMHO brings an incosistency into the
language. Why would you eliminate it only from method signatures - this
proposal mentioned importing ObjC API in the beginning - why not then mark
those properties all as optional as well? IUOs are scheduled to be removed
completely once the language reaches a point where it can handle most scenarios
otherwise...
Try to imagine some APIs brought to Swift with default being nullable:
/// Imported from
public class NSOrderedSet : NSObject, NSCopying, NSMutableCopying,
NSSecureCoding, NSFastEnumeration {
public var count: Int { get }
public func objectAtIndex(idx: Int) -> AnyObject?
public func indexOfObject(object: AnyObject?) -> Int
public init()
public init(objects: UnsafePointer<AnyObject?>, count cnt: Int)
public init?(coder aDecoder: NSCoder?)
}
This doesn't make much sense - mostly objectAtIndex(_:).
> On Jun 27, 2016, at 8:35 PM, Saagar Jha <[email protected]> wrote:
>
> I think you’re mistaking the scope of the proposal. It’s simply removing IUOs
> in function signatures, not throughout the language.
>
> On Mon, Jun 27, 2016 at 11:31 AM Charlie Monroe via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
> There are many useful cases for IUO in Swift - mostly when you have variables
> that cannot be calculated at the point of calling super.init(), but are
> guaranteed to be filled during initialization - i.e. during the lifetime of
> the object, the value is nonnil, but may be nil for a short period of time.
>
> Or @IBOutlets. Making all @IBOutlets optionals would make the code either
> riddled with ! or shadowed locally re-declared instance members.
>
>
> > On Jun 27, 2016, at 8:12 PM, Jean-Daniel Dupas <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Maybe we can prohibit it in Swift function declaration, and allow it only
> > when importing native code.
> >
> > As David, I don’t see any compelling reason to allow such construct in
> > Swift.
> >
> >> Le 27 juin 2016 à 10:39, Charlie Monroe via swift-evolution
> >> <[email protected] <mailto:[email protected]>> a écrit :
> >>
> >> When you import ObjC code that has no nullability annotation, IUO make
> >> sense since:
> >>
> >> - they can be checked against nil
> >> - typically, most values in APIs are nonnull (looking at Foundation, for
> >> example, which is why Apple has the NS_ASSUME_NONNULL_BEGIN to mark entire
> >> regions as nonnull, yet there is no NS_ASSUME_NULL_BEGIN)
> >>
> >> Importing them as optionals would make it really hard to work with the
> >> code - whenever you get a value, it's an optional, even in cases where it
> >> makes no sense and adding ! to unwrap the optional is not a great
> >> solution. And the other solution is to use guards everywhere.
> >>
> >> IMHO the IUO is a nice (temporary) solution for using un-annotated code
> >> until it is. But the "pressure" should be applied on the ObjC code.
> >>
> >>> On Jun 27, 2016, at 10:03 AM, David Rönnqvist <[email protected]
> >>> <mailto:[email protected]>> wrote:
> >>>
> >>> I don’t know about the chances of getting approved, but I think this is
> >>> something worth discussing.
> >>>
> >>> It might just be my ignorance, but I can’t think of a good reason why a
> >>> function argument would be force unwrapped. Either it’s non-null and the
> >>> caller is expected to unwrap it or it’s nullable and the method is
> >>> expected to handle the nil value. So I’m positive to that part of the
> >>> proposal.
> >>>
> >>> As to what we should do with the generated interfaces of Objective-C code
> >>> that hasn’t been annotated with nullability, I think that needs input
> >>> from more people to find the preferred solution.
> >>>
> >>> Once that’s been discussed some more, I’d be willing to write up a formal
> >>> proposal if you don’t feel like it (assuming the discussion leads
> >>> somewhere).
> >>>
> >>> - David
> >>>
> >>>
> >>>> On 27 Jun 2016, at 06:28, Charlie Monroe via swift-evolution
> >>>> <[email protected] <mailto:[email protected]>> wrote:
> >>>>
> >>>> See https://github.com/apple/swift-evolution/blob/master/process.md
> >>>> <https://github.com/apple/swift-evolution/blob/master/process.md> - you
> >>>> would need to make an official proposal and submit it as pull request.
> >>>> But given the reaction here, it's unlikely to get approved.
> >>>>
> >>>> Also, the ObjC code without nullability is getting fairly rare - all
> >>>> Apple's frameworks are with nullability information (as far as I've
> >>>> checked) in macOS 10.12, iOS 10. Third party libraries should be updated
> >>>> to use nullability (and most libraries that are maintained already do).
> >>>>
> >>>>
> >>>>> On Jun 25, 2016, at 5:13 PM, Spromicky via swift-evolution
> >>>>> <[email protected] <mailto:[email protected]>> wrote:
> >>>>>
> >>>>> So, its proposal is dead, or what we must to do to force it to
> >>>>> swift-evolution repo on GitHub?
> >>>>>
> >>>>>> Hello, everyone!
> >>>>>>
> >>>>>> I wanna propose to you to remove force unwrapping in fuction signature
> >>>>>> for swift code. That no sense in clear swift code. If we wanna use
> >>>>>> some optional value as function param, that is not optional, we must
> >>>>>> unwrap it before function call.
> >>>>>> People who new in swift look at how they old Obj-C code (without
> >>>>>> nullability modifiers) translate in to swift:
> >>>>>>
> >>>>>> Obj-C:
> >>>>>> - (void)foo:(NSInteger)bar {
> >>>>>> //...
> >>>>>> }
> >>>>>>
> >>>>>> Swift transaliton:
> >>>>>> func foo(bar: Int!) {
> >>>>>> //...
> >>>>>> }
> >>>>>>
> >>>>>> And think that force unwrapping in signature is good practice. And
> >>>>>> start write functions in clear swift code like this:
> >>>>>>
> >>>>>> func newFoo(bar: Int!) {
> >>>>>> //...
> >>>>>> }
> >>>>>>
> >>>>>> and use it like this:
> >>>>>>
> >>>>>> let bar: Int? = 1
> >>>>>> newFoo(bar)
> >>>>>>
> >>>>>> And it really work, and they does not think that this can crash in
> >>>>>> case if `bar` will be `nil`.
> >>>>>> But in clear swift we wanna work with parametrs in function that
> >>>>>> clearly or optional, or not.
> >>>>>>
> >>>>>> func newFoo(bar: Int) {
> >>>>>> //...
> >>>>>> }
> >>>>>>
> >>>>>> or
> >>>>>>
> >>>>>> func newFoo(bar: Int?) {
> >>>>>> //...
> >>>>>> }
> >>>>>>
> >>>>>> When we write a new function we know what we need in this case and use
> >>>>>> optional params or not.
> >>>>>>
> >>>>>> So my proposal is remove force unwrapping(`!`) from function
> >>>>>> signatures, cause it have no sense, and that confuse new users.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> swift-evolution mailing list
> >>>>> [email protected] <mailto:[email protected]>
> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >>>>
> >>>> _______________________________________________
> >>>> swift-evolution mailing list
> >>>> [email protected] <mailto:[email protected]>
> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >>>
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> [email protected] <mailto:[email protected]>
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> --
> -Saagar Jha
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
