Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Andrew Bennett via swift-evolution]

Thanks for the detailed response :)

My mistake, I was thinking more in terms of managing a user's expectations
regarding ownership and avoiding retain cycles.

What you've described sounds great. I imagine it should only affect this
proposal if the solution it provides adds additional checks for users
accidentally taking strong references.


On Sat, Jul 30, 2016 at 2:21 PM, Chris Lattner  wrote:

> On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I wrote this a few months ago, but we weren't accepting additive
> proposals. Now we're explicitly looking for something like this:
>
> Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory
>> ownership model to Swift is highly desired by systems programmers and folks
>> who want predictable and deterministic performance (for example, in real
>> time audio processing code). More pertinent to the goals of Swift 4, this
>> feature is important because it fundamentally shapes the ABI. It informs
>> code generation for “inout", how low-level “addressors” work in the ABI,
>> impacts the Swift runtime, and will have a significant impact on the type
>> system and name mangling.
>
>
> Memory ownership is about something slightly different than this.  In the
> context of Swift, the model we’re looking for is:
>
> - You can completely ignore memory ownership features of the language, and
> get very far into development with Swift.  This is in stark contrast with
> Rust and Cyclone, which require you to grapple with it up front.  This
> means that in the Swift context, this will be more of a “power user”
> feature, instead of essential part of the model.
>
> - You can choose to use the memory ownership features by adding extra
> annotations, giving better performance and control over ARC.  Right now we
> have very limited options for avoiding ARC overhead in critical loops,
> largely forcing you to drop down to unsafe constructs.  We’d prefer the
> model to be “you can add more annotations to your code to get better
> performance, allowing the compiler statically verify correctness instead of
> dynamically”.
>
> - Memory ownership control is an extremely non-trivial feature, which will
> probably drive us to add first class move semantics and region types to the
> language.  This will also call for significant standard library
> extensions.  It will pay for this complexity by making it easy to ignore
> the complexity if you don’t want it, and by the fact that the standard
> library and other stuff can go much faster.
>
> - As a Stage 2 feature, I can imagine an opt-in mode that “forces” the use
> of these features, for code that wants to guarantee deterministic
> performance.  This is what enables the use of swift in realtime audio
> applications, for example.
>
> While some initial brainstorming and scoping has been done in this area,
> we’re far from having a concrete design.  We have a few folks who are
> experts at Rust that are helping contribute ideas and experience to this
> though.
>
> If you have more specific questions, feel free to ask about it.
>
> -Chris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Andrew Bennett via swift-evolution]

Answers inline:

On Sat, Jul 30, 2016 at 2:17 PM, Félix Cloutier  wrote:

> Seems to me that we can find similar information just from walking over a
> class's fields to build an ownership graph, and cause warnings/errors when
> you find a strong cycle.
>

This is true, but the intent is a whitelist, which is explicit and cannot
be automated. The intent is to catch as many unintentional strong
references as possible. If you walked the fields, methods, and all uses you
could get the same information, but you wouldn't know if they're
intentional.

It may be possible to imply that something owns fields, but the annotation
may need to be more specific than what that produces. For example:
closures, or collections.


> How do you deal with type erasure?
>

That's an interesting point. Currently it will behave much the same as
other collection types. The collection must designate ownership of its
associatedtypes. If that's a protocol then the ownership should be
inherited from the protocol.


> protocol Foo {}
> class A {
> var foo: Foo
> }
> class B: Foo {
> var a: A
> }
>
> // A and B can have a cycle through the Foo protocol
>
>
> Also, how do you encode that your example's "addCallback" closure
> parameter can't have a strong reference to `self`?
>

You encode it by not including it in the list of owned types. If you want
to be able to have a strong reference to self you'd need `@owns(self)`.


>
> Félix
>
> Le 29 juil. 2016 à 18:42:11, Andrew Bennett via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I'd like an *opt-in* way to verify and prevent *unintentional strong
> references* in Swift.
>
> This can be used to verify ownership structures, and ultimately avoid
> retain cycles.
>
> Read a draft proposal here:
>
> https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/-explicit-ownership-type-attribute.md
>
> TL;DR:
>
> If you have any questions please read the proposal before asking here.
>
> It's an opt-in attribute that defines a whitelist of types something can
> own. For example:
>
> @owns(TypeA, TypeB) struct TypeC { ... }
>
> I wrote this a few months ago, but we weren't accepting additive
> proposals. Now we're explicitly looking for something like this:
>
> Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory
>> ownership model to Swift is highly desired by systems programmers and folks
>> who want predictable and deterministic performance (for example, in real
>> time audio processing code). More pertinent to the goals of Swift 4, this
>> feature is important because it fundamentally shapes the ABI. It informs
>> code generation for “inout", how low-level “addressors” work in the ABI,
>> impacts the Swift runtime, and will have a significant impact on the type
>> system and name mangling.
>
>
>>  - Chris
>> 
>
>
> 
>
> Here's a link to the version of the proposal
> 
>  when
> I sent this email.
> ___
> 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] Improved value and move semantics

[Karl via swift-evolution]

> On 29 Jul 2016, at 18:42, Bram Beernink via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Would it be possible to improve value and move semantics (performance) in 
> Swift? Consider this possible Swift code in a future release of Swift:
> 
> let array1 : [String] = ["Val1", "Val2"]
> let array2 = array1.appended(“Val3”) // Copy of array1 with “Val3” appended. 
> array1 is left untouched. Nothing special yet.
> var array3 : [String] = [“Var1”]
> array3 = array3.appended(“Var2”) // array3 can just be mutated to add “Var2”, 
> while maintaining value semantics. Swift can recognize that array3’s old 
> state is not referenced anywhere in the future.
> let array4 = array2.appended("Val4").appended("Val5") // Copy of array2 with 
> both "Val4" and "Val5" appended. In this case, “Val5” can also be appended by 
> mutation.
> 
> This example illustrates improved value semantics with a string array. But it 
> would be good if this can work with any struct. Maybe via something similar 
> to isUniquelyReferenced? Or maybe you can even have a “smart” self in a 
> non-mutating func in a struct:
> struct Array {
> func appended(e : T) -> Array { // No mutating keyword!
> self.append(e) // self would either be mutated here if the current 
> ref count of self is 1, and self is either a “rvalue” or self’s old state 
> cannot possibly referenced anymore after this call. Otherwise, "self” would 
> actually be a copy of self.
> return self
> }
> }
> 
> I think that with such support it is encouraged to make more use of 
> (immutable) value types while not sacrificing performance. Less mutations 
> lead to more understandable code, which leads to less bugs.
> 
> In any case, keep up the fast improvements to Swift.
> 
> Best regards,
> Bram.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

It’s a known issue. See: 
https://github.com/apple/swift/blob/master/docs/OptimizationTips.rst#advice-use-inplace-mutation-instead-of-object-reassignment
 


I’m not a compiler expert, but in theory I’d expect a smart-enough, fast-enough 
optimiser to be able to replace those with mutating calls. 

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

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Muse M via swift-evolution]

I'm open to ZenHub that can be integrate as part of GitHub for discussion,
pull changes and it makes it easier to reference to the patches within
ZenHub than from Discourse or other forums. Swiftly right?

https://www.zenhub.com

On Sat, Jul 30, 2016 at 10:10 AM, Tim Vermeulen via swift-evolution <
swift-evolution@swift.org> wrote:

> +1. Hirundo makes this format bearable, but it is still far from ideal. I
> see many advantages for using Discourse:
>
> - It has actual syntax highlighting.
> - It’s easier to moderate.
> - It supports real-time updates.
> - It’s easier to follow the flow of a conversation.
> - It has better search.
>
> I don’t doubt more people will take part in the Swift evolution process if
> we switch to Discourse.
>
> > Branching...
> >
> > On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via swift-evolution<
> swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > > On Jul 29, 2016, at 5:14 PM, Brandon Knope bkn...@me.com)>wrote:
> > > >
> > > >Chris, has the core team discussed opening up a forum for discussing
> proposal implementations.
> > > >
> > > >Some of us aren't as skilled as the core team or other contributors
> but would like to learn. A forum is a much easier place for us to post for
> code help and to help others with their questions. I think this could help
> get more involved as it would be a more comfortable format for them. Think
> of how there are Apple Developer forums and not mailing lists for iOS betas
> etc.
> > > >
> > > >I am not saying moving swift-evo to forums *yet* but I believe a lot
> of the newer programmers are more comfortable with a forum format,
> especially when it comes to help and discussing code.
> > > >
> > > >Forums for contributors would:
> > > >- be more familiar for a lot of the newer and not as experienced
> developers
> > > >- be easier to search
> > > >- be easier to moderate (not really a problem yet)
> > >
> > > Hi Brandon,
> > >
> > > Moving from email to a forum system has come up before, but they have
> some disadvantages.One of major wins of email is that it is pervasive and
> can be adapted into other forms.For example, if you haven’t seen it yet,
> check out:
> > > https://stylemac.com/hirundo/
> > >
> > > -Chris
> > >
> > We've discussed forums on swift-evolution before. Maybe it's time for
> another go, with Swift 3 winding down.
> >
> > For context, prior discussions are on this thread:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
> >
> > (-1 for mailman: it's hard for me to even properly find to all the
> prior discussion about mailing lists, because of how mailman's archive
> works...)
> >
> >
> > News in the last few days is that Gmane is at least temporarily
> disappearing:
> https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
> >
> >
> > I'd just like to vote once again forDiscourse(
> http://www.discourse.org/faq/#what):-Excellent web interface(
> https://meta.discourse.org/), from the people who brought you Stack
> Overflow(built-in search, etc.)
> > - Read via email if that's your thing: it has "mailing list mode" which
> includes 1-email-per-post, if that's your cup of tea
> > -Reply via email(
> https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099)if
> that's your thing
> > - It'sopen source(https://github.com/discourse/discourse)itself
> > - I believe it has ways of getting content as JSON and/or RSS, so I'd
> hardly say "can be adapted into other forms" is an exclusive feature of
> email.
> >
> > And, Discourse providesfree hosting for community-friendly open-source
> projects(
> http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/).
> Istrongly suspect(
> https://twitter.com/jtbandes/status/705886542309363712)Swift would
> qualify for this.
> >
> >
> > There have been several people on this list arguing in favor of mailing
> lists — I encourage folks to go read the old thread for themselves.
> >
> > It's worth noting there are also plenty of voices that don't get heard
> on this list, because people just don't like using mailing lists. One
> example:
> https://twitter.com/pilky/status/755105431555608580___
> > 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] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Chris Lattner via swift-evolution]

