Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

Hi Nevin,

I think this is an interesting perspective.  For me it begets the question of 
how an API “gets finalized”.  Currently anything that goes through the Swift 
Evolution proposal process that gets ratified is considered an official change 
to the language and Standard Library.  That feels like “finalized” to me, 
unless we want to introduce some new affordances to the process that allow us 
to introduce new APIs that are clearly going through a trial.  I think that’s a 
very interested idea (which is one Xiaodi proposed), but that’s not something 
we have today.

On this thread we are talking about APIs that have been in the Standard Library 
for a while, and largely predate the Swift Evolution process.  What makes them 
less finalized versus other APIs with similar heritage?  These APIs are in use, 
albeit Chris points out that they are (most likely) uncommonly used.  A core 
deliverable of ABI stability, however, is that the majority of the Standard 
Library is in a binary stable form.  The only APIs I think we can consider 
candidates for a “deprecated” dylib that gets embedded in the app are “leaf” 
APIs that are uncommonly used by clients and not relied upon by other parts of 
the Standard Library that are commonly used by clients.  Practically speaking, 
however, I’m not convinced that set is so large to add the 
complexity/engineering cost/time of creating this separate dylib right now.  
Those APIs can’t get ripped out right now — after all they’ve been in there for 
a while and we’re not deprecating them because there aren’t alternatives that 
exist yet anyway.  Thus these APIs need to continue to exist, and the benefits 
to me to create this separate dylib for those old “warty” APIs that we may — 
one day — want to replace seems marginal.

I do think the idea of having a way to add *new* ABI-unstable APIs is very 
interesting, but I think the root of this discussion comes from talking about 
APIs that have been around for a while but feel like potential warts as we 
approach ABI stability.  I hate to say it, but there will be warts regardless.  
There’s a lot to do for ABI stability — it’s making good progress — but not 
every last change we may have wanted to do will get all the attention we may 
have originally hoped it would.  Getting ABI stability done for Swift 5 is 
about prioritization and best effort, which includes accepting that not 
everything is going to be perfect.

Ted

> On Jan 15, 2018, at 1:04 PM, Nevin Brackett-Rozinsky 
> <nevin.brackettrozin...@gmail.com> wrote:
> 
> Alternatively, from a different perspective, rather than adding a new 
> ABI-unstable library that gets bundled with apps, another way to look at it 
> is that we already *have* an ABI-unstable library that gets bundled with 
> apps. So we can instead think about introducing a new library with a stable 
> ABI, which can be distributed with the OS.
> 
> That way, as each piece of the existing standard library gets finalized, we 
> can move it into the new ABI-stable library. Some pieces (eg. Mirror) will 
> never make the jump and can be phased out eventually. And when future 
> proposals make additions to the standard library, they can begin life in the 
> original, existing, non-ABI-stable library.
> 
> The net effect is the same as what we have been discussing, but a shift in 
> viewpoint makes it clear that the ABI-stable library is the new thing we are 
> adding, and the existing standard library can continue to serve a valuable 
> purpose going forward.
> 
> Nevin
> 
> 
> 
> On Sun, Jan 14, 2018 at 9:04 PM, Ted Kremenek via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
> 
> > On Jan 12, 2018, at 11:23 PM, Chris Lattner <clatt...@nondot.org 
> > <mailto:clatt...@nondot.org>> wrote:
> >
> > On Jan 12, 2018, at 4:43 PM, Ted Kremenek <kreme...@apple.com 
> > <mailto:kreme...@apple.com>> wrote:
> >> Hi Chris,
> >>
> >> Instead of responding to each of your point bit-by-bit, I’ll try a 
> >> different tactic to explain my reasoning — which may be wrong — by 
> >> explaining how I see things top down with the tradeoffs they incur.  I’m 
> >> going to say a bunch of things I know *you* know, but others are on this 
> >> thread and I’ll state things for end-to-end clarity.
> >
> > Sounds good.
> >
> >> It seems to me that we are talking about two possible scenarios: (1) the 
> >> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
> >> libswiftCore.dylib into two dylibs, one which includes some of the 
> >> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits 
> >> we will see with both scenarios, and see where the mismatch in our 
> >&

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

For some OS vendors it may be feasible to have multiple Swift runtimes 
installed on the system to be used by different apps.  That, however, is not an 
option if you actually want the libraries in the OS — in the case of macOS and 
iOS the OS frameworks — to actually use Swift themselves.  At the end of the 
day the frameworks in the framework stack have to be using the same Swift 
runtime in order to have Swift APIs, pass Swift objects around that are managed 
by the runtime, etc.

The Swift runtime was designed to actually allow the coexistence of two Swift 
runtimes: one for apps built before ABI stability that include a copy of the 
Swift runtime for their own use, and one for ABI stability that can be used 
both by the OS frameworks as well as apps built with the same version of Swift 
(or later) that had ABI stability.  In the case of runtime coexistence (which 
is to not break older Swift apps that aren’t rebuilt with a newer compiler) 
essentially the two runtimes are designed to essentially ignore each other.

> On Jan 15, 2018, at 11:48 AM, Wallacy via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> This. I asked that already and they not understand me very well.
> 
> I see no reason for each app to have its own version of "deprecated lib".
> 
> Also we can keep the libswiftCore_4.1.dylib, libswiftCore_5.0.dylib, 
> libswiftCore_5.1.dylib etc on the SO too. The default target must be 
> libswiftCore.dylib, but if need to use a specific feature on 
> libswiftCore_4.1.dylib why not.
> 
> Em seg, 15 de jan de 2018 às 16:54, Jacob Williams via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> escreveu:
> Pardon my lack of knowledge in this area, but is there not also a 3rd option 
> available?
> 
> (C) Split libswiftCore.dylib into two dylibs, both at the OS level. The 
> *Deprecated.dylib would only be included when the application binary was 
> compiled using a special -using-deprecated flag that signifies this app needs 
> at least one of the deprecated APIs? Then the code signing verification you 
> mention wouldn’t be a part of the apps that use deprecated APIs.
> 
> If this is not possible because all OS-level .dylibs MUST be included for 
> whatever reason then just disregard me, as I’m not an expert on this area of 
> Swift.
> 
> 
>> On Jan 12, 2018, at 5:43 PM, Ted Kremenek via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi Chris,
>> 
>> Instead of responding to each of your point bit-by-bit, I’ll try a different 
>> tactic to explain my reasoning — which may be wrong — by explaining how I 
>> see things top down with the tradeoffs they incur.  I’m going to say a bunch 
>> of things I know *you* know, but others are on this thread and I’ll state 
>> things for end-to-end clarity.
>> 
>> It seems to me that we are talking about two possible scenarios: (1) the 
>> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
>> libswiftCore.dylib into two dylibs, one which includes some of the 
>> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits 
>> we will see with both scenarios, and see where the mismatch in our “talking 
>> past each other” is happening.
>> 
>> In both cases (A) and (B), with ABI stability the Standard Library has the 
>> option to ship in the OS.  Thus applications using Swift on (say) iOS would 
>> no longer need to include libswiftCore.dylib in the app when running on an 
>> OS that shipped with the Standard Library.
>> 
>> With that in mind, here are the tradeoffs as I see between scenarios (A) and 
>> (B):
>> 
>> 
>> (A) Status quo: Keep shipping everything in libswiftCore.dylib
>> 
>> - Applications running on an OS with the Standard Library would no longer 
>> have *any* of the currently libswift*.dylib’s embedded inside the 
>> application bundle because they would just use the one in the OS.
>> 
>> - One benefit of using libswift*.dylibs in the OS as opposed to those 
>> embedded inside the app bundle is that there is a non-neglible startup time 
>> improvement, as the code signing verification that happens when an app 
>> launches would be faster as it would not need to verify each of these dylibs 
>> that were previously embedded in the app.  We should consider this the new 
>> baseline for app startup time for an app running on an OS with an ABI stable 
>> Standard Library.
>> 
>> - We continue to support the deprecated APIs for some time, possibly 
>> indefinitely, even when better alternatives come around.
>> 
>> (B) Split libswiftCore.

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

> On Jan 12, 2018, at 11:23 PM, Chris Lattner  wrote:
> 
> On Jan 12, 2018, at 4:43 PM, Ted Kremenek  wrote:
>> Hi Chris,
>> 
>> Instead of responding to each of your point bit-by-bit, I’ll try a different 
>> tactic to explain my reasoning — which may be wrong — by explaining how I 
>> see things top down with the tradeoffs they incur.  I’m going to say a bunch 
>> of things I know *you* know, but others are on this thread and I’ll state 
>> things for end-to-end clarity.
> 
> Sounds good.
> 
>> It seems to me that we are talking about two possible scenarios: (1) the 
>> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
>> libswiftCore.dylib into two dylibs, one which includes some of the 
>> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits 
>> we will see with both scenarios, and see where the mismatch in our “talking 
>> past each other” is happening.
> 
> Right.
> 
>> In both cases (A) and (B), with ABI stability the Standard Library has the 
>> option to ship in the OS.  Thus applications using Swift on (say) iOS would 
>> no longer need to include libswiftCore.dylib in the app when running on an 
>> OS that shipped with the Standard Library.
> 
> Right.  Please keep in mind that both approaches also eliminate all the 
> overlay dylibs for those apps, and both approaches put the vast majority of 
> the stdlib code into the OS as well.  The ‘deprecated’ dylib is probably 
> going to be comparatively small.
> 
>> With that in mind, here are the tradeoffs as I see between scenarios (A) and 
>> (B):
>> 
>> (A) Status quo: Keep shipping everything in libswiftCore.dylib
>> 
>> - Applications running on an OS with the Standard Library would no longer 
>> have *any* of the currently libswift*.dylib’s embedded inside the 
>> application bundle because they would just use the one in the OS.
> 
> Right.
> 
>> - One benefit of using libswift*.dylibs in the OS as opposed to those 
>> embedded inside the app bundle is that there is a non-neglible startup time 
>> improvement, as the code signing verification that happens when an app 
>> launches would be faster as it would not need to verify each of these dylibs 
>> that were previously embedded in the app.  We should consider this the new 
>> baseline for app startup time for an app running on an OS with an ABI stable 
>> Standard Library.
> 
> This happens with both models.  Refer back to the dyld optimization WWDC talk 
> by Nick and Louis 2-3 years ago.  The big problem with Swift for startup time 
> is that it adds half a dozen (or more) dylibs to your app bundle.  In the 
> talk they make it clear that adding a single dylib is not a big deal, it is 
> adding a bunch of dylibs that is the problem, particularly if they have 
> interdependencies between them.

Right — it is the large volume of dylibs that is the problem.

> 
> Neither approach presents this performance problem.

Agreed — in practice neither scenario is much different.

> 
> Further, if it were important to solve this startup time problem, it is 
> straight-forward to solve it for apps that do want to deploy backward (which 
> will be almost all of them in NMOS).  You’d do this by merging all the dylibs 
> into a single one in the app bundle instead of leaving them to be 
> independently resolved at load time.
> 
>> - We continue to support the deprecated APIs for some time, possibly 
>> indefinitely, even when better alternatives come around.
> 
> Agreed.
> 
>> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the 
>> app bundle
>> 
>> In the second scenario, we split out the deprecated APIs into a separate 
>> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the 
>> following characteristics:
>> 
>> - Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
>> when running on an OS that had an ABI-stable Standard Library.
>> 
>> - Compared to scenario (A), the OS shipping the Standard Library would have 
>> a slightly smaller libswiftCore.dylib that didn’t carry the bits for the 
>> deprecated APIs.  This would be a benefit in the code size for the OS, but 
>> not for the app itself.
> 
> The code size is small so it doesn’t matter much either way,

Agreed.

> but this actually is an advantage for the average app.  Part of the point of 
> this is that most apps don’t use this stuff, so they wouldn’t include the 
> dylib at all.  There is no cost for them in either launch time or size.
> 
> To pick on Mirrors, the one example someone came up with is an API used by 
> the swift on server community.  I haven’t heard of anyone using them in an 
> iOS app (but of course I’m sure there is someone somewhere doing it :-)
> 
>> - Any app using a deprecated API we put into libswiftCoreDeprecated.dylib 
>> (e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside 
>> their app bundle.  Compared to the new baseline I mentioned in (A), such 
>> 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

Hi Xiaodi,

It’s an interesting suggestion.  My inclination is that seeding prototype APIs 
would be better done via source package managers, and not as binary frameworks. 
 But they are two different approaches to the same problem and it is an 
interesting idea.

I’d like to first focus, however, on the utility of having such a separate 
dylib for the purposes of sunsetting APIs.

Ted

> On Jan 12, 2018, at 6:02 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> One point to bring up is that what you call libswiftCoreDeprecated.dylib can 
> be the place that future APIs live until they’re sufficiently mature.
> 
> I highly doubt that additions to the Swift standard library past 5.0 will all 
> be fully baked on arrival, and having everything carved into stone the moment 
> it’s added seems unwise.
> 
> Against this consideration the benefit of enabling a more stable set and a 
> less stable set of APIs seems to outweigh the start-up time consideration. 
> Yes, the implication is that most Swift apps will have to incur an increased 
> runtime cost.
> On Fri, Jan 12, 2018 at 18:43 Ted Kremenek via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Hi Chris,
> 
> Instead of responding to each of your point bit-by-bit, I’ll try a different 
> tactic to explain my reasoning — which may be wrong — by explaining how I see 
> things top down with the tradeoffs they incur.  I’m going to say a bunch of 
> things I know *you* know, but others are on this thread and I’ll state things 
> for end-to-end clarity.
> 
> It seems to me that we are talking about two possible scenarios: (1) the 
> status quo of keeping everything in libswiftCore.dylib or (2) splitting 
> libswiftCore.dylib into two dylibs, one which includes some of the 
> “deprecated” APIs.  I’ll enumerate what I think are the tradeoffs/benefits we 
> will see with both scenarios, and see where the mismatch in our “talking past 
> each other” is happening.
> 
> In both cases (A) and (B), with ABI stability the Standard Library has the 
> option to ship in the OS.  Thus applications using Swift on (say) iOS would 
> no longer need to include libswiftCore.dylib in the app when running on an OS 
> that shipped with the Standard Library.
> 
> With that in mind, here are the tradeoffs as I see between scenarios (A) and 
> (B):
> 
> 
> (A) Status quo: Keep shipping everything in libswiftCore.dylib
> 
> - Applications running on an OS with the Standard Library would no longer 
> have *any* of the currently libswift*.dylib’s embedded inside the application 
> bundle because they would just use the one in the OS.
> 
> - One benefit of using libswift*.dylibs in the OS as opposed to those 
> embedded inside the app bundle is that there is a non-neglible startup time 
> improvement, as the code signing verification that happens when an app 
> launches would be faster as it would not need to verify each of these dylibs 
> that were previously embedded in the app.  We should consider this the new 
> baseline for app startup time for an app running on an OS with an ABI stable 
> Standard Library.
> 
> - We continue to support the deprecated APIs for some time, possibly 
> indefinitely, even when better alternatives come around.
> 
> (B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the 
> app bundle
> 
> In the second scenario, we split out the deprecated APIs into a separate 
> dylib, say libswiftCoreDeprecated.dylib.  That solution would have the 
> following characteristics:
> 
> - Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
> when running on an OS that had an ABI-stable Standard Library.
> 
> - Compared to scenario (A), the OS shipping the Standard Library would have a 
> slightly smaller libswiftCore.dylib that didn’t carry the bits for the 
> deprecated APIs.  This would be a benefit in the code size for the OS, but 
> not for the app itself.
> 
> - Any app using a deprecated API we put into libswiftCoreDeprecated.dylib 
> (e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside their 
> app bundle.  Compared to the new baseline I mentioned in (A), such apps would 
> have a launch time regression once they started using any API in the 
> libSwiftCoreDeprecated.dylib because code signing would need to verify the 
> dylib, just like it does today with the libswiftCore.dylib that is embedded 
> in every application.  They would also be slightly larger because the app 
> bundle has the burden of hosting libswiftCoreDeprecated.dylib, instead of 
> compared to scenario (A) where the implementations of the deprecated APIs are 
> hosted by the libswiftCore.dylib that ships in the OS.
> 
> - Because of b

[swift-evolution] [Review][returned for revision] SE 0192 - Non-Exhaustive Enums

[Ted Kremenek via swift-evolution]

The review of "SE 0192 - Non-Exhaustive Enums” had extensive discussion and has 
been returned for revision.

The proposal author, Jordan Rose, is working on a revised proposal that 
includes:

- Alterations to the naming of the attributes.
- New affordances for how switch statements work with non-exhaustive enums.

There will be a second round of review, but there is active discussion 
considering the latter point right now on swift-evolution on the thread 
"Handling unknown cases in enums”:

  
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20180108/042604.html
 


I encourage anyway interested in that topic to follow/participate in that 
thread.

Ted___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

Hi Chris,

Instead of responding to each of your point bit-by-bit, I’ll try a different 
tactic to explain my reasoning — which may be wrong — by explaining how I see 
things top down with the tradeoffs they incur.  I’m going to say a bunch of 
things I know *you* know, but others are on this thread and I’ll state things 
for end-to-end clarity.

It seems to me that we are talking about two possible scenarios: (1) the status 
quo of keeping everything in libswiftCore.dylib or (2) splitting 
libswiftCore.dylib into two dylibs, one which includes some of the “deprecated” 
APIs.  I’ll enumerate what I think are the tradeoffs/benefits we will see with 
both scenarios, and see where the mismatch in our “talking past each other” is 
happening.

In both cases (A) and (B), with ABI stability the Standard Library has the 
option to ship in the OS.  Thus applications using Swift on (say) iOS would no 
longer need to include libswiftCore.dylib in the app when running on an OS that 
shipped with the Standard Library.

With that in mind, here are the tradeoffs as I see between scenarios (A) and 
(B):


(A) Status quo: Keep shipping everything in libswiftCore.dylib

- Applications running on an OS with the Standard Library would no longer have 
*any* of the currently libswift*.dylib’s embedded inside the application bundle 
because they would just use the one in the OS.

- One benefit of using libswift*.dylibs in the OS as opposed to those embedded 
inside the app bundle is that there is a non-neglible startup time improvement, 
as the code signing verification that happens when an app launches would be 
faster as it would not need to verify each of these dylibs that were previously 
embedded in the app.  We should consider this the new baseline for app startup 
time for an app running on an OS with an ABI stable Standard Library.

- We continue to support the deprecated APIs for some time, possibly 
indefinitely, even when better alternatives come around.

(B) Split libswiftCore.dylib into two dylibs, one that gets embedded in the app 
bundle

In the second scenario, we split out the deprecated APIs into a separate dylib, 
say libswiftCoreDeprecated.dylib.  That solution would have the following 
characteristics:

- Like scenario (A), app bundles would not need to embed libswiftCore.dylib 
when running on an OS that had an ABI-stable Standard Library.

- Compared to scenario (A), the OS shipping the Standard Library would have a 
slightly smaller libswiftCore.dylib that didn’t carry the bits for the 
deprecated APIs.  This would be a benefit in the code size for the OS, but not 
for the app itself.

- Any app using a deprecated API we put into libswiftCoreDeprecated.dylib 
(e.g., Mirrors) would need to embed libswiftCoreDeprecated.dylib inside their 
app bundle.  Compared to the new baseline I mentioned in (A), such apps would 
have a launch time regression once they started using any API in the 
libSwiftCoreDeprecated.dylib because code signing would need to verify the 
dylib, just like it does today with the libswiftCore.dylib that is embedded in 
every application.  They would also be slightly larger because the app bundle 
has the burden of hosting libswiftCoreDeprecated.dylib, instead of compared to 
scenario (A) where the implementations of the deprecated APIs are hosted by the 
libswiftCore.dylib that ships in the OS.

- Because of binary compatibility concerns, after Swift 5 we would *never* be 
able to “take out” any further APIs from libswiftCore.dylib and put them in 
libswiftCoreDeprecated.dylib.  This factorization can only happen once.

- There is some slight additional complexity added to the compiler and build 
system to support this spit of the Standard Library into multiple dylibs.  It’s 
not a huge concern but it does exist and it is not free both in terms of 
implementing and maintaining.

- We continue to support the deprecated APIs for some time, possibly 
indefinitely, even when better alternatives come around.  We *may* be able to 
completely sunset these APIs by having a future version of the Swift compiler 
simply refuse to build projects that use the deprecated (now obsoleted) APIs.  
At that point, these apps need to move to using the newer API alternatives, or 
not upgrade to using a new Swift compiler.


With these points in mind, both scenarios are (by construction) very similar.  
Scenario (B) potentially provides a bit more flexibility in outright sunsetting 
deprecated APIs down the road — but only the APIs we deem today should be on 
that path. In the future when we decide to deprecate APIs in the Standard 
Library we will need to follow the same kind of deprecation-and-obsoletion path 
as other binary frameworks in macOS/iOS, which may mean keeping API 
implementations around for a very long time just for the purpose of binary 
compatibility.

If you agree with me up to this point, to me this boils down to a tradeoff of 
some slightly increased opportunity to sunset some APIs in the 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

> On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Ok, I understand that (among all the other things going on that are clearly 
> more important) revamping this is probably not the highest priority thing to 
> do.  That said, it would be really unfortunate to carry around these 
> “suboptimal” APIs forever, particularly given how marginal they are (as in, 
> not widely used).  I’m sure that there are other examples beyond these that 
> are similarly unfortunate.
> 
> Given that, I have a meta question for you: have you considered an approach 
> where you take the Swift standard library and split it into two conceptual 
> pieces:
> 
> 1) The "ABI stable” subset of the library that gets burned into the OS.
> 2) The “ABI unstable” subset, which gets statically linked into apps, just 
> like the Swift 4 library used to?
> 
> Given that “import Swift” is implicit anyway, you could just have the 
> compiler implicitly import *both* of these modules.  
> 
> 
> The point of doing this is that it gives you a very general and low friction 
> way to handle compatibility gunk.  In addition to putting obscure stuff like 
> Mirror and “DictionaryLiteral” into this (without breaking source code!) you 
> now get the ability to put the various deprecated forwarding functions in 
> this module as well, avoiding them becoming part of the ABI.
> 
> The nice thing about this is that only people who use these things would have 
> to pay the cost, and you can directly message this by deprecating all the 
> stuff in it.  Think about it as an overlay for the Swift standard library :-)

