Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Jarod Long via swift-evolution]

>
> • What is your evaluation of the proposal?
>
+1, very happy to see this coming together! I've been interested in this 
feature since the early days of Swift.

My only reservation is that I would have expected to be able to access the list 
of values without any extra annotations. Is there a reason to not automatically 
give ValueEnumerable conformance to any enum that fits the criteria for 
synthesis?

>
> • Is the problem being addressed significant enough to warrant a change to 
> Swift?
>
Definitely, for the reasons mentioned in the proposal's motivation.

>
> • Does this proposal fit well with the feel and direction of Swift?
>
Yes, this feels like a very natural addition to the language.

>
> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
>
I've used the GetValues API in C#, and though I think the proposed API is a 
much better fit for Swift, I did appreciate that GetValues could be used on any 
enum without needing to opt in manually.

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


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

Re: [swift-evolution] [swift-evolution-announce] [Accepted with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”

[Jarod Long via swift-evolution]

I don't think anybody wants a big discussion out of this, but if there's a 
chance that the name will be further revised, then I agree with Nevin, the solo 
"compacted" is a more appropriate term than "compacting" here. Compacting needs 
an grammatical object to apply to, so if we wanted to use that form, 
"compactingElements" would be the proper way to phrase it.

"compactingMap" works, because the map operation is being compacted. But 
"compactedMap" also works, because it's a compacted form of the map operation.

So if we want to revise the naming, I would suggest "compacted" and 
"compactedMap". But I think the accepted naming is fine as well, and we should 
avoid "compacting".

Jarod

On Dec 19, 2017, 15:52 -0800, Nevin Brackett-Rozinsky via swift-evolution 
, wrote:
> If we’re bikeshedding the verb tense then “compactMap” sounds right to me, 
> and adding “ing” would be needlessly verbose.
>
> For the non-mapping version, I’d lean toward “compacted”. However, we could 
> also postpone the debate over its spelling until such time as we are actually 
> ready to introduce it.
>
> Nevin
>
>
>
> > On Tue, Dec 19, 2017 at 6:42 PM, Dave Abrahams via swift-evolution 
> >  wrote:
> > >
> > >
> > > > On Dec 19, 2017, at 2:28 PM, Xiaodi Wu via swift-evolution 
> > > >  wrote:
> > > >
> > > > I disagree. Let’s not reopen what is settled. “Compact” can be a noun 
> > > > just as “map” and “filter” can; as long as there are no in-place 
> > > > variants, there can be no ambiguity.
> > > > > On Tue, Dec 19, 2017 at 17:11 Brent Royal-Gordon via swift-evolution 
> > > > >  wrote:
> > > > > > > On Dec 19, 2017, at 8:56 AM, John McCall  
> > > > > > > wrote:
> > > > > > >
> > > > > > > Therefore, SE-0187 is accepted, with the revision that the new 
> > > > > > > name be Sequence.compactMap(_:), and with the agreement that we 
> > > > > > > will add Sequence.compact() when it is possible to do so.
> > > > > >
> > > > > > I like `compact` as the basis for the name, but I hope the core 
> > > > > > team will consider whether the eventual nil-removal method should 
> > > > > > be called `compacting()`, and whether therefore this method should 
> > > > > > be called `compactingMap(_:)`. Prior art on the name `compact()` 
> > > > > > does exist, but I don't think it's strong enough to justify 
> > > > > > deviating from the API Guidelines.
> > > > > >
> > > > > > I don't think we need a full review on this tiny issue; five 
> > > > > > minutes of the core team's time should more than suffice.
> > >
> > > I agree with Brent. IMO we're firmly outside the domain of established 
> > > terms-of-art here (Ruby notwithstanding).
> > >
> > > ___
> > > 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] [Accepted with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”

[Jarod Long via swift-evolution]

Happy to hear that we went in this direction! Looking forward to the compact 
method as well.

Jarod

On Dec 19, 2017, 08:56 -0800, John McCall via swift-evolution 
, wrote:
> Hi, Swift community!  I apologize for the delay in reporting our decision 
> here; between one holiday and the other, it took awhile for the core team to 
> assemble a quorum to talk through this.
>
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>
> The second review of SE-0187 “Introduce Sequence.filterMap(_:)” ran from 
> November 15...20, 2017.  The result of the first review was consensus to 
> rename the method, and the purpose of the second review was to get more 
> specific feedback on what the new name should be.
>
> "filterMap" is a name with some precedent in other programming languages, 
> especially functional ones, but some people felt strongly that the name was 
> misleading because, as a combined operation, it wasn't quite a filter or a 
> map.  Of the alternatives, the one with the strongest support seemed to be 
> "compactMap", which builds on the precedent of "compact", an operation from 
> other languages (notably Ruby) which returns a copy of the input without nil 
> values.  Swift does not currently have such an operation, and in fact it is 
> not currently possible to express it; nonetheless, the core team agrees that 
> it would be a reasonable operation to add, and that "compactMap" is a good 
> name for the operation.
>
> Therefore, SE-0187 is accepted, with the revision that the new name be 
> Sequence.compactMap(_:), and with the agreement that we will add 
> Sequence.compact() when it is possible to do so.
>
> Thank you all for your continued contributions to making Swift a better 
> language.
>
> John McCall
> Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

[Jarod Long via swift-evolution]

The name that feels natural to me would be `sequentiallyEquals`. I don't 
dispute that the term "lexicographical" is used correctly here, although at 
least for me personally, it's not a word that I encounter frequently enough to 
understand what this method would do without reading the documentation. Like 
Kevin, if I were to guess what the method did without checking, I would 
probably think that it compared lexicographically-sorted versions of the 
collections.

But the consistency with `lexicographicallyPrecedes` is a pretty strong 
argument, although `sequentiallyPrecedes` would also feel more natural to me 
there, and my suspicion about the mentioned lack of evidence that the method 
has been a pitfall for users is that it's not actually used often enough out in 
the wild to have heard much about it. That's just a guess though. This proposal 
is the first time I've learned of its existence.

In any case, my ideal version of this proposal would use `sequentiallyEquals` 
and also rename `lexicographicallyPrecedes` to `sequentiallyPrecedes`, but I 
still like the proposal overall as-is. Thanks for bringing it forward!

Jarod

On Oct 12, 2017, 16:24 -0700, Xiaodi Wu via swift-evolution 
, wrote:
> Rename Sequence.elementsEqual
>
> • Proposal: SE-
> • Authors: Xiaodi Wu
> • Review Manager: TBD
> • Status: Awaiting review
>
> Introduction
> The current behavior of Sequence.elementsEqual is potentially confusing to 
> users given its name. Having surveyed the alternative solutions to this 
> problem, it is proposed that the method be renamed to 
> Sequence.lexicographicallyEquals.
> Motivation
> As outlined by Ole Begemann, use of Sequence.elementsEqual(_:) can lead to 
> surprising results if the sequences compared are unordered:
> var set1: Set = Set(1...5)
> var set2: Set = Set((1...5).reversed())
>
> set1 == set2 // true
> set1.elementsEqual(set2) // false
> This result does reflect the intended and documented behavior of the 
> elementsEqual(_:) method, which performs a lexicographical elementwise 
> comparison. That is, the method first compares set1.first to set2.first, then 
> (if the two elements compare equal) compares the next element stored 
> internally in set1 to the next element stored internally in set2, and so on.
> In almost all circumstances where a set is compared to another set, or a 
> dictionary is compared to another dictionary, users should use == instead of 
> elementsEqual(_:).
> Proposed solution
> The proposed solution is the result of an iterative process of reasoning, 
> presented here:
> The first and most obvious solution is to remove the elementsEqual(_:) method 
> altogether in favor of ==. This prevents its misuse. However, because 
> elementsEqual(_:) is a generic method on Sequence, we can use it to compare 
> an instance of UnsafeBufferPointer to an instance of [Int]. This is a 
> useful and non-redundant feature which would be eliminated if the method is 
> removed altogether.
> A second solution is to create overloads that forbid the use of the 
> elementsEqual(_:) method specifically in non-generic code. This would prevent 
> misuse in non-generic code; however, it would also forbid legitimate 
> mixed-type comparisons in non-generic code while failing to prevent misuse in 
> generic code. The solution also creates a difference in the behavior of 
> generic and non-generic code calling the same method, which is potentially 
> confusing, without solving the problem completely.
> A third solution is to dramatically overhaul the protocol hierarchy for Swift 
> sequences and collections so that unordered collections no longer have 
> members such as first and elementsEqual(_:). However, this would be a 
> colossal and source-breaking undertaking, and it is unlikely to be 
> satisfactory in addressing all the axes of differences among sequence and 
> collection types:
>
> • Finite versus infinite
> • Single-pass versus multi-pass
> • Ordered versus unordered
> • Lazy versus eager
> • Forward/bidirectional/random-access
>
> A fourth solution is proposed here. It is predicated on the following 
> observation:
> Another method similar to elementsEqual(_:) already exists on Sequence named 
> lexicographicallyPrecedes(_:). Like first, elementsEqual(_:), drop(while:), 
> and others, it relies on the internal order of elements in a manner that is 
> not completely suitable for an unordered collection. However, like first and 
> unlike elementsEqual(_:), this fact is called out in the name of the method; 
> unsurprisingly, like first and unlike elementsEqual(_:), there is no evidence 
> that lexicographicallyPrecedes(_:) has been a pitfall for users.
> This observation suggests that a major reason for confusion over 
> elementsEqual(_:) stems from its name. So, it is proposed that 
> elementsEqual(_:) should be renamed to lexicographicallyEquals(_:). The 
> function will remain somewhat of a poor fit for unordered collections, but no 
> more so 

Re: [swift-evolution] commas optional

[Jarod Long via swift-evolution]

Ahh, yeah, that does seem like a much trickier case to avoid breaking. My 
instinct says it's still possible to avoid, but maybe not without lots of 
complexity.

Jarod

On Oct 12, 2017, 16:21 -0700, Xiaodi Wu <xiaodi...@gmail.com>, wrote:
> On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution 
> <swift-evolution@swift.org> wrote:
> > > I don't really expect this sort of syntactic sugar to be popular enough 
> > > to make it through swift-evolution, and I don't think it's worth the 
> > > distraction from more important priorities at this time, but for what 
> > > it's worth, I've enjoyed this feature in other languages that support it. 
> > > It plays a small part in making code more focused by eliminating 
> > > unnecessary syntax.
> > >
> > > I could be wrong, but I'm not so sure that this would actually be source 
> > > breaking. Even if you have something like this:
> > >
> > > let points = [
> > >     Point(
> > >         x: 1.0,
> > >         y: 2.0
> > >     ),
> > >     Point(
> > >         x: 3.0,
> > >         y: 4.0
> > >     )
> > > ]
> > >
> > > Proper implementation of this feature wouldn't suddenly interpret 
> > > `Point(` as its own element.
> >
> > There are those of us who respect the 80-character line and break 
> > expressions across lines:
> >
> > let x = [
> >   NSVeryVeryVeryLongType
> >     .veryVeryVeryLongProperty +
> >   NSVeryVeryVeryLongType2
> >     .veryVeryVeryLongProperty2,
> > ]
> >
> > It would be a pleasant surprise if a grammar with optional commas can avoid 
> > blowing up existing code; I'm quite doubtful.
> >
> >
> > > On Oct 12, 2017, 12:23 -0700, Josh Parmenter via swift-evolution 
> > > <swift-evolution@swift.org>, wrote:
> > > >
> > > >
> > > > On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution 
> > > > <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:
> > > >
> > > > a semicolon is a purely syntactic delimiter, the comma on the other 
> > > > hand corresponds to physical elements in a collection. I think the two 
> > > > are more different than you suggest.
> > > >
> > > >
> > > > I very much agree^
> > > >
> > > > Josh
> > > >
> > > >
> > > >
> > > > Joshua Parmenter | Engineering Lead, Apple Technologies
> > > >
> > > > T 248 777 
> > > > C 206 437 1551
> > > > F 248 616 1980
> > > > www.vectorform.com<http://www.vectorform.com/
> > > >
> > > > Vectorform
> > > > 2211 5th Ave Suite 201
> > > > Seattle, WA 98121 USA
> > > >
> > > > Think Tank. Lab. Studio.
> > > > We invent digital products and experiences.
> > > >
> > > > SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
> > > > ___
> > > > 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] commas optional

