Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Patrick Smith via swift-evolution]

I too find the backslash odd, as it’s usually of course used to escape
something.

What about three periods?

let firstFriendsNameKeyPath = Person...friends[0].name
print(luke[keyPath: ...friends[0].name])


I also find wanting to use the same syntax for unapplied methods strange,
as they would product two totally different things: one a key path value,
the other a function.

Patrick
On Thu, 6 Apr 2017 at 10:00 am, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

> On Apr 5, 2017, at 4:55 PM, Colin Barrett 
> wrote:
>
> Is the choice of backslash up for review? I think another operator,
>
>
> We talked through basically everything on the keyboard, and there really
> aren’t other options that don’t stomp on existing behavior.
>
> perhaps backtick (`), would work better.
>
>
> Backtick (`) is already taken for escaping identifiers, e.g.,
>
> var `func` = { /* some code */ }
>
> - 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] [Accepted] SE-0121: Remove Optional Comparison Operators

[Patrick Smith via swift-evolution]

A little nicer I think is:

if request?.httpVersion.map({ $0 < HTTPVersion(1.0) }) ?? true {

It’s very explicit what the fallback is too, the original’s ambiguity makes me 
uncomfortable.

BTW, did you want to be checking for <= 1.0? With HTTP 1.0, it’s opt in. 
https://en.wikipedia.org/wiki/HTTP_persistent_connection

Patrick

> On 28 Aug 2016, at 1:20 PM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> As for optional comparisons making the code cleaner, I end up using them all 
> over the place. The case that motivated my email looked something along the 
> lines of
> 
>  if request?.httpVersion < HTTPVersion(1.0) {
>// no keepalive
>disconnect()
>  }
> 
> This particular case could be trivially replaced with
> 
>  if request.map({ $0.httpVersion < HTTPVersion(1.0) }) ?? true {
> 
> but it’s uglier and harder to read.

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

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

[Patrick Smith via swift-evolution]

Hi Brent,

Will an IncompleteRange always be able to be translated into the same concrete 
Range? i.e., the missing bound is just a stand in for startIndex or endIndex 
right? It seems unfortunate to have this throw away value that is only used as 
an intermediary. Especially when Collection already has an intermediary in the 
form of Index.


What if instead, you ask a collection for a prefix or suffix range from an 
index?

c.indexes(preceding: Index, inclusive: Bool)
c.indexes(succeeding: Index, inclusive: Bool)

These then return a Range or ClosedRange. This I believe would resolve the 
‘suffix’ naming issue you have highlighted here, as instead of asking for a 
suffix from the *collection*, you are asking the all successors of an *index*.


Then subscripts are also added to retrieve slices. The subscripts already infer 
the use of indexes, so there is no need to add additional words here.

c[preceding: Index, inclusive: Bool]
c[succeeding: Index, inclusive: Bool]

This is a variation of your proposed conservative index-based operation.


Also, for the removing- base operations:

c[withoutPreceding: Index, inclusive: Bool]
c[withoutSucceeding: Index, inclusive: Bool]

c.remove(preceding: Index, inclusive: Bool)
c.remove(succeeding: Index, inclusive: Bool)


I think the words ‘preceding’ and ‘succeeding’ fit in well with the concept of 
‘earliest’ and ‘latest’. Note I originally tried writing without the additional 
‘inclusive’ parameter until I realised succeeding would have to be inclusive 
for the current suffix behaviour. It appears to make the API more complicated, 
but it may help to be more explicit wrt index inclusiveness that simple prefix 
and suffix methods ignore, and also the use of indexes instead of distances (or 
perhaps iteration counts?).


Hope some of this is useful! (I might be completely missing the mark)

Patrick


> On 28 Jun 2016, at 9:46 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Addressing the same issue from several people:
> 
>> On Jun 23, 2016, at 11:28 AM, David Hart  wrote:
>> 
>> I’m not a fan of the subscript solutions. They both introduce new types 
>> which seems very heavyweight for such a small use case. I’d vote for keeping 
>> the current functions.
> 
>> On Jun 23, 2016, at 10:46 PM, Xiaodi Wu  wrote:
>> 
>> Ditto, not a fan of a subscript solution here. It is true that 
>> `suffix(from:)` seems weird at first, but it is literally nonsensical to 
>> interpret the single argument any other way, partly because of the mandatory 
>> argument label but mostly because a "suffix" that doesn't go to the end 
>> isn't a suffix.
> 
> 
>> On Jun 23, 2016, at 1:06 PM, Anton Zhilin via swift-evolution 
>>  wrote:
>> 
>> -1, because [separate point snipped] they match the 
>> theme you are proposing, while subscripts do not.
> 
> Superficially, `prefix(upTo:)`, `prefix(through:)` and `suffix(from:)` appear 
> to be prefix and suffix operations, but I think that's actually a poor way to 
> model them.
> 
> The problem is most obvious when you look at `suffix(from:)`. Imagine you 
> have a four-element array:
> 
>   Elements:   a   b   c   d
>   Indices:[0] [1] [2] [3]
> 
> `prefix(2)` and `suffix(2)` will select the first and last two elements, 
> respectively.
> 
>   Elements:   a   b   c   d
>   Indices:[0] [1] [2] [3]
>   prefix(2)   ^^  ^^
>   suffix(2)   ^^  ^^
> 
> And for a four-element array, so will `prefix(upTo:)` and `suffix(from:)`.
> 
>   Elements:   a   b   c   d
>   Indices:[0] [1] [2] [3]
>   prefix(2)   ^^  ^^
> upTo: 2   ^^  ^^
>   suffix(2)   ^^  ^^
> from: 2   ^^  ^^
> 
> However, if you insert an element in the middle of the array, a funny thing 
> happens:
> 
>   Elements:   a   b   c   e   d
>   Indices:[0] [1] [2] [3] [4]
>   prefix(2)   ^^  ^^
> upTo: 2   ^^  ^^
>   suffix(2)   ^^  ^^
> from: 2   ^^  ^^  ^^
> 
> Unlike the other methods, adding additional elements changed the length of 
> `suffix(from:)`'s return value. That indicates to me that it is *not* a 
> suffix operation at all.
> 
> Now, the simplest way to resolve this is to say that `suffix(from:)` is 
> actually misnamed; it should be `removingPrefix(upTo:)`. That will work for 
> arrays, but not necessarily for other collections.
> 
> For instance, I've sketched a LinkedList type here: 
>  The 
> 

Re: [swift-evolution] Stdlib closure argument labels and parameter names

[Patrick Smith via swift-evolution]

Side question: is there going to be any situation where I’m iterating through a 
sequence/collection that I wouldn’t want to always use `lazy`? Is `lazy` 
*always* going to be more efficient than the array-creating defaults when the 
result is iterated?

For instance, something much better than this terrible syntax:

for a in sequence where .filter({ $0 > 5 }).map({ $0 * 2 })  {
  print(a)
}

It would be up to the compiler what calls it turns that into, possibly it could 
make a certain whitelist of transformations (filter, map) as efficient as using 
`for … where` or `guard` today? Or it could simply make use of `lazy`.

`for` is already hiding ‘magic’ by calling `makeIterator()`, why can’t it do 
more ‘magic’, especially since `lazy` is a member of `Sequence` just like 
`makeIterator()`.

Anyway, something for the future after Swift 3.0.

Patrick

> On 28 Jun 2016, at 1:58 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Yeah, kicking myself over that. Can't Swift remind me to add `lazy` 
> by emitting a warning or something? I keep assuming certain things are
> naturally lazy and then have to go back and de-eagerize.

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

Re: [swift-evolution] [Discussion] Terms of Art Swiftification

[Patrick Smith via swift-evolution]

I liked Brent Royal-Gordon’s suggestion of `every(where:)`. Select is too 
abstract and SQLish, whereas ‘every’ is a basic english word that would look 
familiar in a Swift Playground.

Or `where(_:)` I could live with.

Patrick

> On 28 Jun 2016, at 5:31 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Under consideration is the resolution that  "some terms of art while 
> appropriate to many FP languages, may be better served by using Swift names."
> 
> Consider, for example, `filter(_:)`. Sean Heber writes,
> 
>> Just tossing my vote in the hat for renaming .filter() to something like 
>> .select() since that better matches what it does, IMO. “Filter” is almost 
>> like the opposite word from what it should be since the closure returning 
>> true is what decides what is included in the results, not what is filtered 
>> *from* the results. I mean, yeah, I can kind of understand the logic either 
>> way, but it’s always been one of those strange mental gymnastics things."
> 
> 
> When asked "Shouldn't there be a term of art exemption for `filter(_:)`. 
> Otherwise why not use `select(where:)`," Dave Abrahams replies:
> 
>> Because `where(...)` is better.
> 
> 
> Have at it.
> 
> -- E
> 
> ___
> 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] Remove destructive consumption from Sequence

[Patrick Smith via swift-evolution]

There’s a great discussion going on here, and I don’t mean to distract. But I 
want to ask: to get an infinite sequence using the Swift standard library, 
you’re going to have to create one yourself, say using the new `sequence()` 
functions? There’s nothing built in that is already infinite, so people will 
know what they are creating, that’s the explicit step, and there’s no need to 
have safety to infinitely loop over something. And if someone accidentally 
creates an unwanted infinite loop, that’s a fix in the creation of the 
sequence, not in its looping.

Patrick

> On 23 Jun 2016, at 11:12 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> Sure, it’s not wrong in the sense that sometimes an infinite loop is valid.  
> But I think it would almost always be wrong (an accident) in practice.  If 
> you really want to loop over an infinite sequence maybe it’s a good thing to 
> require you to do that explicitly.

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

Re: [swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops

[Patrick Smith via swift-evolution]

Yes, I’m all for removing this syntax which seems to confuse people with what 
it actually does. Having to write more explicit code with a `guard` or 
`.filter` is better than people unexpectedly creating bugs.

I’d say remove it for Swift 3, allowing a potential replacement for this 
functionality to be an addition and not a breaking change. It’s kind of like 
pruning a tree back to prepare it for new growth.

(I like Xiaodi’s suggestion of replacing `where` with `if`, but I imagine that 
would be a separate proposal, but interested in hear other’s thoughts on it, 
although I’ve probably missed some in the discussion.)

Patrick

> On 23 Jun 2016, at 2:12 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0105: Removing Where Clauses from For-In Loops" begins now 
> and runs through June 29. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.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.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> 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] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

[Patrick Smith via swift-evolution]

+1 to MemoryLayout, as I do like how it is namespaced under one type, which 
allows straight forward looking up of documentation. Writers from C or other 
sizeof() languages will able to see all available methods, allowing them to be 
educated to say not go for size but interval/spacing as the better choice.

Patrick

> On 22 Jun 2016, at 10:26 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 21, 2016, at 6:06 PM, Dave Abrahams > > wrote:
>> 
>> It's just that I don't think this part of the library API is important
>> enough, to enough people, that this readability is worth the additional
>> exposed surface area (and further exposure later on—I can easily imagine
>> a “minimumAlignment”).  I would *much* rather keep this stuff corralled
>> in a single namespace where it can all be found.
> 
> See? That, I totally get.
> 
>> I think you represented it just fine, thanks... I just don't think
>> you're accounting for the big picture.  These APIs are not like “map,”
>> “filter,” and “Dictionary.”  They're specialty items that you should
>> only reach for when performing unsafe operations, mostly inside the guts
>> of higher-level constructs.
>> 
>> -- 
>> Dave
> 
> Would you like me to edit it and flip the proposal then? Put the MemoryLayout 
> in as primary,
> mine as secondary, and add in text to explain that the motivation is less 
> usability than serving
> an unsafe API with minimal surface area?
> 
> -- E
> 
> ___
> 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] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

[Patrick Smith via swift-evolution]