Hi Chris,

Even if we split the APIs into two sets, with an “ABI unstable” subset, we are 
still going to “carry round these ’suboptimal APIs’” because clients are using 
them today and those APIs — without an active plan to remove them — *are* a 
part of the Standard Library.  We’ve past the point in Swift where we can just 
rip them out (you said so yourself in a follow up email).

It feels to me that the main advantage of the overlay is a solution to remove 
out pieces of the Standard Library that will be used in practice less, and thus 
clients don’t “pay the cost” when they don’t use them.  But I think we should 
be honest about what that “cost” actually is, as these APIs aren’t going away 
right now.  These suboptimal APIs will stay around at least until better ones 
are created, and even then some existing clients will want to rely on the 
existing suboptimal APIs anyway even if others want to take advantage of newer, 
better APIs and idioms.

The main cost I see here that we save by having an “overlay for the Standard 
library" is code size.  On macOS/iOS it is true that applications embed a copy 
of the Standard Library within them and thus pay a real cost in the Standard 
Library’s actually payload size in their own app.  However, the only reason 
that is necessary today is because we don’t have ABI stability.  With ABI 
stability, other options for shipping the Standard Library — such as shipping 
it in the OS — become possible, and thus the burden of shouldering that “cost” 
of code size shifts around.  Then the tradeoffs of having an overlay for the 
Standard Library are different.  In a world with ABI stability, is it better to 
have a Standard Library "overlay" that only some clients use, and embed within 
their application bundle, than just eat that cost in the Standard Library to be 
shared by potentially multiple clients installed on a system?  I think it 
really comes down to the numbers.  In that case, are we really just talking 
about Mirrors?  I haven’t run the numbers here, but my intuition tells me we 
are talking about a relatively small code size impact overall.

There’s also other potential performance implications from doing this split.  
Being able to have the Standard Library be in the OS has potential major 
implications on the startup time of Swift applications.  Right now, with the 
Swift overlay libraries being part of the application bundle, on macOS/iOS 
there is a real startup time impact of having these libraries shipped in 
applications this way.  Obviously reducing these down to one overlay — and 
overlay that hypothetically wouldn’t be used often — would be a major 
improvement over what we have today.  But this would also introduce a 
performance cliff for some clients that wanted to use the parts of the Standard 
Library that were deemed “ABI unstable”.  If an app starts using one of the 
APIs in this part of the Standard Library — and possibly through an 
intermediary such as a Swift package — then the app silently starts using this 
overlay and thus gets the startup time hit and other costs of using it.  For 
some clients that will seem like an obscure performance cliff.  In all 
fairness, “cliff” might be hyperbole here, but my point is that the tradeoffs 
of costs here are not linear and make the performance programming model of 
using Swift a 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek via swift-evolution]

> On Jan 9, 2018, at 11:48 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> IMO that isn’t a question we should be asking any more except in cases where 
>> an existing implementation is causing active harm. Which, confusing name 
>> aside, this type isn’t (aside from API sprawl I guess).
> 
> It directly impacts code size for applications of swift that use the standard 
> library as a standard library, e.g. a raspberry pi dev situation.

I’m not arguing that we should have profligate bloat in the Standard library, 
but I feel that if we are seriously talking about scenarios where we want a 
super-svelt Standard library for particular use-cases where code size and other 
factors are a major concern, then I think that discussion goes well beyond just 
cutting out APIs like Mirrors.  Depending on the domain, other parts of the 
Standard library seem like prime candidates to jettison as they may not carry 
their weight *in those contexts*, even if those APIs are well-used in others.

In other words, we have various knobs we can pull here in this design space, 
and the needs of Swift in different domains may be slightly different to be 
worth exploring different options where appropriate.  That’s not to say that 
the ideas you are putting forth don’t have merit, but I think there is a danger 
with lumping all of this up with the discussion about ABI stability in Swift 5. 
 More generally, I do think the idea of possibly carving up the Standard 
Library into layers is a possible useful design idiom when considering Swift 
being used in different contexts with different requirements/needs/constraints, 
but an exploration of that idea doesn’t have to be tied to ABI stability.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Incremental ABI stability

[Ted Kremenek via swift-evolution]

Hi Nevin,

I think it is important to separate the issues of concern here, as I think too 
much is get conflated into one topic.  ABI stability doesn’t mean that the 
language or Standard Library can’t change in the future.  It *does* mean we 
can’t just remove APIs wholesale that clients may depend on today, but I feel 
we are already in that place with the Standard Library.  For the Standard 
Library, ABI stability brings promises for binary compatibility for future 
versions of the Standard Library to clients that link against it — but that 
doesn’t mean that APIs can’t be deprecated and/or phased out in practice and 
new ones introduced.  For example, with Mirror, we may need to keep the 
existing Mirror APIs in place for existing clients that depend on them, but 
that doesn’t mean we couldn’t introduce better alternatives to Mirror in the 
future.

When talking about what ABI stability means, I think it is important to be 
technically specific about what it means and what it doesn’t mean.  For 
example, the wording you chose here was “still be able to fix the parts that we 
can already see need fixing” as if ABI stability would prevent you from doing 
that.  It is true that ABI stability means we can’t make certain kinds of 
changes — that’s what the “stability” of ABI stability means — but for the 
Standard Library ABI stability more-or-less brings the same kind of mental 
model for stability that most clients expect out of stable libraries these 
days: APIs can evolve, new ones can be added, and old ones can be 
deprecated/phased out, but existing clients that depend on the old interfaces 
need to continue to work.  That model is not incompatible with “fixing” APIs; 
it just means that “fixing” takes on different forms than just wholesale 
ripping out old APIs and replacing them with totally different ones.  We’re 
rapidly moving past that point with the evolution of the Standard Library 
anyway, and I think that’s something worth keeping in mind.

I’m totally open to considering “carving out specific exemptions to ABI 
stability” — I think specific arguments could be made here.  But I think those 
should be technically well considered on a case-by-case basis, and not just 
fear that ABI stability will lock us into bad APIs permanently.  Even outside 
of the current APIs we feel today might be imperfect, inevitably down the road 
we’re going to look back at some APIs and say that we wish we did them 
differently and find ways to phase in changes/improvements if the need is great.

Ted

> On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> I’m just spitballing here, and I’m not an expert on matters of ABI, however 
> the thought occurs to me that the current all-or-nothing approach might lead 
> to suboptimal results.
> 
> In particular, some recent discussions on this list have mentioned that 
> certain parts of the standard library, such as Mirror, really ought to be 
> redesigned. But their current shape is on track to be baked into the 
> permanent ABI, even though we know right now that we can do better.
> 
> Has any consideration been given to the possibility of carving out specific 
> exemptions to ABI stability for Swift 5, and saying something like, “The 
> entire ABI will be stabilized, except for Mirror (and possibly a small number 
> of other things)”?
> 
> That way we can nail down almost all of the ABI, while still being able to 
> fix the parts that we can already see need fixing. Perhaps I am being naive 
> here, and I’m sure there are major aspects I am unaware of, but from my 
> layperson’s perspective it seems rather silly to tie ourselves to a legacy 
> implementation that we want to redesign.
> 
> Nevin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Ted Kremenek via swift-evolution]

The review of "SE-0193 - Cross-module inlining and specialization" begins now 
and runs through January 5, 2018.
The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
Reviews are an important part of the Swift evolution process. All review 
feedback should be sent to the swift-evolution mailing list at:
> https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review 
manager.
When replying, please try to keep the proposal link at the top of the message:
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
> ...
> Reply text
> ...
> Other replies
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to 
Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

Thanks,
Ted Kremenek
Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Ted Kremenek via swift-evolution]

The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through 
January 3, 2018.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
Reviews are an important part of the Swift evolution process. All review 
feedback should be sent to the swift-evolution mailing list at:

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review 
manager. 

When replying, please try to keep the proposal link at the top of the message:

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
...
Reply text
...
Other replies
What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. 

When reviewing a proposal, here are some questions to consider:

What is your evaluation of the proposal?

Is the problem being addressed significant enough to warrant a change to Swift?

Does this proposal fit well with the feel and direction of Swift?

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?

Thanks,
Ted Kremenek
Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0189 - Restrict Cross-module Struct Initializers

[Ted Kremenek via swift-evolution]

Hello Swift Community,

The review of of “SE-189: Restrict Cross-module Struct Initializers” ran from 
November 14 to 21, 2017.

This proposal has been accepted.

During the review, most of the feedback voiced support that this was a 
necessary change for the library evolution (API resilience) story in Swift.  
There was some concern about the migration impact, as the change is 
source-breaking.  Some options were discussed on the review thread to possibly 
mitigate the migration impact in some cases.  Further, the thought process is 
that by having a warning in Swift 4.1 we can assess the impact of the change 
and soft message it, or if feedback is strong, re-evaluate the change.

Thanks to everyone who participated in the review.

Ted
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0190 - Target environment platform condition

[Ted Kremenek via swift-evolution]

Hello Swift Community,

The review of of “SE-190: Target environment platform condition” ran from 
November 16 to 24, 2017. This proposal has been accepted.

During the review, support for the enhancement was unanimous.  There were some 
questions during the review about the capabilities of this feature. Graydon 
explained that his is largely surfacing target environment information from the 
target triple, which can be flexibly used in many circumstances.

Thanks to everyone who participated in the review.

Ted
Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0190: Target environment platform condition

[Ted Kremenek via swift-evolution]

The review of "SE-0190 - Target environment platform condition" begins now and 
runs through November 24, 2017.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0190-target-environment-platform-condition.md
Reviews are an important part of the Swift evolution process. All review 
feedback should be sent to the swift-evolution mailing list at:

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review 
manager. 

When replying, please try to keep the proposal link at the top of the message:

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0190-target-environment-platform-condition.md
...
Reply text
...
Other replies
What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. 

When reviewing a proposal, here are some questions to consider:

What is your evaluation of the proposal?

Is the problem being addressed significant enough to warrant a change to Swift?

Does this proposal fit well with the feel and direction of Swift?

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?

Thanks,
Ted Kremenek
Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0189: Restrict Cross-module Struct Initializers

[Ted Kremenek via swift-evolution]

The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now 
and runs through November 21, 2017.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
Reviews are an important part of the Swift evolution process. All review 
feedback should be sent to the swift-evolution mailing list at:

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review 
manager. 

When replying, please try to keep the proposal link at the top of the message:

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
...
Reply text
...
Other replies
What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. 

When reviewing a proposal, here are some questions to consider:

What is your evaluation of the proposal?

Is the problem being addressed significant enough to warrant a change to Swift?

Does this proposal fit well with the feel and direction of Swift?

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?

Thanks,
Ted Kremenek
Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] update on forum

[Ted Kremenek via swift-evolution]

I was thinking all the mailing lists.

> On Nov 9, 2017, at 7:07 AM, Alejandro Martinez <alexi...@gmail.com> wrote:
> 
> Thanks for the clarification on that Ted :)
> Are all the mailing list gonna move there or only swift-evo?
> 
> On Thu, Nov 9, 2017 at 2:13 PM, Ted Kremenek via swift-evolution
> <swift-evolution@swift.org> wrote:
>> The decision to move to a forum was announced a while ago, and it hasn’t
>> appeared yet.  I think we will be making the move soon and I wanted to
>> provide some reasons why it was delayed and what comes next.
>> 
>> The reasons it was delayed are twofold:
>> 
>> -  When we (the community) decided to move to a forum there was plenty of
>> other planned infrastructure work that was in the works that took immediate
>> priority (such as the source compatibility suite and supporting Swift 4
>> development).
>> 
>> - In August (when Swift 4 was wrapping up) my team at Apple seriously picked
>> up the topic of the forum again and started looking in how to make it
>> happen.  At that point, a bunch of unexpected delays, one after the other,
>> happened.  I can’t share these details (they are mostly non-technical) and
>> going through them would come off as me making a bunch of excuses anyway.  I
>> do realize the forum has been promised and not yet delivered for some time,
>> and I know how frustrating that is to the community.
>> 
>> Here’s what happens next:
>> 
>> - We plan on having the company behind Discourse.org host the forums.  We’re
>> wrapping up the remaining steps to issue a PO, but my hope is to get that
>> all done within the next couple weeks.  Thanksgiving in the USA may delay
>> that to the beginning of December.
>> 
>> - My understanding is the forum will still have a swift.org address, so the
>> hosting is just an implementation detail.
>> 
>> - The company hosting Discourse.org will migrate the existing mailing list
>> archives over to the new forum.  One thing we will need to figure out
>> (possibly as a community?) are specific requirements we have in place for
>> that migration.  The new forums don’t have to exactly mirror how the mailing
>> lists are structured today, and part of the reason to move to the forum was
>> motivated by having new opportunities to structure conversations.
>> 
>> I suspect there will be some trial and error with moving over the existing
>> mailing lists to the new forum, and I don’t have a good feel on how long
>> that will take.  However, once we reach that stage, it should be very
>> transparent to the community what exactly is going on.  My hope is that
>> process will start in December.
>> 
>> Ted
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> 
> 
> -- 
> Alejandro Martinez
> http://alejandromp.com

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Ted Kremenek via swift-evolution]

> On Nov 8, 2017, at 11:49 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> 
>> On Nov 7, 2017, at 5:54 PM, Dave DeLong via swift-evolution 
>>  wrote:
>> 
>> Hi Swift-Evolution,
>> 
>> The Standard Library's goal is to be small and targeted. However, many 
>> aspects of Apple-provided frameworks need or offer opportunities for 
>> improvement or wholesale replacement. These enhancements lie beyond the 
>> scope of the Standard Library.
>> 
>> To address this, we'd like to propose the idea of a "Non-Standard Library"; 
>> this would be a library that ships with a regular installation of Swift, but 
>> is not imported into .swift files by the compiler, unless explicitly 
>> requested by the developer.
>> 
>> We are proposing a well-organized effort to parallel the Standard Library 
>> without putting additional implementation responsibilities onto the core 
>> team. This effort would mitigate what we see as platform-independent 
>> requirements that provide native Swift implementations that aren't burdened 
>> by Apple history.
> 
> Hi Dave,
> 
> As others have pointed out, we do already have a model for this sort of 
> thing: the swift server working group. 

Hi Chris,

While it is true we have the Swift server work group, it’s not clear that 
should be the default prototype model to follow here.

That work group was created with a specific purpose to help unify different 
efforts in the Swift on server community to establish a base set of 
fundamentals they all could rely upon.  But that was after there was already 
various library implementations/server frameworks in use that could be looked 
upon to inform technical decisions.  The work group is also a fairly 
heavyweight model; it is appropriate in many contexts but not all of them.

> 
> That said, there is another analogy which gets closer to what you’re asking 
> for: the Boost community for C++.  Boost was formed because the C++ committee 
> was too bogged down an wasn’t receptive to major library changes (at one 
> point in time).  Boost has effectively parallel leadership from the C++ 
> committee (though individuals are involved in both organizations of course).  
> This allows Boost to move faster, ship code, and get experience with it.
> 
> One of the specifically nice things about Boost is that they (at least 
> originally) focused on building out ideas, getting experience with them, and 
> then bringing the libraries back to the standard.  The libraries occasionally 
> undergo significant change when they are standardized, but the usage 
> experience is unmatchable, particularly for very large and complex APIs.

This “getting experiences with them” model is what appeals to me most about 
Boost, and is more-or-less what I was suggesting in my earlier reply on this 
thread as an important ingredient when considering how to extend “core Swift”.  
The Swift server work group in many ways already follows this model, as it is 
drawing from other technical work from efforts such as Kitura, Vapor, etc.

> 
> In the context of Swift, I think this sort of model could be very 
> interesting, because there are really several different independent things 
> going on: for a type like BigNum (for example) there are all the details of 
> the implementation and design on the one hand, but then there is also the 
> question of WHICH library it should ship with (Foundation or Swift or 
> something else). That second decision is much easier to make after the 
> community has converged on a specific design.
> 
> In any case, I think it would be a bad move for the official Swift 
> distributions to ship code that hasn’t been through the evolution process.  
> The idea of the Server working group is to delegate detailed design and 
> iteration to a team of experts, but then have them bring back the API to 
> evolution when the iteration is done and it is time to “standardize” it.  I 
> think that this is a good model.

The question in my mind is whether a “work group” is the right default model 
here.  It may be too heavyweight in many cases and perhaps not necessary for 
smaller efforts or efforts that involve less people.

Also, the server work group has a preconceived plan that the libraries are 
added to “core Swift”, or in some way become an official part of Swift.  I 
don’t think that needs to be an upfront goal for all Swift libraries out there. 
 The analogy for Boost is interesting; while Boost is a proving ground for many 
ideas that eventually make it back to the C++ standard, not all of those APIs 
have that fate and that seems fine too.

Ted___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Ted Kremenek via swift-evolution]

I have started a new thread.

> On Nov 9, 2017, at 2:05 AM, Adrian Zubarev <adrian.zuba...@devandartist.com> 
> wrote:
> 
> Hello Ted, would you mind opening a new thread and post an update about the 
> forum and maybe answer a few minor questions like:
> - what is currently planned?
> - in which timeframe we *might* see the forum finally happening (don’t have 
> to be a promise)?
> - what happens to old mailing lists? (I’d say put a public archive somewhere, 
> maybe slightly better formatted than the mailing list is, but do not spam new 
> categories so that we can start with a fresh and clean forum. I also wouldn’t 
> bother with migrating old users to new accounts. If I’m interested in 
> contribution I can take a minute and create a new forum account. I mean we’re 
> not trying to sell here anything, so this shouldn’t be a high priority 
> right!?)
> 
> Thank you. :)
> 
> 
> Am 9. November 2017 um 07:12:10, Ted Kremenek via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> 
>> 
>>> On Nov 8, 2017, at 12:08 PM, Kelvin Ma <kelvin1...@gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> 
>>>>> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution 
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>> 
>>>>>> I do not agree with Ted that only a few projects should be ranked, 
>>>>>> everyone, as it is in npm should be available. Only be graded according 
>>>>>> to recommendations.
>>>>>> 
>>>>> 
>>>>> I’m a bit confused.  I’m not sure what comments of mine I’m referring to.
>>>> 
>>>> Clearly I’m double confused.  That meant to read “I’m not sure what 
>>>> comments of mine *you* are referring to”.
>>>> 
>>>> I fully support having a broad spectrum of libraries that the community 
>>>> builds and uses.  Any library that we decide to make part of “core Swift” 
>>>> — IMHO at a mature point in a library’s evolution — would need to have 
>>>> high value to the majority of the community and would need to feel solid 
>>>> enough that we can lock it in for both source and binary compatibility, 
>>>> high quality of implementation with sustained maintenance, etc.
>>> 
>>> i mean I don’t think these approaches are incompatible. The “swift core” 
>>> could just make the process of independent libraries getting started 
>>> easier. Like right now there’s really no place to say “hey I just started a 
>>> library project for X, and anyone who wants to be involved should 
>>> contribute at Y github repo where it lives right now”. I’ve tried sending 
>>> that on this list before and it didn’t really work because mailing lists 
>>> aren’t really a good medium for that and no one wants the swift-evolution 
>>> list getting clogged with project-specific messages most people don’t care 
>>> about.
>>> 
>> 
>> 
>> These are great points.
>> 
>> FWIW, I’m getting optimistic about moving to a forum soon.  Would you expect 
>> that a forum could provide a better vehicle than a mailing list to arrange 
>> communication and interest within the community around building libraries?  
>> Not just doing shout outs for projects, but also doing possible API design 
>> review, etc.?
>> 
>> As an analogy, within Apple we have various mailing lists to review APIs, 
>> which is one mechanism used for different teams to co-review newly proposed 
>> APIs and consider how they compose together with other APIs.  It’s not 
>> always perfect, but it does help facilitate a culture of API review so that 
>> various APIs can be considered together and part of the same (or compatible) 
>> design philosophies.
>> 
>> One of the things that resonated to me from Dave DeLong’s proposal was a 
>> sense about having a set of libraries that are well-considered and their 
>> efforts coordinated.  While the coordination pitched in Dave’s proposal was 
>> about a focused effort on a particular set of libraries/features, 
>> coordination can also take the form of having a community that cares about 
>> building good APIs and can constructively discuss the

