Re: [swift-evolution] [pitch] Substring performance affordances

Purely additive, so +1 from me. Side note, I’m wondering how problematic these same discussions will be in third-party library code. Should authors use StringProtocol or String as often as possible? > On 28 Jun 2017, at 18:37, Ben Cohen via swift-evolution > wrote:

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

8:52 AM Jacob Williams via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> I feel that the !! operator would be necessary for indicating that if this >>>> fails then something went horribly wrong somewhe

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On 28 Jun 2017, at 17:35, Ben Cohen via swift-evolution > wrote: > > >> On Jun 28, 2017, at 6:03 AM, Erica Sadun via swift-evolution >> > wrote: >> >> In general, does everyone prefer `?? () -> Never`

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On 28 Jun 2017, at 17:41, Ben Cohen <ben_co...@apple.com> wrote: > > >> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Count me in as a strong p

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On 27 Jun 2017, at 20:23, Dave DeLong via swift-evolution > wrote: > > Also a +1 from me. This is something I always put in to my code. > > I agree that having `Never` as a bottom type is interesting, but even if that > were the case, the proposed “!!” operator

Re: [swift-evolution] [Update] Updates to SE-0166 and SE-0167

Great! Just wanted to make sure I understood :) > On 26 Jun 2017, at 22:36, Itai Ferber wrote: > > Taking your code as an example: > Swift > > Swift > struct Foo : Codable { > var prop1: Int? > var prop2: Int? > > enum CodingKeys { ... } > >

Re: [swift-evolution] [Update] Updates to SE-0166 and SE-0167

What I still have difficulties understanding is what will be the semantic difference between decodeIfPresent and decode with optional type: func init(from decoder: Decoder) throws { let container = try decoder.container(keyedBy: CodingKeys.self) prop1 = try

Re: [swift-evolution] Revisiting SE-0110

I think the Core Team initially (pre-Swift 1) wanted to make tuples and arguments isomorphic. But that model has many downsides which forced us to backtrack from that model: • Modifiers on arguments (like inout) would force us to introduce them as part of the type-system on tuples, which makes

Re: [swift-evolution] [Update] Updates to SE-0166 and SE-0167

Sending out again to the whole mailing list ;-) There are a lot of great changes here which make sense after the fact. I'll try to play around with them. One thing I'm concerned about: with the new Optional conformance, why do we still need decodeIfPresent and encodeIfPresent? They seem

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Okay, I undertand. I’m just worried that the proposal is a net negative if the keywords stay optional. I’ll mention it in more detail once we get to the review period. Thanks for the work on the proposal!! > On 16 Jun 2017, at 16:33, Erica Sadun wrote: > > As we say in

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Erica, any thoughts on only having default and making it an error in a future version of Swift like was discussed on this thread? The idea seems to have a few supporters. > On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution > wrote: > > >> On Jun 14, 2017,

Re: [swift-evolution] Revisiting SE-0110

> On 16 Jun 2017, at 08:04, Xiaodi Wu wrote: > >> On Fri, Jun 16, 2017 at 12:17 AM, David Hart wrote: >> >> >>> On 16 Jun 2017, at 01:55, Xiaodi Wu wrote: >>> >>> On Thu, Jun 15, 2017 at 17:43 David Hart

Re: [swift-evolution] Revisiting SE-0110

> On 16 Jun 2017, at 01:55, Xiaodi Wu wrote: > > On Thu, Jun 15, 2017 at 17:43 David Hart wrote: On 16 Jun 2017, at 00:41, David Hart wrote: On 15 Jun 2017, at 19:28, Chris Lattner wrote:

Re: [swift-evolution] Revisiting SE-0110

> On 16 Jun 2017, at 00:41, David Hart wrote: > > >> On 15 Jun 2017, at 19:28, Chris Lattner > > wrote: >> >> >> On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] Revisiting SE-0110

> On 15 Jun 2017, at 19:28, Chris Lattner wrote: > > > On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution > > o >>> > >>> > let (a : Int, b : Float) = foo() >>> >>> >>> I think it would be better if the

Re: [swift-evolution] Revisiting SE-0110

> On 15 Jun 2017, at 18:05, Xiaodi Wu via swift-evolution > wrote: > > On Thu, Jun 15, 2017 at 10:23 Robert Bennett via swift-evolution > > wrote: > > One (tangential) thing that came up is that tuple

