That's an interesting idea. It's a further shorthand for closures rather than
an extension of dot shorthand in a new type context. I wonder if this would
apply in contexts where the dot shorthand wouldn't.
>From a readability point of view I definitely prefer the dot shorthand. The $
>after the opening parenthesis doesn't leave enough "whitespace" for my eyes
>and makes things appear cluttered.
someArray.map($.property)
someArray.map(.property)
That said, I do like the idea of being able to drop the 0 in more complex
single-argument closures.
Matthew
Sent from my iPad
> On Dec 18, 2015, at 10:15 AM, Sean Heber <s...@fifthace.com> wrote:
>
> For me there are two sources to the feeling of noise with simple
> single-statement closures and using $0, etc. - The first are the braces that
> seem redundant when there’s only a single statement, and the second is the
> presence of $0.
>
> I played around a bit, and this is probably just a personal preference thing,
> but I don’t think it’s the $ that bothers me, really, but instead it is the
> digit that makes it feel noisy. When I change $0 to $a, $b, etc. suddenly the
> code doesn’t feel so noisy to me. This may simply be because I rarely ever
> put a number in my variable names, and if I do, I almost always start at 1
> and not 0. :P Again, this might just be me. :)
>
> someArray.map({ $0.property })
> someArray.map({ $a.property })
>
> Then it occurred to me that for the simple case of doing a map or filter or
> whatever using a single method call, what if Swift could instead make an
> assumption that if there’s a $ variable outside of a closure, we meant to
> start a single-statement closure so something like this could be possible:
>
> someArray.map($0.property)
> someArray.map($a.property)
>
> And going farther with this, in the case where there’s only a single argument
> in the closure, maybe we could skip the number/letter entirely and just use
> are bare $ instead of $0:
>
> someArray.map({ $.property })
>
> And finally, combined with the single-statement shortcut:
>
> someArray.map($.property)
>
> l8r
> Sean
>
>
>> On Dec 18, 2015, at 9:31 AM, Matthew Johnson via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> Johan, you are right that all of this is possible but it seems rather
>> verbose to me. I’d rather use the currently possible { $0.member } syntax.
>> The point of the idea is to remove syntactic noise.
>>
>> It’s reasonable to argue that this isn’t necessary, but in that case the
>> current state suffices IMO. We don’t need a more verbose alternative to
>> what we already have.
>>
>>
>>> On Dec 18, 2015, at 9:00 AM, Johan Jensen <j...@johanjensen.dk> wrote:
>>>
>>> I’m not very fond of having just a single dot in front of the method call,
>>> as it could easily be missed.
>>> In the case of s.predicate = .hasPrefix("abc"), I would prefer something
>>> slightly more expressive.
>>>
>>> As it is right now in Swift, accessing methods directly gives you a curried
>>> function back, which expects the object instance as argument in the first
>>> call, and the rest in the second call.
>>> E.g. String.hasPrefix("abcd")("a") is the same as "abcd".hasPrefix("a")
>>>
>>> Flipping the arguments like this:
>>> func flip<A, B, C>(f: A -> B -> C) -> (B -> A -> C) {
>>> return { valB in
>>> return { valA in
>>> return f(valA)(valB)
>>> }
>>> }
>>> }
>>>
>>> String.hasPrefix("abcd")("a")
>>> let myHasPrefix = flip(String.hasPrefix)
>>> myHasPrefix("a")("abcd")
>>>
>>> …would allow us to write the following:
>>> s.predicate = flip(String.hasPrefix("abcd"))
>>>
>>> Perhaps it could be extended to something akin to
>>> s.predicate = String::hasPrefix("abcd")
>>>
>>> The currying only works for methods and not for properties, so this isn’t
>>> currently possible to express like the above:
>>> ["John", "Rachel", "Thomas"].map({ $0.endIndex })
>>> ["John", "Rachel", "Thomas"].map({ $0.characters.count })
>>>
>>> —Johan
>>>
>>>> On Fri, Dec 18, 2015 at 2:05 PM, Matthew Johnson via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>>> On Dec 18, 2015, at 6:52 AM, Al Skipp <al_sk...@fastmail.fm> wrote:
>>>>>
>>>>> On 18 Dec 2015, at 03:27, Matthew Johnson via swift-evolution
>>>>> <swift-evolution@swift.org> wrote:
>>>>>
>>>>> Swift currently offers dot shorthand for static members of type Self in
>>>>> type contexts expecting a value of the type in question. This is most
>>>>> commonly used with enum cases.
>>>>>
>>>>> Swift does not currently offer shorthand for instance members.
>>>>> Introducing a shorthand for instance members would improve clarity and
>>>>> readability of code in common cases:
>>>>>
>>>>> anArray.map{$0.anInstanceMethod()}
>>>>>
>>>>> becomes:
>>>>>
>>>>> anArray.map(.anInstanceMethod())
>>>>>
>>>>> This shorthand would work in typing contexts expecting a single argument
>>>>> function. It would allow abbreviated access to any visible instance
>>>>> property getter or instance method on the type of the argument. Of
>>>>> course the return type would need to match the return type expected by
>>>>> the context or a type mismatch compiler error would occur.
>>>>>
>>>>> The readability advantage is arguably small but it does exist. The
>>>>> feature also aligns very well with an existing language feature.
>>>>>
>>>>> I think it’s an interesting idea and am wondering whether others feel
>>>>> like it is something worth pursuing or not.
>>>>>
>>>>> Matthew
>>>>
>>>> I’d be interested to hear peoples thoughts regarding this proposal. I’m
>>>> personally in favour, but perhaps there are potential issues with the
>>>> suggestion?
>>>>
>>>> It’s only a small visual change, but I think it is a syntactic
>>>> improvement. Let’s pretend for a moment that the current syntax was:
>>>> anArray.map(.anInstanceMethod())
>>>>
>>>> I’m not sure many people would argue for it to be changed to:
>>>> anArray.map { $0.anInstanceMethod() }
>>>
>>> Thanks Al. I should have also pointed out that the syntactic advantage is
>>> a bit greater in other contexts where the braces would not replace
>>> parentheses:
>>>
>>> struct S {
>>> var predicate: String -> Bool
>>> }
>>>
>>> var s = S()
>>> s.predicate = { $0.hasPrefix(“abc”) }
>>>
>>> vs
>>> s.predicate = .hasPrefix(“abc”)
>>>
>>> It’s not a super important change, but maybe a low-hanging fruit item that
>>> can improve clarity and readability.
>>>
>>> Matthew
>>>
>>>
>>> _______________________________________________
>>> 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
