Re: [swift-evolution] A case for postponing ABI stability

Sent from my iPhone > On 27 Jan 2017, at 07:04, Goffredo Marocchi wrote: > > In a way some people moved to a new language with few years of life under its > belt and should kind of expect the language not offering the stability and > maturity something tested and

Re: [swift-evolution] [Discussion] mailing list alternative

That is a so so reason though ;). JIRA can be a discussion hub and it should be used for discussion centred around user stories, bugs, etc... it is a delivery planning/agile planning tool not a mailing list or a forum for general discussion. Creating stories/items to discuss bugs, a proposal

Re: [swift-evolution] A case for postponing ABI stability

on Thu Jan 26 2017, Matthew Johnson wrote: >> On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Thu Jan 26 2017, David Hart wrote: >> > >>> Thanks Michael for the manifesto.

Re: [swift-evolution] Strings in Swift 4

Thanks for pointing this out to me. -Matt > On Jan 25, 2017, at 13:10, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jan 24 2017, Matt Whiteside wrote: > >>> On Jan 22, 2017, at 15:40, Chris Lattner via swift-evolution >>

Re: [swift-evolution] Strings in Swift 4

on Thu Jan 26 2017, Deborah Goldsmith wrote: > To throw another ingredient into the mix, there are issues for Unicode regex > that don’t appear in > more “traditional” regex implementations. See: > > http://userguide.icu-project.org/strings/regexp > > For example: >

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 5:48 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Jan 26, 2017, at 7:29 PM, Ted Kremenek > wrote: > >> >>> On Jan 26, 2017, at 12:19 PM, Matthew Johnson

Re: [swift-evolution] A case for postponing ABI stability

Sent from my iPad > On Jan 26, 2017, at 7:29 PM, Ted Kremenek wrote: > > >> On Jan 26, 2017, at 12:19 PM, Matthew Johnson via swift-evolution >> wrote: >> >> Locking down ABI when all foreseeable desirable changes are additive is one >>

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 12:19 PM, Matthew Johnson via swift-evolution > wrote: > > Locking down ABI when all foreseeable desirable changes are additive is one > thing. But doing so before we get there feels premature. I fully agree that locking down the ABI

Re: [swift-evolution] [Discussion] mailing list alternative

UX: *---EmailJIRADiscourse>  On Thu, Jan 26, 2017 at 5:10 PM, Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote: > I'm surprised there is so little support for JIRA. Anyone think it's a bad > tool for the job? > On Thu, Jan 26, 2017 at 6:38 PM Nevin

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 1:02 PM, Rick Mann via swift-evolution > wrote: > > Thanks for that, that's helpful. > > My concern, of course, is the obvious one: that we'll have to compromise on > future functionality in order to not break ABI compatibility, or we'll have

Re: [swift-evolution] Default Generic Arguments

I don’t have much skin in the nuance of PU vs DWIM since, as far as I can tell, it’s backwards compatible to update from PU to DWIM. So we could conservatively adopt PU and then migrate to DWIM if that's found to be intolerable. I expect it will be intolerable, though. Also, language subtlety

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 2:15 PM, David Sweeris via swift-evolution > wrote: > >> On Jan 26, 2017, at 13:02, Rick Mann via swift-evolution >> wrote: >> >> Thanks for that, that's helpful. >> >> My concern, of course, is the obvious one:

Re: [swift-evolution] [Discussion] mailing list alternative

I'm surprised there is so little support for JIRA. Anyone think it's a bad tool for the job? On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via swift-evolution wrote: > On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution < >

Re: [swift-evolution] Strings in Swift 4

To throw another ingredient into the mix, there are issues for Unicode regex that don’t appear in more “traditional” regex implementations. See: http://userguide.icu-project.org/strings/regexp For example: > Case insensitive matching is specified by the UREGEX_CASE_INSENSITIVE flag > during

Re: [swift-evolution] Default Generic Arguments

Cool, thanks--that makes sense. Personally, although DWIM is appealing, I think if we are to go all-out on your stance that "adding a default to an existing type parameter should be a strict source-breaking change," then "prefer user" is the one rule that maximally clarifies the scenario. With

Re: [swift-evolution] Default Generic Arguments

> On Jan 26, 2017, at 4:26 PM, Xiaodi Wu wrote: > > Very interesting point, Alexis. So can you reiterate again which of the four > options you outlined earlier support this use case? And if there are > multiple, which would be the most consistent with the rest of the

Re: [swift-evolution] [Discussion] mailing list alternative