On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution 
 wrote:
> I wrote this a few months ago, but we weren't accepting additive proposals. 
> Now we're explicitly looking for something like this:
> 
> Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory 
> ownership model to Swift is highly desired by systems programmers and folks 
> who want predictable and deterministic performance (for example, in real time 
> audio processing code).  More pertinent to the goals of Swift 4, this feature 
> is important because it fundamentally shapes the ABI.  It informs code 
> generation for “inout", how low-level “addressors” work in the ABI, impacts 
> the Swift runtime, and will have a significant impact on the type system and 
> name mangling. 

Memory ownership is about something slightly different than this.  In the 
context of Swift, the model we’re looking for is:

- You can completely ignore memory ownership features of the language, and get 
very far into development with Swift.  This is in stark contrast with Rust and 
Cyclone, which require you to grapple with it up front.  This means that in the 
Swift context, this will be more of a “power user” feature, instead of 
essential part of the model.

- You can choose to use the memory ownership features by adding extra 
annotations, giving better performance and control over ARC.  Right now we have 
very limited options for avoiding ARC overhead in critical loops, largely 
forcing you to drop down to unsafe constructs.  We’d prefer the model to be 
“you can add more annotations to your code to get better performance, allowing 
the compiler statically verify correctness instead of dynamically”.

- Memory ownership control is an extremely non-trivial feature, which will 
probably drive us to add first class move semantics and region types to the 
language.  This will also call for significant standard library extensions.  It 
will pay for this complexity by making it easy to ignore the complexity if you 
don’t want it, and by the fact that the standard library and other stuff can go 
much faster.

- As a Stage 2 feature, I can imagine an opt-in mode that “forces” the use of 
these features, for code that wants to guarantee deterministic performance.  
This is what enables the use of swift in realtime audio applications, for 
example.

While some initial brainstorming and scoping has been done in this area, we’re 
far from having a concrete design.  We have a few folks who are experts at Rust 
that are helping contribute ideas and experience to this though.  

If you have more specific questions, feel free to ask about it.

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

Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Félix Cloutier via swift-evolution]

Seems to me that we can find similar information just from walking over a 
class's fields to build an ownership graph, and cause warnings/errors when you 
find a strong cycle.

How do you deal with type erasure?

> protocol Foo {}
> class A {
>   var foo: Foo
> }
> class B: Foo {
>   var a: A
> }
> // A and B can have a cycle through the Foo protocol

Also, how do you encode that your example's "addCallback" closure parameter 
can't have a strong reference to `self`?

Félix

> Le 29 juil. 2016 à 18:42:11, Andrew Bennett via swift-evolution 
>  a écrit :
> 
> I'd like an opt-in way to verify and prevent unintentional strong references 
> in Swift.
> 
> This can be used to verify ownership structures, and ultimately avoid retain 
> cycles.
> 
> Read a draft proposal here:
> https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/-explicit-ownership-type-attribute.md
>  
> 
> 
> TL;DR:
> 
> If you have any questions please read the proposal before asking here.
> 
> It's an opt-in attribute that defines a whitelist of types something can own. 
> For example:
> 
> @owns(TypeA, TypeB) struct TypeC { ... }
> 
> I wrote this a few months ago, but we weren't accepting additive proposals. 
> Now we're explicitly looking for something like this:
> 
> Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory 
> ownership model to Swift is highly desired by systems programmers and folks 
> who want predictable and deterministic performance (for example, in real time 
> audio processing code).  More pertinent to the goals of Swift 4, this feature 
> is important because it fundamentally shapes the ABI.  It informs code 
> generation for “inout", how low-level “addressors” work in the ABI, impacts 
> the Swift runtime, and will have a significant impact on the type system and 
> name mangling. 
> 
>  - Chris 
> 
> 
> 
> 
> Here's a link to the version of the proposal 
> 
>  when I sent this email.
> ___
> 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] [Swift 4] Organizing source stability

[Chris Lattner via swift-evolution]

> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch  wrote:
> 
> Here are a few thoughts:
> -swift=4
> -swift-version=4

-swift-version seems like the best option to me, but Jordan will have a strong 
opinion.  I think he’s crazy busy with Swift 3 work until late next week.

-Chris


> -language-version=4
> a top-of-file "shebang"-style comment indicating the version, something like 
> //#swift(4), mirroring the "#if swift" syntax
> 
> On Fri, Jul 29, 2016 at 5:27 PM, Chris Lattner  > wrote:
> 
>> On Jul 29, 2016, at 5:20 PM, Jacob Bandes-Storch via swift-evolution 
>> > wrote:
>> 
>> Chris writes:
>> - Source stability features: These should be relatively small, but 
>> important.  For example, we need a “-std=swift3” sort of compiler flag.  We 
>> may also add a way to conditionally enable larger efforts that are under 
>> development but not yet stable - in order to make it easier to experiment 
>> with them.
>> 
>> 
>> I am curious whether the team has thoughts on how to organize the compiler 
>> codebase in such a way that new features can be added, and possibly 
>> source-breaking changes made, while still keeping the old functionality 
>> around.
>> 
>> Are any obvious areas that will need refactoring to make this feasible? 
>> (Perhaps they could be turned into StarterBugs.)
> 
> I think this would be a great thing to do.  We need a few things:
> 
> - The actual compiler flag.  It is worth bikeshedding how it is spelled. 
> “-std=“ is good inspiration, but clearly the wrong specific name.
> 
> - The implementation should be straight forward: the flag should get plumbed 
> through to a field in swift::LangOptions.  Code that diverges can then check 
> it.
> 
> - Handling divergence in the standard library is another big issue.  We have 
> some ideas here, but it depends on having the compiler work done anyway to 
> hook into.
> 
>> How many versions back would the compiler be expected to support? Should the 
>> Swift 5 compiler still support Swift 3 code?
> 
> To be determined.  Swift 4 should definitely support Swift 3, but Swift 5 
> perhaps not.  We can decide that when Swift 4 is winding down.
> 
> -Chris
> 

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

Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Andrew Bennett via swift-evolution]

Interesting, I'm not familiar with the history of the feature in Rust. Are
you able to provide more details on what went wrong in practice?

This proposal may be different, this is not attempting to do it without GC.
What I'm suggesting still uses ARC (assuming you were counting ARC as GC).
It does provide the compiler many opportunities to optimise ARC though.

I really like what Rust ended up with, but I'm concerned that it's very
complicated, and I want to explore alternatives. From
https://doc.rust-lang.org/book/ownership.html:

However, this system does have a certain cost: learning curve. Many new
> users to Rust experience something we like to call ‘fighting with the
> borrow checker’.




On Sat, Jul 30, 2016 at 1:22 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

> Rust attempted this sort of type-directed cycle prevention early in its
> development, when it was attempting to provide language-supported shared
> references without GC, and it didn't work out well for them in practice.
>
> -Joe
>
> > On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I'd like an opt-in way to verify and prevent unintentional strong
> references in Swift.
> >
> > This can be used to verify ownership structures, and ultimately avoid
> retain cycles.
> >
> > Read a draft proposal here:
> >
> https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/-explicit-ownership-type-attribute.md
> >
> > TL;DR:
> >
> > If you have any questions please read the proposal before asking here.
> >
> > It's an opt-in attribute that defines a whitelist of types something can
> own. For example:
> >
> > @owns(TypeA, TypeB) struct TypeC { ... }
> >
> > I wrote this a few months ago, but we weren't accepting additive
> proposals. Now we're explicitly looking for something like this:
> >
> > Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory
> ownership model to Swift is highly desired by systems programmers and folks
> who want predictable and deterministic performance (for example, in real
> time audio processing code).  More pertinent to the goals of Swift 4, this
> feature is important because it fundamentally shapes the ABI.  It informs
> code generation for “inout", how low-level “addressors” work in the ABI,
> impacts the Swift runtime, and will have a significant impact on the type
> system and name mangling.
> >
> > - Chris
> >
> > 
> >
> > Here's a link to the version of the proposal when I sent this email.
> > ___
> > 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] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Joe Groff via swift-evolution]

Rust attempted this sort of type-directed cycle prevention early in its 
development, when it was attempting to provide language-supported shared 
references without GC, and it didn't work out well for them in practice.

-Joe

> On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution 
>  wrote:
> 
> I'd like an opt-in way to verify and prevent unintentional strong references 
> in Swift.
> 
> This can be used to verify ownership structures, and ultimately avoid retain 
> cycles.
> 
> Read a draft proposal here:
> https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/-explicit-ownership-type-attribute.md
> 
> TL;DR:
> 
> If you have any questions please read the proposal before asking here.
> 
> It's an opt-in attribute that defines a whitelist of types something can own. 
> For example:
> 
> @owns(TypeA, TypeB) struct TypeC { ... }
> 
> I wrote this a few months ago, but we weren't accepting additive proposals. 
> Now we're explicitly looking for something like this:
> 
> Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory 
> ownership model to Swift is highly desired by systems programmers and folks 
> who want predictable and deterministic performance (for example, in real time 
> audio processing code).  More pertinent to the goals of Swift 4, this feature 
> is important because it fundamentally shapes the ABI.  It informs code 
> generation for “inout", how low-level “addressors” work in the ABI, impacts 
> the Swift runtime, and will have a significant impact on the type system and 
> name mangling. 
> 
> - Chris
> 
> 
> 
> Here's a link to the version of the proposal when I sent this email.
> ___
> 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] [Swift4] Mailing list vs. Forum

[Tim Vermeulen via swift-evolution]

+1. Hirundo makes this format bearable, but it is still far from ideal. I see 
many advantages for using Discourse:

- It has actual syntax highlighting.
- It’s easier to moderate.
- It supports real-time updates.
- It’s easier to follow the flow of a conversation.
- It has better search.

I don’t doubt more people will take part in the Swift evolution process if we 
switch to Discourse.

