Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> Am 22.04.2017 um 05:41 schrieb BJ Homer via swift-evolution > : > > The "Access Control" section of the Swift 3 book says the following: > >> You can mark an extension with an explicit access-level modifier (for >> example, private extension) to set a new default access level for all >> mem

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> Am 21.04.2017 um 20:48 schrieb Xiaodi Wu via swift-evolution > : > > On Fri, Apr 21, 2017 at 1:45 PM, Erica Sadun > wrote: > >> On Apr 21, 2017, at 12:40 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Fri, Apr 21, 2017 a

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> On Apr 21, 2017, at 11:48 AM, Xiaodi Wu via swift-evolution > wrote: > > This goes to my question to David Hart. Isn't this an argument for a feature > to allow breaking a single-line string literal across multiple lines? What > makes this a use case for some feature for _multiline_ string l

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> On 22 Apr 2017, at 10:38, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 21, 2017, at 11:48 AM, Xiaodi Wu via swift-evolution >> wrote: >> >> This goes to my question to David Hart. Isn't this an argument for a feature >> to allow breaking a single-line string literal across

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> On 22 Apr 2017, at 10:21, Thorsten Seitz via swift-evolution > wrote: > > >> Am 21.04.2017 um 20:48 schrieb Xiaodi Wu via swift-evolution >> : >> >> On Fri, Apr 21, 2017 at 1:45 PM, Erica Sadun wrote: >>> On Apr 21, 2017, at 12:40 PM, Xiaodi Wu via swift-evolution wrote: >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization

> On 20 Apr 2017, at 19:08, Tony Parker via swift-evolution > wrote: > > Hi everyone, > > Thanks for your feedback on this proposal. Based on that plus additional > feedback from core team members and others who responded off-thread, we are > making the following small adjustments: > > * Ke

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

On Sat, Apr 22, 2017 at 3:21 AM, Thorsten Seitz wrote: > > Am 21.04.2017 um 20:48 schrieb Xiaodi Wu via swift-evolution < > swift-evolution@swift.org>: > > On Fri, Apr 21, 2017 at 1:45 PM, Erica Sadun wrote: > >> >> On Apr 21, 2017, at 12:40 PM, Xiaodi Wu via swift-evolution < >> swift-evolution

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

On Sat, Apr 22, 2017 at 3:38 AM, Brent Royal-Gordon wrote: > On Apr 21, 2017, at 11:48 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > This goes to my question to David Hart. Isn't this an argument for a > feature to allow breaking a single-line string literal across m

Re: [swift-evolution] "Universal Error" testing method

| https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035965.html My experience with XCTest and optionals recently was that XCTest runs in a separate process and reloads the application for subsequent tests. I auto-converted some Java code and added force-unwrap everywhere as a

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

I'm not sure how we could implement breaking lines with \ for single line strings. Either indentation has to be stripped from the broken line, or the line must not be indented in which case nothing has been gained because soft wrap would accomplish the same thing. (Is there an option I'm missing

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

On Sat, Apr 22, 2017 at 10:35 AM, Robert Bennett wrote: > I'm not sure how we could implement breaking lines with \ for single line > strings. Either indentation has to be stripped from the broken line, or the > line must not be indented in which case nothing has been gained because > soft wrap w

[swift-evolution] [Pitch] Minor adjustment to new FixedWidthInteger protocol