On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution < swift-evolution@swift.org> wrote: > I haven't yet seen a good answer to the question: who is going to put in > the long-term commitment to host and maintain a replacement solution, > moderate forums, make technical upgrades and

Re: [swift-evolution] [Discussion] mailing list alternative

This is amazing! It solved the biggest complaint a few of us have with the current archive! > On Jan 26, 2017, at 1:36 PM, Tyler Stromberg via swift-evolution > wrote: > > on Thu Jan 26 2017, Dave Abrahams wrote: > > on Thu Jan 26 2017, Nate Cook >

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 13:02, Rick Mann via swift-evolution > wrote: > > Thanks for that, that's helpful. > > My concern, of course, is the obvious one: that we'll have to compromise on > future functionality in order to not break ABI compatibility, or we'll have a

Re: [swift-evolution] [Discussion] mailing list alternative

on Thu Jan 26 2017, Dave Abrahams wrote: on Thu Jan 26 2017, Nate Cook wrote: ✋ I forged the mighty, turgid rivers of rubyenv, hand-tweaked gem dependencies, and sed-cleaned mbox files to try this out—you can see the results of an import (using one or two day old data) at this address:

Re: [swift-evolution] Swift ABI Stability Manifesto

> On Jan 26, 2017, at 4:04 PM, Michael Ilseman via swift-evolution > wrote: > Weak references will most likely not be bitwise-movable on all platforms. > > In order for a weak reference to be nil-ed out, the weak reference itself > must, conceptually, be referenced.

Re: [swift-evolution] Swift ABI Stability Manifesto

on Thu Jan 26 2017, Michael Ilseman wrote: > Weak references will most likely not be bitwise-movable on all platforms. > > In order for a weak reference to be nil-ed out, the weak reference > itself must, conceptually, be referenced. There may be many convoluted >

Re: [swift-evolution] Default Generic Arguments

Very interesting point, Alexis. So can you reiterate again which of the four options you outlined earlier support this use case? And if there are multiple, which would be the most consistent with the rest of the language? And Srdan, could you incorporate that information into your discussion? On

Re: [swift-evolution] [Discussion] mailing list alternative

On Thu, Jan 26, 2017 at 12:43 PM, James Berry via swift-evolution < swift-evolution@swift.org> wrote: > > Since many will likely want to continue to access the discussion via mail, > I have some questions for anybody who actually has real-life experience in > using Discourse primarily via email:

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jan 26 2017, David Hart wrote: > >> Thanks Michael for the manifesto. It definitely made quite a few things >> clearer for me. >> >> Concerning the

Re: [swift-evolution] Swift ABI Stability Manifesto

Weak references will most likely not be bitwise-movable on all platforms. In order for a weak reference to be nil-ed out, the weak reference itself must, conceptually, be referenced. There may be many convoluted schemes that can serve as alternatives, but a straight-forward (and pragmatic)

Re: [swift-evolution] A case for postponing ABI stability

on Thu Jan 26 2017, David Hart wrote: > Thanks Michael for the manifesto. It definitely made quite a few things > clearer for me. > > Concerning the topic of when ABI stability should happen, I still have > a strong feelings that Swift 4 might not be the best time

Re: [swift-evolution] A case for postponing ABI stability

Thanks for that, that's helpful. My concern, of course, is the obvious one: that we'll have to compromise on future functionality in order to not break ABI compatibility, or we'll have a painful transition when we do break it. While today it's suboptimal to ship copies of the runtime with each

Re: [swift-evolution] [Discussion] mailing list alternative

I took some screenshots of this: http://discourse.natecook.com/t/pitch-replace-discourse-with-a-mailing-list/3052/3 We can do some further testing once we set up inbound email support. On Thu, Jan 26, 2017 at 11:58 AM David Hart via swift-evolution < swift-evolution@swift.org> wrote: >

Re: [swift-evolution] Annotation of Warnings/Errors

+1 Strongly in favour of this one. One of those things that seems obvious in retrospect It would also make the language more enjoyable to code in. When Xcode nags me about my function not providing a return value when I've only just started writing it, I get the irrational urge to tell Xcode

Re: [swift-evolution] [Discussion] mailing list alternative

