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