Just a minor pitch here, based on user experience: With SE-0104, the `addWithOverflow` family of arithmetic operators are not longer static, they have been renamed `addingReportingOverflow`, and their return type has been changed from `(T, Bool)` to `(partialValue: T, overflow: ArithmeticOverflow)

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

On Sat, Apr 22, 2017 at 10:42 AM, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 10:35 AM, Robert Bennett > wrote: > >> I'm not sure how we could implement breaking lines with \ for single line >> strings. Either indentation has to be stripped from the broken line, or the >> line must not be indente

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution > wrote: > > The "Access Control" section of the Swift 3 book says the following: >> You can mark an extension with an explicit access-level modifier (for >> example, private extension) to set a new default access level for all >> m

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> Am 22.04.2017 um 17:08 schrieb Xiaodi Wu : > > On Sat, Apr 22, 2017 at 3:21 AM, Thorsten Seitz > wrote: > >> Am 21.04.2017 um 20:48 schrieb Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>>: >> >> On Fri, Apr 21, 2017 at 1:45 PM, Erica Sadun > <

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

On Sat, Apr 22, 2017 at 12:57 PM, Thorsten Seitz wrote: > > Am 22.04.2017 um 17:08 schrieb Xiaodi Wu : > > On Sat, Apr 22, 2017 at 3:21 AM, Thorsten Seitz > wrote: > >> >> Am 21.04.2017 um 20:48 schrieb Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org>: >> >> On Fri, Apr 21, 2017 at

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution < swift-evolution@swift.org> wrote: > > > On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution < > swift-evolution@swift.org> wrote: > > The "Access Control" section of the Swift 3 book says the following: > > You can ma

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

+1 Extensions are a great feature and I’m really glad that Swift has them. Conflicts should be handled by improving import and disambiguation features like Xiaodi says which is useful for other cases as well. -Thorsten > Am 18.04.2017 um 03:47 schrieb Xiaodi Wu via swift-evolution > : > > S

Re: [swift-evolution] [pitch] Comparison Reform

on Tue Apr 18 2017, Ben Cohen wrote: >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution >> wrote: >> >> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >>> wrote: >>> > >>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution wrote: >

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> Am 22.04.2017 um 21:27 schrieb Xiaodi Wu : > > On Sat, Apr 22, 2017 at 12:57 PM, Thorsten Seitz > wrote: > >> Am 22.04.2017 um 17:08 schrieb Xiaodi Wu > >: >> >> On Sat, Apr 22, 2017 at 3:21 AM, Thorsten Seitz >

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 22, 2017, at 12:30 PM, Xiaodi Wu wrote: > >> On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution >> wrote: >> >> >>> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution >>> wrote: >>> >>> The "Access Control" section of the Swift 3 book says the follow

Re: [swift-evolution] [pitch] Comparison Reform

on Tue Apr 18 2017, Xiaodi Wu wrote: > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> On Apr 17, 2017, at 9:07 AM, Joe Gro

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 22, 2017, at 2:05 PM, Jose Cheyo Jimenez wrote: > > > >> On Apr 22, 2017, at 12:30 PM, Xiaodi Wu wrote: >> >>> On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution >>> wrote: >>> >>> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution wrote

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: > > on Tue Apr 18 2017, Xiaodi Wu wrote: > > > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution < > >> swift-e

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: > > on Tue Apr 18 2017, Xiaodi Wu wrote: > > > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution < > >> swift-e

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

On Sat, Apr 22, 2017 at 4:05 PM, Jose Cheyo Jimenez wrote: > > > On Apr 22, 2017, at 12:30 PM, Xiaodi Wu wrote: > > On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution

Re: [swift-evolution] [pitch] Comparison Reform

Maybe we should make Float/Double conform to "IEEE754Comparable"/"IEEE754Equatable" instead of "Comparable"/"Equatable". Then it's all a moot point since floating point types wouldn't end up in the same generic functions as other comparable types. (Not sure if I'm serious) - Dave Sweeris > On

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 5:39 PM, David Sweeris wrote: > Maybe we should make Float/Double conform to "IEEE754Comparable"/" > IEEE754Equatable" instead of "Comparable"/"Equatable". Then it's all a > moot point since floating point types wouldn't end up in the same generic > functions as other comp

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: > >> >> on Tue Apr 18 2017, Xiaodi Wu wrote: >> >> > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < >> > swift-evolution@swift.org> wrote: >> > >> >> >> >> On Apr 17, 2017, at 9:40 P

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 5:51 PM, Dave Abrahams wrote: > > on Sat Apr 22 2017, Xiaodi Wu wrote: > > > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams > wrote: > > > >> > >> on Tue Apr 18 2017, Xiaodi Wu wrote: > >> > >> > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < > >> > s

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 5:51 PM, Dave Abrahams wrote: > > on Sat Apr 22 2017, Xiaodi Wu wrote: > > > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams > wrote: > > > >> > >> on Tue Apr 18 2017, Xiaodi Wu wrote: > >> > >> > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < > >> > s

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, David Sweeris wrote: > Maybe we should make Float/Double conform to > "IEEE754Comparable"/"IEEE754Equatable" instead of > "Comparable"/"Equatable". Then it's all a moot point since floating > point types wouldn't end up in the same generic functions as other > comparable type

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: > >> >> on Tue Apr 18 2017, Xiaodi Wu wrote: >> >> > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < >> > swift-evolution@swift.org> wrote: >> > >> >> >> >> On Apr 17, 2017, at 9:40 P

Re: [swift-evolution] [pitch] Comparison Reform

Sent from my iPad > On Apr 22, 2017, at 4:53 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: >> >> on Tue Apr 18 2017, Xiaodi Wu wrote: >> >> > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < >> > swift-evolution@swif

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 22, 2017, at 6:55 PM, Xiaodi Wu wrote: > > Yes. Specifically, in floating point code. I guess that's the part about > shaping the rug not to cover the bump. IEEE does not require `==` to be the > spelling of the quiet equality comparison operator, and it does specifically > describe

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 7:02 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Apr 22, 2017, at 4:53 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams > wrote: > >> >> on Tue Apr 18 2017, Xiaodi Wu wrote: >> >> > O

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 6:37 PM, Dave Abrahams wrote: > > >> > To be clear, this proposal promises that `[0 / 0 as Double]` will be > made > >> > to compare unequal with itself, yes? > >> > >> Nope. > >> > >> As you know, equality of arrays is implemented generically and based on > >> the equata

Re: [swift-evolution] [pitch] Comparison Reform

On Sat, Apr 22, 2017 at 7:37 PM, Stephen Canon wrote: > > On Apr 22, 2017, at 6:55 PM, Xiaodi Wu wrote: > > Yes. Specifically, in floating point code. I guess that's the part about > shaping the rug not to cover the bump. IEEE does not require `==` to be the > spelling of the quiet equality comp

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

My 2c on access control regarding extensions + global variables: Another annoyance from SE-0025 was that "private" and "fileprivate" modifiers meant the same thing when dealing with extensions and global variables. Obviously this was for good reasons, but still seemed weird. Regarding extension

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 6:37 PM, Dave Abrahams wrote: > > >> >> >> > To be clear, this proposal promises that `[0 / 0 as Double]` will be >> made >> >> > to compare unequal with itself, yes? >> >> >> >> Nope. >> >> >> >> As you know, equality of arrays is

Re: [swift-evolution] [pitch] Comparison Reform

On Apr 22, 2017, at 6:06 PM, Xiaodi Wu wrote: > but my quick reaction to `&==` is that it would make me quite nervous to have > `==` not bound to 754-equals as it is in essentially every other language. In > particular, I worry about the risk of people porting numerical code that > depends on i

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 22, 2017, at 9:58 PM, Chris Lattner wrote: > > I don’t think that this proposal is acceptable as written. I think it is > really bad that abstracting a concrete algorithm would change its behavior so > substantially. I don’t care about SNaNs, but I do care about the difference > be

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> Le 22 avr. 2017 à 22:58, Thorsten Seitz via swift-evolution > a écrit : > > You seem to be choosing to deliberately ignore what I (and others) write. Yes. I suggest people who want to hard wrap long strings literals to write a new proposal, on top of SE-0168 which has been accepted now. T

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution > wrote: > > I don’t think that this proposal is acceptable as written. I think it is > really bad that abstracting a concrete algorithm would change its behavior so > substantially. I don’t care about SNaNs, but I do care ab