> On Jan 26, 2017, at 10:02 AM, Nate Cook via swift-evolution > wrote: > > I forged the mighty, turgid rivers of rubyenv, hand-tweaked gem dependencies, > and sed-cleaned mbox files to try this out—you can see the results of an > import (using one or two day old

Re: [swift-evolution] [Discussion] mailing list alternative

on Thu Jan 26 2017, Adrian Zubarev wrote: > That’s exactly how almost all of your replies were displayed in my > mail-client. Yeah, I know. I've at least partly succumbed to the prevailing flow. I started to question my own careful practices several years ago when

Re: [swift-evolution] [Discussion] mailing list alternative

> On Jan 26, 2017, at 1:41 PM, Dave Abrahams via swift-evolution > wrote: > > It's a shame that it has no facility for hiding long quotations. Trying > to find the actual content in this thread is pretty awful: >

Re: [swift-evolution] [Discussion] mailing list alternative

Not true if you quote something via the web interface. See my quote here: http://discourse.natecook.com/t/pitch-add-dark-mode-to-swift/3051 On Thu, Jan 26, 2017 at 12:03 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Thu Jan 26 2017, Nate Cook

Re: [swift-evolution] [Discussion] mailing list alternative

C'mon this is not a concern of the developers making apps that help make this ecosystem popular and thus the devices they sell. I understand your point, but I can also understand that it is fair for a non Apple employee or non Apple stock options holder to question resources allocation. Sent

Re: [swift-evolution] warnings for out of scope?

This seems best handled as a lint rule, probably filed under “pedantic”. It makes sense to apply to a project at certain milestones, but could be noisy during incremental development. > On Jan 25, 2017, at 12:25 AM, Dave Kliman via swift-evolution > wrote: > > Hi!

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 2:12 PM, David Hart via swift-evolution > wrote: > > Thanks Michael for the manifesto. It definitely made quite a few things > clearer for me. > > Concerning the topic of when ABI stability should happen, I still have a > strong feelings that

Re: [swift-evolution] A case for postponing ABI stability

Thanks Michael for the manifesto. It definitely made quite a few things clearer for me. Concerning the topic of when ABI stability should happen, I still have a strong feelings that Swift 4 might not be the best time for it. Concerning Data Layout, Type Metadata, Mangling, the Calling

Re: [swift-evolution] [Discussion] mailing list alternative

Apple having billions of dollars, and the Swift team as a tiny part of Apple with associated resource allocations, are two completely different things. Please don't be obtuse. Best, Austin On Thu, Jan 26, 2017 at 11:27 AM, Charles Srstka wrote: > On Jan 26, 2017, at

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Stephen Canon wrote: > Responding to the thread in general here, not so much any specific email: > > “Arithmetic” at present is not a mathematically-precise concept, and > it may be a mistake to make it be one[1]; it’s a >

Re: [swift-evolution] [Discussion] mailing list alternative

That’s exactly how almost all of your replies were displayed in my mail-client. Combined with inlined messages it’s a nightmare to search through.  The sooner we migrate over to a forum, the better.  --  Adrian Zubarev Sent with Airmail Am 26. Januar 2017 um 21:03:48, Dave Abrahams via

Re: [swift-evolution] [Discussion] mailing list alternative

> On Jan 26, 2017, at 1:44 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jan 26 2017, Matthew Johnson wrote: > >>> On Jan 26, 2017, at 12:26 PM, Daniel Duan via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [Discussion] mailing list alternative

on Thu Jan 26 2017, Nate Cook wrote: > ✋ > > I forged the mighty, turgid rivers of rubyenv, hand-tweaked gem > dependencies, and sed-cleaned mbox files to try this out—you can see > the results of an import (using one or two day old data) at this > address: >

Re: [swift-evolution] [Discussion] mailing list alternative

on Thu Jan 26 2017, Matthew Johnson wrote: >> On Jan 26, 2017, at 12:26 PM, Daniel Duan via swift-evolution >> wrote: >> >> I'm actually convinced that I'd rather use an email client. Having to >> participate in a web app is a regression

Re: [swift-evolution] [Discussion] mailing list alternative

Awesome! I want to use this now :D Btw, for the people who prefer email: how would a system where discourse sends them the email work for them? > On 26 Jan 2017, at 19:02, Nate Cook via swift-evolution > wrote: > > >> On Jan 25, 2017, at 3:32 PM, Douglas Gregor via

Re: [swift-evolution] [Discussion] mailing list alternative

For a tiny but massively important part of Apple on which they’re essentially betting the entire future of the company? Yeah, I think the world’s richest Fortune 500 company can afford to allocate the resources for a web forum. Charles > On Jan 26, 2017, at 1:30 PM, Austin Zheng

Re: [swift-evolution] Strings in Swift 4

> On Jan 26, 2017, at 1:15 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jan 25 2017, Chris Lattner wrote: > >> On Jan 25, 2017, at 7:32 PM, Dave Abrahams wrote: There are two important use cases for regex's: the literal

Re: [swift-evolution] [Discussion] mailing list alternative

> On Jan 26, 2017, at 12:54 PM, Austin Zheng via swift-evolution > wrote: > > I don't like mailing lists in particular (or, really, at all), but I haven't > yet seen a good answer to the question: who is going to put in the long-term > commitment to host and

Re: [swift-evolution] warnings for out of scope?

> On Jan 26, 2017, at 10:21 AM, Joe Groff via swift-evolution > wrote: > > >> On Jan 25, 2017, at 10:40 AM, Xiaodi Wu via swift-evolution >> wrote: >> >> This is contrary to several deliberate design decisions, if I understand >>

Re: [swift-evolution] [Discussion] mailing list alternative

If you're not going to make the barest attempt to respond to my emails with the slightest modicum of good faith I'm finished with this conversation. Have fun! Best, Austin On Thu, Jan 26, 2017 at 11:37 AM, Charles Srstka wrote: > For a tiny but massively important

Re: [swift-evolution] Default Generic Arguments

That's a very good point Alexis and makes sense to me. I'll updated the proposal with that in mind and revise my examples. On Thu, Jan 26, 2017 at 7:06 PM, Alexis wrote: > > On Jan 25, 2017, at 8:15 PM, Xiaodi Wu wrote: > > Srdan, I'm afraid I don't

Re: [swift-evolution] [Discussion] mailing list alternative

+1 for keeping email, +0.25 for moving to GitHub like what Rust did. I don't like mailing lists in particular (or, really, at all), but I haven't yet seen a good answer to the question: who is going to put in the long-term commitment to host and maintain a replacement solution, moderate forums,

Re: [swift-evolution] [Discussion] mailing list alternative

> On Jan 26, 2017, at 10:49 AM, Adrian Zubarev > wrote: > > There are official mobile apps for Discourse: iOS > & > Android . >

Re: [swift-evolution] Strings in Swift 4

on Wed Jan 25 2017, Chris Lattner wrote: > On Jan 25, 2017, at 7:32 PM, Dave Abrahams wrote: >>> There are two important use cases for regex's: the literal case >>> (e.g. /aa+b*/) and the dynamically computed case. The former is >>> really what we’re talking about here,

Re: [swift-evolution] warnings for out of scope?

That's definitely a legit use case. I think it's different from the overarching proposal in that: 1) it has no progressive disclosure implications because it is about one explicitly chosen level vs another; and 2) it is about reducing uses that were clearly called out as suboptimal in an approved

