[swift-evolution] SetAlgebra naming update

[Dave Abrahams]

on Mon Mar 28 2016, Jordan Rose <jordan_rose-AT-apple.com> wrote:

> I don't love it but given how long we've spent discussing this and
> you've spent thinking about it I can believe it's the answer that
> makes the most sense. I do have one question: what are
> 'element(_:subsumes:)' and 'element(_:isDisjointWith:)' for? Imported
> option sets with non-orthogonal options? I know that's not that
> uncommon, but I don't know why I would need dedicated operations for
> it, especially when these types have Element == Self.

You don't need them; they're there so sensible semantic axioms could be
established for SetAlgebra.  Eventually, we'll get rid of Element ==
Self and we can retire those too :-)

> (The naming guidelines also fall down on static methods like this. The
> base name doesn't describe the operation at all.)
>
>
> Jordan
>
>> On Mar 24, 2016, at 13:39, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> Just an update:
>> 
>> The naming guidelines working group went back into negotiation over
>> the shape of SetAlgebra (and thus, Set and OptionSet) for
>> Swift 3, and reached a new consensus.  We intend to bring forward a
>> proposal for the API shown here:
>> 
>>  http://dabrahams.github.io/swift-naming/SetAlgebra-Math.html
>> 
>> and to update the guidelines to suggest using the "form" prefix to
>> create a verb phrase for a mutating method when the operation is
>> fundamentally non-mutating and described by a noun.
>> 
>> Regards,
>> 
>> -- 
>> Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
Dave