Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

Hi Chris, I see, well with that in mind the proposal does set out how ?: is harmful to comprehension of code for new programmers and I hope the pros and cons of keeping it are thoroughly vetted. Regards, Charlotte > On 26 Oct. 2016, at 16:52, Chris Lattner wrote: > > >>> On Oct 25, 2016, a

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

> On Oct 25, 2016, at 10:30 PM, Charlotte Angela Tortorella via swift-evolution > wrote: > >> Not a replacement for the Swift 4 source stability goal. > > Swift 4 doesn't actually have a source stability goal. It has an ABI > stability goal. These are two very different things. ABI is the ca

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

> On Oct 25, 2016, at 10:30 PM, Charlotte Angela Tortorella > wrote: > >> Not a replacement for the Swift 4 source stability goal. > > Swift 4 doesn't actually have a source stability goal. It has an ABI > stability goal. These are two very different things. ABI is the calling > conventions

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

> Not a replacement for the Swift 4 source stability goal. Swift 4 doesn't actually have a source stability goal. It has an ABI stability goal. These are two very different things. ABI is the calling conventions of the language. > So, a programmer learns what '?:' means the first time she enco

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

> On Oct 25, 2016, at 10:13 PM, Charlotte Angela Tortorella > wrote: > > Addressing breaking source code: this is something that an auto migrator > could extremely easily be written for. Auto migrators are: - Specific to Xcode, and therefore OS X Swift development using a very specific toolc

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

Addressing breaking source code: this is something that an auto migrator could extremely easily be written for. Addressing your first point, `?:` has the advantage of terseness. Your solution requires a lot of code repetition and invariably a programmer will eventually have to deal with `?:` wh

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

Strong -1. I don't feel like stylistic concerns alone are a good enough reason to introduce a change that will undoubtedly break source compatibility for many, many projects come Swift 4. That aside, I don't agree with the arguments that the ternary operator is confusing. 1. If you don't know

[swift-evolution] [Pitch] Replace the ternary operator with an in-language function

Preamble: I've read over the threads that already exist about the ternary operator and to be honest they're a complete mess without a single fully formed proposal. Pitch: I'd like to simplify the syntax, compiler complexity and learning curve for newcomers when it comes to dealing with the tern

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 25, 2016, at 3:08 PM, Anton Zhilin via swift-evolution > wrote: > > Why can't we just remove distinction between operator and identifier symbols? > I'd be fine with the following: This has been discussed in prior threads: it is core to the behavior of the parser. -Chris __

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

> On Oct 25, 2016, at 10:20 AM, Joe Groff via swift-evolution > wrote: > > At this point in Swift's evolution, source-breaking changes to the language > require strong motivation. We can't really entertain superficial keyword > changes like this without overwhelming evidence that the existing

Re: [swift-evolution] [Bug] Foundation.URL should support semicolon(; ) appearing in URL path

on Tue Oct 25 2016, "Cao, Jiannan via swift-evolution" wrote: > http://host/book;id=1/page;2/ > > this URL is a valid URL, but URLComponents will ruin it with %3B > http://host/book%3Bid=1/page%3B2/ > > Since Swift Server is coming out, this bug should be solved. Hi Jiannan, At least for now,

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

-1. I'm not enthusiastic about using ~=. IMO it's only a small improvement over the "if case let..." hieroglyphics and still too cryptic. Like the others, I really like "matches" or some other, more explicit, keyword. Anything more general around pattern-matching should probabl

Re: [swift-evolution] [Bug] Foundation.URL should support semicolon(; ) appearing in URL path