Re: [swift-evolution] [Discussion] mailing list alternative

There are official mobile apps for Discourse: iOS & Android. I wonder how people would argue if we’d had started using a forum from the beginning and would now discuss a switch to an email list. That would be a real discussion about regression. --  Adrian Zubarev Sent with Airmail Am 26.

Re: [swift-evolution] Swift ABI Stability Manifesto

> On Jan 26, 2017, at 3:12 AM, Dale Buckley > wrote: > >> I put together a document compiling many conversations with many people >> about Swift’s ABI and what needs to happen prior to ABI stability. It is >> meant to be a blueprint for the project on how to

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

> On Jan 23, 2017, at 3:33 PM, Robert Widmann wrote: > > Some thoughts inline. > >> On Jan 21, 2017, at 11:06 AM, Daryle Walker via swift-evolution >> > wrote: >> >> 1. Variadic generics >> >> When I look

Re: [swift-evolution] [Discussion] mailing list alternative

Sent from my iPad > On Jan 26, 2017, at 12:26 PM, Daniel Duan via swift-evolution > wrote: > > I'm actually convinced that I'd rather use an email client. Having to > participate in a web app is a regression in my experience. +1. I like email way better than web

Re: [swift-evolution] [Discussion] mailing list alternative

I don't like mailing lists since it is very easy to forget about a topic. What I noticed about mailing lists is that the most controversial topics live the longest. I think swift-evolution should be able discussing the stuff that matters for the future of swift. I think the best choice for that

Re: [swift-evolution] [Discussion] mailing list alternative

I'm actually convinced that I'd rather use an email client. Having to participate in a web app is a regression in my experience. Daniel Duan Sent from my iPhone > On Jan 26, 2017, at 10:15 AM, Adrian Zubarev via swift-evolution > wrote: > > Awesome :) Hopefully

Re: [swift-evolution] [Discussion] mailing list alternative

