Now that this trivial extension is accpeted, will someone tackle isFalse for the same reasons and it‘s less terse than the prefix ! operator.
2 Likes
Not sure if joking.
== false is fine for this, in my opinion, but I wouldn't fight the addition of it much because–if I'm being honest–I am not a huge fan of prefix !.
What's up with all the snarky replies here (and on Twitter)? I don't really like that trend, feels pretty hostile.
I sometimes wonder if you and others actually read and understand the proposal. It's quite different from isFalse, and has interesting use cases. Both things has been discussed a number of times in the thread.
7 Likes
I'm not sure why you see this as hostile, especially when my reply wasn't even sarcastic. (Maybe it sounded like that, but it wasn't meant to be sarcastic.) Personally I would appreciate the addition of isFalse in the stdlib Bool even if it's trivial to implement yourself, so was toggle trivial to implement. That's the only comparison I made, so I would like to know that is so snarky about it?
As mentioned during the review, a function that purely acts as an alternative to ! is on the commonly rejected proposals list.
2 Likes
Thank you for re-clarification Ben. Much appreciated.
Then I misinterpreted it, sorry about that.
No it's fine I have not felt offended or something. It's always good to ask though.
I hope I have not contributed to any negative feeling. I honestly don't mind that the proposal passed.
During the review period, I mentioned that I didn't feel it was significant enough for stdlib. That the core team not only embraced this but asked for other clever corner case proposals ("The core team would welcome further proposals to fill in gaps like this in the standard library.") suggests that my objections were outside the team's vision of where Swift is moving
I'd like to see a clarification of that vision so the on-forum discussions can better match where the language is heading in its next steps.
6 Likes
What I really liked about the review decision was that it enumerated five bases for accepting this proposal. A less thoughtful pitch of the same idea would have failed very quickly, but thanks to the detailed discussion here and very well-written feedback, we've got not only a new method, but also some new ways to evaluate future additions to the standard library. Specifically, rephrasing the feedback into question form:
- Does the proposed addition solve a need that is common across multiple different problem domains?
- Does it significantly improve readability?
- Is it important to have a consistent way of doing this across all Swift codebases?
- Is there a correctness risk to existing alternatives that the new addition would avoid?
- Can the new addition be made more efficient than existing alternatives?
I do not imagine that this is an easy standard to meet for arbitrary additions to the standard library.
6 Likes
Is toggled really just a reimplementation of ! though?
Think of the optional chaining case:
let inv = myType.optionalBool?.toggled //inv has Bool? type
vs
let inv = !myType.optionalBool //ERROR: optionalBool not unwrapped
Without commenting on the rest of it, I will note that you can get the same effect as toggled on Optionals using map:
let inv = myType.optionalBool.map(!)
while the same is not true for the mutating toggle() method.
3 Likes
Right. That is, assuming you really want inv to remain optional. I suspect, especially with a boolean, you would usually want to remove optionality at the same time.
1 Like
I still don’t understand how this fits with the Swift API Guideines. We have plenty of methods along the lines of .sort() (mutating) vs .sorted() (non-mutating). Doesn’t this proposal fly in the face of that?