[swift-evolution] update on forum

[Ted Kremenek via swift-evolution]

The decision to move to a forum was announced a while ago, and it hasn’t 
appeared yet.  I think we will be making the move soon and I wanted to provide 
some reasons why it was delayed and what comes next.

The reasons it was delayed are twofold:

-  When we (the community) decided to move to a forum there was plenty of other 
planned infrastructure work that was in the works that took immediate priority 
(such as the source compatibility suite and supporting Swift 4 development).

- In August (when Swift 4 was wrapping up) my team at Apple seriously picked up 
the topic of the forum again and started looking in how to make it happen.  At 
that point, a bunch of unexpected delays, one after the other, happened.  I 
can’t share these details (they are mostly non-technical) and going through 
them would come off as me making a bunch of excuses anyway.  I do realize the 
forum has been promised and not yet delivered for some time, and I know how 
frustrating that is to the community.

Here’s what happens next:

- We plan on having the company behind Discourse.org  
host the forums.  We’re wrapping up the remaining steps to issue a PO, but my 
hope is to get that all done within the next couple weeks.  Thanksgiving in the 
USA may delay that to the beginning of December.

- My understanding is the forum will still have a swift.org  
address, so the hosting is just an implementation detail.

- The company hosting Discourse.org will migrate the existing mailing list 
archives over to the new forum.  One thing we will need to figure out (possibly 
as a community?) are specific requirements we have in place for that migration. 
 The new forums don’t have to exactly mirror how the mailing lists are 
structured today, and part of the reason to move to the forum was motivated by 
having new opportunities to structure conversations.

I suspect there will be some trial and error with moving over the existing 
mailing lists to the new forum, and I don’t have a good feel on how long that 
will take.  However, once we reach that stage, it should be very transparent to 
the community what exactly is going on.  My hope is that process will start in 
December.

Ted___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Ted Kremenek via swift-evolution]

> On Nov 8, 2017, at 12:08 PM, Kelvin Ma <kelvin1...@gmail.com> wrote:
> 
> 
> 
> On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
> 
>> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>>> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I do not agree with Ted that only a few projects should be ranked, 
>>> everyone, as it is in npm should be available. Only be graded according to 
>>> recommendations.
>>> 
>> 
>> I’m a bit confused.  I’m not sure what comments of mine I’m referring to.
> 
> Clearly I’m double confused.  That meant to read “I’m not sure what comments 
> of mine *you* are referring to”.
> 
> I fully support having a broad spectrum of libraries that the community 
> builds and uses.  Any library that we decide to make part of “core Swift” — 
> IMHO at a mature point in a library’s evolution — would need to have high 
> value to the majority of the community and would need to feel solid enough 
> that we can lock it in for both source and binary compatibility, high quality 
> of implementation with sustained maintenance, etc.
> 
> i mean I don’t think these approaches are incompatible. The “swift core” 
> could just make the process of independent libraries getting started easier. 
> Like right now there’s really no place to say “hey I just started a library 
> project for X, and anyone who wants to be involved should contribute at Y 
> github repo where it lives right now”. I’ve tried sending that on this list 
> before and it didn’t really work because mailing lists aren’t really a good 
> medium for that and no one wants the swift-evolution list getting clogged 
> with project-specific messages most people don’t care about. 
> 


These are great points.

FWIW, I’m getting optimistic about moving to a forum soon.  Would you expect 
that a forum could provide a better vehicle than a mailing list to arrange 
communication and interest within the community around building libraries?  Not 
just doing shout outs for projects, but also doing possible API design review, 
etc.?

As an analogy, within Apple we have various mailing lists to review APIs, which 
is one mechanism used for different teams to co-review newly proposed APIs and 
consider how they compose together with other APIs.  It’s not always perfect, 
but it does help facilitate a culture of API review so that various APIs can be 
considered together and part of the same (or compatible) design philosophies.

One of the things that resonated to me from Dave DeLong’s proposal was a sense 
about having a set of libraries that are well-considered and their efforts 
coordinated.  While the coordination pitched in Dave’s proposal was about a 
focused effort on a particular set of libraries/features, coordination can also 
take the form of having a community that cares about building good APIs and can 
constructively discuss them.  This can be done while also completely factoring 
out whether or not those APIs are part of “core Swift”.  Further, shared API 
review wouldn’t necessarily be about making actual decisions — which is the 
case of swift-evolution when evaluating language and standard library changes — 
but offering advice.  Fundamentally the library author still stays in control 
of their library and APIs, but the community could help in shaping up the 
gestalt of what are considered well-crafted Swift APIs in general.

Of course the big difference here with this idea compared to Apple’s internal 
API review process is that for Apple the APIs it vends are intended to be 
shipped together, and thus they must work together.  In open source, however, 
efforts on various libraries are often (usually?) independent.  Projects are 
usually created independently by different authors, and while it may be 
desirable for APIs from various libraries to feel natural to work with 
together, it’s not a requirement on their construction in general.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Ted Kremenek via swift-evolution]

hem might pose problems. The license on either the or the 
> supporting libraries might not be how we'd like. The code might be widely 
> known to present patent problems.
> 
> Distributors should check if they want/can ship these plug-ins
> People writing elements should base their code on these elements
> swift-extension-bad // (Full Community)  
> a set of features that aren't up to par compared to the rest. They might be 
> close to being good quality, but they're missing something - be it a good 
> code review, some documentation, a set of tests, a real live maintainer, or 
> some actual wide use.
> 
> If the features break, you can't complain - instead, you can fix the problem 
> and send us a patch, or bribe someone into fixing them for you
> New contributors can start here for things to work on
> 
> I just change plugins to feature to make more sense here... And at "base" 
> level we can just drop very small projects, and make few guarantees that will 
> always work. And at good level we can drop bigger projects like Alamofire, 
> Perfect etc, because of the nature of those projects, we know that will get a 
> good support but we cant guarantee that documentation and tests and language 
> updates will always be pair with the rest.
> 
> And at "bad" level, will be like NPM is today... just a easy way to obtain 
> some 3rd party code but no guarantees at all!
> 
> We heve IBM Swift Package Catalog (https://packagecatalog.com 
> <https://packagecatalog.com/>) but i think we can do better.
> 
> Also, if we (and Apple) do nothing, the community someway will do! It's like 
> Brew/Macports at some point people will build the tools to make the ecosystem 
> easier. Is better make something oficial (like npm/nuget) of course.
> 
> A "Non-Standard Libraries" its a non start for me, but good indexer, a good 
> integration with SwiftPM, a oficial help/support of the Swift Core Team, and 
> a set of rules/patterns to rule this (and other) projects is a good feature 
> to have.
> 
> Em ter, 7 de nov de 2017 às 21:16, Alejandro Martinez via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> escreveu:
> I’m with Ted on this one. 
> I would also love to see the Swift ecosystem grow but I think that it has to 
> happen with SPM. With improvements on SPM (as discussed in other threads) and 
> having a proper index (imho Cocoapods webpage is the best one out there, with 
> stats about docs, unit testing, downloads...) that makes finding libraries 
> easier. 
> But also a discussion forum where great libs can be shared and highlighted to 
> the rest of the community and big community efforts coordinated. If you look 
> at Rust is a great example, their forums attract the whole community (sadly 
> not something the mailing list does) and big and important projects have come 
> up from the community that have made a huge impact. With that in place and 
> some libs out there maturing I’m sure that in the future the conversation to 
> include battle tested code into an oficial distribution would be easier.
> 
> Sent from my iPad
> 
> On 7 Nov 2017, at 21:58, Ted Kremenek via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> Hi Dave,
>> 
>> Thanks for bringing up this topic.  This has been kicked around a little, 
>> and we’re still exploring different models on how to extend Swift.
>> 
>> The server APIs work group is one operational model for the community to 
>> build out a new set of core libraries.  That work group was formed out of 
>> the observation that there were different implementations of the same thing 
>> being created by different Swift on server efforts, and that those different 
>> efforts should pool those resources together and standardize on some 
>> fundamentals.
>> 
>> That analogy could work here.  However, it also has possible major 
>> downsides.  It can be heavyweight, and also artificially raise the 
>> importance of certain people’s library efforts over others by creating a 
>> formal work group whose efforts are expected to eventually be incorporated 
>> into the core Swift distribution.  It would also force a discussion up front 
>> of what even makes sense to incorporate into the core Swift distribution, 
>> which might be artificially constraining the exploration of the set of 
>> libraries to implement.
>> 
>> I need to think about your idea more, but my first reaction is that my 
>> preferred route is that the community builds these libraries, ideally using 
>> Swift Packages, and through trial and use we evaluate those libraries and 
>> then decide

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Ted Kremenek via swift-evolution]

> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
>> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I do not agree with Ted that only a few projects should be ranked, everyone, 
>> as it is in npm should be available. Only be graded according to 
>> recommendations.
>> 
> 
> I’m a bit confused.  I’m not sure what comments of mine I’m referring to.

Clearly I’m double confused.  That meant to read “I’m not sure what comments of 
mine *you* are referring to”.

I fully support having a broad spectrum of libraries that the community builds 
and uses.  Any library that we decide to make part of “core Swift” — IMHO at a 
mature point in a library’s evolution — would need to have high value to the 
majority of the community and would need to feel solid enough that we can lock 
it in for both source and binary compatibility, high quality of implementation 
with sustained maintenance, etc.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Ted Kremenek via swift-evolution]

> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution 
>  wrote:
> 
> I do not agree with Ted that only a few projects should be ranked, everyone, 
> as it is in npm should be available. Only be graded according to 
> recommendations.
> 

I’m a bit confused.  I’m not sure what comments of mine I’m referring to.  The 
main thing I said is that I’d prefer the community grow libraries that are 
trialed and used first (and then possibly incorporated into “core Swift”) 
rather than focus on standardizing a set of new libraries for distribution with 
Swift from the onset.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Ted Kremenek via swift-evolution]

On Nov 8, 2017, at 4:54 AM, Karl Wagner <razie...@gmail.com 
<mailto:razie...@gmail.com>> wrote:

>> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> FWIW, Ben Cohen and I have been talking about possibly using Swift packages 
>> as a way to seed out experimental ideas for extensions to the Standard 
>> Library.  This would allow ideas to be trialed by real usage (a complaint 
>> I’ve seen about some changes we’ve made to Swift in the past).  Users could 
>> build things on top of those libraries, knowing they are available as 
>> packages, and if an API “graduates” to being part of the Standard Library 
>> the user can then depend upon it being available there.  If it never 
>> graduates, however, the package remains around.
> 
> Yeah this is exactly the problem that the package manager is there to solve, 
> right? It’s supposed to make it ridiculously easy to integrate libraries and 
> manage your dependencies.
> 
> The problem is that most people writing Swift code every day are doing it to 
> make graphical applications on iOS/macOS. SwiftPM doesn’t support those, so 
> if I want to test a library, it’s just a one-off thing that I play with in a 
> Playground.
> 
> I think that the best thing we could do to encourage people to write, use and 
> contribute to public libraries would be to improve the package manager. 
> SwiftPM is still basically a toy (or an interesting curiosity), until it can 
> actually be used in the projects most Swift devs get paid to work on every 
> day. Talking about it supporting a community is way premature; it’s not even 
> close to ready to taking on that responsibility, IMO.
> 

I agree that the tooling support around SwiftPM is not sufficiently advanced 
yet to support this for everybody.  Further, I don’t think there would be a 
need to preclude other ways to share libraries for this purpose, even if the 
SwiftPM tooling support was more mature.

The primary point I wanted to make was more about the model itself.  I’d prefer 
the community grow up a set of libraries that trialed and used before focusing 
on prematurely baking them into the core Swift distribution.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Ted Kremenek via swift-evolution]

> On Nov 7, 2017, at 2:14 PM, Dave DeLong <sw...@davedelong.com> wrote:
> 
> 
> 
>>> On Nov 7, 2017, at 3:12 PM, David Sweeris <daveswee...@mac.com> wrote:
>>> 
>>> 
>>> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Hi Dave,
>>> 
>>> Thanks for bringing up this topic.  This has been kicked around a little, 
>>> and we’re still exploring different models on how to extend Swift.
>>> 
>>> The server APIs work group is one operational model for the community to 
>>> build out a new set of core libraries.  That work group was formed out of 
>>> the observation that there were different implementations of the same thing 
>>> being created by different Swift on server efforts, and that those 
>>> different efforts should pool those resources together and standardize on 
>>> some fundamentals.
>>> 
>>> That analogy could work here.  However, it also has possible major 
>>> downsides.  It can be heavyweight, and also artificially raise the 
>>> importance of certain people’s library efforts over others by creating a 
>>> formal work group whose efforts are expected to eventually be incorporated 
>>> into the core Swift distribution.  It would also force a discussion up 
>>> front of what even makes sense to incorporate into the core Swift 
>>> distribution, which might be artificially constraining the exploration of 
>>> the set of libraries to implement.
>>> 
>>> I need to think about your idea more, but my first reaction is that my 
>>> preferred route is that the community builds these libraries, ideally using 
>>> Swift Packages, and through trial and use we evaluate those libraries and 
>>> then decide if they should be incorporated as part of the core 
>>> distribution.  There’s many factors involved in deciding if they can be 
>>> incorporated into the core distribution, but all of those could be informed 
>>> by actually building libraries and see them getting used.
>>> 
>>> We could also figure out a way to possibly highlight these efforts to the 
>>> Swift community, maybe on swift-evolution or other means — but all with the 
>>> expectation that these libraries are not *necessarily* going to be 
>>> standardized as part of the core swift distribution.  I don’t think that’s 
>>> all that bad either; not every library will make sense to incorporate into 
>>> the core Swift distribution (e.g., they are highly domain specific) but 
>>> still supporting their development would be beneficial to the community.
>>> 
>>> Note that any change going into the Swift core distribution inevitably 
>>> involves swift-evolution and the core team.  Changes going into the core 
>>> Swift distribution must meet a very high bar as far as implementation and 
>>> design, the confidence we have into committing to specific APIs (especially 
>>> since we’ll have ABI stability in Swift 5), and other factors.  Thus this 
>>> will not really alleviate much burden on the Core team or on the community 
>>> — one of the core goals of your proposal.  Further, incorporating all those 
>>> concerns up front when building libraries might be counterproductive.
>>> 
>>> FWIW, Ben Cohen and I have been talking about possibly using Swift packages 
>>> as a way to seed out experimental ideas for extensions to the Standard 
>>> Library.  This would allow ideas to be trialed by real usage (a complaint 
>>> I’ve seen about some changes we’ve made to Swift in the past).  Users could 
>>> build things on top of those libraries, knowing they are available as 
>>> packages, and if an API “graduates” to being part of the Standard Library 
>>> the user can then depend upon it being available there.  If it never 
>>> graduates, however, the package remains around.
>>> 
>>> One thing that resonates me in what you propose is about having a 
>>> “well-organized effort” whose aim is to make these libraries feel cohesive 
>>> and implemented well.  However, given that many of these naturally fall 
>>> somewhere in the spectrum of responsibilities within the Standard Library 
>>> and Foundation, I think it is self-misleading to think that the Core Team 
>>> or others would not be involved in these efforts if the intention is to 
>>> possibly incorporate these one day into the core Swift distribution.  There 
>>> also may be other ways to achieve that le

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Ted Kremenek via swift-evolution]

Hi Dave,

Thanks for bringing up this topic.  This has been kicked around a little, and 
we’re still exploring different models on how to extend Swift.

The server APIs work group is one operational model for the community to build 
out a new set of core libraries.  That work group was formed out of the 
observation that there were different implementations of the same thing being 
created by different Swift on server efforts, and that those different efforts 
should pool those resources together and standardize on some fundamentals.

That analogy could work here.  However, it also has possible major downsides.  
It can be heavyweight, and also artificially raise the importance of certain 
people’s library efforts over others by creating a formal work group whose 
efforts are expected to eventually be incorporated into the core Swift 
distribution.  It would also force a discussion up front of what even makes 
sense to incorporate into the core Swift distribution, which might be 
artificially constraining the exploration of the set of libraries to implement.

I need to think about your idea more, but my first reaction is that my 
preferred route is that the community builds these libraries, ideally using 
Swift Packages, and through trial and use we evaluate those libraries and then 
decide if they should be incorporated as part of the core distribution.  
There’s many factors involved in deciding if they can be incorporated into the 
core distribution, but all of those could be informed by actually building 
libraries and see them getting used.

We could also figure out a way to possibly highlight these efforts to the Swift 
community, maybe on swift-evolution or other means — but all with the 
expectation that these libraries are not *necessarily* going to be standardized 
as part of the core swift distribution.  I don’t think that’s all that bad 
either; not every library will make sense to incorporate into the core Swift 
distribution (e.g., they are highly domain specific) but still supporting their 
development would be beneficial to the community.

Note that any change going into the Swift core distribution inevitably involves 
swift-evolution and the core team.  Changes going into the core Swift 
distribution must meet a very high bar as far as implementation and design, the 
confidence we have into committing to specific APIs (especially since we’ll 
have ABI stability in Swift 5), and other factors.  Thus this will not really 
alleviate much burden on the Core team or on the community — one of the core 
goals of your proposal.  Further, incorporating all those concerns up front 
when building libraries might be counterproductive.

FWIW, Ben Cohen and I have been talking about possibly using Swift packages as 
a way to seed out experimental ideas for extensions to the Standard Library.  
This would allow ideas to be trialed by real usage (a complaint I’ve seen about 
some changes we’ve made to Swift in the past).  Users could build things on top 
of those libraries, knowing they are available as packages, and if an API 
“graduates” to being part of the Standard Library the user can then depend upon 
it being available there.  If it never graduates, however, the package remains 
around.

One thing that resonates me in what you propose is about having a 
“well-organized effort” whose aim is to make these libraries feel cohesive and 
implemented well.  However, given that many of these naturally fall somewhere 
in the spectrum of responsibilities within the Standard Library and Foundation, 
I think it is self-misleading to think that the Core Team or others would not 
be involved in these efforts if the intention is to possibly incorporate these 
one day into the core Swift distribution.  There also may be other ways to 
achieve that level of cohesion in API design, such as through community 
discussion (possibly via the Swift.org  mailing 
lists/forums).  This discussion would not necessarily be the same as the path 
to “ratification” of a library into core Swift, but a step that could benefit 
many library authors (including considering ideas one day incorporated into the 
core swift).  With such a mechanism many library authors could benefit even if 
they do not intend to have the library as part of the core distribution.

My apologies that these are all hand-wavy ideas, but I’m trying to paint a 
possible alternative way to achieve your goal of more library evolution for 
Swift without having such a formal work group that may be too heavy weight or 
too narrowly focused.

Ted

> On Nov 7, 2017, at 9:54 AM, Dave DeLong via swift-evolution 
>  wrote:
> 
> Hi Swift-Evolution,
> 
> The Standard Library's goal is to be small and targeted. However, many 
> aspects of Apple-provided frameworks need or offer opportunities for 
> improvement or wholesale replacement. These enhancements lie beyond the scope 
> of the Standard Library.
> 
> To address this, 

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

[Ted Kremenek via swift-evolution]

A complementary tactic would be that migration tool support to Swift 5 would 
insert the needed casts to NSString.  That way even if the magic lookup is gone 
in Swift 5 the code could be automatically migrated and preserve the same 
semantics.  If this came to a formal proposal I’d really like to see something 
like that considered.

> On Oct 24, 2017, at 3:56 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> I think to maintain source compatibility, the old behavior would be preserved 
> until/if we remove -swift-version 4 mode. By deprecating it though, we won’t 
> have to devote as much time to maintaining it going forward.
> 
> Slava
> 
>> On Oct 24, 2017, at 3:54 PM, Philippe Hausler  wrote:
>> 
>> I think any serious proposal with the removal of APIs would need to consider 
>> source compatibility and to do so you should likely audit the API surface 
>> area that is being offered (and replace it via the NSStringAPI.swift 
>> extension)
>> 
>>> On Oct 24, 2017, at 3:12 PM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> Perhaps you could write up a proposal to outline the missing functionality 
>>> :-)
>>> 
>>> Slava
>>> 
 On Oct 24, 2017, at 3:09 PM, Jonathan Hull  wrote:
 
 I would feel better about it if String gained a lot of the utility of 
 NSString (so that we don’t have to go to NSString all the time for methods)
 
 Thanks,
 Jon
 