I would love to participate in swift evolution discussions, and I made and defended one of the proposals for Swift here (SE-0025), but using email for this is so difficult that I stopped following the list. The only thing that kept me going with that proposal was that I really really wanted the

Re: [swift-evolution] [Discussion] mailing list alternative

Awesome :) Hopefully that will finally convince the people what ‘are working on this’ to actually make it ;) I could find some really old threads of mine in just seconds. My mail client cannot do that job that well.  Cannot wait 襤 --  Adrian Zubarev Sent with Airmail Am 26. Januar 2017 um

Re: [swift-evolution] Default Generic Arguments

> On Jan 25, 2017, at 8:15 PM, Xiaodi Wu wrote: > > Srdan, I'm afraid I don't understand your discussion. Can you simplify it for > me by explaining your proposed solution in terms of Alexis's examples below? > > ``` > // Example 1: user supplied default is

Re: [swift-evolution] [Discussion] mailing list alternative

> On Jan 25, 2017, at 3:32 PM, Douglas Gregor via swift-evolution > wrote: > >> >> On Jan 25, 2017, at 12:05 PM, Ted Kremenek via swift-evolution >> > wrote: >> >> I have no problem with the project

Re: [swift-evolution] warnings for out of scope?

> On Jan 25, 2017, at 10:40 AM, Xiaodi Wu via swift-evolution > wrote: > > This is contrary to several deliberate design decisions, if I understand > correctly. > > First, revisions to visibility rules in the Swift 3 timeline were made with > the deliberate

Re: [swift-evolution] Default Generic Arguments

> On Jan 24, 2017, at 15:33, Xiaodi Wu wrote: > > As I replied above, this doesn't work IMO because omitted generic arguments > are inferred, and that can't change without being hugely source-breaking. > > I think it's absolutely essential that adding a default to my

Re: [swift-evolution] [Discussion] mailing list alternative

> Le 26 janv. 2017 à 00:34, Erica Sadun via swift-evolution > a écrit : > > >> On Jan 25, 2017, at 1:05 PM, Ted Kremenek via swift-evolution >> > wrote: >> >> I have no problem with the project moving to

Re: [swift-evolution] Default Generic Arguments

> On 26 Jan 2017, at 02:15, Xiaodi Wu via swift-evolution > wrote: > > Srdan, I'm afraid I don't understand your discussion. Can you simplify it for > me by explaining your proposed solution in terms of Alexis's examples below? > > ``` > // Example 1: user supplied

Re: [swift-evolution] Strings in Swift 4

Am 2017-01-26 12:49, schrieb Jonathan Hull via swift-evolution: I had a realization a few weeks ago that regexes with capture groups actually correspond to a type, where successive capture groups form a tuple and recursive ones form arrays of the capture groups they recurse (and ‘?’ conveniently

Re: [swift-evolution] Default Generic Arguments

Thanks for your questions Xiaodi, I might have missed some scenarios. I've had some rethinking and here are the conclusions. It's a slight refinement of the idea I had in the previous mail. Bear with me :) If we have func process(_ t: T) {} process(5) compiler will infer T as Int.

Re: [swift-evolution] Strings in Swift 4

> On Jan 25, 2017, at 7:32 PM, Dave Abrahams via swift-evolution > wrote: > >> 4. Pattern matching greatness: One of the most obnoxious/error prone >> aspects of regex’s in many languages is that when you match a pattern, >> the various matches are dumped into

Re: [swift-evolution] [Discussion] mailing list alternative

I too had to create an additional email account for Swift Evolution. And ended up removing it from Mail.app after a week, due to pure exhaustion. It's just overwhelming. The fact that Swift's official channels require me signing up to a firehose and the fact that previous discussions on mailing

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

On Thu, Jan 26, 2017 at 1:55 PM, Robert Widmann via swift-evolution < swift-evolution@swift.org> wrote: > Three parts for three points: > > 1) Thanks! > > 2) I'm not sure generalizing this is particularly useful post-products. > The larger point is not to have non-exported/local target

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

Three parts for three points: 1) Thanks! 2) I'm not sure generalizing this is particularly useful post-products. The larger point is not to have non-exported/local target dependencies but to make clear the divide between a package and its test suite in the manifest as well as on disk. Local

Re: [swift-evolution] Annotation of Warnings/Errors

There's nothing wrong with fix-its and error messages, and indeed they can be quite helpful-the issue is that sometimes they show up when they really shouldn't, like in the middle of typing a line. Novices will then often stop and see what it's trying to say (wouldn't you trust a tool if it tells