> Branching...
> 
> On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via 
> swift-evolutionwrote:
> > On Jul 29, 2016, at 5:14 PM, Brandon 
> > Knopewrote:
> > >
> > >Chris, has the core team discussed opening up a forum for discussing 
> > >proposal implementations.
> > >
> > >Some of us aren't as skilled as the core team or other contributors but 
> > >would like to learn. A forum is a much easier place for us to post for 
> > >code help and to help others with their questions. I think this could help 
> > >get more involved as it would be a more comfortable format for them. Think 
> > >of how there are Apple Developer forums and not mailing lists for iOS 
> > >betas etc.
> > >
> > >I am not saying moving swift-evo to forums *yet* but I believe a lot of 
> > >the newer programmers are more comfortable with a forum format, especially 
> > >when it comes to help and discussing code.
> > >
> > >Forums for contributors would:
> > >- be more familiar for a lot of the newer and not as experienced developers
> > >- be easier to search
> > >- be easier to moderate (not really a problem yet)
> > 
> > Hi Brandon,
> > 
> > Moving from email to a forum system has come up before, but they have some 
> > disadvantages.One of major wins of email is that it is pervasive and can be 
> > adapted into other forms.For example, if you haven’t seen it yet, check out:
> > https://stylemac.com/hirundo/
> > 
> > -Chris
> > 
> We've discussed forums on swift-evolution before. Maybe it's time for another 
> go, with Swift 3 winding down.
> 
> For context, prior discussions are on this 
> thread:https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
> 
> (-1 for mailman: it's hard for me to even properly find to all the prior 
> discussion about mailing lists, because of how mailman's archive works...)
> 
> 
> News in the last few days is that Gmane is at least temporarily 
> disappearing:https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
> 
> 
> I'd just like to vote once again 
> forDiscourse(http://www.discourse.org/faq/#what):-Excellent web 
> interface(https://meta.discourse.org/), from the people who brought you Stack 
> Overflow(built-in search, etc.)
> - Read via email if that's your thing: it has "mailing list mode" which 
> includes 1-email-per-post, if that's your cup of tea
> -Reply via 
> email(https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099)if 
> that's your thing
> - It'sopen source(https://github.com/discourse/discourse)itself
> - I believe it has ways of getting content as JSON and/or RSS, so I'd hardly 
> say "can be adapted into other forms" is an exclusive feature of email.
> 
> And, Discourse providesfree hosting for community-friendly open-source 
> projects(http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/).
>  Istrongly 
> suspect(https://twitter.com/jtbandes/status/705886542309363712)Swift would 
> qualify for this.
> 
> 
> There have been several people on this list arguing in favor of mailing lists 
> — I encourage folks to go read the old thread for themselves.
> 
> It's worth noting there are also plenty of voices that don't get heard on 
> this list, because people just don't like using mailing lists. One 
> example:https://twitter.com/pilky/status/755105431555608580___
> 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] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Andrew Bennett via swift-evolution]

I'd like an *opt-in* way to verify and prevent *unintentional strong
references* in Swift.

This can be used to verify ownership structures, and ultimately avoid
retain cycles.

Read a draft proposal here:
https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/-explicit-ownership-type-attribute.md

TL;DR:

If you have any questions please read the proposal before asking here.

It's an opt-in attribute that defines a whitelist of types something can
own. For example:


@owns(TypeA, TypeB) struct TypeC { ... }


I wrote this a few months ago, but we weren't accepting additive proposals.
Now we're explicitly looking for something like this:

Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory
> ownership model to Swift is highly desired by systems programmers and folks
> who want predictable and deterministic performance (for example, in real
> time audio processing code). More pertinent to the goals of Swift 4, this
> feature is important because it fundamentally shapes the ABI. It informs
> code generation for “inout", how low-level “addressors” work in the ABI,
> impacts the Swift runtime, and will have a significant impact on the type
> system and name mangling.


>  - Chris
> 




Here's a link to the version of the proposal

when
I sent this email.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Chris Lattner via swift-evolution]

> On Jul 29, 2016, at 6:14 PM, Daniel Duan  wrote:
> 
> 
>> On Jul 29, 2016, at 5:59 PM, Brandon Knope via swift-evolution 
>> > wrote:
>> 
>> Where can we learn what affects the ABI? (Google, yes, but is there a highly 
>> respected document or article?)
>> 
> 
> This is a really good question, if we expect lots of discussion on this list 
> relating to ABIs, some organized, introductory material would be really 
> helpful. I’d start with 
> https://github.com/apple/swift/blob/master/docs/ABI.rst 
> . 

Right.  In addition, it is basically “every public symbol exported by the 
standard library”.  This includes everything you get by running the ‘nm’ 
command on the standard library dylibs.  Each of those has to be right.

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

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Chris Lattner via swift-evolution]

On Jul 29, 2016, at 5:53 PM, Magnus Ahltorp  wrote:
>>> Is it appropriate to discuss high-level topics that are not one of the 
>>> topics on your list? Example: Decreasing the number of cases where unsafe 
>>> constructs have to be used.
>>> 
>>> If it is not, how do topics get on the list?
>> 
>> If a topic is related to source or ABI compatibility, it is fair game for 
>> discussion.  We don’t want to widen the doors beyond this, because that is 
>> already a huge set of very important topics.
> 
> I assume you mean for Swift 4 Stage 1?

Yes, I was referring to Stage 1, sorry for not being specific.

> I was more referring to the Stage 2 list of high-level topics. When/how will 
> it be appropriate to discuss what the topics should be? Before or after Stage 
> 1 is completed, or not at all?

Stage 2 discussions will start once the work for Stage 1 is well understood and 
the implementation work starts converging (but is not necessarily done).  My 
wild guess is sometime in the early spring next year.

> Also, "Our goal is to be better at string processing than Perl!" doesn't seem 
> to be very related to ABI stability, but it is listed under Stage 1.

Great point, let me clarify: I expect String to get a major design overhaul.  
For example, sizeof(String) is currently three words, but it should be one.  
Relatedly, the API exposed by it is known to need revisions.  All of that work 
clearly impacts the ABI, and so it is a key project for Stage 1.

There is also a lot of other work that will build on that Stage 1 work, but is 
appropriate for Stage 2.  I’m personally convinced that we don’t get to great 
string processing without regular expressions (as one example), but they are 
clearly out of scope for Stage 1.  That’s ok though: the design work for the 
Stage 1 string design can just assume that that will come in at some point, and 
make sure the ultimate design anticipates that.

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

[swift-evolution] [Swift4] Mailing list vs. Forum

[Jacob Bandes-Storch via swift-evolution]

Branching...

On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jul 29, 2016, at 5:14 PM, Brandon Knope  wrote:
> >
> > Chris, has the core team discussed opening up a forum for discussing
> proposal implementations.
> >
> > Some of us aren't as skilled as the core team or other contributors but
> would like to learn. A forum is a much easier place for us to post for code
> help and to help others with their questions. I think this could help get
> more involved as it would be a more comfortable format for them. Think of
> how there are Apple Developer forums and not mailing lists for iOS betas
> etc.
> >
> > I am not saying moving swift-evo to forums *yet* but I believe a lot of
> the newer programmers are more comfortable with a forum format, especially
> when it comes to help and discussing code.
> >
> > Forums for contributors would:
> > - be more familiar for a lot of the newer and not as experienced
> developers
> > - be easier to search
> > - be easier to moderate (not really a problem yet)
>
> Hi Brandon,
>
> Moving from email to a forum system has come up before, but they have some
> disadvantages.  One of major wins of email is that it is pervasive and can
> be adapted into other forms.  For example, if you haven’t seen it yet,
> check out:
> https://stylemac.com/hirundo/
>
> -Chris
>
>

We've discussed forums on swift-evolution before. Maybe it's time for
another go, with Swift 3 winding down.

For context, prior discussions are on this thread:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html

  (-1 for mailman: it's hard for me to even properly find & link to all the
prior discussion about mailing lists, because of how mailman's archive
works...)


News in the last few days is that Gmane is at least temporarily
disappearing:
https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502


I'd just like to vote once again for Discourse
:
- Excellent web interface , from the people
who brought you Stack Overflow  (built-in search, etc.)
- Read via email if that's your thing: it has "*mailing list mode*" which
includes 1-email-per-post, if that's your cup of tea
- Reply via email
 if
that's your thing
- It's open source  itself
- I believe it has ways of getting content as JSON and/or RSS, so I'd
hardly say "can be adapted into other forms" is an exclusive feature of
email.

And, Discourse provides free hosting for community-friendly open-source
projects
.
I strongly suspect 
Swift would qualify for this.


There have been several people on this list arguing in favor of mailing
lists — I encourage folks to go read the old thread for themselves.

It's worth noting there are also plenty of voices that don't get heard on
this list, because people just don't like using mailing lists. One example:
https://twitter.com/pilky/status/755105431555608580
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Brandon Knope via swift-evolution]

Thanks for this! This looks great!

Brandon

> On Jul 29, 2016, at 9:14 PM, Daniel Duan  wrote:
> 
> 
>> On Jul 29, 2016, at 5:59 PM, Brandon Knope via swift-evolution 
>>  wrote:
>> 
>> Where can we learn what affects the ABI? (Google, yes, but is there a highly 
>> respected document or article?)
>> 
> 
> This is a really good question, if we expect lots of discussion on this list 
> relating to ABIs, some organized, introductory material would be really 
> helpful. I’d start with 
> https://github.com/apple/swift/blob/master/docs/ABI.rst. 
> 
>> Unless it's just something I'm not really familiar with, it might be helpful 
>> to detail what kind of changes would affect the ABI. 
>> 
>> Brandon
>> 
>> On Jul 29, 2016, at 8:38 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>>> 
> On Jul 29, 2016, at 5:29 PM, Magnus Ahltorp  wrote:
> 
> 30 Jul 2016 02:17 Chris Lattner via swift-evolution 
>  wrote:
> 
> Moving into early Swift 4 planning and development, we have no desires 
> beyond what I listed in the big email.  There is no long laundry list, it 
> is a few specific (big!) topics.
> 
> We specifically do not want a surge of proposals.
 
 Is it appropriate to discuss high-level topics that are not one of the 
 topics on your list? Example: Decreasing the number of cases where unsafe 
 constructs have to be used.
 
 If it is not, how do topics get on the list?
>>> 
>>> If a topic is related to source or ABI compatibility, it is fair game for 
>>> discussion.  We don’t want to widen the doors beyond this, because that is 
>>> already a huge set of very important topics.
>>> 
>>> -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] [Swift4] Priorities and Sugar

[Daniel Duan via swift-evolution]

> On Jul 29, 2016, at 5:59 PM, Brandon Knope via swift-evolution 
>  wrote:
> 
> Where can we learn what affects the ABI? (Google, yes, but is there a highly 
> respected document or article?)
> 

