The trouble with this line of reasoning, IMO, is that it is what led to the floppy disk becoming the “universal” save icon for years and years. Apple has spent considerable effort in macOS and iOS trying to show that you don’t really need a save button at all most of the time - it turns out that auto-save by default is what people expect. Flip the logic on it’s head!
I fear that by adhering strongly to terms of art, we could be looking at a floppy-save-icon scenario over time. What if there are simply better ways of doing these things? What if the names themselves are blinding us to other alternatives? One of the purposes of my thought of having aliases for functions/methods is that it would give us an obvious primary location for a function - inside of the correct type or protocol - that feels Swifty. It would allow us to use “proper” Swift names that read fluently according to the guidelines even if they are perhaps more verbose or nontraditional or even unusual. Then by mapping those names to the existing common names, we can bring people along without too much initial pain while still allowing exploration of a new way to express things. Swift already has a rather unusual rule in that statements are meant to read like english phrases. It is meant to have a kind of human language flow when read because code is read more than it is written. Virtually all existing terms of art were NOT created with that kind of consideration. How can Swift come into its own if it isn’t allowed to have its own names for things that work with its own rules? I mean, sure, not *every* name needs to change and not every word needs to change, but it feels to me like we’re just coming up with our own dialect of a “standard” language that’s no different than American english vs. British english when what I think we should be exploring is more along the lines of the differences between english vs. greek. l8r Sean > On Jun 28, 2016, at 12:31 AM, Charlie Monroe via swift-evolution > <swift-evolution@swift.org> wrote: > > Erica had a nice list of various term-of-art usages among languages - it > included filter, map, etc. - I just can't seem to find it anywhere. This > nicely showed that there is only a few languages that name things > differently, mostly C# and C++. > > "filter" is nowadays quite a universal word that is in many languages - and > I'm talking both about programming and a natural language. And I don't think > that it goes against what one might be expecting - when you open a filter in > the UI, you don't tick things that you don't want to see, but items that you > *do* want to see. > > I don't think that changing those names will add any additional value to the > Swift language. I've personally had more issues with the naming of flatMap - > it could have been called filterMap to stay in line of filtering by returning > nil (flattening an array is in my head associated with flattening of an array > of arrays). But it's a term of art and I got my head around it. > >> On Jun 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Under consideration is the resolution that "some terms of art while >> appropriate to many FP languages, may be better served by using Swift names." >> >> Consider, for example, `filter(_:)`. Sean Heber writes, >> >>> Just tossing my vote in the hat for renaming .filter() to something like >>> .select() since that better matches what it does, IMO. “Filter” is almost >>> like the opposite word from what it should be since the closure returning >>> true is what decides what is included in the results, not what is filtered >>> *from* the results. I mean, yeah, I can kind of understand the logic either >>> way, but it’s always been one of those strange mental gymnastics things." >> >> When asked "Shouldn't there be a term of art exemption for `filter(_:)`. >> Otherwise why not use `select(where:)`," Dave Abrahams replies: >> >>> Because `where(...)` is better. >> >> Have at it. >> >> -- E >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
