* 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.
* 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
···
On Jul 29, 2016, at 4:26 PM, Erica Sadun <erica@ericasadun.com> wrote:
* 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
···
On Jul 29, 2016, at 5:43 PM, Chris Lattner <clattner@apple.com> wrote:
On Jul 29, 2016, at 4:26 PM, Erica Sadun <erica@ericasadun.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)
My .02
Brandon
···
On Jul 29, 2016, at 7:43 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jul 29, 2016, at 4:26 PM, Erica Sadun <erica@ericasadun.com> 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!
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:
-Chris
···
On Jul 29, 2016, at 5:05 PM, Erica Sadun <erica@ericasadun.com> wrote:
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
···
On Jul 29, 2016, at 5:14 PM, Brandon Knope <bknope@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)
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
···
30 Jul 2016 02:17 Chris Lattner via swift-evolution <swift-evolution@swift.org> 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.
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
···
On Jul 29, 2016, at 5:29 PM, Magnus Ahltorp <map@kth.se> wrote:
30 Jul 2016 02:17 Chris Lattner via swift-evolution <swift-evolution@swift.org> 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.
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\.
···
On Jul 29, 2016, at 5:59 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:
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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Jul 29, 2016, at 5:29 PM, Magnus Ahltorp <map@kth.se <mailto:map@kth.se>> wrote:
30 Jul 2016 02:17 Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.
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
···
On Jul 29, 2016, at 6:14 PM, Daniel Duan <daniel@duan.org> wrote:
On Jul 29, 2016, at 5:59 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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\.
Where can we learn what affects the ABI? (Google, yes, but is there a highly respected document or article?)
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 <swift-evolution@swift.org> wrote:
On Jul 29, 2016, at 5:29 PM, Magnus Ahltorp <map@kth.se> wrote:
30 Jul 2016 02:17 Chris Lattner via swift-evolution <swift-evolution@swift.org> 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.
On Jul 29, 2016, at 9:14 PM, Daniel Duan <daniel@duan.org> wrote:
On Jul 29, 2016, at 5:59 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> 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 <swift-evolution@swift.org> wrote:
On Jul 29, 2016, at 5:29 PM, Magnus Ahltorp <map@kth.se> wrote:
30 Jul 2016 02:17 Chris Lattner via swift-evolution <swift-evolution@swift.org> 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
···
30 Jul 2016 02:38 Chris Lattner <clattner@apple.com> wrote:
On Jul 29, 2016, at 5:29 PM, Magnus Ahltorp <map@kth.se> wrote:
30 Jul 2016 02:17 Chris Lattner via swift-evolution <swift-evolution@swift.org> 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.
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
···
On Jul 29, 2016, at 5:53 PM, Magnus Ahltorp <map@kth.se> wrote:
Foundation already has NSRegularExpression. Do you mean that the
stdlib could potentially duplicate Foundation functionality? If so,
what are the implications for Foundation (and
swift-corelibs-foundation)? Does this also mean that other "stringy"
functionality could arrive in the stdlib, for example a Swifty JSON
serializer/deserializer?
Best wishes,
···
On 30 July 2016 at 02:33, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
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.
As others have mentioned, the interesting thing in this space is language support for regex literals. They should tie into the pattern matching constructs in the language (e.g. switch, if case, etc).
Better support for JSON is also interesting and possible over the next year, but it would be the domain of the corelibs folks. I believe they have some ideas in this space, but probably aren’t ready to dive into it given that Swift 3 isn’t done, and I’m not sure if there are any “plans”.
-Chris
···
On Jul 30, 2016, at 1:42 AM, Ian Partridge <ian@poncho.org.uk> wrote:
On 30 July 2016 at 02:33, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote:
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.
Foundation already has NSRegularExpression. Do you mean that the
stdlib could potentially duplicate Foundation functionality? If so,
what are the implications for Foundation (and
swift-corelibs-foundation)? Does this also mean that other "stringy"
functionality could arrive in the stdlib, for example a Swifty JSON
serializer/deserializer?
Foundation already has NSRegularExpression. Do you mean that the
stdlib could potentially duplicate Foundation functionality?
NSRegularExpression is not really easy to use for most common usecases (first match in string, etc.) + it lacks a lot of features e.g. Python has (named groups, etc.). I've personally never used NSRegularExpression and rather wrote an ObjC wrapper around re2 (https://github.com/google/re2/\).
I'd really like Swift's regex to be much more powerful and be able to match against it in a switch:
switch someString {
case /\d+:
...
case /w+:
...
...
Also, you can have compile-time check whether the expression is valid if regex is part of the language. But that's kind of getting too specific and away from the original discussion.
···
If so,
what are the implications for Foundation (and
swift-corelibs-foundation)? Does this also mean that other "stringy"
functionality could arrive in the stdlib, for example a Swifty JSON
serializer/deserializer?
actually, we are already doing something like this without modifying the
language itself here:
It's Scala style (.r notion). Works perfectly with switch keyword:
*switch letter {*
* //note .r after the string literal of the pattern*
* case "\\d".r: print("digit")*
* case "[a-z]".r: print("letter")*
* default: print("bizarre symbol")*
*}*
You can try it in release 0.8 (for Swift 2.x, Swift 3.0 release with this
feature is not issued yet).
What we really lack though is matching objects to tuples with *switch*.
Here is the explanation:
Let's say we have a match:
let match = "(\d*)(.*)".r.findFirst("123abc")
what I would love to do with it is the following:
*switch match {*
*case (_, "xyz"): print("end of alphabet")*
*case ("123", _): print("beginning of numerics")*
*default: print("I don't care")*
*}*
It would be possible if ~= operator was a bit more powerful and allow to
match against tuples (currently, it can't even without underscores). What I
would like to propose (will create an evolution proposal later if it's
something the core-team is willing to consider) is to:
1. Either extend ~= to allow to match tuples. Currently, I see it the
following way (an example):
*// you have to create an operator for each tuple size, any ideas on a
better solution?*
Why optionals? Well, this way we could process _ substitutions.
2. Implement Scala-like apply/unapply. Good too, but option one sounds more
"Swiftish" to me personally.
Why is this cool? Well, this is not just about Regular Expressions, it's
rather overall language power and Regex is a nice example. I think there
will be a lot of examples, especially with the web apps. Some additional
ones I can think of right away is processing of URL or query params or
"parsing" of message object (i.e. in Actors or Queues).
Why making the match object to be an enum would not work? Well, first of
all there is some more additional info in it which I would like to keep
hidden for the user (i.e. full match, etc.) and not to push to match to.
This is not just one use case and in others it might become even more
important.
Hope it's clear and understandable (let me know if not and I'll bring it in
more details). Would this fit to Swift 3.x (no existing code impact) or to
Swift 4.x?
Best,
Daniel
···
On Sat, Jul 30, 2016 at 12:37 PM, Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote:
> Foundation already has NSRegularExpression. Do you mean that the
> stdlib could potentially duplicate Foundation functionality?
NSRegularExpression is not really easy to use for most common usecases
(first match in string, etc.) + it lacks a lot of features e.g. Python has
(named groups, etc.). I've personally never used NSRegularExpression and
rather wrote an ObjC wrapper around re2 (https://github.com/google/re2/\).
I'd really like Swift's regex to be much more powerful and be able to
match against it in a switch:
switch someString {
case /\d+:
...
case /w+:
...
...
Also, you can have compile-time check whether the expression is valid if
regex is part of the language. But that's kind of getting too specific and
away from the original discussion.
> If so,
> what are the implications for Foundation (and
> swift-corelibs-foundation)? Does this also mean that other "stringy"
> functionality could arrive in the stdlib, for example a Swifty JSON
> serializer/deserializer?
>
> Best wishes,
>
> --
> Ian Partridge
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution