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 <s...@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@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