[Jarod Long via swift-evolution]

I don't really expect this sort of syntactic sugar to be popular enough to make 
it through swift-evolution, and I don't think it's worth the distraction from 
more important priorities at this time, but for what it's worth, I've enjoyed 
this feature in other languages that support it. It plays a small part in 
making code more focused by eliminating unnecessary syntax.

I could be wrong, but I'm not so sure that this would actually be source 
breaking. Even if you have something like this:

let points = [
    Point(
        x: 1.0,
        y: 2.0
    ),
    Point(
        x: 3.0,
        y: 4.0
    )
]

Proper implementation of this feature wouldn't suddenly interpret `Point(` as 
its own element.

Jarod

On Oct 12, 2017, 12:23 -0700, Josh Parmenter via swift-evolution 
, wrote:
>
>
> On Oct 12, 2017, at 12:17 PM, Kelvin Ma via swift-evolution 
> > wrote:
>
> a semicolon is a purely syntactic delimiter, the comma on the other hand 
> corresponds to physical elements in a collection. I think the two are more 
> different than you suggest.
>
>
> I very much agree^
>
> Josh
>
>
>
> Joshua Parmenter | Engineering Lead, Apple Technologies
>
> T 248 777 
> C 206 437 1551
> F 248 616 1980
> www.vectorform.com
> Vectorform
> 2211 5th Ave Suite 201
> Seattle, WA 98121 USA
>
> Think Tank. Lab. Studio.
> We invent digital products and experiences.
>
> SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
> ___
> 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] Enums and Source Compatibility

[Jarod Long via swift-evolution]

>From the perspective of primarily an app developer rather than library author, 
>I'm not a big fan of this change. I find myself in the "unhappy with the loss 
>of compiler warnings" camp -- if I'm switching over every case of an enum, 
>then I almost certainly want to be notified that a new case has been added by 
>way of a compiler error than via the arbitrary runtime behavior I added in the 
>previously-unreachable default case.

This seems like a clear situation where source compatibility is not desired to 
me. For those who want to maximize compatibility, it is possible to opt into it 
by adding a default case to an exhaustive switch over a library enum, but the 
reverse is not true if this change is made as-is. You can't opt into an 
exhaustive switch for nonexhaustive enums if handling every case is valued over 
source compatibility.

A secondary concern I have is that this introduces extra complexity that could 
be confusing for new Swift developers. The current enum exhaustivity rules are 
consistent and easy to explain, but they become more cumbersome with this added 
exception that only applies to some enums that specifically only come from 
outside the current module. If this change is made, I would encourage some 
effort towards a specific error message when switching over all cases of a 
nonexhaustive enum without a default case. Rather than the existing "Switch 
must be exhaustive", I think it would go a long way towards avoiding confusion 
to say something like "Switch over a nonexhaustive enum must have a default 
case".

In any case, I don't think these are terrible issues -- I agree with the 
proposal's statement that switches over nonexhaustive enums are generally 
uncommon. But if that's true, it feels like the source compatibility motivation 
is weak, since not much code is affected anyways. Perhaps the benefits from a 
library author's perspective make this change worth it, but at least for me and 
my coworkers, it would be an unwelcome change overall.

Jarod

