Re: [swift-evolution] [proposal] extra if syntax

[Krzysztof Siejkowski via swift-evolution]

And what is with ‘a’ if this situation:

if b == x {
a = 5
}

Nothing :)
Well, it’s not nothing, it has the same value that it had before.

However, as pointed by Leonardo Pessoa, there is a problem with expression:

let a = 5 if b == x

It is equivalent to:

if b == x {

    let a = 5 

} 

but doesn’t communicate clearly that in the next line `a` is already out of 
scope and that you cannot write:

let a = 5 if b == x

let c = a // a is not defined here

but you can write:

let a = 1 if b == x 

let a = 2 if b == x // other a from other scope

let a = 3 if b == x // another a from another scope

without error concerning immutability.

Austin Zheng has also rightly pointed that this “postfix” syntax looks as if 
the if-statement is now an expression, which will further confuse people coming 
from languages that use if-expressions.

Also, I find:

{

    // … a lot of code 

} if b == x

way less readable, simply because I read top to bottom. This syntax makes me 
search for the scope delimiter, understand the condition and only after lets me 
read the logic.



All the best,

Krzysztof



___
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] [Review] SE-0081: Move where clause to end of declaration

[Krzysztof Siejkowski via swift-evolution]

* What is your evaluation of the proposal?
+1

More readable.

* Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes. Current form of defining requirements makes deciphering the signatures 
with high number of requirements a logical riddle.



* Does this proposal fit well with the feel and direction of Swift?
I do think so. It’ll further encourage the use of generics, which I see as one 
of the cornerstones of Swift.



* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Not that I can think of, but now I’d like to see similar change in Scala :)



* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I’ve read proposal and corresponding discussion.



All the best,

Krzysztof___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Krzysztof Siejkowski via swift-evolution]

* What is your evaluation of the proposal?
-1

While I appreciate the ease of reordering and commenting out that the proposal 
brings, I think it hurts readability. Also, it seems to me that keeping the 
commas in check is a job of a IDE, not language syntax feature. 

The analogy for me is the Lisp parentheses problem. It’s often even more 
difficult to manage parens while editing and commenting code. Instead of 
providing a language syntax feature that makes the number of trailing parents 
flexible, it was better solved with IDE feature called Parinfer.



* Is the problem being addressed significant enough to warrant a change to 
Swift?
I do not think so. It’s a minor issue with minor consequences.



* Does this proposal fit well with the feel and direction of Swift?
The only part of Swift “feel and direction” that I think can be of relevance is 
its focus on educational cases. I do not have any data concerning whether 
trailing commas will be easier or harder to grasp by the students. However, 
it’s one more think to explain.



* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
I’ve used a little Python and JavaScript. I didn’t use this feature in those 
languages, but it was just me. I think it fits better with their scripting 
style, where by “scripting” I mean very forgiving, very flexible (multiple ways 
to achieve the same effect) and hardly ever preventing you from making 
mistakes. I think Swift was always trying to drive away from this attitude and 
replace it with “scripting syntax for safe language” one.



* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I’ve read the proposal and related discussion.



All the best,

Krzysztof___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Switch on an optional enum -- `case: nil`?

[Krzysztof Siejkowski via swift-evolution]

It doesn’t compile because you’re switching on the Optional and trying to 
pattern match it to Coin.

It compiles right when you pattern match it to Optional:

switch result {
case .heads?: print("heads")
case .tails?: print("tails")
case nil: print("not yet flipped")
}

Best,
Krzysztof

On 5 May 2016 at 17:42:24, Eric Miller via swift-evolution 
(swift-evolution@swift.org) wrote:

Wondering if you guys think this is a reasonable idea.

I was switching on an optional enum today, and naturally gravitated towards 
including nil as a case:

enum Coin {
  case heads
  case tails
}
var result: Coin?

switch result {
case heads: print("heads")
case tails: print("tails")
case nil: print("not yet flipped") // exhaustive
}

Doesn't compile, and of course I can if-let or guard to unwrap instead, but I 
like the compactness of this.
___
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] [Idea] Remove optional pattern binding

[Krzysztof Siejkowski via swift-evolution]

Question coming of a pure curiosity, although somewhat related: isn’t the fact 
that the Optional is an enum just an implementation detail? I thought this was 
the case.

>From this perspective `if let value = optional` is and will stay an 
>optional-only syntax regardless of the implementation. `if case let 
>.some(value) = optional` is just a special case of applying the pattern 
>matching, which is related to the Optional type only via the current 
>implementation.


Cheers,
Krzysztof

On 2 May 2016 at 20:47:49, Chris Lattner via swift-evolution 
(swift-evolution@swift.org) wrote:

On May 2, 2016, at 11:12 AM, John McCall via swift-evolution 
 wrote:
>  
>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution 
>>  wrote:
>>> On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>>  
 Pattern binding for optionals will look like:
  
 if let x? = y { ... }
>>>  
>>> I suggested precisely this in February. The core team shot it down:
>>>  
 We tried this* and got a lot of negative feedback. Optionals are unwrapped 
 too often for people to be comfortable writing "if let name? = 
 optionalCondition".
>>>  
>>>  
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008964.html
>>>  
>>> Having said that, this still seems like a good idea to me, but they're the 
>>> ones with implementation experience; all I have is an elegant idea.
>>  
>> Yeah, as nice as it sounds, it didn’t work out in practice. I’ll add it to 
>> the frequently-suggested list.
>  
> Yeah. My take on it is that 'if let' was probably a mistake, but once we made 
> it, it was really hard to back out.

I understand that you (and probably a ton of other people on this list) feel 
that way, but I disagree pretty strongly. I think we have the right design here.

Context: As was mentioned up-thread, in the Swift 2 development cycle, we 
significantly extended pattern matching (this is when we added ‘if case’, etc). 
One of the things we implemented - but then backed out - was exactly the 
proposal above. We did this because we found it to be the *wrong* thing to do.

The reason is simple: most developers don’t grok pattern matching. Particularly 
for people new to swift, “if let” is taught as a magic for dealing with 
optionals (which it is). This is a very useful mechanic when working in Swift, 
and this way of thinking is fine. Optionals are very prominent, and having 
special sugar for dealing with them is important, even as people grow to become 
swift experts in time.

Going with the proposal would definitely simplify the language ('if case’ could 
probably go away), but would force everyone, all the time, to think about 
pattern matching. This would be a barrier to entry that many programmers should 
never have to face. The fact that many people don’t think about things in terms 
of pattern matching is the root cause for the comments about “it seems weird 
that the question mark is on the LHS of the assignment”.

Finally, some may argue that making pattern matching more prominent would help 
teach pattern matching and get more people to use it. That may be true, but our 
goal here is to build a pragmatic language that helps people get things done, 
not push to one specific language feature. I personally love pattern matching 
(and was the one who drove and implemented the Swift 2 pattern matching 
enhancements), but it is an esoteric and special case feature. It makes sense 
for it to be “buried” under “if case”: those who are unfamiliar with the syntax 
have something they can google for.

-Chris
___
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