This is a really good question, if we expect lots of discussion on this list 
relating to ABIs, some organized, introductory material would be really 
helpful. I’d start with https://github.com/apple/swift/blob/master/docs/ABI.rst 
. 

> Unless it's just something I'm not really familiar with, it might be helpful 
> to detail what kind of changes would affect the ABI. 
> 
> Brandon
> 
> On Jul 29, 2016, at 8:38 PM, Chris Lattner via swift-evolution 
> > wrote:
> 
>> 
>>> On Jul 29, 2016, at 5:29 PM, Magnus Ahltorp >> > wrote:
>>> 
 30 Jul 2016 02:17 Chris Lattner via swift-evolution 
 > wrote:
 
 Moving into early Swift 4 planning and development, we have no desires 
 beyond what I listed in the big email.  There is no long laundry list, it 
 is a few specific (big!) topics.
 
 We specifically do not want a surge of proposals.
>>> 
>>> Is it appropriate to discuss high-level topics that are not one of the 
>>> topics on your list? Example: Decreasing the number of cases where unsafe 
>>> constructs have to be used.
>>> 
>>> If it is not, how do topics get on the list?
>> 
>> If a topic is related to source or ABI compatibility, it is fair game for 
>> discussion.  We don’t want to widen the doors beyond this, because that is 
>> already a huge set of very important topics.
>> 
>> -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] [Swift 4] Organizing source stability

[Jacob Bandes-Storch via swift-evolution]

Here are a few thoughts:

   - -swift=4
   - -swift-version=4
   - -language-version=4
   - a top-of-file "shebang"-style comment indicating the version,
   something like //#swift(4), mirroring the "#if swift" syntax


On Fri, Jul 29, 2016 at 5:27 PM, Chris Lattner  wrote:

>
> On Jul 29, 2016, at 5:20 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Chris writes:
>
>> - *Source stability features: *These should be relatively small, but
>> important.  For example, we need a “-std=swift3” sort of compiler flag.  We
>> may also add a way to conditionally enable larger efforts that are under
>> development but not yet stable - in order to make it easier to experiment
>> with them.
>
>
>
> I am curious whether the team has thoughts on how to organize the compiler
> codebase in such a way that new features can be added, and possibly
> source-breaking changes made, while still keeping the old functionality
> around.
>
> Are any obvious areas that will need refactoring to make this feasible?
> (Perhaps they could be turned into StarterBugs.)
>
>
> I think this would be a great thing to do.  We need a few things:
>
> - The actual compiler flag.  It is worth bikeshedding how it is spelled.
> “-std=“ is good inspiration, but clearly the wrong specific name.
>
> - The implementation should be straight forward: the flag should get
> plumbed through to a field in swift::LangOptions.  Code that diverges can
> then check it.
>
> - Handling divergence in the standard library is another big issue.  We
> have some ideas here, but it depends on having the compiler work done
> anyway to hook into.
>
> How many versions back would the compiler be expected to support? Should
> the Swift 5 compiler still support Swift 3 code?
>
>
> To be determined.  Swift 4 should definitely support Swift 3, but Swift 5
> perhaps not.  We can decide that when Swift 4 is winding down.
>
> -Chris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Magnus Ahltorp via swift-evolution]

> 30 Jul 2016 02:38 Chris Lattner  wrote:
> 
>> On Jul 29, 2016, at 5:29 PM, Magnus Ahltorp  wrote:
>> 
>>> 30 Jul 2016 02:17 Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> Moving into early Swift 4 planning and development, we have no desires 
>>> beyond what I listed in the big email.  There is no long laundry list, it 
>>> is a few specific (big!) topics.
>>> 
>>> We specifically do not want a surge of proposals.
>> 
>> Is it appropriate to discuss high-level topics that are not one of the 
>> topics on your list? Example: Decreasing the number of cases where unsafe 
>> constructs have to be used.
>> 
>> If it is not, how do topics get on the list?
> 
> If a topic is related to source or ABI compatibility, it is fair game for 
> discussion.  We don’t want to widen the doors beyond this, because that is 
> already a huge set of very important topics.

I assume you mean for Swift 4 Stage 1? I was more referring to the Stage 2 list 
of high-level topics. When/how will it be appropriate to discuss what the 
topics should be? Before or after Stage 1 is completed, or not at all?

Also, "Our goal is to be better at string processing than Perl!" doesn't seem 
to be very related to ABI stability, but it is listed under Stage 1.

/Magnus

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

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Chris Lattner via swift-evolution]

> On Jul 29, 2016, at 5:29 PM, Magnus Ahltorp  wrote:
> 
>> 30 Jul 2016 02:17 Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Moving into early Swift 4 planning and development, we have no desires 
>> beyond what I listed in the big email.  There is no long laundry list, it is 
>> a few specific (big!) topics.
>> 
>> We specifically do not want a surge of proposals.
> 
> Is it appropriate to discuss high-level topics that are not one of the topics 
> on your list? Example: Decreasing the number of cases where unsafe constructs 
> have to be used.
> 
> If it is not, how do topics get on the list?

If a topic is related to source or ABI compatibility, it is fair game for 
discussion.  We don’t want to widen the doors beyond this, because that is 
already a huge set of very important topics.

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

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Magnus Ahltorp via swift-evolution]

> 30 Jul 2016 02:17 Chris Lattner via swift-evolution 
>  wrote:
> 
> Moving into early Swift 4 planning and development, we have no desires beyond 
> what I listed in the big email.  There is no long laundry list, it is a few 
> specific (big!) topics.
> 
> We specifically do not want a surge of proposals.

Is it appropriate to discuss high-level topics that are not one of the topics 
on your list? Example: Decreasing the number of cases where unsafe constructs 
have to be used.

If it is not, how do topics get on the list?

/Magnus

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

Re: [swift-evolution] [Swift 4] Organizing source stability

[Chris Lattner via swift-evolution]

> On Jul 29, 2016, at 5:20 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Chris writes:
> - Source stability features: These should be relatively small, but important. 
>  For example, we need a “-std=swift3” sort of compiler flag.  We may also add 
> a way to conditionally enable larger efforts that are under development but 
> not yet stable - in order to make it easier to experiment with them.
> 
> 
> I am curious whether the team has thoughts on how to organize the compiler 
> codebase in such a way that new features can be added, and possibly 
> source-breaking changes made, while still keeping the old functionality 
> around.
> 
> Are any obvious areas that will need refactoring to make this feasible? 
> (Perhaps they could be turned into StarterBugs.)

I think this would be a great thing to do.  We need a few things:

- The actual compiler flag.  It is worth bikeshedding how it is spelled. 
“-std=“ is good inspiration, but clearly the wrong specific name.

- The implementation should be straight forward: the flag should get plumbed 
through to a field in swift::LangOptions.  Code that diverges can then check it.

- Handling divergence in the standard library is another big issue.  We have 
some ideas here, but it depends on having the compiler work done anyway to hook 
into.

> How many versions back would the compiler be expected to support? Should the 
> Swift 5 compiler still support Swift 3 code?

To be determined.  Swift 4 should definitely support Swift 3, but Swift 5 
perhaps not.  We can decide that when Swift 4 is winding down.

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

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Chris Lattner via swift-evolution]

On Jul 29, 2016, at 5:14 PM, Brandon Knope  wrote:
> 
> Chris, has the core team discussed opening up a forum for discussing proposal 
> implementations. 
> 
> Some of us aren't as skilled as the core team or other contributors but would 
> like to learn. A forum is a much easier place for us to post for code help 
> and to help others with their questions. I think this could help get more 
> involved as it would be a more comfortable format for them. Think of how 
> there are Apple Developer forums and not mailing lists for iOS betas etc. 
> 
> I am not saying moving swift-evo to forums *yet* but I believe a lot of the 
> newer programmers are more comfortable with a forum format, especially when 
> it comes to help and discussing code. 
> 
> Forums for contributors would:
> - be more familiar for a lot of the newer and not as experienced developers 
> - be easier to search
> - be easier to moderate (not really a problem yet)

Hi Brandon,

Moving from email to a forum system has come up before, but they have some 
disadvantages.  One of major wins of email is that it is pervasive and can be 
adapted into other forms.  For example, if you haven’t seen it yet, check out:
https://stylemac.com/hirundo/

-Chris


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

[swift-evolution] [Swift 4] Organizing source stability

[Jacob Bandes-Storch via swift-evolution]

Chris writes:

> - *Source stability features: *These should be relatively small, but
> important.  For example, we need a “-std=swift3” sort of compiler flag.  We
> may also add a way to conditionally enable larger efforts that are under
> development but not yet stable - in order to make it easier to experiment
> with them.



I am curious whether the team has thoughts on how to organize the compiler
codebase in such a way that new features can be added, and possibly
source-breaking changes made, while still keeping the old functionality
around.

Are any obvious areas that will need refactoring to make this feasible?
(Perhaps they could be turned into StarterBugs.)

How many versions back would the compiler be expected to support? Should
the Swift 5 compiler still support Swift 3 code?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Chris Lattner via swift-evolution]

On Jul 29, 2016, at 5:05 PM, Erica Sadun  wrote:
>> I expect/hope each of the topics listed in the email to turn into active 
>> threads of discussion.  If you or others have questions about them, feel 
>> free to ask now.  That said, major design work on them probably won’t kick 
>> off in earnest until Swift 3 is closer to being out the door.
> 
> A single asynchronously updated document can host ideas that may not yet be 
> ready for the development timeline. I'm not saying they shouldn't also appear 
> in threads, but I'd like to see an Apple-sourced wishlist given equal status 
> with formal proposals. There is *so* much traffic on-list, and a lot gets 
> lost. I speak as someone who has a vested interest in keeping on top of 
> what's happening on-list.

Moving into early Swift 4 planning and development, we have no desires beyond 
what I listed in the big email.  There is no long laundry list, it is a few 
specific (big!) topics.

We specifically do not want a surge of proposals.