On Sep 5, 2017, 17:19 -0700, Jordan Rose via swift-evolution 
, wrote:
> I've taken everyone's feedback into consideration and written this up as a 
> proposal: 
> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md.
>  The next step is working on an implementation, but if people have further 
> pre-review comments I'd be happy to hear them.
>
> Jordan
>
>
> > On Aug 8, 2017, at 15:27, Jordan Rose  wrote:
> >
> > Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to 
> > an issue that's been around for a while: the source compatibility of enums. 
> > Today, it's an error to switch over an enum without handling all the cases, 
> > but this breaks down in a number of ways:
> >
> > - A C enum may have "private cases" that aren't defined inside the original 
> > enum declaration, and there's no way to detect these in a switch without 
> > dropping down to the rawValue.
> > - For the same reason, the compiler-synthesized 'init(rawValue:)' on an 
> > imported enum never produces 'nil', because who knows how anyone's using C 
> > enums anyway?
> > - Adding a new case to a Swift enum in a library breaks any client code 
> > that was trying to switch over it.
> >
> > (This list might sound familiar, and that's because it's from a message of 
> > mine on a thread started by Matthew Johnson back in February called 
> > "[Pitch] consistent public access modifiers". Most of the rest of this 
> > email is going to go the same way, because we still need to make progress 
> > here.)
> >
> > At the same time, we really like our exhaustive switches, especially over 
> > enums we define ourselves. And there's a performance side to this whole 
> > thing too; if all cases of an enum are known, it can be passed around much 
> > more efficiently than if it might suddenly grow a new case containing a 
> > struct with 5000 Strings in it.
> >
> >
> > Behavior
> >
> > I think there's certain behavior that is probably not terribly 
> > controversial:
> >
> > - When enums are imported from Apple frameworks, they should always require 
> > a default case, except for a few exceptions like NSRectEdge. (It's Apple's 
> > job to handle this and get it right, but if we get it wrong with an 
> > imported enum there's still the workaround of dropping down to the raw 
> > value.)
> > - When I define Swift enums in the current framework, there's obviously no 
> > compatibility issues; we should allow exhaustive switches.
> >
> > Everything else falls somewhere in the middle, both for enums defined in 
> > Objective-C:
> >
> > - If I define an Objective-C enum in the current framework, should it allow 
> > exhaustive switching, because there are no compatibility issues, or not, 
> > because there could still be private cases defined in a .m file?
> > - If there's an Objective-C enum in another framework (that I built locally 
> > with 

Re: [swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

[Jarod Long via swift-evolution]

It's hard to say at this point since Jai is in an early state and isn't 
publicly available yet, but it seems to be working well on a small scale at 
least from the demos that have been shown.

If anyone's curious, this is the video where the feature was originally demoed. 
It's from the very beginning of the language's development, so a lot of it is 
probably out of date, but it should still be a good introduction to the 
feature: https://www.youtube.com/watch?v=UTqZNujQOlA

Jarod

On Aug 1, 2017, 11:20 -0700, Gor Gyolchanyan , 
wrote:
> > On Aug 1, 2017, at 8:50 PM, sw...@lng.la wrote:
> >
> > While we're considering compile-time execution, we should take a look at 
> > the `#run` directive in Jon Blow's Jai programming language. It allows you 
> > to run arbitrary code in your program at compile time and then utilize the 
> > output in your program.
> >
> > This page has a good summary and an example of the feature: 
> > https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md#arbitrary-compile-time-code-execution
>
> I read through the page and the way compile-time mechanism in Jai is very 
> close to what I had in mind. I'm curious about how it turned out for them.
>
> > I'm no expert, so I'm not sure if there's a reason something like this 
> > wouldn't work in the world of Swift, but it seems extremely elegant and 
> > flexible.
> >
> > Jarod
> >
> > On Jul 31, 2017, 23:58 -0700, Gor Gyolchanyan via swift-evolution 
> > , wrote:
> > > As with many other threads, the "constexpr" one changed into a fixed-size 
> > > array thread , so instead of fighting it, let's branch off into another 
> > > topic that also almost took over.
> > >
> > > The bottom line of this discussion is to weight pros and cons of a 
> > > compile-time execution feature and a metaprogramming feature built on top 
> > > of it.
> > >
> > > The way I imagine it to work is to have a new keyword `compiletime` (or 
> > > something similar) that can be applied to any executable block (property 
> > > accessor, property observer, function, closure), which would restrict the 
> > > use of runtime-only features of swift (the exact list of which is yet to 
> > > be defined) and make that block of code eligible for guaranteed 
> > > compiletime execution. Being eligible for compile-time execution 
> > > essentially means having the return value (and values of mutated state) 
> > > pass as a literal in the eyes of the compiler. Obviously, restrictions of 
> > > the subset of Swift (which would most definitely include access to source 
> > > code) in the compile-time context are transitive: the entire call 
> > > hierarchy has to adhere to the restrictions with no exceptions. Also, 
> > > obviously, in order to eligible code blocks to execute, all their 
> > > captured context and parameters have to also be compiletime. Compiletime 
> > > variables are mutable state during the compilation, which are demoted to 
> > > compile-time constants after the compilation.
> > >
> > > According to John McCall, the beginnings of this already exist in the 
> > > form of a simple expression folding that could be extended to encompass 
> > > more types of code to be executed at compile-time.
> > >
> > > The metaprogramming part is all about generating language constructs 
> > > programmatically. Currently, that niche is occupied by text-based 
> > > boilerplate generators like Gyb, Sourcery and the like.
> > > With the compile-time execution available, boilerplate could be remove 
> > > from the language entirely due to an unprecedented ability to modify the 
> > > fully parsed, structurized binary representation of the code form inside 
> > > the code.
> > > A set of built-in types and functions could be used to generate instances 
> > > of TypeAliasDeclaration, StructureDefinition, VariableDeclaration and 
> > > such. These would then be fed into a compile-time in-language 
> > > representation of the compiler to cause it to insert them into the 
> > > current module for use by other code. This would work very similarly to 
> > > LLVM's instruction builder class.
> > >
> > > According to David Sweeris, getting rid of compiler magic is one of 
> > > Swift's goals and you can see how this will be single most powerful way 
> > > of reducing the compiler to its bare minimum and moving most of the 
> > > runtime into the standard library.
> > >
> > > My main point of why I'd like to start an in-depth discussion about this 
> > > now is because this is a huge endeavor with tremendous consequences, 
> > > which need time to think through and plan accordingly. Swift 4 is about 
> > > to release in a few months and Swift 5's stages and priorities will be on 
> > > the table. I'd like to see where this can go *before* we miss the window 
> > > of opportunity on such a proposal and are stuck waiting for another 
> > > release cycle.
> > >
> > > I'd like to hear as many opinions as possible (especially 

Re: [swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

[Jarod Long via swift-evolution]

While we're considering compile-time execution, we should take a look at the 
`#run` directive in Jon Blow's Jai programming language. It allows you to run 
arbitrary code in your program at compile time and then utilize the output in 
your program.

This page has a good summary and an example of the feature: 
https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md#arbitrary-compile-time-code-execution

I'm no expert, so I'm not sure if there's a reason something like this wouldn't 
work in the world of Swift, but it seems extremely elegant and flexible.

Jarod

On Jul 31, 2017, 23:58 -0700, Gor Gyolchanyan via swift-evolution 
, wrote:
> As with many other threads, the "constexpr" one changed into a fixed-size 
> array thread , so instead of fighting it, let's branch off into another 
> topic that also almost took over.
>
> The bottom line of this discussion is to weight pros and cons of a 
> compile-time execution feature and a metaprogramming feature built on top of 
> it.
>
> The way I imagine it to work is to have a new keyword `compiletime` (or 
> something similar) that can be applied to any executable block (property 
> accessor, property observer, function, closure), which would restrict the use 
> of runtime-only features of swift (the exact list of which is yet to be 
> defined) and make that block of code eligible for guaranteed compiletime 
> execution. Being eligible for compile-time execution essentially means having 
> the return value (and values of mutated state) pass as a literal in the eyes 
> of the compiler. Obviously, restrictions of the subset of Swift (which would 
> most definitely include access to source code) in the compile-time context 
> are transitive: the entire call hierarchy has to adhere to the restrictions 
> with no exceptions. Also, obviously, in order to eligible code blocks to 
> execute, all their captured context and parameters have to also be 
> compiletime. Compiletime variables are mutable state during the compilation, 
> which are demoted to compile-time constants after the compilation.
>
> According to John McCall, the beginnings of this already exist in the form of 
> a simple expression folding that could be extended to encompass more types of 
> code to be executed at compile-time.
>
> The metaprogramming part is all about generating language constructs 
> programmatically. Currently, that niche is occupied by text-based boilerplate 
> generators like Gyb, Sourcery and the like.
> With the compile-time execution available, boilerplate could be remove from 
> the language entirely due to an unprecedented ability to modify the fully 
> parsed, structurized binary representation of the code form inside the code.
> A set of built-in types and functions could be used to generate instances of 
> TypeAliasDeclaration, StructureDefinition, VariableDeclaration and such. 
> These would then be fed into a compile-time in-language representation of the 
> compiler to cause it to insert them into the current module for use by other 
> code. This would work very similarly to LLVM's instruction builder class.
>
> According to David Sweeris, getting rid of compiler magic is one of Swift's 
> goals and you can see how this will be single most powerful way of reducing 
> the compiler to its bare minimum and moving most of the runtime into the 
> standard library.
>
> My main point of why I'd like to start an in-depth discussion about this now 
> is because this is a huge endeavor with tremendous consequences, which need 
> time to think through and plan accordingly. Swift 4 is about to release in a 
> few months and Swift 5's stages and priorities will be on the table. I'd like 
> to see where this can go *before* we miss the window of opportunity on such a 
> proposal and are stuck waiting for another release cycle.
>
> I'd like to hear as many opinions as possible (especially from the core team, 
> which is ultimately going to have to decide whether or not this is ever going 
> to happen).
>
> ___
> 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] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Jarod Long via swift-evolution]