> On 17 Jun 2016, at 8:21 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> map   => mapped
>> flatMap   => flatMapped 
>> filter=> filtered
>> reduce=> reduced
> 
> You posted before I finished responding to this on the other thread, so I 
> guess I'll do it here.
> 
> You're right that renaming these operations wouldn't be terrible. But I think 
> they're easily distinguishable from things like `dropFirst`, and 
> distinguishable in a way that tilts rather strongly towards leaving these 
> as-is.
> 
> `map`, `filter`, and `reduce` are *the* higher-order functions. Almost 
> anything with any kind of block/lambda/closure feature supports them (I'm 
> giving the side-eye to Foundation here), and all three names are backed by 
> *very* strong conventions:
> 
> * `map` is by far the strongest. It is universally supported among languages 
> with higher-order collection operations, and is almost always called `map`. 
> In Wikipedia's list of 32 languages with a `map` 
> ,
>  we find (grouping together similar names like `map` and `maplist`, and 
> double-counting languages with several aliases):
> 
>   Map: 19
>   Collect: 3
>   Apply: 3
>   Special syntax: 2
>   Select: 1 (C#, which uses it in the SQL-inspired LINQ)
>   Transform: 1 (C++, which uses a bizarre signature involving an out 
> parameter)
>   ForEach: 1 (XPath)
> 
> * `filter` is supported nearly as widely as `map`, and the name `filter` is 
> used nearly as consistently as `map`. Wikipedia lists 27 languages supporting 
> a `filter`-style function, and `filter` is by far the most common choice, 
> arguably favored even more consistently than `map` 
> :
> 
>   Filter: 17
>   Select: 4
>   Special syntax: 3
>   FilteredArrayUsingPredicate: 1 (Foundation, doesn't actually take a 
> closure)
>   Where: 1 (C#, in LINQ)
>   CopyIf: 1 (C++, bizarre signature)
>   FindAll: 1
>   Grep: 1
>   RemoveIfNot: 1
> 
> * `reduce` is extremely popular among functional languages because it's a 
> primitive list-handling operation, although it's a little less common among 
> mainstream languages than the other two. It *does* actually have an alternate 
> name, `fold`, which is nearly as common as `reduce`. However, languages using 
> `fold` are usually those which support both leftward- and rightward-reducing 
> versions of the operation, whereas languages using `reduce` usually don't. 
> Swift falls into the second camp. From Wikipedia's 39-language list 
> :
> 
>   Reduce: 20  (with both left and right: 4)
>   Fold: 18(with both left and right: 12)
>   Inject: 3
>   Special syntax: 3
>   Aggregate: 1 (C#, in LINQ)
>   Accumulate: 1 (C++, bizarre signature)
>   Partition: 1
>   ToIterator: 1
> 
> (Note that, although I *would* have counted the -ed or -ing forms of these 
> names with the originals, I don't believe I saw any.)

Great research. Thanks for doing this.

> 
> Another illustration of the strength of these names: Google named a 
> distributed computing project MapReduce, and everyone basically understood 
> what it meant.
> 
> If `map`, `filter`, and `reduce` are not covered by the term-of-art rule, we 
> might as well rename it to the sin()-and-Int rule, because I don't know what 
> else it would cover. There is remarkable consistency in the naming of these 
> operations across dozens of languages.
> 
> (Incidentally, I think if we *do* decide to rename the main higher-order list 
> APIs, they would be better named as `mapping(to:)`, `flatMapping(to:)`, 
> `filtering(by:)`, and `reducing(from:with:)`. Unlike `sorted`, the parameters 
> are mandatory and deeply necessary to understand what the call does, so they 
> deserve grammatical labels. Grammatical labels usually imply -ing form, not 
> -ed form. If we want to address Dave's complaint about the ambiguity of 
> `filter`, we might rename that to `selecting(where:)`, which is crystal clear 
> about whether it keeps the true elements or the false ones.)

It would seem strange in one way to get rid of such strong terms of art (and 
also since they are nice and short, they are easy to glance at), but it also 
seems very inconsistent to keep them. These are methods that will be used by 
new programmers to Swift, so is it better to keep the existing terms or to 
modify them?

Say my type has a method filtered(with: Author), is it then strange that I am 
changing tense within the method’s implementation?

filtered(with author: Author) -> [Item] {
  return items.filter{ $0.author == author }
}

Would it not make more sense to write?

filtered(with author: Author) -> [Item] {
  return items.filtered(where: { $0.author == author })
}

> 
>> dropFirst => 

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

[Patrick Smith via swift-evolution]

I’m not really interested in a really rich language, just the most simple thing 
possible that lets me create rich apps. I like Vladimir’s description of there 
being more when you need it.

(I guess what I am concerned about is complexity as a writer. I want everything 
to be as consistent and logical as possible. I don’t really want any situations 
as a writer where I’m like ‘now hang on, this follows these particular rules’, 
or ‘this is this particular edge case’. I guess I’m a little worried about the 
piecemeal nature of the evolution process. Sometimes I think the way Apple 
works is so great since that they ‘marinate’ things for so long (e.g. Siri 
capabilities), they allow it internally to be discussed and prototyped and be 
released when it’s ready and not sooner.)

Patrick

> On 16 Jun 2016, at 1:42 AM, L. Mihalkovic <laurent.mihalko...@gmail.com> 
> wrote:
> 
> 
> On Jun 15, 2016, at 5:04 PM, Austin Zheng <austinzh...@gmail.com 
> <mailto:austinzh...@gmail.com>> wrote:
> 
>> 
>>> On Jun 14, 2016, at 7:12 AM, L. Mihalkovic via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>> On Jun 14, 2016, at 11:31 AM, Patrick Smith via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> Thanks Xiaodi. Interesting arguments there. It possibly seems a shame to 
>>>> me, because it has knock on effects of making other things more 
>>>> complicated. But I do see how for the most simple case of unwrapping a 
>>>> single Optional, it makes sense.
>>>> 
>>>> As much as I would like Brent’s proposal to make things easier to type, I 
>>>> think nesting things inside a tuple, where a reader must keep track of 
>>>> which input matches which output, could lead to harder to follow code.
>>> 
>>> Isomehow I think last yesterday's keynote should recast some expectations 
>>> about the degree of complexity (richness) the language will ever reach... 
>>> Somehow xamarin/c# might endupmbeing swift++ for many people
>> 
>> How so? What proposals might the core team accept that would confirm your 
>> suspicions; would this be one of them? Maybe I should drop Swift and move to 
>> C#, if that language is going to end up so much better than Swift in the 
>> future. It's never good to be tied down to a single language.
> 
> I think it is non-disputable that objc is a very simple language when 
> compared to more recent languages. Today swift is capable of doing a lot of 
> things, while still being a simpler language than older ones. Si the question 
> for some people might be how much richer will swift become? Will it rival 
> scala's type system? Will it rival java/scala/kotlin/ceylon/c++ for the 
> ability to organize large codebases? Will it have the runtime/compile time 
> code fluidity of D? Etc.. The only way to find out is ... there is none. So 
> then who is swift for? Apple wants it usable by people off the street... not 
> people with a degree in computer science, but the people who may one day get 
> a degree or not. So i wonder this plus the fact that objc was enough for so 
> many years doesn't  simply mean that there is already a cap on the 
> sophistication swift will ever get!!! that they will touch everything around 
> it, before they push it. Today i have a degree of expressiveness with c# that 
> i cannot have with swift, is the gap going to increase of decrease? That is 
> what i care to know about before I advise large corps to invest in swift or 
> not. bored/curious devs (i included) will always easily pick it up, but 
> should i advise a CTO to invest on it... 

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

Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding

[Patrick Smith via swift-evolution]

Thanks Xiaodi. Interesting arguments there. It possibly seems a shame to me, 
because it has knock on effects of making other things more complicated. But I 
do see how for the most simple case of unwrapping a single Optional, it makes 
sense.

As much as I would like Brent’s proposal to make things easier to type, I think 
nesting things inside a tuple, where a reader must keep track of which input 
matches which output, could lead to harder to follow code.

In my own code I will probably stick to using the long form `guard let a = 
opt1, let b = opt2, let c = opt3 else { … }`, not because I would like typing 
it, but because it will be the most clear.

I would have loved for SE-0099 to have gone with semicolon/newline separators 
so I could write it like this, but alas:

guard
  let a = opt1
  let b = opt2
  let c = opt3
else {
  …
}


A different thought — maybe if Xcode had autocompletion to unwrap Optionals 
when inside an `if` or `guard` statement it would make things a lot easier. 
Just type the full name of the optional, then press escape, and then code will 
be suggested to unwrap it. Is the pain this proposal targets mainly in the 
writing more than reading?


guard opt·|·


guard let <#placeholder#> = opt1


guard let a = opt1


guard let a = opt1, opt2·|·


guard let a = opt1, let <#placeholder#> = opt2


guard let a = opt1, let b = opt2



Patrick

> On 14 Jun 2016, at 2:07 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> Also, see: 
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md 
> <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>
> 
> 
> On Mon, Jun 13, 2016 at 11:06 PM, Xiaodi Wu <xiaodi...@gmail.com 
> <mailto:xiaodi...@gmail.com>> wrote:
> This has been suggested before, I believe. The core team has weighed in 
> several times; it seemed like there was some disagreement amongst them 
> whether the current syntax is the wisest, but the concluding statement seemed 
> uncontroversial: "I don't think it's something we can change."
> 
> Source:
> http://article.gmane.org/gmane.comp.lang.swift.evolution/15879/ 
> <http://article.gmane.org/gmane.comp.lang.swift.evolution/15879/>
> 
> 
> On Mon, Jun 13, 2016 at 10:32 PM, Patrick Smith via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> If Pyry’s suggestion remained the preferred way of unwrapping a tuple, could 
> it also become the only way for unwrapping a single item?
> 
> guard case let a? = opt1 {
> ...
> }
> 
> Or even shortened for matching optionals only:
> 
> guard let a? = opt1 {
> ...
> }
> 
> Or even as has often been requested, to keep the same name:
> 
> guard let opt1? {
> ...
> }
> 
> Multiples:
> 
> guard let (opt1?, opt2?, opt3?) {
> ...
> }
> 
> guard let (a?, b?, c?) = (opt1, opt2, opt3) {
> ...
> }
> 
> Sorry, not trying to derail, but it always has seemed like something shorter 
> and more self explanatory could be made for optionals. `?` in pattern 
> matching is a special syntax anyway, so why not make this common use case 
> easier?
> 
> Patrick
> 
> _
> From: Pyry Jahkola via swift-evolution <swift-evolution@swift.org 
> <mailto:swift-evolution@swift.org>>
> Sent: Sunday, June 12, 2016 10:04 PM
> Subject: Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding
> To: Brent Royal-Gordon <br...@architechies.com 
> <mailto:br...@architechies.com>>
> Cc: swift-evolution List <swift-evolution@swift.org 
> <mailto:swift-evolution@swift.org>>
> 
> 
> 
> 
> On 12 Jun 2016, at 14:46, Brent Royal-Gordon via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
> guard let (a, b, c) = (opt1, opt2, opt3) else { ... }
> 
> You mention `guard case` in the motivation, but I think for the uninitiated 
> reader it would be fair to point out that the following example already works 
> equivalently, with only a few extra characters:
> 
> guard case let (a?, b?, c?) = (opt1, opt2, opt3) else { ... }
> 
> Aside of that, it's yet more magic to our `if let` syntax but I don't mind, 
> it would be useful at times.
> 
> — Pyry
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <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] [Draft] Tuple-Based Compound Optional Binding

[Patrick Smith via swift-evolution]

If Pyry’s suggestion remained the preferred way of unwrapping a tuple, could it 
also become the only way for unwrapping a single item?

guard case let a? = opt1 {...}
Or even shortened for matching optionals only:

guard let a? = opt1 {...}
Or even as has often been requested, to keep the same name:
guard let opt1? {...}
Multiples:
guard let (opt1?, opt2?, opt3?) {...}
guard let (a?, b?, c?) = (opt1, opt2, opt3) {...}
Sorry, not trying to derail, but it always has seemed like something shorter 
and more self explanatory could be made for optionals. `?` in pattern matching 
is a special syntax anyway, so why not make this common use case easier?

Patrick

_
From: Pyry Jahkola via swift-evolution 
Sent: Sunday, June 12, 2016 10:04 PM
Subject: Re: [swift-evolution] [Draft] Tuple-Based Compound Optional Binding
To: Brent Royal-Gordon 
Cc: swift-evolution List 



On 12 Jun 2016, at 14:46, Brent Royal-Gordon via swift-evolution 
 wrote:
guard let (a, b, c) = (opt1, opt2, opt3) else { ... }
You mention `guard case` in the motivation, but I think for the uninitiated 
reader it would be fair to point out that the following example already works 
equivalently, with only a few extra characters:
guard case let (a?, b?, c?) = (opt1, opt2, opt3) else { ... }
Aside of that, it's yet more magic to our `if let` syntax but I don't mind, it 
would be useful at times.
— Pyry



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

Re: [swift-evolution] Sketch: Teach init a 'defer'-like ability to deinit

[Patrick Smith via swift-evolution]

I like the idea, I don’t like the potential to capture anything else though, or 
for instances to store closure references. It should offer similar performance 
to a standard `deinit`.

Instead, what about a sibling to `willSet`, `didSet` etc?

class Foo {
  var ptr: UnsafeMutablePointer {
deinit {
  ptr.destroy(...)
  ptr.dealloc(...)
}
  }

  init(count: Int = 0, ptr: UnsafeMutablePointer = nil) {
self.count = count
self.space = count

self.ptr = UnsafeMutablePointer.alloc(count)
self.ptr.initializeFrom(ptr, count: count)
  }
}

That way you can have as many initializers as you like. It would be called when 
the object deinitializes only, and not when changing the property.

This could also hopefully be possible with property behaviours.

Patrick

> On 11 Jun 2016, at 9:45 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Twitter tl;dr: 
>> Brent: So each instance must remember which init was used for it and then 
>> run the matching deinit code at deinit time?
>> Me: In my version, the constructive act and destructive act are always 
>> paired, even redundantly, using a stack if needed
>> Graham: so all your deferredDeinit blocks would run, no matter which init 
>> was invoked?
>> Brent: Closure stack in the worst case. Might be able to optimize to 
>> something cheaper if no captures.  Degenerate case: `for i in 0..<10 { 
>> deinit { print(i) } 
> 
> So continuing on from Twitter, assuming the compiler cannot optimize in the 
> case of multiple inits, and init-redirections, how about allowing traditional 
> deinit as well, and introduce compile-time optimization into traditional 
> de-init if the compiler finds only one initialization path per class? We can 
> also warn anyone using my version in a complicated degenerate way that it can 
> be costly through education, manual, etc. It would also help if (especially 
> in Cocoa), you could legally use shared initialization setup closures.
> 
> If I create an observer, I want to be able to handle its end-of-life at that 
> point. If I allocate memory, ditto. Etc etc. Surely Swift should be able to 
> support doing this.
> 
> -- E
> 
>> On Jun 8, 2016, at 3:43 PM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>> I really like this idea. Spatially moving cleanup next to unsafe operations 
>> is good practice.
>> 
>> In normal code, I want my cleanup to follow as closely as possible to my 
>> unsafe act:
>> 
>> let buffer: UnsafeMutablePointer = 
>> UnsafeMutablePointer(allocatingCapacity: chunkSize)
>> defer { buffer.deallocateCapacity(chunkSize) }
>> 
>> (Sorry for the horrible example, but it's the best I could grep up with on a 
>> moment's notice)
>> 
>> I like your idea but what I want to see is not the deinit child closure in 
>> init you propose but a new keyword that means defer-on-deinit-cleanup
>> 
>> self.ptr = UnsafeMutablePointer(allocatingCapacity: count)
>> deferringDeInit { self.ptr.deallocateCapacity(count) }
>> 
>> Or something.
>> 
>> -- E
>> p.s. Normally I put them on the same line with a semicolon but dang these 
>> things can be long
>> 
>>> On Jun 8, 2016, at 10:54 AM, Graham Perks via swift-evolution 
>>> > wrote:
>>> 
>>> Teach init a 'defer'-like ability to deinit
>>> 
>>> 'defer' is a great way to ensure some clean up code is run; it's 
>>> declaritive locality to the resource acquisition is a boon to clarity.
>>> 
>>> Swift offers no support for resources acquired during 'init'.
>>> 
>>> For an example, from 
>>> https://www.mikeash.com/pyblog/friday-qa-2015-04-17-lets-build-swiftarray.html
>>>  
>>> 
>>> 
>>> init(count: Int = 0, ptr: UnsafeMutablePointer = nil) {
>>> self.count = count
>>> self.space = count
>>> 
>>> self.ptr = UnsafeMutablePointer.alloc(count)
>>> self.ptr.initializeFrom(ptr, count: count)
>>> }
>>> 
>>> deinit {
>>> ptr.destroy(...)
>>> ptr.dealloc(...)
>>> }
>>> 
>>> Another 'resource' might be adding an NSNotificationCenter observer, and 
>>> wanting to unobserve in deinit (no need in OS X 10.11, iOS 9, but for 
>>> earlier releases this is a valid example).
>>> 
>>> Changing the above code to use a 'defer' style deinit block might look like:
>>> 
>>> init(count: Int = 0, ptr: UnsafeMutablePointer = nil) {
>>> self.count = count
>>> self.space = count
>>> 
>>> self.ptr = UnsafeMutablePointer.alloc(count)
>>> self.ptr.initializeFrom(ptr, count: count)
>>> 
>>> deinit {
>>> ptr.destroy(...)
>>> ptr.dealloc(...)
>>> }
>>> 
>>> // NSNotificationCenter example too
>>> NSNotificationCenter.defaultCenter().addObserver(...)
>>> deinit { 
>>> NSNotificationCenter.defaultCenter().removeObserver(...)
>>> }
>>> }
>>> 
>>> The need to provide a separate 

Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

[Patrick Smith via swift-evolution]

> On 9 Jun 2016, at 9:55 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
>> On 9 Jun 2016, at 9:23 PM 
>> , Adrian Zubarev via 
>> swift-evolution > > wrote:
>> 
>> So what is the counterpart to AnyClass aka. AnyObject.Type for AnyValue? 
>> There is no and I don’t see any good name for it.
>> 
>> You could just use AnyValue.Type?
> 
> So basically you’re for consistency for `AnyValue` but not for current 
> `AnyObject`.
> 
> It’s clear that `AnyValue` can represent more than one value type, where 
> `AnyObject` can only represent one reference type (class). IMO for 
> consistency it should be named as `AnyClass`.
> 
There could be one day more than one reference type, and AnyObject could also 
work with that.

>> More confusion with generalized existentials:
>> 
>> Any vs. AnyClass aka AnyObject.Type
>> Any makes it crystal clear that you’re using an instance of a class 
>> not an instance of .Type. It should be consistent.
>> 
>> Any<…> would be used for any of a certain type. So Any to me says 
>> ‘any of class’, not ‘any class’. Whereas AnyClass says to me literally ‘any 
>> class’.
> 
> `Any` and `AnyClass` should be the same otherwise it will lead to 
> confusion!
> 
If Any was introduced, then I’d advocate for it being an outright 
replacement and just removing AnyObject.
> If someone is new to the language and reads `AnyObject.Type` its not clear 
> that a `.Type` instance of a class is meant, because its not clear what 
> `Object` might be. 
> 
> If then you also have existentials with any-class requirements and `AnyClass` 
> typealias which is `AnyObject.Type` it would definitely lead to confusion 
> between:
> 
> func foo(value: AnyClass & SomeProtocol) // this would be illegal with 
> current implementation
> 
> vs.
> 
> func foo(value: Any & SomeProtocol)
> 
> If one would want to use a `.Type` instance then should always type out 
> `.Type` suffix after your type name: `AnyClass.Type` == any `.Type` instance 
> of any class
> 
> I'm strongly against keeping `AnyClass` as an alias for `AnyObject.Type`, I’d 
> consider to keep only `AnyObject` but if `Any<>` existentials were to come 
> we’d get this mismatch:
> 
> typealias AnyObject = Any
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> ___
> 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] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

[Patrick Smith via swift-evolution]

> On 9 Jun 2016, at 9:23 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> So what is the counterpart to AnyClass aka. AnyObject.Type for AnyValue? 
> There is no and I don’t see any good name for it.
> 
You could just use AnyValue.Type?
> More confusion with generalized existentials:
> 
> Any vs. AnyClass aka AnyObject.Type
> Any makes it crystal clear that you’re using an instance of a class 
> not an instance of .Type. It should be consistent.
> 
Any<…> would be used for any of a certain type. So Any to me says ‘any 
of class’, not ‘any class’. Whereas AnyClass says to me literally ‘any class’.
> I’m not proposing for AnyStruct or AnyEnum here, it would be enough to get 
> AnyValue in Swift, but I did considered both in my proposal. 
> 
> Lets say we also would have something like One which picks A or B and 
> we have generalized struct and enum. That said we could create AnyValue like 
> this typealias AnyValue = One. Again this is not the main part 
> of the proposal.
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 9. Juni 2016 um 13:09:28, Patrick Smith (pgwsm...@gmail.com 
> ) schrieb:
> 
>> I find this more confusing, not less. AnyClass suggests that will be any 
>> class, but it’s not, it’s any class instance. So I think it’s less accurate.
>> 
>> For arguments that AnyStruct and AnyEnum will come, I don’t agree with those 
>> either. AnyValue would make more sense to me. The fact that a value’s type 
>> is a struct or enum is irrelevant, just as AnyObject makes no promise about 
>> the superclass. I don’t believe there would be much or anything you could do 
>> knowing if something was a struct or enum anyway — both support properties 
>> and methods, mutations, yet cases can only be used with a concrete enum 
>> type. So AFAIK, there would no um value in having both AnyStruct and AnyEnum.
>> 
>> So I am happy staying with AnyObject, as it describes what the actual 
>> instance is. And if AnyValue comes, they would pair nicely together.
>> 
>> Patrick
>> 
>> 
>>> On 9 Jun 2016, at 8:08 PM, Adrian Zubarev via swift-evolution 
>>> > wrote:
>>> 
>>> I added a draft proposal here: 
>>> https://github.com/DevAndArtist/swift-evolution/blob/rename_anyobject_remove_anyclass/proposals/-rename-anyobject-remove-anyclass.md
>>>  
>>> 
>>> Rename AnyObject and remove current AnyClass
>>> 
>>> Proposal: SE- 
>>> 
>>> Author(s): Adrian Zubarev 
>>> Status: Awaiting review 
>>> Review manager: TBD
>>> Introduction
>>> 
>>> From the beginning AnyObject protocol and AnyClass type-alias felt wrong 
>>> and confusing. This proposal aims to sort out the confusion and provide a 
>>> consistency for future version of Swift.
>>> 
>>> Swift-evolution thread: [Pitch] Rename AnyObject to AnyClass and drop 
>>> current AnyClass 
>>> 
>>> Motivation
>>> 
>>> In Swift 3 the standard library will correspond to a particular guideline 
>>> .
>>>  This means that the Type suffix will be removed almost everywhere. This 
>>> provides good readability and makes usage of .Type more clearer and 
>>> consistent. Furthermore this change is a first step towards consistency for 
>>> generalized existentials 
>>> .
>>> 
>>> Short example:
>>> 
>>> -func construct(type: AnyClass) -> AnyObject?
>>> +func construct(type: AnyClass.Type) -> AnyClass? {
>>> if let objectType = type as? NSObject.Type {
>>> return objectType.init()
>>> } else {
>>> return nil
>>> }
>>> }
>>> Proposed solution
>>> 
>>> Remove current AnyClass type-alias from the standard library and rename 
>>> current AnyObject protocol to AnyClass. Then migrate existing code from 
>>> AnyClass to AnyClass.Type and from AnyObject to AnyClass.
>>> 
>>> // Remove completely
>>> -public typealias AnyClass = AnyObject.Type
>>> 
>>> // Rename to AnyClass
>>> -@objc public protocol AnyObject {}
>>> +@objc public protocol AnyClass {}
>>> Impact on existing code
>>> 
>>> This change will break existing code, and will require a migrator to 
>>> translate Swift 2 code into Swift 3 code.
>>> 
>>> Alternatives considered & Future consistency
>>> 
>>> Use generalized existentials with any-class requirement Any instead, 
>>> which won’t make it into Swift 3 in time:
>>> AnyClass equals Any or typealias AnyClass = Any
>>> AnyClass.Type 

Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

[Patrick Smith via swift-evolution]

I find this more confusing, not less. AnyClass suggests that will be any class, 
but it’s not, it’s any class instance. So I think it’s less accurate.

For arguments that AnyStruct and AnyEnum will come, I don’t agree with those 
either. AnyValue would make more sense to me. The fact that a value’s type is a 
struct or enum is irrelevant, just as AnyObject makes no promise about the 
superclass. I don’t believe there would be much or anything you could do 
knowing if something was a struct or enum anyway — both support properties and 
methods, mutations, yet cases can only be used with a concrete enum type. So 
AFAIK, there would no um value in having both AnyStruct and AnyEnum.

So I am happy staying with AnyObject, as it describes what the actual instance 
is. And if AnyValue comes, they would pair nicely together.

Patrick


> On 9 Jun 2016, at 8:08 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I added a draft proposal here: 
> https://github.com/DevAndArtist/swift-evolution/blob/rename_anyobject_remove_anyclass/proposals/-rename-anyobject-remove-anyclass.md
>  
> 
> Rename AnyObject and remove current AnyClass
> 
> Proposal: SE- 
> 
> Author(s): Adrian Zubarev 
> Status: Awaiting review 
> Review manager: TBD
> Introduction
> 
> From the beginning AnyObject protocol and AnyClass type-alias felt wrong and 
> confusing. This proposal aims to sort out the confusion and provide a 
> consistency for future version of Swift.
> 
> Swift-evolution thread: [Pitch] Rename AnyObject to AnyClass and drop current 
> AnyClass 
> 
> Motivation
> 
> In Swift 3 the standard library will correspond to a particular guideline 
> .
>  This means that the Type suffix will be removed almost everywhere. This 
> provides good readability and makes usage of .Type more clearer and 
> consistent. Furthermore this change is a first step towards consistency for 
> generalized existentials 
> .
> 
> Short example:
> 
> -func construct(type: AnyClass) -> AnyObject?
> +func construct(type: AnyClass.Type) -> AnyClass? {
> if let objectType = type as? NSObject.Type {
> return objectType.init()
> } else {
> return nil
> }
> }
> Proposed solution
> 
> Remove current AnyClass type-alias from the standard library and rename 
> current AnyObject protocol to AnyClass. Then migrate existing code from 
> AnyClass to AnyClass.Type and from AnyObject to AnyClass.
> 
> // Remove completely
> -public typealias AnyClass = AnyObject.Type
> 
> // Rename to AnyClass
> -@objc public protocol AnyObject {}
> +@objc public protocol AnyClass {}
> Impact on existing code
> 
> This change will break existing code, and will require a migrator to 
> translate Swift 2 code into Swift 3 code.
> 
> Alternatives considered & Future consistency
> 
> Use generalized existentials with any-class requirement Any instead, 
> which won’t make it into Swift 3 in time:
> AnyClass equals Any or typealias AnyClass = Any
> AnyClass.Type equals Any.Type
> Add AnyValue type-alias with generalized existentials and value keyword:
> AnyValue equals Any or typealias AnyValue = Any
> AnyValue.Type equals Any.Type
> Or instead AnyValue add AnyStruct and AnyEnum type-aliases:
> AnyStruct equals Any or typealias AnyStruct = Any
> AnyEnum equals Any or typealias AnyEnum = Any
> AnyStruct.Type equals Any.Type
> AnyEnum.Type equals Any.Type
> Example:
> 
> // Accept any type that conforms to `SomeProtocol`
> func doSomething(with interface: SomeProtocol) { ... }
> 
> // Accept any class that conforms to `SomeProtocol`
> // We use shorthand syntax for existentials here (SE-0095)
> func doSomething(with interfaceReference: AnyClass & SomeProtocol) { ... }
> func doSomething(with interfaceReference: Any & SomeProtocol) { ... }
> 
> // Accept any value that conforms to `SomeProtocol`
> // Missing counterpart to `AnyClass`
> func doSomething(with interfaceValue: AnyValue & SomeProtocol) { ... }
> func doSomething(with interfaceValue: Any & SomeProtocol) { ... }
> 
> // Or more specific value types:
> func doSomething(with interfaceValue: AnyStruct & SomeProtocol) { ... }
> func doSomething(with interfaceValue: Any & SomeProtocol) { ... }
> 
> func doSomething(with interfaceValue: AnyEnum & SomeProtocol) { ... }
> func doSomething(with interfaceValue: Any & SomeProtocol) { ... }
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> 

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Patrick Smith via swift-evolution]

To answer my own question, relooking at the proposal, RawRepresentable wouldn’t 
be suitable for Bool, Character, UnicodeScalar, Integer, etc.

> On 5 Jun 2016, at 7:20 PM, Patrick Smith  wrote:
> 
> (This raises a point — what’s the difference between the proposed 
> LosslessStringConvertible and RawRepresentable where RawValue = String? They 
> both have a failable init. Is it due to current limitations with typealiases 
> that makes this hard?)

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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Patrick Smith via swift-evolution]

> On 5 Jun 2016, at 4:31 PM, Brent Royal-Gordon  wrote:
> 
> Sorry, I meant to reply to this but forgot.

No worries Brent! Thanks for the thoughtful reply.

> 
>> For developers, like ourselves, it seems straight-forward that a string is 
>> this simple primitive. We get them in, we process them, and we spit them 
>> back out. However, this is a flawed system, as it one that is made easiest 
>> for the programmer, and is really designed for a context where the user is 
>> also a programmer. It best suits technical scenarios such as configuration 
>> files, environment variables, and command line arguments, as Brent suggests. 
>> However, I don’t think this is the best case to design for.
> 
> It is *a* case we need to design for. It is also the *base* case: 
> localization is layered on top of non-localized constructs.
> 
>>> So, here's my version of your table:
>>> 
>>> User-readable, nonlocalized: CustomStringConvertible
>>> User- and machine-readable, nonlocalized: LosslessStringConvertible
>>> User-readable, localized: (nothing)
>>> Developer-readable: CustomDebugStringConvertible
>>> 
>>> (Playground isn't necessarily working with strings, so it doesn't belong in 
>>> this list.)
>> 
>> The first item in your table ‘User-readable, non-localised’, is the big 
>> problem area to me. Ideally in my mind all of these should be moved to other 
>> areas, such as the second area that LosslessStringConvertible occupies, 
>> which command line arguments and configuration keys certainly could. And 
>> user-readable should use a system that always allows localisation to be 
>> added progressively, by use of type extensions or protocols.
>> 
>> In a UI application, everything that is displayed should be using a system 
>> which allows localisation.
> 
> In theory, yes. In practice? We write code that will be used only once (like 
> an ad-hoc fix for some problem). We write code that will never be exposed to 
> users (like a background process). We write code that is kept in one limited 
> environment (like a company internal app). We write code that simply isn't 
> going to be localized for business reasons (like an app that wouldn't be 
> profitable to translate).
> 
> We write code that constructs strings without caring what their contents are 
> (think of a Markdown converter). We write code that emits strings which are 
> primarily for machines, but formatted to be convenient for 
> humans—particularly human programmers working with the formats—to understand 
> (think of a reporting tool that emits CSV with column headings in English). 
> We write code where we know everyone will understand a certain language (air 
> traffic control is conducted entirely in English worldwide). We write code 
> that's too low-level to be localized. We write unit tests (hopefully).
> 
> And we write code when we're just learning how to program, and printing the 
> result of 1 + 2 in French is the last thing on our minds.
> 
> So yes, in a meticulously-engineered ideal application, you would have little 
> call for "user-readable, nonlocalized". But that's not what people write a 
> lot of the time.

Strings are this very flexible type. Currently the only validations I know of 
that the String type does are conformance to the various Unicode encodings.

I think it’s similar to pointer safety. A pointer in C can point to anything. 
The programmer might be sure its valid, but the computer isn’t until it 
dereferences it. It could be null (crash) or it could be pointing to an already 
deallocated object or something else entirely (worse than a crash). Swift tries 
to save us from making these mistakes. Similarly, the programmer could be 100% 
percent sure her cast will succeed, that this object is of a certain class or 
conforms to a certain protocol. Swift makes these casts safe, by either 
crashing immediately or letting the programmer decide what to do with nil, or 
avoids them by use of generics.

A String in Swift can mean anything. It could be empty, it could be 7000 
characters long, it could be formatted incorrectly or contain illegal 
characters. `String` says as much to me as `id` does in Objective-C. It’s up to 
me to decide what the meaning is and whether it’s valid yet or not.

I wonder if most data-facing strings could use a string-represented enum or 
struct instead?

e.g.

enum GitCommand : String {
  case clone = "clone"
  case init = "init"
  case add = "add"
  case mv = "mv"
  ...
}

which can be conveniently shortened to:

enum GitCommand : String {
  case clone, init, add, mv, ...
}

A initialized GitCommand value can only be valid, which leads to clearer and 
safer code.

Loose string identifiers such as CSV column headings could use a struct that 
conforms to RawRepresentable / LosslessStringConvertible. The failable 
initializer could trim whitespace and validate, and generally conform it into 
an ideal form. There’s no flags for `isValidated` or assumptions that you bring 
by using 

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

[Patrick Smith via swift-evolution]

The issue I think is that it would open up serialisation for all sorts of 
formats, which is a much larger problem in itself, whereas this can just focus 
on a user-defined ‘lossless’ string.

Patrick

> On 5 Jun 2016, at 1:25 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Jun 4, 2016, at 15:46, Jacob Bandes-Storch via swift-evolution 
>>  wrote:
>> 
>>  - The "lossless" protocol will be a welcome addition for 
>> serialization/deserialization code, and it makes the replacement init(_:) 
>> API very clear in its behavior.
> 
> Speaking of which, would "Serializable" be a better name for the protocol? I 
> don't recall whether anyone's already asked.
> 
> - Dave Sweeris
> ___
> 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] Working with enums by name

[Patrick Smith via swift-evolution]

>From what I understand, enums normally are represented internally by an offset 
>— that is their truth. With RawRepresentable enums, you are saying “no, I want 
>the truth to be something else”. But it seems that they are still represented 
>internally by an offset, so you can’t reorder a RawRepresentable enum’s cases 
>and maintain ABI compatibility either.

So what you are saying about the order of cases being an intrinsic part of an 
enum does make sense. I’m not sure if can still lead to confusing / fragile 
code though.

Patrick


> On 2 Jun 2016, at 10:17 PM, Leonardo Pessoa  wrote:
> 
> There are several ways to solve this, which IMO is a basic functionality of 
> enums, writing code that is currently possible and works. But that's the 
> issue, you still have to write code to have a basic functionally. I don't 
> remember not being able to do this out-of-the-box in any language I worked 
> with.
> 
> L
> From: Patrick Smith 
> Sent: ‎02/‎06/‎2016 02:07 AM
> To: Brent Royal-Gordon 
> Cc: Leonardo Pessoa ; swift-evolution 
> 
> Subject: Re: [swift-evolution] Working with enums by name
> 
> Great points Brent. I think the ValuesEnumerable method would be the most 
> straight forward. Also, the number of cases are likely only going to be in 
> range of 6–20, so iterating would be fine I think. People can create 
> something like `Dictionary(Planet.allValues.enumerated().lazy.map{ ($1, $0) 
> })` (I think that’s right) if they really need.
> 
> 
> > On 2 Jun 2016, at 2:40 PM, Brent Royal-Gordon via swift-evolution 
> >  wrote:
> > 
> > Or the `ValuesEnumerable` proposal would give you a convenient, though 
> > slightly slow, way to do two-way lookup by order:
> > 
> > enum Planet: String, ValuesEnumerable {
> > var order: Int {
> > return Planet.allValues.index(of: self)!
> > }
> > init(order: Int) {
> > self = Planet.allValues[order]
> > }
> > case mercury, venus, …
> > }
> 

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Patrick Smith via swift-evolution]

Yeah I realise who Dave is :)

Ok, that’s good to know about your uses. An extra benefit that MemoryLayout has 
is a developer who is familiar with sizeof() from other languages (I only know 
of C), if it was called the same thing in Swift they might just go ahead and 
use it and add their own alignment tricks. Whereas a MemoryLayout type ties of 
all this functionality together in the one place, where they can discover that 
`stride`/`spacing` might serve them better.

Patrick

> On 2 Jun 2016, at 4:23 PM, Xiaodi Wu  wrote:
> 
> On Thu, Jun 2, 2016 at 12:37 AM, Patrick Smith  > wrote:
> Yes but, if they weren’t functions now, what would be the best design?
> 
> Dave's suggestions then were made in the context of a language that had 
> `.dynamicType`. The question today is how best to align these functions with 
> `type(of:)`. If we were to ignore this context, I'm not sure on what basis we 
> could judge whether a property or function is 'best' for these facilities.
>  
> How many Swift developers will be using this functionality? Less than 1%? I 
> trust Dave’s judgement because he is in that small group.
> 
> I would caution against this assumption. I'm not a particularly advanced 
> developer by any stretch of the imagination, and I've been using `strideof()` 
> plenty of times while doing some math with Accelerate.framework and Metal 
> buffers. That said, Dave's in a very small group indeed, the group that wrote 
> these functions to start with.

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Patrick Smith via swift-evolution]

Yes but, if they weren’t functions now, what would be the best design?

How many Swift developers will be using this functionality? Less than 1%? I 
trust Dave’s judgement because he is in that small group.

> On 2 Jun 2016, at 3:27 PM, Xiaodi Wu  wrote:
> 
> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith  > wrote:
> I really like this idea. This IMO is lower level functionality than 
> `type(of:)` (née dynamicType), so I think it makes sense for it to be grouped 
> under its own domain, the MemoryLayout type.
> 
> Plus MemoryLayout can be extended with new convenience methods.
> 
> I’m fine with those old methods being removed, but I never use them so! Is it 
> the same as calling type(of:) then using that with MemoryLayout? I imagine 
> they could be fixit’d easily, and that they compile down to the same 
> underlying code.
> 
> I'm actually souring to the idea. It goes in the diametrically opposite 
> direction from dynamicType. There, something was changed from being 
> property-like to being function-like. Here, Dave's proposal would take 
> something that's a function and turn it into a property. Hmm.
>> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> 2. Dave A. and others expressed the opinion that these should probably not 
>> be global functions; his preference was for:
>> 
>> ```
>> MemoryLayout.size // currently sizeof()
>> MemoryLayout.spacing // currently strideof()
>> MemoryLayout.alignment // currently alignof()
>> ```
>> 
>> 3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue() 
>> are better off removed altogether. I don't know if people are going to be 
>> happy about this idea.
> 
> 

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

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Patrick Smith via swift-evolution]

I really like this idea. This IMO is lower level functionality than `type(of:)` 
(née dynamicType), so I think it makes sense for it to be grouped under its own 
domain, the MemoryLayout type.

Plus MemoryLayout can be extended with new convenience methods.

I’m fine with those old methods being removed, but I never use them so! Is it 
the same as calling type(of:) then using that with MemoryLayout? I imagine they 
could be fixit’d easily, and that they compile down to the same underlying code.

Patrick

> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 2. Dave A. and others expressed the opinion that these should probably not be 
> global functions; his preference was for:
> 
> ```
> MemoryLayout.size // currently sizeof()
> MemoryLayout.spacing // currently strideof()
> MemoryLayout.alignment // currently alignof()
> ```
> 
> 3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue() 
> are better off removed altogether. I don't know if people are going to be 
> happy about this idea.

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

Re: [swift-evolution] Ad hoc enums / options

[Patrick Smith via swift-evolution]

Yes, great point! I think this is a sign it’s better to just have one way with 
an enum, so there’s no deciding on which method to use, or reluctance to switch 
away from ad hoc enums because they felt nicer initially. And enums aren’t that 
much to write.

With the addition of a macro system in future Swift you could probably create 
your own ad hoc enums, and that would be perfect for something like a 
playground.

Patrick

> On 2 Jun 2016, at 2:57 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> Thinking of your example: where might the value for .fit or .fill come from? 
> In most cases it won't be hardcoded in the call, but be either the result of 
> a user setting or an algorithm. Both would need to be able to assign this 
> value.

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

Re: [swift-evolution] Ad hoc enums / options

[Patrick Smith via swift-evolution]

> On 2 Jun 2016, at 7:38 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> Would those who dislike ad hoc enums argue that this also shouldn't be 
> allowed:
> 
> func foo(bar: (x: Int, y: Int)) {}
> let t: (x: Int, y: Int) = (x: 5, y: 5)


I would argue that example contains a code smell, so while it compiles, I 
personally wouldn’t allow it.

But it depends on the semantics of course. And there should always be a pull as 
a writer to turn a tuple into a struct.

My issue with ad hoc enums is that their context is to the function. They 
should instead be an independent concept, and that’s why an enum type is so 
useful, because it even names the concept.

Tuples from what I see are primarily function based, so it’s really overcoming 
the fact that while you can pass multiple parameters to a function, you only 
get one back, so a tuple is the best way to solve that. (And of course they 
work with callbacks too, an asynchronous version of returning from a function, 
or functions that alter and return their input).

As soon as you start passing a tuple around, it has meaning, and our job as 
programmers is to assign names and flesh out meaning.

And if you are translating from (.fit | .fill) to (.fit | .fill | .florp), 
that’s a lot of boilerplate code, which goes against the whole reason for 
having ad hoc enums (or just imagine going the opposite way, there’s a lot more 
to be discussed on how ad hoc enums work I think). It would be better in mind 
to break them up into thoughtful pieces, such as two enums or an enum and an 
extra bool. This isn’t always easy of course. Them’s the breaks!

Patrick

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

Re: [swift-evolution] Ad hoc enums / options

[Patrick Smith via swift-evolution]

Lots of people have added their 2¢ now, you probably have about 10 dollars 
worth, but here goes.

While it looks nice and short, I think it has a range of drawbacks:
- It’s not a real type that can participate in protocols or extensions.
- Discourages DRY coding, because some people will think they are taking the 
easy way out, and even copy and paste this same declaration multiple times.
- Encourages adding subtypes to functions instead of types. Swift seems 
primarily type-focused more than function-focused. I remember seeing someone 
write their solution as an extension to UIImage, which was a nice way to do it. 
This subtype would be best conceptually as UIImage.FitOperation (use with 
multiple methods!) not scaleAndCropImage.Operation (use once!)

The beauty of Swift is that you can add methods to value types. This opens up 
interesting, more reusable solutions such as:


enum ContentFit {
  case fit
  case fill
  
  func adjust(size contentSize: CGSize, within bounds: CGRect) -> CGRect {
let (widthFactor, heightFactor) = (bounds.size.width / contentSize.width, 
bounds.size.height / contentSize.height)
let scaleFactor: CGFloat
switch self {
case .fit: scaleFactor = min(widthFactor, heightFactor)
case .fill: scaleFactor = max(widthFactor, heightFactor)
}

let adjustedSize = CGSize(width: contentSize.width * scaleFactor, height: 
contentSize.height * scaleFactor)
let adjustedOrigin = CGPoint(x: (bounds.size.width - adjustedSize.width) / 
2.0, y: (bounds.size.height - adjustedSize.height) / 2.0)
return CGRect(origin: adjustedOrigin, size: adjustedSize)
  }
}


That way you break functions up into smaller chunks, while also making the 
types more useful in themselves.

(For context, Erica’s original post is here: 
http://ericasadun.com/2016/05/31/swift-rewrite-challenge/ 
)

Patrick

> On 1 Jun 2016, at 2:16 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Here's a function signature from some code from today:
> 
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> fitImage: Bool = true
> ) -> UIImage {
> 
> 
> And here's what I want the function signature to actually look like:
> 
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> operation: (.Fit | .Fill) = .Fit
> ) -> UIImage {
> 
> 
> where I don't have to establish a separate enumeration to include ad-hoc 
> enumeration-like semantics for the call. A while back, Yong hee Lee 
> introduced anonymous enumerations (and the possibility of anonymous option 
> flags) but the discussion rather died.
> 
> I'm bringing it up again to see whether there is any general interest in 
> pursuing this further as I think the second example is more readable, 
> appropriate, and Swifty than the first, provides better semantics, and is 
> more self documenting.
> 
> Thanks for your feedback,
> 
> -- Erica
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Patrick Smith via swift-evolution]

I’ve always had a funny feeling about the `where` keyword in `if` statements. 
It feels like it adds structure, but it’s not the most flexible of keywords. I 
sometimes find myself writing to match the structure it wants rather than the 
other way around. I rather like this proposal.

What if `where` could be used to constrain the unwrapping of the optional 
rather than being an independent boolean expression? You could possibly use it 
normally outside of `if` like so:

let a: Optional = "hello"

…

let b = a where a?.count > 4  // .some(“hello”)
let c = a where a?.count > 10  // .none


That way when used in an `if` statement, the `where` is actually part of the 
optional unwrap rather than a separate sibling.

if let x = x where x < 3 {
  …
}

So people keep their ability to group related things together, with the simple 
elegance of this proposal. Just an idea, and I’m sure it can be improved.


Another idea is a .filter() method added to Optional.

if let x = x.filter({ $0 < 3 }) {
  …
}


Patrick


> On 1 Jun 2016, at 8:38 PM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 1 Jun 2016, at 02:47, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> Q: How is an arbitrary boolean assertion introduced after `if let`?
>> 
>> Option 1 (present scenario)--using `where`
>> Advantages: expressive when it means exactly the right thing
>> Drawbacks: makes obligatory the suggestion of a semantic relationship 
>> between what comes before and after even when there is no such relationship
> 
> Like I said a little earlier, this drawback is not strictly true. No matter 
> how unrelated to the binding a where clause may seemingly be, the binding is 
> still dependent upon it; i.e- no value is bound if the condition fails, so 
> regardless of what the condition is actually testing for it is very much 
> related to the binding, like-so:
> 
>   if let value = foo where somethingUnrelatedIsTrue() { … }
> 
> The variable named “value” doesn’t exist outside of this condition if 
> somethingUnrelatedIsTrue() fails, so I’d say there is still very much a 
> relationship between these two things. A lot of the time you probably do want 
> to test the unwrapped value, but it’s not a requirement for the condition to 
> be related, because one cannot succeed without the other.
> 
>> Option 3--using a symbol never encountered in conditional statements (e.g. 
>> semicolon)
>> Advantages: doesn't need to be disambiguated from any existing uses
>> Drawbacks: looks out of place
> 
> How out of place does it really look? It’s no different from semi-colons for 
> separating statements in code, and if where remains supported you’ll only 
> need to use it in a handful of cases anyway (much like semi-colons for 
> statement separation).
> 
>> It does occur to me that there is one more option. I don't know that I like 
>> it, but it's an option no one has put forward before: recite the opening 
>> keyword when beginning a new boolean expression:
>> 
>> `if let x = x where x < 3 { ... }` becomes
>> `if let x = x if x < 3 { ... }`
>> 
>> `while let item = sequence.next() where item > 0 { ... }` becomes
>> `while let item = sequence.next() while item > 0 { ... }`
> 
> I’m not sure what the difference is here; it doesn’t seem to have any 
> capability that where doesn’t, surely it’s just changing the name of the 
> keyword or is the point to have the full range of capabilities on both sides 
> of the keyword? This could be done with where just as easily, no need for 
> renaming, like so:
> 
>   if let value = foo where case .Some(let value2) = bar { … }
> 
> Bad example I know, but I don’t use pattern matching much. This currently 
> doesn’t compile, but where could be extended to include all conditional 
> types, so you could chain it to do pattern matching, conditional binding and 
> a conditional all in one, is that the kind of thing you mean?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Patrick Smith via swift-evolution]

Thank you Brent. I like your points, and agree that localisation is not a 
simple problem. Also interesting to see the latest discussion (from Vladimir, 
Dave, Austin, and Hooman).

Replied inline below:

> On 30 May 2016, at 4:23 PM, Brent Royal-Gordon  wrote:
> 
>> Thanks Chris. I just meant where is that string going?
>> 
>> To a developer -> CustomDebugStringConvertible / Reflection
>> To standard output -> Streamable
>> To a user -> NSLocalizedString — no protocol (yet?)
>> To an API / for serialisation -> LosslessStringConvertible
>> To a playground -> CustomPlaygroundQuickLookable
>> 
>> CustomStringConvertible is left over, but doesn’t have a use case? Unless 
>> it’s an alternative to Streamable, but then why have Streamable?
> 
> There are *very* few conformances to Streamable in the standard library—just 
> Character, String, and UnicodeScalar. I think that Streamable is for data 
> that can be *directly* written to an output stream, whereas 
> CustomStringConvertible is a way to convert an instance that *isn't* directly 
> Streamable into something Streamable.

OK, that’s an interesting distinction (and interesting protocol in Streamable — 
it feels as though it has some functionality to come).

For developers, like ourselves, it seems straight-forward that a string is this 
simple primitive. We get them in, we process them, and we spit them back out. 
However, this is a flawed system, as it one that is made easiest for the 
programmer, and is really designed for a context where the user is also a 
programmer. It best suits technical scenarios such as configuration files, 
environment variables, and command line arguments, as Brent suggests. However, 
I don’t think this is the best case to design for.

> 
> So, here's my version of your table:
> 
> User-readable, nonlocalized: CustomStringConvertible
> User- and machine-readable, nonlocalized: LosslessStringConvertible
> User-readable, localized: (nothing)
> Developer-readable: CustomDebugStringConvertible
> 
> (Playground isn't necessarily working with strings, so it doesn't belong in 
> this list.)

The first item in your table ‘User-readable, non-localised’, is the big problem 
area to me. Ideally in my mind all of these should be moved to other areas, 
such as the second area that LosslessStringConvertible occupies, which command 
line arguments and configuration keys certainly could. And user-readable should 
use a system that always allows localisation to be added progressively, by use 
of type extensions or protocols.

In a UI application, everything that is displayed should be using a system 
which allows localisation. I would argue a command line tool is also a UI 
application. I would not advocate for a full-on locale system like the one 
Foundation has to be brought to the Swift standard library (unless eventually 
it’s easy to integrate a standard a la Unicode).

> Localization is an obvious hole in our string conversions, but I think the 
> reality here is that localization is part of a higher layer than the standard 
> library. From what I can see, all of the "standard library" APIs which handle 
> localization are actually part of Foundation. I'm sure that, if we build any 
> localization-related features into the language, we'll add basic supporting 
> code to the standard library if needed, but other than that, I don't think 
> the standard library is the right place.

I believe best practices can be put in place with a system no more complicated 
for the programmer than the one we have now. This could be possible with 
protocols: a core protocols in the standard library that are then fleshed out 
in a Foundation-level framework above, with Locale / CultureCode / etc types 
extending or conforming.

> 
>> I’m not sure if anyone else shares the concern, so I’ll leave it. I do 
>> believe it’s important however.
> 
> I do think this is an important concern, and I also think it's important to 
> ask how interpolation interacts with it. For instance, I think it would be 
> very useful to be able to say "interpolate developer representations" or 
> "interpolate user representations" or "interpolate localized user 
> representations", and have the compiler reject interpolated expressions which 
> don't have the necessary representation.

I like this idea. I think “interpolate localised user representations” should 
not be distinct from “interpolate user representations”. Instead non-localised 
is specifically denoted as ‘technical’ or perhaps ‘en-US’. Locales, or more 
broadly ‘contexts’, are not something additional, instead, everything already 
has a context, and the context of a string could be made more explicit.

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] Working with enums by name

[Patrick Smith via swift-evolution]

I had no idea you could do this!!

> On 1 Jun 2016, at 12:32 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> Who said anything about repeating the name?
> 
> Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). 
> Type :help for assistance.
>  1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, 
> uranus, neptune }
>  2> Planet.mercury.rawValue
> $R0: String = "mercury"

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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

Yes exactly, use the protocol conformance syntax, Michael’s description was 
mistaken I think.

Just the same way you get protocol extensions without having to use a special 
keyword.


> On 31 May 2016, at 6:26 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> I see these two groups: both wants explicit conformance to protocols, but 
> first thinks that current syntax is enough (`: Equatable`) and second thinks 
> we should introduce new keyword `deriving` for this(`: deriving Equatable`). 
> I see no opinions(except the one opinion in proposal itself) to automatically 
> deriving without explicit decoration.
> 
> On 30.05.2016 22:04, Michael Peternell via swift-evolution wrote:
>> It seems that there are two groups here. 1) Group 1 wants Equatable (and 
>> others) be derived automatically unless specifically overridden: similar to 
>> auto-synthesis of properties in Objective-C. 2) The other group (Group 2) 
>> wants Equatable (and others) be derived explicitly using a `deriving` 
>> keyword (or something semantically equivalent). Unless I missed something, 
>> there were no voices for keeping the status quo, and not introducing any 
>> process to automatically derive these protocols.
>> 
>> I think I chose an easy strategy when proposing the `deriving` keyword. 
>> Haskell is a mature language, and "copying" a feature from them is usually a 
>> safe choice. For each language feature, someone has to think through all the 
>> implications of it; this is usually far from trivial. I argue that if I take 
>> a feature from another language, someone has probably already thought about 
>> all the pros and cons of different solutions. This is just a plea for 
>> embracing precedent.
>> 
>> There is one advantage of method 2 that (I think) hasn't been discussed so 
>> far: when you declare a type `S`, and an `Equatable` instance is 
>> automatically derived, there is no way to override that instance in another 
>> module. With method 1, there is also no way to request that an `Equatable` 
>> instance should *not* be generated. I think no one will vote for something 
>> like `struct S @notderiving(Equateble,Hashable) { ... }`.
>> 
>> Also, a `deriving` keyword is less magical than just automatically deriving 
>> `Equatable` and `Hashable` instances. I think the language rules should be 
>> as simple as possible, by default. If you want any kind of special behavior, 
>> you have to ask for it: `deriving Equatable`, `@IBOutlet`, `@NSManaged`. 
>> Furthermore, I think it is good that the developer is aware that there is an 
>> "==" method somewhere, specifically for this new type. The compiler should 
>> not arbitrarily create methods, because someone may need them. Even if it is 
>> very likely that you will need them. Just like in a coffee house, you are 
>> asked if you want a coffee, even if you are visiting it every day. For 
>> example with Objective-C, I want each developer to be aware of the 
>> difference between a property and an iVar, and be aware of the connection 
>> between properties, methods, and key-value-coding. The complexities of the 
>> language shouldn't be hidden completely.
>> 
>> Just my two cents..
>> 
>> -Michael
>> 
>> ___
>> 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] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

Yes, and I’ve been arguing for it being explicit by conforming to the Equatable 
/ Hashable protocol. This would then work the same way as protocol extensions. 
Protocol extension don’t require a special ‘deriving’ keyword, so I don’t 
believe there needs to be one here. Just conforming to the protocols is enough.


> On 29 May 2016, at 9:42 PM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On May 29, 2016, at 12:28 AM, Patrick Smith  > wrote:
> 
>> Yeah I don’t see a problem. It’s the same way that protocol extensions just 
>> work. Think of this automatic synthesis as a really flexible protocol 
>> extension:
>> 
>> extension Hashable where Members : Hashable {
>>   var hashValue : Int {
>> return self.allMembers.reduce(^) // Or whatever combiner is best
>>   }
>> }
> 
> Protocol extensions require you to declare conformance before your type 
> receives their implementation and it must be identical for all do conforming 
> types.  
> 
> You should have to declare conformance to receive Equatable conformance and 
> synthesis.  IMO it makes sense to do that with 'deriving' which makes it 
> clear that you are requesting synthesized rather than manual conformance.
> 
>> 
>> 
>>> On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution 
>>> > wrote:
>>> 
 The problem with this is that it doesn’t differentiate between synthesized 
 and manual conformance.  You won’t get error messages you otherwise would 
 when you intend to supply manual conformance.  It is also less clear to a 
 reader of the code that the default, compiler synthesized implementation 
 is being generated.
>>> 
>>> I don’t think it’s reasonable to force the language down the path where 
>>> developers don’t have to be familiar with its features in order to use them 
>>> correctly. If types in Swift were to automatically gain Equatable and 
>>> Hashable conformances whenever they were used by something that required 
>>> them, that would be a core language feature, like type inference, that even 
>>> junior developers in the language would need to know. Yet few (though not 
>>> none) would insist that all types be manually declared, despite otherwise 
>>> not knowing when our type inference goes wrong. It’s just a basic feature 
>>> of the language that anyone using the language should know about, otherwise 
>>> it can bite them in the ass when weird compiler errors start popping up. 
>>> Frankly, IMO, this is an obvious case of 80/20 optimization. In the 
>>> vast majority of cases where my types are trivially equatable, I should 
>>> just be able to declare them as such and gain the compiler-synthesized ==. 
>>> In the cases where that’s not possible, the compiler can emit an error. And 
>>> in the cases where I want a custom == implementation I can provide it. 
>>> Requiring a new keyword and not making this feature as simple as possible 
>>> because the rare developer with a custom type who doesn’t want the 
>>> synthesized == they just said they did by declaring Equatable conformance 
>>> is an unnecessary defaulting to the rare case. 
>>> 
>>> 
>>> 
>>> 
>>> Jon Shier
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 

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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Patrick Smith via swift-evolution]

Thanks for replying Chris!

> On 29 May 2016, at 6:00 AM, Chris Lattner  wrote:
> 
> 2) If a value wants a better, or more customized, string form, then it 
> conforms to CustomStringConvertible.


What are the use cases for this more customized string form? If it is for the 
programmer, then debugDescription seems to be a better fit? For Playgrounds, 
the CustomPlaygroundQuickLookable protocol is used.

What are its other use cases? APIs? What about Streamable? Does this not take 
the same responsibility — it converts the receiver into a string? Here it seems 
like it trumps CustomStringConvertible with string conversion: 
https://github.com/apple/swift/blob/cf73dd9177c231a15429b08ae889e94f20e53f50/stdlib/public/core/OutputStream.swift#L332

Patrick


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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

Yeah I don’t see a problem. It’s the same way that protocol extensions just 
work. Think of this automatic synthesis as a really flexible protocol extension:

extension Hashable where Members : Hashable {
  var hashValue : Int {
return self.allMembers.reduce(^) // Or whatever combiner is best
  }
}


> On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution 
>  wrote:
> 
>> The problem with this is that it doesn’t differentiate between synthesized 
>> and manual conformance.  You won’t get error messages you otherwise would 
>> when you intend to supply manual conformance.  It is also less clear to a 
>> reader of the code that the default, compiler synthesized implementation is 
>> being generated.
> 
>   I don’t think it’s reasonable to force the language down the path where 
> developers don’t have to be familiar with its features in order to use them 
> correctly. If types in Swift were to automatically gain Equatable and 
> Hashable conformances whenever they were used by something that required 
> them, that would be a core language feature, like type inference, that even 
> junior developers in the language would need to know. Yet few (though not 
> none) would insist that all types be manually declared, despite otherwise not 
> knowing when our type inference goes wrong. It’s just a basic feature of the 
> language that anyone using the language should know about, otherwise it can 
> bite them in the ass when weird compiler errors start popping up. 
>   Frankly, IMO, this is an obvious case of 80/20 optimization. In the 
> vast majority of cases where my types are trivially equatable, I should just 
> be able to declare them as such and gain the compiler-synthesized ==. In the 
> cases where that’s not possible, the compiler can emit an error. And in the 
> cases where I want a custom == implementation I can provide it. Requiring a 
> new keyword and not making this feature as simple as possible because the 
> rare developer with a custom type who doesn’t want the synthesized == they 
> just said they did by declaring Equatable conformance is an unnecessary 
> defaulting to the rare case. 
>   
> 
> 
> 
> Jon Shier
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Patrick Smith via swift-evolution]

New proposal looks great. I love how this brings more consistency with how 
normal statements are written.

It would be nice to see in the proposal examples of before & afters for `while` 
too. Especially as it says "where clauses are no longer used to conjoin Boolean 
expressions with conditional binding. This fixes user confusion issues and 
addresses a problem where Boolean conditions need to be attached to arbitrary 
bindings.” An example of this?


> On 29 May 2016, at 8:48 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On May 27, 2016, at 12:11 PM, Joe Groff > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0099 “Restructuring Condition Clauses” begins now and runs 
>> through June 3, 2016. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md
>>  
>> 
> Thanks everyone.  FYI, Erica and I discussed it offlist and agreed to amend 
> the proposal: now you can use semicolons or a newline to separate clauses of 
> different types.
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Patrick Smith via swift-evolution]

+1. This has always tripped me up, I guess I felt there was a good reason for 
requiring you to add a `return`, but not sure what it would be.


> On 28 May 2016, at 3:57 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> The idea is simple:
> 
> Can we make return keyword optional in cases like this?
> Shouldn’t this behave like @autoclosure or @noescape?
> type A {
> var characters: [Character] = …
> var string: String { String(self.characters) }
> var count: Int { 42 }
> }
> Is this worth a proposal or Swifty enough, what do you think?
> 
> Sure I could write return, but why do we allow this behavior for @noescape 
> functions like map!?
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> ___
> 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-0099: Restructuring Condition Clauses

[Patrick Smith via swift-evolution]

> On 28 May 2016, at 10:37 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> But I don't know what that has to do with the fact that newline can be used 
> as an alternative.  It's just an alternate separator.  As far as I know, 
> everywhere semicolons are used as separators newlines are accepted as an 
> alternate separator.



Looks like an interesting proposal. I agree that the use of semicolons being 
interchangeable with newline separators should be consistent in their usage.

Otherwise there’s one approach to learn for members of a type, one for arrays 
and dictionaries, one for generic parameters, one for a list of clauses, one 
for pattern matching, one for tuples. Each of these have different rules it 
seems?

Not sure what the best rule and separator to use is, but it would be nice to 
have something consistent, even if it was more strict in places than today’s 
rules. Even if when different hierarchies that are used together, such as 
pattern matching with multiple parts and multiple boolean expressions, then it 
would be nice for these to have a different separator so they can never clash 
and step on each others’ toes. Maybe this is the comma and semicolon (/newline).


A different train of thought: could semicolons allow the closure ambiguity to 
be resolved that Chris brought up a couple of months ago? e.g.

if numbers.contains { $0 > 7 }; {
  // ...
}

// Or newlines

if
  numbers.contains { $0 > 7 }
{
  // ...
}

I imagine it wouldn’t, as the parser would always catch that first ‘{‘ as an 
opening brace? Would be nice to solve this if possible too.

Patrick

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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Patrick Smith via swift-evolution]

Some feedback:

I wonder if ValuePreservingStringConvertible having an initializer restricts 
its use case at all? Plus, ValuePreservingStringConvertible seems very similar 
to RawRepresentable with a RawValue of String.

Lossless sounds nice to me. Or ‘canonical’ I had wondered, but lossless sounds 
better.

• The standard library will be audited. Any type which can be reasonably 
represented as a string in a value-preserving way will be modified to conform 
to ValuePreservingStringConvertible. If they conform to CustomStringConvertible 
and their existing description is value-preserving, stringRepresentation will 
simply return description.
---
I think this should instead say description will simply return 
stringRepresentation, as it is more of a source of truth, and description is 
derivative

• CustomStringConvertible will provide a human-readable description of an 
instance. It may provide as little or as much detail as deemed appropriate.
• CustomDebugStringConvertible will provide a human-readable description of an 
instance. It can provide additional information relative to 
CustomStringConvertible, information that would not be pertinent for consumers 
of descriptions (such as human readers or other APIs), but would be useful for 
development or diagnostic purposes.
---
I think this reasoning for having both CustomStringConvertible and 
CustomDebugStringConvertible doesn’t really hold up. It’s a little bit vague. 
If it’s for an API, then the lossless value is the better choice. If it’s for 
people, then either a localised value (which description is not) or the 
lossless string representation is a better choice.

I know I keep repeating this, but I can’t see any use cases for a ‘description’ 
property. I think ‘stringRepresentation’ and ‘debugDescription’ cover all use 
cases. The ‘description’ property is never accessed by developers, instead as 
the Swift team’s feedback said `String.init(describing: T)` or 
`"\(interpolation)"` is to be used, and I think they can detect and fallback to 
`NSObject.description’ for Objective-C objects, e.g. in _print_unlocked() here: 
https://github.com/apple/swift/blob/cf73dd9177c231a15429b08ae889e94f20e53f50/stdlib/public/core/OutputStream.swift#L319

Not having ‘description’ taken means we can create a struct like so without 
clashing:

struct Channel {
  let title: String
  let link: NSURL
  let description: String
}

Patrick
 

> On 28 May 2016, at 1:51 PM, Austin Zheng <austinzh...@gmail.com> wrote:
> 
> Hello swift-evolution,
> 
> I've put together a preliminary v2 of the proposal, taking into account 
> feedback expressed on this thread. I would appreciate any comments, 
> suggestions, or criticisms.
> 
> https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md
>  
> <https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md>
> 
> If any objections can be worked out quickly, I hope to resubmit this proposal 
> for review early next week.
> 
> Best,
> Austin
> 
> 
> On Fri, May 27, 2016 at 7:50 PM, Patrick Smith via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Is there any possibility we can break from this? Especially as:
> 
> 1. ValuePreservingStringConvertible expects its description to be value 
> preserving, but current Cocoa implementations are not.
> 2. ‘Description’ doesn’t really convey the meaning of ‘value preserving’ in 
> my mind, but is a valuable name for many other use cases.
> 3. Swift 3 has a wide range of breaking changes for the better.
> 4. With the presence of ValuePreservingStringConvertible, 
> CustomStringConvertible doesn’t seem to provide much value over 
> CustomDebugStringConvertible?
> 
> For string interpolation, I imagine the standard library could fall back to a 
> ‘description’ method for NSObject subclasses.
> 
> Thanks,
> 
> Patrick
> 
> > On 28 May 2016, at 7:49 AM, Dave Abrahams via swift-evolution 
> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >
> >
> > on Thu May 26 2016, Patrick Smith <swift-evolution@swift.org 
> > <mailto:swift-evolution@swift.org>> wrote:
> >
> >>> On 27 May 2016, at 2:40 PM, Austin Zheng via swift-evolution 
> >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >>>
> >>> Any of the NSObject subclass candidates may require their
> >>> `description`s to be altered to meet the semantics, which may or may
> >>> not be an acceptable breaking change.
> >>
> >> Do you think it might be worth changing `description` to be named
> >> something else? Something more clear, l

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

A different way of layering could be allowing value types to be composed, where 
the outer type inherits the inner member’s properties and methods.

Let’s say you want only fields ‘contentID’ and ‘contentData' to participate in 
equality and hashing, but not ‘revisionID':

  struct ContentInfo : Equatable, Hashable { // Automatic implementations for 
== and hashValue are provided since members conform
let contentID: NSUUID
let contentData: NSData
  }

  struct RevisionInfo : Equatable, Hashable {
let revisionID: NSUUID
private let content: ContentInfo // Hidden from the outside world
public compose content // Adds .contentID, .contentData, .hashValue 
properties to RevisionInfo that delegate to those of `content`
  }

  func ==(lhs: RevisionInfo, rhs: RevisionInfo) -> Bool {
return lhs.content == rhs.content
  }


> On 28 May 2016, at 5:41 AM, plx via swift-evolution 
>  wrote:
> 
>> 
>> On May 27, 2016, at 10:48 AM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On May 27, 2016, at 10:37 AM, plx via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution 
 > wrote:
 
 A `deriving` keyword, at the very least, is pretty explicitly *not* an 
 all-or-nothing situation. If you want to define equality/hashability for 
 your type manually, don't use `deriving`. This should leave the simplest 
 cases to auto generation and anything more complex should be handled by 
 the developer.
>>> 
>>> It’s all-or-nothing in the sense you can’t use a naive `deriving` 
>>> implementation to assist in any case where what you need is *almost* the 
>>> trivial implementation, but not quite.
>>> 
>>> Consider a case like this:
>>> 
>>>   class QuxEvaluator  {
>>>   
>>> let foo: Foo // Equatable
>>> let bar: Bar // Equatable
>>> let baz: Baz // Equatable
>>> 
>>> private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]
>>> 
>>> // pure function of `foo`, `bar`, `baz`, and `identifier`
>>> // expensive, and uses `quxCache` for memoization 
>>> func qux(for identifier: QuxIdentifier) -> Qux
>>> 
>>>   }
>>> 
>>> …if it weren’t for `quxCache` we could easily synthesize `==` for 
>>> `QuxEvaluator`, but the trivial synthesis will yield invalid results due to 
>>> `[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also be 
>>> equatable once conditional conformances are in place).
>>> 
>>> So we’re back to e.g. writing this: 
>>> 
>>>   extension QuxEvaluator : Equatable {
>>> 
>>>   }
>>> 
>>>   func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
>>> return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar && 
>>> lhs.baz == rhs.baz)
>>>   }
>>> 
>>> …just to omit a single field from the `==` consideration; this is another 
>>> sense in which you can say deriving is an all-or-none; there’s just no way 
>>> to invoke the synthesis mechanism other than for "all fields”.
>> 
>> I don’t see why this must necessarily be the case.  Annotations such as you 
>> describe below could be taken into account by `deriving`.  `deriving` is 
>> just a way to invoke the synthesis mechanism.
> 
> Different people are using it differently I think; I agree with you if it’s 
> just the name of the invocation, but I think at least some people are using 
> it as a shorthand for the “naive” implementation (all fields equatable => 
> equatable).
> 
> That is, I meant "naive deriving” to refer to something like this (quoting 
> Patrick):
> 
>> It would fail if not all members were Equatable or Hashable. If it was 
>> automatic, you wouldn’t get any warning or sign at all. If you have to 
>> explicitly conform to the protocols, then your intention is clear, and if an 
>> automatic implementation cannot be made (because not all members were 
>> Equatable or Hashable), then you will get an error that you need to 
>> implement the protocol yourself like you do now (i.e. implement == and 
>> hashValue).
> 
> 
> …but I could’ve been clearer!
> 
>> 
>>> 
>>> On the one hand, it’s possible to imagine a finer-grained form of this 
>>> synthesis that’d allow you to e.g. indicate a certain field should be 
>>> omitted (and also perhaps specialize how fields are compared, customize the 
>>> synthesized comparison ordering to put cheaper comparisons earlier, and an 
>>> endless list of other possible requests…).
>> 
>> If you don’t trust the compiler to optimize this well and therefore want 
>> control over order of comparisons you should probably just implement it 
>> manually.  As you note below, this is a convenience feature that needs to 
>> strike a fine balance.
> 
> I agree, but at the same time i think that scenarios like this:
> 
>   struct RevisionInfo {
> let contentID: NSUUID
> let 

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Patrick Smith via swift-evolution]

Is there any possibility we can break from this? Especially as:

1. ValuePreservingStringConvertible expects its description to be value 
preserving, but current Cocoa implementations are not.
2. ‘Description’ doesn’t really convey the meaning of ‘value preserving’ in my 
mind, but is a valuable name for many other use cases.
3. Swift 3 has a wide range of breaking changes for the better.
4. With the presence of ValuePreservingStringConvertible, 
CustomStringConvertible doesn’t seem to provide much value over 
CustomDebugStringConvertible?

For string interpolation, I imagine the standard library could fall back to a 
‘description’ method for NSObject subclasses.

Thanks,

Patrick

> On 28 May 2016, at 7:49 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Thu May 26 2016, Patrick Smith  wrote:
> 
>>> On 27 May 2016, at 2:40 PM, Austin Zheng via swift-evolution 
>>>  wrote:
>>> 
>>> Any of the NSObject subclass candidates may require their
>>> `description`s to be altered to meet the semantics, which may or may
>>> not be an acceptable breaking change.
>> 
>> Do you think it might be worth changing `description` to be named
>> something else? Something more clear, less likely to conflict with
>> ‘real’ properties — ‘description’ doesn’t seem to portray something
>> that is value-preserving. What is the reason for calling it
>> ‘description’?
> 
> The main reason was backward compatibility with Cocoa, which already has
> a “description” property.
> 
>> Especially if NSObject subclasses won’t fit, then why not have a
>> different method that can be strictly value preserving? (Then
>> `description` can stay being an NSObject thing.)
> 
> -- 
> 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] Circling back to `with`

[Patrick Smith via swift-evolution]

Just some alternate naming suggestions for with() and withVar(), as the naming 
guidelines suggest -ed/-ing:

withVar
altered() // Changes a value copy / reference and returns it
mutated() // Or this, but uses value-specific term ‘mutate’

with
inspect() // Works with an immutable copy, has @discardableResult
use()


> On 28 May 2016, at 10:19 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>> - A plain `with` whose closure parameter is not mutable and which is marked 
>>> `@discardableResult`.
>> 
>> I would like to see this version restricted to AnyObject.  It has extremely 
>> limited utility with value types.  It would usually be a mistake to call it 
>> with a value type.
> 
> I would not. It gives you a way to give a value type a short, scoped, 
> immutable alias:
> 
>   with(RareMagicalDeviceOwner.shared.spimsterWickets[randomIndex]) {
>   print($0.turns)
>   print($0.turnSpeed)
>   }
> 
> And in this form, there is no danger of mistakenly mutating the value type, 
> because mutating methods would not be allowed:
> 
>   with(RareMagicalDeviceOwner.shared.spimsterWickets[randomIndex]) {
>   $0.turnRepeatedly(times: 3) // Error: can't call mutating 
> method on immutable parameter
>   }
> 
> To be clear, I'm not convinced there's a need to make any change from the 
> proposed version at all. I'm spitballing alternate designs here, trying to 
> see if there might be something a little better out there. But so far, I 
> think the proposal balances the feature size against strictness pretty well, 
> whereas these stricter designs I'm discussing increase the surface of the 
> feature more than they improve it. This is a small (but significant!) 
> convenience, and I feel pretty strongly that it should have a small 
> implementation.
> 
>> That said, I am not convinced these non-copying functions would be worth 
>> having after method cascades are introduced.  Are there any use cases left 
>> for them in that future?
> 
> Yes, absolutely. Method cascades have a narrow use case: methods on `self`. 
> Not everything in Swift is a method, and not all methods are on `self`.
> 
>   with(tableView.cellForRow(at: indexPath).myLabel) { label in
>   print("Constraining label: \(label)")
>   
>   NSLayoutConstraint.activate(
>   NSLayoutConstraint.withVisualFormat("|-[label]-|", 
> options: [], metrics: [:], views: ["label": label]) +
>   NSLayoutConstraint.withVisualFormat("V:|[label]|", 
> options: [], metrics: [:], views: ["label": label])
>   )
>   
>   constrainedLabels.append(label)
>   }
> 
> None of the calls in that `with` block would benefit from method cascades, 
> but they all benefit from `with`.
> 
>>> - A `withVar` whose parameter *is* mutable and which is *not* marked 
>>> `@discardableResult`. (This would help with the fact that our use of 
>>> `@discardableResult` is a little dangerous, in that people might expect 
>>> mutations to affect the original variable even if it's a value type.)
>>> 
>>> `withVar` does, I think, make it pretty clear that you're working with a 
>>> copy of the variable.
>> 
>> One thing to consider in choosing a name here is the cases where this 
>> function would still be useful in a future that includes method cascades.  
>> The one thing this function does that method cascades don’t is make a copy 
>> of the value before operating on it and returning it.  
>> 
>> With that in mind, I think it is worthwhile to consider the name `withCopy` 
>> and make the closure argument optional.
> 
> I specifically considered and rejected `withCopy` because it only creates a 
> copy of a value type, not a reference type. (Of course, it does create a copy 
> of the reference itself, but that's a very subtle distinction.) I chose 
> `withVar` to make it very clear that you're getting the same semantics as you 
> would for a `var` temporary.
> 
>> public func withCopy(_ item: T, update: (@noescape (inout T) throws -> 
>> Void)?) rethrows -> T {
>>   var this = item
>>   try update?()
>>   return this
>> }
>> 
>> This function would be more clear and useful in conjunction with method 
>> cascades:
>> 
>> let bar = withCopy(foo)
>>   ..cascaded = “value"
>>   ..operations()
>>   ..onFoo()
> 
> Honestly, I'm not sure there's a coherent way to make method cascades work 
> with your `withCopy` (or the `copy` function you mentioned upthread) at all.
> 
> Here's the problem. Suppose you have a property like this:
> 
>   var array: [Int]
> 
> And then you write this:
> 
>   array = [1, 2, 3]
>   return array
>   ..remove(at: 1)
>   ..remove(at: 0)
> 
> I assume you think this should not only *return* `[3]`, but also *set* 
> `array` to `[3]`. That's kind of implied by the fact that you think we need a 
> `withCopy(array)` call to 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

It would fail if not all members were Equatable or Hashable. If it was 
automatic, you wouldn’t get any warning or sign at all. If you have to 
explicitly conform to the protocols, then your intention is clear, and if an 
automatic implementation cannot be made (because not all members were Equatable 
or Hashable), then you will get an error that you need to implement the 
protocol yourself like you do now (i.e. implement == and hashValue).

Patrick

> On 28 May 2016, at 1:38 AM, Ricardo Parada  wrote:
> 
> When would the automatic implementation fail?
> 
> I see your point about adding to the compile size and I had previously 
> mentioned that. Usually in the apps I develop that is not a concern. However 
> I can see it could be a concern for apps that are more restrictive. If Swift 
> is to be used to build such apps too then I agree that not being automatic 
> would be important. It would have to be opt-in. I would be okay with that 
> solution. Hopefully most would make use of it in high-level frameworks.
> 
> I guess similar to reflection and enabling dynamism. I look forward to 
> eventually being able to do key-value-coding in pure Swift and being able to 
> implement a framework similar to WebObjects which would require being able to 
> find properties by their name, getting and setting values. That would be 
> another example of opting in for a richer run-time. 
> 
> 
> On May 27, 2016, at 10:11 AM, Patrick Smith  > wrote:
> 
>> If you have to specify Equatable / Hashable, then you can get an error if 
>> the automatic implementation failed, due to a member also not being 
>> Equatable/Hashable. If it’s automatic, then it will just quietly fail, 
>> making problems harder to know about and track. It will also always add to 
>> the compile size, even if you didn’t want the functionality.
>> 
>> 
>>> On 27 May 2016, at 10:46 PM, Ricardo Parada >> > wrote:
>>> 
>>> I agree, I think there is no need for deriving/synthesizes, but also, no 
>>> need to specify Equatable, Hashable. They should get the functionality by 
>>> default but allow for override and customization. 
>>> 
>>> 
>>> On May 26, 2016, at 11:02 PM, Patrick Smith >> > wrote:
>>> 
 I don’t understand why you couldn’t conform to Equatable, and if it 
 fulfils the requirements (all members are also Equatable), then its 
 implementation is automatically created for you. That way you don’t need a 
 new keyword. It’s like Objective-C’s property automatic synthesising that 
 get used unless you implement ones yourself.
 
 
> On 27 May 2016, at 12:57 PM, Ricardo Parada via swift-evolution 
> > wrote:
> 
> 
> 
> I wonder if synthesizes would be a better choice than deriving. 
> 
> 
> 
> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
> > wrote:
> 
>> Can we just copy the solution from Haskell instead of creating our 
>> own? It's just better in every aspect. Deriving `Equatable` and 
>> `Hashable` would become
>> 
>> struct Polygon deriving Equatable, Hashable {
>>...
>> }
>> 
>> This has several advantages:
>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>> automatically derived or not.
>> - Deriving becomes an explicit choice.
>> - If you need a custom `Equatable` implementation (for whatever reason), 
>> you can still do it.
>> - It doesn't break any code that is unaware of the change
>> - It can be extended in future versions of Swift, without introducing 
>> any new incompatibilities. For example, `CustomStringConvertible` could 
>> be derived just as easily.
>> - It is compatible with generics. E.g. `struct Shape deriving 
>> Equatable` will make every `Shape` equatable if `X` is equatable. But 
>> if `X` is not equatable, `Shape` can be used as well. (Unless `X` is 
>> not used, in which case every `Shape` would be equatable. Unless 
>> something in the definition of `Shape` makes deriving `Equatable` 
>> impossible => this produces an error.)
>> - It is proven to work in production.
>> 
>> -Michael
>> 
>>> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>>> >:
>>> 
>>> Thanks so much for putting this together, Tony! Glad I was able to be 
>>> some inspiration. :^)
>>> 
>>> 
>>> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>>> > wrote:
>>> I was inspired to put together a draft proposal based on an older 
>>> discussion in the 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

If you have to specify Equatable / Hashable, then you can get an error if the 
automatic implementation failed, due to a member also not being 
Equatable/Hashable. If it’s automatic, then it will just quietly fail, making 
problems harder to know about and track. It will also always add to the compile 
size, even if you didn’t want the functionality.


> On 27 May 2016, at 10:46 PM, Ricardo Parada  wrote:
> 
> I agree, I think there is no need for deriving/synthesizes, but also, no need 
> to specify Equatable, Hashable. They should get the functionality by default 
> but allow for override and customization. 
> 
> 
> On May 26, 2016, at 11:02 PM, Patrick Smith  > wrote:
> 
>> I don’t understand why you couldn’t conform to Equatable, and if it fulfils 
>> the requirements (all members are also Equatable), then its implementation 
>> is automatically created for you. That way you don’t need a new keyword. 
>> It’s like Objective-C’s property automatic synthesising that get used unless 
>> you implement ones yourself.
>> 
>> 
>>> On 27 May 2016, at 12:57 PM, Ricardo Parada via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
>>> I wonder if synthesizes would be a better choice than deriving. 
>>> 
>>> 
>>> 
>>> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
>>> > wrote:
>>> 
 Can we just copy the solution from Haskell instead of creating our 
 own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
 would become
 
 struct Polygon deriving Equatable, Hashable {
...
 }
 
 This has several advantages:
 - you don't have to guess wether `Equatable` or `Hashable` should be 
 automatically derived or not.
 - Deriving becomes an explicit choice.
 - If you need a custom `Equatable` implementation (for whatever reason), 
 you can still do it.
 - It doesn't break any code that is unaware of the change
 - It can be extended in future versions of Swift, without introducing any 
 new incompatibilities. For example, `CustomStringConvertible` could be 
 derived just as easily.
 - It is compatible with generics. E.g. `struct Shape deriving 
 Equatable` will make every `Shape` equatable if `X` is equatable. But 
 if `X` is not equatable, `Shape` can be used as well. (Unless `X` is 
 not used, in which case every `Shape` would be equatable. Unless 
 something in the definition of `Shape` makes deriving `Equatable` 
 impossible => this produces an error.)
 - It is proven to work in production.
 
 -Michael
 
> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
> >:
> 
> Thanks so much for putting this together, Tony! Glad I was able to be 
> some inspiration. :^)
> 
> 
> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
> > wrote:
> I was inspired to put together a draft proposal based on an older 
> discussion in the Universal Equality, Hashability, and Comparability 
> thread  > that 
> recently got necromanced (thanks Mark Sands!).
> 
> I'm guessing that this would be a significant enough change that it's not 
> possible for the Swift 3 timeline, but it's something that would benefit 
> enough people that I want to make sure the discussion stays alive. If 
> there are enough good feelings about it, I'll move it from my gist into 
> an actual proposal PR.
> 
> Automatically deriving Equatable andHashable for value types
> 
>• Proposal: SE-
>• Author(s): Tony Allevato
>• Status: Awaiting review
>• Review manager: TBD
> Introduction
> 
> Value types are prevalent throughout the Swift language, and we encourage 
> developers to think in those terms when writing their own types. 
> Frequently, developers find themselves writing large amounts of 
> boilerplate code to support equatability and hashability of value types. 
> This proposal offers a way for the compiler to automatically derive 
> conformance toEquatable and Hashable to reduce this boilerplate, in a 
> subset of scenarios where generating the correct implementation is likely 
> to be possible.
> 
> Swift-evolution thread: Universal Equatability, Hashability, and 
> Comparability
> 
> Motivation
> 
> Building robust value types in Swift can involve writing significant 
> boilerplate code to support concepts of hashability and equatability. 
> Equality is 

Re: [swift-evolution] [Pitch] Property reflection

[Patrick Smith via swift-evolution]

Here’s an idea using enums. They work similar to a lens, where they are 
separate from the actual instance. So you can convert string keys or validate 
potential values without needing an instance.

The PropertyIdentifierProtocol is implemented by an string representable enum, 
piggy backing on its failable initializer for converting from strings.
The PropertyStateProtocol, implemented by an enum with associated values, 
encapsulates a property in a type-safe manner, allowing it to be extracted as 
an entity then applied to other instances. It has a failable initializer for 
validating a value.

https://gist.github.com/BurntCaramel/315ee4dfca0c240755b534e1a5ee183f


> On 27 May 2016, at 11:30 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> Property descriptors could be useful in the sense that they wouldn't need to 
> refer back to the instance.  But I would also like to see a way to get 
> something like a lens into the property for a specific instance which is what 
> the views allow for.  This design doesn't allow for that.  Maybe we want to 
> allow you to query for property descriptors alone, lenses alone, or the 
> combination in a view.

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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Patrick Smith via swift-evolution]

> On 27 May 2016, at 2:40 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> Any of the NSObject subclass candidates may require their `description`s to 
> be altered to meet the semantics, which may or may not be an acceptable 
> breaking change.

Do you think it might be worth changing `description` to be named something 
else? Something more clear, less likely to conflict with ‘real’ properties — 
‘description’ doesn’t seem to portray something that is value-preserving. What 
is the reason for calling it ‘description’?

Especially if NSObject subclasses won’t fit, then why not have a different 
method that can be strictly value preserving? (Then `description` can stay 
being an NSObject thing.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Patrick Smith via swift-evolution]

> On 26 May 2016, at 5:40 PM, David Hart  wrote:
> 
> I’ve always found those two confusing. But I guess that 
> CustomDebugStringConvertible could provide more information, like the actual 
> type and pointer value. For example, imagine that we make UIColor 
> ValuePreservingStringConvertible, one implementation could look like:
> 
> let a = UIColor(red: 0, green: 0, blue: 0)
> a.description // #00
> a.debugDescription // 

This distinction seems a little arbitrary to me. However, something like 
`preservedString` would make more sense to me:

let a = UIColor(red: 0, green: 0, blue: 0)
a.preservedString // #00 — or perhaps more accurate: rgba(0.0,0.0,0.0,1.0)
a.debugDescription // 

This why I think it makes sense to really differentiate `description` from 
`debugDescription`, so it’s no long ‘confusing’ as you say.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

I don’t understand why you couldn’t conform to Equatable, and if it fulfils the 
requirements (all members are also Equatable), then its implementation is 
automatically created for you. That way you don’t need a new keyword. It’s like 
Objective-C’s property automatic synthesising that get used unless you 
implement ones yourself.


> On 27 May 2016, at 12:57 PM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> 
> 
> I wonder if synthesizes would be a better choice than deriving. 
> 
> 
> 
> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
> > wrote:
> 
>> Can we just copy the solution from Haskell instead of creating our 
>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
>> would become
>> 
>> struct Polygon deriving Equatable, Hashable {
>>...
>> }
>> 
>> This has several advantages:
>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>> automatically derived or not.
>> - Deriving becomes an explicit choice.
>> - If you need a custom `Equatable` implementation (for whatever reason), you 
>> can still do it.
>> - It doesn't break any code that is unaware of the change
>> - It can be extended in future versions of Swift, without introducing any 
>> new incompatibilities. For example, `CustomStringConvertible` could be 
>> derived just as easily.
>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>> equatable, `Shape` can be used as well. (Unless `X` is not used, in which 
>> case every `Shape` would be equatable. Unless something in the definition 
>> of `Shape` makes deriving `Equatable` impossible => this produces an error.)
>> - It is proven to work in production.
>> 
>> -Michael
>> 
>>> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>>> >:
>>> 
>>> Thanks so much for putting this together, Tony! Glad I was able to be some 
>>> inspiration. :^)
>>> 
>>> 
>>> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>>> > wrote:
>>> I was inspired to put together a draft proposal based on an older 
>>> discussion in the Universal Equality, Hashability, and Comparability thread 
>>> >> > that 
>>> recently got necromanced (thanks Mark Sands!).
>>> 
>>> I'm guessing that this would be a significant enough change that it's not 
>>> possible for the Swift 3 timeline, but it's something that would benefit 
>>> enough people that I want to make sure the discussion stays alive. If there 
>>> are enough good feelings about it, I'll move it from my gist into an actual 
>>> proposal PR.
>>> 
>>> Automatically deriving Equatable andHashable for value types
>>> 
>>>• Proposal: SE-
>>>• Author(s): Tony Allevato
>>>• Status: Awaiting review
>>>• Review manager: TBD
>>> Introduction
>>> 
>>> Value types are prevalent throughout the Swift language, and we encourage 
>>> developers to think in those terms when writing their own types. 
>>> Frequently, developers find themselves writing large amounts of boilerplate 
>>> code to support equatability and hashability of value types. This proposal 
>>> offers a way for the compiler to automatically derive conformance 
>>> toEquatable and Hashable to reduce this boilerplate, in a subset of 
>>> scenarios where generating the correct implementation is likely to be 
>>> possible.
>>> 
>>> Swift-evolution thread: Universal Equatability, Hashability, and 
>>> Comparability
>>> 
>>> Motivation
>>> 
>>> Building robust value types in Swift can involve writing significant 
>>> boilerplate code to support concepts of hashability and equatability. 
>>> Equality is pervasive across many value types, and for each one users must 
>>> implement the == operator such that it performs a fairly rote memberwise 
>>> equality test. As an example, an equality test for a struct looks fairly 
>>> uninteresting:
>>> 
>>> func ==(lhs: Foo, rhs: Foo) -> Bool
>>> {
>>> 
>>> return lhs.property1 == rhs.property1 &&
>>> 
>>> lhs
>>> .property2 == rhs.property2 &&
>>> 
>>> lhs
>>> .property3 == rhs.property3 &&
>>> 
>>> 
>>> ...
>>> 
>>> }
>>> 
>>> What's worse is that this operator must be updated if any properties are 
>>> added, removed, or changed, and since it must be manually written, it's 
>>> possible to get it wrong, either by omission or typographical error.
>>> 
>>> Likewise, hashability is necessary when one wishes to store a value type in 
>>> a Set or use one as a multi-valuedDictionary key. Writing high-quality, 
>>> well-distributed hash functions is not trivial so developers may not put a 
>>> great deal of thought into 

Re: [swift-evolution] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Patrick Smith via swift-evolution]

These are some great points. I like the sound of 
ValuePreservingStringConvertible. A few questions to add:

- If its conformers produce a value-preserving representation, would it make 
sense for it to also have an initializer accepting the value? What specifically 
makes it value preserving otherwise?

- What is the difference between CustomStringConvertible and 
CustomDebugStringConvertible? Are most implementations of description and 
debugDescription identical? It says CustomStringConvertible is for writing to 
an output stream. Is a ‘value preserving string’ going to be a better fit for 
that all the time?

- To the question of ‘is CustomStringConvertible enough?’, what about replacing 
it with ValuePreservingStringConvertible? Then there are two very distinct 
protocols: ValuePreservingStringConvertible and CustomDebugStringConvertible, 
one obviously safely value preserving and one obviously just for inspecting.

- Could `.description` be renamed to something more specific and clear? For 
example, `preservedValue` or `.valuePreservingDescription`. If the recommended 
way is to use `init(_ v: T)`, will anybody 
be using `.description` directly anyway? I always found NSObject’s seize of the 
‘description’ property annoying, as on models it’s a perfect valid property to 
want as a member, so I was a little disappointed to see it in Swift too. If 
there’s an alternative, more clear name for this property then it won’t clash 
with anything else.

I like this clear separation of ‘value preserving’ and ‘just show me something’ 
representations.

Patrick


> On 26 May 2016, at 3:08 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
> 
> The review of "SE-0089: Renaming String.init(_: T)" ran from May 17…23, 
> 2016. The proposal has been *returned for revision* and another round of 
> discussion - the core team would love to see the revised proposal make it 
> into Swift 3.
> 
> The community and core team both want to remove this “footgun” from the 
> standard library, where someone could write "String(x)” with the intention of 
> getting a value-preserving conversion to String, but may instead get a 
> potentially lossy and potentially expensive reflection-based conversion to a 
> String.  After extensive discussion, the core team recommends that the 
> community consider a somewhat more elaborate design:
> 
> - Rename the existing reflection-based "String.init(_: T)” initializer to 
> "String.init(describing: T)” as recommend by the community.  This 
> initializer would rarely be invoked in user code directly.
> 
> - Introduce a new protocol (for sake of discussion, call it 
> “ValuePreservingStringConvertible") that refines CustomStringConvertible but 
> that adds no new requirements.  Conformance to this protocol indicates that 
> the “description” requirement produces a value-preserving representation in 
> String form.
> 
> - Introduce a new unlabeled initializer on String: "init ValuePreservingStringConvertible>(_ v: T) { return v.description }".  This 
> permits the “String(x)” syntax to be used on all values of types that can be 
> converted to string in a value-preserving way.
> 
> - Audit important standard library types (e.g. the integer and floating point 
> types), and make them explicitly conform to ValuePreservingStringConvertible 
> with an explicitly implemented “description” property.
> 
> - As a performance optimization, change the implementation of the string 
> literal interpolation syntax to prefer the unlabeled initializer when 
> interpolating a type that is ValuePreservingStringConvertible or that has 
> otherwise has an unlabeled String initializer, but use the 
> "String.init(describing: T)” initializer if not.
> 
> 
> The expected advantages of this design are:
> 
> - Swift encourages the T(x) syntax for value preserving conversions, and this 
> design ensures that String(x) continues to work for the value preserving 
> cases.
> 
> - This ensures that the String(x) syntax does not accidentally fall off a 
> performance cliff by using the extremely-dynamic reflection mechanism 
> unintentionally.
> 
> - The preferred “I don’t care how you do it, just convert this value to a 
> string somehow” syntax remains string interpolation syntax.  This syntax is 
> efficient in the cases where the String(x) syntax is allowed, but fully 
> general to the other cases where custom convert-to-string code has not been 
> provided.
> 
> 
> Some remaining open questions:
> 
> - Exactly what types should conform to ValuePreservingStringConvertible.  It 
> seems clear that integer, floating point types, and Character can and should 
> conform.  What other types should?
> 
> - Do we need the ValuePreservingStringConvertible at all, or is the existing 
> CustomStringConvertible enough?  We already have a few protocols for handling 
> string 

Re: [swift-evolution] [Pitch] Remove associated type inference

[Patrick Smith via swift-evolution]

While this has been a handy feature, I don’t mind making things more explicit, 
as I think it helps communication. Sometimes clarity that helps the compiler 
will also help the reader. It’s only really convenient when writing.

I would be happy with this change as long as the issue with same named generics 
were changed. Currently in Swift 2.2 I can’t do this:

struct SomeGenericGenerator : GeneratorType {
  typealias Element = Element // Error: Type alias ‘Element’ circularly 
references itself
}

It’s a real pain, as now I have to think up some alternate name for the generic 
parameter ‘Element’.

Whereas, with automatic inference, I can do this without the compiler 
complaining:

struct SomeGenericGenerator : GeneratorType {
  mutating func next() -> Element? {
return nil
  }
}

So I’d like to see the above `typealias Element = Element` allowed if possible.


> On 26 May 2016, at 7:43 AM, David Hart via swift-evolution 
>  wrote:
> 
> Here’s a pitch for removing associated type inference as per the Generics 
> Manifesto. If we want to do it, we’d better do it before Swift 3:
> 
> Remove associated type inference
> 
> Proposal: SE- 
> 
> Author: David Hart , Douglas Gregor 
> 
> Status: TBD
> Review manager: TBD
>  
> Introduction
> 
> This proposal seeks to remove the inference of associated types in types 
> conforming to protocols.
> 
>  
> Motivation
> 
> Even if associated types inference in a useful feature, it is also a big 
> source of bugs in the compiler. This proposal argues that the usefulness does 
> not outweight its architectural complexity. As per the Generics Manifesto 
> :
> 
> associated type inference is the only place in Swift where we have a global 
> type inference problem: it has historically been a major source of bugs, and 
> implementing it fully and correctly requires a drastically different 
> architecture to the type checker.
> Because this is a breaking change, it would be beneficial to implement it for 
> Swift 3. 
> 
>  
> Detailed
>  Design
> 
> The proposal would remove associated type inference and make code which 
> relied on it invalid:
> 
> protocol IteratorProtocol {
>   associatedtype Element
>   mutating func next() -> Element?
> }
> 
> struct IntIterator : IteratorProtocol {
>   mutating func next() -> Int? { ... }  // used to infer Element = Int
> }
> The compiler would generate an error message stating: error: IntIterator is 
> missing its Element associated type declaration. The code would have to be 
> modified as follows to fix the error:
> 
> struct IntIterator : IteratorProtocol {
> typealias Element = Int
> mutating func next() -> Int? { return nil }  // used to infer Element = 
> Int
> }
>  
> Impact
>  on Existing Code
> 
> This is a breaking change that will require conforming types which relied on 
> the inference, including in the Standard Library, to explicitly declare 
> associated types. A Fix-It could be introduced to add the typealias and leave 
> the type to be filled in. That way, all the type inference could be removed 
> from the compiler.
> 
>  
> Alternatives
>  Considered
> 
> The only alternative is to keep the inference with the known consequences on 
> the compiler.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Enums with static stored properties foreach case

[Patrick Smith via swift-evolution]

Raw values are for coverting to and from an external representation only. 
That’s why it must be a primitive value, as they can be checked for equality in 
`init?(rawValue:)`.

The planets here have fuzzy floating point values, and so must never be checked 
for equality. The only source of truth are their names.

If you want a list of planets, the best way is to do this:

struct Planet {
  var mass: Float
  var radius: Float
  
  static let mercury = Planet(mass: 3.303e+23, radius: 2.4397e6)
  static let venus = Planet(mass: 4.869e+24, radius: 6.0518e6)
  static let earth = Planet(mass: 5.976e+24, radius: 6.37814e6)
  static let mars = Planet(mass: 6.421e+23, radius: 3.3972e6)
  static let jupiter = Planet(mass: 1.9e+27, radius: 7.1492e7)
  static let saturn = Planet(mass: 5.688e+26, radius: 6.0268e7)
  static let uranus = Planet(mass: 8.686e+25, radius: 2.5559e7)
  static let neptune = Planet(mass: 1.024e+26, radius: 2.4746e7)
}


What this proposal is asking for is an easier way to have derived values from 
enum cases. Asking for more flexible RawValues means mass and radius are not 
derived, they are the source of truth. It goes against the whole point of 
RawRepresentable. You are not saying ‘Mercury is identified by the case 
.mercury’, you are saying ‘Mercury is identified by a mass of 3.303e+23’. It’s 
backwards.


> On 26 May 2016, at 1:47 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On May 25, 2016, at 10:27 PM, Jacob Bandes-Storch > > wrote:
>> 
>> On Wed, May 25, 2016 at 8:15 PM, David Sweeris via swift-evolution 
>> > wrote:
>> On May 25, 2016, at 7:37 AM, Leonardo Pessoa via swift-evolution 
>> > wrote:
>>> 
>>> Hi,
>>> 
>>> Couldn't this be solved by using tuples? If not because the syntax is not 
>>> allowed I think this would be more coherent to do it using current syntax.
>>> 
>>> enum Planet : (mass: Float, radius: Float) {
>>> case mercury = (mass: 3.303e+23, radius: 2.4397e6)
>>> case venus = (mass: 4.869e+24, radius: 6.0518e6)
>>> case earth = (mass: 5.976e+24, radius: 6.37814e6)
>>> case mars = (mass: 6.421e+23, radius: 3.3972e6)
>>> case jupiter = (mass: 1.9e+27, radius: 7.1492e7)
>>> case saturn = (mass: 5.688e+26, radius: 6.0268e7)
>>> case uranus = (mass: 8.686e+25, radius: 2.5559e7)
>>> case neptune = (mass: 1.024e+26, radius: 2.4746e7)
>>> }
>> 
>> 
>> This would be my preferred solution… AFAIK, the only reason we can’t do it 
>> now is that Swift currently requires RawValue be an integer, floating-point 
>> value, or string. I don’t know why the language has this restriction, so I 
>> can’t comment on how hard it would be to change.
>> 
>> - Dave Sweeris
>> 
>> Except you'd have to write Planet.mercury.rawValue.mass, rather than 
>> Planet.mercury.mass.
>> 
>> This could be one or two proposals: allow enums with tuple RawValues, and 
>> allow `TupleName.caseName.propertyName` to access a tuple element without 
>> going through .rawValue.
> 
> Good point… Has there been a thread on allowing raw-valued enums to be 
> treated as constants of type `RawValue` yet? Either way, removing the 
> restriction on what types can be a RawValue is still my preferred solution.
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal] Enums with static stored propertiesforeach case

[Patrick Smith via swift-evolution]

Yes, that would be a great behaviour, but that’s exactly how enums with raw 
values do not work. The enum cases transform to and from an external 
representable form, that’s why it is ‘RawRepresentable’. So in your example of 
tuples, that representable form would be the tuple values themselves.

I agree about having enum cases as strings is handy. For your described case it 
is best to use a String as the raw value type, and the derived values as 
calculated properties. It would be handy, as we are discussing, to declare 
those calculated properties in an easier manner, and I would’t mind if it used 
a tuple syntax. But it should’t be used as the underlying value, as this is the 
source of ‘truth’ for the enum.


> On 26 May 2016, at 12:09 PM, Leonardo Pessoa  wrote:
> 
> I'd still go with tuple syntax as it feels more like a natural extension to 
> current enum syntax and does not introduce new elements to the syntax of 
> enums (other than add tuples as a possible enum value type) thus being 
> simpler and faster to implement and learn than a new syntax built 
> specifically for this kind of construction.
> 
> As I mentioned before, the issue with JSON and other engines trying to record 
> the raw value instead of the enum seems to me as a wrong implementation 
> choice of the engine. Previous to Swift enums I've always seen enum cases the 
> same as constants and any additional values they'd hold are associated with 
> that constant and not persisted. This may also be a thing from the company I 
> work for today that choses to store the names of the enum cases (as strings) 
> in databases and any values associated with them are recovered from the enum 
> case constant. Of course the language I work with supports finding the enum 
> value by its name, which it seems Swift doesn't.
> 
> From: Patrick Smith 
> Sent: ‎25/‎05/‎2016 10:20 PM
> To: Jānis Kiršteins 
> Cc: Leonardo Pessoa ; swift-evolution@swift.org 
> 
> Subject: Re: [swift-evolution] [Proposal] Enums with static stored 
> propertiesforeach case
> 
> Yes, I don’t think it would work with a raw value behaviour. You want it to 
> compile down to the same underlying code as the first example, without having 
> to write lots of switch statements.
> 
> Another syntax I could imagine is:
> 
> enum Planet {
>   var mass: Float { get }
>   var radius: Float { get }
> 
>   case mercury [
> mass: 3.303e+23,
> radius: 2.4397e6
>   ]
>   case venus [
> mass: 4.869e+24,
> radius: 6.0518e6
>   ]
>   case earth [
> mass: 5.976e+24,
> radius: 6.37814e6
>   ]
>   ...
> }
> 
> 
> You couldn’t have an initializer, as enums only have storage when they have 
> associated values, which these do not. ‘where’ is used for pattern matching, 
> not declaring as far as I know, so that’s why I suggest this other way.
> 
> Patrick
> 
> > On 26 May 2016, at 5:50 AM, Jānis Kiršteins via swift-evolution 
> >  wrote:
> > 
> > That would replace current enum raw value functionality and I see two
> > problems with that.
> > 
> > 1. A lot of breaking changes
> > 2. Raw values currently are unique values among all cases. That makes
> > a possibility that enums can be easily serialized/deserialized to
> > formats like JSON, property lists, etc. In "case mercury = (mass:
> > 3.303e+23, radius: 2.4397e6)" neither mass nor radius is unique value
> > (it is possible that two different planets could have the same mass as
> > radius).
> > 
> > 
> > 
> > On Wed, May 25, 2016 at 3:37 PM, Leonardo Pessoa  wrote:
> >> Hi,
> >> 
> >> Couldn't this be solved by using tuples? If not because the syntax is not
> >> allowed I think this would be more coherent to do it using current syntax.
> >> 
> >> enum Planet : (mass: Float, radius: Float) {
> >>case mercury = (mass: 3.303e+23, radius: 2.4397e6)
> >>case venus = (mass: 4.869e+24, radius: 6.0518e6)
> >>case earth = (mass: 5.976e+24, radius: 6.37814e6)
> >>case mars = (mass: 6.421e+23, radius: 3.3972e6)
> >>case jupiter = (mass: 1.9e+27, radius: 7.1492e7)
> >>case saturn = (mass: 5.688e+26, radius: 6.0268e7)
> >>case uranus = (mass: 8.686e+25, radius: 2.5559e7)
> >>case neptune = (mass: 1.024e+26, radius: 2.4746e7)
> >> }
> >> 
> >> From: Jānis Kiršteins via swift-evolution
> >> Sent: ‎25/‎05/‎2016 08:58 AM
> >> To: swift-evolution@swift.org
> >> Subject: [swift-evolution] [Proposal] Enums with static stored properties
> >> foreach case
> >> 
> >> Hello everyone,
> >> 
> >> Currently Swift only supports computed properties for each enum case.
> >> If you want to somehow get static values with each case you would
> >> probably do it like this:
> >> 
> >> enum Planet {
> >>case mercury
> >>case venus
> >>case earth
> >>case mars
> >>case jupiter
> >>case 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

This would be very handy! It’s one of those rare scenarios where I think “I 
can’t believe Swift makes me type all this out, there must be an easier way”.

I think explicitly conformance to Equatable and Hashable would be preferable. 
This means if one of the members is not Equable/Hashable, the user knows by 
getting an error of ‘Does not conform to Equatable, must implement func ==’ at 
the type level rather than scratching their head when instances are not 
automatically Equatable. It also means code is only generated when it is needed.

There’s a small typo (before [sic] below):

> On 26 May 2016, at 4:28 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> As with raw-value enums today, should the derived conformance be completely 
> explicit [sic], or should users have to explicitly list conformance with 
> Equatable and Hashable in order for the compiler to generate the derived 
> implementation?

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

Re: [swift-evolution] [Pitch] Allow explicit specialization of generic functions

[Patrick Smith via swift-evolution]

Sounds good to me. So it matches the order of the generic parameters?

e.g.

func foo(t: T, u: U) { … }

let f1 = foo

So if the function declaration was changed to swap T and U, it would break, 
same as say a generic struct type.

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

Re: [swift-evolution] [Proposal] Enums with static stored properties foreach case

[Patrick Smith via swift-evolution]

Yes, I don’t think it would work with a raw value behaviour. You want it to 
compile down to the same underlying code as the first example, without having 
to write lots of switch statements.

Another syntax I could imagine is:

enum Planet {
  var mass: Float { get }
  var radius: Float { get }

  case mercury [
mass: 3.303e+23,
radius: 2.4397e6
  ]
  case venus [
mass: 4.869e+24,
radius: 6.0518e6
  ]
  case earth [
mass: 5.976e+24,
radius: 6.37814e6
  ]
  ...
}


You couldn’t have an initializer, as enums only have storage when they have 
associated values, which these do not. ‘where’ is used for pattern matching, 
not declaring as far as I know, so that’s why I suggest this other way.

Patrick

> On 26 May 2016, at 5:50 AM, Jānis Kiršteins via swift-evolution 
>  wrote:
> 
> That would replace current enum raw value functionality and I see two
> problems with that.
> 
> 1. A lot of breaking changes
> 2. Raw values currently are unique values among all cases. That makes
> a possibility that enums can be easily serialized/deserialized to
> formats like JSON, property lists, etc. In "case mercury = (mass:
> 3.303e+23, radius: 2.4397e6)" neither mass nor radius is unique value
> (it is possible that two different planets could have the same mass as
> radius).
> 
> 
> 
> On Wed, May 25, 2016 at 3:37 PM, Leonardo Pessoa  wrote:
>> Hi,
>> 
>> Couldn't this be solved by using tuples? If not because the syntax is not
>> allowed I think this would be more coherent to do it using current syntax.
>> 
>> enum Planet : (mass: Float, radius: Float) {
>>case mercury = (mass: 3.303e+23, radius: 2.4397e6)
>>case venus = (mass: 4.869e+24, radius: 6.0518e6)
>>case earth = (mass: 5.976e+24, radius: 6.37814e6)
>>case mars = (mass: 6.421e+23, radius: 3.3972e6)
>>case jupiter = (mass: 1.9e+27, radius: 7.1492e7)
>>case saturn = (mass: 5.688e+26, radius: 6.0268e7)
>>case uranus = (mass: 8.686e+25, radius: 2.5559e7)
>>case neptune = (mass: 1.024e+26, radius: 2.4746e7)
>> }
>> 
>> From: Jānis Kiršteins via swift-evolution
>> Sent: ‎25/‎05/‎2016 08:58 AM
>> To: swift-evolution@swift.org
>> Subject: [swift-evolution] [Proposal] Enums with static stored properties
>> foreach case
>> 
>> Hello everyone,
>> 
>> Currently Swift only supports computed properties for each enum case.
>> If you want to somehow get static values with each case you would
>> probably do it like this:
>> 
>> enum Planet {
>>case mercury
>>case venus
>>case earth
>>case mars
>>case jupiter
>>case saturn
>>case uranus
>>case neptune
>> 
>>var mass: Float {
>>switch self {
>>case .mercury: return 3.303e+23
>>case .venus: return 4.869e+24
>>case .earth: return 5.976e+24
>>case .mars: return 6.421e+23
>>case .jupiter: return 1.9e+27
>>case .saturn: return 5.688e+26
>>case .uranus: return 8.686e+25
>>case .neptune: return 1.024e+26
>>}
>>}
>> 
>>var radius: Float {
>>switch self {
>>case .mercury: return 2.4397e6
>>case .venus: return 6.0518e6
>>case .earth: return 6.37814e6
>>case .mars: return 3.3972e6
>>case .jupiter: return 7.1492e7
>>case .saturn: return 6.0268e7
>>case .uranus: return 2.5559e7
>>case .neptune: return 2.4746e7
>>}
>>}
>> }
>> 
>> However I see two problems with this approach:
>> 
>> 1. These value definitions are spread out and difficult to read and
>> maintain (especially if you have many computed properties for each
>> enum case);
>> 2. These values are not static. They are computed each time property
>> is accessed. This can be a problem when value is expensive to create.
>> 
>> The proposed solution is to have single static initializer for each
>> enum case that initializes stored properties. For example,
>> 
>> enum Planet {
>>var mass: Float
>>var radius: Float
>> 
>>static init(mass: Float, radius: Float) {
>>self.mass = mass
>>self.radius = radius
>>}
>> 
>>case mercury where (mass: 3.303e+23, radius: 2.4397e6)
>>case venus where (mass: 4.869e+24, radius: 6.0518e6)
>>case earth where (mass: 5.976e+24, radius: 6.37814e6)
>>case mars where (mass: 6.421e+23, radius: 3.3972e6)
>>case jupiter where (mass: 1.9e+27, radius: 7.1492e7)
>>case saturn where (mass: 5.688e+26, radius: 6.0268e7)
>>case uranus where (mass: 8.686e+25, radius: 2.5559e7)
>>case neptune where (mass: 1.024e+26, radius: 2.4746e7)
>> }
>> 
>> This approach do not affect enums that have raw or associated values,
>> or custom enum initializers:
>> 
>> case A = "A" where (id: 0)
>> 
>> or
>> 
>> case B(Int, Int, Int) where (id: 0)
>> 
>> Benefits:
>> 1. Less verbosity
>> 2. Improved readability
>> 3. Related values are closer to each other
>> 4. Static values are not recomputed

Re: [swift-evolution] [Pitch] Brace omission for single-statement n-ary closures

[Patrick Smith via swift-evolution]

I know there was more to what you were suggesting, but can I suggest removing 
the parentheses:

  let neg = [1, -2, 3].map{ -abs($0) }

  let ascii = words.flatMap{ $0.unicodeScalars.filter{ $0.isASCII } }


Patrick

> On 25 May 2016, at 5:46 AM, Marc Prud'hommeaux via swift-evolution 
>  wrote:
> 
> Everyone loves this syntax:
> 
>   let pos = [1, -2, 3].map(abs)
> 
> This syntax not so much:
> 
>   let neg = [1, -2, 3].map({ -abs($0) })

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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Patrick Smith via swift-evolution]

I just want to highlight the Photoshop history example. I agree you’d want as 
much state and memory shared between steps in the history.

However, I see nothing wrong with having pointers to pixel buffer, and that 
affecting the ‘purity’ of the state. The way Photoshop’s history is 
implemented, is every image is broken up into tiles. Changes are recorded only 
within touched tiles. 
(http://www.photoshopforphotographers.com/CC_2013/Help_guide/tp/History_palette.html
 
)
 This improves memory usage compared to a single pixel buffer. With a graphics 
programming workflow, say where a background thread or the GPU is involved, the 
contents of those pixel buffers are going to change independently to the 
history stack. I think there would no problem for the history steps to have 
pointers to their mutable pixel buffers. Once the thread/GPU has finished 
processing changes within a step’s pixel buffer, it is ‘sealed’ say with a 
flag, and can’t be mutated later.

The only other way I could think of is for each history step to use UUIDs to 
reference tile pixel buffers, and manage a separate map of [UUID: PixelBuffer]. 
Possibly this approach might have other benefits, but I think it doesn’t differ 
practically in ‘purity’ of state vs one state tree involving pointers. The 
purity is from the point of view of the programmer, where they know their 
system is purely additive.

The guarantee is in the system the programmer has created. Not allowing 
pointers to carefully managed mutable state is too rigid.


> On 23 May 2016, at 5:12 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On May 22, 2016, at 12:04 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> 
>> on Mon May 16 2016, Matthew Johnson > > wrote:
>> 
 On May 15, 2016, at 2:01 PM, Dave Abrahams
 > wrote:
 
 
 on Fri May 13 2016, Matthew Johnson >>> 
 >> 
 wrote:
 
>>> 
> Sent from my iPad
> 
>> On May 13, 2016, at 9:12 AM, Dave Abrahams > > wrote:
>> 
>> 
>>> on Mon May 09 2016, Matthew Johnson >> > wrote:
>>> 
>>> My claim is that substituting the constraint of “it has value
>>> semantics,” while presumably looser than the PureValue constraint, would
>>> not compromise the correctness of your view controller, so not only is
>>> the meaning of PureValue hard to define, but it doesn't buy you
>>> anything.  If you want to refute that, just show me the code.
>>> 
>>> This is not an algorithmic use but is still perfectly valid IMO.
>>> 
>>> If the properties of PureValue matter to your view controller, there's
>>> an algorithm somewhere that depends on those properties for its
>>> correctness.
>>> 
>>> In many cases it may just be view configuration that depends on those
>>> properties.  I suppose you can call view configuration code an
>>> algorithm but I think that would fall outside of common usage.
>> It's an algorithm, or if the configuration is declarative, there's
>> an algorithm that manipulates it.  That said, I still don't have a
>> concrete example of how view configuration can depend on these
>> properties.
> The algorithm might just be "copy x bit of data to y view
> property, etc".  That is so trivial that it feels like a stretch to
> call it an algorithm.
 
 Algorithms can be trivial.
>>> 
>>> Fair enough.  Although in most contexts people don’t use the word when
>>> discussing the trivial.
>> 
>> Yes, quite a shame, that.
>> 
> That "algorithm" doesn't depend on this property because it
> executes at a single point in time.  However, a view controller
> might depend on that property in order to render properly across
> time (for example, configuring cells as they scroll on and off
> screen).
 The example is too abstract for me to understand.
 
 Let me put this differently: I recognize that your concept of
 “PureValue” may be a *sufficient* condition for some generic
 algorithm/component to work, but it is never a *necessary*
 condition, because genericity (or use of a superclass or protocol
 type) erases details of the actual types involved from the point of
 view of the algorithm/component.  It doesn't matter if your type
 contains a class reference if it has value semantic properties.  My
 claim is that PureValue is an overly-restrictive constraint that
 makes many things less useful than they should be.
>>> 
>>> In many cases 

Re: [swift-evolution] Initialiser Helper

[Patrick Smith via swift-evolution]

You could move getAge() to be a private func outside of the scope of Person?


> On 23 May 2016, at 11:24 PM, James Campbell via swift-evolution 
>  wrote:
> 
> I would like to be able to use functions to help me initilise a class or 
> struct so I can break down a init into seperate methods, like so:
> 
> struct Person {
> 
> let age: Int
> 
> init (json: Dictionary) {
> // lots of code
> 
> age = json["age"]
> }
> 
> }
> 
> This can become un-wieldly, so I would love to be able to do this:
> 
> 
> struct Person {
> 
> let age: Int
> 
> init (json: Dictionary) {
> // lots of code
> 
> age = getAge(json)
> }
> 
> private func getAge(json: Dictionary) -> Int {
> 
> }
> 
> }
> ___
> 
> James⎥
> 
> ja...@supmenow.com ⎥supmenow.com 
> 
> Sup
> 
> Runway East
> 
> 
> 10 Finsbury Square
> 
> London
> 
> 
> EC2A 1AF 
> 
> ___
> 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 `mapValues` method to Dictionary

[Patrick Smith via swift-evolution]

This seems like a great way to do mapValues, as you get the ability to lazily 
map or flatMap the pairs. I’m pretty sure a key/value pair constructor is 
coming to Dictionary.


> On 22 May 2016, at 5:01 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 21 May 2016, at 15:47, Honza Dvorsky > > wrote:
>> 
>> While I agree that it'd be nice to add a Map abstraction into which we could 
>> move a lot of the Dictionary-ness, my original pitch is *just* about adding 
>> the specific implementation of `mapValues` in its regular, non-lazy form. My 
>> example was about only keeping a subset of the information in memory in a 
>> Dictionary to allow for quick and frequent access (lazy goes against that). 
>> I think it'd be better to get that in first, or at least evaluate that 
>> separately from a comprehensive refactoring of the Dictionary, which would 
>> just accumulate more opinions and slow this specific step down.
> 
> Sorry, my point was that I think it’s better to wait until we can also do the 
> lazy equivalent and have both done together, otherwise we end up with one map 
> function that can work both lazily and one that never does. Sure that will 
> require a refactoring into a protocol, but it seems to me that it’s better to 
> do that as the first step, then add the feature after that. In the mean time 
> extensions have you well covered for convenience.
> 
> Another alternative to this feature might be to add a key/value pair 
> constructor to Dictionary (it technically already has one, but it’s variadic 
> only) so you could do something like this:
> 
>   let myTransformedDictionary = Dictionary(myIntegerDictionary.lazy.map { 
> ($0, $1 + 5) })
> 
> Since this would be a useful initialiser both now and in future. I dunno, 
> it’s just my opinion, but I find it a bit weird to get half the 
> implementation now, and could lead to misunderstandings with people trying to 
> do myMap.lazy.mapValues (won’t be recognised) and wondering why there isn’t 
> one.
> ___
> 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 Revision] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Patrick Smith via swift-evolution]

Great stuff! Truly is a massive improvement to an already venerable API.

Was there any consideration to make this a new module ‘Dispatch’, and drop all 
the Dispatch- prefixes? Or rather, what is the reason for keeping the prefixes? 
(Group could become WorkGroup to lessen naming conflicts)


> On 20 May 2016, at 1:57 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> 
> Hello Swift Community,
> 
> The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" 
> ran from May 10…17, 2016. The proposal is *accepted with revisions* for Swift 
> 3.
> 
> The community and core team are both very positive about this massive 
> improvement to the libdispatch APIs.  Much of the discussion has centered 
> around specific details in the proposal - for example the “.asynchronously” 
> method on DispatchQueue.  This great discussion leads to several requested 
> revisions in the proposal:
> 
> - Rename the DispatchQueue.[a]synchronously methods to ".async” and ".sync”, 
> to follow the term of art.
> - Rename DispatchIO setHighWater, setLowWater --> setLimit(highWater:), 
> setLimit(lowWater:)
> - Rename setTargetQueue(queue:) and DispatchSource.setTimer 
> - Rename Semaphore, Group and WorkItem: .wait(timeout:) --> wait() and 
> wait(withTimeout:)
> - Expand source handler methods to take the same arguments as async()
> - Expand DispatchQueue.after to take the same arguments as async() in 
> addition to the when: argument
> 
> Thank you to Matt Wright proposing this, and for all of the implementation 
> work that has gone into this so far!
> 
> -Chris Lattner
> 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] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

[Patrick Smith via swift-evolution]

I think that is a little confusing and has potential to be ‘abused’. I think 
it’s more confusing that a `for(;;)` loop for instance, and that got removed. I 
think var + AnyIterator is more explicit, and can become the canonical way to 
do this.

Hopefully AnyIterator can be optimized to the same performance.


> On 20 May 2016, at 10:57 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
>> 
>> On May 19, 2016, at 6:52 PM, Kevin Ballard via swift-evolution 
>> > wrote:
>> 
>> After having given this some thought, it seems apparent that 
>> `sequence(state:next:)` is equivalent to `AnyIterator({ ... })` where the 
>> closure captures a single mutable variable. The microbenchmark performance 
>> may differ slightly, as the AnyIterator version will allocate a box on the 
>> heap to hold the captured variable (assuming it can't get inlined entirely), 
>> whereas UnfoldSequence won't. But the functionality is the same.
>>  
>> Thus the question: do we want to keep `sequence(state:next:)` or is it too 
>> close to AnyIterator in functionality? Arguments in favor of 
>> `sequence(state:next:)`:
>>  
>> * It's equivalent to unfold and the dual of reduce, so people who've used 
>> functional programming languages may expect it to exist.
>> * It allows you to create ad-hoc stateful sequences without polluting the 
>> current scope with a variable that exists solely to be captured.
>> * If the cost of a small heap allocation is significant for your code, it 
>> may be more performant than AnyIterator.
>>  
>> Personally, the most important reason here for me is not having to pollute 
>> the current closure with a variable. And this could actually be solved 
>> another way, by allowing the use of `var` in a capture list, which would let 
>> you say something like `AnyGenerator({ [var state=foo] in ... })`.
>>  
>> Given all this, at this point I'm actually leaning towards 
>> saying`sequence(state:next:)` doesn't pull its own weight and we should just 
>> go with `sequence(initial:next:)`.
>>  
>> -Kevin Ballard
> 
> Adding on, to the best of my understanding the biggest win in the stateful 
> variation is to be able to create a sequence from a starting state without 
> declaring any external variables, as in the perfectly wrong and evil example 
> I showed Kevin:
> 
> enum Finger: Int { case Thumb = 1, Pointer, Middle, Ring, Pinky }
> 
> extension Finger {
> static func members() -> AnySequence {
> return sequence(Thumb.rawValue, next: {
> (inout idx: Int) in
> defer { idx += 1 }
> return Finger(rawValue: idx)
> })
> }
> }
> 
> for finger in Finger.members() { print(finger) }
> 
> -- E
> 
> ___
> 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-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

[Patrick Smith via swift-evolution]

Would `sequence(mutatingState:next:)` perhaps be clearer?


> On 20 May 2016, at 10:37 AM, Trent Nadeau via swift-evolution 
>  wrote:
> 
> Ah, yes. I apologize. The fact that state is inout, and the same instance is 
> always passed in confused me. Thanks for the correction.
> 
> On Thu, May 19, 2016 at 7:46 PM, Brent Royal-Gordon  > wrote:
> > Also note that there's a typo in the second example:
> >
> > for view in sequence(initial: someView, next: { $0.
> > superview }) {
> >
> > // someView, someView.superview, someView.superview.superview, ...
> >
> > }
> >
> >
> > should be:
> >
> > for view in sequence(state: someView, next: { $0.
> > superview }) {
> >
> > // someView, someView.superview, someView.superview.superview, ...
> >
> > }
> 
> I don't think these are mistakes—in each iteration of the loop, $0 is 
> supposed to be the view from the previous iteration.
> 
> If you wanted an example using `state`, here's one which is roughly 
> equivalent to `stride(from: 1.0, to: 2.0, by: 0.1)`, using a 
> non-error-accumulating algorithm:
> 
> let start = 1.0
> let end = 2.0
> let distance = 0.1
> 
> for color in sequence(state: -1.0, next: { $0 += 1; let next = start 
> + $0 * distance; return next < end ? next : nil }) {
> …
> }
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> 
> 
> 
> -- 
> Trent Nadeau
> ___
> 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] ADC Swift Blog

[Patrick Smith via swift-evolution]

There’s some new posts, they’re just not listed:

https://developer.apple.com/swift/blog/introducing-the-swift-bikeshedding-mailing-list
https://developer.apple.com/swift/blog/virtual-reality-playgrounds-the-next-paradigm
https://developer.apple.com/swift/blog/no-we-dont-accept-prs-for-the-wwdc-2016-website
https://developer.apple.com/swift/blog/11-proposals-you-didnt-review-but-actually-should
https://developer.apple.com/swift/blog/accepted-with-modifications-you-wont-believe-what-happened-next


> On 20 May 2016, at 6:25 AM, Pavel Kapinos via swift-evolution 
>  wrote:
> 
> Hi,
> 
> I think Apple Developer Connections doesn’t advertise well what is going on 
> with Swift 3 development, for example Swift blog on ADC is stalled from 
> February. Come on people, let others know that Swift 3 is a big deal and urge 
> others to read all its proposals because they shape up quite quickly and 
> Swift 3 will affect everyone!
> 
> Cheers,
> Pavel.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

[Patrick Smith via swift-evolution]

Yes, I think I agree this should show a warning, and require you to explicitly 
state that you are happy dealing with an optional.

Possibly you would have to add a ? suffix to make it explicit:

"http://apple.com\(originalURL.path?)/help”

This would be compatible with StringInterpolationConvertible, where you may 
still want the original optional passed, whereas `.debugDescription` would 
always pass a string.


> On 19 May 2016, at 5:39 PM, Krystof Vasa via swift-evolution 
>  wrote:
> 
> Consider the following example:
> 
> let originalURL: NSURL = NSURL(string: "http://apple.com/iphone 
> ")!
> let newURL = NSURL(string: "http://apple.com\(originalURL.path)/help 
> ")
> 
> What's the newURL? Nil, because it was being inited with
> 
> http://apple.comOptional(/iphone)/help 
> 
> 
> Since the path property is optional.
> 
> Which is not something you figure out until runtime, wondering why the URL is 
> nil. This is very annoying when you run into this issue repeatedly on several 
> occasions because you forget to unwrap the value.
> 
> *This* is IMHO an undesired and unexpected behavior.
> 
> If interpolating optionals did become a warning, you'd immediately know about 
> a potential bug: you don't check if path != nil.
> 
> BTW if you still want the original behavior of printing 
> 
> Optional(my string value),
> 
> you can still write 
> 
> "http://apple.com\(originalURL.path.debugDescription)/help 
> " 
> 
> which invokes debugDescription on the Optional, not the String (since there 
> is no "?"), and you get the original value anyway. And this could be the 
> Fix-It for it as well to maintain original behavior.
> 
> Krystof
> 
>> On May 19, 2016, at 9:28 AM, Dan Appel > > wrote:
>> 
>> You know what's worse than seeing "Optional(my string value)" in a label? 
>> Seeing "nil". When the optional is there, it is made clear to the developer 
>> that the string they are showing can be nil. However, if you hide that from 
>> the users you are less likely to unwrap that optional and hence more likely 
>> to show the user "nil". This behavior really goes against some of the core 
>> ideas of Swift - you want your code to be expressive but not abstract away 
>> potentially useful information.
>> 
>> On Thu, May 19, 2016 at 12:24 AM David Waite > > wrote:
>> Making string interpolation reject just optional (at compile time) when it 
>> doesn’t reject any other type sounds tricky to express.
>> 
>> What if instead Optional just didn’t decorate the wrapped value, outputting 
>> either the inner value or “nil” in these cases?
>> 
>> The debugDescription could remain "Optional(data)" style.
>> 
>> -DW
>> 
>>> On May 19, 2016, at 12:52 AM, Valentin via swift-evolution 
>>> > wrote:
>>> 
>>> From what I understand of this thread, the argument here is that directly 
>>> using an optional in a string interpolation is almost never what you really 
>>> want to do (except mainly for debugging purposes) but you wouldn't see this 
>>> mistake until much later at runtime.
>>> And I feel like one of Swift goals is to enable us, imperfect human 
>>> creatures, to detect as many problems or mistakes as possible long before 
>>> runtime.
>>> 
>>> On 19 mai 2016, at 00:56, Dan Appel via swift-evolution 
>>> > wrote:
>>> 
 -1. 
 
 Optional(foo) better depicts the actual type (it's an options string, 
 after all). If you're not happy with it, just use the nil coalescing 
 operator such as "\(foo ?? "")". This is from the same series of proposals 
 as implicit casting - there are reasons it's done the way it is.
 On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via swift-evolution 
 > wrote:
 +1, personally I have taken to using `x+"str"+y` instead of 
 `"\(x)str\(y)"`, if x/y are strings, so I can get a compile-time error if 
 I do this accidentally.
 
 But I do see the appeal of being able to print("the data: \(data)") for 
 simple use cases. Didn't someone earlier propose some modifiers/labels 
 like "\(describing: x)" ?
 
 
 On Wed, May 18, 2016 at 11:50 AM, Krystof Vasa via swift-evolution 
 > wrote:
 The string interpolation is one of the strong sides of Swift, but also one 
 of its weaknesses.
 
 It has happened to me more than once that I've used the interpolation with 
 an optional by mistake and the result is then far from the expected result.
 
 This happened 

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

[Patrick Smith via swift-evolution]

Oh yep, I accidentally read that section as ‘Alternatives Considered’.

I still find this a little bit of a hack, so I hope this approach doesn’t get 
used too much, certainly not in the standard library. Is this only useful for 
factory or other static methods? It would just be a shame to see protocols 
become defensive for use cases like this.

I believe the protocol should remain ‘pure’, and the conforming types then 
decide on which way they want to go. If they use a static type (or label the 
method final), then its particular protocol requirements change.

Anyway, nice resolution!


> On 19 May 2016, at 1:06 PM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On May 18, 2016, at 9:57 PM, Patrick Smith  > wrote:
> 
>> I think the distinction between StaticSelf and Self will be very confusing 
>> to newcomers.
>> 
>> So the only reason why we must use StaticSelf instead of Self here is 
>> because we want NSURL to conform, and it isn’t final?
>> 
>> protocol StringCreatable {
>> static func createWithString(s: String) -> StaticSelf
>> }
>> 
>> I find it a code smell that this would affect the protocol and not the class.
>> 
>> Why couldn’t you have this?
>> 
>> protocol StringCreatable {
>> static func createWithString(s: String) -> Self
>> }
>> 
>> extension NSURL: StringCreatable {
>>  // can now conform conform because NSURL is fixed and matches the static
>>  // type of the conforming construct. Subclasses need not re-implement
>>  // NOTE: the return type can be declared as StaticSelf *or* as NSURL
>>  //   they are interchangeable
>>  static func createWithString(s: String) -> StaticSelf { 
>>  // ...
>>  }
>> }
>> 
> 
> You can't do this because the Self return type in the protocol requirement 
> specifically *requires* all subclasses to override the method and return an 
> instance of the subclass type.  
> 
> Nevertheless, we have identified a workaround that is similar enough to 
> StaticSelf that we have abandoned the proposal.  Please see The last couple 
> posts in this thread if you're interested in the details.
> 
>> 
>> 
>>> On 19 May 2016, at 3:37 AM, Erica Sadun via swift-evolution 
>>> > wrote:
>>> 
>>> As a wrap-up of the topic, I've updated our original draft with Nicola S's 
>>> resolution.
>>> 
>>> https://gist.github.com/erica/995af96a0de2f2f3dc419935e8140927 
>>> 
>>> 
>>> -- E
>>> 
>>> 
 On May 14, 2016, at 8:35 AM, Matthew Johnson via swift-evolution 
 > wrote:
 
> 
> On May 14, 2016, at 12:55 AM, Nicola Salmoria via swift-evolution 
> > wrote:
> 
> Matthew Johnson via swift-evolution  writes:
> 
>> I agree it’s a bit tricky.  But that’s better than not possible at all.
> You just need a typealias and a same type constraint to make this work as
> expected / desired:
>> 
>> 
>> protocol Makable {
>> 
>>  typealias RootMakable = StaticSelf
>>  static func make(value: Int) -> StaticSelf
>> }
>> 
>> func makeWithZero(x: Int) -> T {
>>  return T.make(value: 0) // works now
>> }
>> 
>> 
>> Now that we have a typealias we can refer to the binding of StaticSelf 
>> and
> constrain it as necessary for whatever purpose we have in mind.  In some
> cases that will be a same type constraint so that our code works properly
> with class clusters.  I don’t have concrete examples of other use cases 
> but
> can imagine use cases constraining the typealias to a protocol, for 
> example.
> 
> You can do that today:
> 
> protocol Makable {
>   associatedtype MadeType
>   static func make(value: Int) -> MadeType
> }
> 
> func makeWithZero(x: Int) -> T {
>   return T.make(value: 0)
> }
> 
> You can't currently constrain MadeType to be the same as the conforming
> type, but, does it matter? What kind of extra guarantees would that give,
> since you need to add the extra constraint anyway in generic code?
 
 Wow, this is pretty cool.  Thank you very much for pointing this out 
 Nicola!
 
 I haven’t seen this approach to solving the problem.  Given the amount of 
 discussion this problem has received I am surprised nobody has shared this 
 solution yet.  I just checked in Xcode 7.3 and it works there.  It isn’t 
 dependent on any pre-release features.  
 
 Instead of using StaticSelf under the current proposal:
 
 protocol StringInitializable {
static func initializeWith(string: String) -> StaticSelf
 }
 
 We just add an associatedtype defaulted to Self:
 
 protocol 

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

[Patrick Smith via swift-evolution]

I think the distinction between StaticSelf and Self will be very confusing to 
newcomers.

So the only reason why we must use StaticSelf instead of Self here is because 
we want NSURL to conform, and it isn’t final?

protocol StringCreatable {
static func createWithString(s: String) -> StaticSelf
}

I find it a code smell that this would affect the protocol and not the class.

Why couldn’t you have this?

protocol StringCreatable {
static func createWithString(s: String) -> Self
}

extension NSURL: StringCreatable {
 // can now conform conform because NSURL is fixed and matches the static
 // type of the conforming construct. Subclasses need not re-implement
 // NOTE: the return type can be declared as StaticSelf *or* as NSURL
 //   they are interchangeable
 static func createWithString(s: String) -> StaticSelf { 
 // ...
 }
}



> On 19 May 2016, at 3:37 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> As a wrap-up of the topic, I've updated our original draft with Nicola S's 
> resolution.
> 
> https://gist.github.com/erica/995af96a0de2f2f3dc419935e8140927 
> 
> 
> -- E
> 
> 
>> On May 14, 2016, at 8:35 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On May 14, 2016, at 12:55 AM, Nicola Salmoria via swift-evolution 
>>> > wrote:
>>> 
>>> Matthew Johnson via swift-evolution  writes:
>>> 
 I agree it’s a bit tricky.  But that’s better than not possible at all.
>>> You just need a typealias and a same type constraint to make this work as
>>> expected / desired:
 
 
 protocol Makable {
 
typealias RootMakable = StaticSelf
static func make(value: Int) -> StaticSelf
 }
 
 func makeWithZero(x: Int) -> T {
return T.make(value: 0) // works now
 }
 
 
 Now that we have a typealias we can refer to the binding of StaticSelf and
>>> constrain it as necessary for whatever purpose we have in mind.  In some
>>> cases that will be a same type constraint so that our code works properly
>>> with class clusters.  I don’t have concrete examples of other use cases but
>>> can imagine use cases constraining the typealias to a protocol, for example.
>>> 
>>> You can do that today:
>>> 
>>> protocol Makable {
>>>   associatedtype MadeType
>>>   static func make(value: Int) -> MadeType
>>> }
>>> 
>>> func makeWithZero(x: Int) -> T {
>>>   return T.make(value: 0)
>>> }
>>> 
>>> You can't currently constrain MadeType to be the same as the conforming
>>> type, but, does it matter? What kind of extra guarantees would that give,
>>> since you need to add the extra constraint anyway in generic code?
>> 
>> Wow, this is pretty cool.  Thank you very much for pointing this out Nicola!
>> 
>> I haven’t seen this approach to solving the problem.  Given the amount of 
>> discussion this problem has received I am surprised nobody has shared this 
>> solution yet.  I just checked in Xcode 7.3 and it works there.  It isn’t 
>> dependent on any pre-release features.  
>> 
>> Instead of using StaticSelf under the current proposal:
>> 
>> protocol StringInitializable {
>>static func initializeWith(string: String) -> StaticSelf
>> }
>> 
>> We just add an associatedtype defaulted to Self:
>> 
>> protocol StringInitializable {
>>associatedtype Initialized = Self // where Self: Initialized
>>static func initializeWith(string: String) -> Initialized
>> }
>> 
>> extension NSURL: StringInitializable {
>>static func initializeWith(string: String) -> NSURL {
>>return NSURL()
>>}
>> }
>> 
>> func makeWith(string: 
>> String) -> T {
>>return T.initializeWith(string: string)
>> }
>> 
>> There are two minor downsides to this approach:
>> 
>> 1. You can’t copy and paste the method signature.
>> 2. You can theoretically conform a type completely unrelated to 
>> `Initialized` to the protocol, thus violating the semantics.
>> 
>> I think we can live with these downsides.  Maybe the `Self: Initialized` 
>> will be possible someday.  That would be pretty close to StaticSelf.  The 
>> only difference would be that subclasses still have flexibility to override 
>> with their own type.
>> 
>> Now that a reasonable way to do this with existing language features has 
>> been identified I will withdraw this proposal.   If this approach doesn’t 
>> address use cases others have in mind for StaticSelf please speak up!
>> 
>> Doug, if you’re reading this, does the `where Self: Initialized` (i.e. 
>> arbitrary subclass constraints) fall into the scope of your “completing 
>> generics” manifesto?  This is a concrete use case that would utilize 
>> subclass constraints.
>> 
>> -Matthew
>> 
>> 
>>> 
>>> Nicola
>>> ___
>>> swift-evolution mailing list
>>> 

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

[Patrick Smith via swift-evolution]

`init(describing:)` make sense to me. I can see how it could be argued “well it 
looks like it calls the ‘description’ method of the argument, when it doesn’t, 
so this is poor naming”.

However, `init(printing:)` looks like it has something to do with `print()`, 
when it doesn’t. ‘Print’ is a verb, and means to print to standard output. 
`init(printing:)` has nothing to do with the standard output.

So, `init(describing:)`, how is it more clear? I think it is more clear as you 
are always getting a description. If you want a custom description, it’s 
obvious, you implement CustomStringConvertible’s description method. The word 
‘describing’ is just based on its meaning, not on how it is implemented with 
the use of CustomStringConvertible or not.

Patrick

> On 19 May 2016, at 6:34 AM, Leonardo Pessoa via swift-evolution 
>  wrote:
> 
>> Hello Swift community,
>> 
>> The review of "SE-0089: Renaming String.init(_: T)" begins now and runs 
>> through May 23. The proposal is available here:
>> 
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
>> 
>>* What is your evaluation of the proposal?
> 
> As described in the proposal, it makes sense. I never faced the issue
> myself but agree to the change. I'd also go with Jacob's version
> 'init(describing:)' since there is no guarantee the resulting string
> will be printed but will surely describe the object used as argument.
> 
>>* Is the problem being addressed significant enough to warrant a 
>> change to Swift?
> 
> As outlined by the proposal, yes.
> 
>>* Does this proposal fit well with the feel and direction of Swift?
> 
> Yes.
> 
>>* If you have used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
> 
> None.
> 
>>* How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> A quick reading.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] RFC: didset and willset

[Patrick Smith via swift-evolution]

Yeah I agree completely with this. They may be camel case with property 
behaviours, so best to keep them as is for now.

> On 19 May 2016, at 6:53 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> didSet and willSet remain outliers in the general rule of conjoined 
>> lowercase keywords. Is there any support for bringing these outliers into 
>> the fold?
> 
> I don't think we shouldn't touch these until we know what accessors on 
> property behaviors are going to look like. We could very well change these 
> now and then change them back in the next version; that kind of bouncing back 
> and forth is maddening for users. Better leave them alone for now and change 
> them later if we decide to, than change them in Swift 3 and then have a high 
> probability of changing them back in Swift 4.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] RFC: didset and willset

[Patrick Smith via swift-evolution]

Not really sure, Like the way the camel case ones look. I’m not sure I 
understand why keywords are lowercase? To reduce clashes with variables?


> On 19 May 2016, at 1:09 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> didSet and willSet remain outliers in the general rule of conjoined lowercase 
> keywords. Is there any support for bringing these outliers into the fold?
> 
> -- E, going through her "ttd notes" this morning
> 
> ___
> 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-0084 spinoff: Newlines as item separators

[Patrick Smith via swift-evolution]

I don’t really see what the issue with having to reintroduce commas would be? 
The losing track of where the items are separated?

Maybe there could be an Xcode key shortcut to toggle commas off and on for 
newline separated items, like the current toggler for comments.

> On 18 May 2016, at 6:28 PM, David Hart via swift-evolution 
>  wrote:
> 
> -1 I see one big downside. Contrary to statements, which rarely appear on the 
> same line, other list elements are more frequently reformatted, from one line 
> to multiple lines and back. For example, I'll try to find function 
> declarations with too many arguments (formatted on multiple lines) and 
> refactor them to reduce the number of arguments and reformat them on one 
> line. This style refactoring would be made more difficult because it would 
> force me to re-introduce commas if they had been removed. Summary: I'm 
> against this proposal because element lists can be frequently reformatted 
> from one to multiple lines.
> 
> On 17 May 2016, at 20:06, Tino Heth via swift-evolution 
> > wrote:
> 
>> [Due to popular demand ;-) in the discussion of SE-0084: Allow trailing 
>> commas in parameter lists and tuples]
>> 
>> The option to skip semicolons for statements followed by a newline is only a 
>> tiny convinience, yet it is one of the most favored differences to C (and 
>> one of the most annoying things to remember when you have to switch from 
>> Swift to do some coding in Objective-C).
>> While lists of statements don't need a special separator character anymore, 
>> other lists still rely on commas to separate items:
>> - method parameters
>> - array and dictionary literals
>> - tuples
>> [anything else?]
>> 
>> SE-0084 targets to make it easier to reorder list elements by allowing an 
>> additional comma after the last element; afaics, the same can be achieved by 
>> making all of those commas optional, as long as there is a newline to 
>> separate the next item (without those newlines, SE-0084 makes less sense as 
>> well).
>> 
>> This change is not incompatible with SE-0084, but imho it doesn't make much 
>> sense to combine those features (at least in actual source code).
>> 
>> So, first question:
>> What are the downsides of this change? (question zero is "are there any 
>> other places where comma-separeted lists could be turned into 
>> newline-separated lists?"...)
>> 
>> Tino
>> 
>> ___
>> 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] [Idea] if let value!

[Patrick Smith via swift-evolution]

Here’s a idea, what if you could use a symbol to denote that you want the same 
name used?

Here’s an interesting sign from music: https://en.wikipedia.org/wiki/Repeat_sign

Then you can write (one) of these:

if let |: = mySomeValue {
  // Use unwrapped
}

if let mySomeValue = :| {
  // Use unwrapped
}

Not sure which one is more clear. Just a totally random idea! I’m not sure 
about the above symbols, but it would help in other places too from memory to 
not have to write the same variable name twice.

> On 18 May 2016, at 1:18 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution 
>> > wrote:
>> 
>> While I've sometimes (early on) wished for a shorter-hand syntax for that 
>> construct, I've never been able to think of something that I thought was 
>> better. I've gotten to the point where I don't particularly mind it anymore.
>> 
>> Regarding the exclamation point specifically, seeing one of those in an 
>> expression context says to me "this thing will die horribly if it is 
>> nil/throws an error". Using it in this context where that's not the case 
>> would probably go against users' expectations.
> 
> Agree.  If we are going have syntax similar to pattern matching it should be 
> the same as pattern matching.  This would mean using ‘?' rather than ‘!’.  
> However, we already have generalized pattern matching with `if case` for 
> that.  This topic has been debated extensively.
> 
>> 
>> 
>> On Tue, May 17, 2016 at 8:05 AM Vladimir.S via swift-evolution 
>> > wrote:
>> On 17.05.2016 16:51, Johan Jensen wrote:
>>  > This was one of the first and most commonly suggested ideas, when the 
>> Swift
>>  > Evolution mailing list first started.
>>  > Chris Lattner sums it up
>>  >
>> >  
>> >
>>  > in one of those threads:
>>  >
>>  >> This is commonly requested - the problem is that while it does help
>>  > reduce boilerplate, it runs counter to the goal of improving clarity.
>>  >
>>  > — Johan
>> 
>> Oh, thank you for letting this know.
>> 
>> Well, I totally disagree with Chris. And as soon as there was no 'official'
>> proposal and 'official' decision, I'd like to discuss this more.
>> 
>> I saw a lot of code like
>> if let mySomeValue = mySomeValue {} in sources and even in books.
>> Plus, I really believe that
>> if let mySomeValue! {..} is better in any way: readability, less space for
>> errors(when you need to repeat the same name) etc
>> 
>> FWIW, I suggest more explicit variant:
>> if let value! {...} // with exclamation mark
>> In that "old" proposal there was `if let value {...}`, was not so clear.
>> 
>> I can't accept an argument that you can use another name - as usually
>> 'good' name is already 'crafted' for the instance and you want to use it in
>> next code.
>> Otherwise, we need a 'best practice' to name optional variables with some
>> prefix or suffix like : mySomeValueOpt, then `if let mySomeValue =
>> mySomeValueOpt` will have a sense. But as I understand, we don't want to
>> use such approach.
>> Additionally, when you shadow optional value with same name - you are
>> *protecting* yourself from using optional value inside block of unwrapped
>> code. IMO it is a good idea.
>> And want we or don't want, we already have this practice widely. So I
>> believe this(my) proposal will improve the code.
>> 
>> I'd like to get opinion of the community regarding this feature.
>> 
>> On 17.05.2016 16:51, Johan Jensen wrote:
>> > This was one of the first and most commonly suggested ideas, when the Swift
>> > Evolution mailing list first started.
>> > Chris Lattner sums it up
>> > > >  
>> > >
>> > in one of those threads:
>> >
>> >> This is commonly requested - the problem is that while it does help
>> > reduce boilerplate, it runs counter to the goal of improving clarity.
>> >
>> > — Johan
>> >
>> > On Tue, May 17, 2016 at 3:43 PM, Vladimir.S via swift-evolution
>> >  
>> > >> 
>> > wrote:
>> >
>> > It is common to shadow optional value name with unwrapped value with
>> > same name:
>> >
>> > if let someGoodValue = someGoodValue {...}
>> >
>> > What if we'll have a syntax to not repeat the variable name to achieve
>> > the same target:
>> >
>> > if let someGoodValue! {...}
>> >
>> > What do you think?
>> > ___
>> > swift-evolution mailing 

Re: [swift-evolution] [RFD] Non-Self Protocol Requirements

[Patrick Smith via swift-evolution]

Yes, something like this would be handy! Even the ability to coerce from one 
type to another, if that destination type has a keyless initialiser for the 
source type.

Here’s some imaginary syntax for with Erica’s array example. I would prefer a 
way to not have a separate type for ‘DoubleSource’ if possible.

let foo: [Double] = Double[int32, int8, double, cgfloat, float] // As if you 
had written Double(…) around each item

or

let foo: [Double] = [int32, int8, double, cgfloat, float](Double.init) // // As 
if you had written Double(…) around each item


Here’s another use case I’ve had:

enum Deferred {
typealias UseResult = () throws -> Result

case unit(UseResult)
case future(((UseResult) -> ()) -> ())

init(_ subroutine: UseResult) {
self = .unit(subroutine)
}
}

Instead of this:

struct Example {
func next() -> Deferred {
return Deferred{ 42 }
}
}

It would be nice to be able to do this:

struct Example {
func next() -> Deferred {
return { 42 }
}
}

I don’t know if that’s playing with fire, but it would be seemingly nice for 
Swift to automatically infer what I want.


> On 17 May 2016, at 12:15 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> The following situation has come up for me now and then: I want to work with 
> groups of types that share a common behavior, but that behavior is not 
> sourced in the implementation of the Self type but rather in a secondary 
> type.  Specifically, could Swift be extended to introduce a protocol 
> requirement that discusses how a type is used by a secondary type and not the 
> kind of member provided directly by the type. For example:
> 
> // These are all numbers
> let int32: Int32 = 1; let int8: Int8 = 1
> let double: Double = 1.0; let cgfloat: CGFloat = 1.0; let float: Float = 1
> 
> // They can all be converted to Double using Double.init
> Double(int32); Double(int8); Double(double); Double(cgfloat); Double(float)
> 
> // A heterogeneous collection cannot be unified into a single protocol
> let foo: [Any] = [int32, int8, double, cgfloat, float]
> foo.map{ Double($0) } // Can't work, Any doesn't make any sense here
> 
> The kind of thing I am looking for is something like this:
> 
> protocol DoubleSource {
> Double.init(Self)
> }
> 
> In other words, the functionality constraint is not provided by the base type 
> but by a second type to which the base type is a parameter.
> 
> My use case is for unrelated types (that is, there's no inheritance 
> relationship like you'd find in `UISwitch` and `UISlider`, for example -- 
> both of which are `UIView` and `UIControl`), where there is a secondary type 
> that implements behavior with the same signature for these separate types, 
> such as the Double initializer. Where this pops up the most is in working 
> with Sprite/SceneKit, GamePlayKit, QuartzCore, Accelerate, unifying my 
> numeric values so I can mix and match calls and clean up the flow where some 
> calls require CGPoint, others need float2, etc. Ideally I would be able to 
> 
> extension DoubleSource {
> func bar() -> T {
> let value = Double.init(self)
> // do something with value; return T of some type
> }
> }
> 
> let foo: [DoubleSource] = [int32, int8, double, cgfloat, float]
> foo.map{ bar($0) } // would work
> 
> Would something like this be a valuable direction to extend Swift? Is it 
> something found in other languages? Does this kind of requirement have a 
> name? Is it *pragmatically* possible to introduce it in Swift?
> 
> Thanks in advance for your thoughts and insights.
> 
> -- E
> 
> ___
> 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-0081: Move where clause to end of declaration

[Patrick Smith via swift-evolution]

I tend to agree with Jon Shier, Karl Wagner, Nicola Salmoria, and Tony 
Allevato. I think moving `where` to the end hinders comprehension. The extra 
constraint abilities that Nicola brought up look interesting.


> On 15 May 2016, at 1:52 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> On 2016-05-10 18:51:29 +, Chris Lattner via swift-evolution said:
> 
>> Hello Swift community,
>> The review of "SE-0081: Move where clause to end of declaration" begins now 
>> and runs through May 16. The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.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.
>> What goes into a review?
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and contribute to the direction of Swift. 
>> When writing your review, here are some questions you might want to answer 
>> in your review:
>>  * What is your evaluation of the proposal?
> 
> -1. My thoughts essentially mirror those of Jon Shier, Karl Wagner, and 
> Nicola Salmoria.
> 
> To me, this makes declarations with complex sets of constraints much harder 
> to read, because I have to hunt them down instead of finding them all in one 
> place. Under this proposal, the longer an argument list gets, the further 
> separated the constraints are from the type parameters that use them.
> 
> This solution also obfuscates function definitions. Having the function's 
> return type be the very last thing in the header line is has very nice 
> readability benefit, and this proposal takes that away by sandwiching the 
> return type awkwardly in the middle.
> 
> The admission that some constraints should be allowed inside the angle 
> brackets (conformance constraints) while moving others (associated type 
> constraints) out introduces inconsistency in the language and seems like an 
> incomplete fix. From a teaching point of view, I would find it more difficult 
> to explain to users of the language "constraints that look like *this* go 
> here, but constraints that look like *that* go way over there". The current 
> model of "all generic constraints go between < and >" is clean and simple.
> 
> Lastly, from a bit of a pedantic point of view, moving the where-clause to 
> the end of a function declaration makes it look like the function is 
> satisfying some constraints, when it's actually the generic type parameters 
> that are satisfying them. In that sense, it's better to keep them closer 
> together.
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes, but not in this fashion. I agree with some of the other sentiment that 
> there should be better ways of satisfying complex constraint sets (through 
> generic typealiases or something else) to clean them up, but moving the 
> where-clause creates more readability problems than it solves.
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> I don't believe so; it adds inconsistency rather than removes it.
> 
>>  * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> No languages that allow generics to be expressed so richly as Swift's.
> 
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Read the proposal and followed the mailing list threads.
> 
>> More information about the Swift evolution process is available at
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> Thank you,
>> -Chris Lattner
>> 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

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

Re: [swift-evolution] [Idea] "guard not let" optional binding

[Patrick Smith via swift-evolution]

I’d probably write that as:

if let value = cachedValue { return value }

cachedValue = // … expensive calculation


> On 14 May 2016, at 3:52 PM, Karl via swift-evolution 
>  wrote:
> 
> If we want to check that an optional has a value and bail if it doesn't, we 
> have the helpful pattern:
> 
>guard let x = x else { throw SomeError }
> 
> However, it is also fairly common that you want to check that an optional 
> *is* nil, and still bail if it isn’t (maybe using the value that you now know 
> exists), e.g:
> 
>guard cachedValue == nil else { return cachedValue! }
>cachedValue = //… expensive calculation
> 
> It seems a little bit “unfair” that we have this lovely clean `let` syntax 
> when checking for Optional.Some, but we to have to do this ugly manual check 
> against nil and explicit unwrap when checking for Optional.None. There is 
> literally no other way to satisfy the guard statement; our optional bindings 
> only go one-way can’t be evaluated.
> 
> What about if we introduced a “not” modifier to optional bindings?
> 
>guard not let cachedValue = _someExpensiveResult else { return cachedValue 
> }
> 
> This obviously wouldn’t make sense for “if let…” switching, as the variables 
> get bound in the ‘else’ block and the code wouldn’t be very readable. For the 
> special case of a guard statement, though, which only has an ‘else’ block, it 
> does make some sense.
> 
> If we had something like this, certainly in my code, I’d be able to eliminate 
> almost all (maybe even all) remaining force-unwraps of optionals; that’s 
> great! It’d be amazing if the language was expressive enough that you could 
> go without ever having to force-unwrap an optional. And it just makes sense. 
> 
> Thoughts?
> 
> Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

[Patrick Smith via swift-evolution]

Would there be any issue with the return type being AnySequence? It’s used in 
other areas:

LazySequence & FlattenSequence’s
dropFirst(n: Int) -> AnySequence
dropLast(n: Int) -> AnySequence

No need to introduce another type, and it’s straight forward to implement with 
AnySequence.


> On 14 May 2016, at 5:07 AM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> On Fri, May 13, 2016, at 11:08 AM, Erica Sadun wrote:
>> On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>>>  
 The proposal has been updated as per feedback from the core team 
 (https://github.com/apple/swift-evolution/pull/275 
 ). This includes 
 removing some last vestiges of Swift 2 naming as well as replacing 
 `iterate(_:apply:)` with an overloaded function `unfold(_:applying:)`.
>>>  
>>> The proposal says this:
>>>  
>>>  public func unfold(_ initialState: State, applying: State -> (T, 
>>> State)?) -> UnfoldSequence
>>>  public func unfold(_ initialElement: T, apply: T -> T) -> 
>>> UnfoldSequence
>>>  
>>> However, the comment implies that the second one should instead be this:
>>>  
>>>  public func unfold(_ initialElement: T, applying: T -> T?) -> 
>>> UnfoldSequence
>>>  
>>> I'm not sure I like having these be overloaded on only the return type of 
>>> the closure. Maybe we could do something like this?
>>>  
>>>  public func unfold(fromState initialState: State, applying: 
>>> State -> (T, State)?) -> UnfoldSequence
>>>  public func unfold(fromFirst initialElement: T, apply: T -> T) -> 
>>> UnfoldSequence
>>>  
>>> That way you're calling either `unfold(fromState:applying:)` or 
>>> `unfold(fromFirst:applying:)`. (Some further bikeshedding might be needed 
>>> here—it's late and I'm tired.)
>> 
>>  
>> I really don't want to see this discussion die as I have a vested interest 
>> in getting this functionality into
>> Swift 3. So let me suggest that
>>  
>> `sequence(_:, next:) -> AdHocSequence`
>>  
>> might be a Swift acceptable solution.  We're not going to see fold/unfold 
>> pair happen. It's a given that
>> `reduce` is a fixed point in Swift space and `sequence` well describes what 
>> this should be doing.
>>  
>> So is it possible to push forward with `sequence`, whose only negative seems 
>> to be that it's not as well
>> loved as `unfold`?
>  
> I do like `sequence`, though I'm not sold on the name AdHocSequence (just 
> from that name it's hard to figure out what it does). An alternative is 
> `expand`, which is nice because it pairs with `reduce`, but it's less obvious 
> that it produces a sequence and the name isn't as good with the stateful 
> version.
>  
> As for return type name, we could go ahead and use UnfoldSequence anyway 
> even though the function isn't named `unfold`, because this name will make 
> sense to people who do know what unfold is, and I'm not convinced we can have 
> a meaningful name for people who don't (since SequenceSequence is too silly).
>  
> So given that, I'll suggest the following:
>  
>   func sequence(initial: T, next: T -> T?) -> UnfoldSequence
>   func sequence(state: State, next: (inout State) -> T?) -> 
> UnfoldSequence
>  
> I'm suggesting `sequence(initial:next:)` instead of the previously-suggested 
> `sequence(from:applying:)` because the term "from" could equally well mean 
> the first element or the state, whereas "initial" should make it more obvious 
> that this value is the first element of the resulting sequence. And I'm using 
> "next" as suggested by Erica because the function does return the next 
> element, and it's similar to the IteratorProtocol method. I've also chosen to 
> change the stateful version to use an inout parameter, as previously 
> suggested, because it's equivalent to the State -> (T, State)? in 
> functionality but is less likely to produce unwanted COW copies.
>  
> -Kevin Ballard
> ___
> 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-0075: Adding a Build Configuration Import Test

[Patrick Smith via swift-evolution]

I can’t decide if this would be a good idea or not? I can see pluses and 
minuses!

+
Consistent.
One way to remember to work with modules.
Reinforces the rule that if you want to work with a module, you want to import 
it.

-
Could get confusing exactly where things are being imported, but you can stick 
an import away from the top of file today.


I imagine might still need something like `#if module(UIKit)` for certain 
scenarios, but not sure.


Patrick


> On 13 May 2016, at 7:05 PM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> This would be less of a problem if conditional imports like that worked 
> locally in all scopes of code, so you could write just
> 
> func foo() {
> #if import UIKit
> // Actually use UIKit...
> #endif
> // UIKit no longer visible.
> }

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

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

[Patrick Smith via swift-evolution]

Well my idea also included module(X), modelled after the os() function, e.g. 
#if os(OSX)

#if import UIKit
// Some UIKit-related declarations
#endif
// Later in the same file
func f() {
#if module(UIKit)
// Use UIKit-only declarations
#endif
}


Looking forward to seeing more feedback, esp from Erica. My concern was that 
hasModule() was just a bit raw.

I will point out a few concerns I have:

Is there a better way of writing this with nothing inside:
#if import UIKit
#endif

Is it strange that all other functions with #if use parentheses (), but not 
import?

However, I just feel code like this doesn’t feel very Swifty:

#if hasModule(UIKit)
import UIKit
#endif

> However, I don't get your concerns of "whether already imported or not". 
> Isn't `import` strictly about bringing identifiers of linked libraries 
> visible in the current file and not about linking to libraries in code.


I was originally going to include this, but cut it out, because it would be an 
unclear way to still import something. import ‘returned’ a boolean. So forgot 
to cut that bit out too.

#if ! import SomethingCool
import SomeFallback
#endif

> On 13 May 2016, at 6:54 PM, Gwendal Roué  wrote:
> 
> Hello,
> 
> `#if import Foo` can not deal with the fact that a single source file may 
> have to perform the importability test several times.
> 
> For example:
> 
>   #if canImport(UIKit)
>   import UIKit
>   // Some UIKit-related declarations
>   #endif
>   // Later in the same file
>   func f() {
>   #if canImport(UIKit)
>   // Use UIKit-only declarations
>   #endif
>   }
> 
> I know, I know, some will tell me to refactor my code. So let's just say I'm 
> prototyping and that the code doesn't have its final shape, OK?
> 
> Still, testing for module importability is not the same as importing it.
> 
> Gwendal Roué
> 
>> Le 13 mai 2016 à 10:40, Pyry Jahkola via swift-evolution 
>> > a écrit :
>> 
>> Patrick,
>> 
>> I think you're making valuable points here. I also can't think of cases 
>> where you wouldn't also import a module in case it was found to be 
>> importable. So the use cases I can think of could as well be tackled by 
>> allowing expressions such as `import Foo.Bar` as compile-time checks within 
>> the conditions of `#if` like you suggested. That would bring those libraries 
>> only visible within the scope of that block.
>> 
>> However, there can be cases where you're considering importing more than one 
>> module, so something like:
>> 
>> #if import Foo, import Bar
>>   ...
>> #elseif import Baz
>>   ...
>> #endif
>> 
>> should be considered in that design too. And I don't like the fact that it 
>> would import many modules in one line of code.
>> 
>> However, I don't get your concerns of "whether already imported or not". 
>> Isn't `import` strictly about bringing identifiers of linked libraries 
>> visible in the current file and not about linking to libraries in code.
>> 
>> — Pyry
>> 
>>> I guess one issue I can see is it’s used in two different ways:
>>> - The first use of canImport is used to check whether it can import a 
>>> module, and then does so, but there’s no requirement for it to do so. Is 
>>> this the right this to do?
>>> - The second use of canImport makes no guarantee that the module has been 
>>> imported, only that it can.
>>> 
>>> What if instead `import` could return whether it imported or not, when used 
>>> with #if? Instead of ‘can import’, you get ‘did just import’ and ‘has 
>>> imported’.
>>> 
>>> 
>>> import Required // Error if not present, current behaviour
>>> 
>>> #if import CoolThing // Skips code block if not present, imports otherwise
>>>  // Do something with CoolThing module
>>> #else
>>>  import AlmostAsCoolThing
>>> #endif
>>> 
>>> and you test at the use-site
>>> 
>>> #if module(X) // Does not import, only checks if it has been imported
>>>  // use things that are available in X
>>> #else
>>> 
>>> 
>>> As per Pyry’s feedback, you could add a version:
>>> 
>>> #if import Frobnication(<1.7.3) // <- Only added version constraint here.
>>> extension Knob : Frobnicatable { ... }
>>> #endif
>>> 
>>> 
>>> 
>>> Just a way to make it less low level.
>>> 
>>> ___
>>> 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-0075: Adding a Build Configuration Import Test

[Patrick Smith via swift-evolution]

> canImport (or whatever it ends up being called) is deliberate.
> 
> You test before you import:
> 
> #if canImport(x)
>import x
> #else
> ...
> #endif
> 
> and you test at the use-site
> 
> #if canImport(x)
>   // use things that are available in x
> #else
> ...
> 
> So you don't import UIKit unless you *can*, and you don't use UIColor unless 
> you can import UIKit. This follows closely on the design of __has_include.
> 
> -- E


I guess one issue I can see is it’s used in two different ways:
- The first use of canImport is used to check whether it can import a module, 
and then does so, but there’s no requirement for it to do so. Is this the right 
this to do?
- The second use of canImport makes no guarantee that the module has been 
imported, only that it can.

What if instead `import` could return whether it imported or not, when used 
with #if? Instead of ‘can import’, you get ‘did just import’ and ‘has imported’.


import Required // Error if not present, current behaviour

#if import CoolThing // Skips code block if not present, imports otherwise
  // Do something with CoolThing module
#else
  import AlmostAsCoolThing
#endif

and you test at the use-site

#if module(X) // Does not import, only checks if it has been imported
  // use things that are available in X
#else


As per Pyry’s feedback, you could add a version:

#if import Frobnication(<1.7.3) // <- Only added version constraint here.
extension Knob : Frobnicatable { ... }
#endif



Just a way to make it less low level.

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

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

[Patrick Smith via swift-evolution]

Could protocol Self change to just the first behaviour for classes?

If a conformance absolutely needs to have a method returning ‘only me but not 
my subclasses’, then it sets that conforming method to be final.


> On 13 May 2016, at 4:38 PM, Vladimir.S <sva...@gmail.com> wrote:
> 
> The proposed StaticSelf when used as `->StaticSelf` in protocol means ‘myself 
> or my some *base* class’. I.e. if this requirement was implemented in one of 
> base classes, any subclass automatically conforms to the protocol as it has 
> `->(myself or some base class)` in his hierarchy.
> 
> This is the difference with `->Self` in protocol which requires 'myself'.
> 
> On 13.05.2016 7:21, Patrick Smith via swift-evolution wrote:
>> I didn’t really understand some of the lead in discussion examples
>> regarding protocols A and B each being interwoven, but I would prefer to
>> see StaticSelf only used for concrete types, and protocols only to use
>> Self. If Self has problems with non-final classes, then maybe how it
>> works in protocols could change. A class could interpret a protocol’s
>> ‘Self’ as ‘myself or my subclasses’?
>> 
>> Maybe instead of introducing StaticSelf it could be renamed simply Self,
>> and ‘Self’ as used in protocols could change to something else?
>> ‘Instance’ perhaps?
>> 
>>> On 13 May 2016, at 12:21 PM, Joe Groff via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>>> On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> The invariant StaticSelf identifier will always refer to A, unlike
>>>> Self, which is covarying and refers to the type of the actual
>>>> instance. Since multiple inheritance for non-protocol types is
>>>> disallowed, this establishes this invariant type identifier with no
>>>> possibility for conflict.
>>>> 
>>>> Consider the following example, under the current system:
>>>> 
>>>> protocol StringCreatable {
>>>> 
>>>> static func createWithString(s: String) -> Self
>>>> 
>>>> }
>>>> 
>>>> 
>>>> extension NSURL: StringCreatable {
>>>> 
>>>> // cannot conform because NSURL is non-final
>>>> 
>>>> 
>>>> // error: method 'createWithString' in non-final class 'NSURL' must
>>>> return `Self` to conform to protocol 'A'
>>>> 
>>>> }
>>>> 
>>>> Introducing a static, invariant version of Self permits the desired
>>>> conformance:
>>>> 
>>>> protocol StringCreatable {
>>>> 
>>>> static func createWithString(s: String) -> StaticSelf
>>>> 
>>>> }
>>>> 
>>>> 
>>>> extension NSURL: StringCreatable {
>>>> 
>>>> // can now conform conform because NSURL is fixed and matches the
>>>> static
>>>> 
>>>> 
>>>> // type of the conforming construct. Subclasses need not
>>>> re-implement
>>>> 
>>>> 
>>>> // NOTE: the return type can be declared as StaticSelf *or* as
>>>> NSURL
>>>> 
>>>> 
>>>> //   they are interchangeable
>>>> 
>>>> 
>>>> static func createWithString(s: String) -> StaticSelf {
>>>> 
>>>> // ...
>>>> 
>>>> } }
>>>> 
>>>> 
>>> 
>>> As I've noted before, I don't think this makes sense to encode in the
>>> protocol. `Self` is already effectively invariant within a protocol.
>>> If a protocol doesn't have the foresight to use StaticSelf, then you
>>> still have the same problems retroactively conforming class
>>> hierarchies to the protocol. Whether a conformance is inherited or not
>>> feels more natural as a property of a conformance, not something that
>>> can be legislated a priori by a protocol definition.
>>> 
>>> Something like StaticSelf might still be useful as shorthand within a
>>> class definition with a long-winded name, though `StaticSelf` feels
>>> kind of long as a shortcut to me.
>>> 
>>> -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
>> 

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

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Patrick Smith via swift-evolution]

I forgot to add I like this style particularly as it matches how the type is 
declared (below). There’s a symmetry between them all. Obviously each var in a 
struct doesn’t need a comma between it, so it would be nice to not have to type 
them in the other cases too!

public struct ImageGraphic : GraphicType {
var imageSource: ImageSource
var width: Dimension?
var height: Dimension?
}


> On 13 May 2016, at 4:22 PM, Vladimir.S <sva...@gmail.com> wrote:
> 
> It seems like all problems could be solved by allowing line-break instead of 
> comma in list:
> 
>   public init(source: JSONObjectDecoder) throws {
>   try self.init(
>   imageSource: source.decode("imageSource")
>   width: source.decodeOptional("width")
>   height: source.decodeOptional("height")
>   )
>   }
>   
>   public func toJSON() -> JSON {
>   return .ObjectValue([
>   "imageSource": imageSource.toJSON()
>   "width": width.toJSON()
>   "height": height.toJSON()
>   ])
>   }
> 
> Shouldn't we move in that direction? Probably in addition to allow trailing 
> comma just to allow one to use his/her preferable formatting
> 
> On 13.05.2016 9:07, Patrick Smith via swift-evolution wrote:
>> I do it quite a lot, especially for initialising structs, enums. I use it to 
>> get the same benefits as a switch statement spread over several lines.
>> 
>> I think it’s often good to liberally apply new lines, as it aids legibility.
>> 
>> Here some sample code of mine using it:
>> 
>> extension ImageGraphic : JSONObjectRepresentable {
>>  public init(source: JSONObjectDecoder) throws {
>>  try self.init(
>>  imageSource: source.decode("imageSource"),
>>  width: source.decodeOptional("width"),
>>  height: source.decodeOptional("height")
>>  )
>>  }
>>  
>>  public func toJSON() -> JSON {
>>  return .ObjectValue([
>>  "imageSource": imageSource.toJSON(),
>>  "width": width.toJSON(),
>>  "height": height.toJSON()
>>  ])
>>  }
>> }
>> 
>> 
>>> On 13 May 2016, at 3:01 PM, Chris Lattner via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> On May 12, 2016, at 4:50 PM, Joe Groff <jgr...@apple.com> wrote:
>>>>>>  --- a.swift
>>>>>>  +++ a.swift
>>>>>>   foo(
>>>>>> x: 0,
>>>>>>  -  y: 1
>>>>>>  +  y: 1,
>>>>>>  +  z: 2
>>>>>>   )
>>>>>> 
>>>>>> Trailing commas avoid this:
>>>>>> 
>>>>>>  --- a.swift
>>>>>>  +++ a.swift
>>>>>>   foo(
>>>>>> x: 0,
>>>>>> y: 1,
>>>>>>  +  z: 2,
>>>>>>   )
>>>>> 
>>>>> You’re arguing that you want to read Swift code written like this?
>>>> 
>>>> I wouldn't mind it.
>>> 
>>> I personally find that style repulsive :-) and I haven’t seen swift code 
>>> commonly doing it.  I’m not sure that we want to encourage it either.
>>> 
>>>> The standard library already uses this style for function parameters, 
>>>> modulo the trailing comma, and I certainly prefer it to:
>>>>
>>>>>   --- a.swift
>>>>>   +++ a.swift
>>>>>foo( x: 0
>>>>>   , y: 1
>>>>>   +   , z: 2
>>>>>   )
>>> 
>>> I agree that this is even worse, but I also haven’t seen this used in Swift 
>>> code.  Have you?   Swift’s strictness with argument labels makes any of 
>>> this pretty unappealing to use.
>>> 
>>> If we were really concerned about this, a narrower way to solve the same 
>>> problem would be to allow a comma before the ), but *only* when there is a 
>>> newline between them.  I still don’t see why we’d want to encourage this 
>>> though.
>>> 
>>> -Chris
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 

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

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Patrick Smith via swift-evolution]