>>> * A way to submit pitches for early design review intervention on a regular 
>>> calendar, so pitches without legs get cut off early and mercifully, and 
>>> traffic is reduced.
>> 
>> I’m not sure what you mean by this.
> 
> Remember the design review meetings that reviewed proposals and gave 
> feedback? (e.g. 
> http://ericasadun.com/2016/03/16/behind-the-scenes-swift-core-team-design-discussion-315/)
>  It seems like a huge amount of effort, late in the process. It would be 
> great to step back to a less developed preliminary proposal (say 1-2 
> paragraphs), that gets thumbs up/down without so much investment of list and 
> team resources on a regular design review schedule. I'm thinking "early 
> intervention”.

Sure, this makes a lot of sense as proposals are coming together for the areas 
that are on topic.

>>> * Swift-academy outreach for those of us who can code but fall somewhere 
>>> between starter bugs and full contribution.
>> 
>> I’m also not sure what you mean by this, but it sounds interesting!
> 
> Ted's email 
> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025587.html)
>  highlighted the gap between designing ideas and writing code. Or as you 
> wrote, "Software scheduling (particularly with open source) continues to be 
> difficult-to-impossible to predict." Outreach (maybe through slack?) could 
> help guide almost-but-not-quite-there devs, specifically working on swift 
> coding.

Ah, this would be fantastic.  I’m not sure exactly what the right approach is, 
but if you haven’t seen it, Slava wrote some phenomenal blog posts about the 
inner workings of the Swift type system:
https://medium.com/@slavapestov/the-secret-life-of-types-in-swift-ff83c3c000a5#.utgtukjwf

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

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Brandon Knope via swift-evolution]

Chris, has the core team discussed opening up a forum for discussing proposal 
implementations. 

Some of us aren't as skilled as the core team or other contributors but would 
like to learn. A forum is a much easier place for us to post for code help and 
to help others with their questions. I think this could help get more involved 
as it would be a more comfortable format for them. Think of how there are Apple 
Developer forums and not mailing lists for iOS betas etc. 

I am not saying moving swift-evo to forums *yet* but I believe a lot of the 
newer programmers are more comfortable with a forum format, especially when it 
comes to help and discussing code. 

Forums for contributors would:
- be more familiar for a lot of the newer and not as experienced developers 
- be easier to search
- be easier to moderate (not really a problem yet)

My .02
Brandon 

> On Jul 29, 2016, at 7:43 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Jul 29, 2016, at 4:26 PM, Erica Sadun  wrote:
>> Things I'd like to see:
>> 
>> * On the Swift Evolution repository site, a wish list from core engineers, 
>> with a précis for each topic, a priority estimate, and contact information 
>> for the team (which can be none through "willing to mentor"). Using a 
>> central document is key. Placing requests on-list means they get lost within 
>> a day or two and cannot be updated in one place. 
> 
> I expect/hope each of the topics listed in the email to turn into active 
> threads of discussion.  If you or others have questions about them, feel free 
> to ask now.  That said, major design work on them probably won’t kick off in 
> earnest until Swift 3 is closer to being out the door.
> 
>> * At the same time, I'd like to see regular posted updates on-list 
>> (announcement, or evolution) about the bigger picture goals: for example, 
>> neglected items that need some contributor love
> 
> Makes sense.
> 
>> * A way to submit pitches for early design review intervention on a regular 
>> calendar, so pitches without legs get cut off early and mercifully, and 
>> traffic is reduced.
> 
> I’m not sure what you mean by this.
> 
>> * A deferred proposals folder where people can place low-priority (for 
>> example, "sugar") items, to clear them from their heads, from the pull 
>> queue. Add in some structure for discussion, whether on a separate swift.org 
>> pipermail list, on github, or on-list using a well-specified tag that can be 
>> filtered out for those who need more on-topic bandwidth.
> 
> The core team discussed this and specifically does not want to do this.  The 
> proposal template will change year over year, as will the goals for the 
> releases.  There are plenty of places to post speculative ideas (blogs, 
> personal github repos, etc).  Hosting them as an official part of the swift 
> project doesn’t seem productive unless they are blessed, filtered, or somehow 
> endorsed.
> 
>> * Swift-academy outreach for those of us who can code but fall somewhere 
>> between starter bugs and full contribution.
> 
> I’m also not sure what you mean by this, but it sounds interesting!
> 
> -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

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Erica Sadun via swift-evolution]

> On Jul 29, 2016, at 5:43 PM, Chris Lattner  wrote:
> 
> On Jul 29, 2016, at 4:26 PM, Erica Sadun  wrote:
>> Things I'd like to see:
>> 
>> * On the Swift Evolution repository site, a wish list from core engineers, 
>> with a précis for each topic, a priority estimate, and contact information 
>> for the team (which can be none through "willing to mentor"). Using a 
>> central document is key. Placing requests on-list means they get lost within 
>> a day or two and cannot be updated in one place. 
> 
> I expect/hope each of the topics listed in the email to turn into active 
> threads of discussion.  If you or others have questions about them, feel free 
> to ask now.  That said, major design work on them probably won’t kick off in 
> earnest until Swift 3 is closer to being out the door.

A single asynchronously updated document can host ideas that may not yet be 
ready for the development timeline. I'm not saying they shouldn't also appear 
in threads, but I'd like to see an Apple-sourced wishlist given equal status 
with formal proposals. There is *so* much traffic on-list, and a lot gets lost. 
I speak as someone who has a vested interest in keeping on top of what's 
happening on-list.

> 
>> * At the same time, I'd like to see regular posted updates on-list 
>> (announcement, or evolution) about the bigger picture goals: for example, 
>> neglected items that need some contributor love
> 
> Makes sense.
> 
>> * A way to submit pitches for early design review intervention on a regular 
>> calendar, so pitches without legs get cut off early and mercifully, and 
>> traffic is reduced.
> 
> I’m not sure what you mean by this.