Just wanted to throw in my preference for supporting both options. I'd also 
like to emphasize that !! isn't appealing just for the sake of terseness, but 
also because it completes the ?, ??, !, !! "family" of unwrapping operators in 
a way that reinforces their underlying concepts. In that sense, I think the 
addition of the operator actually makes the overall system more learnable 
through repeated application of a pattern.

Jarod

On Jun 30, 2017, 10:02 -0700, Dave DeLong via swift-evolution 
, wrote:
> These are good points, Brent.
>
>
> > On Jun 29, 2017, at 11:24 PM, Brent Royal-Gordon via swift-evolution 
> >  wrote:
> >
> > > On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution 
> > >  wrote:
> > >
> > > Using an operator to provide feedback on the context of a failed unwrap 
> > > has become a commonly implemented approach in the Swift developer 
> > > Community. What are your thoughts about adopting this widely-used 
> > > operator into the standard library?
> > >
> > > guard !lastItem.isEmpty else { return }
> > > let lastItem = array.last !! "Array must be non-empty"
> > >
> > > Details here:  
> > > https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b
> > >
> > > Thank you for your thoughtful feedback, -- E
> >
> > Finally found a few minutes to read this thread.
> >
> > I'm a big fan of the `Never`-based approach. (I was before, but I am more 
> > so now.) Here are the points I can see in its favor:
> >
> > 1. It is extremely clear about what's happening—`!!` is another random 
> > operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are 
> > fairly self-explanatory, and `??` is something you might already be using.
>
> !! is also clear about what’s happening, because it’s just like the existing 
> ! operator.
>
> > 2. It allows you to control the optimization behavior by using 
> > `fatalError`, `preconditionFailure`, or `assertionFailure` as desired.
>
> Yep. That’s cool.
>
> > 3. If we later change `throw` from being a statement to being a 
> > `Never`-returning expression, you could use `throw` on the right-hand side 
> > of `??`.
>
> Neat idea. 
>
> > 4. It supports other `Never`-returning operations, like `abort()` or 
> > `exit(_:)` or your custom `usage()` function, on the right side of `??`.
>
> Yep. That’s cool.
>
> > 5. It supports file-and-line error reporting without having to add any new 
> > features; `!!` could not do this because an operator can't have extra, 
> > defaulted parameters to carry the file and line.
>
> Erica’s proposal addresses this. Allowing operator functions to accept more 
> than 2 parameters that all have default arguments looks like it would be a 
> pretty straight-forward and non-controversial change. It would also allow the 
> FRP crowd to make their <~ and |> and ಠ_ಠ and (╯°□°)╯︵ ┻━┻ operators all 
> capture the #file and #line they’re used on, which would make debugging those 
> style of apps much easier.
>
> > 6. It harmonizes with the eventual idea of making `Never` a universal 
> > bottom type, but we don't actually have to implement that today, because we 
> > can just overload `??` for now.
>
> Yep. That’s cool.
>
> > Against these advantages, the only one I can see for `!!` is that it is 
> > terse. Terseness is good, especially for a feature which is competing with 
> > the single-character postfix `!` operator, but I can't help but be drawn to 
> > the flexibility and power of `??` with a `Never` expression on the 
> > right-hand side.
>
> I would argue that terseness is a goal of Swift. If it weren’t, we shouldn’t 
> have [Element] as sugar syntax for Array, or even a bunch of our 
> operators (postfix !, postfix ?, overflow checking operators, nil coalescing, 
> etc).
>
> IMO, having both !! that takes an error message and ?? that takes a () → 
> Never seem like worthwhile goals. The former allows me to be terse, yet still 
> expressive, and the latter allows me the customization to do what I want for 
> whatever is contextually appropriate in my situation.
>
> I don’t think anyone is arguing that ?? () → Never isn’t useful. The purpose 
> of this proposal is to put forward and defend the claim that “!! String” is 
> also useful and meets the barrier to entry in to the Standard Library.
>
> Dave
>
> ___
> 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] [Pitch or bug?] Expanding the capability of `.` prefixed lookup

[Jarod Long via swift-evolution]

I'd be happy to see this enhancement as well.

For what it's worth, a real case that I've wanted to use this for is modifying 
named colors, as in:

`view.backgroundColor = .blue.withAlphaComponent(0.5)`

Not a major inconvenience for sure, but it would be nice if this worked.

Jarod

On Jun 29, 2017, 09:54 -0700, Joe Groff via swift-evolution 
, wrote:
>
> > On Jun 29, 2017, at 5:19 AM, Matt Gallagher via swift-evolution 
> >  wrote:
> >
> > Super short summary:
> >
> > I think a function argument or right-hand-side expression prefixed with `.` 
> > should allow access to *any* static member on the expected type, dropping 
> > the existing limitations of this syntax.
> >
> > Detail:
> >
> > At the moment in Swift, you can use a `.` (period or dot) prefix to perform 
> > a scoped lookup of static vars and funcs on the expected type, if those 
> > static vars or funcs return that type.
> >
> > For example:
> >
> > // If we have a type `SomeNontrivialTypeName`
> > struct SomeNontrivialTypeName {
> > // With a static function returning `SomeNontrivialTypeName`
> > static func a() -> SomeNontrivialTypeName
> > }
> >
> > // And a function that requires a `SomeNontrivialTypeName` parameter
> > func f(a: SomeNontrivialTypeName)
> >
> > // We can call the function like this:
> > f(a: .a())
> >
> > The `.` prefix allows us to omit the typename `SomeNontrivialTypeName`; 
> > since the parameter already expects `SomeNontrivialTypeName`, the `.` 
> > already implies lookup in the list of static func/vars for 
> > `SomeNontrivialTypeName`.
> >
> > The purpose is syntactic efficiency and it's used to great extent across a 
> > wide range of Swift/AppKit/Foundation interfaces for enum-like value 
> > lookups. It lets us have very simple names that won't clash with names in 
> > the global namespace because they're not in the global namespace – and yet, 
> > they're only a single `.` more syntactic overhead.
> >
> > Unfortunately, there is no extendability. This approach will look up only 
> > static vars or funcs that immediately return the expected type and you 
> > can't transform the result – it's one function and done. For example, if 
> > `SomeNontrivialTypeName` has a fluent-style interface (i.e. an interface 
> > where instance methods return mutated `self` or new instances of 
> > `SomeNontrivialTypeName`):
> >
> > extension SomeNontrivialTypeName {
> > func addThings() -> SomeNontrivialTypeName
> > }
> >
> > trying to append this function won't work, even though the return type 
> > remains correct:
> >
> > f(a: .a().addThings())
> >
> > This fails and claims that we've forgotten to provide a parameter (!).
> >
> > A completely different kind of transformation might go via a different type
> >
> > extension SomeNontrivialTypeName {
> > static func another() -> AnotherType
> > }
> >
> > struct AnotherType {
> > func back() -> SomeNontrivialTypeName
> > }
> >
> > It would be nice to be able to use this "there-and-back-again" 
> > transformation:
> >
> > f(a: .another().back())
> >
> > But it also won't work.
> >
> > I realize that this is a point about minor syntactic efficiency. Yes, you 
> > could simply write:
> >
> > f(a: SomeNontrivialTypeName.another().back())
> >
> > but it's clunky and the type name gets in the way.
> >
> > There's also an element of consistency. Swift already lets us look up 
> > static functions in this way – but:
> >
> > * only functions that return the expected type
> > * and we can't *use* the function result ourselves, it must be immediately 
> > yielded to the parameter or left-hand-side
> >
> > Seems more than a little strange.
> >
> > Anyone else care or have thoughts on this point?
>
> I've also wanted this. It seems like a straightforward extension of the 
> existing feature, which already has to set up a constraint system dependent 
> on the contextual type, but which happens to be artificially constrained to 
> adding only one step of member lookup or of member lookup followed by a call 
> of that member to the system.
>
> -Joe
> ___
> 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] [Review] SE-0168: Multi-Line String Literals