> On Oct 24, 2017, at 3:00 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Hi,
> 
> Members of NSString, except those defined in Foundation, are available on 
> values of type String. For example,
> 
> extension NSString {
> @objc func foo() {}
> }
> 
> let s: String = “hello”
> 
> s.foo()
> 
> We don’t do this for any other bridged types, for instance NSArray 
> methods are not imported as Array methods. It’s literally a special case 
> in the type checker for member lookup on String.
> 
> This behavior doesn’t really much sense conceptually and it was put in as 
> a stop-gap in Swift 1 to beef up the String API. I would like to phase it 
> out as follows:
> 
> - Unconditional warning in Swift 4.1, with a fixit to insert an ‘as 
> NSString’ cast
> - Error in Swift 5 with -swift-version 5
> 
> What does everyone think about this?
> 
> Slava
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Ted Kremenek via swift-evolution]

> On Oct 1, 2017, at 4:00 AM, Haravikk via swift-evolution 
>  wrote:
> 
>> 
>> On 14 Sep 2017, at 20:10, Ben Rimmington  wrote:
>> 
>> 
>>> On 14 Sep 2017, at 15:31, Haravikk wrote:
>>> 
 On 14 Sep 2017, at 02:12, Xiaodi Wu wrote:
 
> On Wed, Sep 13, 2017 at 09:13 Haravikk wrote:
> 
> I mean because not once have you summarised what these alleged 
> "considerations" were; if they exist then you should be able do so, yet 
> all I am hearing is "it was considered", which frankly is not an argument 
> at all as it is entirely without substance.
 
 Of course it is not an argument at all. It is a factual statement. The 
 objections which you mentioned were also mentioned prior to a decision 
 about SE-0185. The community and the core team had an opportunity to view 
 those objections. After that time, a decision was made, having considered 
 all the stated pros and cons which included the ones that you are now 
 repeating. What "considerations" are you looking for?
>>> 
>>> Ones with proof that they were ever made! Once again you are stating that 
>>> these issues were "considered", yet you show not a single shred of proof 
>>> that that was the case. You're asking me to take you at your word but I 
>>> have no reason to trust that the problem has been as carefully considered 
>>> as you claim.
>>> I was involved in one such discussion and the response from the core team 
>>> was frankly pitiful; they did not provide any justification whatsoever.
>> 
>> Chris Lattner already said that the core team discussed your concerns:
>> 
>> 
>> 
>> 
>> 
>> The original idea was for most types to be *implicitly* equatable and 
>> hashable:
>> 
>> 
>> 
>> The accepted proposal, with *explicit* declaration of conformance, is a good 
>> compromise.
>> 
>> Instead of discussing hypothetical issues with SE-0185, we can wait for 
>> Swift 4.1 beta.
> 
> And as I pointed out this "consideration" was pathetic; he interjected once 
> with a flawed argument and was never seen again. The core team has utterly 
> failed to justify their decision. It does not prove "consideration"; there 
> are no reasoned points, alternatives are never discussed, it is a dictate not 
> a discussion.
> 
> But fuck it, I no longer care; it is clear to me now that Swift Evolution 
> serves no purpose if the core team cannot or will not listen, and on that 
> basis if I cannot trust the core team I cannot trust Swift as a language, and 
> will not be using it going forward, as the direction it is taking frankly 
> undermines any optimism I once had for it.

I’m sad to see the thread go this way.  Myself and others who want to make 
swift-evolution feel like a place where ideas are heard certainly are sensitive 
to individuals getting frustrated.  That said, closing out the thread in a way 
that clearly violates the code of conduct (and thus the core sense of courtesy 
and professionalism we want to maintain on the list) isn’t effective either.  I 
think the thread should stop here, and remedial actions will be taken to stem 
this negative dialogue from continuing.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0186 - Remove ownership keyword support in protocols

[Ted Kremenek via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md
 


The review of SE-0186 “Remove ownership keyword support in protocols” ran from 
September 20 to 27, 2017.

The proposal has been accepted.

Feedback for the proposal — which many interpreted as being mostly a compiler 
bug fix — was limited but unanimously positive.  The consensus was that 
removing the support for these ownership keywords in protocols removes false 
expectations on their behavior, which could be a source of bugs.

Ted Kremenek
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0176: Remove ownership keyword support in protocols

[Ted Kremenek via swift-evolution]

The review of “SE-0186: Remove ownership keyword support in protocols” begins 
now and runs through September 27.

The proposal is available here:

   
https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md

Reviews are an important part of the Swift evolution process. All review 
feedback should be sent to the swift-evolution mailing list at:

   https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. 

When replying, please try to keep the proposal link at the top of the message:

>  Proposal link:  
> https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md
>  
> 
>  ….
>  Reply text
>  ...
>  Other replies


## What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. 

When reviewing a proposal, here are some questions to consider:

* What is your evaluation of the proposal?

* Is the problem being addressed significant enough to warrant a change to 
Swift?

* Does this proposal fit well with the feel and direction of Swift?

* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?

* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?


Thanks,
Ted Kremenek
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift 4.0 released!

[Ted Kremenek via swift-evolution]

I am pleased to announce that Swift 4.0 has been officially released:

  https://swift.org/blog/swift-4-0-released/

Swift 4 is available in Xcode 9 (which went live on the Mac App Store earlier 
today) and we will be posting an official toolchain shortly as well (likely 
early tomorrow morning).

Official builds have been posted for Linux (Ubuntu 16.10, Ubuntu 16.04 and 
Ubuntu 14.04).  For those of you downloading the Linux builds, please note that 
there is a new signing key (search for 'Swift 4.x Release Signing Key’) on the 
downloads page:

  https://swift.org/download/ 

Thank you to everyone who contributed to making this release happen!

Ted___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[Ted Kremenek via swift-evolution]

> On Aug 31, 2017, at 1:13 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Aug 31, 2017, at 3:16 PM, Taylor Swift via swift-evolution 
>> > wrote:
>> Where is the source for this number? XCode is not even available for Linux. 
>> And XCode’s market share is only shrinking as Swift expands more into the 
>> open source world. To make Swift depend on proprietary XCode features would 
>> nullify all of the work that has been done in the past 2 years to bring 
>> Swift to Linux platforms.
>> 
>> On Thu, Aug 31, 2017 at 12:44 PM, John Pratt > > wrote:
>> XCode is not just one of many editors to edit Swift you asshole.
> 
> John, this sort of personal attack is not acceptable behavior in the Swift 
> community, and sending it privately does not alter that.  If you would like 
> to continue participating in this community, please learn to treat your 
> fellow contributors with respect.
> 


Hi John,

This is a clear violation of Swift’s code of conduct.  We will not tolerate 
this kind of toxic interaction on or off the mailing lists.

Ted___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] kicking off concurrency discussions

[Ted Kremenek via swift-evolution]

Hi everyone,

One of the goals for Swift 5 is to start laying the *groundwork* for a 
concurrency model. 

>From https://github.com/apple/swift-evolution:

> Laying groundwork for a new concurrency model. We will lay groundwork for a 
> new concurrency model, especially as needed for ABI stability. Finalizing 
> such a model, however, is a non-goal for Swift 5. A key focus area will be on 
> designing language affordances for creating and using asynchronous APIs and 
> dealing with the problems created by callback-heavy code.


Concurrency is a topic with many axes of design to explore, as the different 
domains we wish Swift to be successful will place different demands on a model. 
 That exploration will take time: there will be tradeoffs with any model, and 
evaluating those tradeoffs will take discussion and iteration.

Today I’d like to open up swift-evolution to start some discussions about 
concurrency.  Some of those discussions will focus on broader designs and 
concerns, and some will focus on specific use cases which we want to work great 
in Swift.  Some opinions will likely differ significantly in the directions we 
should take — that’s fine.  We intentionally want to explore different design 
spaces here, as a concurrency model for Swift has far reaching impact in the 
long-term on Swift as a language.

To kick things off, Chris Lattner has been sharing privately with a few people 
his own ideas for concurrency, which I have encouraged him to send out after 
this email.  These are just his ideas and **not** an official plan of record, 
but beyond having some interesting points to discuss I think the way he has 
framed some of his thinking is a good model for others to follow when bringing 
up alternate design directions — which I encourage people to do.

Once the Discourse forum comes online (which we are making progress on) we will 
likely tag or somehow segregate/mark discussions related to concurrency so they 
can easily be found.  For now, one useful trick is to add “[Concurrency]” to 
the subject line, and when we move to the forum we’ll look to correctly tagging 
them.

Cheers,
Ted___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 5: start your engines

[Ted Kremenek via swift-evolution]

The project would definitely be well-served by having more documentation, and 
hopefully we’ll see that grow both incrementally and in spurts.  Even writing 
tutorials, however, must be weighed against competing priorities — such as 
finishing the work for ABI stability.  My hope is we can find a balance of 
investment in helping more people in the community feel empowered to implement 
proposals in the compiler/standard library while not diluting focus from 
delivering ABI stability.

> On Aug 8, 2017, at 11:28 PM, Jonathan Hull <jh...@gbis.com> wrote:
> 
> Would it be possible to get a series of tutorials on how the systems that 
> make up Swift generally work?  In other words, what are the pieces and how do 
> they fit together?
> 
> I think it would be useful even for people who aren’t directly implementing 
> because they can have a better idea of how difficult a change actually is.  
> It might also help some of us who have been sitting on the sideline to dip 
> our toes in the water.  I know I get a bit lost every time I try to find 
> something in the Swift source, and I am guessing I am not the only one...
> 
> Thanks,
> Jon
> 
> 
>> On Aug 8, 2017, at 5:27 PM, Ted Kremenek via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>>> On Aug 8, 2017, at 2:29 PM, Paul Cantrell <cantr...@pobox.com 
>>> <mailto:cantr...@pobox.com>> wrote:
>>> 
>>> I imagine that the core team will assist in providing implementations for 
>>> proposals that are crucial to the progress of the language and/or highly 
>>> popular — regardless of whether the proposal was authored by the core team 
>>> or a community member.
>>> 
>> 
>> That is true.  Everyone’s ability to assist is ultimately balanced by their 
>> own capacity and priorities, but I think there are plenty of examples of 
>> this happening in the past.  Also, there is a increasing number of people — 
>> and not just the Core Team or compiler engineers in my team at Apple — who 
>> are becoming increasingly comfortable working with the implementation of the 
>> compiler and the standard library.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift 5: start your engines

[Ted Kremenek via swift-evolution]

Hi everyone,

The proposal phase for Swift 4 is now officially over, and the release is now 
in endgame engineering convergence for an expected release later this year.  
Swift 4 has turned out to be one of the highest quality, well-rounded releases 
of Swift, and I am grateful to everyone in the community who made this release 
come together!

Now it is time to turn our attention to Swift 5.  I have just posted updates to 
the README.md file on the swift-evolution repository, which outlines the core 
themes and focus areas for Swift 5:

  https://github.com/apple/swift-evolution 


and a more persistent URL (invariant to future README.md changes):

  
https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md
 


I am not going to repeat all of that information here, but I wanted to 
highlight a few important things.

## ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot much of 
our prioritization of efforts for Swift 5 around it.  With Swift 4, ABI 
stability was a strong goal.  In Swift 5, it is a *requirement* of the release. 
 Whatever ABI we have at the end of Swift 5 is the ABI that we will have.  ABI 
stability is an important inflection point for the maturity of the language, 
and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module 
stability.   If you are not aware of the difference — which is rather important 
— please read the first few paragraphs of the ABI stability manifesto:

  https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md 


Module stability is a stretch goal for Swift 5, but even without module 
stability we can still achieve the primary value of ABI stability.

##  Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat here, 
but there is a general theme of refining and broadening out the core ergonomics 
of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for 
concurrency.  It is a non-goal of Swift 5 to roll out a full new concurrency 
model.  That is simply too large an effort to do alongside ABI stability.  
However, it is important that we start making progress on discussing the 
directions for concurrency and laying some of the groundwork.  This may take 
the form of specific enhancements to the language that get implemented, 
depending on where the discussions for concurrency lead and how they align with 
the priorities for delivering ABI stability in Swift 5.

## Changes to the language evolution process

Last, I want to highlight important changes to the evolution process:

  https://github.com/apple/swift-evolution 
#evolution-process-for-swift-5 


With Swift 4, the release period was divided up into “stage 1” and “stage 2” 
for setting guidelines for the kind of evolution proposals that were in scope 
for the release.  This was needed to establish focus — especially after the 
churn we saw during Swift 3 — on some core themes that were aligned with 
converging the language towards source & ABI stability.  One downside is that 
“stage 2” opened up discussion for potentially disruptive changes fairly late 
in the release.  Further, some proposals — such as SE-0155 — came in so late 
that there was little runway to actually implement them for Swift 4, let alone 
evaluate their impact in practice on real projects.  Related, there has been 
some desire  for a while to be able to better evaluate the impact of proposals 
on real code before they are locked into the release, and the best way to do 
that is to actually have an implementation that vets out the design in a 
proposal.

With Swift 5, the focus on ABI stability will predominate priorities for both 
design and implementation work, but the Core Team did not want that focus to 
stifle all discussion on potential enhancements to the language that were not 
fundamentally tied to that primary goal.  After reflecting on the evolution 
process during both the Swift 3 and Swift 4 releases, the Core Team felt that 
we could strike a balance with not diluting attention from ABI stability while 
still enabling a broader range of proposals compared to Swift 4 by **requiring 
that all proposals have an implementation** before they are officially reviewed 
by the Core Team.  An implementation can come long after an idea has been 
pitched and after a proposal has been written.  However, before a pull request 
for an evolution proposal will be accepted — and thus an official review 
scheduled — an implementation 

Re: [swift-evolution] RFC: structuring forums for best use for swift-evolution

[Ted Kremenek via swift-evolution]

> On Aug 1, 2017, at 10:30 PM, Rick Mann  wrote:
> 
> My inclination is to start with two broad-level categories: Evolution and 
> User (this presumes both the evolution and user lists are moving to 
> Discourse).

Just to help frame the rest of the discussion on this thread, the intention is 
to move all of the lists to Discourse.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] RFC: structuring forums for best use for swift-evolution

[Ted Kremenek via swift-evolution]

A while back a decision was reached to move from using mailing lists for 
swift-evolution to using a forum, specifically Discourse.  At the time that 
decision was made, efforts had been already well committed for supporting the 
development of Swift 4 — including efforts supporting important infrastructure 
efforts such as the source compatibility suite.  I apologize for not providing 
more transparency in why moving to a forum was being delayed.  Some things took 
longer than expected.

To be clear, the plan is to still move to Discourse, and with Swift 4 winding 
down there is now bandwidth to focus on making the transition from mailing 
lists to a forum.  As part of that transition, I’d like to get some feedback 
from the community.

There has been some good conversations on this mailing list on how 
swift-evolution can possibly evolve to better serve the needs of the community. 
 I’m not talking about whether or not we use a mailing list or a forum — that 
decision has been made.  Specifically, I’m talking about how a forum could best 
be structured to organize discussions and allow everyone to optimally 
participate.  In the move to Discourse, we have the opportunity here to 
possibly do things a bit differently than we have been so far.

For example, here are some of the questions I’m thinking about how we should be 
use a forum:

-  We currently have swift-evolution and swift-evolution-announce.  Should we 
use a specific “category” in the forum for "proposals that are in active 
review" — and possibly remove the need to have something like 
swift-evolution-announce?  

- Should we have other topical areas to organize discussions?  If so, at what 
granularity?

We can certainly figure out a lot of this over time, but I’d like some feedback 
from the community now on things they’d like to see in how we organize the 
swift-evolution forum based on experiences we’ve had with swift-evolution since 
it was created.

Please chime in on this thread if you have feedback, and focus on keeping this 
constructive.

Thanks,
Ted___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Revised and review extended] SE-0180 - String Index Overhaul

