Re: [swift-evolution] ternary operator ?: suggestion

multiary is not a natural and easy expression to pronounce. ternary was likely used originally because they could not think of something better - but at least it is easy on the tongue…. [composed of 3 parts] regardless of syntax - maybe just call it a “match expression”. > On 2016-01-07,

Re: [swift-evolution] ternary operator ?: suggestion

Is there a reason why we are reusing “?” since the proposal is to leave ternary ? : as is. And “?” is also used by optionals. Why not just use a new keyword like “match” (which I prefer better than which - but that may be because it is familiar to me :p ). then reuse the rest of switch

Re: [swift-evolution] Remove forEach?

I don’t see the benefit of taking a simple declarative expression (map, flatMap, filter) and turning it into a complicated imperative/iterative loop. You already have the ability to iterate through a set and do whatever you want to do with with whatever logic you want to use using. I would

Re: [swift-evolution] Proposal: CollectionType.cycle property for an infinite sequence

I have never tried to implement a “stream” in Swift, so I am not sure if there is an easy way to do it…. but I don’t see a collection of type stream as I have in Scala. http://www.scala-lang.org/api/current/index.html#scala.collection.immutable.Stream

Re: [swift-evolution] ternary operator ?: suggestion

That looks pretty ugly. I think the best we can hope for at this point is maybe another keyword that mirrors switch but is expression based (aka match) — leaving the ternary ? : expression as is - which is not all that bad since any if else that becomes a compound expression or more than two

Re: [swift-evolution] Lambda function syntax

Assuming that you are using : for type assignment and -> or => for functions unlabelled functions would have the syntax Int => Int not Int: Int. So func(int : Int, bool: Bool) : Int // would return a value func((int: Int, bool: Bool) : Int => Int would return a function with parameter of int

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

I prefer “type”. > On 2015-12-23, at 20:05:46, Pierre Monod-Broca via swift-evolution > wrote: > > I would agree to stop talking about associated types and start talking about > placeholder types instead. > But as a keyword, IMO the problem is that `placeholder` is

Re: [swift-evolution] Final by default for classes and methods

I thought sealed and final were effectively the same thing for production code, which is why it confuses me when you say final is right anything less including sealed is not. In Scala at least sealed is final with the exception that subclasses within the same source file are allowed. When it

Re: [swift-evolution] Community Proposal: "This Week In Swift" newsletter

You might want to take a look at http://notes.implicit.ly/ . I think it is based on something called Herald and Tumblr. Something equivalent for Swift library version announcements would be great. > On 2015-12-24, at 1:27:28, Kenny Leung via swift-evolution >

Re: [swift-evolution] Final by default for classes and methods

The “module” in this case being the same source file. i.e. Family.scala contains a sealed class called “Parent” which is sealed, you could have another class in their called “Child” which inherits from the parent. but you cannot write another class and inherit from it in Sibling.scala.

Re: [swift-evolution] Lambda function syntax

I am joining this discussion a little late - so I would not be surprised if discussed earlier. but: My preference would be: foo.map( bar => bar.boz) // single line or foo.map { bar => …. } if more than one line if there are multiple values then: foo.map

Re: [swift-evolution] Lambda function syntax

It would not prevent curly brackets for single-line cases…. just the difference between a map function call map() vs infix with scope. > On 2015-12-23, at 9:48:24, Alexander Regueiro wrote: > > Why not curly braces for single-line and multi-line cases? About the brackets

Re: [swift-evolution] ternary operator ?: suggestion

IMHO, I think the issue is that (at least in my case) we may be trying to create expression versions of “if” and “switch” (multi-line) and not are trying to create them in such a way as to keep statements and expressions as separate syntax / keywords…. which is leading to a more cryptic

Re: [swift-evolution] ternary operator ?: suggestion

I see no need to remove the existing ternary command — for simple conditions of assignment (one condition, one then value, one else value) that fit on one line…. nested conditions regardless of syntax can quickly become nightmare. What I would like to be able to do is write code in a

Re: [swift-evolution] Proposal: Support for commit comments

Amir, You might want to read the scope of swift-evolution: https://github.com/possen/swift-evolution/blob/master/process.md > On 2015-12-22, at 6:20:08, Amir Michail via swift-evolution > wrote:

Re: [swift-evolution] [Proposal] function "return" optional keyword.

ol statements. Having implicit return in that case hurts >> readability. For example, out of three possible return points within this >> function only one is not marked with return: >> >> func f(input: Int) -> Int { >> if input > 10 { >>

Re: [swift-evolution] ternary operator ?: suggestion

The complaint that you have about Javascript is more a function of it not being a strongly typed language. If you were to write a function with the type of return specified and the code inside the function (because of a single character) end up changing type for the return value or a future

Re: [swift-evolution] Proposal: Make braces optional much like semicolons.

Although I am not for braces being optional and using tab / indentation for scope, the forcing of using braces for one line scopes is overkill IMHO. If there is scope that is multiline though I would probably include scope on all of them (there is one multi-line scope in that example). So +1 /

Re: [swift-evolution] Brace syntax

Removing braces for scope would cause more problems than whatever you would gain from it - it is one character at the end of a function declaration and one at the end of a function. Using white space to (indentation sometimes is a tab, sometimes and sometimes get mixed up) scope is not the

Re: [swift-evolution] Proposal: Remove % operator for floating-point types

http://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/ > On 2015-12-19, at 4:17:45, Craig Cruden wrote: > > Floating point numbers by their very nature are