[Jarod Long via swift-evolution]

Thanks Brent, I really appreciate the thoughtful response. Apologies for 
anything I overlooked previously.

I agree with most of your points, although I still find myself preferring the 
common-whitespace logic and leading/trailing newline stripping when considering 
the pros and cons. It doesn't seem likely to gain traction though, so I won't 
spend more time on it.

Thanks again!

Jarod

On Apr 12, 2017, 16:35 -0700, Brent Royal-Gordon <br...@architechies.com>, 
wrote:
> > On Apr 12, 2017, at 11:58 AM, Jarod Long via swift-evolution 
> > <swift-evolution@swift.org> wrote:
> >
> > On a separate note, I'd like to bring up the de-indentation behavior I 
> > described earlier again. I still feel that having the position of the 
> > closing delimiter determine how much whitespace is de-indented is not very 
> > natural or intuitive, since I don't think there is any precedent in 
> > standard Swift styling to indent a closing delimiter to the same level as 
> > its content.
>
> String literal delimiters are very different from other delimiters because 
> they switch the parser into a different mode where characters are interpreted 
> in vastly different ways, and every character has a significant meaning. For 
> instance, it's good practice to put either a space, or a newline and 
> indentation, between array and dictionary literal delimiters or curly 
> brackets and their content, but this is not possible with a string literal 
> because the space would count as part of the content. This is the same way: 
> you can't outdent because whitespace is significant inside a string literal, 
> so it would change the meaning.
>
> I think that this probably seems way weirder on paper than it really is in 
> practice. I recommend that you try it and see how it feels.
>
> > Stripping the most common whitespace possible from each line seems to be a 
> > much more intuitive and flexible solution in terms of formatting, and it's 
> > still compatible with the proposed formatting if that's anyone's preference.
>
> I discuss this at length in the Rationale section for indentation stripping. 
> If you'll forgive me for quoting myself:
>
> > We could instead use an algorithm where the longest common whitespace 
> > prefix is removed from all lines; in well-formed code, that would produce 
> > the same behavior as this algorithm. But when not well-formed—when one line 
> > was accidentally indented less than the delimiter, or when a user mixed 
> > tabs and spaces accidentally—it would lead to valid, but incorrect and 
> > undiagnosable, behavior. For instance, if one line used a tab and other 
> > lines used spaces, Swift would not strip indentation from any of the lines; 
> > if most lines were indented four spaces, but one line was indented three, 
> > Swift would strip three spaces of indentation from all lines. And while you 
> > would still be able to create a string with all lines indented by indenting 
> > the closing delimiter less than the others, many users would never discover 
> > this trick.
> Let me provide an example to illustrate what I'm talking about. Suppose you 
> want to say this:
>
> xml += """\↵
> ↵
> \(author)↵
> \(title)↵
> \(genre)↵
> \(price)↵
> ↵
> """↵
>
> But instead, you miss just one little insignificant character:
>
> xml += """\↵
> ···↵
> \(author)↵
> \(title)↵
> \(genre)↵
> \(price)↵
> ↵
> """↵
>
> This is the kind of mistake you will almost certainly never notice by hand 
> inspection. You probably can't see the mistake without looking very 
> carefully—and this is with invisible whitespace replaced with visible dots! 
> But in the least-common-whitespace design, it's perfectly valid, and 
> generates this:
>
> ↵
> ·\(author)↵
> ·\(title)↵
> ·\(genre)↵
> ·\(price)↵
> ·↵
> ·
>
> That is not what you wanted. I'm pretty sure it's almost *never* what you 
> want. But it's valid, it's going to be accepted, and it's going to affect 
> every single line of the literal in a subtle way. (Plus the next line, thanks 
> to that trailing space!) It's not something we can warn about, either, 
> because it's perfectly valid. To fix it, you'll have to notice it's wrong and 
> then work out why that happened.
>
> In the proposed design, on the other hand, we have a single source of truth 
> for indentation: the last line tells us how much we should remove. That means 
> we can actually c

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

[Jarod Long via swift-evolution]

This is the most logical newline stripping behavior in my opinion. It's very 
easy to think about -- all the lines in-between the triple quotes are the 
contents of the string. Leading and trailing newlines are easily added if 
desired by adding extra lines.

To support that model, I also agree with the suggestion that we shouldn't allow 
multiline string contents on the same line as the opening or closing 
delimiters. They are multiline strings after all, so I don't see much value in 
supporting that.

On a separate note, I'd like to bring up the de-indentation behavior I 
described earlier again. I still feel that having the position of the closing 
delimiter determine how much whitespace is de-indented is not very natural or 
intuitive, since I don't think there is any precedent in standard Swift styling 
to indent a closing delimiter to the same level as its content. Stripping the 
most common whitespace possible from each line seems to be a much more 
intuitive and flexible solution in terms of formatting, and it's still 
compatible with the proposed formatting if that's anyone's preference.

The only functional limitation that I see is that if you can't have leading 
whitespace in the interpreted string if you actually want that. That doesn't 
seem like a very important use case to me, but if we think it is important, it 
could be supported by something like having a backslash in the leading 
whitespace at the location where it should be preserved from.

If we're set on the proposed behavior, have we considered what happens if the 
closing delimiter goes beyond the non-whitespace content of the string?

let string = """
    aa
    bb
    cc
     """

Does it strip the non-whitespace characters? Does it strip up to the 
non-whitespace characters? Does it generate an error?

Jarod

On Apr 12, 2017, 10:41 -0700, Ricardo Parada via swift-evolution 
, wrote:
> Hi all,
>
> I agree as well, I think we should make optimize for the most common case of 
> multi-line strings.  A rule that says strip the first leading newline as well 
> as the trailing newline.  So it's almost back to where Brent started with the 
> addition of removing the trailing newline.
>
> Borrowing Adrian's example, I could just have this:
>
>
> let myReallyLongXMLConstantName = """
>
>
>
>John Doe
>XML Developer's Guide
>Computer
>44.95
>
>
>"""
> If somebody wants the last line to include a newline at the end, they can 
> just add a \n at the end or an empty line.
>
> So if I do this:
>
> print(myReallyLongXMLConstantName)
> print("Text right below")
> It would output this:
>
>  
>  
>      
>          John Doe
>          XML Developer's Guide
>          Computer
>          44.95
>      
>  
> Test right below
>
> Without removing the trailing newline then it would print like this:
>
>  
>  
>      
>          John Doe
>          XML Developer's Guide
>          Computer
>          44.95
>      
>  
>
> Test right below
>
>
>
>
> > On Apr 12, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution 
> >  wrote:
> >
> > Agree. I prefer the new rules over the old, but considering common use 
> > cases, stripping the leading and trailing newline makes for a more pleasant 
> > experience than not stripping either of them.
> >
> > I think that is generally worth prioritizing over a simpler algorithm or 
> > even accommodating more styles. Moreover, a user who wants a trailing or 
> > leading newline merely types an extra one if there is newline stripping, so 
> > no use cases are made difficult, only a very common one is made more 
> > ergonomic.
> > > On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution 
> > >  wrote:
> > > > > Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution 
> > > > > :
> > > > >
> > > > > Hey folks,
> > > > >
> > > > >
> > > > > We've revised the proposal again. The main difference: You no longer 
> > > > > need an initial newline to enable indentation stripping, and 
> > > > > stripping no longer removes that newline even if it is present. 
> > > > > (Adrian Zubarev and I believe some others argued for this.) We
> > > >
> > > > Hmm, not sure if I like these changes. I expect that almost all strings 
> > > > won't begin with a newline and a majority won’t end with a newline. The 
> > > > new design would require a leading backslash almost all the time and a 
> > > > trailing backslash often, which is ugly:
> > > >
> > > > let mystring = "““\
> > > >     text text
> > > >     text text\
> > > >     "““
> > > >
> > > > -Thorsten
> > > >
> > > >
> > > > > disagreed with this at first, but it made more sense as we thought 
> > > > > about it more. There are a few things we like about it:
> > > > >
> > > > >       1. The rules and algorithm are simpler.
> > > > >       2. It accommodates more coding styles.
> > > > 

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