I do it quite a lot, especially for initialising structs, enums. I use it to 
get the same benefits as a switch statement spread over several lines.

I think it’s often good to liberally apply new lines, as it aids legibility.

Here some sample code of mine using it:

extension ImageGraphic : JSONObjectRepresentable {
public init(source: JSONObjectDecoder) throws {
try self.init(
imageSource: source.decode("imageSource"),
width: source.decodeOptional("width"),
height: source.decodeOptional("height")
)
}

public func toJSON() -> JSON {
return .ObjectValue([
"imageSource": imageSource.toJSON(),
"width": width.toJSON(),
"height": height.toJSON()
])
}
}


> On 13 May 2016, at 3:01 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> On May 12, 2016, at 4:50 PM, Joe Groff  wrote:
--- a.swift
+++ a.swift
 foo(
   x: 0,
-  y: 1
+  y: 1,
+  z: 2
 )
 
 Trailing commas avoid this:
 
--- a.swift
+++ a.swift
 foo(
   x: 0,
   y: 1,
+  z: 2,
 )
>>> 
>>> You’re arguing that you want to read Swift code written like this?
>> 
>> I wouldn't mind it.
> 
> I personally find that style repulsive :-) and I haven’t seen swift code 
> commonly doing it.  I’m not sure that we want to encourage it either.
> 
>> The standard library already uses this style for function parameters, modulo 
>> the trailing comma, and I certainly prefer it to:
>>  
>>> --- a.swift
>>> +++ a.swift
>>>  foo( x: 0
>>> , y: 1
>>> +   , z: 2
>>> )
> 
> I agree that this is even worse, but I also haven’t seen this used in Swift 
> code.  Have you?   Swift’s strictness with argument labels makes any of this 
> pretty unappealing to use.
> 
> If we were really concerned about this, a narrower way to solve the same 
> problem would be to allow a comma before the ), but *only* when there is a 
> newline between them.  I still don’t see why we’d want to encourage this 
> though.
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Allowing `guard let self = self else { … }` for weakly captured self in a closure.