[Ted Kremenek via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md
 


The review of “SE-0180 - String Index Overhaul” ran from June 4…8, 2017.

Feedback on the proposal and further discussion in the Core Team has resulted 
in a slightly revised proposal.  A revised review of that proposal will run 
from now until June 28.

The revised proposal focuses on feedback concerning cases where indices fall 
between Unicode scalar boundaries in views having distinct encodings.  Please 
see the revised review (link above) for the specific technical revisions.

Thanks to everyone who participated in providing feedback for the review, and 
please take a look at the revised proposal!

- Ted
Review Manager

— REVISED REVIEW —

When replying, please try to keep the proposal link at the top of the message:

Proposal link:

 
https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md
 

Reply text

Other replies


What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift phases and mis-timed proposals

[Ted Kremenek via swift-evolution]

> On Jun 12, 2017, at 12:47 PM, Paul Cantrell <cantr...@pobox.com> wrote:
> 
> 
>> On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>>> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> I think having a queue to submit "proposals for eventually", written when 
>>> the inspiration is there, and having a core team review (say once a month 
>>> or even once a quarter) of their viability for future Swift directions 
>>> would be amazingly valuable.
>> 
>> This is a good point.  I think the concern about a queue is that ideas in it 
>> may still be subject to starvation if the queue gets too long.  Ideas also 
>> can atrophy in their relevance as the language evolves but proposals stay in 
>> the queue.  It then becomes a delicate matter when closing out old 
>> proposals. …
>> 
>> The point about understanding “viable for future Swift directions” is key 
>> here.  Viability really comes down to trajectory for the language.  None of 
>> us are fully omniscient about what is coming in future releases, but we do 
>> have a sense of some of the priorities for the language that we need to 
>> tackle, balanced with what **kind** of changes are still acceptable to take 
>> into the language depending on the kind of disruption they cause for users, 
>> the tools we have to mitigate any pain with those changes, etc.
> 
> This touches on two related concerns I’ve long had about how swift-evolution 
> has worked so far.
> 
> Concern #1 is that we consider proposals in relative isolation, on their own 
> merits. That’s understandable and wise. Without this focus, we’d never reach 
> conclusions about anything. However, this does tilt the process toward greedy 
> optimization as we traverse the language space. I worry that there’s not 
> enough attention to the big picture.

I agree that some of the proposals have felt like steps of a hill-climbing 
algorithm.

A few thoughts here:

- In contrast to the greedy optimization analogy, the series of manifestos in 
the Swift 4 timeframe (ABI stability, String, Ownership) are intended to 
provide an umbrella of design for what will turn out to be related but separate 
SE proposals.  The idea of these manifestos is to chart a direction for design 
and provide the basis for which the proposals related to the goals of the 
manifesto will be evaluated.

- Many SE proposals have been about language refinements, which fall into a 
category of topics that have been part of an ongoing design discussion for 
Swift for years — including long before Swift was publicly announced.  While 
the proposals may sometimes feel disjoint, their evaluation is not necessarily 
so.  Often for me proposals relate (directly or indirectly) to design 
discussions from previous versions of Swift (including pre-Swift 1) that help 
provide broader optics when evaluating the merit of the proposals.  Sometimes 
when a proposal comes back for revision it incorporates those optics.

- Sometimes (often?) refinements aren’t part of a grand design.  They evolve in 
the mind space from usage of Swift.  In other words, greedy optimization is 
sometimes just a natural way discussion and design happens.  The question in my 
mind is when these concerns come up should we throttle individual proposals and 
take more time to take a broader view?  Maybe that’s the answer.  Having been 
in discussions in the Core Team meetings I can say that sometimes it is clear 
there is a broader topic to be discussed, and other times it isn’t.

> 
> Concern #2 is that it’s hard to know what to do with a proposal when the 
> ideal answer is “we need to see how it plays out in practice and then decide 
> whether to accept it.” Theoretical discussion untempered by practical 
> prototyping is a great way for a group to talk itself into a bad idea. (This 
> will especially be a problem with future work to build out generics & 
> existentials.)

I agree.  Do you have specific thoughts here on what could be done differently?

> 
> Swift is already a very featureful language, and not always in a good way. A 
> new feature that makes good sense in the context of a particular problem may 
> make less sense when we consider the totality of its effect on the programmer 
> model: its mental burden, its unforeseen interactions, its surprising 
> pitfalls. How often do we reviewers give only a perfunctory answer to “Does 
> this proposal fit well with the feel and direction of Swift?” How often _can_ 
> we give anything but?
> 
> The net result is that IMO we tend to over-favor narrow solutions that solve 
> very specific problems, and under-favor simpler

Re: [swift-evolution] Swift phases and mis-timed proposals

[Ted Kremenek via swift-evolution]

> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> I am sitting on a number of ideas that I think have merit (in a non-random 
> use-case non-C# way) and I have no idea when the right time will be to bring 
> them up. Several were marked as "bring forward to Swift 4" and obvious that 
> was never going to happen for them.

I think perhaps this was obvious in hindsight, but in fairness we **all** were 
still figuring out how swift-evolution worked at all in the Swift 3 timeframe 
and we are **still** figuring things out (as evident by this thread).  When it 
is clear that something isn’t in scope for the current release we aren’t always 
omniscient about how it aligns with the next release.  Swift 5, for example, 
hasn’t been scoped yet.  There are certainly ideas, but it’s hard to say what 
the scoping should be for the next release until we see how the current active 
release shapes up.

A lot of ideas have merit, and I know it is frustrating to not get active 
discussion on them as quickly as we all would like.  Establishing focus for 
discussions is really key not only to have themes for a release (as Ben Cohen 
has eloquently summarized in the past) but also just prioritization.  Beyond 
prioritizing design points that are possibly the most pressing in Swift’s 
usability/success as a language, there’s only so much that can be done at once. 
 Thus there is a real balancing act between scheduling time to talk about 
things and actually implementing them.  I mentioned this in another reply, but 
SE-0155 is an example of this.  We discussed it, but nobody had adequate enough 
time to implement it so now it isn’t in scope for Swift 4.  It still probably 
was the right thing to discuss in in the Swift 4 timeframe, but the time we did 
spend on it was at a direct cost to other things we could have been doing.

> 
> I think having a queue to submit "proposals for eventually", written when the 
> inspiration is there, and having a core team review (say once a month or even 
> once a quarter) of their viability for future Swift directions would be 
> amazingly valuable.

This is a good point.  I think the concern about a queue is that ideas in it 
may still be subject to starvation if the queue gets too long.  Ideas also can 
atrophy in their relevance as the language evolves but proposals stay in the 
queue.  It then becomes a delicate matter when closing out old proposals.   
Having the Core Team review proposals in the queue on a regular basis may be 
the solution, but I wonder how tenable that would be in practice.  The current 
thinking behind closing out proposals that are out-of-scope is NOT to 
demoralize community participation in the evolution process, but to engage 
everyone in thinking about what is in scope for the release and to advocate for 
an idea when it makes sense for the community — and not just the Core Team — to 
actively engage on thinking about a proposal.  If an idea doesn’t make sense 
for the current release but does for a later one, then (hopefully) that idea 
will be brought up again, and possibly incorporating new context.  If anything, 
having a queue of a bunch of written proposals (each which can take significant 
effort to write) not getting much traction would possibly be even more 
demoralizing both for authors of the proposal but also everyone else.

The point about understanding “viable for future Swift directions” is key here. 
 Viability really comes down to trajectory for the language.  None of us are 
fully omniscient about what is coming in future releases, but we do have a 
sense of some of the priorities for the language that we need to tackle, 
balanced with what **kind** of changes are still acceptable to take into the 
language depending on the kind of disruption they cause for users, the tools we 
have to mitigate any pain with those changes, etc.  Discussion on 
swift-evolution does help shape those priorities in both specific ways and in 
broad strokes.  However, it is hard for me to tell if all or any of the ideas 
you are sitting on are viable — as I don’t know what they are.  I know that’s 
your point about having a queue of proposals.  But I am skeptical that such a 
thing would scale or leave you thinking the process worked any better.  What it 
sounds like to me is we need a better way to both air your ideas for 
consideration as well as a better understanding of the current thinking about 
future Swift releases.  I don’t have specific ideas yet on either, although at 
least for the former there has been some interesting ideas mentioned on this 
thread.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift phases and mis-timed proposals

[Ted Kremenek via swift-evolution]

Everyone: this is a great thread, and I appreciate the candid thoughts here.  
This is something Ben Cohen and I started chatting about offline and we’ll 
definitely bring it up for discussion with the rest of the Core Team.

I realize there is a tension here, and a sense of frustration, because ideas 
sometimes feel like they don’t get air time or it isn’t clear what’s the right 
conduit for discussing them.  I’m still mulling over the thoughts on this 
thread, but I’d first like to respond to Xiaodi’s point below.

> On Jun 11, 2017, at 2:54 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> A key question here to be answered is: is this mailing list the appropriate 
> forum for "discussing ideas right away," whatever they might be? or is it 
> more of a working list for bringing forward in-scope proposals in the 
> successive forms of pitch, draft, and proposal review? As far as I can tell, 
> the aim of scoping rules is to nudge it towards the latter, and personally I 
> think that's quite nice in terms of bringing sanity back to my inbox as well 
> as focus to the discussions. By contrast, I have seen blogs, Twitter, and 
> other channels used profitably for discussing ideas right away, and 
> personally I've found off-list communications to be the best way to prepare 
> for the much more difficult task of convincing the discerning crowd here.

I think this captures the current reality fairly well.  In the Swift 3 
timeframe, the swift-evolution process/venue was brand new and lots of 
discussion emerged on the swift-evolution list almost overnight.  Further, 
while there was a scope of the changes in Swift 3 they were pretty vast and 
encompassing.  For myself and other members of the Core Team the evolution 
discussion at times also felt a bit overwhelming.  Beyond the investment in 
shaping the swift-evolution community, it was a struggle to balance 
discussions, design work, and implementation work that aligned with Swift 3.

The phases of discussion we see in Swift 4 in many ways are a direct response 
to trying to instill a bit more order to make swift-evolution both less chaotic 
but also fit with the rhythm of the release.  Swift release follow a fairly 
predictable schedule, roughly following Apple’s yearly OS release cadence with 
the first “beta” of the major release of the language in June (aligning with 
WWDC).  The engineering and design work for a Swift release pretty much orients 
around that.  My hope is that major design discussions that define a release 
come earlier in the release cycle, with proposals trickling in as refinements.  
We saw that a bit in Swift 4 with the String Manifesto and the Ownership 
Manifesto.  We also phrased “phase 1” as being very focused so that critical 
momentum on Swift 4 could be established without discussions unrelated to the 
release creating major distractions for the community and the Core Team.  With 
“phase 2” the scope of what was on topic for Swift 4 was opened up a bit, but 
even that was hit and miss. We took some proposals very late that also landed 
with hot implementations.  As it is, some proposals simply were beyond our 
capacity to implement, such as SE-0155.  The fate of SE-0155 in particular will 
need to be re-evaluated once we look at the scope for Swift 5 (TBD).

Getting to Xiaodi’s observation, the evolution list is really the most 
effective as a working list for bringing forward in-scope proposals.  There’s a 
ton of different topics people want to talk about — and their is some obvious 
angst about getting to those — but at the end of the day there is only so much 
bandwidth from everyone to pay attention to these discussions and to get 
seriously invested in them.  Maybe moving to Discourse (which is something we 
still want to do, but have had limited bandwidth to implement) will provide the 
“off-list” communication channels analogous to the ones Xiaodi describes that 
keeps those discussions in the Swift.org discussion forums but clearly 
separates discussion for in-scope proposals versus the side discussions people 
want to have on topics they are interested in.  Even in this setup, however, I 
think everyone needs to acknowledge that members of the Core Team or anyone 
else active in the evolution process has limited capacity to participate in 
only so many discussions.  In reality, the discussions that are about in-scope 
proposals will continue to get the priority attention even if there is a place 
to discuss things that are out-of-scope.

I appreciate everyone’s thoughts here, and myself and other members of the Core 
Team are keenly interested in finding ways to improve the nature of 
swift-evolution for the benefits of its participants and the broader Swift 
community.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0180: String Index Overhaul

[Ted Kremenek via swift-evolution]

Hello Swift community,

The review of SE-0180 "String Index Overhaul" begins now and runs through June 
8, 2017.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md
 

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at:

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md
 

Reply text

Other replies
What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,
Ted (Review Manager)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0178: Add unicodeScalars property to Character

[Ted Kremenek via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0178-character-unicode-view.md
 


The review of “SE-0178: Add unicodeScalars property to Character' ran from May 
12…17, 2017.

The proposal is accepted without revision.  The proposal was uncontentious both 
on swift-evolution and in the Core Team review.

Thanks to everyone who participated in the review!

- Ted
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0178: Add unicodeScalars property to Character

[Ted Kremenek via swift-evolution]

Hello Swift community,

The review of SE-0178: Add unicodeScalars property to Character begins now and 
runs through May 17, 2017.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0178-character-unicode-view.md
 

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at:

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0178-character-unicode-view.md
 

Reply text

Other replies
What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,
Ted (Review Manager)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0173: Add MutableCollection.swapAt(_:_:)

[Ted Kremenek via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0173-swap-indices.md
 


The review of “SE-0173: Add MutableCollection.swapAt(_:_:)” (originally named 
"Add MutableCollection.swap(_:with:)”) ran from April 25...28, 2017.

The proposal is accepted, including the revision to change the method name from 
“swap(_:with:)” to “swapAt(_:_)” that came out of the Core Team meeting.

The consensus on swift-evolution was to add the method, with division mostly on 
the naming of the method.  The Core Team reviewed the proposed options as well 
as consulted the API design guidelines to resolve the issue:

https://swift.org/documentation/api-design-guidelines/ 


Two important points from the guidelines serve to us well here:

  "Omit all labels when arguments can’t be usefully distinguished”
 
and:

  "When the first argument forms part of a prepositional phrase, give it an 
argument label...An exception arises when the first two arguments represent 
parts of a single abstraction….In such cases, begin the argument label after 
the preposition, to keep the abstraction clear."

The combination of these rules leads to the method name “swapAt(_:_:)”, which 
the Core Team believes was most in line with the guidelines.  The proposal is 
accepted with this revision.

Thanks to everyone who participated in the review!

- Ted
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0173: Add `MutableCollection.swap(_:with:)

[Ted Kremenek via swift-evolution]

Hello Swift community,

The review of SE-0173 "Add MutableCollection.swap(_:with:)" begins now and runs 
through April 28, 2017.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0173-swap-indices.md
 

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at:

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0173-swap-indices.md

Reply text

Other replies
What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,
Ted (Review Manager)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted Kremenek via swift-evolution]

> On Apr 18, 2017, at 12:00 AM, David Hart via swift-evolution 
> > wrote:
> 
> Here's my rough idea:
> The Swift compiler gains a new off-by-default `next` version triggerable with 
> the `-swift-version next` flag.
> All controversial proposals start their implementation in that version.
> Once one of the poposals feels stable enough, it is brought into an official 
> version.
> Developers would be encouraged to try the `next` features while being warned 
> that source compatibility on that version will *not* be garanteed.
> As the vast majority of the Swift user base are still Apple platform 
> developers, I think it would be important for the success of that strategy 
> that the applications compiled with the `next` flag be accepted on the Apple 
> stores or it will reduce the group of developers ready to play in this 
> "breeding-group".

Hi David,

I think this is a well-intentioned suggestion, but I see several problems with 
this approach.

The first problem is one of expectations.  Developers invest in using features 
because they want to write code to get their work done.  Once someone starts 
shipping something that depends on a feature they get very grumpy when it gets 
taken away.  It doesn’t really matter if the feature is “official” or not.  
Once enough people invest in using a feature it becomes “unofficially” part of 
the language.  IMO, that doesn’t promote a model where changes to the language 
are well-considered.

The second problem is that within the compiler there is still vestigial 
remnants of earlier days in Swift when we were doing a lot of experimentation.  
Before Swift 1 was released we toyed around quite a bit with the syntax, the 
type checker, pretty much everything.  We’d have a design meeting and then 
immediately someone would go implement something in the compiler.  During those 
days such rapid experimentation was helpful to see how ideas would work out and 
to get a feel for the language we were crafting.  But as time has gone by we’ve 
repeatedly found ourselves removing cruft from the compiler’s implementation 
and fixing bugs from technical debt of incompletely implemented features or 
features that didn’t work well together.  Features added for the purpose of 
experimentation are almost always incomplete — it’s the very nature of 
experimentation.  It is also very easy to convince yourself that a new language 
feature “works” when you try it out on a few examples.

No design process is going to be perfect.  We made a lot design decisions 
before Swift was publicly announced that were made based on our intuition and 
experiences, but really those decisions weren’t evaluated until people started 
writing a lot of Swift code.  We then have gone back — several times — and have 
revised core design decisions in the language based on learning from real-world 
usage of Swift.  With the access control saga I think we saw another instance 
of that story: a lot of discussion happened in the Swift 3 timeframe, but some 
important factors/implications of the design being discussed that are now 
obvious in hindsight just weren’t apparent when the discussions were happening. 
 I believe some number of these sagas are inevitable, and hopefully we learn 
from them to better inform our design decisions in the future.

I know the idea behind having a “-swift-version next” is to allow people to 
invest in experimental ideas to provide real feedback, but I don’t think this 
encourages good language design and many developers would be fearful of using 
such experimental features.  Those that fall in love with an experimental 
feature would likely fervently defend their existence, even if they end up 
being a bad idea.  It’s also not clear by what criteria we would take 
experimental features into the compiler in the first place, and adding more 
cruft into the compiler could be very detrimental to its implementation quality.

As Chris said, Xcode betas really are a good time for people to provide 
feedback about features.  With Swift 3 some of that feedback was delayed 
because of the upheaval caused by the Grand API Renaming and the migration work 
projects needed to do to go from Swift 2 to Swift 3.  Going forward the intent 
is that the evolution of Swift provides a much smoother, continuous experience 
for users, and allows them to try out new features of the language more easily 
and thus possible provide feedback sooner.

Ted___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] ABI dashboard now up

[Ted Kremenek via swift-evolution]

Hi everyone,

We now have a dashboard up on Swift.org to track remaining tasks for ABI 
stability:

  https://swift.org/abi-stability/

The contents of the dashboard (which we may refine over time*) are largely 
drawn from JIRA and the ABI manifesto:

  https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md

The tasks currently tracked on the dashboard are fairly low-level details 
concerning the ABI itself.  These include details that should be re-reviewed 
and finalized, or finishing up areas we know are incomplete.

Ted

* - One area that is currently under represented in the dashboard is the work 
on the standard library.  The work needed to be done is fairly well understood; 
there's just some effort needed to aggregate that information into rows in the 
dashboard.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift 4 — converging "phase 2" discussions

[Ted Kremenek via swift-evolution]

Hi everyone,
 
In mid-February we kicked of "stage 2" for the discussion of evolution 
proposals for Swift 4:
 
  
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032116.html
 
The timetable set forth was to have discussions for "stage 2" go through April 
1.  The intent of that timetable was to (a) timebox discussions on proposals to 
help *focus* them within the theme/focus areas of the release and to (b) 
provide time after discussion to *implement* approved proposals for Swift 4.
 
While the April 1 date for the end of stage 2 has passed, it is clear that by 
looking at where we are in the development of Swift 4 and what remains to be 
done that there are still important discussions happening on swift-evolution 
concerning changes possibly impacting Swift 4.  Those discussions should 
continue and given the opportunity to converge.  That said, we have reached to 
point where we need to be increasingly circumspect on what topics remain in 
scope for Swift 4.

At this point, discussions about changes impacting Swift 4 should generally 
focus in the following areas:
Anything fitting in the "stage 1" phase for the release, such as (among others) 
the `String` re-evaluation and the memory ownership model remain priority 
topics to discuss.

*Existing* topics we have already covered during "stage 2" also remain relevant 
to discuss for the release, although the scope of actual change we will 
consider for Swift 4 is rapidly diminishing.
The distinction of what is "out-of-scope" may not always be clear to everyone, 
and the Core Team will try and provide clear guidance as discussions happen on 
swift-evolution where appropriate to indicate whether or not something is in 
scope for Swift 4.
 
Looking beyond Swift 4, serious discussion about Swift 5 will likely start up 
in July as the themes and focus areas of that release are identified.

Thank you to everyone who has contributed to the discussions so far to help 
shape Swift 4!

Ted
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Setting expectations on when we move to Discourse

[Ted kremenek via swift-evolution]

Hi everyone,

Moving to Discourse (from the mailing lists) is something that is being scoped 
out, but I wanted to lay some expectations that the move will not be immediate.

The reason is that the people who would do the work on making the transition 
were already busy with already planned infrastructure work.  Once some of that 
completes, probably in the next few weeks, a more serious push can be made on 
doing the actual move.

Ted
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 4, stage 2 starts now

[Ted Kremenek via swift-evolution]

> On Feb 16, 2017, at 10:17 PM, Chris Lattner <clatt...@nondot.org> wrote:
> 
> On Feb 16, 2017, at 4:18 PM, Ted Kremenek via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> Deferring ABI Stability from Swift 4
>> 
>> Given the importance of getting the core ABI and the related fundamentals 
>> correct, we are going to defer the declaration of ABI stability out of Swift 
>> 4 while still focusing the majority of effort to get to the point where the 
>> ABI can be declared stable.
>> 
> Given where we are in the yearly schedule, I think that this is a pragmatic 
> decision.  ABI stability is far more important to Apple than it is to most 
> developers, so I’m happy to see that you’re prioritizing the needs of the 
> community (improved compile time, compiler stability, etc), particularly 
> given the importance of doing the right thing for the long term success of 
> Swift.
> 
> Beyond that, I agree that it is prudent to continue work on the many ABI 
> stability tasks despite it not being a goal for Swift 4.  Given the 
> significance of declaring ABI stability, it would be great to get these tasks 
> really nailed down early in the Swift 5 schedule so you have time to bake it 
> out.

Absolutely — giving time for these changes to bake to make sure we did not miss 
anything is essential part of keeping the focus in Swift 4 on core ABI 
stability tasks (and other language fundamentals that impact ABI and source 
stability).  That thinking went into the scoping of stage 2.

> 
> Do you have any idea what the typical download size impact of the Swift 4 
> libraries will be on the ARM64 slice of a typical iOS app?  I know that many 
> of the ABI-related optimizations also contribute to a significant code size 
> improvement, but don’t know how folks expect that to net out.  Do you think 
> that it is plausible to get the overlays coalesced with the stdlib into a 
> single dylib, improving app launch times?

This is an interesting idea, but off-topic for swift-evolution.  A better place 
to discuss this is swift-dev.

That said, there are tradeoffs here: creating a single dylib slightly 
complicates the long-term goal of sinking the overlay APIs back into the OS, 
and the number of overlays is not guaranteed to remain fixed so the tradeoffs 
of creating a single dylib versus multiple are nuanced.  The focus has been on 
the ABI-related optimizations, such as reducing the size of mangled symbols, 
which are tasks that absolutely need to be done before ABI stability.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift 4, stage 2 starts now

[Ted Kremenek via swift-evolution]

Back in July, we laid out a plan for Swift 4 which divided the release into two 
stages. Since then, we’ve been in Swift 4 stage 1, which is characterized by 
the following text in the swift-evolutionrepository's README.md 

 file as follows:

Stage 1 focuses on the essentials required for source and ABI stability. 
Features that don't fundamentally change the ABI of existing language features 
or imply an ABI-breaking change to the standard library will not be considered 
in this stage. Swift 4 is currently only considering proposals that fit in 
Stage 1.

Stage 2 will commence once the implementation work on the Stage 1 features is 
cresting, and can contain a few other large and small features. We expect that 
stage 2 will commence some time in Spring 2017.
Since July, we now have a much better understanding now of how to achieve ABI 
stability, with an ABI Manifesto 
 
detailing the list of all language/implementation work that is needed to 
achieve ABI stability. We have made substantial progress in that work during 
stage 1, but much remains to be done. Once Swift achieves ABI stability the ABI 
can be extended, but not changed. Thus the cost of locking down an ABI too 
early is quite high.

Deferring ABI Stability from Swift 4

Given the importance of getting the core ABI and the related fundamentals 
correct, we are going to defer the declaration of ABI stability out of Swift 4 
while still focusing the majority of effort to get to the point where the ABI 
can be declared stable.

To allow the community to follow along with this effort, an ABI dashboard will 
get wired up from the swift-evolution 
 home page that will present a table 
of main ABI tasks remaining and what Swift release they landed in. This 
dashboard will largely track open tasks in JIRA. I expect the dashboard to be 
up next week, and I'll send a follow up email when it is available.

Stage 2
With ABI stability well-understood and many of the stage 1 goals underway, it 
is time to open up Swift 4 stage 2 to expand the scope of proposals to be 
considered.

Timeline

Stage 2 starts right now.  All design work and discussion for stage 2 extends 
to April 1, 2017. The intent is to timebox discussion to provide adequate time 
for the actual implementation of accepted proposals.

Scope

Swift 4 stage 2 builds on the goals of stage 1. It differs in that stage 2 
proposals may include some additive changes and changes to existing features 
that don't affect the ABI. There are a few focus areas for Swift 4 stage 2:

Stage 1 proposals: Any proposal that would have been eligible for stage 1 is a 
priority for stage 2.

Source-breaking changes: The Swift 4 compiler will provide a 
source-compatibility mode to allow existing Swift 3 sources to compile, but 
source-breaking changes can manifest in "Swift 4" mode. That said, changes to 
fundamental parts of Swift's syntax or standard library APIs that breaks source 
code are better front-loaded into Swift 4 than delayed until later releases. 
Relative to Swift 3, the bar for such changes is significantly higher:

The existing syntax/API being changed must be actively harmful.
The new syntax/API must clearly be better and not conflict with existing Swift 
syntax.
There must be a reasonably automatable migration path for existing code.
Improvements to existing Standard Library facilities: Additive changes that 
improve existing standard library facilities can be considered. With standard 
library additions in particular, proposals that provide corresponding 
implementations are preferred. Potential focus areas for improvement include 
collections (e.g., new collection algorithms) and improvements to the 
ergonomics of Dictionary.

Foundation improvements: We anticipate proposing some targeted improvements to 
Foundation API to continue the goal of making the Cocoa SDK work seamlessly in 
Swift. Details on the specific goals will be provided as we get started on 
Swift 4 stage 2.

As part of initiating Swift 4 stage 2, the Core Team reviewed those proposals 
that were accepted into Swift 3 but were never implemented:

SE-0104 "Protocol-oriented Integers": This proposal requires revision and 
another round of review based on other changes that have been made to the 
language and standard library since acceptance.

SE-0075 "Adding a Build Configuration Import Test": This is (still) an additive 
proposal and no other changes affect this proposal. It will be carried forward 
and considered accepted for Swift 4.

SE-0042 "Flattening the function type of unapplied method references”: This 
proposal requires another round of review. This is a significant 
source-breaking change, and the bar for such source-breaking changes is 
considerably higher in Swift 4 than it was in Swift 3.

SE-0068 

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Ted Kremenek via swift-evolution]

> On Feb 9, 2017, at 4:09 PM, Matthew Johnson  wrote:
> 
> 
>> On Feb 9, 2017, at 6:04 PM, Ted Kremenek > > wrote:
>> 
>> 
>>> On Feb 9, 2017, at 3:52 PM, Ted Kremenek via swift-users 
>>> > wrote:
>>> 
 I’ve been mostly silent in this conversation largely because I didn’t 
 realize it was leading up to a formal decision.  I wish it would have 
 followed the proposal process so it was clear to everyone that a decision 
 was being considered and this was our chance to offer input.  
>>> 
>>> FWIW, I am not ignoring this thread.  At some point there was diminishing 
>>> signal on the thread, and it felt like the category of opinions that had 
>>> been voiced had been vocalized on the thread.  Looping in swift-users into 
>>> that thread would have been a good thing to do in hindsight so more people 
>>> felt like they had a chance to participate.  Based on what I am seeing in 
>>> reaction to this decision, however, I’m not seeing much new signal.
>> 
>> Just to add to this point — new insights on this topic are welcome, and will 
>> be paid attention to.  The decision to change to a forum is because that was 
>> evaluated as being the best thing for the community, based on the range of 
>> opinions provided and the tradeoffs made.  If there is something important 
>> that was missed, obviously that is not going to be ignored.  We want to do 
>> the right thing.  So far I still feel that moving to a forum software is the 
>> right choice, but I’d like to do that in a way that allows people to still 
>> participate effectively via email.
> 
> Is there any way to have a trial run so we can evaluate the email experience 
> of using the forum software before we make the final switch?  I agree that 
> this sounds like the right direction, but it’s hard to know what the email 
> experience will really be like until we give it a try for a week or so.

I need to formalize a plan, but yes I’d like to trial this somehow.  Nate Cook 
created a staged installation of Discourse when the thread on swift-evolution 
was happening and there was some useful telemetry out of that experiment (such 
as how rich text email interacted with doing inline replies).  Moving to 
Discourse (or some alternate forum software if we decide Discourse is not a 
fit) would be a staged thing.  The main question to me is how do we do a 
meaningful trial without actually doing the real discussions in the forum 
(while the mailing lists are still running).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Ted Kremenek via swift-evolution]

> On Feb 9, 2017, at 3:52 PM, Ted Kremenek via swift-users 
>  wrote:
> 
>> I’ve been mostly silent in this conversation largely because I didn’t 
>> realize it was leading up to a formal decision.  I wish it would have 
>> followed the proposal process so it was clear to everyone that a decision 
>> was being considered and this was our chance to offer input.  
> 
> FWIW, I am not ignoring this thread.  At some point there was diminishing 
> signal on the thread, and it felt like the category of opinions that had been 
> voiced had been vocalized on the thread.  Looping in swift-users into that 
> thread would have been a good thing to do in hindsight so more people felt 
> like they had a chance to participate.  Based on what I am seeing in reaction 
> to this decision, however, I’m not seeing much new signal.

Just to add to this point — new insights on this topic are welcome, and will be 
paid attention to.  The decision to change to a forum is because that was 
evaluated as being the best thing for the community, based on the range of 
opinions provided and the tradeoffs made.  If there is something important that 
was missed, obviously that is not going to be ignored.  We want to do the right 
thing.  So far I still feel that moving to a forum software is the right 
choice, but I’d like to do that in a way that allows people to still 
participate effectively via email.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Ted Kremenek via swift-evolution]

> On Feb 9, 2017, at 9:30 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Feb 9, 2017, at 11:16 AM, Jens Alfke via swift-users 
>> > wrote:
>> 
>> 
>>> On Feb 9, 2017, at 3:41 AM, Jan Neumüller via swift-users 
>>> > wrote:
>>> 
>>> I would prefer http://www.fudforum.org/  that has 
>>> good mailing list support, too.
>> 
>> Well, we appear to have completely opposite opinions on UI/usability. I took 
>> a look at fudforum and yeah, to my eyes it exemplifies the awful clutter 
>> that’s been a hallmark of web forums since before PHPBB. There’s so much 
>> visual noise it’s very hard to parse or to find anything. Clearly designed 
>> by a coder with a big hammer named “”. I’m not a UI designer, but 
>> I’ve worked extensively with UI designers (I spent 15 years at Apple working 
>> on stuff like iChat and AppleScript) so I think I have some grounding in the 
>> field.
>> 
>> I do believe, though, that whatever solution swift.org  
>> switches to needs to have good email support. That way the people who hate 
>> the web UI, or who just don’t prefer to use the web for discussions, can 
>> keep using email as we do today. This is perfectly feasible to do; again, 
>> groups.io  is a good example. 
>> 
>> Here my concern is that I have not found a way to configure Discourse to 
>> make its email notifications work well as a substitute for a mailing list. I 
>> have admin privileges on a Discourse installation run by my employer, so 
>> I’ve looked through the entire admin UI for ways to improve the emails, and 
>> some of the problems don’t seem fixable by tweaking settings.
>> 
>> At this point I’m going to shut up because it sounds like the decision has 
>> been made, and I don’t want to contribute to further bike-shedding.
> 
> I’ve been mostly silent in this conversation largely because I didn’t realize 
> it was leading up to a formal decision.  I wish it would have followed the 
> proposal process so it was clear to everyone that a decision was being 
> considered and this was our chance to offer input.  

FWIW, I am not ignoring this thread.  At some point there was diminishing 
signal on the thread, and it felt like the category of opinions that had been 
voiced had been vocalized on the thread.  Looping in swift-users into that 
thread would have been a good thing to do in hindsight so more people felt like 
they had a chance to participate.  Based on what I am seeing in reaction to 
this decision, however, I’m not seeing much new signal.

> 
> I really like the experience of participating in the community via email.  If 
> I knew a decision was being seriously considered I would have taken a closer 
> look at Discourse and likely offered more input.  I will be disappointed if 
> the experience of participating is not at least as good as it is using email.

This opinion was also eloquently voiced on the swift-evolution thread, and FWIW 
it is one that holds weight.  I really want to strike a good balance here so we 
do what is best for the overall community.  The reality is that we are pivoting 
from one technology to another, and with a web forum naturally the prime 
experience is in that forum.  Email will likely feel “second class” to some 
degree simply because it, by design, is not the primary interaction model for 
forum software like Discourse.  That doesn’t mean the email experience has to 
be terrible.  Ideally it is good experience so that people who want to continue 
to use email for participation can continue to do so.

> 
> One of the most important reasons I like using email is that Mail offers a 
> great experience on iPhone and iPad.  I am skeptical that a web-based forum 
> could offer the same level of convenience and efficiency for keeping up with 
> the community that email provides.

Email unfortunately provides an uneven experience across clients, including the 
support for threading, what kind of content authorship affordances provided, 
and so forth.  I totally get what you are saying though, being someone who uses 
Mail in the same way.


> 
> I hope that we do find a way to configure our tool (probably Discourse) so 
> that the email experience on iPhone and iPad does not suffer.  If we can meet 
> that criteria and *also* offer the advantages of a web-based tool I will be 
> very happy.  But I think the current email experience on iPhone and iPad 
> should set a minimum criteria that any tool must meet.

This is something I’m interested in achieving as well.  There are a lot of 
tradeoffs here, and I suspect what we end up with will be tradeoffs that will 
be highly subjective from person to person.  The “does not suffer” is hard to 
qualify, at least objectively, because it likely will be *different* from what 
we have now.

> 
>> 
>> —Jens
>> 

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Ted kremenek via swift-evolution]

There will be discussions about each of the mailing lists on whether or not to 
move to Discourse.  My preference is that all of the mailing lists move, but 
the needs of the different lists are slightly different and I didn't want to 
gate moving swift-evolution to a forum based on the outcome of those 
discussions.  It is clear there is a real need that is solved by moving 
swift-evolution to a forum, and I want to get that moving.  As it is, this will 
take some effort to make happen, and likely by that point we'll have settled 
what to do with the other mailing lists.

> On Feb 8, 2017, at 9:50 PM, Muse M via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> I don't see any discussions to have Swift Server Side shift to Discourse 
> forum too?
> 
>> On Thursday, February 9, 2017, James Hillhouse via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> I'll echo Nick and Joshua–thanks Swift Core team for taking the time to 
>> decide on this change.
>> 
>> Jim
>> 
>> 
>> > On Feb 8, 2017, at 9:37 PM, Rick Mann via swift-evolution 
>> > <swift-evolution@swift.org> wrote:
>> >
>> > I second this praise. FWIW, I recently installed Discourse using a 
>> > DigitalOcean droplet, and it couldn't have been easier. Upgrades are 
>> > surprisingly easy, too.
>> >
>> > I have yet to figure out the email integration; I hope you can get that 
>> > working.
>> >
>> > I also hope you give some effort to improving on the default Discourse 
>> > look. It's not bad, but I feel like it doesn't do a good job of 
>> > delineating functional areas on the page. Having said that, I'm more than 
>> > happy to wait indefinitely for such an improvement; it's not worth holding 
>> > up the roll-out.
>> >
>> > Thanks again!
>> >
>> >> On Feb 8, 2017, at 19:34 , Joshua Alvarado via swift-evolution 
>> >> <swift-evolution@swift.org> wrote:
>> >>
>> >> 
>> >> This is an awesome decision and a huge enhancement for the Swift 
>> >> community. Thanks (Core Team) for taking the time to entertain the 
>> >> discussion and move forward with what many community members have wanted.
>> >>
>> >> Alvarado, Joshua
>> >>
>> >>> On Feb 8, 2017, at 5:03 PM, Ted kremenek via swift-evolution 
>> >>> <swift-evolution@swift.org> wrote:
>> >>>
>> >>> Hi everyone,
>> >>>
>> >>> There was a long thread on swift-evolution about whether we should use 
>> >>> modern forum software — like Discourse — as an alternative to the 
>> >>> mailing lists we have now.  After a long discussion, the Core Team has 
>> >>> decided to move swift-evolution and swift-users to Discourse.
>> >>>
>> >>> There are tradeoffs to moving to a forum.  The main advantages are:
>> >>>
>> >>> - Easy for people to participate without subscribing to the entire 
>> >>> mailing list, as well as no need to provide email address to 
>> >>> participate.  A lot of people have voiced concern that they feel 
>> >>> resistance to participate because of needing to subscribe to a mailing 
>> >>> list.
>> >>>
>> >>> - Consistent affordances and rendering of content, including Markdown 
>> >>> support.  This is really useful for having technical discussions.
>> >>>
>> >>> - Better searching of topics, archiving, etc.
>> >>>
>> >>> - More tools for moderation.
>> >>>
>> >>> - Topic cross-referencing, and consistent organization of topics instead 
>> >>> of whatever threading support a mail client provides (which is 
>> >>> inconsistent).
>> >>>
>> >>> I also want to consider moving the -dev lists to the same forum setup as 
>> >>> well; but that will be a separate conversation on those lists.
>> >>>
>> >>> A rollout plan has not been figured out.  People are busy and there are 
>> >>> logistics to figure out.  I will be engaging a handful of members from 
>> >>> the community to help with the transition.  Specifically, there are 
>> >>> those who really value using email for participation on swift-evolution 
>> >>> and swift-users, and the goal is to get the forum setup to allow those 
>> >>> people to continue to feel effective when using emai

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Ted kremenek via swift-evolution]

Hi Jan,

There was a lot of discussion — albeit not on swift-users — and Discourse was 
the one put forward that those that were pro-forum were most advocating.  I 
actually didn't hear alternative forum software get strongly advocated.

Specific things about Discourse (which may be offered by other solutions):

- Good archiving and searching.
- Markdown support.
- Email bridging to those who still want to have a "mailing list" experience.
- Easy participation without needing to subscribe to a high-volume mailing list.

Not all of these benefits are specific to Discourse.

I'm happy to hear your thoughts, but I'd need more precise feedback than 
adjectives like "junk" to weigh in your concerns.  Specific suggestions for 
something better, and why they are better, would be great.

The key decision here is to move away from mailing lists.  Discourse so far 
seems like the best candidate put forth.

Ted


> On Feb 8, 2017, at 4:48 PM, Jan Neumüller via swift-users 
>  wrote:
> 
> May I ask why with so many great open source forums that junk Discourse got 
> chosen? I'm very perplexed by this decision...
> 
> Jan
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Ted kremenek via swift-evolution]

Hi everyone,

There was a long thread on swift-evolution about whether we should use modern 
forum software — like Discourse — as an alternative to the mailing lists we 
have now.  After a long discussion, the Core Team has decided to move 
swift-evolution and swift-users to Discourse.

There are tradeoffs to moving to a forum.  The main advantages are:

- Easy for people to participate without subscribing to the entire mailing 
list, as well as no need to provide email address to participate.  A lot of 
people have voiced concern that they feel resistance to participate because of 
needing to subscribe to a mailing list.

- Consistent affordances and rendering of content, including Markdown support.  
This is really useful for having technical discussions.

- Better searching of topics, archiving, etc.

- More tools for moderation.

- Topic cross-referencing, and consistent organization of topics instead of 
whatever threading support a mail client provides (which is inconsistent).

I also want to consider moving the -dev lists to the same forum setup as well; 
but that will be a separate conversation on those lists.

A rollout plan has not been figured out.  People are busy and there are 
logistics to figure out.  I will be engaging a handful of members from the 
community to help with the transition.  Specifically, there are those who 
really value using email for participation on swift-evolution and swift-users, 
and the goal is to get the forum setup to allow those people to continue to 
feel effective when using email for discussions on these "lists".

More details will be announced as they get figured out, but I felt it was 
important to let the community know about this direction.

Ted




___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted kremenek via swift-evolution]

There has been a tremendous amount of participation on this thread, with some 
extremely thoughtful analysis of how the mailing list serves the community and 
the tradeoffs of moving to a forum, like Discourse.

I've been thinking about the points made on this thread as well as looking at 
the experimental Discourse setup that Nate Cook provided.  While there are 
tradeoffs with moving swift-evolution to Discourse, I think the benefits 
outweigh the negatives.

After discussing this with the Core Team, the decision is to move 
swift-evolution and swift-users to Discourse.  I will also bring it up for 
discussion on the -dev mailing lists to do the same there, so that we all are 
using consistent infrastructure.

No rollout plan has been established yet.  People are busy, and there are a 
variety of logistics to figure out.  My intent is to engage with a handful of 
people across the community on helping with the transition, including making 
sure we configure Discourse properly so we have the best experience for those 
who want to continue to use email.  We also want to import the history of the 
mailing list as well so that we do not lose valuable conversation.  As a 
rollout plan gets figured out it will get communicated.

I realize that many people aren't following this thread anymore, so I'll send 
out a separate email just so people don't miss the decision.  Thank you all to 
EVERYONE who participated in this thread and expressed an opinion.

Ted


> On Jan 23, 2017, at 8:02 AM, Joshua Alvarado via swift-evolution 
>  wrote:
> 
> Hey swifters,
>   I would like to (re)open up discussion on moving away from email for the 
> swift evolution mailing list. I know this has probably been discussed before 
> but it really should be addressed again. I wouldn't even know how to find if 
> it has been discussed before because it would be too hard to go back through 
> the history. 
> 
> The main factors to move away from email is because email may deter 
> newcomers, history, and threads. I may be speaking for myself when saying 
> email may intimidate newcomers from expressing their opinions and thoughts. 
> It is hard to know what has already been discussed and who is even in the 
> active conversation. Keeping track of history is a pain as well. Searching 
> through many emails to find who said what and when is not effective in email 
> clients. Also, code formatting in emails is not effective. Let's discuss and 
> actually make an action to move away from email if the community so agrees. 
> Of course, recommendations are Slack, Hipchat (-1), and Gitter.
> 
> -- 
> Joshua Alvarado
> alvaradojosh...@gmail.com
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 9:56 PM, Erica Sadun  wrote:
> 
> 
>> On Feb 2, 2017, at 10:29 PM, Ted kremenek  wrote:
>> 
>> 
>> 
>> On Feb 2, 2017, at 6:36 PM, Karl Wagner  wrote:
>> 
>>> 
 On 3 Feb 2017, at 02:55, Ted kremenek  wrote:
 
 
 
> On Feb 2, 2017, at 12:58 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> Personally I think that's an absurd reason not to move to a forum. What 
> is your complaint? That it's _too_ inclusive? That others only have 
> trivial things to say? Frankly, every way I try to interpret your comment 
> makes it come off as snobbery.
 
 Hi Karl,
 
 I appreciate your candor here, but let's avoid making these comments sound 
 personal.  This is a thread prompting polarized opinions, and most of it 
 has been civil and productive.  Let's keep it that way.  I do respect that 
 you are anxious to see progress on the resolution of the topic, but these 
 same points could be made in a less antagonistic way.
 
 I encourage all of you to re-read this part of the Code of Conduction on 
 Swift.org:
 
> Examples of unacceptable behavior by participants include:
> 
> The use of sexualized language or imagery
> Personal attacks
> Trolling or insulting/derogatory comments
> Public or private harassment
> Publishing other’s private information, such as physical or electronic 
> addresses, without explicit permission
> Other unethical or unprofessional conduct
> Project maintainers have the right and responsibility to remove, edit, or 
> reject comments, commits, code, wiki edits, issues, and other 
> contributions that are not aligned to this Code of Conduct, or to ban 
> temporarily or permanently any contributor for other behaviors that they 
> deem inappropriate, threatening, offensive, or harmful.
> 
 Thank you,
 Ted
 
>>> 
>>> As I explained to Erica, it isn’t meant to be read personally. What I said 
>>> is that the community should be as inclusive as possible and that 
>>> prejudicing certain opinions as “trivial” conceptually runs against that.
>> 
>> I appreciate that perspective — and I personally agree with that point.  My 
>> cautionary statement — which was also directed at others on the thread — was 
>> to ensure that the thread remains amicable, and that our choice of our words 
>> match our intentions as the arguments become potentially polarized.
> 
> "Trivial" describes the briefness of the response and  *not* the quality of 
> opinions. Quick back and forth comments that fit well on forums can produce 
> an explosion of emails. Moving to a forum that supports email mirroring does 
> not produce the same experience for those using mail clients. 
> 
> -- E

I agree with you that moving to a forum that supports email mirroring will not 
produce the same experience for those using mail clients.  The question to me 
is not whether they are different, but what impact that difference will have in 
practice — and whether that difference, even if it is slightly negative, is the 
right tradeoff.  Some of that is hard to predict, as it comes down somewhat to 
how participation on a swift-evolution forum would be in practice.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 7:23 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> Great, but let's continue discussing what the needs and aspirations of the 
> community are and what our non-goals are, then study what platforms best fit 
> those. It sure sounds nice that Discourse can be set up as a mailing list, 
> and that it can have extra voting dingbats or none at all, etc., etc. But in 
> deciding what platform we should use it helps not to lose sight of what kind 
> of a community we want to promote. Articulate those and gain some consensus, 
> and after that the process of comparing product feature lists will surely be 
> the easy part.

I agree — which should pick the tool that matches with community we want to 
promote.

For me I feel that swift-evolution has an established ethos that works well, 
and I would not want to see that go away in a forum.  My hope is a forum allows 
more people to sporadically participate on topics that are of interest to them. 
 I also feel that a forum provides some standard affordances — e.g., Markdown — 
that can be helpful in technical discussions.

Here are the factors I am evaluating:

1. Preserves/encourages the community discussions we want — which ties in with 
the points you made about the nature of the community we want.

2. Make discussions more accessible to members of the community who want to use 
their valuable time to participate in discussions that are important to them, 
but not necessarily need to pay a high cost in participating in all discussions.

3. Ideally not degrade the experience for those participating on 
swift-evolution all the time and are monitoring all (or the majority) of 
traffic.  This is the main concern from people who like the mailing lists.

4. Affordances for searching through topics, cross-referencing, etc.  This is 
very useful for relating similar but disjoint topics.

5. Better tools for authoring content, such as using Markdown (especially for 
writing out code).

6. Privacy — not everyone wants to share their email or create a new one just 
to participate not he evolution threads.  This ties in with #2.

The other thing — which has not been discussed very much — is whether or not if 
we move to a forum to move ALL of the lists to a forum, or just 
swift-evolution.  My preference if we moved to forums would be to go all in, 
but discussion should happen on those lists as well (e.g., swift-dev).


>> On Thu, Feb 2, 2017 at 20:59 Jacob Bandes-Storch <jtban...@gmail.com> wrote:
>> On Thu, Feb 2, 2017 at 6:37 PM, Xiaodi Wu via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> On Thu, Feb 2, 2017 at 8:03 PM, Ted kremenek via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>> On Feb 2, 2017, at 5:35 PM, Karl Wagner via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> It's at least worth a beta test.
>> 
>> There are real concerns to work out here — just moving to the forum blindly 
>> would be bad if it is highly disruptive to the community having important 
>> discussions.  I DO think a forum is likely the way to go, but I also am not 
>> dismissive that individuals who are highly active on swift-evolution that 
>> prefer an email workflow will not have their own participation significantly 
>> compromised by just moving to a forum in a cavalier way.
>> 
>> What I have enjoyed seeing from this thread is a healthy discussion about 
>> tradeoffs of both approaches and an identification of concerns of moving 
>> away from the mailing lists.  Some responses to those concerns have been 
>> "Discourse can handle that", which to me is part of the evaluation of the 
>> tradeoffs.  I am also really happy that Nate setup the mock Discourse setup 
>> so we could evaluate thing like the email bridge.  For example, 
>> experimenting of whether or not a rich HTML email works versus plain text 
>> emails for inline responses (which turns out to have problems), etc.   
>> That's all super useful for actually evaluating moving to Discourse, so in 
>> my mind we are actually trying things out and identifying problem points.
>> 
>> The other thing I'm considering is the practical logistics of getting this 
>> set up and maintained (from an infrastructure perspective).  That's not 
>> something that needs to be discussed on this thread — I'd rather the thread 
>> focus on whether a forum is the right thing for the community.  But it is 
>> still something that is being considered in tandem to this discussion, which 
>> obviously needs to be figured out before we just jump to using Discourse (if 
>> that is what we end up doing).
>> 
>> On the topic of whether a forum is the right thing for th

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

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 6:37 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
>> On Thu, Feb 2, 2017 at 8:03 PM, Ted kremenek via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>> On Feb 2, 2017, at 5:35 PM, Karl Wagner via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> It's at least worth a beta test.
>> 
>> There are real concerns to work out here — just moving to the forum blindly 
>> would be bad if it is highly disruptive to the community having important 
>> discussions.  I DO think a forum is likely the way to go, but I also am not 
>> dismissive that individuals who are highly active on swift-evolution that 
>> prefer an email workflow will not have their own participation significantly 
>> compromised by just moving to a forum in a cavalier way.
>> 
>> What I have enjoyed seeing from this thread is a healthy discussion about 
>> tradeoffs of both approaches and an identification of concerns of moving 
>> away from the mailing lists.  Some responses to those concerns have been 
>> "Discourse can handle that", which to me is part of the evaluation of the 
>> tradeoffs.  I am also really happy that Nate setup the mock Discourse setup 
>> so we could evaluate thing like the email bridge.  For example, 
>> experimenting of whether or not a rich HTML email works versus plain text 
>> emails for inline responses (which turns out to have problems), etc.   
>> That's all super useful for actually evaluating moving to Discourse, so in 
>> my mind we are actually trying things out and identifying problem points.
>> 
>> The other thing I'm considering is the practical logistics of getting this 
>> set up and maintained (from an infrastructure perspective).  That's not 
>> something that needs to be discussed on this thread — I'd rather the thread 
>> focus on whether a forum is the right thing for the community.  But it is 
>> still something that is being considered in tandem to this discussion, which 
>> obviously needs to be figured out before we just jump to using Discourse (if 
>> that is what we end up doing).
> 
> On the topic of whether a forum is the right thing for the community, I 
> figure I should throw another point into the conversation. Forums are often 
> designed around a rewards system to encourage participation in approved ways, 
> and to encourage it frequently. People who write popular posts get more 
> likes, or stars, or dingbats, and voting is encouraged from the community to 
> surface the most liked/starred/dingbatted. Just earlier in this thread, there 
> were explicit calls for any adopted platform to have liking/unliking features.
> 
> In a mailing list format, everyone is free to start a new thread. Whether you 
> invented the language or started learning it yesterday, if you have a new 
> idea, it comes into everyone's inbox in exactly the same way. No one's user 
> name has extra flares or trophies or whatever reminding you of their status. 
> Yes, it's true that there have been a proliferation of +1's lately. It is 
> also true that not too long ago community members reminded each other not to 
> do that. The mantra, if I recall, was that it wasn't about soliciting upvotes 
> or downvotes, but rather about posting thoughtful critiques, new takes on the 
> the idea, alternative designs, etc.
> 
> So I guess I'd sum up the point as this: in the current setup, everyone's 
> message is treated equally (unless it exceeds the max email size limit, ugh); 
> in a forum, everyone's likes are treated equally. Are we unsatisfied with the 
> current community ethos? Do we want the evolution process to be about what 
> ideas garnered the most votes and whose thoughts are most popular?

These are really interesting points.  From my perspective, I'm not quite so 
concerned about this because of how I have witnessed the evolution process 
working in practice.  Everyone's message is not treated equally — instead they 
are evaluated based on the quality of their substance.  When arguments for or 
against evolution proposals get evaluated — and eventually arbitrated into a 
decision — it is rarely a strict popularity contest for an idea, but rather a 
balancing of the arguments made.  Essentially your comment about "thoughtful 
critiques", which ultimately I think provides the most meaningful guidance 
towards reaching decisions on language changes.  That's not to say that a ton 
of +1's on an argument doesn't have signal — but I'd never like to see that 
become a direct "vote".







___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 6:36 PM, Karl Wagner  wrote:
> 
> 
>> On 3 Feb 2017, at 02:55, Ted kremenek  wrote:
>> 
>> 
>> 
>>> On Feb 2, 2017, at 12:58 PM, Karl Wagner via swift-evolution 
>>>  wrote:
>>> 
>>> Personally I think that's an absurd reason not to move to a forum. What is 
>>> your complaint? That it's _too_ inclusive? That others only have trivial 
>>> things to say? Frankly, every way I try to interpret your comment makes it 
>>> come off as snobbery.
>> 
>> Hi Karl,
>> 
>> I appreciate your candor here, but let's avoid making these comments sound 
>> personal.  This is a thread prompting polarized opinions, and most of it has 
>> been civil and productive.  Let's keep it that way.  I do respect that you 
>> are anxious to see progress on the resolution of the topic, but these same 
>> points could be made in a less antagonistic way.
>> 
>> I encourage all of you to re-read this part of the Code of Conduction on 
>> Swift.org:
>> 
>>> Examples of unacceptable behavior by participants include:
>>> 
>>> The use of sexualized language or imagery
>>> Personal attacks
>>> Trolling or insulting/derogatory comments
>>> Public or private harassment
>>> Publishing other’s private information, such as physical or electronic 
>>> addresses, without explicit permission
>>> Other unethical or unprofessional conduct
>>> Project maintainers have the right and responsibility to remove, edit, or 
>>> reject comments, commits, code, wiki edits, issues, and other contributions 
>>> that are not aligned to this Code of Conduct, or to ban temporarily or 
>>> permanently any contributor for other behaviors that they deem 
>>> inappropriate, threatening, offensive, or harmful.
>>> 
>> Thank you,
>> Ted
>> 
> 
> As I explained to Erica, it isn’t meant to be read personally. What I said is 
> that the community should be as inclusive as possible and that prejudicing 
> certain opinions as “trivial” conceptually runs against that.

I appreciate that perspective — and I personally agree with that point.  My 
cautionary statement — which was also directed at others on the thread — was to 
ensure that the thread remains amicable, and that our choice of our words match 
our intentions as the arguments become potentially polarized.

> 
> That’s also my reply to the opinion others have shared that subscribing and 
> publishing your email address is a kind of “good pain” to filter out the 
> weak. Take the String model for example - isn’t it possible that this one 
> particular discussion is critical to my business, and that I don’t really 
> care about “for-else syntax” or “Annotation of Warnings/Errors” or “Compound 
> Names for Enum Cases”? I don’t see the logic which says that if I care very 
> much about one aspect of the language, I must care equally about everything 
> else that ever changes with it.

I agree with this point, and I'll be honest that I am not concerned about the 
forums being flooded with noise just because we removed friction for more 
people to participate.  The swift-evolution participants have established a 
timbre for its discussions already that I don't see fundamentally changing if 
we move to a forum.

> 
> I don’t understand why some feel it is so important to discourage ad-hoc 
> contributions. Open-source lives off ad-hoc.

For me, removing some of the friction for participation is one of the most 
appealing aspects of a forum.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 5:35 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> It's at least worth a beta test.

There are real concerns to work out here — just moving to the forum blindly 
would be bad if it is highly disruptive to the community having important 
discussions.  I DO think a forum is likely the way to go, but I also am not 
dismissive that individuals who are highly active on swift-evolution that 
prefer an email workflow will not have their own participation significantly 
compromised by just moving to a forum in a cavalier way.

What I have enjoyed seeing from this thread is a healthy discussion about 
tradeoffs of both approaches and an identification of concerns of moving away 
from the mailing lists.  Some responses to those concerns have been "Discourse 
can handle that", which to me is part of the evaluation of the tradeoffs.  I am 
also really happy that Nate setup the mock Discourse setup so we could evaluate 
thing like the email bridge.  For example, experimenting of whether or not a 
rich HTML email works versus plain text emails for inline responses (which 
turns out to have problems), etc.   That's all super useful for actually 
evaluating moving to Discourse, so in my mind we are actually trying things out 
and identifying problem points.

The other thing I'm considering is the practical logistics of getting this set 
up and maintained (from an infrastructure perspective).  That's not something 
that needs to be discussed on this thread — I'd rather the thread focus on 
whether a forum is the right thing for the community.  But it is still 
something that is being considered in tandem to this discussion, which 
obviously needs to be figured out before we just jump to using Discourse (if 
that is what we end up doing).

Ted___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted kremenek via swift-evolution]

> On Feb 2, 2017, at 12:58 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> Personally I think that's an absurd reason not to move to a forum. What is 
> your complaint? That it's _too_ inclusive? That others only have trivial 
> things to say? Frankly, every way I try to interpret your comment makes it 
> come off as snobbery.

Hi Karl,

I appreciate your candor here, but let's avoid making these comments sound 
personal.  This is a thread prompting polarized opinions, and most of it has 
been civil and productive.  Let's keep it that way.  I do respect that you are 
anxious to see progress on the resolution of the topic, but these same points 
could be made in a less antagonistic way.

I encourage all of you to re-read this part of the Code of Conduction on 
Swift.org:

> Examples of unacceptable behavior by participants include:
> 
> The use of sexualized language or imagery
> Personal attacks
> Trolling or insulting/derogatory comments
> Public or private harassment
> Publishing other’s private information, such as physical or electronic 
> addresses, without explicit permission
> Other unethical or unprofessional conduct
> Project maintainers have the right and responsibility to remove, edit, or 
> reject comments, commits, code, wiki edits, issues, and other contributions 
> that are not aligned to this Code of Conduct, or to ban temporarily or 
> permanently any contributor for other behaviors that they deem inappropriate, 
> threatening, offensive, or harmful.
> 
Thank you,
Ted




___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted kremenek via swift-evolution]

> On Jan 27, 2017, at 4:21 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
>> On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolution 
>>  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 Brackett-Rozinsky via swift-evolution 
>>  wrote:
>>> On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution 
>>>  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 backups, and perform all the 
>>> other maintenance and administrative work it takes to properly run a system 
>>> like Discourse, a web forum, or even a bug tracker.
>>> 
>>> I will volunteer to be a moderator of the Swift forums. I have time 
>>> available, and the core team surely has better things to do.
>>> 
>>> Nevin
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> Personally, I’d prefer if we used GitHub Issues. I like keeping the current 
> state of the project together with the known issues in it. It also has better 
> formatting and actually supports some kind of syntax highlighting for Swift 
> code.

We did not go with GitHub Issues for our bug tracking for a few reasons (in no 
particular order):

(1) At the time Swift became open source, GitHub did not support arbitrary 
attachments to issues, which seemed a non-starter since it is important to 
allow users to be able to file meaningful bug reports with reproducible test 
cases.  This has since been resolved.

(2) The locus of everything on GitHub is the repository.  The Swift project 
spans a bunch of repositories, and we felt it was not desirable to have GitHub 
Issues, at least for the purposes of bug-tracking, on a per repository level.  
Instead, we wanted a central place to file issues that had its own affordances 
for organizing them.  This is important for many reasons.  First, not all the 
logical "sub-components" have their own repositories, and it is important to 
distinguish in the bug-tracker the differences between (say) compiler and 
standard library bugs.  We also found that users frequently do not know what 
component — even if they are separate repositories in GitHub — to file a bug 
report against, and often get it wrong.  Having a central bug database allows 
us to move things around.  JIRA also provides a lot more tools out of the box 
for managing issues at scale.

Note that syncing with other bug tracking systems is not an issue with either 
JIRA or GitHub Issues, since both provide nice web services APIs for querying 
them.

I completely agree that GitHub provides a nicer interface than JIRA, and would 
be one less tool for us to use.  Unfortunately, it doesn't match with some 
important workflows we have in mind for bug tracking.  It forces an 
organization of issues that doesn't match with what the project needs.  If 
those problems did not exist, we'd almost certainly be using GitHub Issues for 
issue tracking as that would more tightly match with the development workflows 
of the rest of the project (e.g., pull requests).

It's an interesting idea to use GitHub Issues or JIRA essentially as a forum — 
but it feels a bit too structured.  I pretty much share Goffredo's opinion here 
on the value of a forum like Discourse versus using a tool like JIRA for 
discussions.  The discussions on swift-dev or swift-evolution often are just 
discussion or even chatter — important chatter, but unstructured and ad hoc.  I 
can see something like GitHub Issues being a useful way for tracking more 
official discussions, such as when a proposal is getting official discussed, 
but I'm not certain if doing something different for those kinds of discussions 
than what are done for the informal shop-and-idea-around discussions on the 
mailing list would be worth it.

> 
> I just assumed that some of our requirements (e.g. syncing with Apple’s 
> internal “radar” system) disqualified it.
> 
> The reason why we don’t have topics every month about migrating our 
> bug-tracking system is that JIRA (while perhaps not optimal) is at least 
> passable. That’s more than you can say for the mailing lists, most of the 
> time.
> 
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org

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

[Ted Kremenek via swift-evolution]

> 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 prematurely would be detrimental to the 
long-term future of the language.

Part of the point of the ABI manifesto is to scope out what are the desirable 
or critical changes needed before ABI gets locked down.  From that we can have 
concrete discussions on what’s left to be done, how much work it will take to 
get there, etc.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted Kremenek via swift-evolution]

Thanks Jacob.

It also looks like one can initiate a new topic via email — does that sound 
correct?

> On Jan 25, 2017, at 10:28 PM, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
> 
> Discourse provides:
> 
> - Reply to a topic via email: 
> https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099
> - "Mailing list mode": 
> https://discourse.mcneel.com/t/mailing-list-mode-for-discourse/5763 & 
> https://meta.discourse.org/t/what-is-mailing-list-mode/46008
> 
>> On Wed, Jan 25, 2017 at 10:13 PM, Ted kremenek via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> I had this same question in my mind — especially if one can reply to an 
>> email and it posts back to the forum.
>> 
>> The mailing list model works well for those who want to get the entire feed 
>> of traffic, and easily monitor which threads they want to follow/read using 
>> the standard affordances in their mail program (e.g., mail filters, flagging 
>> messages, and so on).
>> 
>> The forum interface provides a way for people to just jump in and 
>> participate on specific topics, provide better (standard) rendering of 
>> content — such as code (which can be nice for technical conversations), and 
>> better archiving and possibly be more searchable.
>> 
>> If Discourse supports participation via email, it seems we get the best of 
>> both worlds, as you say.  I'm not super familiar with what Discourse can do 
>> in this regards.
>> 
>>> On Jan 25, 2017, at 9:22 PM, Nevin Brackett-Rozinsky via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Can a forum be configured to send each new post to the mailing list with 
>>> proper subject line?
>>> 
>>> If so, that would enable a best-of-both-worlds scenario—or at least the 
>>> ability to dip our toes in a forum to see if it works, while still showing 
>>> everything on-list.
>>> 
>>> Nevin
>>> 
>>> 
>>> 
>>>> On Wed, Jan 25, 2017 at 11:28 PM, Chris Lattner via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>>> On Jan 25, 2017, at 6:57 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>>> 
>>>>>>> Signing up for mailing lists is straightforward, yes—but that’s only a 
>>>>>>> small part of it. Signing up for a mailing list is a *commitment.* Once 
>>>>>>> you do it, your inbox will be inundated with mailing list posts, making 
>>>>>>> it difficult to find messages that actually have been intended for you 
>>>>>>> personally. Therefore, you’ll have to deal with that somehow. You can 
>>>>>>> set up rules in Mail to route mailing list posts to a separate folder, 
>>>>>>> but that won’t help you if you access your webmail from a public 
>>>>>>> machine. 
>>>>>> 
>>>>>> FWIW, I subscribe to many mailing lists in gmail and have it auto filter 
>>>>>> emails to mailing lists into a separate mailbox (well, really, tags) for 
>>>>>> each list.  It works great for me.
>>>>>> 
>>>>>> This doesn’t detract from your point about it being a commitment though.
>>>>> 
>>>>> It does kind of imply a follow-up question, though: is it _undesirable_ 
>>>>> that signing up for a mailing list is a modicum of commitment?
>>>> 
>>>> I’m mixed on that.  On the one hand, it is great to have some level of 
>>>> commitment before people inject their opinion into the mix for some 
>>>> discussion.  OTOH, I’m sympathetic to the desire that a lot of people want 
>>>> to just “follow along” without participating, and the mailman web 
>>>> interface is pretty uninspired.
>>>> 
>>>> -Chris
>>>> 
>>>> 
>>>> ___
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted kremenek via swift-evolution]

> On Jan 25, 2017, at 9:45 PM, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
> 
>> On Wed, Jan 25, 2017 at 12:05 PM, Ted Kremenek via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> ...
>> 
>> So in short, using mailing lists specifically is not sacred — we can change 
>> what we use for our community discussions.  I just want an objective 
>> evaluation of the needs the mailing lists are meant to serve, and work from 
>> there.  If moving to something like (say) Discourse would be a negative on a 
>> critical piece that is well-served by the mailing lists, that would (in my 
>> opinion) a bad direction to take.  I’m not saying that is the case, just 
>> that this is how I prefer we approach the discussion.
> 
> I'm interested in hearing more about the needs you feel the lists are meant 
> to serve. I'm guessing some of this is a strategic matter for the Swift team, 
> not something that all of us here on the list could fully articulate.
> 
> The valuable things I see are:
> 
> - anyone with an idea can discuss it with the community, regardless of their 
> experience with PLs and compilers.
> - multiple community members, and core team members, can collaborate in a 
> discussion or author a proposal.
> - the community can watch and learn from discussion and implementation 
> processes amongst the core team.
> - the core team can disseminate strategic vision and internal decisions that 
> otherwise would have to wait for the release notes or WWDC, or at least a 
> blog post.

I think all of these are important.

> 
> None of these seem specific to any particular message board/system, except 
> that they are much more easily attainable with a highly asynchronous system, 
> like you mentioned.

The current set of lists serve different purposes for different audiences.

I suspect those participating on the *-dev lists are mostly fine with keeping 
those as mailing lists.  Those lists are for individuals who want to be 
continuously plugged into the conversations regarding the development of 
Swift's implementation, and the volume of discussion there has tended to be far 
more manageable than on swift-evolution.

For swift-evolution and swift-users, I suspect forums would be a better model.  
It allows people to jump into specific discussions more easily, especially if a 
discussion has already started but they aren't permanently subscribed the feed 
of all chatter on the list.   The Mailman archives aren't "interactive" in that 
one can jump in on a thread; if you missed the thread you essentially missed 
participating in it, and have to start a new one if you want to continue a 
topic.  Forums like allow participation on swift-evolution to be more 
intermittent — facilitating (temporary) wider participation on topics that have 
broader interest to more of the community because of the (possibly) lower 
barrier to entry the ability to jump in on an ongoing topic without needing to 
always be subscribed to everything.  I see some huge advantages there; if we 
think there is a topic that is of particular interest to the community one can 
(say) tweet about it to advertise the discussion and draw more immediate 
participation.

OTOH, I see mailing lists being attractive to those who really want to get the 
entire feed of discussion, apply post-hoc filtering or other management 
techniques to prioritize looking at the discussions that interest them.

I'm keenly interested in seeing if we can get both the benefits of forum and 
mailing lists.  If Discourse provides a nice way to integrate into the current 
email workflow that many of us use — and like — then that seems really 
promising.  The questions that come to mind is whether or not using email would 
really feel second class or awkward.  This includes the formatting of the 
emails, how easy it is to organize topics, etc.


>  
>> 
>> Ted
>> 
>> 
>>>> On Jan 23, 2017, at 3:18 PM, Ole Begemann via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> Obligatory prior discussion sheds, er, I mean threads:
>>>> 
>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025692.html
>>>> / 
>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160801/thread.html#25765
>>> 
>>> I haven't followed the previous discussions closely. As someone who mostly 
>>> follows the discussions passively and only rarely posts something to the 
>>> list, I have two major complaints with the current situation:
>>> 
>>> * The disconnect between the messages in my mail client and their URLs in 

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

[Ted kremenek via swift-evolution]

I had this same question in my mind — especially if one can reply to an email 
and it posts back to the forum.

The mailing list model works well for those who want to get the entire feed of 
traffic, and easily monitor which threads they want to follow/read using the 
standard affordances in their mail program (e.g., mail filters, flagging 
messages, and so on).

The forum interface provides a way for people to just jump in and participate 
on specific topics, provide better (standard) rendering of content — such as 
code (which can be nice for technical conversations), and better archiving and 
possibly be more searchable.

If Discourse supports participation via email, it seems we get the best of both 
worlds, as you say.  I'm not super familiar with what Discourse can do in this 
regards.

> On Jan 25, 2017, at 9:22 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> Can a forum be configured to send each new post to the mailing list with 
> proper subject line?
> 
> If so, that would enable a best-of-both-worlds scenario—or at least the 
> ability to dip our toes in a forum to see if it works, while still showing 
> everything on-list.
> 
> Nevin
> 
> 
> 
>> On Wed, Jan 25, 2017 at 11:28 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>>> On Jan 25, 2017, at 6:57 PM, Xiaodi Wu  wrote:
>>> 
> Signing up for mailing lists is straightforward, yes—but that’s only a 
> small part of it. Signing up for a mailing list is a *commitment.* Once 
> you do it, your inbox will be inundated with mailing list posts, making 
> it difficult to find messages that actually have been intended for you 
> personally. Therefore, you’ll have to deal with that somehow. You can set 
> up rules in Mail to route mailing list posts to a separate folder, but 
> that won’t help you if you access your webmail from a public machine. 
 
 FWIW, I subscribe to many mailing lists in gmail and have it auto filter 
 emails to mailing lists into a separate mailbox (well, really, tags) for 
 each list.  It works great for me.
 
 This doesn’t detract from your point about it being a commitment though.
>>> 
>>> It does kind of imply a follow-up question, though: is it _undesirable_ 
>>> that signing up for a mailing list is a modicum of commitment?
>> 
>> I’m mixed on that.  On the one hand, it is great to have some level of 
>> commitment before people inject their opinion into the mix for some 
>> discussion.  OTOH, I’m sympathetic to the desire that a lot of people want 
>> to just “follow along” without participating, and the mailman web interface 
>> is pretty uninspired.
>> 
>> -Chris
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted Kremenek via swift-evolution]

I have no problem with the project moving to forums instead of the Mailman 
mailing lists we have now — if it is the right set of tradeoffs.

My preference is to approach the topic objectively, working from goals and 
seeing how the mailing lists are aligning with those goals and how an 
alternative, such as Discourse, might do a better job.

The current use of mailing lists has been carry-over of how both LLVM does 
public discussion (which is all mailing lists) and how the Swift team at Apple 
has used mailing lists for discussion.  That inertia has benefits in that it is 
a familiar workflow that is “proven” to work — but the doesn’t mean it is the 
best option going forward.

Here are some of the things that matter to me:

- Topics are easy to manage and search, with stable URLs for archives.

- It is easy to reference other topics with a stable (canonical) URL that 
allows you to jump into that other topic easily.  That’s hard to do if you 
haven’t already been subscribed to the list.

- Works fine with email clients, for those who want to keep that workflow 
(again this inertia is important).

- Code formatting, and other tools that add clarity in communication, are a 
huge plus.

I’d like to understand more the subjective comments on this thread, such as 
"may intimidate newcomers”.  This feels very subjective, and while I am not 
disagreeing with that statement I don’t fully understand its justification.  
Signing up for mailing lists is fairly straightforward, and one isn’t obligated 
to respond to threads.  Are forums really any less “intimating”? If so, why is 
that the case?  Is this simply a statement about mailing lists not being in 
vogue?

I do also think the asynchronous nature of the mailing lists is important, as 
opposed to discussions feeling like a live chat.  Live chat, such as the use of 
Slack the SwiftPM folks have been using, is very useful too, but I don’t want 
participants on swift-evolution or any of our mailing lists feel obligated to 
respond in real time — that’s simply not the nature of the communication on the 
lists.

So in short, using mailing lists specifically is not sacred — we can change 
what we use for our community discussions.  I just want an objective evaluation 
of the needs the mailing lists are meant to serve, and work from there.  If 
moving to something like (say) Discourse would be a negative on a critical 
piece that is well-served by the mailing lists, that would (in my opinion) a 
bad direction to take.  I’m not saying that is the case, just that this is how 
I prefer we approach the discussion.

Ted


> On Jan 23, 2017, at 3:18 PM, Ole Begemann via swift-evolution 
>  wrote:
> 
>> Obligatory prior discussion sheds, er, I mean threads:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025692.html
>> / 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160801/thread.html#25765
> 
> I haven't followed the previous discussions closely. As someone who mostly 
> follows the discussions passively and only rarely posts something to the 
> list, I have two major complaints with the current situation:
> 
> * The disconnect between the messages in my mail client and their URLs in the 
> list archive makes sharing or bookmarking messages a major pain in the ass. 
> If it were possible for each message to contain its own permalink in the 
> footer, I would be much happier. It seems this feature is available in 
> Mailman 3 [1], but the Swift lists seem to be running on Mailman 2.x.
> 
> * The web archive has very bad usability. I suppose design is a matter of 
> taste, but having the archive organized by week is just wrong. This means 
> that readers will regularly miss significant parts of threads that cross week 
> boundaries without even noticing it.
> 
> I don't like the mailing lists (and hadn't subscribed to any for close to a 
> decade before Swift), but fixing the above two points would go 90% of the way 
> for me.
> 
> If you're counting votes, I'm also +1 for trying out Discourse.
> 
> Another, less important complaint:
> 
> * Readability is inconsistent because people use different formatting and 
> email allows full control over HTML. I assume a forum that allows Markdown 
> strikes the ideal middle ground between some control over formatting but not 
> needlessly messing with font sizes etc.
> 
> I can understand if the Swift team is hesitant to switch to a forum. If you 
> have a working mailing list infrastructure everybody at the company is used 
> to, migrating to a forum is a pretty big undertaking and potential disruption 
> to the workflow. I'm not certain conversations will be much easier to follow 
> in a forum.
> 
> I found it very uncomfortable to read the mailing lists in my normal mail 
> client because I want a totally different UI for the two tasks of reading 
> swift-evolution 

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

[Ted kremenek via swift-evolution]

Hi David,

My apologies for being late to the thread — I've been away for the last week.

ABI stability remains a keystone goal for Swift, but the concerns you have here 
about not rushing important things are real.  There's been a lot of scoping 
work into what ABI stability means, soup-to-nuts from the runtime to the 
Standard Library.  As Michael Ilseman said he plans on sending out a manifesto 
shortly (possibly today) that includes a bunch of the scoping information for 
ABI stability.  We also plan on having a dashboard up (probably on swift.org) 
that will allow the community to get a holistic view of the work on ABI 
stability and see the progress being made toward that goal.  With that 
information we (the entire community) can make informed decisions on the 
priorities of specific ABI stability tasks and for Swift in general, and the 
relative tradeoffs being made.  As Joe Groff said elsewhere in this thread some 
aspects of ABI are additive, and thus can be added later.  When scoping ABI 
stability, we are trying to assess those kinds of lateral tradeoffs.

But as you point out, a lot of decisions get locked in once we have ABI 
stability.  As part of that, we'll have some public discussion soon on when to 
open up "phase 2" (per Chris's email over the summer about goals for Swift 4) 
and what it means for Swift 4.  I think a key goal for "phase 2" is to front 
load important design changes to Swift that may have implications on ABI.

Thank you for bringing up this topic.  Let's continue this general discussion 
about ABI stability and what it means for prioritizing specific tasks for Swift 
once Michael has his manifesto out.

Ted

> On Jan 23, 2017, at 10:40 PM, David Hart via swift-evolution 
>  wrote:
> 
> Hello swift-evolution,
> 
> ABI stability is an important feature which many Swift users are looking 
> forward to. If I understand it correctly, once it’s here, the Standard 
> Library becomes part of that ABI and only additive and backwards-compatible 
> changes can be done. Seeing how we are still heavily modifying the Standard 
> Library this year (Strings), wouldn’t it be wiser to let those changes simmer 
> under the scrutiny of the broader community of Swift users for a year before 
> we make it into the ABI?
> 
> ABI compatibility is important. Some projects need it, but I think that most 
> projects (most Apple platform third-party applications) would only mildly 
> benefit from it. But I want to make sure the Standard Library has had enough 
> time to mature before we set it in stone.
> 
> Regards,
> David.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] announcing Server APIs work group

[Ted Kremenek via swift-evolution]

Hi everyone,

I’d like to announce the introduction of a new Server APIs work group:

  https://swift.org/blog/server-api-workgroup/

From the blog post:

"Since Swift became available on Linux there has been a huge amount of interest 
in using Swift on the server, resulting in the emergence of a number of Web 
Frameworks, including Kitura, Vapor, Perfect, and Zewo, along with many others. 
As an important part of the Swift ecosystem, and one that we are keen to 
foster, we are today announcing the formation of the Server APIs work group.

The work group provides the framework for participants in the the community 
with an interest in building server applications and frameworks to come 
together to work on providing new Swift APIs. These APIs will provide low level 
“server” functions as the basic building blocks for developing server-side 
capabilities, removing the reliance on interfacing with generally platform 
specific C libraries for these functions. This will enable more developers to 
create frameworks and server applications using pure-Swift code, without the 
need to also have systems programming skills and knowledge of multiple 
platforms.”

The idea behind the work group is to have a way for the Swift.org community to 
prototype and design a core set of APIs for empowering Swift development for 
server development.  This work group complements the evolution process on 
swift-evolution, whereby the work group will incubate new APIs and libraries 
that eventually will be brought back for formal review/proposal on 
swift-evolution.  The work group, however, provides a focused forum to develop 
and discuss these new APIs.  Please see the blog post for more information, as 
well as the project page on Swift.org:

  https://swift.org/server-apis/

Thanks so much to Chris Bailey for driving much of the effort to organize the 
work group.

Cheers,
Ted


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift 3.0 released!

[Ted kremenek via swift-evolution]

Hi everyone,

Swift 3.0 has been officially released:

https://swift.org/blog/swift-3-0-released/

This moment marks an incredible achievement for the Swift open source 
community.  The release is the culmination of an incredible amount of 
discussion and implementation work to bring it all together.

Beyond the changes to Swift itself, the Linux port has made great strides in 
Swift 3 with the first official release of the core libraries.  The Swift 
Package Manager is now officially available for building cross-platform Swift 
packages.

Thank you to everyone — and I mean everyone — who contributed to Swift 3 in 
some way.

Ted
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Endgame for Swift 3

[Ted kremenek via swift-evolution]

Good question.

Dave/Dmitri: do you have a recommendation here?  I can see either the JIRA 
issues referencing the proposal (if one exists) or updating the gist.  I prefer 
the former.

> On Jul 15, 2016, at 11:18 AM, Will Field-Thompson <will.a...@gmail.com> wrote:
> 
> Is there any way to tell which of the changes in the gist have had proposals 
> associated with them?
> 
> -- Will
> 
>> On Fri, Jul 15, 2016 at 1:46 PM Ted Kremenek via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> Hi everyone,
>> 
>> Swift 3 has shaped up to be a remarkable release — a product of the 
>> inspiration, ideas, and hard labor many people from across the Swift open 
>> source community. It is now time, however, to talk about the endgame for the 
>> release.
>> 
>> Here are the key points:
>> 
>> The last day to take planned source-breaking changes for Swift 3 is July 27.
>> 
>> On that day, there will likely be a set of approved-but-not-implemented 
>> proposals for Swift 3 — including proposals for source-breaking changes. 
>> Will have an open discussion on that day on the fate of those unimplemented 
>> proposals in the context of Swift 3 and future Swift releases.
>> 
>> Starting on August 1 we will open up discussion about Swift 4. Part of this 
>> discussion will likely be guided by important work that was deferred from 
>> Swift 3, as well as the a goal of achieving binary stability in Swift 4. 
>> Until then, however, discussion should remain focused on Swift 3.
>> 
>> Note that there is an intentional gap of a few days between the last planned 
>> day to take source-breaking changes for Swift 3 and when we start talking 
>> about Swift 4. The idea is to provide some time for the community to take 
>> stock of where things have ended up for Swift 3.
>> 
>> The final branching plan for Swift 3 development is to be determined, but 
>> the final convergence branch is likely to be cut from master around that 
>> date or shortly after. Part of it comes down to the discussion on July 27 on 
>> how to handle the remaining unimplemented proposals for Swift 3.
>> 
>> The final release date for Swift 3 is TBD, but essentially after July 27 the 
>> intent is that Swift 3 is in full convergence and not in active development.
>> 
>> With these dates in mind, I want to call attention to some 
>> approved-but-not-yet-implemented proposals that currently I have nobody on 
>> Apple's Swift team able to tackle in the next couple weeks:
>> 
>> SE-0042: Flattening the function type of unapplied method references
>> SE-0068: Expanding Swift Self to class members and value types
>> SE-0075: Adding a Build Configuration Import Test
>> SE-0096: Converting dynamicType from a property to an operator
>> SE-0077: Improved operator declarations
>> SE-0092: Typealiases in protocols and protocol extensions
>> SE-0110: Distinguish between single-tuple and multiple-argument function 
>> types
>> Some proposals — like SE-0075 — are things we can add at any time, but many 
>> of the others tie into the goal of achieving some degree of source-stability 
>> for Swift in Swift 3. I'm letting the community know that these proposals 
>> currently have no implementation traction in case there is interest in 
>> helping make them happen in time for Swift 3.
>> 
>> Related, I'd like to call out a special thanks to the community for getting 
>> implementation traction on SE-0095:
>> 
>> SE-0095: Replace protocol<P1,P2> syntax with P1 & P2 syntax
>> Currently there is a JIRA issue and pull request tracking work on 
>> implementing this proposal.
>> 
>> In addition to these language proposals, there is also an assortment of 
>> outstanding work for the Standard Library that would be great to do for 
>> Swift 3. There is a gist summarizing those tasks:
>> 
>> https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d
>> These tasks are broken down in relative order of difficulty, with a JIRA 
>> issue associated with each one of them. If a JIRA isssue is currently not 
>> assigned to anyone, please consider them fair game to tackle if you are 
>> interested. API changes that have currently not gone through the evolution 
>> process will still need an evolution proposal, even if they are listed in 
>> the gist. If you take on a specific task, please assign the JIRA issue to 
>> yourself so others know it is being tackled.
>> 
>> Thank you to everyone — and I mean everyone — who has contributed to making 
>> Swift 3 happen.
>> 
>> Ted
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Endgame for Swift 3

[Ted Kremenek via swift-evolution]

Hi everyone,

Swift 3 has shaped up to be a remarkable release — a product of the 
inspiration, ideas, and hard labor many people from across the Swift open 
source community. It is now time, however, to talk about the endgame for the 
release.

Here are the key points:

The last day to take planned source-breaking changes for Swift 3 is July 27.

On that day, there will likely be a set of approved-but-not-implemented 
proposals for Swift 3 — including proposals for source-breaking changes. Will 
have an open discussion on that day on the fate of those unimplemented 
proposals in the context of Swift 3 and future Swift releases.

Starting on August 1 we will open up discussion about Swift 4. Part of this 
discussion will likely be guided by important work that was deferred from Swift 
3, as well as the a goal of achieving binary stability in Swift 4. Until then, 
however, discussion should remain focused on Swift 3.

Note that there is an intentional gap of a few days between the last planned 
day to take source-breaking changes for Swift 3 and when we start talking about 
Swift 4. The idea is to provide some time for the community to take stock of 
where things have ended up for Swift 3.

The final branching plan for Swift 3 development is to be determined, but the 
final convergence branch is likely to be cut from master around that date or 
shortly after. Part of it comes down to the discussion on July 27 on how to 
handle the remaining unimplemented proposals for Swift 3.

The final release date for Swift 3 is TBD, but essentially after July 27 the 
intent is that Swift 3 is in full convergence and not in active development.

With these dates in mind, I want to call attention to some 
approved-but-not-yet-implemented proposals that currently I have nobody on 
Apple's Swift team able to tackle in the next couple weeks:

SE-0042: Flattening the function type of unapplied method references 

SE-0068: Expanding Swift Self to class members and value types 

SE-0075: Adding a Build Configuration Import Test 

SE-0096: Converting dynamicType from a property to an operator 

SE-0077: Improved operator declarations 

SE-0092: Typealiases in protocols and protocol extensions 

SE-0110: Distinguish between single-tuple and multiple-argument function types 

Some proposals — like SE-0075 

 — are things we can add at any time, but many of the others tie into the goal 
of achieving some degree of source-stability for Swift in Swift 3. I'm letting 
the community know that these proposals currently have no implementation 
traction in case there is interest in helping make them happen in time for 
Swift 3.

Related, I'd like to call out a special thanks to the community for getting 
implementation traction on SE-0095:

SE-0095: Replace protocol syntax with P1 & P2 syntax 

Currently there is a JIRA issue  and 
pull request  tracking work on 
implementing this proposal.

In addition to these language proposals, there is also an assortment of 
outstanding work for the Standard Library that would be great to do for Swift 
3. There is a gist summarizing those tasks:

https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d 

These tasks are broken down in relative order of difficulty, with a JIRA issue 
associated with each one of them. If a JIRA isssue is currently not assigned to 
anyone, please consider them fair game to tackle if you are interested. API 
changes that have currently not gone through the evolution process will still 
need an evolution proposal, even if they are listed in the gist. If you take on 
a specific task, please assign the JIRA issue to yourself so others know it is 
being tackled.

Thank you to everyone — and I mean everyone — who has contributed to making 
Swift 3 happen.

Ted___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift 2.2 released!

[Ted Kremenek via swift-evolution]

Hi everyone,

I am very pleased to announce the release of Swift 2.2!  This is the first 
release of Swift since Swift became an open source project.  Swift 2.2 began 
it’s convergence in mid-January when it branched from master, and since then is 
had taken curated changes (bug fixes and some language changes) that were 
aligned with the goals of the release.

We have an official release announcement on the Swift.org blog:

  https://swift.org/blog/swift-2-2-released/


Being a minor release, the purpose of Swift 2.2 was to be a transition point 
between Swift 2 and Swift 3.  Swift 2.2 went through a release process that 
will be a prototype for future Swift releases.  The release process was 
described here:

  https://swift.org/blog/swift-2-2-release-process/


While Swift 2.2 contains support for Swift on Linux, support for that platform 
in Swift 2.2 should still be considered relatively new.  The Package Manager is 
not included in this release, nor are the Swift Core Libraries.

Qualification for Swift 2.2 was based on regression tests (run in continuous 
integration), users reporting issues with downloadable Swift 2.2 packages, and 
seeding of the Swift 2.2 compiler in Xcode 7.3 seeds.  In the future I’d like 
to beef up our qualification processes around Linux, including more extensive 
testing of the compiler and LLDB.  Any feedback from the community is welcome 
on how we can improve it.

The swift-2.2-branch release branch will remain “open” under the same release 
manager process of Swift 2.2.  The branch can take targeted fixes in the chance 
that we decide to release a Swift 2.2 dot release.  This would largely be 
driven by feedback from users.

The final tag in GitHub for the release (for the impacted repositories) is 
‘swift-2.2-RELEASE’.

Cheers,
Ted___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution