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 >> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
