`formFilter` strongly implies that the result is a filter, so this would be a very bad choice. i do not follow the argument that it makes sense to just concatenate `form` and the non-mutating method name. The precedence set by `formUnion` is not a good one but at least there it makes sense because using union as a noun preserves the original meaning (the missing `with:` is tolerable) whereas `formFilter` conveys a completely wrong meaning.
To answer Ben's questions: > 1. Is it right to assert that with a “removing” operation, the closure should > return `true` for removal? Yes, definitely. > 2. Is it likely that users will want to switch from out-of- to in-place, and > if so, will having to flip the closure cause confusion/bugs? I do not think that it is very likely and if so I do not think that having to flip the closure will cause confusion because both methods are very differently named. > 3. Should we “complete” the matrix of 4 operations, or is it fine for it to > have gaps? No, it is fine to have gaps. I would consider adding a `removing` variant but as there is no good name for the mutating variant of `filter` I would definitely not add this one. > 4. If you are for completing, what should X and Y be called? I am against completing. -Thorsten > Am 27.09.2017 um 04:33 schrieb Xiaodi Wu via swift-evolution > <[email protected]>: > >> On Tue, Sep 26, 2017 at 6:48 PM, Robert Bennett <[email protected]> >> wrote: >> formFilter reads really weirdly... the use of filter in `filter` is not as a >> noun, but as a verb — compare to e.g., formRemainder. Calling formFilter >> won’t create a filter, it will “do” a filter. Perhaps formByFiltering? > > That's interesting. I worry it might be too clever by half, though. > > The prototypical "form" method is "formUnion"; it's so named because the term > "union" is used in math as both noun and verb ("a union b"; "the union of a > and b") and is a term of art that doesn't lend itself to the noun/verb rule > in Swift. Here, "filter" is a term of art (otherwise, it'd be called > "filtered"); now that "filter" is the non-mutating function (i.e., what > should otherwise be a noun), there's no way to maintain the noun/verb rule in > Swift. Therefore, without overthinking it, "formFilter". > > Note that it's not "formUnion(with:)", just "formUnion(_:)". As is the case > with "formUnion", no particular attempt is made here to turn this method name > into an English phrase. The phrase "by filtering" very strongly suggests > true-to-remove; that's the only way the term "filtering" is used in English. > Here, we mean true-to-keep, and there's no way to express that with the > English word "filter" between the receiver and the predicate with any sort of > conjugation of the word or concise combination of helper words. The nearest > good-English name might be something like > "formFilteredResultKeeping(where:)", which is clearly awful for other reasons. > >>> On Sep 26, 2017, at 7:23 PM, Xiaodi Wu via swift-evolution >>> <[email protected]> wrote: >>> >>>> On Tue, Sep 26, 2017 at 6:14 PM, Ben Cohen via swift-evolution >>>> <[email protected]> wrote: >>>> And here are my answers, in a separate email to maintain a shred of >>>> separation between objectivity and subjectivity :) >>>> >>>> > On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution >>>> > <[email protected]> wrote: >>>> > >>>> > 1. Is it right to assert that with a “removing” operation, the closure >>>> > should return `true` for removal? >>>> >>>> Yes. If the closure returned false for removal a different, less readable, >>>> name would be needed for the method. >>> >>> Agree, yes. >>> >>>> > 2. Is it likely that users will want to switch from out-of- to in-place, >>>> > and if so, will having to flip the closure cause confusion/bugs? >>>> >>>> I don’t think so. While the argument for an in-place remove is partly that >>>> it’s more efficient than x = x.filter (in addition to >>>> reability/discoverability benefits), I think that once both an in- and >>>> out-of-place version are available, users will reach immediately for the >>>> one they want. The scenario where you were filtering, and then you realize >>>> you could do it in-place more efficiently, doesn’t seem to me like it will >>>> come up in day-to-day use. >>> >>> Unsure. Maybe and maybe, but I think the confusion/bugs would be limited if >>> the full matrix of four operations exist. >>> >>>> > 3. Should we “complete” the matrix of 4 operations, or is it fine for it >>>> > to have gaps? >>>> >>>> I think filter(_:) and remove(where:) are sufficient. I don’t think we >>>> need to complete the set. >>> >>> Based on question (2), I would argue that the answer is yes. >>> >>>> > 4. If you are for completing, what should X and Y be called? >>>> > >>>> >>>> One of the reasons I _don’t_ think we should complete the set is that >>>> formFilter(_:) will take us into serious jumped-the-shark territory, >>>> naming-wise. >>>> >>>> I think there’s an argument for never having had filter, and always having >>>> had remove/removed (or possibly select/selected), but don’t think this is >>>> important enough to clear the bar for a rename of this magnitude. >>> >>> IMO, they should be called removing(where:) [removed(where:) reads weirdly >>> in conjunction with the preceding receiver] and formFilter(_:). Hundreds of >>> messages finally settled on "form" as the in-place verb of choice where the >>> noun can't ordinarily be verbed. No point in being shy about it now: that's >>> the Swift way, wear it proudly. >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
