It's actually whomst'd've, don't confuse please.
4 Likes
I really like this proposal, but I think it could be improved by using U+0027 APOSTROPHE rather than U+2019 RIGHT SINGLE QUOTATION MARK. This would not only be easier to type, it would also resolve the dispute about the appropriate design for character literals.
8 Likes
I think that's a non-issue. Double negatives are bad style, so you should never have more than one apostrophe on a line of good code, avoiding the ambiguity.
4 Likes
don't {
runThisCode()
}
So is this code going to run or not run?
1 Like
Have you considered using U+20E0 COMBINING ENCLOSING CIRCLE BACKSLASH as an alternative sigil for these negated control flows? It could be combined with the first character of the keyword as a way of indicating to the reader "HEY. This thing is negated."
Unfortunately Chrome is unable to render this correctly, but I hope that we wouldn't allow such a limitation to decide whether Swift uses modern Unicode features. I've attached a screenshot as an example:
15 Likes
Actually I think an efficient implementation will require a totally new mangling scheme for symbols, preferably one based around the BurrowsâWheeler algorithm. Since there are a few other changes we planned on making anyway, such as switching over fully to objc_msgSend() dispatch, we can just add a new compiler flag, like -abi 2019april1 to select the new ABI. Of course it will only work on the upcoming Apple Grandfather Clock edition of the Watch.
7 Likes
It works with try, we just have to replace try! with tryn't, which has precisely the meaning "don't try, just do it". Alternatively some people proposed to call it doOrDoNotThereIsNoTry
1 Like
Okay but you must use <= to make ifn't into an expression. Also where is switchn't? If we cant have switchn't or notswitch then I don't think we should add any of the others. Have you thought about a compiler directive like #syke() so I can just say #syke(if) ? I guess it would work as @syke too and we could add it anywhere after a statement or expression.
<= if isTrue {
// return or do
} @syke
I think there's a good opportunity in this proposal to realign ourselves with C compatibility. Many people complain that switch in Swift doesn't behave like C. We could restore C compatibility by making fallthrough implicit again, and adding a fallthron't keyword to suppress it.
10 Likes
I would also change it to be fall-up, so it goes back up the cases if it matches.
I am also open to introducing fallupn't matching the proposals original spirit.
Also big opportunity to do RTL language support right. For example ifn't should definitely be spelled t'nfi when your locale indicates a preference for an RTL language.
4 Likes
I disagree still: the true negation of defer is to perform the given block several lines ago, at the start of the function. A proper implementation would, upon reaching defern't, adjust all program state to match what it would have been, had that code run before anything else.
Other than that, huge +1. I assume a future proposal will do the same for observers--I've been waiting a long time for didn'tSet and won'tSet. Do you think let is too ingrained at this point to be replaced by varn't?
7 Likes
I've been thinking about this some more, and I think this sort of expressibility is missing from nearly all of Swift's ecosystem. Consider SPM, it would be pretty useful to be able to swift buildn't and swift runn't. It would be interesting if you could explore this idea a bit more maybe in Future Directions.
5 Likes
This proposal did not age well.
4 Likes
I think you mean it agenât well. :-)
12 Likes