Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

[Johan Jensen via swift-evolution]

-1 for the aforementioned reasons by David Waite and T.J. Usiyan.

On Thu, Jun 16, 2016 at 9:51 PM, Patrick Pijnappel via swift-evolution <
swift-evolution@swift.org> wrote:

> Due to considerably support on this thread
> ,
> a draft proposal to revisit the core functional method exceptions to the
> -ed/-ing rule.
>
> Online version:
> https://github.com/PatrickPijnappel/swift-evolution/blob/functional-methods-ed-ing/proposals/-functional-methods-ed-ing.md
>
> Apply -ed/-ing rule to core functional methods
>
>- Proposal: SE-
>
> 
>- Author: Patrick Pijnappel 
>- Status: Awaiting review
>- Review manager: TBD
>
>
> 
> Introduction
>
> The Swift API Guidelines standardizes non-mutating method forms on verbs
> ending in -ed/-ing (or nouns). However, a few non-mutating forms have been
> kept as "Terms of Art": map, flatMap, filter, reduce, dropFirst and
> dropLast. This proposal proposes to bring these in line with all other
> non-mutating forms (e.g. filter => filtered).
>
> Swift-evolution threads: Source
> 
>
> 
> Motivation
>
> These method have been kept to preserve the terms of art. Generally, this
> can have significant benefits:
>
>- Anyone familiar with the term will immediately understand it, and
>use their assumptions about how it works.
>- Users learning the term from Swift can use their knowledge when
>encountering it elsewhere.
>- Experienced users will be able to use the mental pattern matching
>they've built-up for quickly recognizing common programming patterns.
>
> However, basically all of the benefits of using a term of art still apply
> to the modified forms: – For recognition, the modified forms are still very
> close to the traditional terms of art. So both coming to and from Swift
> you'll be able to use your knowledge pretty much unaffected.
>
>- If the user looks for e.g. filter they are pretty much guaranteed to
>quickly find the correct form, be it through code-completion, google or a
>fix-it.
>- There isn't really any violation of assumptions that might cause
>problems in this case.
>- Any mental pattern matching will likely transfer quickly due to the
>minimal difference.
>
>
> Proposed
> solution
>
> The proposed solution modifies the method verbs to their -ed/-ing forms
> (preferring the former).
>
> It removes the last clear exceptions to the -ed/-ing rule from the
> standard library, which previously were exactly the opposite of what one
> would expect based on the API guidelines (and the rest of the language).
>
> It also aids users in learning to pattern match on the -ed/-ing rule and
> internalizing the API guidelines, since now all methods are named this way
> – instead of the most commonly used methods defying the normal pattern.
>
> Detailed
> design
>
> The change would rename the following method families:
>
> map   => mapped
> flatMap   => flatMapped
> filter=> filtered
> reduce=> reduced
> dropFirst => droppingFirst
> dropLast  => droppingLast
>
>
> Impact
> on existing code
>
> The Swift migrator and fix-its would be provided for the change.
>
> Alternatives
> considered
>
>- Alternatively -ing suffixes could be used for map/flatMap/filter/
>reduce. However, these are normally reserved for when -ed doesn't
>really work (e.g. droppedFirst).
>
>
> ___
> 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

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

[Johan Jensen via swift-evolution]

Currently `if case let (foo?, bar?, baz?) = (_foo(), _bar(), _baz())`, and
_bar() returns nil, then `_baz()` will not be evaluated.

