I considered suggesting that at first - and maybe that’d be easier/better - but
I liked the idea of preserving the *intent* of the alias in different
scenerios. Not sure. That could be hammered out assuming people thought this
was a good direction to even consider vs. just picking a single name for things
and having that be that. :)
l8r
Sean
> On Jun 27, 2016, at 3:44 PM, Jeff Kelley <slauncha...@gmail.com> wrote:
>
> 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
>
> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
>
>> On Jun 27, 2016, at 4:37 PM, Sean Heber via swift-evolution
>> <swift-evolution@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 <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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
