[swift-evolution] [Discussion] Terms of Art Swiftification

[Jeff Kelley]

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

SlaunchaMan at gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan> | jeffkelley.org <http://jeffkelley.org/>
> On Jun 27, 2016, at 4:37 PM, Sean Heber via swift-evolution <swift-evolution at swift.org> 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 <sean at fifthace.com> 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 <swift-evolution at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160627/af43011f/attachment.html>