[Jarod Long via swift-evolution]

> • What is your evaluation of the proposal?

I like the feature a lot, but I'm not so sure about the described 
indentation-stripping behavior. I don't think that putting the closing """ at 
the same indentation level as the string's contents is very intuitive. It feels 
a bit like writing this:

if someCondition {
    print("message")
    }

In general, the closing delimiter in a multiline context (for lack of a better 
general term) is indented to the same level as the line that contains the 
opening delimiter, so I think that unless developers are explicitly taught 
otherwise, they would likely default to that style for multiline strings, 
resulting in confusion about why there's an extra level of indentation in the 
interpreted multiline string.

I think what would be more intuitive and stylistically flexible would be to 
strip the largest amount leading whitespace that is common to each line. In 
other words, whichever line(s) that have the least amount of leading whitespace 
would determine the amount of indentation that gets stripped.

Apologies if this approach has been discussed before -- I missed most of the 
discussion that led to the proposal. Any thoughts on this?

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

Yes -- this would be a very useful feature in some situations.

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

I think so.

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

I haven't used this feature enough in other languages to comment here.

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

I read the proposal thoroughly.

Jarod

On Apr 6, 2017, 12:35 -0700, Joe Groff via swift-evolution 
, wrote:
> Hello Swift community,
>
> The review of SE-0168 "Multi-Line String Literals" begins now and runs 
> through April 12, 2017. The proposal is available here:
>
> > https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
>
> > Proposal link:
>
> > > https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>
> > Reply text
> > Other replies
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to 
> Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
>
> More information about the Swift evolution process is available at:
>
> > https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Joe
> Review Manager
> ___
> 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] SE-165: Dictionary & Set Enhancements

[Jarod Long via swift-evolution]

> • What is your evaluation of the proposal?

I think it's great! Enthusiastic +1 from me.

Just an idea -- in addition to `mapValues`, it seems like it would be useful to 
have both a `mapKeys` and plain `map` for key-value pairs. The proposal 
mentions that `map` was omitted because unique keys aren't guaranteed, but it 
seems reasonable to me to trap if duplicate keys are generated during a map, 
similar to how the proposed sequence-based initializer traps on duplicate keys.

I don't think those additions are critical, but they seem nice to me.

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

Yes -- I've struggled with several of the issues that the proposal addresses. 
The specialized map / filter, default subscript values, and merging are 
particularly appealing to me.

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

I think so, since Swift already goes to great lengths to provide a robust 
collection system. This is a logical iteration of that idea.

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

I don't recall any features I've used elsewhere that would be helpful to 
compare to.

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

I didn't follow any discussion that led to the proposal, but I read the whole 
thing.

Jarod

On Apr 5, 2017, 17:45 -0700, Ben Cohen via swift-evolution 
, wrote:
> Hello, Swift community!
>
> The review of "SE-165: Dictionary & Set Enhancements" begins now and runs 
> through next Tuesday, April 11th. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md
>
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
>
> Proposal link:  
> https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md
>
> Reply text
>
> Other replies
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to 
> Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
>
> More information about the Swift evolution process is available at 
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> Ben Cohen
> Review Manager
>
>
> ___
> 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] [Pitch] Add an all algorithm to Sequence

[Jarod Long via swift-evolution]

I don't think an argument label is sufficient to satisfy the first fundamental 
API design guideline: "Clarity at the point of use is your most important goal."

The argument label is not visible at the point of use when using trailing 
closure syntax, so it provides no additional clarity there. Moving the argument 
label into the base method name solves that problem and I think is a clear case 
of satisfying the second fundamental guideline: "Clarity is more important than 
brevity."

Jarod

On Apr 5, 2017, 14:51 -0700, Kevin Nattinger via swift-evolution 
, wrote:
> I definitely think we should stick with `all` and an appropriate argument 
> label. It’s a term of art and the label makes it perfectly clear what to 
> expect.
> That said, `all(match)` and `all(equal)` sound to me like they expect an 
> object to compare each against (func all(equal needle: Element))
> I suggest something like `all(pass:)`.
>
> > On Apr 5, 2017, at 4:34 PM, Brandon Trussell via swift-evolution 
> >  wrote:
> >
> > I retract my gripes on the original names also.  The argument labels make 
> > the intent of the method clear.
> >
> > > On Wed, Apr 5, 2017 at 11:23 AM, Thorsten Seitz via swift-evolution 
> > >  wrote:
> > > > +1
> > > >
> > > > Am 03.04.2017 um 10:29 schrieb Daniel Duan via swift-evolution 
> > > > :
> > > >
> > > > > I want to retract my nitpickings on argument labels; `all(equal:)` 
> > > > > and `all(match:)` are the best names for these methods.
> > > > >
> > > > > things all match condition?
> > > > > things all equal value?
> > > > >
> > > > > If we accept `all` as a term of art (which I think we should), along 
> > > > > with these labels the use site are very readable!
> > > > >
> > > > > > On Mar 31, 2017, at 6:38 PM, Daniel Duan via swift-evolution 
> > > > > >  wrote:
> > > > > >
> > > > > > nit: should these names be `all(matching)`/`all(equalTo)` per API 
> > > > > > Design Guidelines?
> > > > > > > On Mar 31, 2017, at 8:28 AM, Ben Cohen via swift-evolution 
> > > > > > >  wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > A short proposal for you as part of the algorithms theme. 
> > > > > > > Hopefully non-controversial, aside from the naming of the method 
> > > > > > > and arguments, about which controversy abounds. Online copy here: 
> > > > > > > https://github.com/airspeedswift/swift-evolution/blob/9a778e904c9be8a3692edd19bb757b23c54aacbe/proposals/0162-all-algorithm.md
> > > > > > >
> > > > > > >
> > > > > > > Add an all algorithm to Sequence
> > > > > > >
> > > > > > > • Proposal: SE-
> > > > > > > • Authors: Ben Cohen
> > > > > > > • Review Manager: TBD
> > > > > > > • Status: Awaiting review
> > > > > > >
> > > > > > > Introduction
> > > > > > > It is common to want to confirm that every element of a sequence 
> > > > > > > equals a value, or matches a certain criteria. Many 
> > > > > > > implementations of this can be found in use on github. This 
> > > > > > > proposal adds such a method to Sequence.
> > > > > > > Motivation
> > > > > > > You can achieve this in Swift 3 with contains by negating both 
> > > > > > > the criteria and the result:
> > > > > > >
> > > > > > > // every element is 9
> > > > > > > !nums.contains { $0 != 9 }
> > > > > > > // every element is odd
> > > > > > > !nums.contains { !isOdd($0) }
> > > > > > > but these are a readability nightmare. Additionally, developers 
> > > > > > > may not make the leap to realize contains can be used this way, 
> > > > > > > so may hand-roll their own for loop, which could be buggy, or 
> > > > > > > compose other inefficient alternatives:
> > > > > > >
> > > > > > > // misses opportunity to bail early
> > > > > > > nums.reduce(true) { $0.0 && $0.1 == 9 }
> > > > > > > // the most straw-man travesty I could think of...
> > > > > > > Set(nums).count == 1 && Set(nums).first == 9
> > > > > > > Proposed solution
> > > > > > > Introduce two algorithms on Sequence which test every element and 
> > > > > > > return true if they match:
> > > > > > >
> > > > > > > nums.all(equal: 9)
> > > > > > > nums.all(match: isOdd)
> > > > > > > Detailed design
> > > > > ___
> > > > > 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
> > > >
> >
> >
> >
> > --
> > Brandon
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> 

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

[Jarod Long via swift-evolution]

On Apr 5, 2017, 13:21 -0700, Xiaodi Wu <xiaodi...@gmail.com>, wrote:

> On Wed, Apr 5, 2017 at 2:22 PM, Jarod Long via swift-evolution 
> <swift-evolution@swift.org> wrote:
> > > `integers.all { $0.isEven }` reads like an alias of `filter` to me. The 
> > > meaning is ambiguous because the missing argument label can be filled in 
> > > in different ways -- some will read this as "all are even", and others 
> > > will read it as "all that are even".
> > >
> > > I think that ambiguity should be avoided. Something along the lines of 
> > > `integers.allMatch { $0.isEven }` does just that and reads quite nicely 
> > > in my opinion.
> >
> > There is little to stop someone who might interpret "all are even" to mean 
> > "all that are even" also from interpreting "all match" to mean "all that 
> > match."
> >
> > The point of having that gigantic discussion on API guidelines in the past 
> > was to obviate these kinds of discussions. Does the proposed `all(equal:)` 
> > adhere to those guidelines? If so, then the presumption should be that it 
> > achieves the right balance of clarity, concision, readability, etc. If not, 
> > we ought to ask what we need to do to get it into compliance with the 
> > guidelines, or whether a term-of-art exception is called for.

I think "all that match" would be a far less reasonable and common 
interpretation, because if the phrase were to be shortened by removing "that", 
it would then be phrased as "all matching", not "all match".

I don't want to derail the discussion too much regarding the guidelines, but 
I'll say that I think it's unrealistic to expect them to eliminate the need to 
discuss naming. There's a lot of wiggle room within the guidelines, and I think 
it would be a mistake to hastily accept the first name we think of that doesn't 
blatantly violate them. We shouldn't spend be spending weeks upon weeks 
discussing each and every name, but we're well within a reasonable timeframe of 
discussion for this proposal in my opinion.

> > > I also like `integers.containsOnly { $0.isEven }` a lot since it pairs 
> > > nicely with the existing `contains` method.
> > >
> > > Jarod
> > >
> > > On Apr 4, 2017, 02:16 -0700, David Rönnqvist via swift-evolution 
> > > <swift-evolution@swift.org>, wrote:
> > > > I agree that  `all(equal:)` and `all(match:)` are really good names for 
> > > > these methods (I could also consider `every`).
> > > >
> > > > In my understanding of the Swift API Design Guidelines, it’s good for a 
> > > > number of reasons:
> > > >
> > > > It omits needless words. It’s a sequence of Element, so explicitly 
> > > > mentioning “elements”, “members”, or “items" doesn’t add much.
> > > >
> > > > It strives for fluent usage when used with their argument labels. As 
> > > > Daniel Duan pointed out, these names roughly read read as:
> > > >
> > > > > things all match condition?
> > > > > things all equal value?
> > > >
> > > > Without the argument label it’s not as clear what it does, but other 
> > > > functions have a similar problems when used without argument labels. 
> > > > For example,
> > > >
> > > > xs.prefix { $0 > 5 }
> > > > xs.drop { $0 > 5 }
> > > > xs.index { $0 > 5 }
> > > >
> > > > It uses terminology well, if `all` is accepted as a term of art. It is 
> > > > at least a common term in other languages for this functionality.
> > > >
> > > > However, one area where it doesn’t hold as well (ignoring any term of 
> > > > art argument) is that Boolean methods [...] should read as assertions 
> > > > […] when the use is nonmutating. Here I kind of like the `are` prefix, 
> > > > similar to how `empty` has an `is` prefix (isEmpty). In this case I 
> > > > would also like to see the labels change for a more fluent usage: 
> > > > `areAll(equalTo:)` and `areAll(matching:)`.
> > > >
> > > >
> > > > > On 3 Apr 2017, at 10:29, Daniel Duan via swift-evolution 
> > > > > <swift-evolution@swift.org> wrote:
> > > > >
> > > > > I want to retract my nitpickings on argument labels; `all(equal:)` 
> > > > > and `all(match:)` are the best names for these methods.
> > > > >
> > > > > things all match condit

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

[Jarod Long via swift-evolution]

`integers.all { $0.isEven }` reads like an alias of `filter` to me. The meaning 
is ambiguous because the missing argument label can be filled in in different 
ways -- some will read this as "all are even", and others will read it as "all 
that are even".

I think that ambiguity should be avoided. Something along the lines of 
`integers.allMatch { $0.isEven }` does just that and reads quite nicely in my 
opinion. I also like `integers.containsOnly { $0.isEven }` a lot since it pairs 
nicely with the existing `contains` method.

Jarod

On Apr 4, 2017, 02:16 -0700, David Rönnqvist via swift-evolution 
, wrote:
> I agree that  `all(equal:)` and `all(match:)` are really good names for these 
> methods (I could also consider `every`).
>
> In my understanding of the Swift API Design Guidelines, it’s good for a 
> number of reasons:
>
> It omits needless words. It’s a sequence of Element, so explicitly mentioning 
> “elements”, “members”, or “items" doesn’t add much.
>
> It strives for fluent usage when used with their argument labels. As Daniel 
> Duan pointed out, these names roughly read read as:
>
> > things all match condition?
> > things all equal value?
>
> Without the argument label it’s not as clear what it does, but other 
> functions have a similar problems when used without argument labels. For 
> example,
>
> xs.prefix { $0 > 5 }
> xs.drop { $0 > 5 }
> xs.index { $0 > 5 }
>
> It uses terminology well, if `all` is accepted as a term of art. It is at 
> least a common term in other languages for this functionality.
>
> However, one area where it doesn’t hold as well (ignoring any term of art 
> argument) is that Boolean methods [...] should read as assertions […] when 
> the use is nonmutating. Here I kind of like the `are` prefix, similar to how 
> `empty` has an `is` prefix (isEmpty). In this case I would also like to see 
> the labels change for a more fluent usage: `areAll(equalTo:)` and 
> `areAll(matching:)`.
>
>
> > On 3 Apr 2017, at 10:29, Daniel Duan via swift-evolution 
> >  wrote:
> >
> > I want to retract my nitpickings on argument labels; `all(equal:)` and 
> > `all(match:)` are the best names for these methods.
> >
> > things all match condition?
> > things all equal value?
> >
> > If we accept `all` as a term of art (which I think we should), along with 
> > these labels the use site are very readable!
> >
> > > On Mar 31, 2017, at 6:38 PM, Daniel Duan via swift-evolution 
> > >  wrote:
> > >
> > > nit: should these names be `all(matching)`/`all(equalTo)` per API Design 
> > > Guidelines?
> > > > On Mar 31, 2017, at 8:28 AM, Ben Cohen via swift-evolution 
> > > >  wrote:
> > > >
> > > > Hi,
> > > >
> > > > A short proposal for you as part of the algorithms theme. Hopefully 
> > > > non-controversial, aside from the naming of the method and arguments, 
> > > > about which controversy abounds. Online copy here: 
> > > > https://github.com/airspeedswift/swift-evolution/blob/9a778e904c9be8a3692edd19bb757b23c54aacbe/proposals/0162-all-algorithm.md
> > > >
> > > >
> > > > Add an all algorithm to Sequence
> > > >
> > > > • Proposal: SE-
> > > > • Authors: Ben Cohen
> > > > • Review Manager: TBD
> > > > • Status: Awaiting review
> > > >
> > > > Introduction
> > > > It is common to want to confirm that every element of a sequence equals 
> > > > a value, or matches a certain criteria. Many implementations of this 
> > > > can be found in use on github. This proposal adds such a method to 
> > > > Sequence.
> > > > Motivation
> > > > You can achieve this in Swift 3 with contains by negating both the 
> > > > criteria and the result:
> > > >
> > > > // every element is 9
> > > > !nums.contains { $0 != 9 }
> > > > // every element is odd
> > > > !nums.contains { !isOdd($0) }
> > > > but these are a readability nightmare. Additionally, developers may not 
> > > > make the leap to realize contains can be used this way, so may 
> > > > hand-roll their own for loop, which could be buggy, or compose other 
> > > > inefficient alternatives:
> > > >
> > > > // misses opportunity to bail early
> > > > nums.reduce(true) { $0.0 && $0.1 == 9 }
> > > > // the most straw-man travesty I could think of...
> > > > Set(nums).count == 1 && Set(nums).first == 9
> > > > Proposed solution
> > > > Introduce two algorithms on Sequence which test every element and 
> > > > return true if they match:
> > > >
> > > > nums.all(equal: 9)
> > > > nums.all(match: isOdd)
> > > > Detailed design
> > > > Add the following extensions to Sequence:
> > > >
> > > > extension Sequence {
> > > > /// Returns a Boolean value indicating whether every element of the 
> > > > sequence
> > > > /// satisfies the given predicate.
> > > > func all(match criteria: (Iterator.Element) throws -> Bool) rethrows -> 
> > > > Bool
> > > > }
> > > >
> > > > extension Sequence where Iterator.Element: Equatable {
> > > > /// Returns a Boolean 

Re: [swift-evolution] Type-based ‘private’ access within a file

[Jarod Long via swift-evolution]

Pretty bummed out about the rejection. I know it's a petty aesthetic issue, but 
thinking about having to write "fileprivate" 5 or 10 years from now kills more 
of my enthusiasm about using the language than I'd like to admit. I think it's 
going to always be viewed by most as a major wart on an otherwise great 
language. Hopefully we can be more careful in the future about letting this 
sort of thing get through in the first place.

All that said, I'll support a proposal along the lines of what's being 
suggested.

Jarod

> On Apr 3, 2017, at 12:34 PM, Douglas Gregor via swift-evolution 
>  wrote:
>
> Hello Swift Community,
>
> In rejecting SE-0159, the core team described a potential direction we would 
> like to investigate for “private” access control that admits a limited form 
> of type-based access control within files. The core team is seeking some 
> discussion here and a motivated volunteer to put together a proposal along 
> these lines for review in the Swift 4 time-frame (i.e., very soon). To be 
> clear, the core team it’s sure this is the right direction to go… but it 
> appears promising and we would *love* to be able to settle the access-control 
> issue.
>
> The design, specifically, is that a “private” member declared within a type 
> “X” or an extension thereof would be accessible from:
>
> * An extension of “X” in the same file
> * The definition of “X”, if it occurs in the same file
> * A nested type (or extension thereof) of one of the above that occurs in the 
> same file
>
> This design has a number of apparent benefits:
> + “private” becomes the right default for “less than whole module” 
> visibility, and aligns well with Swift coding style that divides a type’s 
> definition into a number of extensions.
> + “fileprivate” remains for existing use cases, but now it’s use it more 
> rare, which has several advantages:
> + It fits well with the "progressive disclosure” philosophy behind Swift: you 
> can use public/internal/private for a while before encountering and having to 
> learn about “fileprivate”   (note: we thought this was going to be true of 
> SE-0025, but we were clearly wrong)
> + When “fileprivate” occurs, it means there’s some interesting coupling 
> between different types in the same file. That makes fileprivate a useful 
> alert to the reader rather than, potentially, something that we routinely use 
> and overlook so that we can separate implementations into extensions.
> + “private” is more closely aligned with other programming languages that use 
> type-based access control, which can help programmers just coming to Swift. 
> When they reach for “private”, they’re likely to get something similar to 
> what they expect—with a little Swift twist due to Swift’s heavy use of 
> extensions.
> + Loosening the access restrictions on “private” is unlikely to break 
> existing code.
>
> There are likely some drawbacks:
> - Developers using patterns that depend on the existing lexically-scoped 
> access control of “private” may find this new interpretation of “private” to 
> be insufficiently strict
> - Swift’s access control would go from “entirely lexical” to “partly lexical 
> and partly type-based”, which can be viewed as being more complicated
>
> Thoughts? Volunteer?
>
> - Doug
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Jarod Long via swift-evolution]