Re: [swift-evolution] [Idea] Trailing Multi-Line String Literal

I totally see what you are driving at. But I just see less value in it that with trailing closure. But it’s very personal. > On 15 Jun 2017, at 13:18, Gor Gyolchanyan wrote: > > Funny you should mention DSLs: > > let myQuery = sql """ > SELECT id, name, date >

Re: [swift-evolution] [Idea] Trailing Multi-Line String Literal

Personally, I have never felt that need. Trailing closures fill of need of making Swift a good candidate for building DSLs, where they make the function calls look more like first-class operations. But I don’t think that trailing strings would be as useful. David. > On 15 Jun 2017, at 11:54,

Re: [swift-evolution] Revisiting SE-0110

It declares variables Int and Float, but I know that only because CodaFi asked us the same question on twitter a while back! I'd be very happy if that was deprecated. > On 15 Jun 2017, at 06:01, Chris Lattner via swift-evolution > wrote: > > >> On Jun 12, 2017, at

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

t;mailto:swift-evolution@swift.org>> wrote: >>> >>> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>Sorry, initially sent off-list: &g

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

14, 2017 at 1:08 PM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> Sorry, initiall

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Sorry, initially sent off-list: I think this proposal is a great idea. But I would vote for the alternative of only having default and implicitly deducing extend when default is not specified: it would mimic how override works with only one keyword, it would not introduce a completely new

Re: [swift-evolution] [swift-dev] RFC: bridging peephole for "as" casts

Very good description. It's always worth re-explaining terms like bridged conversion to make sure every body is on the same page. But concerning the rules at the end, I’m not quite sure I understood them all. Please let me know if I’m correct: No bridging conversions will be performed if:

Re: [swift-evolution] [Proposal] Change Void meaning

> On 12 Jun 2017, at 19:25, Xiaodi Wu via swift-evolution > wrote: > > Unfortunately, I think this proposal appears to be mistaken as to this key > premise: Void was never (IIUC) meant to model the absence of arguments; it is > a type with one possible value. > >

Re: [swift-evolution] [Proposal] Change Void meaning

It’s from type theory: https://en.wikipedia.org/wiki/Unit_type > On 12 Jun 2017, at 19:57, David Sweeris via swift-evolution > wrote: > > > On Jun 12, 2017, at 10:44, Jérémie Girault via swift-evolution >

Re: [swift-evolution] [Proposal] Change Void meaning

Hi there, While I also feel it's kind of odd to have Void defined as the empty tuple with the latest changes like SE-0110, I also see issues with your proposal. For example, your change will cause ambiguity when calling generic functions and functions that contain all the arguments but the

Re: [swift-evolution] Int indexing into UTF16View

> On 11 Jun 2017, at 02:49, Ben Cohen <ben_co...@apple.com> wrote: > > >> On Jun 8, 2017, at 10:32 AM, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello, >> >> When working with Strings whi

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

> On 9 Jun 2017, at 19:06, Max Moiseev via swift-evolution > wrote: > > Sorry. I might be missing something. Why is this better than: > > let allEmployees = Set(managers.flatMap { $0.directReports } > > ? For the same reasons

Re: [swift-evolution] Int indexing into UTF16View

> On 8 Jun 2017, at 14:15, Vladimir.S <sva...@gmail.com> wrote: > >> On 08.06.2017 20:32, David Hart via swift-evolution wrote: >> Hello, >> When working with Strings which are known to be ASCII, I tend to use the >> UTF16View for the performance of random

Re: [swift-evolution] Int indexing into UTF16View

ying. It's just a pitty that it's making the code much more complicated than it should be. > On Thu, Jun 8, 2017 at 16:26 David Hart via swift-evolution > <swift-evolution@swift.org> wrote: >>> On 8 Jun 2017, at 12:35, Tony Allevato <tony.allev...@gmail.com> wro

Re: [swift-evolution] Proposal: Always flatten the single element tuple

let driver: Driver = … driver.onNext(()) Conclusion Basically, these regressions add synctactic pollution to quite a few cases turning around tuples and Void. David. > On 8 Jun 2017, at 12:08, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On

Re: [swift-evolution] Int indexing into UTF16View

writing your own extension or using index.offset(by:) isn't a huge > penalty here. Is it really an invitation when it’s hidden inside the UTF16View? > On Thu, Jun 8, 2017 at 10:32 AM David Hart via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> On 8 Jun 2017, at 11:17, Gwendal Roué via swift-evolution > wrote: > > >> Le 8 juin 2017 à 19:40, Brent Royal-Gordon via swift-evolution >> > a écrit : >> >>> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev

[swift-evolution] Int indexing into UTF16View

Hello, When working with Strings which are known to be ASCII, I tend to use the UTF16View for the performance of random access. I would also like to have the convenience of indexing with Int: let barcode = "M1X/CLEMENT EELT9QBQGVAAMSEZY1353 244 21D 531 10A1311446838” let name =

Re: [swift-evolution] [Meta] WWDC week

 On 5 Jun 2017, at 20:53, Brent Royal-Gordon wrote: >> On May 30, 2017, at 10:26 PM, Brent Royal-Gordon >> wrote: >> >> I'm going to be in San Jose during WWDC next week, and I'm assuming I won't >> be the only one. Are there any

Re: [swift-evolution] Question regarding SE-0167 Swift Encoders

> On 31 May 2017, at 14:36, Gwendal Roué via swift-evolution > wrote: > > Itai, > > (This email is not technical) > > I'm not claiming that SE-0166 should be able to address all archival formats. > I've been talking about GRDB to show at least one format that

Re: [swift-evolution] [Meta] WWDC week

I'll be there too. I don't think there is a swift-evo meeting organized. If there is, please let me know. If not, we could all try to meet some evening. Don't know SJ so don't know where. > On 31 May 2017, at 07:45, Jonathan Hull via swift-evolution > wrote: > >

Re: [swift-evolution] Feedback on SE-0166 and SE-0167

> On 27 May 2017, at 12:40, Gwendal Roué wrote: > > >> Le 27 mai 2017 à 11:59, David Hart > > a écrit : >> >> I didn’t know that was possible either! Really cool. Even better: >> >> if let databaseValueType = T.self as?

Re: [swift-evolution] Feedback on SE-0166 and SE-0167

> On 27 May 2017, at 08:59, Gwendal Roué wrote: > > >> Le 26 mai 2017 à 22:30, David Hart a écrit : >> >> Can you explain what’s the problem with Issue 2? > > The problem was me, I guess :-) Of course nobody knows the list of keys, but > the type

Re: [swift-evolution] Feedback on SE-0166 and SE-0167

Can you explain what’s the problem with Issue 2? Am I correct in suggesting that Issue 1 is more of a missing generics feature than a problem with SE-0166/0167? David. > On 26 May 2017, at 16:26, Gwendal Roué via swift-evolution > wrote: > > Hello, > > I want to

Re: [swift-evolution] [Pitch] Improve String Literals

> On 16 May 2017, at 17:36, Gwendal Roué wrote: > > >> Le 16 mai 2017 à 16:39, David Hart > > a écrit : >> >>> >>> On 16 May 2017, at 15:01, Gwendal Roué >> >

Re: [swift-evolution] [Pitch] Improve String Literals

The problem I see is that + is an operator of the Standard Library and not part of the core language. I wouldn’t want + to sometimes to be a runtime operation and other times a compile-time operation. No, I really think we need strong language support here. > On 16 May 2017, at 22:20, Tony

Re: [swift-evolution] [Pitch] Improve String Literals

> On 16 May 2017, at 16:20, Gwendal Roué via swift-evolution > wrote: > > I >> Le 16 mai 2017 à 15:39, Adrian Zubarev > > a écrit : >> >> Well the main complain I had during the discussion

Re: [swift-evolution] [Pitch] Improve String Literals

about only allowing that inside multi-line literals and felt that that >>> could also be considered later as an additive feature.' >>> >>> >>> If someone from the Core Team lets us know this is definitely out of scope >>> for Swift 4, we’ll be happy

Re: [swift-evolution] [Review] SE-0179: Swift `run` Command

> On 16 May 2017, at 14:32, Gwendal Roué via swift-evolution > wrote: > > >> Le 16 mai 2017 à 02:09, Daniel Dunbar via swift-evolution >> > a écrit : >> >> Hello Swift community, >> >> The review of

Re: [swift-evolution] [Pitch] Improve String Literals

" and "later" don't > mean revisiting a topic 22 days after the original proposal is modified and > 16 days after it's implemented, but rather in a future version of Swift, > after users have been able to try and gain experience with the approved > design. Thanks for t

Re: [swift-evolution] [Pitch] Swift run Command

build >>> $ swift run -b >>> Builds first, then runs the new build. >>> >>> >>> Regards, >>> Rien >>> >>> Site: http://balancingrock.nl >>> Blog: http://swiftrien.blogspot.com >>> Github: http://github.com/Balan

Re: [swift-evolution] [Pitch] Swift run Command

r for websites build in Swift > > > > > > >> On 15 May 2017, at 09:47, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello evolution (and build-dev), >> >> I’d like to pitch a QOL proposal to improve th

[swift-evolution] [Pitch] Swift run Command

Hello evolution (and build-dev), I’d like to pitch a QOL proposal to improve the development of command-line Swift Packages by introducing a `swift run` command. I’d value any feedback before moving forward.

Re: [swift-evolution] [Pitch] Improve String Literals

starts. David. > On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Hi swift-evolution, > > Adrian Zubarev and I have discussed several issues with string literals still

[swift-evolution] [Pitch] Improve String Literals

Hi swift-evolution, Adrian Zubarev and I have discussed several issues with string literals still unresolved after the multi-line string literals proposals and we believe that they are important enough to address for Swift 4. Here is the pitch for our proposal. Please let us know what you

Re: [swift-evolution] Quick question: Constraint Aliasing

> On 12 May 2017, at 09:05, Dave Abrahams via swift-evolution > wrote: > > > on Thu May 11 2017, David Hart wrote: > >> I have the impression this would be simple enough because it would only live >> in the parser. But I'm >> no expert.

Re: [swift-evolution] [Review] SE-0163 [2]: String Revision: Collection Conformance, C Interop, Transcoding

I didn't provide feedback on the first iteration because I felt overwhelmed by all the changes. I think I could better comment on them if I could try them out. Is there an Xcode toolchain with those changes implemented? David. > On 11 May 2017, at 23:39, John McCall via swift-evolution >

Re: [swift-evolution] Quick question: Constraint Aliasing

I have the impression this would be simple enough because it would only live in the parser. But I'm no expert. > On 12 May 2017, at 01:50, Erica Sadun via swift-evolution > wrote: > > Can anyone give me a rough estimate of how hard (in terms of coding, not in >

Re: [swift-evolution] Ownership on protocol property requirements

LGTM! I'd go ahead with opening a PR. Time is running out! > On 8 May 2017, at 14:40, Greg Spiers wrote: > >> On Mon, May 8, 2017 at 7:57 AM, David Hart wrote: >> Sounds great! It should be an easy one to get through, > > Thanks David, appreciate it :)

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

> On 8 May 2017, at 09:09, Xiaodi Wu wrote: > > On Mon, May 8, 2017 at 12:16 AM, David Hart > wrote: > > On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution > >

Re: [swift-evolution] Ownership on protocol property requirements

i...@gmail.com >>> <mailto:gspi...@gmail.com>> wrote: >>> >>> >>> >>> On Mon, May 8, 2017 at 6:26 AM, David Hart via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >

Re: [swift-evolution] Ownership on protocol property requirements

Sounds great! It should be an easy one to get through, > On 8 May 2017, at 08:35, Greg Spiers <gspi...@gmail.com> wrote: > > > > On Mon, May 8, 2017 at 6:26 AM, David Hart via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>

Re: [swift-evolution] Ownership on protocol property requirements

> On 7 May 2017, at 20:12, Xiaodi Wu via swift-evolution > wrote: > > Today these keywords have no meaning inside a protocol, so clearly it should > be an error to use it in that context. I agree with Jordan that the error > should be on the protocol. > > It's

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

> On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution > wrote: > > To which human would it be misleading? > > To the writer? No, because the compiler will warn you right away. By the time > you're done with writing the first line, it'll warn you that Int and

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

gt; I would assume the error is correct, because if we ban reordering than > labeled tuple types will become incompatible if the labels are swapped, > remember the strict order or labels. > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 5. Mai 2017 um

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

> On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution > wrote: > >> On Fri, May 5, 2017 at 03:11 André Videla wrote: >> >> Just to make sure: >> >> let pair = (x: 3, y: 5) >> Let swapped: (y: Int, x: Int) = pair > > Error. Why error

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

> On 5 May 2017, at 09:24, Xiaodi Wu wrote: > > On Fri, May 5, 2017 at 2:22 AM, David Hart > wrote: > >> On 5 May 2017, at 07:56, Xiaodi Wu > > wrote: >> >> On Fri, May 5,

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

> On 5 May 2017, at 07:56, Xiaodi Wu wrote: > > On Fri, May 5, 2017 at 12:54 AM, David Hart > wrote: > > On 5 May 2017, at 07:17, Robert Widmann via swift-evolution >

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

> On 5 May 2017, at 07:17, Robert Widmann via swift-evolution > wrote: > > On the contrary, this is precisely what it means to deprecate tuple shuffles. > You can’t map common parlance onto this term; the proposal and the Twitter > thread weren’t merely about

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

I'm not giving my opinion, but quoting Ben Cohen's great list of questions to ask ourselves before adding something to the Standard Library: All methods added to the standard library increase complexity, so need a strong justification to reduce the risk of API sprawl. When requesting

Re: [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

> On 1 May 2017, at 00:46, Jon Shier wrote: > > `install` only sounds like it should install things in the system if > that’s the only type of manager you’ve ever used. If I’ve only ever used > brew, of course I’ll assume that every other thing that calls itself a >

Re: [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

Very happy about this proposal as the pinning feature was un-necessarily complicated and because SwiftPM will now work like many other package managers out there: users won't be surprised. By the way, why wasn't resolve called install instead, mirroring the terminology used everywhere else? It

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

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

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

> On 21 Apr 2017, at 20:20, Xiaodi Wu wrote: > >> On Fri, Apr 21, 2017 at 8:45 AM, David Hart wrote: >> >>> On 21 Apr 2017, at 11:32, Adrian Zubarev via swift-evolution >>> wrote: >>> >>> Dear Xiaodi Wu, why do you always

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

> On 21 Apr 2017, at 11:32, Adrian Zubarev via swift-evolution > wrote: > > Dear Xiaodi Wu, why do you always have to be offensive in a way of > questioning every single word another person says and not letting others to > have their own opinion?! I do not want to

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

> On 21 Apr 2017, at 01:31, Douglas Gregor via swift-evolution > wrote: > > >>> On Apr 20, 2017, at 3:39 PM, John McCall wrote: >>> >>> On Apr 20, 2017, at 6:35 PM, Xiaodi Wu via swift-evolution >>> wrote: On

Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

> On 19 Apr 2017, at 06:51, Chris Lattner <clatt...@nondot.org> wrote: > > >> On Apr 18, 2017, at 12:00 AM, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello community, >> >> I'm happy to see that SE-0169

Re: [swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

> On 18 Apr 2017, at 10:12, David Waite <da...@alkaline-solutions.com> wrote: > > >> On Apr 18, 2017, at 1:00 AM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> All

[swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

Hello community, I'm happy to see that SE-0169 got accepted and that we've patched the issues of SE-0025. But it's been a difficult process. And I can't stop asking myself if it could have been avoided. The crux of the problem is that source-compatibility is now becoming a very strong

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

> On 17 Apr 2017, at 21:11, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > All right, time to dive in! > > First things first, the “helper visible” row in the table I posted is > actually unnecessary: a private helper type can have its visible members >

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

Tony resumed very well my thought on this proposal. I'd like to add that even with all its complexity, it does not solve any of the issues introduced with SE-0025 and that the recent proposals have tried to fix. At the heart, SE-0159 and SE-0169 try to bring back a good safe-default private

Re: [swift-evolution] SE-0171: Reduce with inout

> • What is your evaluation of the proposal? Great addition. Reduce (aka foldl) is so useful and universal that a proposal like this that increases its usefulness is a big +1 for me. > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes. >

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

Looking good. A few comments inline: > On 13 Apr 2017, at 22:17, Ben Cohen via swift-evolution > wrote: > > > Hi swift evolution, > > Here’s another pitch, for The Propoosal Formerly Known As Spaceship. > Comparison Reform > > Proposal: SE- > > Authors:

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

> On 12 Apr 2017, at 20:44, Russ Bishop via swift-evolution > wrote: > > >> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution >> > wrote: >> >> Hello Swift community, >> >> The review of

Re: [swift-evolution] [pitch] One-sided Ranges

I remember being against this feature when it was first discussed long ago. But I’ve since appreciated how elegant it is. I also like the i… was chosen instead of i..< I guess Range would be a better name for the generic protocol to represent all ranges. But its too late for that now. Correct?

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

I think I agree that the simplicity of the new rules outweigh the loss of the first newline’s automatic stripping. Good job! > On 12 Apr 2017, at 15:40, Brent Royal-Gordon via swift-evolution > wrote: > > Hey folks, > > > We've revised the proposal again. The main

Re: [swift-evolution] Enhancing access levels without breaking changes

> On 12 Apr 2017, at 07:42, Chris Lattner wrote: > > On Apr 11, 2017, at 10:30 PM, David Hart > wrote: >>> To me, the reason for limiting it to a file is about predictability, the >>> ability to locally reason about a type,

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

> On 12 Apr 2017, at 02:50, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, Apr 11, 2017 at 7:32 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution >>>

Re: [swift-evolution] Enhancing access levels without breaking changes

//github.com/apple/swift-evolution/pull/587> >> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I don't want to make any change until Chris has been able to chime in. If he &g

Re: [swift-evolution] Enhancing access levels without breaking changes

all <rjmcc...@apple.com> wrote: > > >> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >> On 11 Apr 2017, at 16:27, Matthew Johnson <matt...@anandabits.com> wrote: >>

Re: [swift-evolution] Enhancing access levels without breaking changes

> On 11 Apr 2017, at 16:27, Matthew Johnson <matt...@anandabits.com> wrote: > > > > Sent from my iPad > >> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>>&

Re: [swift-evolution] Enhancing access levels without breaking changes

> On 11 Apr 2017, at 13:29, Jonathan Hull <jh...@gbis.com> wrote: > >> >> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> On 11 Apr 2017, at 09

Re: [swift-evolution] SE-0169

> On 11 Apr 2017, at 09:24, Goffredo Marocchi via swift-evolution > wrote: > > > > Sent from my iPhone > >> On 11 Apr 2017, at 02:41, Michael Mayer via swift-evolution >> wrote: >> >> All - >> >> I am not in favor of this change.

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

> On 11 Apr 2017, at 08:48, Tino Heth via swift-evolution > wrote: > > -1 (strong) > > I think I've read all messages and haven't much to add — so just to sum up my > concerns in order: > — It makes access control more complicated > For me, it's not about the

Re: [swift-evolution] Enhancing access levels without breaking changes

> On 11 Apr 2017, at 09:40, John McCall <rjmcc...@apple.com> wrote: > >> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Sent from my iPhone >> On 11 Apr 2017, at 01:37, Ricardo Parada vi

Re: [swift-evolution] Enhancing access levels without breaking changes

Sent from my iPhone > On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution > wrote: > > I have not voted in favor or against the proposal. I have been reading a lot > of responses but I agree with Tony. > > When I started reading the proposal everything

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

> On 10 Apr 2017, at 17:17, Maximilian Hünenberger via swift-evolution > wrote: > > How about this: > > array.removeEvery(3) > array.removeEvery{ $0 > 3 } > > I think it preserves the meaning while it reads nicely. However "every" has > no precedent in

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution > wrote: > > This is a really great proposal. As an iOS developer I work with JSON almost > every day since most mobile apps communicate with a backend through JSON > messages. It's good to see that

Re: [swift-evolution] Enhancing access levels without breaking changes

> On 10 Apr 2017, at 08:21, Jean-Daniel <mail...@xenonium.com> wrote: > > >> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> >> >> O

Re: [swift-evolution] Enhancing access levels without breaking changes

> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution > wrote: > > >> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution >> wrote: >> >> This struck me as a bit odd at first, but the more I think about it, the

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

> On 10 Apr 2017, at 04:46, Xiaodi Wu via swift-evolution > wrote: > > Well, if we're going to bikeshed: > > I think removeAll(3) reads fine, while removeAll(of: 3) does not. I do not > think that reads right at all--what is "all of three"? Do we mean to contrast

Re: [swift-evolution] Type-based ‘private’ access within a file

> On 7 Apr 2017, at 15:41, BJ Homer via swift-evolution > wrote: > > -0.5 > > SE-0159 was rejected because it was determined that some developers are > actively using strongly-scoped access control. This proposal removes that > strong scoping, so I do not see how

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

Sent from my iPhone > On 7 Apr 2017, at 12:17, Haravikk wrote: > > >>> On 6 Apr 2017, at 21:47, David Hart wrote: >>> >>> On 6 Apr 2017, at 22:34, Haravikk via swift-evolution wrote:

<    1   2   3   4   5   6   >