[Patrick Smith via swift-evolution]

How about [weak(guard) self]? It would only work with closures returning -> () 
as if you are weakly capturing something you are likely to be messaging that 
not returning some, so they can be ignored.

networkRequest.fetchData() { [weak(guard) self] result in
switch result {
case .succeeded(let data):
self.processData(data)

case .failed(let err):
self.handleError(err)
}
}

Patrick


> On 13 May 2016, at 2:10 AM, Hoon H. via swift-evolution 
>  wrote:
> 
> I am replying months lately, but anyway, I just read your proposal, and I 
> think this is cool.
> 
>[guard self]
> 
> I am in doubt about another stuffs such as `[guard self else …]`. I hope your 
> proposal to be accepted. I am getting a bit tired of writing `guard let S = 
> self else { … }`.
> 
> I am still not sure how to use mailing list… but I hope this to be a correct 
> way.
> …Sending again because I mistyped Evan’s address.
> 
> — Hoon H.
> 
> ___
> 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] [Draft] Introducing StaticSelf, an Invariant Self

[Patrick Smith via swift-evolution]

I didn’t really understand some of the lead in discussion examples regarding 
protocols A and B each being interwoven, but I would prefer to see StaticSelf 
only used for concrete types, and protocols only to use Self. If Self has 
problems with non-final classes, then maybe how it works in protocols could 
change. A class could interpret a protocol’s ‘Self’ as ‘myself or my 
subclasses’?

