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

> On 29 Jun 2017, at 12:37, Elviro Rocca wrote: > > From the user's standpoint, a crash is the worst thing possible, and should > always be avoided. A failure doesn't need to be silent for user, the app can > still communicate that there was an error with some kind of human readable > message

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

> On 29 Jun 2017, at 09:19, Elviro Rocca via swift-evolution > wrote: > > >> Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution >> ha scritto: >> >> Finally, there’s a woolier justification: there’s an often-touted >> misconception out there that force unwraps are bad, t

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

olution@swift.org>> wrote: >>>> I feel that the !! operator would be necessary for indicating that if this >>>> fails then something went horribly wrong somewhere and we should throw the >>>> fatalError. This allows the inclusion of optimizations using -Ounchecked >>&

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: > > Hi swift-evolution, >

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

t;> 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 somewhere and we should throw the >>>> fatalError. This allows the inclusion of optimizations usi

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can >> argue both ways, with the

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

> On 28 Jun 2017, at 17:41, Ben Cohen wrote: > > >> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Count me in as a strong proponent of ?? () -> Never. We don't need to burden

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

> On 28 Jun 2017, at 15:03, Erica Sadun via swift-evolution > wrote: > > I'll give this a kick around as soon as I get a moment and revise. I am > slightly concerned that we discussed variations of this in the past (throwing > if memory serves, with `Error` on the rhs) and that it broke the

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 is still useful, because it

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 { ... } > > init(from decoder: Decoder)

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 container.decodeIfPresent(Prop1

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 superfl

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 our introduction, we're

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, at 11:46 PM, Dave Abrahams v

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 wrote: >> On 16 Jun 2017, at 00:41, David Hart wrote: >> >> >> On 1

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: On Jun 15, 2017, at 9:41 AM, Xiaodi Wu via swift-evolution

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 >> mailto:swift-evolution@swift.org>> o > > let (a : Int, b : Float) = foo()

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 > mailto:swift-evolution@swift.org>> o >>> > >>> > let (a : Int, b : Float) = foo() >>> >>> >>> I think it would be better if the compiler raised a warning whenever you >>> tr

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 > mailto:swift-evolution@swift.org>> wrote: > > One (tangential) thing that came up is that tuple element names in tuple > > *patterns* should probably be de

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 > FROM MyTable >

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, G

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 10:07 PM, Paul Cantrell wr

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

> On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution > wrote: > > On 14.06.2017 21:23, Haravikk via swift-evolution wrote: >>> On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >&g

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

t; wrote: >> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> Sorry, initially sent off-list: >> >> I think this proposal is a great idea. But I would vote for the alternative >> of only

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 keywo

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. > > If I recall, a number of con

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 > mailto:swift-evolution@swift.org>> wrote: > >> Void was the empty tuple because argume

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 gene

Re: [swift-evolution] Int indexing into UTF16View

> On 11 Jun 2017, at 02:49, Ben Cohen wrote: > > >> On Jun 8, 2017, at 10:32 AM, 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

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 managers.flatMap(calculateReports(_:)) Is better than: manager

Re: [swift-evolution] Int indexing into UTF16View

> On 8 Jun 2017, at 14:15, Vladimir.S 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 access. > >

Re: [swift-evolution] Int indexing into UTF16View

ty 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 > wrote: >>> On 8 Jun 2017, at 12:35, Tony Allevato wrote: >>> >>> It is an extremely rare case for a developer to know a pri

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 > wrote: > >> >> On 8 Jun 2017, at 11:17, Gwendal Ro

Re: [swift-evolution] Int indexing into UTF16View

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 > mailto:swift-evolution@swift.org>> wrote: > Hello, > > When working with String

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 >> mailto:swift-evolution@swift.org>> a écrit : >> >>> On Jun 7, 2017, at 3:03 AM, Adrian Zubarev via swift-evolution >>> mailto:swift-evolution@swift.o

[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 = barc

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 swift-evolution meetings or events planned? >> Personally, I

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 SE-0166 doesn't > cover well. A

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: > > I’ll be in the area. Not sure

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? DatabaseValueConvertible.Type { >> let da

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 itself. It's a matter of injecting an encode

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 provide real-life feedback f

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é >> > wrote: >>> >>> Xiaodi Wu, your opposition has been recorded. You don't buy t

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 Alle

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 with David was, that I >> previously had such a model in mind w

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

hat >>> 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 to bring it back once discussion for Swift 5 >>> start

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 >> mailto:swift-evolution@swift.org>> a écrit : >> >> Hello Swift community, >> >> The review of SE-0179: Swift `run` Command begins now and runs through Ma

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

ot; 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. Th

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

. >>> >>> >>> Regards, >>> Rien >>> >>> Site: http://balancingrock.nl >>> Blog: http://swiftrien.blogspot.com >>> Github: http://github.com/Balancingrock >>> Project: http://swiftfire.nl - A server for websites build

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

gt; $ 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/Balancingrock > Project: http://swiftfire.nl - A server for websites build in Swif

[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. https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/-swift-

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

that they were not discussed by the Core Team. We feel obliged to put this proposal forward to formalise those issues. If someone from the Core Team lets us know this is definitely out of scope for Swift 4, we’ll be happy to bring it back once discussion for Swift 5 starts. David. > On Fr

[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 thin

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. > > You would need some way to tell the compiler whic

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

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 > terms of Swift Evolution proces

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 :) I've created a draft of the proposal. > A

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 > mailto:swift-evolution@swift.org>> wrote: > >> To which human would it be misleading? >> >> To the writ

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

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

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 entirely a different conversat

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 Double > are unused variables.

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

ecause 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 12:08:59, David Hart via swift-evolutio

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 here? In this case. It's not a label but he type. >>

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

> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution > wrote: > >> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev >> wrote: >> I’m not arguing to remove all labels in Swift. Labels are great, this is a >> fact for sure. The point I was trying to make is that labels in tuples how >> eit

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, 2017 at 12:54 AM, David Hart > > wrote: >

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 > mailto:swift-evolution@swift.org>> wrote: > >> On the contrary, this is precisely what it means to

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 reordering arguments. > >> but

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 additions/

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 > package manager will

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

Hi Rick, Thanks for taking the time to reply. I discussed the same argument with Ankit Aggarwal, and here are my counter-arguments: It seems to me like the survey should take into account the developer population using each tool. If we are doing such a survey to see what tool a programmer comi

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: >>> On Apr 21, 2017, at 12:40 PM, Xiaodi Wu via swift-evolution 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 >> to allow breaking a single-line string literal across

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 have to be offensive in a way of >>> questioning every single word a

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 have a discussion with you t

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 Thu, Apr 20, 2017 at 5:03 PM, Douglas Gregor wrote: >> On

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

> On 19 Apr 2017, at 06:51, Chris Lattner wrote: > > >> On Apr 18, 2017, at 12:00 AM, David Hart via swift-evolution >> wrote: >> >> Hello community, >> >> I'm happy to see that SE-0169 got accepted and that we've patched the issues

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

> On 18 Apr 2017, at 10:12, David Waite wrote: > > >> On Apr 18, 2017, at 1:00 AM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> All controversial proposals start their implementation in that version. > > J

[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 requireme

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 > unmarked (so, “internal”) an

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 modi

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

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

+1 > On 13 Apr 2017, at 11:28, Adrian Zubarev via swift-evolution > wrote: > > Now that I had some sleep I actually revise my opinion about the last line. I > took a few hours to sum my thoughts together in a gist, here is a formatted > version of it: > https://gist.github.com/DevAndArtist/d

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> Hello Swift community, >> >> The review of SE-0166 "Swift Archival & Serialization" begins now and r

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 difference: You no longer n

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, and the need to define some >>> boundary (f

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

> On 12 Apr 2017, at 07:16, Chris Lattner wrote: > > On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution > wrote: >>>> I understand what you are saying and I wouldn't be against relaxing that >>>> requirement (not talking for Chris here

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 >>> wrote: >>> >>> That’s also the example that kept me thinkin

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

on/pull/587> >> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I don't want to make any change until Chris has been able to chime in. If he >> agrees with us, what should be done? >&

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

n McCall wrote: > > >> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution >> wrote: >> >> >> >> On 11 Apr 2017, at 16:27, Matthew Johnson wrote: >> >>> >>> >>> Sent from my iPad >>> >>>>

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

> On 11 Apr 2017, at 16:27, Matthew Johnson wrote: > > > > Sent from my iPad > >> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution >> wrote: >> >> >>>> On 11 Apr 2017, at 13:29, Jonathan Hull wrote: >>>> >

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

> On 11 Apr 2017, at 13:29, Jonathan Hull wrote: > >> >> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On 11 Apr 2017, at 09:40, John McCall > <mailto:rjmcc...@apple.com>> w

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. While I agree that the implementation of >> fileprivate

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 complexity itself (it's not terri

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

> On 11 Apr 2017, at 09:40, John McCall wrote: > >> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution >> wrote: >> >> Sent from my iPhone >> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution >> wrote: >> >>>

<    1   2   3   4   5   6   7   >