I also feel that Swift should be held "hostage" to a term of art especially if the term is fairly badly named and/or unswifty. I feel the term of art can incorporated in the API docs and possibly expressed by the alias concept that has been discussed.
I strongly encourage going with a swiftly name for things first and only then back peddling after considering the range of terms of art seen in other languages. -Shawn On Tue, Jun 28, 2016 at 6:38 AM Sean Heber via swift-evolution < [email protected]> wrote: > 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 < > [email protected]> 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 < > [email protected]> 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 > >> [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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