Maybe instead of introducing StaticSelf it could be renamed simply Self, and 
‘Self’ as used in protocols could change to something else? ‘Instance’ perhaps?

> On 13 May 2016, at 12:21 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> The invariant StaticSelf identifier will always refer to A, unlike Self, 
>> which is covarying and refers to
>> the type of the actual instance. Since multiple inheritance for non-protocol 
>> types is disallowed,
>> this establishes this invariant type identifier with no possibility for 
>> conflict.
>> 
>> Consider the following example, under the current system:
>> 
>> protocol StringCreatable 
>> {
>> 
>> static func createWithString(s: String) -> Self
>> 
>> }
>> 
>> 
>> extension NSURL: StringCreatable 
>> {
>> 
>> // cannot conform because NSURL is non-final
>> 
>> 
>> // error: method 'createWithString' in non-final class 'NSURL' must return 
>> `Self` to conform to protocol 'A'
>> 
>> }
>> 
>> Introducing a static, invariant version of Self permits the desired 
>> conformance:
>> 
>> protocol StringCreatable 
>> {
>> 
>> static func createWithString(s: String) -> StaticSelf
>> 
>> }
>> 
>> 
>> extension NSURL: StringCreatable 
>> {
>> 
>> // can now conform conform because NSURL is fixed and matches the static
>> 
>> 
>> // type of the conforming construct. Subclasses need not re-implement
>> 
>> 
>> // NOTE: the return type can be declared as StaticSelf *or* as NSURL
>> 
>> 
>> //   they are interchangeable
>> 
>> 
>> static func createWithString(s: String) -> StaticSelf
>> { 
>> 
>> // ...
>> 
>> }
>> }
>> 
>> 
> 
> As I've noted before, I don't think this makes sense to encode in the 
> protocol. `Self` is already effectively invariant within a protocol. If a 
> protocol doesn't have the foresight to use StaticSelf, then you still have 
> the same problems retroactively conforming class hierarchies to the protocol. 
> Whether a conformance is inherited or not feels more natural as a property of 
> a conformance, not something that can be legislated a priori by a protocol 
> definition.
> 
> Something like StaticSelf might still be useful as shorthand within a class 
> definition with a long-winded name, though `StaticSelf` feels kind of long as 
> a shortcut to me.
> 
> -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-0088: Modernize libdispatch for Swift 3 naming conventions

