1

There have been many threads on the Swift forums pitching to deprecate or replace force-unwrapping of optionals. Discussions in those threads were always divisive, with those against it finding values in force-unwrapping where the variable is known to be non-nil. For example:

var optionalNumber: Int? = nil
optionalNumber = 1
let number = optionalNumber! // number == 1

Now what if we make some minimal change to the code snippet above, and make it impossible for anyone to predict whether optionalNumber can be force-unwrapped successfully? Something like this maybe:

@Quantum
var optionalNumber: Int? = nil // `optionalNumber` is initialised with an initial state of `nil`
optionalNumber = 1 // `optionalNumber` now has a 50% chance of being `nil`, and 50% being 1
let number = optionalNumber! // The force-unwrapping has a 50% chance of being successful

It won't invalidate the opinion that force-unwrapping is useful, but it should be interesting though.

Full text of this silly proposal here.

April fools has basically gone by, but since there are still some places in the world where it's 2021-04-01, I hope it's still fine for me to post this.

27 Likes
2

I am strongly +1 or -1 on this pitch.

26 Likes
3

Is this proposal compatible with the Bell inequalities? I think it is of paramount importance to avoid having counterfactual definiteness.

2 Likes
4

There is no entanglement in this proposal, so in some sense, you can probably say that it both is and isn't compatible with Bell inequality?

2 Likes
5

Damn, and Swift was just about to make concurrency simple...

6

The closer I look at this proposal, the less I see where it is going…

13 Likes
7

There is at least one possible world in which I support this proposal.

3 Likes
8

I clearly see where it is going, but I don't have any clue about how fast it goes. :slight_smile:

1 Like
9

oh I can def see how fast this is going, but I'm not sure where we are right now.

2 Likes