> On Oct 25, 2016, at 12:50 PM, Saagar Jha via swift-evolution > wrote: > > This is expected behavior. The semicolon character is reserved in URLs, and > it requires escaping if it is used. This is not accurate: "If data for a URI component would conflict with a reserved character's purp

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> Am 26.10.2016 um 00:08 schrieb Anton Zhilin via swift-evolution > : > > Why can't we just remove distinction between operator and identifier symbols? > I'd be fine with the following: > > ```swift > infix operator map > infix func map(lhs: [Int], rhs: (Int) -> Int) { ... } > [1,2,3] map {$0*

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Why can't we just remove distinction between operator and identifier symbols? I'd be fine with the following: ```swift infix operator map infix func map(lhs: [Int], rhs: (Int) -> Int) { ... } [1,2,3] map {$0*2} ``` No explicit imports required, plus we can create nice DSLs. Of course, it's an add

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

Haravikk, I fully agree with you; before I read your post I thought I’d write exactly that. if matches 1. Another “ideological” reason: = is just an operator, so lhs = rhs should be an expression, but meaning of = is overloaded in this context. On the other hand, when you see a keyword, you can’

Re: [swift-evolution] [Bug] Foundation.URL should support semicolon(; ) appearing in URL path

This is expected behavior. The semicolon character is reserved in URLs, and it requires escaping if it is used. On Tue, Oct 25, 2016 at 12:05 Cao, Jiannan via swift-evolution < swift-evolution@swift.org> wrote: > > http://host/book;id=1/page;2/ > > this URL is a valid URL, but URLComponents will r

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

> On Oct 25, 2016, at 11:44 AM, Jay Abbott wrote: > > Hey Joe, > > I tend to agree, it seems like a tiny niggle for experienced C-family > developers who have used if(negative condition) as a guard for years, and > those with knowledge in other languages where it is already known. But for >

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

There is more difference between “guard” and “ensure”. “Guarding” is something you do at the gate, not just everywhere. This has imo an impact on how code is structured. (It did for me) “Ensuring” is something you can do everywhere. Myself, I tend to use “guard” mostly at the beginning of a routin

[swift-evolution] [Bug] Foundation.URL should support semicolon(; ) appearing in URL path

http://host/book;id=1/page;2/ this URL is a valid URL, but URLComponents will ruin it with %3B http://host/book%3Bid=1/page%3B2/ Since Swift Server is coming out, this bug should be solved. ___ swift-evolution mailing list swift-evolution@swift.org h

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

Hey Joe, I tend to agree, it seems like a tiny niggle for experienced C-family developers who have used if(negative condition) as a guard for years, and those with knowledge in other languages where it is already known. But for new developers, learning the language of the future as a first-languag

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I’m also -1 on disallowing emojis as identifiers. As it was stated may times before, emojis are an important part of modern communication, especially between young people and kids. I understand the complexity of keeping them around, especially if they are not well-defined by Unicode and if they

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 24, 2016, at 10:40 PM, Russ Bishop wrote: > >> >> On Oct 24, 2016, at 9:43 AM, Joe Groff via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Oct 23, 2016, at 9:41 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

At this point in Swift's evolution, source-breaking changes to the language require strong motivation. We can't really entertain superficial keyword changes like this without overwhelming evidence that the existing syntax is problematic in practice. `guard` has precedent in functional languages,

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

> > I don’t read “*Guard that x is higher than 0 else … *”, but instead I > read it like “*Guard! x must be higher than 0 else …*”. > > I see, yes I hadn't considered this interpretation... > > Probably adding a colon could make it more clear to the reader: > > guard: x > 0 else { > return >

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

> On Oct 25, 2016, at 10:38 AM, Jay Abbott via swift-evolution > wrote: > > I mentioned this in passing on a different thread > . > Although it caused some slight confusion when I first learned the 'guard' >

[swift-evolution] [pitch] rename 'guard' to 'ensure'

I don’t really mind the “guard” keyword after having used it hundreds of times, but it didn’t really make a lot of sense to me to start with (I’m not a native speaker). “ensure” definitely conveys the meaning better, in my opinion. I’d be in favor of this change. I bet most people won’t think i

[swift-evolution] announcing Server APIs work group

Hi everyone, I’d like to announce the introduction of a new Server APIs work group: https://swift.org/blog/server-api-workgroup/ From the blog post: "Since Swift became available on Linux there has been a huge amount of interest in using Swift on the server, resulting in the emergence of a n

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

The issue is that in English, 'guard' has an inverted logical connotation to how it is used in Swift. For example, take this sentence: "In some functions it's a good idea is to put some checks in place, in order to guard against invalid input values." That’s a good point, but I think it depends

[swift-evolution] [pitch] rename 'guard' to 'ensure'

I mentioned this in passing on a different thread . Although it caused some slight confusion when I first learned the 'guard' keyword, it was easy to overcome and I didn't think the issue was strong enough to warran

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> On Oct 24, 2016, at 10:15 PM, Chris Lattner wrote: > >> >> On Oct 24, 2016, at 9:40 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Oct 22, 2016, at 5:53 PM, Jonathan S. Shapiro >>> wrote: >>> >>> I missed this earlier posting from Joe Groff, who wrote: >>> >>> In the discuss

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

Hi, I agree removing the "case" word after the "if" / "guard", but I prefer removing it completely rather then make it optional to limit the number of different implementation. Regarding the operator, I agree that it can be improved because we should find something that contains two different

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

> On 25 Oct 2016, at 14:15, Haravikk wrote: > > Lastly, on it being more readable the issue isn't general readability but > rather discoverability. If you see "if x matches .some(let y)" or "if x is > let y?" then there's some immediate context for what's going on the first > time you see it

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

> On 25 Oct 2016, at 12:44, Jeremy Pereira via swift-evolution > wrote: >> If possible, I think it would be nice to make the “case” after the “if” or >> “guard” optional. But that would be enough imo. >> Alternatively replacing the “~=“ with a different keyword (and dropping the >> “case”) cou

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

> On 25 Oct 2016, at 08:13, Rien via swift-evolution > wrote: > > I have tried to like this because at first it seems like a good idea. > But having let it shimmer for a while, I simply cannot muster the enthusiasm > for it. Using “~=“ does not ‘feel’ right to me. Especially for a code > brea

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Unfortunately, Joe is correct on this point. As I stated earlier in the thread, there are a series of characters that can be either text or emoji in presentation, where the default presentation differs depending on platform, technology, use case, or context. This is also not a bug, but explicitly c

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

I have tried to like this because at first it seems like a good idea. But having let it shimmer for a while, I simply cannot muster the enthusiasm for it. Using “~=“ does not ‘feel’ right to me. Especially for a code breaking change at this stage. There are probably already a number of user defin