[Patrick Smith via swift-evolution]

+1 to naming like this. dispatch() and dispatchSynchronously() if needed to 
please thy naming gods.


> On 13 May 2016, at 4:16 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> dispatch() and dispatchSync() would be my preference as asynchronous dispatch 
> is the point of GCD and synchronous dispatch is a special case and therefore 
> I think the visual asymmetry is an advantage.
> 
> -Thorsten
> 
> 
>> Am 12.05.2016 um 20:10 schrieb James Dempsey via swift-evolution 
>> >:
>> 
>> 
>>> On May 11, 2016, at 8:02 PM, Ricardo Parada >> > wrote:
>>> 
>>> 
>>> 
>>> For synchronously and asynchronously how about the adverbs before the verb:
>>> 
>>> syncDispatch()
>>> asyncDispatch()
>> 
>> 
>> I think with the abbreviation ‘sync’ it’s very easy to read ‘sync’ as a verb 
>> and dispatch as a noun.
>> 
>> i.e. I’m going to sync up with you about our plan
>> i.e. I received a dispatch from headquarters
>> 
>> I would be very fine with
>> 
>> dispatchAsync() and dispatchSync() as method names.
>> 
>> 
>> 
>>> 
>>> ?
>>> 
>>> On May 11, 2016, at 10:50 AM, James Dempsey >> > wrote:
>>> 
> So maybe that will conform to the API naming guideline?  Or would the 
> verb have to be in the base name of the func?
 
 
 It seems from the guidelines that the intent is for the verb to be in the 
 base name of the func, especially since there is another set of guidelines 
 for naming function parameters.
 
 In general the other methods in the proposal are verbs (perform(), 
 notify(), wait(), cancel(), etc.)
 
 At least for me, not including a verb makes the API read like the sentence 
 “The dog quickly”.  This wasn’t so bad in the C API, because you could 
 read the word ‘dispatch’ as the verb.
 
 
 Looking at the current GDC API, it does seem like dispatching 
 synchronously is the rare and special case.
 
 Could there be just a single dispatch() method, with async as a flag with 
 a default value of true?
 
 It might be a little ugly because most of the other parameters of the 
 proposed asynchronously() method would not apply in the sync case.
 
 James
 
 
 
