Swift already is an unmanaged language, and is far closer to C++ than Java. There is no equivalent to the CLR or JVM and it is trivially easy to call into C code or the unsafe APIs and do nearly anything that C can do with regard to direct access to memory.
The force-unwrap operator was never intended to model a Java-style runtime exception. Instead, it is an assertion which indicates a programmer logic error. The preferred way to handle an optional at runtime has always been to use the conditional-unwrapping functionality the language offers. The correct way to report errors at runtime that aren't due to programmer error is through the do-try-catch mechanism. Pervasive, unnecessary use of '!' is a project management and/or developer competence issue, and not something the language should go out of its way to fix. Sugaring 'if let' for programmer convenience is something on the commonly rejected proposals list: https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md Regards, Austin On Mon, Mar 6, 2017 at 6:27 PM, Elijah Johnson via swift-evolution < swift-evolution@swift.org> wrote: > Additionally, not discarding previous comments, one way the language could > be improved is by replacing (or rather augmenting) optional binding with a > faster syntax. > > ex. > > func test( name : String?, name2 :String? ){ > name! , name2! { > // inside this block, “name” and “name2” are non-optional > } else { > // no forced unwrapping, just optional else case > } > } > > Whereas the alternative (current optional binding), requires a > re-definition of variables and an additional “if” operator. Besides the > extra characters involved in typing and reading it, usually variables have > specific names that the user does not want to augument. > > func test( name : String?, name2 :String? ){ > if let nameUnwrapped = name , let name2Unwrapped = name2 { > > } else { > } > } > > func test( name : String?, name2 :String? ){ > guard let nameUnwrapped = name , let name2Unwrapped = name2 else { > > } > > } > > The fact that we don’t need a “nameUnwrapped” variable (which is unsightly > and requires refractoring) is one thing that still makes forced unwrapping > still very much a necessary or common part of Swift coding, even where it > could be replaced with optional binding. > > > > > On March 6, 2017 at 7:20:40 PM, Elijah Johnson (ejrx7...@gmail.com) wrote: > > Hi, > > I’ve been recently considering Swift on the server-side, and there came up > the question, “what happens when a null optional is forcibly unwrapped?” > and the answer was clearly that not only would the request crash, but the > entire server would also crash, since the server itself is/would be also > written in Swift. > > I think that this highlights serveral weaknesses in Swift’s “null safety” > attempts. The first is that there needs to be a way to isolate blocks of > code so that a “null pointer exception” does not crash the system. I think > it is fair to say, in the language of Java, that these are really “runtime > exceptions” and for some reason are being treated as segmentation faults > would be in C/C++. In my opinion, the existence of these things has the > ability to bring Swift down below Java and closer to an unamanged language. > Not really sure why it would ever be desireable, but in terms of > server-side programming, it is definitely a serious issue. > > Secondly, Swift’s “null safety” is really completely undermined by these > “force-unwrap” errors. I agree with the usage of new language features like > guard, optional binding, etc to remove a null value, but I see this > force-unwrap as extremely pervasive for a lot of reasons: > > 1. When porting code from a C style language to Swift, force-unwrap is > needed to make the code work without refractoring. > 2. XCode itself reccomends this operator and when it is used to satisfy a > requirement, then it can be left in the code > 3. Some styles of coding just can’t work without force-unwrap. > > I don’t think the logic of making the consequences extreme for making a > mistake are a rational for making better coders. In fact, I personally see > the “force-unwrap” operator having very great potential usage as a > deliberate assertion exception - the programmer demands that a certain > value be non-null for execution to continue, only there should be a proper > scope and context where these exceptions can propogate to. On debug modes, > one might want it to pause on the line, but for other uses, it should be > caught IMO - on regular code by the user, and inside dispatch blocks by the > queue itself. For a multithreaded app or server to exit, the user should > have to explicitly write exit(0), isn’t this the goal of a managed > language? Maybe in some cases, Apple will want the program to crash, but if > Swift is given an audience not just with Apple hardware, then it should > have more flexibility IMO. > > Elijah > > > _______________________________________________ > 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
