Adds a PPC for any and all as built-in operator syntax
#50
Conversation
|
|
||
| These operators are similar to `grep` in scalar context, though yield a simple boolean truth value relating to how many input values made the filter block yield true. `any` yields true when its block yields true for at least one of its input values, or false if they all yield false. `all` yields true only if every input value makes the block yield true, or false if at least one yields false. | ||
|
|
||
| A consequence of these rules is what happens when given an empty list. A call to `any` with an empty list does not have any input values which made the block return true, so its result is false. Conversely, a call to `all` with an empty list does not have any input values which made the block return false, so its result is true. |
There was a problem hiding this comment.
I was at first surprised by this behavior, that all would be true on an empty list; though i did see that that's how every works in javascript and all in python, and i suppose it makes sense. I think we could have a word on why this design choice makes sense from a user's perspective rather than just the implementation reason.
|
Why guard them by a feature, instead of adding them as |
Because these aren't quite normal functions, the same way grep isn't. |
|
When builtin was being designed, at one point a second "keywords" namespace was proposed (possibly by me) for keywords that may have unique parsing behavior. But feature handles these just fine as long as we don't mind the extra feature proliferation. |
A reminder on the PPC process: Accepting this PR means we like the document, but it does not automatically imply that we accept the idea embodied by it. Accepting the document first is useful as it gives it a number and allows us to discuss and iterate on one canonical version of it, ahead of accepting the underlying idea. It is perfectly fine to accept the document even if questions and issues still surround it.