> On May 11, 2016, at 7:14 AM, Ricardo Parada  > wrote:
> 
> Jacob Bandes-Storch suggested:
> 
> synchronously(execute work: …)
> 
> So maybe that will conform to the API naming guideline?  Or would the 
> verb have to be in the base name of the func?
> 
> Or perhaps:
> 
> synchronously(dispatch work: …)
> asynchronously(dispatch work: …)
> 
> 
> 
>> On May 11, 2016, at 9:32 AM, James Dempsey via swift-evolution 
>> > wrote:
>> 
>> The method names
>> 
>>  synchronously()
>>  asynchronously() 
>> 
>> are both adverbs, not noun phrases or verb phrases.
>> These methods have side effects, so each name should have a verb in it 
>> to make it a verb phrase.
>> 
>> 
>> Since these are the methods where you actually dispatch a block into a 
>> queue
>> 
>> dispatchSynchronously()
>> dispatchAsynchronously()
>> 
>> would include the verb in the name of the methods.
>> 
> 
 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Patrick Smith via swift-evolution]

Hi Tony,

Thanks for the response! As Kevin said:

“And if done right, the swiftified types can operate without Foundation at all”

This is why I think DispatchData would be superior to NSData, as NSData brings 
along all the rest of Foundation, whereas the entire Dispatch library looks 
like a great fit for Swift.

In fact, won’t Foundation require Dispatch as a dependency? So there’s already 
a doubling there if it is.

I think Dispatch is much more native than Foundation, and would vote to have 
its Dispatch- prefixes removed rather than Foundation remove its NS- ones.

Patrick


> On 13 May 2016, at 5:06 AM, Tony Parker <anthony.par...@apple.com> wrote:
> 
>> 
>> On May 12, 2016, at 1:32 AM, Patrick Smith via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I second Matthew’s points. I believe dropping NS- is more harmful than 
>> helpful, especially for the future. People have been using Foundation with 
>> the prefix for decades, so I don’t think there’s a longing need that will 
>> make using it in Swift unbearable. It has an older Objective-C flavoured 
>> approach, relying heavily on classes, run loops, key value observing (e.g. 
>> NSOperation), exceptions, and notifications. I think its philosophy will 
>> stand out more than its NS- prefix. Even if many classes become value types, 
>> it feels more like a port.
>> 
>> I think for something to be so central as the recommended ‘foundational’ 
>> library for Swift, it carries too much baggage, which is unfortunate in the 
>> light of Swift’s radical eagerness to reject unnecessary legacy.
>> 
>> Many Foundation classes expect NSObject subclasses for delegates and for key 
>> value coding & observing. Key value observing requires on-the-fly 
>> subclassing at run time, something which goes strongly against Swift’s 
>> philosophy AFAIK.
>> 
>> Foundation is in some cases a wrapper around underlying technologies such as 
>> GCD, because years ago an Objective-C wrapper was seen as a more friendly, 
>> more safe, and a more familiar object-oriented approach. With Swift we have 
>> the power to make those technologies themselves more friendly, safe, and 
>> familiar with modernisations such as the current proposal for libdispatch. 
>> Extensions allow us to add properties and methods directly to the native 
>> types.
>> 
>> NSURL has methods such as .getResourceValue(_:forKey:) that involve mutable 
>> state.
>> 
>> I think removing the prefixes will take valuable real estate for types such 
>> as ‘URL’ and ‘Data’, which instead can have new replacements made, focused 
>> on the use-cases of only Swift. I think DispatchData could be a fine choice 
>> for ‘Data’, and has the strong benefit that it bridges to NSData on Darwin.
>> 
> 
> Perhaps you missed it, but SE-0069 adds corresponding value types for URL and 
> Data, among others.
> 
> - Tony
> 
>> I fully support the idea of improving Foundation, and of there being a 
>> Linux-compatible version. I don’t support it being as first class as the 
>> standard library or libdispatch, and don’t support removing the NS prefixes.
>> 
>> Patrick
>> 
>> 
>>> On 11 May 2016, at 1:36 AM, Matthew Johnson via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> What is your evaluation of the proposal?
>>> I very much support hoisting types, updating enumerations, and updating the 
>>> NSStringEncoding constants.  
>>> 
>>> I do not support dropping NS on type level names.  Dropping the 2 character 
>>> prefix is a very small benefit and it comes with very real costs.  I 
>>> believe unprefixed top level names should not be taken without a manual 
>>> review of the API design.  
>>> 
>>> Types which will be value types in the future are obvious candidates for 
>>> redesign but are not the only types whose API would benefit by human 
>>> consideration and Swiftification.  Keeping the NS prefix until this happens 
>>> recognizes that the Swiftification of Foundation is a work in progress.  It 
>>> will give us more options in the future that don’t involve breaking 
>>> changes.  
>>> 
>>> It will also serve as a signal to developers about what kinds of APIs 
>>> should be considered idiomatic in Swift.  If we want developers to learn 
>>> how to distinguish idiomatic Swift, our API guidelines, etc from 
>>> Objective-C mappings we need to provide some cues.  I believe name prefixes 
>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Patrick Smith via swift-evolution]

I second Matthew’s points. I believe dropping NS- is more harmful than helpful, 
especially for the future. People have been using Foundation with the prefix 
for decades, so I don’t think there’s a longing need that will make using it in 
Swift unbearable. It has an older Objective-C flavoured approach, relying 
heavily on classes, run loops, key value observing (e.g. NSOperation), 
exceptions, and notifications. I think its philosophy will stand out more than 
its NS- prefix. Even if many classes become value types, it feels more like a 
port.

I think for something to be so central as the recommended ‘foundational’ 
library for Swift, it carries too much baggage, which is unfortunate in the 
light of Swift’s radical eagerness to reject unnecessary legacy.

Many Foundation classes expect NSObject subclasses for delegates and for key 
value coding & observing. Key value observing requires on-the-fly subclassing 
at run time, something which goes strongly against Swift’s philosophy AFAIK.

Foundation is in some cases a wrapper around underlying technologies such as 
GCD, because years ago an Objective-C wrapper was seen as a more friendly, more 
safe, and a more familiar object-oriented approach. With Swift we have the 
power to make those technologies themselves more friendly, safe, and familiar 
with modernisations such as the current proposal for libdispatch. Extensions 
allow us to add properties and methods directly to the native types.

NSURL has methods such as .getResourceValue(_:forKey:) that involve mutable 
state.

I think removing the prefixes will take valuable real estate for types such as 
‘URL’ and ‘Data’, which instead can have new replacements made, focused on the 
use-cases of only Swift. I think DispatchData could be a fine choice for 
‘Data’, and has the strong benefit that it bridges to NSData on Darwin.

I fully support the idea of improving Foundation, and of there being a 
Linux-compatible version. I don’t support it being as first class as the 
standard library or libdispatch, and don’t support removing the NS prefixes.

Patrick


> On 11 May 2016, at 1:36 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> What is your evaluation of the proposal?
> I very much support hoisting types, updating enumerations, and updating the 
> NSStringEncoding constants.  
> 
> I do not support dropping NS on type level names.  Dropping the 2 character 
> prefix is a very small benefit and it comes with very real costs.  I believe 
> unprefixed top level names should not be taken without a manual review of the 
> API design.  
> 
> Types which will be value types in the future are obvious candidates for 
> redesign but are not the only types whose API would benefit by human 
> consideration and Swiftification.  Keeping the NS prefix until this happens 
> recognizes that the Swiftification of Foundation is a work in progress.  It 
> will give us more options in the future that don’t involve breaking changes.  
> 
> It will also serve as a signal to developers about what kinds of APIs should 
> be considered idiomatic in Swift.  If we want developers to learn how to 
> distinguish idiomatic Swift, our API guidelines, etc from Objective-C 
> mappings we need to provide some cues.  I believe name prefixes are a good 
> way to do this.
> 
> I hope that we will move forward with most of this proposal while keeping the 
> NS prefix for top-level names.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Yes, but we need to do this carefully, deliberately and in a way that we 
> won’t regret in the future.  I believe several parts of the proposal are 
> warranted, but the namesake “drop NS prefix” portion should deferred until 
> each type receives manual consideration and possibly redesign.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> Mostly yes.  However, taking top-level unprefixed names without a process of 
> Swiftification does not.
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> I think this question is N/A for this proposal.
> 
> I hesitate in saying this, but I think the best comparison to consider is the 
> origin of Foundation and Cocoa themselves.  They are fantastic Objective-C 
> APIs.  If they had originated by wrapping pre-existing APIs written in a 
> different language with different idioms and then incrementally enhanced I 
> wonder if they may have been less fantastic.  
> 
> I believe reserving unprefixed top-level names for manually designed, 
> idiomatic types is the path for Swift that avoids this risk altogether and 
> gives us the best chance possible at an incredible, idiomatic set of 
> libraries.
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> I participated in the discussion, read the proposal, and carefully considered 
> the 

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Patrick Smith via swift-evolution]

I’m going to propose the keyword #litter as an alias for , so I can throw 
garbage syntax into my code more effectively seven letters at time :P

I think this is just a choice of taste, and this is offering an additional 
choice. You don’t have to agree with it, you don’t have to make use of it, you 
don’t even have to know it’s there.

We’ve all seen and written messy code, and it wasn’t due to the punctuation. 
There are much more powerful weapons at hand for that.


> On 12 May 2016, at 1:25 AM, Evan Maloney via swift-evolution 
>  wrote:
> 
> 
>>> It feels wrong to allow garbage syntax lying around in one's code simply 
>>> for the sake of occasional convenience.
>> 
>> Would you then recommend removing trailing comma support for collections on 
>> the same principle?
> 
> Yes.
> 
> ___
> 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-0088: Modernize libdispatch for Swift 3 naming conventions

[Patrick Smith via swift-evolution]

You could use dispatch(), and name the synchronous method something else? 
synchronize() or its shortened form sync(), which is a real word, or maybe 
wait(). (However, there was a beauty in the yin-yang of async/sync in the 
original API. I would call them terms of art, like map, filter, reduce, etc)


class DispatchQueue : DispatchObject {
func synchronize(work: @convention(block) () -> Void)

func dispatch(
group: DispatchGroup? = nil, 
qos: DispatchQoS = .unspecified, 
flags: DispatchWorkItemFlags = [], 
work: @convention(block) () -> Void)
}

queue.dispatch(group: group) {
print("Hello World")
}

queue.synchronize {
print("Hello World")
}