Remember the design review meetings that reviewed proposals and gave feedback? 
(e.g. 
http://ericasadun.com/2016/03/16/behind-the-scenes-swift-core-team-design-discussion-315/)
 It seems like a huge amount of effort, late in the process. It would be great 
to step back to a less developed preliminary proposal (say 1-2 paragraphs), 
that gets thumbs up/down without so much investment of list and team resources 
on a regular design review schedule. I'm thinking "early intervention".

> 
>> * A deferred proposals folder where people can place low-priority (for 
>> example, "sugar") items, to clear them from their heads, from the pull 
>> queue. Add in some structure for discussion, whether on a separate swift.org 
>> pipermail list, on github, or on-list using a well-specified tag that can be 
>> filtered out for those who need more on-topic bandwidth.
> 
> The core team discussed this and specifically does not want to do this.  The 
> proposal template will change year over year, as will the goals for the 
> releases.  There are plenty of places to post speculative ideas (blogs, 
> personal github repos, etc).  Hosting them as an official part of the swift 
> project doesn’t seem productive unless they are blessed, filtered, or somehow 
> endorsed.

Understood.

> 
>> * Swift-academy outreach for those of us who can code but fall somewhere 
>> between starter bugs and full contribution.
> 
> I’m also not sure what you mean by this, but it sounds interesting!

Ted's email 
(https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025587.html)
 highlighted the gap between designing ideas and writing code. Or as you wrote, 
"Software scheduling (particularly with open source) continues to be 
difficult-to-impossible to predict." Outreach (maybe through slack?) could help 
guide almost-but-not-quite-there devs, specifically working on swift coding.

-- E

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

Re: [swift-evolution] [Swift4] Priorities and Sugar

[Chris Lattner via swift-evolution]

On Jul 29, 2016, at 4:26 PM, Erica Sadun  wrote:
> Things I'd like to see:
> 
> * On the Swift Evolution repository site, a wish list from core engineers, 
> with a précis for each topic, a priority estimate, and contact information 
> for the team (which can be none through "willing to mentor"). Using a central 
> document is key. Placing requests on-list means they get lost within a day or 
> two and cannot be updated in one place. 

I expect/hope each of the topics listed in the email to turn into active 
threads of discussion.  If you or others have questions about them, feel free 
to ask now.  That said, major design work on them probably won’t kick off in 
earnest until Swift 3 is closer to being out the door.

> * At the same time, I'd like to see regular posted updates on-list 
> (announcement, or evolution) about the bigger picture goals: for example, 
> neglected items that need some contributor love

Makes sense.

> * A way to submit pitches for early design review intervention on a regular 
> calendar, so pitches without legs get cut off early and mercifully, and 
> traffic is reduced.

I’m not sure what you mean by this.

> * A deferred proposals folder where people can place low-priority (for 
> example, "sugar") items, to clear them from their heads, from the pull queue. 
> Add in some structure for discussion, whether on a separate swift.org 
> pipermail list, on github, or on-list using a well-specified tag that can be 
> filtered out for those who need more on-topic bandwidth.

The core team discussed this and specifically does not want to do this.  The 
proposal template will change year over year, as will the goals for the 
releases.  There are plenty of places to post speculative ideas (blogs, 
personal github repos, etc).  Hosting them as an official part of the swift 
project doesn’t seem productive unless they are blessed, filtered, or somehow 
endorsed.

> * Swift-academy outreach for those of us who can code but fall somewhere 
> between starter bugs and full contribution.

I’m also not sure what you mean by this, but it sounds interesting!

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

[swift-evolution] [Swift4] Priorities and Sugar

[Erica Sadun via swift-evolution]

Things I'd like to see:

* On the Swift Evolution repository site, a wish list from core engineers, with 
a précis for each topic, a priority estimate, and contact information for the 
team (which can be none through "willing to mentor"). Using a central document 
is key. Placing requests on-list means they get lost within a day or two and 
cannot be updated in one place. 

* At the same time, I'd like to see regular posted updates on-list 
(announcement, or evolution) about the bigger picture goals: for example, 
neglected items that need some contributor love

* A way to submit pitches for early design review intervention on a regular 
calendar, so pitches without legs get cut off early and mercifully, and traffic 
is reduced.

* A deferred proposals folder where people can place low-priority (for example, 
"sugar") items, to clear them from their heads, from the pull queue. Add in 
some structure for discussion, whether on a separate swift.org pipermail list, 
on github, or on-list using a well-specified tag that can be filtered out for 
those who need more on-topic bandwidth.

* Swift-academy outreach for those of us who can code but fall somewhere 
between starter bugs and full contribution.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Looking back on Swift 3 and ahead to Swift 4

[Chris Lattner via swift-evolution]

Hello Everyone,

The Swift 3 release is nearing completion, so it is time to look back on the 
release, learn from what happened, and use it to shape what we (the Swift 
community) do in the year ahead.  Overall, Swift 3 is going to be an absolutely 
*amazing* release, and it is impressive how much got done.  Thank you to 
everyone who contributed to making it happen.  Instead of diving into a flurry 
of new proposals immediately, it is important to take stock of where we are, 
and look at the bigger picture.

Metapoint: this email is ridiculously long and covers multiple topics.  Instead 
of replying to it directly, it is best to start new threads on individual 
topics that you’d like to discuss.  Just tag them with “[Swift 4]” in the 
subject line.


### Swift 3 Retrospective ###

Every year of Swift’s development has been completely different from the 
previous one, and I expect Swift 4 to continue this trend.  With a goal of 
learning and improving year over year, here are some observations & 
retrospective about Swift 3:

 - Open source is pretty great.  It has been incredible to see such a vibrant 
community working so well together, and to see you come together practically 
overnight.  It is really fantastic to work with such a talented and 
enthusiastic group of people!

 - Open source also brings challenges.  I think it is fair to say that "open 
design" is slower and less predictable than "closed design”.  However, the end 
result is significantly better, and therefore the tradeoff is worth it.  A big 
“Thank you!” goes out to everyone who helps improve Swift through the evolution 
process.

 - Software scheduling (particularly with open source) continues to be 
difficult-to-impossible to predict.  We set off on Swift 3 with a lofty set of 
goals that had to be trimmed back later.  It is *good* to have high goals, but 
we need to do a better job of communicating that “goals” are not “promises” so 
that people don’t feel misled.

 - The community benefits from keeping focus on a limited number of topics, 
because if there is too much going on, no one can follow and keep track of it 
all.  It is important for the core team to be involved in key discussions up 
front.  In the Swift 3 cycle, it was problematic that many folks had no time to 
follow the threads until after the review period completed.

 - Having clear goals is liberating.  In the December/January timeframe in 
particular, we loosely scoped what sorts of ideas would fit into Swift 3, and 
embarked on several projects that ended up being far beyond what we could 
handle.  Later in the release, we had very specific goals (for example, “no 
additive proposals”) which made it much easier for everyone to focus on what 
was important.

 - It is impossible to make everyone happy, particularly when discussing which 
features to pick up and prioritize - because that implicitly de-prioritizes 
something else. This is inevitable though, because there is no way that all the 
interesting work will fit into a one-year release cycle.  Fortunately, there 
will “always be another release,” and each new release will have its share of 
big improvements.

With that as context, let’s look ahead!


### Swift Release Plan ###

Over the next year, the core team expects to ship two major releases of Swift: 
Swift 3.x in Spring 2017 and Swift 4 in Fall 2017.   In addition to the major 
releases, we will surely ship some minor releases (e.g. Swift 3.0.1) to fix 
bugs or service the needs of the corelibs or other swift.org 
 projects.


### Swift 4 Release Cycle Planning Approach ###

>From our experience with Swift 3, we know we need to pick and choose what 
>we’re going to tackle.  For Swift 4, the primary goals are to deliver on the 
>promise of source stability from 3.0 on, and to provide ABI stability for the 
>standard library.  As such, the core team has decided to take a two-stage 
>approach to the next year:

Stage #1: Focus on the essentials required for Source and ABI stability, and 
keep reasonably strict focus on only that work.  This means that any 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. For example, generics features like conditional conformance 

 is an additive feature, but since it is expected to reshape much of the 
standard library it would be part of Stage 1.  On the other hand, language 
support for regular expressions would not affect existing ABI nor cause major 
changes to existing standard library features, so it would not fit in Stage 1.

The work entailed by Stage 1 is non-trivial (explored in somewhat more detail 
below), and will probably keep us busy until the Spring.

Stage #2: As the design and implementation work on the Stage 1 features is 
cresting, we’ll scope and plan a few other 

[swift-evolution] [Review] SE-0135: Package Manager Support for Differentiating Packages by Swift version

[Daniel Dunbar via swift-evolution]

Hello Swift community,

The review of "SE-0135: Package Manager Support for Differentiating Packages by 
Swift version" begins now and runs through August 3rd. The proposal is 
available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-build-dev and swift-evolution mailing lists at

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

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

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and contribute to 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,

- Daniel Dunbar
Review Manager

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

Re: [swift-evolution] [Meta] What does the backlog mean to the process?

[David Sweeris via swift-evolution]

Oh gosh yes. I’ve been working on a bug off and on for a while, and half the 
reason it isn’t fixed yet is that I can’t wrap my head around how modern 
compilers work (which isn’t really saying much since this is the only compiler 
I’ve looked at).

> On Jul 29, 2016, at 11:32 AM, Brandon Knope via swift-evolution 
>  wrote:
> 
> This too. I think some better documentation for all of us could pay great 
> dividends. Or a primer of some sort. A weekly series diving into the common 
> parts of LLVM?
> 
> Brandon
> 
>> On Jul 29, 2016, at 12:30 PM, Karl > > wrote:
>> 
>> 
>>> On 29 Jul 2016, at 18:01, Brandon Knope via swift-evolution 
>>> > wrote:
>>> 
>>> I think this just shows how familiar many of us are with this process.
>>> 
>>> It’s fun and challenging coming up with the great ideas…but someone has to 
>>> implement it. It may not be fun…and it may be very time consuming.
>>> 
>>> I think a lot of us just expected the core team to implement these all…but 
>>> they really need help from the community to save them time and sanity with 
>>> trying to get all of this done.
>>> 
>>> 
>>> To me this means I need to familiarize myself with the swift code base even 
>>> more. I need to understand all the GitHub processes to get a change 
>>> implemented and submitted.
>>> 
>>> I really hope at some point someone can make a primer of the process they 
>>> went through to implement one of these proposals from start to finish. I 
>>> think this could be illuminating for many on this list.
>>> 
>>> ALSO: I think this is where a forum can help greatly: some of us need a way 
>>> to discuss our implementations and ask for help while we are working on one 
>>> of these proposals. Mailing lists make it very hard to have a general 
>>> discussion where we talk code and ask for help in get detail. It is also 
>>> much easier for others to browse to learn from that conversation.
>>> 
>>> In short: the swift-evolution process works…but some of us in the community 
>>> need to step up and help a little more other than just proposing things. I 
>>> think the swift team could make this easier with some detailed guides and 
>>> documentation and a forum for better discussions when trying to implement 
>>> these things…but I know they are insanely busy. I do think some time 
>>> investment in this area will pay off in the future…and quickly.
>>> 
>>> Brandon
>>> 
 On Jul 29, 2016, at 11:15 AM, Félix Cloutier via swift-evolution 
 > wrote:
 
 Hello all,
 
 With the Swift 3 deadline passed, according to the Swift Evolution 
 progress page, about 20% of the proposals that the community voted in 
 won't make it for Swift 3. Beyond the implications for the language 
 itself, what does that mean for the swift-evolution process?
 
 Félix
 
 ___
 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 
>>> 
>> 
>> The thing that’s stopping me contributing to the compiler itself is that it 
>> uses LLVM types and functions, and I don’t know them. The Swift compiler 
>> itself looks very clean and approachable.
>> 
>> And then, when you try to look up any of those LLVM functions, you get 
>> Doxygen, which isn’t really great. It just puts me off really getting to 
>> grips with LLVM’s conventions. Maybe one day when I have more time.
>> 
>> Unless somebody knows of some better documentation?
>> 
>> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Meta] What does the backlog mean to the process?

[Chris Lattner via swift-evolution]

> On Jul 29, 2016, at 8:48 AM, Daniel Vollmer via swift-evolution 
>  wrote:
> 
> Hi,
> 
>> On 29 Jul 2016, at 17:15, Félix Cloutier via swift-evolution 
>>  wrote:
>> 
>> Hello all,
>> 
>> With the Swift 3 deadline passed, according to the Swift Evolution progress 
>> page, about 20% of the proposals that the community voted in won't make it 
>> for Swift 3.

Just FWIW, several of the big currently unimplemented proposals are about to 
land today.  Your meta question still stands.

>> Beyond the implications for the language itself, what does that mean for the 
>> swift-evolution process?
> 
> Getting a proposal approved doesn’t necessarily mean someone will feel 
> obliged to implement it. Sometimes people propose a feature they’d like to 
> see, but do not have the knowledge to implement it. Sometimes the scope of a 
> feature is only evident after the review (and sometimes it’s not even evident 
> then — some gotchas only pop up once you try to implement “for real”).
> 
> I think we need to keep an eye on the backlog (both proposals *and* 
> implementation of previously approved ones), but if no-one’s willing to 
> implement them, I don’t think we can force anyone…

Exactly right.  This is an inherent part of Swift being an open source project.

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

[swift-evolution] Improved value and move semantics

[Bram Beernink via swift-evolution]

Hi all,

Would it be possible to improve value and move semantics (performance) in 
Swift? Consider this possible Swift code in a future release of Swift:

let array1 : [String] = ["Val1", "Val2"]
let array2 = array1.appended(“Val3”) // Copy of array1 with “Val3” appended. 
array1 is left untouched. Nothing special yet.
var array3 : [String] = [“Var1”]
array3 = array3.appended(“Var2”) // array3 can just be mutated to add “Var2”, 
while maintaining value semantics. Swift can recognize that array3’s old state 
is not referenced anywhere in the future.
let array4 = array2.appended("Val4").appended("Val5") // Copy of array2 with 
both "Val4" and "Val5" appended. In this case, “Val5” can also be appended by 
mutation.

This example illustrates improved value semantics with a string array. But it 
would be good if this can work with any struct. Maybe via something similar to 
isUniquelyReferenced? Or maybe you can even have a “smart” self in a 
non-mutating func in a struct:
struct Array {
func appended(e : T) -> Array { // No mutating keyword!
self.append(e) // self would either be mutated here if the current ref 
count of self is 1, and self is either a “rvalue” or self’s old state cannot 
possibly referenced anymore after this call. Otherwise, "self” would actually 
be a copy of self.
return self
}
}

I think that with such support it is encouraged to make more use of (immutable) 
value types while not sacrificing performance. Less mutations lead to more 
understandable code, which leads to less bugs.

In any case, keep up the fast improvements to Swift.

Best regards,
Bram.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Meta] What does the backlog mean to the process?

[Mark Lacey via swift-evolution]