On Mon, Jun 13, 2016 at 2:54 AM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> What's the behavior currently with `if case let (foo?, bar?, baz?)...`?
>
> On Sun, Jun 12, 2016 at 19:53 plx via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> This proposal should specify if the tuple is evaluated “eagerly” or as an
>> “early-exit”.
>>
>> That is, if we write `if let (foo,bar,baz) = (_foo(), _bar(), _baz())`,
>> and _bar() -> nil, will `_baz()` have been evaluated, or not?
>>
>> I’d use this feature either way, but the proposal should have a clear
>> statement on this point.
>>
>> On Jun 12, 2016, at 6:46 AM, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> When I suggested this syntax in the acceptance thread for SE-0099, Chris
>> said it should be written up as a proposal. I'm sure this will get lost in
>> the WWDC shuffle, but here goes.
>> Tuple-Based Compound Optional Binding
>>
>>- Proposal: TBD
>>- Author: Brent Royal-Gordon 
>>- Status: TBD
>>- Review manager: TBD
>>
>>
>> 
>> Introduction
>>
>> This proposal enhances optional binding with a new, tuple-based syntax
>> for binding multiple values. It replaces functionality lost in SE-0099 with
>> a syntax compatible with the new design.
>>
>> Swift Evolution Discussion: [Accepted with Revision] SE-0099
>> Restructuring Condition Clauses
>> 
>>
>> 
>> Motivation
>>
>> In Swift 2, it was possible to bind multiple optional values in a single if
>> let, guard let, or while let clause:
>>
>> guard let a = opt1, b = opt2, c = opt3 else { ... }
>>
>> SE-0099
>> 
>>  simplified
>> the syntax of conditional statements, but removed this feature so that , 
>> could
>> instead separate different conditional clauses. Code like this must now use
>> three separate optional binding clauses:
>>
>> guard let a = opt1, let b = opt2, let c = opt3 else { ... }
>>
>> The similar case clause sidesteps this problem because it can
>> pattern-match tuples. Hence, you can put several patterns in a tuple on the
>> left side of the =, and a matching number of values in a tuple on the
>> right side, and match them all with one case clause:
>>
>> guard case (.none, .none, .none) = (opt1, opt2, opt3) else { ... }
>>
>> This doesn't conflict with the clause separation syntax because the
>> commas are within parentheses. However, the analogous syntax for optional
>> bindings is not permitted:
>>
>> guard let (a, b, c) = (opt1, opt2, opt3) else { ... }// error: initializer 
>> for conditional binding must have // Optional type, not '(Int?, Int?, Int?)' 
>> (aka // '(Optional, Optional, Optional)')
>>
>>
>> Proposed
>> Solution
>>
>> We should extend optional binding clauses to permit a tuple of optional
>> values on the right of the = and a tuple of constants with identical
>> arity on the left. Swift should test each element of the tuple on the
>> right, and if none of them are nil, bind them to the constants on the
>> left.
>>
>> Nothing in this proposal should change the way optional binding handles
>> an *optional tuple* (T, U)?, as opposed to a *tuple of optionals* (T?,
>> U?). Even an optional tuple of optionals (T?, U?)? should continue to be
>> handled as before.
>>
>> Detailed
>> Design
>>
>> No change to the formal grammar is necessary, as the *pattern* and
>> *initializer* productions in the *optional-binding-head* rule can
>> already match tuples:
>>
>> optional-binding-head : 'let' pattern initializer
>>
>> Rather, Sema should be modified to detect this situation and generate
>> appropriate code. Currently, TypeCheckPattern.cpp essentially converts let
>> a = opt1 into case let a? = opt1; if this proposal is accepted, it
>> should similarly convert let (a, b) = (opt1, opt2) into case let (a?,
>> b?) = (opt1, opt2).
>>
>> Edge
>> cases
>> Nested
>> tuples-of-optionals
>>
>> Permitting deeper pattern matching of nested tuples is highly precedented
>> by pattern matching, but is a niche feature. It should be supported if
>> easily achievable.
>>
>> guard let (a, (b, c)) = (opt1, (opt2, opt3)) else { ... }
>>
>>
>> 

Re: [swift-evolution] [Idea] if let value!

[Johan Jensen via swift-evolution]

This was one of the first and most commonly suggested ideas, when the Swift
Evolution mailing list first started.
Chris Lattner sums it up

in one of those threads:

> This is commonly requested - the problem is that while it does help
reduce boilerplate, it runs counter to the goal of improving clarity.

— Johan

On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> It is common to shadow optional value name with unwrapped value with same
> name:
>
> if let someGoodValue = someGoodValue {...}
>
> What if we'll have a syntax to not repeat the variable name to achieve the
> same target:
>
> if let someGoodValue! {...}
>
> What do you think?
> ___
> 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

Re: [swift-evolution] Rename "guard" to "unless"

[Johan Jensen via swift-evolution]

On Wed, Jan 6, 2016 at 11:09 AM, James Campbell via swift-evolution <
swift-evolution@swift.org> wrote:

> What is "guard"? why its the opposite to "if"!
>

But it’s not.
guard’s else-clause requires you to transfer program control outside the
guard statement’s enclosing scope.
And any constants or variables assigned a value from an optional binding
declaration in a guard statement condition can be used for the rest of the
guard statement’s enclosing scope. That is what allows us to do `guard let
val = opt else { return }` where opt is an optional and val is the value
contained in opt if it is not nil.

Changing it to unless (and removing the else-clause) would only confuse
people coming from Ruby or similar languages, as they wouldn’t expect any
of the variable declarations to live in the guard statement’s enclosing
scope.


>
> So in other languages what have they called this, well in Ruby they called
> it "unless" which I feel is a much clearer form of intent and lower barrier
> of entry for a user. See this code.
>
> guard name != nil else {
>fatalError("Please enter a name")
> }
>
> What does that actually say if you look at it from a linguistic point of
> view, "guard that name doesn't equal nil otherwise fail", that feels very
> obtuse.
>
> With my proposal the syntax could become this:
>
> unless name != nil {
>   fatalError("Please enter a name")
> }
>
> This now reads as "unless name doesn't equal nil then fail" which I think
> is a much clearer syntax. I think this would be a great change for Swift 3.
> For me I think this is more friendly for beginners.
>
> It would support the same structure as an if block:
>
> unless name != nil {
> }
> else
> {
> }
>
> Going forward it would allow us to be more flexible if we added inline
> if/unless statement, as in Ruby.
>
> callThisMethod() if age > 0
> throwThisError() unless age <= 0
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>
> ___
> 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

Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

[Johan Jensen via swift-evolution]

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(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  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