[swift-evolution] Request: Multiple Bool signatures

[Dave Abrahams]

on Mon Mar 28 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

>> On Mar 28, 2016, at 11:16 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Fri Mar 25 2016, Erica Sadun <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>
>>> I am looking for examples of method/function signatures that use multiple Boolean flags, e.g.
>>> 
>>> func generateContact(withAddress: Bool, withEmail: Bool, withPhone: Bool) -> Customer // not my code
>>> 
>>> If you have app code or library code around that you can check, I
>>> would greatly appreciate if you can share signatures with me or just
>>> generally comment on how often this pattern shows up in your daily
>>> life. I am specifically looking for: use of two or more separate
>>> Boolean parameters passed as flags.
>>> 
>>> I would also welcome examples of option sets that replaced Boolean
>>> flags with a note as to whether that option set type is used elsewhere
>>> in your app.
>>> 
>>> I am following up to an action item that Brent Royal-Gordon mentioned
>>> on-list a while back but I want real supporting motivating code
>>> evidence before I move forward with a draft proposal.
>>> 
>>> Feel free to email me off-list. Thank you,  -- Erica
>> 
>> It's not hard to grep through Apple's APIs for things like this using
>> the repository we put up for the API naming review.
>> 
>> HTH,
>
> I actually did this. I also pulled down a bunch of Github repos looking for the pattern.
>
> Interestingly what I found was:
>
> * Few circumstances where multiple boolean flags were used, both in Apple code and third party code
> * Two flags was the most common multiplicity. Three flags were rare. I did not find any with four or more.
> * Code from what I judged as experts that used multiple booleans were
> primarily initializers, with a few instances from graphics code for
> things like stroke and fill.
> * Code in gists that showed many flag booleans in normal methods were
> almost always from what I'd rank as "beginner code"
>
> I'm not going to press forward with the language enhancement I had in
> mind because I don't see a compelling reality-based need for it after
> performing this check.

Thank you anyway for doing the due diligence.  That kind of research is
important and often overlooked.

Cheers,

-- 
Dave