> On Jul 29, 2016, at 09:30, Karl via swift-evolution 
>  wrote:
> 
> 
>> On 29 Jul 2016, at 18:01, Brandon Knope via swift-evolution 
>>  wrote:
>> 
>> I think this just shows how familiar many of us are with this process.
>> 
>> It’s fun and challenging coming up with the great ideas…but someone has to 
>> implement it. It may not be fun…and it may be very time consuming.
>> 
>> I think a lot of us just expected the core team to implement these all…but 
>> they really need help from the community to save them time and sanity with 
>> trying to get all of this done.
>> 
>> 
>> To me this means I need to familiarize myself with the swift code base even 
>> more. I need to understand all the GitHub processes to get a change 
>> implemented and submitted.
>> 
>> I really hope at some point someone can make a primer of the process they 
>> went through to implement one of these proposals from start to finish. I 
>> think this could be illuminating for many on this list.
>> 
>> ALSO: I think this is where a forum can help greatly: some of us need a way 
>> to discuss our implementations and ask for help while we are working on one 
>> of these proposals. Mailing lists make it very hard to have a general 
>> discussion where we talk code and ask for help in get detail. It is also 
>> much easier for others to browse to learn from that conversation.
>> 
>> In short: the swift-evolution process works…but some of us in the community 
>> need to step up and help a little more other than just proposing things. I 
>> think the swift team could make this easier with some detailed guides and 
>> documentation and a forum for better discussions when trying to implement 
>> these things…but I know they are insanely busy. I do think some time 
>> investment in this area will pay off in the future…and quickly.
>> 
>> Brandon
>> 
>>> On Jul 29, 2016, at 11:15 AM, Félix Cloutier via swift-evolution 
>>>  wrote:
>>> 
>>> Hello all,
>>> 
>>> With the Swift 3 deadline passed, according to the Swift Evolution progress 
>>> page, about 20% of the proposals that the community voted in won't make it 
>>> for Swift 3. Beyond the implications for the language itself, what does 
>>> that mean for the swift-evolution process?
>>> 
>>> Félix
>>> 
>>> ___
>>> 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
> 
> The thing that’s stopping me contributing to the compiler itself is that it 
> uses LLVM types and functions, and I don’t know them. The Swift compiler 
> itself looks very clean and approachable.
> 
> And then, when you try to look up any of those LLVM functions, you get 
> Doxygen, which isn’t really great. It just puts me off really getting to 
> grips with LLVM’s conventions. Maybe one day when I have more time.
> 
> Unless somebody knows of some better documentation?

This is a good reference if you want to start getting to know things like 
DenseMap, SmallVector, etc.: 
http://llvm.org/docs/ProgrammersManual.html#picking-the-right-data-structure-for-a-task

The other thing I would suggest is just taking a look at the headers and when 
needed the source. Most of the ADTs closely resemble STL counterparts in API 
and are easy to get up-to-speed with. 

I have never taken a serious look at the Doxygen documentation as I personally 
don't find it useful with the source available. 

Mark

> 
> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Meta] What does the backlog mean to the process?

[Brandon Knope via swift-evolution]

This too. I think some better documentation for all of us could pay great 
dividends. Or a primer of some sort. A weekly series diving into the common 
parts of LLVM?

Brandon

> On Jul 29, 2016, at 12:30 PM, Karl  wrote:
> 
> 
>> On 29 Jul 2016, at 18:01, Brandon Knope via swift-evolution 
>> > wrote:
>> 
>> I think this just shows how familiar many of us are with this process.
>> 
>> It’s fun and challenging coming up with the great ideas…but someone has to 
>> implement it. It may not be fun…and it may be very time consuming.
>> 
>> I think a lot of us just expected the core team to implement these all…but 
>> they really need help from the community to save them time and sanity with 
>> trying to get all of this done.
>> 
>> 
>> To me this means I need to familiarize myself with the swift code base even 
>> more. I need to understand all the GitHub processes to get a change 
>> implemented and submitted.
>> 
>> I really hope at some point someone can make a primer of the process they 
>> went through to implement one of these proposals from start to finish. I 
>> think this could be illuminating for many on this list.
>> 
>> ALSO: I think this is where a forum can help greatly: some of us need a way 
>> to discuss our implementations and ask for help while we are working on one 
>> of these proposals. Mailing lists make it very hard to have a general 
>> discussion where we talk code and ask for help in get detail. It is also 
>> much easier for others to browse to learn from that conversation.
>> 
>> In short: the swift-evolution process works…but some of us in the community 
>> need to step up and help a little more other than just proposing things. I 
>> think the swift team could make this easier with some detailed guides and 
>> documentation and a forum for better discussions when trying to implement 
>> these things…but I know they are insanely busy. I do think some time 
>> investment in this area will pay off in the future…and quickly.
>> 
>> Brandon
>> 
>>> On Jul 29, 2016, at 11:15 AM, Félix Cloutier via swift-evolution 
>>> > wrote:
>>> 
>>> Hello all,
>>> 
>>> With the Swift 3 deadline passed, according to the Swift Evolution progress 
>>> page, about 20% of the proposals that the community voted in won't make it 
>>> for Swift 3. Beyond the implications for the language itself, what does 
>>> that mean for the swift-evolution process?
>>> 
>>> Félix
>>> 
>>> ___
>>> 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
> 
> The thing that’s stopping me contributing to the compiler itself is that it 
> uses LLVM types and functions, and I don’t know them. The Swift compiler 
> itself looks very clean and approachable.
> 
> And then, when you try to look up any of those LLVM functions, you get 
> Doxygen, which isn’t really great. It just puts me off really getting to 
> grips with LLVM’s conventions. Maybe one day when I have more time.
> 
> Unless somebody knows of some better documentation?
> 
> Karl

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

Re: [swift-evolution] [Meta] What does the backlog mean to the process?

[Karl via swift-evolution]

> On 29 Jul 2016, at 18:01, Brandon Knope via swift-evolution 
>  wrote:
> 
> I think this just shows how familiar many of us are with this process.
> 
> It’s fun and challenging coming up with the great ideas…but someone has to 
> implement it. It may not be fun…and it may be very time consuming.
> 
> I think a lot of us just expected the core team to implement these all…but 
> they really need help from the community to save them time and sanity with 
> trying to get all of this done.
> 
> 
> To me this means I need to familiarize myself with the swift code base even 
> more. I need to understand all the GitHub processes to get a change 
> implemented and submitted.
> 
> I really hope at some point someone can make a primer of the process they 
> went through to implement one of these proposals from start to finish. I 
> think this could be illuminating for many on this list.
> 
> ALSO: I think this is where a forum can help greatly: some of us need a way 
> to discuss our implementations and ask for help while we are working on one 
> of these proposals. Mailing lists make it very hard to have a general 
> discussion where we talk code and ask for help in get detail. It is also much 
> easier for others to browse to learn from that conversation.
> 
> In short: the swift-evolution process works…but some of us in the community 
> need to step up and help a little more other than just proposing things. I 
> think the swift team could make this easier with some detailed guides and 
> documentation and a forum for better discussions when trying to implement 
> these things…but I know they are insanely busy. I do think some time 
> investment in this area will pay off in the future…and quickly.
> 
> Brandon
> 
>> On Jul 29, 2016, at 11:15 AM, Félix Cloutier via swift-evolution 
>> > wrote:
>> 
>> Hello all,
>> 
>> With the Swift 3 deadline passed, according to the Swift Evolution progress 
>> page, about 20% of the proposals that the community voted in won't make it 
>> for Swift 3. Beyond the implications for the language itself, what does that 
>> mean for the swift-evolution process?
>> 
>> Félix
>> 
>> ___
>> 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

The thing that’s stopping me contributing to the compiler itself is that it 
uses LLVM types and functions, and I don’t know them. The Swift compiler itself 
looks very clean and approachable.

And then, when you try to look up any of those LLVM functions, you get Doxygen, 
which isn’t really great. It just puts me off really getting to grips with 
LLVM’s conventions. Maybe one day when I have more time.

Unless somebody knows of some better documentation?

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

Re: [swift-evolution] [Meta] What does the backlog mean to the process?

[Brandon Knope via swift-evolution]

I think this just shows how familiar many of us are with this process.

It’s fun and challenging coming up with the great ideas…but someone has to 
implement it. It may not be fun…and it may be very time consuming.

I think a lot of us just expected the core team to implement these all…but they 
really need help from the community to save them time and sanity with trying to 
get all of this done.


To me this means I need to familiarize myself with the swift code base even 
more. I need to understand all the GitHub processes to get a change implemented 
and submitted.

I really hope at some point someone can make a primer of the process they went 
through to implement one of these proposals from start to finish. I think this 
could be illuminating for many on this list.

ALSO: I think this is where a forum can help greatly: some of us need a way to 
discuss our implementations and ask for help while we are working on one of 
these proposals. Mailing lists make it very hard to have a general discussion 
where we talk code and ask for help in get detail. It is also much easier for 
others to browse to learn from that conversation.

In short: the swift-evolution process works…but some of us in the community 
need to step up and help a little more other than just proposing things. I 
think the swift team could make this easier with some detailed guides and 
documentation and a forum for better discussions when trying to implement these 
things…but I know they are insanely busy. I do think some time investment in 
this area will pay off in the future…and quickly.

Brandon

> On Jul 29, 2016, at 11:15 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> Hello all,
> 
> With the Swift 3 deadline passed, according to the Swift Evolution progress 
> page, about 20% of the proposals that the community voted in won't make it 
> for Swift 3. Beyond the implications for the language itself, what does that 
> mean for the swift-evolution process?
> 
> Félix
> 
> ___
> 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] [Meta] What does the backlog mean to the process?

[Daniel Vollmer via swift-evolution]

Hi,

> On 29 Jul 2016, at 17:15, Félix Cloutier via swift-evolution 
>  wrote:
> 
> Hello all,
> 
> With the Swift 3 deadline passed, according to the Swift Evolution progress 
> page, about 20% of the proposals that the community voted in won't make it 
> for Swift 3. Beyond the implications for the language itself, what does that 
> mean for the swift-evolution process?

Getting a proposal approved doesn’t necessarily mean someone will feel obliged 
to implement it. Sometimes people propose a feature they’d like to see, but do 
not have the knowledge to implement it. Sometimes the scope of a feature is 
only evident after the review (and sometimes it’s not even evident then — some 
gotchas only pop up once you try to implement “for real”).

I think we need to keep an eye on the backlog (both proposals *and* 
implementation of previously approved ones), but if no-one’s willing to 
implement them, I don’t think we can force anyone…

Daniel.

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

[swift-evolution] [Meta] What does the backlog mean to the process?

[Félix Cloutier via swift-evolution]

Hello all,

With the Swift 3 deadline passed, according to the Swift Evolution progress 
page, about 20% of the proposals that the community voted in won't make it for 
Swift 3. Beyond the implications for the language itself, what does that mean 
for the swift-evolution process?

Félix

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

