More generically, it could be something like @alias: > @alias(filter) func where(…)
This would allow this particular case to have another name, but also allow for things like alternate spellings. Jeff Kelley [email protected] | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/> > On Jun 27, 2016, at 4:37 PM, Sean Heber via swift-evolution > <[email protected]> wrote: > > And along a similar line of thinking, what about a @termOfArt() attribute > that similarly redefines or provides additional names for things. This way > the name in the standard library/etc would be the “Swift” version of the name > - but there’d be a way to use it and find it even if you’re familiar with > other names for the same feature. > > @termOfArt(filter) func where(…) > > etc. > > There could then be migration tools in Xcode (and others) which do things > like transform all of your termsOfArt usages into the standard Swift > nomenclature if you want to migrate/standardize. > > Again, maybe this is silly. On the one hand, I’m not a fan of multiple names > for the same things. On the other hand, sometimes the best name for a thing > depends on context. > > l8r > Sean > > >> On Jun 27, 2016, at 3:19 PM, Sean Heber <[email protected]> wrote: >> >> Here’s a perhaps unlikely “what if” idea that is tangentially related to the >> problem that FP and mathematical names are sometimes weird in Swift and >> often don’t have a place to “live” that makes sense. >> >> Let’s say we add an ability to declare a function on a >> struct/protocol/class/enum as a “functionalAlias” (for lack of a better >> name) which creates both a normal method, but also an effectively global >> function of the same (or an alternate given) name for use in functional >> scenarios. >> >> Example: >> >> struct Float { >> @functionalAlias(floor) func roundedDown() -> Float { return … } >> } >> >> This would allow you to do this: >> >> let value: Float = 42 >> let a = value.roundedDown() >> let b = floor(value) >> >> Essentially, the compiler generates something sort of like this for you: >> >> extension Float { >> static func floor(_ v: Float) -> Float { return v.roundedDown() } >> } >> >> When looking up a global function, the compiler would include these >> generated static functions as if they were top-level functions and proceed >> pretty much like normal. If there is any ambiguity, since the auto-generated >> function are effectively declared as a static inside of another type, you >> could always disambiguate with “Float.floor” if necessary. >> >> Obviously this is just brainstorming/talking out loud. Maybe this is silly. >> Maybe it’s terrible. (Probably both.) >> >> l8r >> Sean >> >> >> >>> On Jun 27, 2016, at 2: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