Given that this is such a divisive issue, I'd like to see a revised version of 
this proposal that renames fileprivate back to private but maintains scoped 
access control under a different name like "scoped", as has been suggested. 
That seems like the best compromise -- those that want scoped access control 
can continue to use it, and those that don't can go back to using private.

Jarod

> Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reply text
> Other replies
> What
>  goes into a review?
>
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
>
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md Thank you,
>
> -Doug
>
> Review Manager


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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jarod Long via swift-evolution]

>
> • What is your evaluation of the proposal?
>
I think it could stand to make a bit of a stronger case, but I am strongly in 
favor of the outcome. The introduction of fileprivate was disappointing to me 
when it happened, and I've yet to encounter a situation where it has been 
beneficial, but it has often been frustrating.

>
> • Is the problem being addressed significant enough to warrant a change to 
> Swift?
>
I think so -- I believe that it's very important for this sort of fundamental 
language feature to be simple and pleasant to use. The tradeoffs that 
fileprivate makes in that regard feel pretty significant to me, and I don't 
think the additional level of control is of much benefit.

I would go as far as to say that scoped access control is harmful in that it 
promotes bad programming practices. If your file is large enough that there is 
value in protecting yourself from accessing certain parts of it, that file is 
almost certainly excessively large and difficult to follow.

>
> • Does this proposal fit well with the feel and direction of Swift?
>
I believe that it does to the extent that Swift strives to avoid overburdening 
its users with low-value features.

>
> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
>
I used Swift prior to version 3, and I strongly preferred the previous access 
control model.

>
> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
>
I read the proposal fully and have been casually following much of the 
discussion on this topic.

Jarod


On Mar 20, 2017, 16:54 -0700, Douglas Gregor via swift-evolution , wrote:
> Hello Swift community,
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> > https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> > Proposal link:
> > > https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> > Reply text
> > > Other replies
> What goes into a review?
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to 
> Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
>
> More information about the Swift evolution process is available at
> > https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> -Doug
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jarod Long via swift-evolution]

Another +1 for Discourse. I'd like to participate more, but the mailing list 
format is difficult for me to use.

I've gone through three email clients since swift-evolution started (Apple 
Mail, then Airmail, and now Spark), and they work well enough for general, 
simple email usage, but the mailing list experience has been poor enough to 
discourage me from participating. Threads get split all the time -- right now I 
see four separate threads for the "Strings in Swift 4" discussion. I'd need to 
click around each of them to get the entire discussion and piece together the 
chronology manually, and if I want to participate I need to somehow determine 
which thread is the correct one to reply to.

I appreciate the philosophy of the mailing list, but I really think that forum 
software would work much better from a practical standpoint.

I think a chat service like Slack could be useful as well, but not as a 
replacement for something like a forum. A forum works much better for 
long-form, asynchronous discussions.

Jarod

On Jan 23, 2017, 09:59 -0800, Joshua Alvarado via swift-evolution 
, wrote:
> It will be painted! ;)
>
> So far we have:
> +2 Disclosure
> +1 Slack
> +1 Issue tracker
>
> Let's really get everyone's opinions and see if we can get this rock rolling 
> towards a better solution. Of course it will be Apple's choice in the end but 
> we can give a voice on the matter to show we do care about moving over.
>
> Alvarado, Joshua
>
> On Jan 23, 2017, at 10:55 AM, David Waite  
> wrote:
>
> > As long as we are pretending this bike shed is getting painted again…
> >
> > I would actually prefer something closer to an issue tracker than 
> > discourse. We get a lot of repeat and diverging topics, and it would be 
> > nice to mark discussions as related, duplicates, etc
> >
> > -DW
> >
> > > On Jan 23, 2017, at 9:22 AM, Adrian Zubarev via swift-evolution 
> > >  wrote:
> > >
> > > +1 for Discourse. Cannot wait any longer for this to happen.
> > >
> > >
> > >
> > > --
> > > Adrian Zubarev
> > > Sent with Airmail
> > >
> > > Am 23. Januar 2017 um 17:18:42, Joshua Alvarado via swift-evolution 
> > > (swift-evolution@swift.org) schrieb:
> > > > Hey swifters,
> > > >   I would like to (re)open up discussion on moving away from email for 
> > > > the swift evolution mailing list. I know this has probably been 
> > > > discussed before but it really should be addressed again. I wouldn't 
> > > > even know how to find if it has been discussed before because it would 
> > > > be too hard to go back through the history.
> > > >
> > > > The main factors to move away from email is because email may deter 
> > > > newcomers, history, and threads. I may be speaking for myself when 
> > > > saying email may intimidate newcomers from expressing their opinions 
> > > > and thoughts. It is hard to know what has already been discussed and 
> > > > who is even in the active conversation. Keeping track of history is a 
> > > > pain as well. Searching through many emails to find who said what and 
> > > > when is not effective in email clients. Also, code formatting in emails 
> > > > is not effective. Let's discuss and actually make an action to move 
> > > > away from email if the community so agrees. Of course, recommendations 
> > > > are Slack, Hipchat (-1), and Gitter.
> > > >
> > > > --
> > > > Joshua Alvarado
> > > > alvaradojosh...@gmail.com
> > > > ___
> > > > swift-evolution mailing list
> > > > swift-evolution@swift.org
> > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> ___
> 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