Re: [swift-evolution] Arrays and variadic parameters

[Tim Vermeulen via swift-evolution]

I agree mostly with what you’re saying, but variadic parameters don’t actually 
require at least one element. `max` simply returns a non-optional because its 
function signature has three non-variadic parameters as well:

public func max(_ x: T, _ y: T, _ z: T, _ rest: T...) -> T

> This has been brought up and there was a proposal by Haravikk, but the 
> discussion started almost mid-July and the deadline for all Swift 3 
> *implementation* was on Jul 27. So it didn't make it, but I think there will 
> be enough discussion about it on Aug 1 and after (all discussion about 
> features for future Swift releases is currently on hold until Aug 1).
> 
> Unfortunately, the suggested behavior has an issue what to do when the array 
> is empty. For example, you've mentioned min and max - there are (as variadic) 
> ensured to always be called with at least one value. When you use it with an 
> array, there is no guarantee that the array contains any element. In such 
> cases, what should the min/max do? Crash? Return +-infinity?
> 
> Changing min/max to return an optional would be a solution, but I don't think 
> a good one.
> 
> Moreover, for this particular example, you already have min/max on arrays:
> 
> let numbers = [23, 43, 12, 10]
> numbers.minElement()
> 
> > On Jul 29, 2016, at 11:46 AM, Alexandre Lopoukhine via 
> > swift-evolutionwrote:
> > 
> > Hello all,
> > 
> > I'm not sure if this has been brought up before, or what the status of the 
> > issue is as of Swift 3, but I was wondering why there is no option to call 
> > a function that takes a variadic parameter argument with an array. Seen as 
> > the parameter essentially becomes an array, and is used as such in the 
> > function, I think that adding the ability to call it with one directly 
> > could be useful, with few downsides. This will, for example, allow you to 
> > use the built-in `min` and `max` functions on arrays.
> > 
> > WDYT?
> > 
> > – Sasha
> > ___
> > 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]Allow constraints on associatedtype and shorten type constraints list in function

[Susan Cheng via swift-evolution]

Thanks.

I found this proposal in pull requests after the email sent.

Anders Ha  於 2016年7月29日星期五 寫道：

> It is one of the items in the Generics Manifesto, and we had a discussion
> thread with a proposal on this already, however halted for being an
> addictive feature. Anyway, aren't discussions on post Swift 3 matters
> preferred to start on Aug 1?
>
>
>
> Hart's proposal
>
> https://github.com/hartbit/swift-evolution/blob/master/proposals/-powerful-constraints-associated-types.md
>
> [swift-evolution] [Proposal] More Powerful Constraints for Associated Types
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016354.html
>
>
>
> Regards,
> Anders
>
>
> On 29 Jul 2016, at 10:17 AM, Susan Cheng via swift-evolution <
> swift-evolution@swift.org
> > wrote:
>
> Hello swift community,
>
> I want to introduce a proposal to allow constraints on associatedtype.
> I found a bug report(https://bugs.swift.org/browse/SR-1466) and it's due
> to without constraints on associatedtype itself.
>
> This force us always have to write the redundant constraints like 
> Indices.Iterator.Element
> == Index or Indices.SubSequence.Iterator.Element == Index on type
> constraints in function:
>
> public extension MutableCollection where Self : RandomAccessCollection,
> Indices.Index == Index, Indices.SubSequence : RandomAccessCollection,
> Indices.SubSequence.Iterator.Element == Index {
>
>
> /// Shuffle `self` in-place.
> mutating func shuffle() {
> for i in self.indices.dropLast() {
> let j = self.indices.suffix(from: i).random()!
> if i != j {
> swap([i], [j])
> }
> }
> }
> }
>
> Besides this, we also can write some odd definitions but allowed by swift
> compiler.
>
> struct MyArray : Collection {
>
>
> typealias Indices = CountableRange
>
>
> var base: [Int]
>
>
> var startIndex: Int {
> return base.startIndex
> }
> var endIndex: Int {
> return base.endIndex
> }
>
> func index(after: Int) -> Int {
> return after + 1
> }
>
>
> var indices: CountableRange {
> return CountableRange(uncheckedBounds: (lower: Int32(startIndex),
> upper: Int32(endIndex)))
> }
>
>
> subscript(position: Int) -> Int {
> get {
> return base[position]
> }
> set {
> base[position] = newValue
> }
> }
> }
>
> as a reference:
> http://stackoverflow.com/questions/37581234/can-an-associated-type-be-restricted-by-protocol-conformance-and-a-where-clause
>
> it's clearly that we need a syntax like this:
>
> public protocol Collection : Indexable, Sequence {
>
>
> /// A sequence that represents a contiguous subrange of the
> collection's
> /// elements.
> ///
> /// This associated type appears as a requirement in the `Sequence`
> /// protocol, but it is restated here with stricter constraints. In a
> /// collection, the subsequence should also conform to `Collection`.
> associatedtype SubSequence : IndexableBase, Sequence where
> SubSequence.Iterator.Element == Iterator.Element = Slice
>
>
> /// A type that can represent the indices that are valid for
> subscripting the
> /// collection, in ascending order.
> associatedtype Indices : IndexableBase, Sequence where
> Indices.Iterator.Element == Index = DefaultIndices
>
> }
>
> This  harmless and brings huge benefits to swift.
> ___
> 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]Allow constraints on associatedtype and shorten type constraints list in function

[Anders Ha via swift-evolution]

It is one of the items in the Generics Manifesto, and we had a discussion 
thread with a proposal on this already, however halted for being an addictive 
feature. Anyway, aren't discussions on post Swift 3 matters preferred to start 
on Aug 1?



Hart's proposal
https://github.com/hartbit/swift-evolution/blob/master/proposals/-powerful-constraints-associated-types.md
 


[swift-evolution] [Proposal] More Powerful Constraints for Associated Types
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016354.html
 




Regards,
Anders


> On 29 Jul 2016, at 10:17 AM, Susan Cheng via swift-evolution 
>  wrote:
> 
> Hello swift community,
> 
> I want to introduce a proposal to allow constraints on associatedtype. 
> I found a bug report(https://bugs.swift.org/browse/SR-1466 
> ) and it's due to without constraints 
> on associatedtype itself.
> 
> This force us always have to write the redundant constraints like 
> Indices.Iterator.Element == Index or Indices.SubSequence.Iterator.Element == 
> Index on type constraints in function:
> 
> public extension MutableCollection where Self : RandomAccessCollection, 
> Indices.Index == Index, Indices.SubSequence : RandomAccessCollection, 
> Indices.SubSequence.Iterator.Element == Index {
> 
> /// Shuffle `self` in-place.
> mutating func shuffle() {
> for i in self.indices.dropLast() {
> let j = self.indices.suffix(from: i).random()!
> if i != j {
> swap([i], [j])
> }
> }
> }
> }
> 
> Besides this, we also can write some odd definitions but allowed by swift 
> compiler.
> 
> struct MyArray : Collection {
> 
> typealias Indices = CountableRange
> 
> var base: [Int]
> 
> var startIndex: Int {
> return base.startIndex
> }
> var endIndex: Int {
> return base.endIndex
> }
> 
> func index(after: Int) -> Int {
> return after + 1
> }
> 
> var indices: CountableRange {
> return CountableRange(uncheckedBounds: (lower: Int32(startIndex), 
> upper: Int32(endIndex)))
> }
> 
> subscript(position: Int) -> Int {
> get {
> return base[position]
> }
> set {
> base[position] = newValue
> }
> }
> }
> 
> as a reference: 
> http://stackoverflow.com/questions/37581234/can-an-associated-type-be-restricted-by-protocol-conformance-and-a-where-clause
>  
> 
> 
> it's clearly that we need a syntax like this:
> 
> public protocol Collection : Indexable, Sequence {
> 
> /// A sequence that represents a contiguous subrange of the collection's
> /// elements.
> ///
> /// This associated type appears as a requirement in the `Sequence`
> /// protocol, but it is restated here with stricter constraints. In a
> /// collection, the subsequence should also conform to `Collection`.
> associatedtype SubSequence : IndexableBase, Sequence where 
> SubSequence.Iterator.Element == Iterator.Element = Slice
> 
> /// A type that can represent the indices that are valid for subscripting 
> the
> /// collection, in ascending order.
> associatedtype Indices : IndexableBase, Sequence where 
> Indices.Iterator.Element == Index = DefaultIndices
> 
> }
> 
> This  harmless and brings huge benefits to swift.
> ___
> 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] Arrays and variadic parameters

[Charlie Monroe via swift-evolution]

This has been brought up and there was a proposal by Haravikk, but the 
discussion started almost mid-July and the deadline for all Swift 3 
*implementation* was on Jul 27. So it didn't make it, but I think there will be 
enough discussion about it on Aug 1 and after (all discussion about features 
for future Swift releases is currently on hold until Aug 1).

Unfortunately, the suggested behavior has an issue what to do when the array is 
empty. For example, you've mentioned min and max - there are (as variadic) 
ensured to always be called with at least one value. When you use it with an 
array, there is no guarantee that the array contains any element. In such 
cases, what should the min/max do? Crash? Return +-infinity?

Changing min/max to return an optional would be a solution, but I don't think a 
good one.

Moreover, for this particular example, you already have min/max on arrays:

let numbers = [23, 43, 12, 10]
numbers.minElement()

> On Jul 29, 2016, at 11:46 AM, Alexandre Lopoukhine via swift-evolution 
>  wrote:
> 
> Hello all,
> 
> I'm not sure if this has been brought up before, or what the status of the 
> issue is as of Swift 3, but I was wondering why there is no option to call a 
> function that takes a variadic parameter argument with an array. Seen as the 
> parameter essentially becomes an array, and is used as such in the function, 
> I think that adding the ability to call it with one directly could be useful, 
> with few downsides. This will, for example, allow you to use the built-in 
> `min` and `max` functions on arrays.
> 
> WDYT?
> 
> – Sasha
> ___
> 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] Arrays and variadic parameters

[Alexandre Lopoukhine via swift-evolution]

Hello all,

I'm not sure if this has been brought up before, or what the status of the 
issue is as of Swift 3, but I was wondering why there is no option to call a 
function that takes a variadic parameter argument with an array. Seen as the 
parameter essentially becomes an array, and is used as such in the function, I 
think that adding the ability to call it with one directly could be useful, 
with few downsides. This will, for example, allow you to use the built-in `min` 
and `max` functions on arrays.

WDYT?

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