> On 12 May 2016, at 12:50 AM, James Dempsey via swift-evolution 
>  wrote:
> 
>> So maybe that will conform to the API naming guideline?  Or would the verb 
>> have to be in the base name of the func?
> 
> 
> It seems from the guidelines that the intent is for the verb to be in the 
> base name of the func, especially since there is another set of guidelines 
> for naming function parameters.
> 
> In general the other methods in the proposal are verbs (perform(), notify(), 
> wait(), cancel(), etc.)
> 
> At least for me, not including a verb makes the API read like the sentence 
> “The dog quickly”.  This wasn’t so bad in the C API, because you could read 
> the word ‘dispatch’ as the verb.
> 
> 
> Looking at the current GDC API, it does seem like dispatching synchronously 
> is the rare and special case.
> 
> Could there be just a single dispatch() method, with async as a flag with a 
> default value of true?
> 
> It might be a little ugly because most of the other parameters of the 
> proposed asynchronously() method would not apply in the sync case.
> 
> James
> 
> 
> 
>> On May 11, 2016, at 7:14 AM, Ricardo Parada > > wrote:
>> 
>> Jacob Bandes-Storch suggested:
>> 
>> synchronously(execute work: …)
>> 
>> So maybe that will conform to the API naming guideline?  Or would the verb 
>> have to be in the base name of the func?
>> 
>> Or perhaps:
>> 
>> synchronously(dispatch work: …)
>> asynchronously(dispatch work: …)
>> 
>> 
>> 
>>> On May 11, 2016, at 9:32 AM, James Dempsey via swift-evolution 
>>> > wrote:
>>> 
>>> The method names
>>> 
>>> synchronously()
>>> asynchronously() 
>>> 
>>> are both adverbs, not noun phrases or verb phrases.
>>> These methods have side effects, so each name should have a verb in it to 
>>> make it a verb phrase.
>>> 
>>> 
>>> Since these are the methods where you actually dispatch a block into a queue
>>> 
>>> dispatchSynchronously()
>>> dispatchAsynchronously()
>>> 
>>> would include the verb in the name of the methods.
>>> 
>> 
> 
> ___
> 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] Re-Visit Proposal: Weak Native Swift Containers (12 2015)

[Patrick Smith via swift-evolution]

I remember reading that Swift’s weak references are ‘lazy’, and only clear (and 
release if needed) when they are next accessed. So you couldn’t observe them 
AFAIK.


> On 11 May 2016, at 11:23 PM, Haravikk via swift-evolution 
>  wrote:
> 
> I’ve used the following in some similar cases:
> 
>   struct Weak {
>   weak var value:T?
>   init(_ value:T) { self.value = value }
>   }
>   let myCache = Array()
> 
> When inserting new values I just look for the first one that’s nil or append 
> if it’s taking too long, but you’re right, something more reactive would be 
> better, for example if the above were observable I could do something about 
> it as soon as it became nil.
> 
>> On 11 May 2016, at 14:00, Dominik Pich via swift-evolution 
>>  wrote:
>> 
>> Hello,
>> I'd like to re-visit a proposal from Riley Testut about weak containers. 
>> Since no conclusion/outcome was achieved (AFAICS from looking at the 
>> archives and the repository)
>> and since I just would have needed this again too... I found it a good time 
>> to re-propose this :D
>> 
>> ---
>> 
>> "
>> In multiple places in my projects, I essentially recreate the “multiple 
>> observer” pattern used by NSNotificationCenter. Originally this was 
>> implemented by simply maintaining an array of observers, and adding 
>> to/removing from it as necessary. However, this had the unintended side 
>> effect of maintaining a strong reference to the observers, which in many 
>> cases is undesirable (for the same reasons it’s common to mark delegate 
>> properties as weak).
>> 
>> Now, I’m using a private NSHashTable instance, and expose the observers as 
>> public API by creating a public computed property which essentially returns 
>> an array derived from the NSHashTable like so:
>> 
>> public var receivers: [GameControllerReceiverType] {
>>   // self.privateReceivers.allObjects as! [GameControllerReceiverType] 
>> crashes Swift :(
>>   return self.privateReceivers.allObjects.map({ $0 as! 
>> GameControllerReceiverType })
>> }
>> 
>> This workaround works, but is undesirable for a number of reasons. Most 
>> notably:
>> 
>> • NSHashTable is not a native Swift collection, and is also not in the 
>> Foundation Swift port, so it is not portable to other systems.
>> • It also has not yet been annotated with generics, so it loses the nice 
>> type safety of other Swift collections. Because of this, I have to map the 
>> objects to the appropriate type before returning the allObjects array, which 
>> runs in O(n) time instead of O(1).
>> • It’s repetitive. For every type that wants to implement this pattern, they 
>> must maintain both a public computed method and a private NSHashTable 
>> instance. This gets worse when this should be part of a protocol; there’s no 
>> way to enforce that each type conforming to it has a NSHashTable, while also 
>> keeping that information private from the consumer of the API.
>> 
>> I think native swift collections with support for weak references for their 
>> contents would be very useful, and in more places than just listed above. I 
>> don’t think Array could be easily extended to support it (what happens if a 
>> value is released? does everything shift down? do they keep their indices?), 
>> but Set and Dictionary (where the keys and/or values could be weak, akin to 
>> NSMapTable) would be good candidates IMO.
>> 
>> Thoughts?"
>> 
>> --reference to last message thread: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001579.html
>> (last messages were 'arguing' how to implement it)
>> 
>> 
>> 
>> ___
>> 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] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Patrick Smith via swift-evolution]

I +1 the proposal. If it doesn’t make the compiler more complicated, and its a 
purely opt-in feature for writers, then I don’t why it couldn’t literally 
extend to everywhere there’s a comma-separated list as a general rule.

> On 11 May 2016, at 6:57 AM, Rob Napier via swift-evolution 
>  wrote:
> 
> On Tue, May 10, 2016 at 2:53 PM, Chris Lattner via swift-evolution 
> > wrote:
> 
> * What is your evaluation of the proposal?
> 
> Trailing commas is clearly very useful in the collections case. While that 
> case is more common than functions and tuples, I don't see any reason that 
> collections should be treated as a special case. Why should some 
> comma-separated lists allow trailing commas and some not?
> 
> This seems a reasonable move towards consistency and is useful in some cases 
> while not harmful in others. When in doubt, I'd rather broad rules ("trailing 
> commas are allowed in comma-separated lists") rather than special cases. This 
> improves teachability.
> 
> It also improves diffs when functions pick up new parameters, particularly 
> ones with default values. This is particularly common (and expected) in 
> constructors. That's valuable.
> 
>  
> * Is the problem being addressed significant enough to warrant a 
> change to Swift?
> 
> As a language rule simplification, I believe it's worth a change if it 
> doesn't introduce problematic corner cases. The fact that it improves diffs 
> is no less valuable for functions than it is for collections.
> 
>  
> * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes; it definitely feels Swifty in the same way that it does for collections. 
> There's no reason for Swift to treat them differently.
> 
>  
> * If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> 
> I've seen this in Perl, Python, and Go. Basically every language I've used 
> that allows trailing commas in collections also allows them in function 
> calls. In Go, the trailing comma is mandatory in some cases. This has been 
> nice for consistency.
> 
>  
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> Quick reading.
> 
> -Rob
> 
> ___
> 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: Soft unwrapping of optionals

[Patrick Smith via swift-evolution]

I actually think this is less safe. It depends on the situation for what value 
the default should be. Sometimes it will be false, other times it will be true. 
So far better to explicitly show what the default is.


> On 11 May 2016, at 10:16 PM, Basem Emara via swift-evolution 
>  wrote:
> 
> Forcing unwrapping of optionals is bad practice, but safely unwrapping can be 
> tedious. I’m hoping for something in between that would that would provide 
> soft unwrapping using a syntax like: myVar?!
> 
> For example, currently we have to do this:
> 
> let temp = (myString ?? “”); print(“\(temp)”)
> if (myString ?? “”).isEmpty {…}
> if myBool ?? false {…}
> if (myInt ?? 0) > otherInt {…}
> 
> To something like this instead:
> 
> print(“\(temp?!)”)
> if myString?!.isEmpty {…}
> if myBool?! {…}
> if myInt?! > otherInt {…}
> 
> What this is implying is that it will attempt to unwrap or use the default of 
> the type.
> 
> Of course, this will only work with primitive types and leverage their 
> implicit default values which would go a long way with tedious code and more 
> safety (less forced unwrapping in the world). Otherwise it will produce a 
> compile error if doing something like: myCustomType?!. What do you think?
> 
> Basem
> ___
> 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] Standard library 'Data' type pre-proposal

[Patrick Smith via swift-evolution]

Hi Austin,

The proposal looks well fleshed out! Another alternative to consider is the 
‘DispatchData’ struct from libdispatch currently being reviewed? Some of 
additions these could be added as an extension to that type? Or perhaps a 
protocol could be made ‘DataProtocol’, that has a base set of required methods 
and a further set of extensions using that base. Then NSData and DispatchData 
can conform and implement those base methods and each get the functionality. 
But personally I think it would be nice to make DispatchData the native Swift 
data type, whether the libdispatch team would accept extensions in the future 
like this I don’t know, but I think it would be interesting.

Patrick


> On 11 May 2016, at 7:37 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> Hello swift-evolution,
> 
> I've been thinking about a standard library 'Data' type for a while, 
> analogous to NSData in the same way Swift's Arrays and Dictionaries are 
> analogous to NSArrays and NSDictionaries. A first-class container for binary 
> data that is available to every Swift user, conforms to Swift semantics, and 
> is safer and easier to work with than UnsafeBufferPointer seems like a 
> natural fit for the standard library.
> 
> As such, I've put together a very preliminary proposal, which can be found 
> here: 
> https://github.com/austinzheng/swift-evolution/blob/d2/proposals/-stdlib-data.md
>  
> .
>  I present it not as a way to impose a vision of what such a Data type should 
> look like, but rather as a way to catalyze discussion (including discussion 
> as to whether or not a Data type is even a good idea in the first place).
> 
> Some thoughts:
> 
> - It's not clear if the methods to convert to and from base-64 encoded data 
> are necessary. The state flag that tries to mark whether or not a Data 
> represents base-64-encoded string stored as a data may be unnecessary as well.
> 
> - I didn't really go into how NSData should be bridged. Special consideration 
> needs to be given to how any native Data type would interact with the 
> overlays described in 
> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>  
> .
>  It's possible (and only if a compelling technical reason exists) that the 
> Foundation implementation of NSData can in the future be moved into 
> Swift/supplanted by such a native data type, with API extensions to provide 
> conformance to the Objective-C Foundation API. This proposal should not be 
> seen as an attempt to usurp Foundation's job, though - there are plenty of 
> to-be-value types in Foundation whose inclusion directly in the standard 
> library makes little sense.
> 
> - Perhaps Data should be generic over various types of fixed-width integers 
> (signed and unsigned, 8, 16, 32, 64, machine-width, etc). In that case it 
> might also provide generic views (for example, to allow iteration over a 
> Data as if it were a collection of UInt8 bytes). I'm not yet sure if 
> this is feasible or desirable.
> 
> Finally, it's possible that this is strictly Swift 4 territory, in which case 
> I'm happy to withdraw from discussion until the time is right later this year.
> 
> Best regards,
> Austin
> ___
> 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-0088: Modernize libdispatch for Swift 3 naming conventions

[Patrick Smith via swift-evolution]

Sorry, instead of saying this I meant to say fall into the pit of success with 
concurrency and QOS. 
(http://blog.codinghorror.com/falling-into-the-pit-of-success/)
The Foundation APIs such as -[NSData writeToURL:atomically:] are easy to find 
yet synchronous, and might be a newcomer’s first choice. A new API built on top 
of libdispatch might make doing the right thing the first choice.

> On 11 May 2016, at 3:41 PM, Patrick Smith  wrote:
> 
> that get have concurrency and compatible with QOS by default.

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

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Patrick Smith via swift-evolution]

Oh man, this is fantastic!

* What is your evaluation of the proposal?

Great stuff, really brings dispatch into the world of Swift, and seems like it 
will not only make it more pleasant but better.

I have a couple of questions:
- Why is everything prefixed with Dispatch-, when you can surely rename the 
module, e.g. Dispatch.Queue, Dispatch.IO, or is the concern that this could 
clash? It just would be nice to write Queue directly. Group can become 
WorkGroup, to match WorkItem.
- Can static vars be added to DispatchQueue for all the concurrent QOS? So you 
can just write DispatchQueue.utility, or DispatchQueue.utilityConcurrent. I 
think this would increase their adoption.
- Is the .synchronously method able to have the @noescape attribute added?
- .asynchronously/.synchronously feels a bit long, will be interested to see 
what others think.
- Will DispatchData bridge to Foundation’s NSData, both in Darwin and Linux?

To be honest, I’d rather this become more of a standard alongside Swift than 
Foundation. I think you can build interesting modern APIs on top of this, such 
as for working with files and data, that get have concurrency and compatible 
with QOS by default.

For example, DispatchData supersedes NSData as Swift’s native ‘Data’, and extra 
methods that NSData has DispatchData gets in the same way Swift’s String gets 
some NSString methods. Eventually these methods are ported to DispatchData as 
extensions, or in new forms that make use of protocols and other Swift features.

* Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes, I think this will increase adoption, and make it feel like an official 
part of Swift.

* Does this proposal fit well with the feel and direction of Swift?
Yes, this makes libdispatch modern and suitable for future applications.

* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Compared to using it in Objective-C, it seems to cover all the features.

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


> On 11 May 2016, at 2:39 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" 
> begins now and runs through May 17. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.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.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> 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] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[Patrick Smith via swift-evolution]

How about:

Consuming (from)
Producing (to)


IntegerLiteralConsuming
StringLiteralConsuming

CustomStringProducing
CustomDebugStringProducing


As for something that does both, all I could find was ‘bidirectional’, 
‘two-way’, ‘mutual’, ‘duplex’. I tried searching in biology 
(https://en.wikipedia.org/wiki/Organic_reaction), but couldn’t find anything. I 
like the idea of just conforming to both protocols, and some sort of protocol 
typealias. Or staying with Representable.


> On 11 May 2016, at 12:33 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
>> 
>> On May 10, 2016, at 6:51 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On May 10, 2016, at 11:48 AM, Chris Lattner  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0041: Updating Protocol Naming Conventions for 
>>> Conversions" begins now and runs through May 16. The proposal is available 
>>> here:
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
>> 
>> Here are comments from someone who preferred to stay anonymous.  These are 
>> not my own:
>> 
>> 
>> 
>> 
>> * What is your evaluation of the proposal?
>> 
>> I rather agree with the comments mentioned in the proposal from the Standard 
>> Library design team, in that I agree with the basic intention of the 
>> proposal, but I’m not convinced about the proposed answer. Specifically:
> 
> 
> We'd be happy to bikeshed again.
> 
> I think fundamentally our take on this is:
> 
> * We want there to be a standard that expresses the three 
> conversion/initialization styles.
> * We feel the system is currently broken. And we want to have a coherent and 
> settled vision in place for 3, even imperfect.
> * We're flexible about the naming but it should be (1) Swifty and (2) well 
> grounded in meaning.
> 
> Let me turn the floor over to Matthew here.
> 
> -- E
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [RFC] #Self

[Patrick Smith via swift-evolution]

I think Type fits really well. Because every class, struct, and enum gets a 
static member called ‘Type’. But you can only use it outside the declaration 
(String.Type), not inside.

So similar to how types declared inside can be referenced:

struct A {
  enum Kind {
case cat
case dog
  }

  var kind: Kind // Use nested type here; I don’t have to write A.Kind
}


We could use Type in a similar way:

struct B {
  // This gets created automatically for every type, and is accessible today 
from B.Type
  //metatype Type { … }

  var children: [Type] // Use here in the same way as Kind above
}


> On 11 May 2016, at 8:32 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On May 10, 2016, at 5:24 PM, Hooman Mehr  > wrote:
> 
>> 
>>> On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution 
>>> > wrote:
 That said, I’m not sure I understand the concrete use-cases.  When is this 
 concept important?  When is “Self” not good enough?
>>> 
>>> The only case where there is new functionality is when this is used in a 
>>> protocol requirement.  I gave an example earlier today.  
>> 
>> This functionality is the key: Ability of an open (non-final) class to 
>> conform to a protocol that lets it return an instance of the conforming type 
>> (itself). Self does not work for that and we can’t change its behavior (or 
>> can we?) So one solution seems to be Matt’s proposal. This functionality is 
>> important for me and an example use case is class clusters. For the client 
>> code it is sealed and acts just like a final class, but internally it may 
>> return a subclass that is an implementation detail. We should be able to do 
>> this.
> 
> Agree and this is why I am willing to write the proposal for this.  There was 
> a discussion a few months ago about this problem and a few solutions were 
> kicked around.  The biggest problem with this approach at the time was lack 
> of a good name, which I believe we now have in Type.
> 
> I'm going to let the discussion continue for a day or two and will write a 
> proposal if no significant counter arguments arise.
> 
> -Matthew
> 
>> 
>> Hooman
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-build-dev] [Review] SE-0085: Package Manager Command Names

[Patrick Smith via swift-evolution]

I like the readability of `swiftpm` or even `swift package`, but `spm` is nice 
for typing.

This is a silly request: what if swift packages were called eggs? Like Ruby’s 
gems.

And I’ve no idea if there’s already an ‘egg’ tool out there:
egg init
egg update
egg test


> On 11 May 2016, at 3:35 AM, orta therox via swift-evolution 
>  wrote:
> 
> I agree, I think just `swiftpm` is a great mix of ease of use and 
> discoverability, for exactly the reasons you propose. I’ve been trying to 
> always use that when talking about Swift Package Manager for the last few 
> months.
> 
> I think this is also better than `swift xxx` due to swiftpm really being a 
> different user context from `swift` commands. Yes, under the hood it’s doing 
> swift-y things, but package management is not compiling.
> 
> -- 
> 
> [ ·/ ]Orta Therox
> 
>> w/ Artsy 
>> CocoaPods  / CocoaDocs  / 
>> GIFs.app @orta 
>>  / orta.github.com 
>> On May 10, 2016, at 12:38 PM, Rick Ballard via swift-build-dev 
>> > wrote:
>> 
>> 
>>> On May 10, 2016, at 8:49 AM, Matthew Johnson via swift-build-dev 
>>> > wrote:
>>> 
>>> 
 On May 10, 2016, at 2:19 AM, Dan Appel via swift-evolution 
 > wrote:
 
 +1 to `swift package` being a little too verbose. However, I like the 
 alternative `swift pm`/`swiftpm` (as noted in the proposal) even less. I 
 have already been referring to the package manager as SPM, so IMO that 
 name does not lose out on any clarity while also allowing it to be terse 
 enough for every day use. 
 
 I would not be against having both `spm` and `swift package` as Honza 
 suggested.
>>> 
>>> + 1 to the proposal in general and also to adding the `spm` alias.
>> 
>> Question for those of you who are advocating for a "spm" alias: Do you have 
>> a strong argument / preference for "spm" vs "swiftpm"? Personally I have 
>> been abbreviating the project as "swiftpm" and not "spm" when I talk about 
>> it, and have been trying to push that as the preferred abbreviation. "spm" 
>> is a few less keystrokes, but is a much more generic, less googleable name; 
>> out of context, it's impossible to know what it refers to. Once the project 
>> gets enough mindshare, like "npm" has, that might be less of an issue, but I 
>> still personally prefer the more descriptive "swiftpm". Thoughts?
>> 
>>  - Rick
>> 
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-build-dev 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [proposal] Treat (case .Foo = bar) as a Boolean expression

[Patrick Smith via swift-evolution]

I like the idea of a boolean expression! I think it is cleaner; the required if 
statement is a pain.

For the second idea, I’ve wondered if there could be some way of unwrapping the 
associated values:

case .foo(?) = bar

It would produce an optional. This would let you do:

let isAlan = (case .foo(?) = bar) == “Alan”


There’s also force unwrap:

let name = (case .foo(!) = bar)


Even better would be a way of unwrapping multiple values of the same type:

enum Bar {
  case foo(name: String)
  case goo(kind: GooKind, name: String)

  var name: String {
return case .foo(!), .goo(_, !) = bar
  }
}


> On 10 May 2016, at 9:33 PM, Sam Dods via swift-evolution 
>  wrote:
> 
> I propose that (case .Foo = bar) should be treated as an expression with a 
> Boolean value, so the result can be set to a variable or returned from a 
> method.
> 
> Considering the following enumeration:
> 
> enum Bar {
>   case foo(name: String)
>   case notFoo
>   case unknownFoo
> }
> 
> Instead of having to do the following:
> 
> func isBarFoo(bar: Bar) -> Bool {
> if case .Foo = bar {
> return true
> }
> return false
> }
> 
> We could simply do the following:
> 
> func isBarFoo(bar: Bar) -> Bool {
> return (case .Foo = bar)
> }
> 
> We could also do things like this:
> 
> let isBarFoo = (case .Foo = bar)
> XCTAssert(isBarFoo)
> 
> Of course, this change is only required for enumerations that don't have a 
> raw value type (String, Int, etc).
> 
> It assumes the developer does not care what the associated value is, which 
> could lead to issues. But this is already the case with the `if case ... 
> return true/false` syntax. So it is not a degrading feature, just a more 
> concise syntax for something that already exists.
> 
> Something to consider is whether `case let ...` could be treated as an 
> expression in the same way. For example:
> 
> if (case let .Foo(name) = bar) && name == "Alan" {
>   return true
> }
> return false
> 
> The above could be simplified to:
> 
> return (case let .Foo(name) = bar) && name == "Alan"
> 
> Due to the way AND-ed expression results are computed at runtime, the second 
> expression would not be computed unless the first was true, so `name` must 
> have a value. The compiler would know that when OR-ing expressions, the 
> second expression is only computed if the first expression was false, so 
> `name` definitely doesn't have a value:
> 
> return (case let .Foo(name) = bar) || name == "Alan"
> 
> I would expect a compiler error similar to `Variable declared in 'guard' 
> condition is not usable in its body`.
> 
> What does everyone think of this? It would have no impact on existing code. 
> 
> 
> alternative, not proposing...
> 
> An alternative would be defaulting what equality means for enumerations, such 
> that the `==` operator is automatically defined for enumerations in the 
> following way:
> 
> func ==(lhs: Bar, rhs: Bar) -> Bool {
> if case rhs = lhs {
> return true
> }
> return false
> }
> 
> However, I think that having a default implementation for enum is a bad idea, 
> because it's adding default behaviour that the developer might not know 
> about. And this could lead to a less experienced developer making a mistake 
> when comparing two enum values with associated values. Developers that know 
> the `if case ...` syntax are already expected to understand that they are 
> ignoring the associated value and they can use `if case let ...` if they care 
> about the associated value. So my proposal is in-line with an existing 
> expectation.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [RFC] #Self

[Patrick Smith via swift-evolution]

Is there an example of a before / after? Thanks.

> On 10 May 2016, at 11:15 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> To focus SE-0068 and narrow its scope, I removed the `#Self` part of the 
> proposal. This offered compile-time substitution of the defining type for a 
> related #Self literal:
> 
> A further static identifier, #Self expands to static type of the code it 
> appears within, completing the ways code may want to refer to the type it is 
> declared in. 
> 
> #Self expands to the static type of the code it is declared within. In value 
> types, this is always the same as Self. In reference types, it refers to the 
> declaring type. #Self will offer a literal textual replacement just like 
> #file, etc.
> 
> At Chris's suggestion, I'm starting a new SE thread to see whether there 
> remains any interest for including #Self in the language. I'm personally 
> happy with the SE-0068 outcome but I didn't want to undercut anyone like 
> Timothy Wood who had originally spoken up for its inclusion.
> 
> -- E
> 
> ___
> 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-0085: Package Manager Command Names

[Patrick Smith via swift-evolution]

* What is your evaluation of the proposal?
These sound great! +1. Subcommands, even nested ones like `swift package init`, 
are more solid and easier to remember.

* Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes, I think establishing a clear system is important.

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

* 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 `npm`, which has similar subcommands and shortcut methods.

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


> On 10 May 2016, at 8:05 AM, Daniel Dunbar via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0085: Package Manager Command Names" begins now and runs 
> through May 12. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0085-package-manager-command-name.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.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> - Daniel
> 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

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

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

[Patrick Smith via swift-evolution]

I like the idea of the of the bounded subscript, however the optional one I 
feel could be used for clumsy code.

.first and .last have value, but once you start stepping several arbitrary 
indices in, then that code is likely fragile?


I can think of ‘within’, ‘inside’ and ‘intersecting’ as alternative names for 
‘bounded’ that attempt to explain what is going on:

let a = [1, 2, 3]

a[within: 0 ..< 5] // [1, 2, 3]
a[inside: 0 ..< 5] // [1, 2, 3]
a[intersecting: 0 ..< 5] // [1, 2, 3]


> On 28 Apr 2016, at 10:11 PM, Luis Henrique B. Sousa via swift-evolution 
>  wrote:
> 
> As we have discussed throughout this thread, the initial proposal was 
> modified to include alternative subscript methods instead of modifying the 
> default operator/subscript behaviour. 
> The first draft is here: 
> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md
>  
> 
> 
> I've also put this as a gist so that you can leave comments with respect to 
> the proposal document itself. Any suggestion or help is very welcome.
> https://gist.github.com/luish/832c34ee913159f130d97a914810dbd8 
> 
> 
> Regards,
> 
> - Luis
> 
> On Mon, Apr 11, 2016 at 1:23 PM, Luis Henrique B. Sousa  > wrote:
> This proposal seeks to provide a safer ..< (aka half-open range operator) in 
> order to avoid **Array index out of range** errors in execution time.
> 
> Here is my first draft for this proposal: 
> https://github.com/luish/swift-evolution/blob/half-open-range-operator/proposals/-safer-half-open-range-operator.md
>  
> 
> 
> In short, doing that in Swift causes a runtime error:
> let a = [1,2,3]
> let b = a[0..<5]
> print(b)
> 
> > Error running code: 
> > fatal error: Array index out of range
> 
> The proposed solution is to slice the array returning all elements that are 
> below the half-open operator, even though the number of elements is lesser 
> than the ending of the half-open operator. So the example above would return 
> [1,2,3]. 
> We can see this very behaviour in other languages, such as Python and Ruby as 
> shown in the proposal draft.
> 
> This would eliminate the need for verifications on the array size before 
> slicing it -- and consequently runtime errors in cases when the programmer 
> didn't. 
> 
> Viewing that it is my very first proposal, any feedback will be helpful.
> 
> Thanks!
> 
> Luis Henrique Borges
> @luishborges
> 
> ___
> 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] Dropping NS Prefix in Foundation

[Patrick Smith via swift-evolution]

But if the NS- prefix is removed now, then it will make it more painful to have 
breaking changes down the road. I’d prefer to see breaking changes happen and 
the introduction of new completely modern APIs. Even just protocols that the 
NS- Foundation can implement.

Say for example, a FileReferenceProtocol and a URLProtocol, where NSURL could 
conform to both, but a modern implementation could have two separate concrete 
struct types. Maybe that’s not feasible.

It’s just a shame to say ‘goodbye Objective-C, hello Swift clean slate’, and 
then bring Foundation along for the ride as a core part for writing new modern 
applications.

It would be great in my mind to have a plan to transition to a modern 
‘Foundation 2.0’. Say made using Swift 4.0 and its possible concurrency 
operators. I think that would be the time to drop the NS- prefixes.

> On 9 May 2016, at 3:09 AM, Michael Sheaver via swift-evolution 
>  wrote:
> 
> Foundation is indeed tightly coupled with the Apple ecosystem; however with 
> the movement to open source, I think we are approaching a fork in the 
> road regarding this discussion. Like David articulated, Foundation either 
> will need to her decoupled from its Apple historical roots or a parallel 
> non-Apple Foundation will need to be developed. We all know how difficult and 
> painful it is to maintain two different code sets that do mostly the same 
> thing. My humble recommendation is that we start looking at decoupling 
> foundation from its roots and a good first step would be to remove the NS- 
> prefix. This change would do many positive things, including alerting 
> developers that change is coming.
> 
> A long-term concern that I have is that if you do not begin the enormous task 
> of at least beginning to remove Apple-centric dependencies, then sometime 
> down the road someone outside the Apple environment will fork Swift and take 
> it in ways out of our control.
> 
> In short, I am in favor of at least beginning the move toward removing NS- 
> from Foundation.
> 
>> On May 8, 2016, at 11:16 AM, Josh Parmenter via swift-evolution 
>> > wrote:
>> 
>> David has articulated what I couldn't quite put my finger on, and I agree.
>> This also comes around to something I probably missed elsewhere in the 
>> discussion- but is the proposal to make NS classes just look like thus don't 
>> have NS in Swift? Or is it to write Swift versions of those classes that 
>> duplicate the functionality of those classes in Swift (for instance, giving 
>> String the full interface of NSString without actually having it call into 
>> NSString obj-c code?).
>> I tried glancing through the discussion and couldn't really find an answer 
>> to this (though I did it quickly, so my apologies if this is an obvious 
>> question that has already been answered).
>> Best
>> Josh
>> 
>> Sent from my iPhone
>> 
>> On May 8, 2016, at 00:41, David Waite via swift-evolution 
>> > > >> wrote:
>> 
>> It's not a goal to rewrite Foundation from scratch in Swift. All Swift apps 
>> that are running out there today are in fact using a combination of Swift, 
>> Objective-C, C, C++, various flavors of assembly, and more. The goal is to 
>> present the existing API of Foundation in a way that fits in with the 
>> language today while allowing us to iteratively improve it over time.
>> 
>> Perhaps my concern is a higher level - I don't understand where Foundation 
>> is envisioned going.
>> 
>> From my perspective, Foundation is highly coupled to Apple platforms and 
>> Objective-C on one side, and part of the Swift standard library on the 
>> other. Perhaps long-term Foundation should be split into two new things - a 
>> core library for cross-platform swift development, and the infrastructure 
>> for Objective-C interoperability on apple platforms only.
>> 
>> -DW
>> ___
>> 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