Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Haravikk via swift-evolution]

> On 17 Aug 2017, at 00:06, Robert Bennett via swift-evolution 
>  wrote:
> 
> How do unstable hash values play with Codable? If you encode and save a Set, 
> might you have problems interacting with it in the future? (This is more a 
> Codable question than Hashable, but I figure I might as well ask here) 

I'm not big on the specifics of Codable, but collections are usually a case 
where you need to be careful about how exactly you encode them; i.e- you 
usually only want to encode the length and the contents, not anything related 
to the way in which they are actually stored. This way it doesn't matter if the 
hashes change, as you recreate the Set like you're adding all the values for 
the first time; any collisions should then be resolved as normal (i.e- 
assigning into buckets of non-identical items with the same hash). Nothing in a 
Set should ever be overwritten on the basis of its hash alone. Otherwise, any 
code that requires a more stable hash value should be using something other 
than Hashable to generate it.

> On 16 Aug 2017, at 23:29, Chris Lattner via swift-evolution 
>  wrote:
> 

> The code synthesized is meant to feel like a default implementation that 
> you’re getting for free from a (constrained) extension on the protocol.  This 
> is why conformance to the protocol itself is all that is required, not 
> something like “AutoEquatable”.  


I still strongly feel that treating this like a default implementation is a 
mistake, especially in the case of Equatable; we are literally talking here 
about a feature that introduces the potential to hide bugs, and it is not the 
same as a default implementation, not at all as it uses details of the concrete 
type, rather than merely what is defined within the protocol itself, you are 
talking here about using parts of a type that are not clearly defined, to 
create an implementation that by its very nature must give accurate results.

I mean, the whole point of a protocol is to define what we as developers need 
to do in order to ensure correct behaviour; when we start talking about 
providing that behaviour automatically with behind the scenes magic that 
necessarily has to make assumptions about a type then you lose any ability to 
guarantee correctness. I feel so strongly that this is a mistake that I would 
rather never see this feature implemented than see it implemented in this way, 
and feel that this concern has been trivialised and ignored.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Improve `init(repeating:count)`

[Adrian Zubarev via swift-evolution]

This is a small pitch which I will abandon if there is not much appetite for 
such improvement. ;)

I would like to propose an improvement to an initializer of all collection 
types that provide: init(repeating repeatedValue: Element, count: Int).

This change is meant to support reference type initialization on each iteration 
of the internal for-loop rather than copying the same references n times.

The change would be really straightforward and should not break existing code, 
except that the behavior would change for class types.

Instead of:

init(repeating repeatedValue: Element, count: Int)

let threeViews = Array(repeating: UIView(), count: 3) // contains 1 view 3 times
we would have:

init(repeating repeatedValue: @autoclosure () -> Element, count: Int)

This simple change would allow us to construct an array of different objects 
instead of an array with n references to the same object.

let threeViews = Array(repeating: UIView(), count: 3) // contains 3 different 
views


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

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Jonathan Hull via swift-evolution]

+1

> On Aug 17, 2017, at 2:38 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> This is a small pitch which I will abandon if there is not much appetite for 
> such improvement. ;)
> 
> I would like to propose an improvement to an initializer of all collection 
> types that provide: init(repeating repeatedValue: Element, count: Int).
> 
> This change is meant to support reference type initialization on each 
> iteration of the internal for-loop rather than copying the same references n 
> times.
> 
> The change would be really straightforward and should not break existing 
> code, except that the behavior would change for class types.
> 
> Instead of:
> 
> init(repeating repeatedValue: Element, count: Int)
> 
> let threeViews = Array(repeating: UIView(), count: 3) // contains 1 view 3 
> times
> we would have:
> 
> init(repeating repeatedValue: @autoclosure () -> Element, count: Int)
> 
> This simple change would allow us to construct an array of different objects 
> instead of an array with n references to the same object.
> 
> let threeViews = Array(repeating: UIView(), count: 3) // contains 3 different 
> views
> 
> 
> 
> 
> ___
> 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-0185 - Synthesizing Equatable and Hashable conformance

[Robert Bennett via swift-evolution]

Chris mentions that the intent was to mimic a default implementation in a 
constrained protocol extension, with one extension per type that doesn’t define 
its own ==/hashValue while conforming to Equatable/Hashable. Constrained 
extensions are allowed to use type information from the constraint, so I don’t 
think there is an issue here.

> On Aug 17, 2017, at 4:12 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 17 Aug 2017, at 00:06, Robert Bennett via swift-evolution 
>>  wrote:
>> 
>> How do unstable hash values play with Codable? If you encode and save a Set, 
>> might you have problems interacting with it in the future? (This is more a 
>> Codable question than Hashable, but I figure I might as well ask here) 
> 
> I'm not big on the specifics of Codable, but collections are usually a case 
> where you need to be careful about how exactly you encode them; i.e- you 
> usually only want to encode the length and the contents, not anything related 
> to the way in which they are actually stored. This way it doesn't matter if 
> the hashes change, as you recreate the Set like you're adding all the values 
> for the first time; any collisions should then be resolved as normal (i.e- 
> assigning into buckets of non-identical items with the same hash). Nothing in 
> a Set should ever be overwritten on the basis of its hash alone. Otherwise, 
> any code that requires a more stable hash value should be using something 
> other than Hashable to generate it.
> 
>> On 16 Aug 2017, at 23:29, Chris Lattner via swift-evolution 
>>  wrote:
>> 
> 
>> The code synthesized is meant to feel like a default implementation that 
>> you’re getting for free from a (constrained) extension on the protocol.  
>> This is why conformance to the protocol itself is all that is required, not 
>> something like “AutoEquatable”.  
> 
> 
> I still strongly feel that treating this like a default implementation is a 
> mistake, especially in the case of Equatable; we are literally talking here 
> about a feature that introduces the potential to hide bugs, and it is not the 
> same as a default implementation, not at all as it uses details of the 
> concrete type, rather than merely what is defined within the protocol itself, 
> you are talking here about using parts of a type that are not clearly 
> defined, to create an implementation that by its very nature must give 
> accurate results.
> 
> I mean, the whole point of a protocol is to define what we as developers need 
> to do in order to ensure correct behaviour; when we start talking about 
> providing that behaviour automatically with behind the scenes magic that 
> necessarily has to make assumptions about a type then you lose any ability to 
> guarantee correctness. I feel so strongly that this is a mistake that I would 
> rather never see this feature implemented than see it implemented in this 
> way, and feel that this concern has been trivialised and ignored.
> ___
> 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] Improve `init(repeating:count)`

[Xiaodi Wu via swift-evolution]

This would be very source-breaking, no?
On Thu, Aug 17, 2017 at 04:47 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> +1
>
> On Aug 17, 2017, at 2:38 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is a small pitch which I will abandon if there is not much appetite
> for such improvement. ;)
>
> I would like to propose an improvement to an initializer of all collection
> types that provide: init(repeating repeatedValue: Element, count: Int).
>
> This change is meant to support reference type initialization on each
> iteration of the internal for-loop rather than copying the same references
> n times.
>
> The change would be really straightforward and should not break existing
> code, except that the behavior would change for class types.
>
> Instead of:
>
> init(repeating repeatedValue: Element, count: Int)
>
> let threeViews = Array(repeating: UIView(), count: 3) // contains 1 view 3 
> times
>
> we would have:
>
> init(repeating repeatedValue: @autoclosure () -> Element, count: Int)
>
> This simple change would allow us to construct an array of different
> objects instead of an array with n references to the same object.
>
> let threeViews = Array(repeating: UIView(), count: 3) // contains 3 different 
> views
>
>
>
>
>
> ___
> 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] [Pitch] Improve `init(repeating:count)`

[Adrian Zubarev via swift-evolution]

In terms of functionality yes potentially a breaking change, because the 
behavior would change for objects that were initialized through the passed 
expression.

Personally it always bugged me that it does not work for objects and forced map 
usage over a range to create an array of different objects.
However, this change feels like a fix to the intended behavior, but yes it 
might be very source breaking.


Yet again it’s up to the community to decide if we need this or not. ;)


Am 17. August 2017 um 12:59:06, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

This would be very source-breaking, no?
On Thu, Aug 17, 2017 at 04:47 Jonathan Hull via swift-evolution 
 wrote:
+1

On Aug 17, 2017, at 2:38 AM, Adrian Zubarev via swift-evolution 
 wrote:

This is a small pitch which I will abandon if there is not much appetite for 
such improvement. ;)

I would like to propose an improvement to an initializer of all collection 
types that provide: init(repeating repeatedValue: Element, count: Int).

This change is meant to support reference type initialization on each iteration 
of the internal for-loop rather than copying the same references n times.

The change would be really straightforward and should not break existing code, 
except that the behavior would change for class types.

Instead of:

init(repeating repeatedValue: Element, count: Int)

let threeViews = Array(repeating: UIView(), count: 3) // contains 1 view 3 times
we would have:

init(repeating repeatedValue: @autoclosure () -> Element, count: Int)

This simple change would allow us to construct an array of different objects 
instead of an array with n references to the same object.

let threeViews = Array(repeating: UIView(), count: 3) // contains 3 different 
views




___
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] [Pitch] Improve `init(repeating:count)`

[Haravikk via swift-evolution]

> On 17 Aug 2017, at 10:38, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> This is a small pitch which I will abandon if there is not much appetite for 
> such improvement. ;)
> 
> I would like to propose an improvement to an initializer of all collection 
> types that provide: init(repeating repeatedValue: Element, count: Int).
> 
> This change is meant to support reference type initialization on each 
> iteration of the internal for-loop rather than copying the same references n 
> times.
> 
> The change would be really straightforward and should not break existing 
> code, except that the behavior would change for class types.
> 
> Instead of:
> 
> init(repeating repeatedValue: Element, count: Int)
> 
> let threeViews = Array(repeating: UIView(), count: 3) // contains 1 view 3 
> times
> we would have:
> 
> init(repeating repeatedValue: @autoclosure () -> Element, count: Int)
> 
> This simple change would allow us to construct an array of different objects 
> instead of an array with n references to the same object.
> 
> let threeViews = Array(repeating: UIView(), count: 3) // contains 3 different 
> view
I don't think that changing the existing initialiser is the way to do this, as 
it's not really clear here that the UIView() will be instantiated multiple 
times rather than the same reference copied multiple times. The copying 
behaviour is in fact desirable as it will be significantly faster, especially 
with very large arrays.

I think the better way to achieve this might be add some closure-based sequence 
that returns a closure's result N times, so we could do something like this:

let threeViews = Array(Repeat(count: 3) { return UIView() })

i.e- we would initialise Array from a sequence returning a new UIView three 
times. While we could also do an array initialiser with closure, using a 
separate type is probably the cleaner way to do this.

There is already a Repeater type, but this just does the same as the array 
initialiser already does, could be another type I've missed that might do what 
is needed, otherwise it seems to require types like AnyIterator with some 
counting code.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Haravikk via swift-evolution]

> On 17 Aug 2017, at 11:42, Robert Bennett  wrote:
> 
> Chris mentions that the intent was to mimic a default implementation in a 
> constrained protocol extension, with one extension per type that doesn’t 
> define its own ==/hashValue while conforming to Equatable/Hashable. 
> Constrained extensions are allowed to use type information from the 
> constraint, so I don’t think there is an issue here.

And I disagree; this isn't a constraint extension either, not even close, we're 
talking here about automatic behaviour based upon variables the protocol knows 
literally nothing about, in a way that can result in new errors that are 
currently impossible (as you can't currently conform to Equatable without 
providing some kind of code to implement it).

It is no more comparable to a constrained extension than it is to a default 
implementation, as it is neither of these things; both of those are well 
defined by their very nature, this instead is utterly arbitrary. There is no 
justification that will make that any less true.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Robert Bennett via swift-evolution]

Alternatively, instead of replacing the current definition with an autoclosure 
version, we could leave the current version in place and add a version taking a 
function. This could be especially useful when you’ve defined a function like 
`makeMySpecialKindOfButton() -> UIButton` that does a lot of customization to 
an object before returning it.

Array(repeating: { return UIView() }, count: 3)
and
Array(repeating: makeMySpecialKindOfButton, count: 3)

> On Aug 17, 2017, at 7:54 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 17 Aug 2017, at 10:38, Adrian Zubarev via swift-evolution 
>>  wrote:
>> 
>> This is a small pitch which I will abandon if there is not much appetite for 
>> such improvement. ;)
>> 
>> I would like to propose an improvement to an initializer of all collection 
>> types that provide: init(repeating repeatedValue: Element, count: Int).
>> 
>> This change is meant to support reference type initialization on each 
>> iteration of the internal for-loop rather than copying the same references n 
>> times.
>> 
>> The change would be really straightforward and should not break existing 
>> code, except that the behavior would change for class types.
>> 
>> Instead of:
>> 
>> init(repeating repeatedValue: Element, count: Int)
>> 
>> let threeViews = Array(repeating: UIView(), count: 3) // contains 1 view 3 
>> times
>> we would have:
>> 
>> init(repeating repeatedValue: @autoclosure () -> Element, count: Int)
>> 
>> This simple change would allow us to construct an array of different objects 
>> instead of an array with n references to the same object.
>> 
>> let threeViews = Array(repeating: UIView(), count: 3) // contains 3 
>> different view
> I don't think that changing the existing initialiser is the way to do this, 
> as it's not really clear here that the UIView() will be instantiated multiple 
> times rather than the same reference copied multiple times. The copying 
> behaviour is in fact desirable as it will be significantly faster, especially 
> with very large arrays.
> 
> I think the better way to achieve this might be add some closure-based 
> sequence that returns a closure's result N times, so we could do something 
> like this:
> 
>   let threeViews = Array(Repeat(count: 3) { return UIView() })
> 
> i.e- we would initialise Array from a sequence returning a new UIView three 
> times. While we could also do an array initialiser with closure, using a 
> separate type is probably the cleaner way to do this.
> 
> There is already a Repeater type, but this just does the same as the array 
> initialiser already does, could be another type I've missed that might do 
> what is needed, otherwise it seems to require types like AnyIterator with 
> some counting code.
> ___
> 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] Improve `init(repeating:count)`

[Rintaro Ishizaki via swift-evolution]

I don't think it's worthwhile adding new API.
I think this is simple enough:

let views = Array(AnyIterator(UIView.init).prefix(3))

2017-08-17 21:04 GMT+09:00 Robert Bennett via swift-evolution <
swift-evolution@swift.org>:

> Alternatively, instead of replacing the current definition with an
> autoclosure version, we could leave the current version in place and add a
> version taking a function. This could be especially useful when you’ve
> defined a function like `makeMySpecialKindOfButton() -> UIButton` that does
> a lot of customization to an object before returning it.
>
> Array(repeating: { return UIView() }, count: 3)
> and
> Array(repeating: makeMySpecialKindOfButton, count: 3)
>
> On Aug 17, 2017, at 7:54 AM, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 17 Aug 2017, at 10:38, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is a small pitch which I will abandon if there is not much appetite
> for such improvement. ;)
>
> I would like to propose an improvement to an initializer of all collection
> types that provide: init(repeating repeatedValue: Element, count: Int).
>
> This change is meant to support reference type initialization on each
> iteration of the internal for-loop rather than copying the same references
> n times.
>
> The change would be really straightforward and should not break existing
> code, except that the behavior would change for class types.
>
> Instead of:
>
> init(repeating repeatedValue: Element, count: Int)
>
> let threeViews = Array(repeating: UIView(), count: 3) // contains 1 view 3 
> times
>
> we would have:
>
> init(repeating repeatedValue: @autoclosure () -> Element, count: Int)
>
> This simple change would allow us to construct an array of different
> objects instead of an array with n references to the same object.
>
> let threeViews = Array(repeating: UIView(), count: 3) // contains 3 different 
> view
>
> I don't think that changing the existing initialiser is the way to do
> this, as it's not really clear here that the UIView() will be instantiated
> multiple times rather than the same reference copied multiple times. The
> copying behaviour is in fact desirable as it will be significantly faster,
> especially with very large arrays.
>
> I think the better way to achieve this might be add some closure-based
> sequence that returns a closure's result N times, so we could do something
> like this:
>
> let threeViews = Array(Repeat(count: 3) { return UIView() })
>
> i.e- we would initialise Array from a sequence returning a new UIView
> three times. While we could also do an array initialiser with closure,
> using a separate type is probably the cleaner way to do this.
>
> There is already a Repeater type, but this just does the same as the array
> initialiser already does, could be another type I've missed that might do
> what is needed, otherwise it seems to require types like AnyIterator with
> some counting code.
>
> ___
> 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] [Pitch] Improve `init(repeating:count)`

[Rob Mayoff via swift-evolution]

On Thu, Aug 17, 2017 at 7:04 AM, Robert Bennett via swift-evolution <
swift-evolution@swift.org> wrote:

> Alternatively, instead of replacing the current definition with an
> autoclosure version, we could leave the current version in place and add a
> version taking a function. This could be especially useful when you’ve
> defined a function like `makeMySpecialKindOfButton() -> UIButton` that does
> a lot of customization to an object before returning it.
>
> Array(repeating: { return UIView() }, count: 3)
> and
> Array(repeating: makeMySpecialKindOfButton, count: 3)
>

This is still source-breaking, because an array of closures is legal. We
need a different name to avoid breaking source:

Array(repeatedlyCalling: { UIView() }, count: 3)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Robert Bennett via swift-evolution]

Good catch. I think this functionality is worth adding. Seems like it could be 
useful for e.g., a grid of buttons.

> On Aug 17, 2017, at 11:25 AM, Rob Mayoff via swift-evolution 
>  wrote:
> 
>> On Thu, Aug 17, 2017 at 7:04 AM, Robert Bennett via swift-evolution 
>>  wrote:
>> Alternatively, instead of replacing the current definition with an 
>> autoclosure version, we could leave the current version in place and add a 
>> version taking a function. This could be especially useful when you’ve 
>> defined a function like `makeMySpecialKindOfButton() -> UIButton` that does 
>> a lot of customization to an object before returning it.
>> 
>> Array(repeating: { return UIView() }, count: 3)
>> and
>> Array(repeating: makeMySpecialKindOfButton, count: 3)
> 
> This is still source-breaking, because an array of closures is legal. We need 
> a different name to avoid breaking source:
> 
> Array(repeatedlyCalling: { UIView() }, count: 3)
>  
> ___
> 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] Improve `init(repeating:count)`

[Christopher Kornher via swift-evolution]

We might as well add the index to the call so elements can be created from 
other lists, etc.

 Array(repeatedlyCalling: { (index:Int) in MyView( forIndex:index ) }, count: 
3) // This might by syntactically correct...



> On Aug 17, 2017, at 9:24 AM, Rob Mayoff via swift-evolution 
>  wrote:
> 
> On Thu, Aug 17, 2017 at 7:04 AM, Robert Bennett via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Alternatively, instead of replacing the current definition with an 
> autoclosure version, we could leave the current version in place and add a 
> version taking a function. This could be especially useful when you’ve 
> defined a function like `makeMySpecialKindOfButton() -> UIButton` that does a 
> lot of customization to an object before returning it.
> 
> Array(repeating: { return UIView() }, count: 3)
> and
> Array(repeating: makeMySpecialKindOfButton, count: 3)
> 
> This is still source-breaking, because an array of closures is legal. We need 
> a different name to avoid breaking source:
> 
> Array(repeatedlyCalling: { UIView() }, count: 3)
>  
> ___
> 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] Improve `init(repeating:count)`

[Jonathan Hull via swift-evolution]

The closure should go on the end though…

> On Aug 17, 2017, at 8:40 AM, Christopher Kornher via swift-evolution 
>  wrote:
> 
> We might as well add the index to the call so elements can be created from 
> other lists, etc.
> 
>  Array(repeatedlyCalling: { (index:Int) in MyView( forIndex:index ) }, count: 
> 3) // This might by syntactically correct...
> 
> 
> 
>> On Aug 17, 2017, at 9:24 AM, Rob Mayoff via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> On Thu, Aug 17, 2017 at 7:04 AM, Robert Bennett via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Alternatively, instead of replacing the current definition with an 
>> autoclosure version, we could leave the current version in place and add a 
>> version taking a function. This could be especially useful when you’ve 
>> defined a function like `makeMySpecialKindOfButton() -> UIButton` that does 
>> a lot of customization to an object before returning it.
>> 
>> Array(repeating: { return UIView() }, count: 3)
>> and
>> Array(repeating: makeMySpecialKindOfButton, count: 3)
>> 
>> This is still source-breaking, because an array of closures is legal. We 
>> need a different name to avoid breaking source:
>> 
>> Array(repeatedlyCalling: { UIView() }, count: 3)
>>  
>> ___
>> 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] [Pitch] Improve `init(repeating:count)`

[Tony Allevato via swift-evolution]

Couldn't this be rewritten more simply today as:

Array((0..<3).map { index in MyView(forIndex: index) })

And the version that doesn't need the index could be written:

Array((0..<3).map { _ in UIView() })

The AnyIterator approach posted above is also nice—I wouldn't have thought
of that one. But I suppose that only works in the case where you don't need
the index.

So the question is, should we increase the API surface of Array for
something that (IMO) is already fairly straightforward to do? The nice
thing about the approaches above is that they're composable. Array doesn't
have to make any assumptions about closures or index arguments to those
closures; it just takes a sequence and we already have primitives to
construct sequences of new objects using .map. Array(repeating:count:) and
repeatedElement(_:count:) are nice when the value being repeated is fixed,
but I think once you start getting into questions like "what if I need a
different thing each time?" or "what if I need to involve the index as part
of the elements?" then it's better suited to compose the features already
there to build something up than to add new APIs that try to cover each of
these special cases.


On Thu, Aug 17, 2017 at 8:40 AM Christopher Kornher via swift-evolution <
swift-evolution@swift.org> wrote:

> We might as well add the index to the call so elements can be created from
> other lists, etc.
>
>  Array(repeatedlyCalling: { (index:Int) in MyView( forIndex:index ) },
> count: 3) // This might by syntactically correct...
>
>
>
> On Aug 17, 2017, at 9:24 AM, Rob Mayoff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Thu, Aug 17, 2017 at 7:04 AM, Robert Bennett via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Alternatively, instead of replacing the current definition with an
>> autoclosure version, we could leave the current version in place and add a
>> version taking a function. This could be especially useful when you’ve
>> defined a function like `makeMySpecialKindOfButton() -> UIButton` that does
>> a lot of customization to an object before returning it.
>>
>> Array(repeating: { return UIView() }, count: 3)
>> and
>> Array(repeating: makeMySpecialKindOfButton, count: 3)
>>
>
> This is still source-breaking, because an array of closures is legal. We
> need a different name to avoid breaking source:
>
> Array(repeatedlyCalling: { UIView() }, count: 3)
>
> ___
> 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] [Pitch] Improve `init(repeating:count)`

[Ross O'Brien via swift-evolution]

(0..<3).map{ _ in UIView() } - map already returns an Array.

Array((0..<3).map{ _ in UIView() }) is redundant.

I've fallen foul before, of trying to create an array of six buttons and
getting an array of one button six times; I think that should be easier.
But if each button corresponds to an existing value or needs to be
initialised based on its index in that array, map transposing values or
indices into buttons is already covered.

On Thu, Aug 17, 2017 at 5:03 PM, Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:

> Couldn't this be rewritten more simply today as:
>
> Array((0..<3).map { index in MyView(forIndex: index) })
>
> And the version that doesn't need the index could be written:
>
> Array((0..<3).map { _ in UIView() })
>
> The AnyIterator approach posted above is also nice—I wouldn't have thought
> of that one. But I suppose that only works in the case where you don't need
> the index.
>
> So the question is, should we increase the API surface of Array for
> something that (IMO) is already fairly straightforward to do? The nice
> thing about the approaches above is that they're composable. Array doesn't
> have to make any assumptions about closures or index arguments to those
> closures; it just takes a sequence and we already have primitives to
> construct sequences of new objects using .map. Array(repeating:count:) and
> repeatedElement(_:count:) are nice when the value being repeated is fixed,
> but I think once you start getting into questions like "what if I need a
> different thing each time?" or "what if I need to involve the index as part
> of the elements?" then it's better suited to compose the features already
> there to build something up than to add new APIs that try to cover each of
> these special cases.
>
>
> On Thu, Aug 17, 2017 at 8:40 AM Christopher Kornher via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> We might as well add the index to the call so elements can be created
>> from other lists, etc.
>>
>>  Array(repeatedlyCalling: { (index:Int) in MyView( forIndex:index ) },
>> count: 3) // This might by syntactically correct...
>>
>>
>>
>> On Aug 17, 2017, at 9:24 AM, Rob Mayoff via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Thu, Aug 17, 2017 at 7:04 AM, Robert Bennett via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Alternatively, instead of replacing the current definition with an
>>> autoclosure version, we could leave the current version in place and add a
>>> version taking a function. This could be especially useful when you’ve
>>> defined a function like `makeMySpecialKindOfButton() -> UIButton` that does
>>> a lot of customization to an object before returning it.
>>>
>>> Array(repeating: { return UIView() }, count: 3)
>>> and
>>> Array(repeating: makeMySpecialKindOfButton, count: 3)
>>>
>>
>> This is still source-breaking, because an array of closures is legal. We
>> need a different name to avoid breaking source:
>>
>> Array(repeatedlyCalling: { UIView() }, count: 3)
>>
>> ___
>> 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

[swift-evolution] pitch: Unified libc import (again)

[Taylor Swift via swift-evolution]

I know this has come up before without any action, but having the standard
C library be packaged under `Darwin` on OSX and `Glibc` under Linux is
something that’s really becoming an issue as the Swift package ecosystem
matures. Right now a lot of packages are a lot less portable than they
could be because somewhere along the dependency line, there is a package
that only imports the C library for one platform. Unifying it under one
import would allow people to write packages that are portable by default.

Since I think this got hung up in the past over “what constitutes” a
universal libc, I propose a unified package should just consist of the
functionality that is common between Darwin and Glibc right now, since
those are the only two supported platforms anyway.

Alternatively, Swift could make it a priority to get basic functionality
like file IO and math functions shipped with the compiler, which would
probably cover 98% of cases where people currently import Darwin/Glibc. A
large portion of the standard C libraries are redundant to the Swift
standard library anyway.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Tony Allevato via swift-evolution]

On Thu, Aug 17, 2017 at 9:20 AM Ross O'Brien 
wrote:

> (0..<3).map{ _ in UIView() } - map already returns an Array.
>
> Array((0..<3).map{ _ in UIView() }) is redundant.
>

Ah, right, thanks for pointing that out. I couldn't remember off the top of
my head whether it returned an array or some kind of special sequence type
that would need to be converted over.

In that case, I still think the map version wins—it's very clear that a
repeated *operation* is occurring, whereas the originally proposed
@autoclosure version hides that very important semantic information.


I've fallen foul before, of trying to create an array of six buttons and
> getting an array of one button six times; I think that should be easier.
> But if each button corresponds to an existing value or needs to be
> initialised based on its index in that array, map transposing values or
> indices into buttons is already covered.
>
> On Thu, Aug 17, 2017 at 5:03 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Couldn't this be rewritten more simply today as:
>>
>> Array((0..<3).map { index in MyView(forIndex: index) })
>>
>> And the version that doesn't need the index could be written:
>>
>> Array((0..<3).map { _ in UIView() })
>>
>> The AnyIterator approach posted above is also nice—I wouldn't have
>> thought of that one. But I suppose that only works in the case where you
>> don't need the index.
>>
>> So the question is, should we increase the API surface of Array for
>> something that (IMO) is already fairly straightforward to do? The nice
>> thing about the approaches above is that they're composable. Array doesn't
>> have to make any assumptions about closures or index arguments to those
>> closures; it just takes a sequence and we already have primitives to
>> construct sequences of new objects using .map. Array(repeating:count:) and
>> repeatedElement(_:count:) are nice when the value being repeated is fixed,
>> but I think once you start getting into questions like "what if I need a
>> different thing each time?" or "what if I need to involve the index as part
>> of the elements?" then it's better suited to compose the features already
>> there to build something up than to add new APIs that try to cover each of
>> these special cases.
>>
>>
>> On Thu, Aug 17, 2017 at 8:40 AM Christopher Kornher via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> We might as well add the index to the call so elements can be created
>>> from other lists, etc.
>>>
>>>  Array(repeatedlyCalling: { (index:Int) in MyView( forIndex:index ) },
>>> count: 3) // This might by syntactically correct...
>>>
>>>
>>>
>>> On Aug 17, 2017, at 9:24 AM, Rob Mayoff via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> On Thu, Aug 17, 2017 at 7:04 AM, Robert Bennett via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Alternatively, instead of replacing the current definition with an
 autoclosure version, we could leave the current version in place and add a
 version taking a function. This could be especially useful when you’ve
 defined a function like `makeMySpecialKindOfButton() -> UIButton` that does
 a lot of customization to an object before returning it.

 Array(repeating: { return UIView() }, count: 3)
 and
 Array(repeating: makeMySpecialKindOfButton, count: 3)

>>>
>>> This is still source-breaking, because an array of closures is legal. We
>>> need a different name to avoid breaking source:
>>>
>>> Array(repeatedlyCalling: { UIView() }, count: 3)
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Chris Lattner via swift-evolution]

> On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 17 Aug 2017, at 11:42, Robert Bennett > > wrote:
>> 
>> Chris mentions that the intent was to mimic a default implementation in a 
>> constrained protocol extension, with one extension per type that doesn’t 
>> define its own ==/hashValue while conforming to Equatable/Hashable. 
>> Constrained extensions are allowed to use type information from the 
>> constraint, so I don’t think there is an issue here.
> 
> And I disagree; this isn't a constraint extension either, not even close, 
> we're talking here about automatic behaviour based upon variables the 
> protocol knows literally nothing about, in a way that can result in new 
> errors that are currently impossible (as you can't currently conform to 
> Equatable without providing some kind of code to implement it).

I understand and recognize your concern.  Your points are apply equally to the 
default implementation of the Codable protocols as well, and the core team 
specifically discussed this.

Also, if I were to nitpick your argument a bit, it isn’t true that the protocol 
knows “nothing" about the type anyway, because the protocol has access to self. 
 The default implementation could conceptually use reflection to access all the 
state in the type: we’re producing the same effect with more efficient code.

-Chris


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

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Erica Sadun via swift-evolution]

Also, for those of you here who haven't heard my previous rant on the subject, 
I dislike using map for generating values that don't depend on transforming a 
domain to a range. (It has been argued that `_ in` is mapping from `Void`, but 
I still dislike it immensely)

Here are the ways that I have approached this:

// Ugh
[UIView(), UIView(), UIView(), UIView(), UIView()]

// No:
let viewsA = Array(repeating: UIView(), count: 5) 
// You end up with 5 of the same view

// Two statements that really should be one
var views: [UIView] = []
for _ in 1 ... 5 { views.append(UIView()) }

// Wrong use of `map`,  because it's mapping over `Void`
let viewsA = (1 ... 5).map({ _ in UIView() }) 

// You can introduce `collect` specifically for the `_ in` in case, matching 
other languages:
public func collect(_ generator: () throws -> T) rethrows -> [T]

// I think these are just ugly
let viewsA__ = sequence(first: UIView(), next: { _ in UIView() }).lazy.prefix(5)
let viewsB__ = sequence(state: 5, next: { defer { $0 -= 1 }; $0 == 0 ? nil : 
UIView() }

// You can build an iterator

let labeler = AnyIterator({ return UILabel() })
let labels4 = Array(labeler.prefix(5))

// which lets you create multiple "slices" off the iterator

let randoms = AnyIterator({ return Int(arc4random_uniform(100) )})

print(Array(randoms.prefix(5)))
print(Array(randoms.prefix(5)))


// A little complex and I don't like making this `Int` based, because it pulls 
the semantics away from sequences/collections

extension Int {
func of(_ generator: @autoclosure () -> T) -> [T] {
assert(self >= 0, "cannot generate negative-count collection")
return (0 ..< self).map({ _ in generator() })
}
}

5.of(UIView())

// Even worse
protocol Constructable {
init()
}

extension UIView: Constructable {}

extension Int {
func of(_ generator: @autoclosure () -> T) -> 
UnfoldSequence {
assert(self > 0, "cannot generate negative-count collection")
return sequence(state: self, next: { (state: inout Int) -> T? in
defer { state -= 1 }; return state == 0 ? nil : T.init() })
}
}

print(Array(5.of(UIView(

// or

extension Int {
func of(_ generator: @escaping @autoclosure () -> T) -> 
LazyMapRandomAccessCollection<(CountableRange), T> {
assert(self > 0, "cannot generate negative-count collection")
return (0 ..< self).lazy.map({ _ in generator() })
}
}

// where some people preferred calling this `elements`, for example 
`5.elements(of: UIView())`

// You can go Array:

extension Array {
/// Creates a new array containing the specified number of values created 
by repeating a generating closure.
///
/// - Parameters:
///   - count: The number of times to apply the closure. `count` must be 
zero or greater.
///   - generator: The closure to execute
public init(count: Int, repeating: () -> Element) {
precondition(count >= 0, "")
self.init((1 ... count).map({ _ in repeating() }))
}
}

let labels = Array(count: 4) { UILabel() }

// Or similarly

extension Array {
init(repeat count: Int, byCalling generator: @autoclosure () -> Element) {
self = (1 ... count).map({ _ in generator() })
}
}

// From Oliver H:

extension Array {
  convenience init(count: Int, repeating: () -> Elements) {
self = Array( (0..(generator: @autoclosure () -> T, n: Int) -> [T] {
  (0.. On Aug 17, 2017, at 10:36 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> 
> 
> On Thu, Aug 17, 2017 at 9:20 AM Ross O'Brien  > wrote:
> (0..<3).map{ _ in UIView() } - map already returns an Array.
> 
> Array((0..<3).map{ _ in UIView() }) is redundant.
> 
> Ah, right, thanks for pointing that out. I couldn't remember off the top of 
> my head whether it returned an array or some kind of special sequence type 
> that would need to be converted over.
> 
> In that case, I still think the map version wins—it's very clear that a 
> repeated *operation* is occurring, whereas the originally proposed 
> @autoclosure version hides that very important semantic information.
> 
> 
> I've fallen foul before, of trying to create an array of six buttons and 
> getting an array of one button six times; I think that should be easier. But 
> if each button corresponds to an existing value or needs to be initialised 
> based on its index in that array, map transposing values or indices into 
> buttons is already covered.
> 
> On Thu, Aug 17, 2017 at 5:03 PM, Tony Allevato via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Couldn't this be rewritten more simply today as:
> 
> Array((0..<3).map { index in MyView(forIndex: index) })
> 
> And the version that doesn't need the index could be written:
> 
> Array((0..<3).map { _ in UIView() })
> 
> The AnyIterator approach posted above is also nice—I wouldn't have thought of 
> that one. But I suppose that only works in the case where you don't need the 
> index.
> 
> So the ques

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Max Moiseev via swift-evolution]

> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Also, for those of you here who haven't heard my previous rant on the 
> subject, I dislike using map for generating values that don't depend on 
> transforming a domain to a range. (It has been argued that `_ in` is mapping 
> from `Void`, but I still dislike it immensely)

Can you please elaborate why (or maybe point me at the rant)? Does the same 
argument apply to `for _ in 1.. [C] {
  var result: [C] = []
  result.reserveCapacity(n)
  for _ in 1...n {
result.append(C())
  }
  return result
}

@inline(never)
func bar(n: Int) -> [C] {
  return (1...n).map { _ in C() }
}

Version using map wins in both the size of sil and performance. It is also 
easier to implement right (fewer moving parts, I guess). If one forgets to call 
`reserveCapacity` on `result` in the first case, performance drops even further.

Max

> 
> Here are the ways that I have approached this:
> 
> // Ugh
> [UIView(), UIView(), UIView(), UIView(), UIView()]
> 
> // No:
> let viewsA = Array(repeating: UIView(), count: 5) 
> // You end up with 5 of the same view
> 
> // Two statements that really should be one
> var views: [UIView] = []
> for _ in 1 ... 5 { views.append(UIView()) }
> 
> // Wrong use of `map`,  because it's mapping over `Void`
> let viewsA = (1 ... 5).map({ _ in UIView() }) 
> 
> // You can introduce `collect` specifically for the `_ in` in case, matching 
> other languages:
> public func collect(_ generator: () throws -> T) rethrows -> [T]
> 
> // I think these are just ugly
> let viewsA__ = sequence(first: UIView(), next: { _ in UIView() 
> }).lazy.prefix(5)
> let viewsB__ = sequence(state: 5, next: { defer { $0 -= 1 }; $0 == 0 ? nil : 
> UIView() }
> 
> // You can build an iterator
> 
> let labeler = AnyIterator({ return UILabel() })
> let labels4 = Array(labeler.prefix(5))
> 
> // which lets you create multiple "slices" off the iterator
> 
> let randoms = AnyIterator({ return Int(arc4random_uniform(100) )})
> 
> print(Array(randoms.prefix(5)))
> print(Array(randoms.prefix(5)))
> 
> 
> // A little complex and I don't like making this `Int` based, because it 
> pulls the semantics away from sequences/collections
> 
> extension Int {
> func of(_ generator: @autoclosure () -> T) -> [T] {
> assert(self >= 0, "cannot generate negative-count collection")
> return (0 ..< self).map({ _ in generator() })
> }
> }
> 
> 5.of(UIView())
> 
> // Even worse
> protocol Constructable {
> init()
> }
> 
> extension UIView: Constructable {}
> 
> extension Int {
> func of(_ generator: @autoclosure () -> T) -> 
> UnfoldSequence {
> assert(self > 0, "cannot generate negative-count collection")
> return sequence(state: self, next: { (state: inout Int) -> T? in
> defer { state -= 1 }; return state == 0 ? nil : T.init() })
> }
> }
> 
> print(Array(5.of(UIView(
> 
> // or
> 
> extension Int {
> func of(_ generator: @escaping @autoclosure () -> T) -> 
> LazyMapRandomAccessCollection<(CountableRange), T> {
> assert(self > 0, "cannot generate negative-count collection")
> return (0 ..< self).lazy.map({ _ in generator() })
> }
> }
> 
> // where some people preferred calling this `elements`, for example 
> `5.elements(of: UIView())`
> 
> // You can go Array:
> 
> extension Array {
> /// Creates a new array containing the specified number of values created 
> by repeating a generating closure.
> ///
> /// - Parameters:
> ///   - count: The number of times to apply the closure. `count` must be 
> zero or greater.
> ///   - generator: The closure to execute
> public init(count: Int, repeating: () -> Element) {
> precondition(count >= 0, "")
> self.init((1 ... count).map({ _ in repeating() }))
> }
> }
> 
> let labels = Array(count: 4) { UILabel() }
> 
> // Or similarly
> 
> extension Array {
> init(repeat count: Int, byCalling generator: @autoclosure () -> Element) {
> self = (1 ... count).map({ _ in generator() })
> }
> }
> 
> // From Oliver H:
> 
> extension Array {
>   convenience init(count: Int, repeating: () -> Elements) {
> self = Array( (0..   }
> }
> 
> let views: [UIView] = Array(count: 5) { UIView(frame: .zero) }
> 
> // This one is from Soroush K. I think it's clever but I wouldn't really use 
> it
> 
> func * (generator: @autoclosure () -> T, n: Int) -> [T] {
>   (0.. }
> 
> UIView() * 5
> 
> 
>> On Aug 17, 2017, at 10:36 AM, Tony Allevato via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>> On Thu, Aug 17, 2017 at 9:20 AM Ross O'Brien > > wrote:
>> (0..<3).map{ _ in UIView() } - map already returns an Array.
>> 
>> Array((0..<3).map{ _ in UIView() }) is redundant.
>> 
>> Ah, right, thanks for pointing that out. I couldn't remember off the top of 
>> my head whether it returned an array or some kind of special sequence type 
>> that would ne

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Haravikk via swift-evolution]

> On 17 Aug 2017, at 18:04, Chris Lattner  wrote:
>> On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>> On 17 Aug 2017, at 11:42, Robert Bennett >> > wrote:
>>> 
>>> Chris mentions that the intent was to mimic a default implementation in a 
>>> constrained protocol extension, with one extension per type that doesn’t 
>>> define its own ==/hashValue while conforming to Equatable/Hashable. 
>>> Constrained extensions are allowed to use type information from the 
>>> constraint, so I don’t think there is an issue here.
>> 
>> And I disagree; this isn't a constraint extension either, not even close, 
>> we're talking here about automatic behaviour based upon variables the 
>> protocol knows literally nothing about, in a way that can result in new 
>> errors that are currently impossible (as you can't currently conform to 
>> Equatable without providing some kind of code to implement it).
> 
> I understand and recognize your concern.  Your points are apply equally to 
> the default implementation of the Codable protocols as well, and the core 
> team specifically discussed this.
> 
> Also, if I were to nitpick your argument a bit, it isn’t true that the 
> protocol knows “nothing" about the type anyway, because the protocol has 
> access to self.  The default implementation could conceptually use reflection 
> to access all the state in the type: we’re producing the same effect with 
> more efficient code.

Parts that the protocol specifically defines are fine, I've said as much; the 
part I object to is everything else as the issue here is that the protocol must 
make assumptions about the concrete type and I find that dangerous, especially 
on an existing protocol. I would argue that any default implementation using 
reflection to do the same is likewise flawed unless the behaviour is very 
carefully and very clearly defined as part of a contract that developers are 
explicitly opting in to.

But that's not what's happening here; Equatable is an existing and well 
understood protocol and you are proposing to change it arbitrarily to suddenly 
imply functionality that doesn't currently exist and which has the potential to 
introduce bugs.

I have seen not one shred of justification why this feature must be implicit 
through Equatable except that Codable does it, and frankly I don't find that 
even close to acceptable as a precedent at all as Codable is not preexisting, 
and personally I don't like it in Codable's case either, and wasn't aware of 
the discussion around it. But for Equatable we're talking about a preexisting 
protocol that will today catch 100% of missing conformance bugs, being changed 
such that that is no longer the case because of a default behaviour that will 
hide such bugs by making potentially flawed assumptions about a concrete type.

Frankly, setting a precedent for this kind of automated background reflective 
guesswork on basic protocols is a horrifying prospect to me, even more so if it 
is being introduced arbitrarily on existing protocols. At least with things 
like unit testing that reflect test methods the rules are clearly known from 
the outset (i.e- there's a clear naming convention for what is reflected, 
everything else is the developer's domain, you opt-in by following that naming 
convention), this is not the case here.

And what exactly is the burden from opting in explicitly? A different protocol 
name, a keyword or an attribute are not going to trouble developers, and will 
clarify exactly what they intended without hiding bugs. This is why I feel this 
hasn't been considered sufficiently at all, as no justification is given why 
"AutoEquatable" or whatever is somehow an unacceptable burden to clarify what a 
developer actually wanted.

For me the whole point of a basic protocol is that it forces me to implement 
some requirements in order to conform; I can throw a bunch of protocols onto a 
type and know that it won't compile until I've finished it, developers get 
distracted, leave things unfinished to go back to later, make typos etc. etc. 
To me declaring a conformance is a declaration of "my type will meet the 
requirements for this make, sure I do it", not "please, please use some magic 
to do this for me"; there needs to be a clear difference between the two.

This is an overreach, plain and simple. While it may seem small, I would 
frankly rather go back to coding everything in C++ than continue using Swift if 
this is to be the direction of travel, as there's a big a difference between 
convenience and trying to guess what a developer wanted. Cutting down on 
boilerplate is a fine goal, but it should be because I as the developer wanted 
it, not someone else who thinks they're doing me a favour despite knowing 
nothing about my code.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo

Re: [swift-evolution] pitch: Unified libc import (again)

[Daniel Dunbar via swift-evolution]

> On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution 
>  wrote:
> 
> I know this has come up before without any action, but having the standard C 
> library be packaged under `Darwin` on OSX and `Glibc` under Linux is 
> something that’s really becoming an issue as the Swift package ecosystem 
> matures. Right now a lot of packages are a lot less portable than they could 
> be because somewhere along the dependency line, there is a package that only 
> imports the C library for one platform. Unifying it under one import would 
> allow people to write packages that are portable by default.

What we (SwiftPM) have done for now is use a `libc` target to start by 
normalizing the name:
  https://github.com/apple/swift-package-manager/tree/master/Sources/libc
(and in the past, when we find missing things in Glibc getting them added to 
the compiler). Also, this name is technically a misnomer, but we couldn’t think 
of a better one (“os” might have been a good one).

Unfortunately, I think this change alone is really only the tip of the iceberg. 
It would be nice to not have it the difference, but we found we very quickly 
needed several other layers on top to get to having a relatively stable 
cross-platform base:
  https://github.com/apple/swift-package-manager/tree/master/Sources/POSIX
  https://github.com/apple/swift-package-manager/tree/master/Sources/Basic

My hope is that one minimal improvement we can get soon is multi-package repo 
support in SwiftPM, which will at least allow us to share those targets & 
functionality with other packages.

> Since I think this got hung up in the past over “what constitutes” a 
> universal libc, I propose a unified package should just consist of the 
> functionality that is common between Darwin and Glibc right now, since those 
> are the only two supported platforms anyway.

What would the concrete proposal be? It isn’t trivial to determine that subset 
and make it well-defined what the exact API is. Is the proposal to just to pick 
a standard name, and reexport Darwin and Glibc from it?

> Alternatively, Swift could make it a priority to get basic functionality like 
> file IO and math functions shipped with the compiler, which would probably 
> cover 98% of cases where people currently import Darwin/Glibc. A large 
> portion of the standard C libraries are redundant to the Swift standard 
> library anyway.

I’m not sure I agree with these statements about the percentages. For some 
clients (I’m biased, the areas I work in tend to be in this boat), what we 
largely need is good platform-agnostic access to the POSIX APIs. This is a hard 
problem to make a good cross-platform API for (esp. if Windows support is in 
your head), and which many projects struggle with (Netscape :: NSPR, LLVM :: 
libSupport, many many more).

The sticking point I see is this: if the proposal is just to unify the name & 
that doesn’t actually buy us all that much (still need standard layers on top), 
then have we really solved enough of a problem to be worth standardizing on?

+1 in general agreement with the meta-issue being an important one to discuss.

 - Daniel

> ___
> 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-0185 - Synthesizing Equatable and Hashable conformance

[Nevin Brackett-Rozinsky via swift-evolution]

I am really glad this is happening, it will make implementing basic data
types much nicer, and it is exactly the sort of feature that saves
developers from having to waste time thinking about trivial rote
boilerplate both when writing and when reading code—an excellent and
welcome addition to the language.

As for Haravikk’s scenario of marking a type as Equatable to trigger an
error so you remember to implement the protocol later, you can achieve the
same goal by tagging it “MakeMeEquatable” instead. The compiler will give
an error (because there is no such protocol) and then you can come back to
fix it another time.

Nevin


On Wed, Aug 16, 2017 at 6:29 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal Link: https://github.com/apple/swift-evolution/blob/master/
> proposals/0185-synthesize-equatable-hashable.md
>
> The review of SE-0185 “Synthesizing Equatable and Hashable conformance”
> ran from August 9…15, 2017. Feedback for the feature was glowingly
> positive, and the proposal is accepted.  The core team discussed the
> concerns raised in the feedback thread for the proposal.  Here are some
> rough notes (not intended to be exhaustive), but it is important to
> recognize that the proposal follows the design of the auto-synthesized
> Codable proposal, and that many of these same points were discussed when it
> came up:
>
> - The core team feels that adding compiler magic for this case is
> reasonable because it solves an important user need, and doesn’t preclude
> the introduction of a more general feature (e.g. like a macro system, or
> Rust's ‘deriving’ feature) in the future.  When/if that feature is designed
> and built, the compiler magic can be replaced with standard library magic.
>
> - The hash value of a type is not intended to be stable across rebuilds or
> other changes to the code.  It is ok to change if fields are reordered, the
> standard library changes the hash function, etc.  Tony pointed this out
> on-thread, saying:  The stdlib documentation for hashValue states "Hash
> values are not guaranteed to be equal across different executions of your
> program. Do not save hash values to use during a future execution.”
>
> - The code synthesized is meant to feel like a default implementation that
> you’re getting for free from a (constrained) extension on the protocol.
> This is why conformance to the protocol itself is all that is required, not
> something like “AutoEquatable”.
>
> Many thanks to Tony Allevato for driving forward this proposal.  The patch
> just needs final code review now - I think we’re all looking forward to
> this landing, congrats!
>
> 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] [Pitch] Improve `init(repeating:count)`

[Erica Sadun via swift-evolution]

> On Aug 17, 2017, at 12:04 PM, Max Moiseev  wrote:
> 
> 
>> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Also, for those of you here who haven't heard my previous rant on the 
>> subject, I dislike using map for generating values that don't depend on 
>> transforming a domain to a range. (It has been argued that `_ in` is mapping 
>> from `Void`, but I still dislike it immensely)
> 
> Can you please elaborate why (or maybe point me at the rant)? 


Summary:

. Since this application is a generator and not a transformative function, 
`map` is a misfit to usage semantics. It breaks the contract that map means to 
project from a domain to a range via a function. More languages conventionally 
use `collect` than `map` to collect n applications of a generator closure

-- E

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

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Xiaodi Wu via swift-evolution]

This is, I would argue, much too limiting in the way of semantics and not
at all required by “map”. It’s unclear to me how _any_ result with
reference semantics or any function with side effects could be used in a
way that comports with that definition.

On the other hand, just as y = 0x is a function, { _ in Foo() } is a
closure that very much does project from a domain to a range. I’m not sure
I understand what wins are to be had by having “collect {}” as a synonym
for “map { _ in }”.

On Thu, Aug 17, 2017 at 16:01 Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Aug 17, 2017, at 12:04 PM, Max Moiseev  wrote:
>
>
> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Also, for those of you here who haven't heard my previous rant on the
> subject, I dislike using map for generating values that don't depend on
> transforming a domain to a range. (It has been argued that `_ in` is
> mapping from `Void`, but I still dislike it immensely)
>
>
> Can you please elaborate why (or maybe point me at the rant)?
>
>
>
> Summary:
>
> . Since this application is a generator and not a transformative function,
> `map` is a misfit to usage semantics. It breaks the contract that map means
> to project from a domain to a range via a function. More languages
> conventionally use `collect` than `map` to collect n applications of a
> generator closure
>
> -- 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

[swift-evolution] kicking off concurrency discussions

[Ted Kremenek via swift-evolution]

Hi everyone,

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

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

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


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

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

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

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

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

Re: [swift-evolution] [Concurrency] async/await + actors

[Chris Lattner via swift-evolution]

> On Aug 17, 2017, at 3:24 PM, Chris Lattner  wrote:
> 
> Hi all,
> 
> As Ted mentioned in his email, it is great to finally kick off discussions 
> for what concurrency should look like in Swift.  This will surely be an epic 
> multi-year journey, but it is more important to find the right design than to 
> get there fast.
> 
> I’ve been advocating for a specific model involving async/await and actors 
> for many years now.  Handwaving only goes so far, so some folks asked me to 
> write them down to make the discussion more helpful and concrete.  While I 
> hope these ideas help push the discussion on concurrency forward, this isn’t 
> in any way meant to cut off other directions: in fact I hope it helps give 
> proponents of other designs a model to follow: a discussion giving extensive 
> rationale, combined with the long term story arc to show that the features 
> fit together.
> 
> Anyway, here is the document, I hope it is useful, and I’d love to hear 
> comments and suggestions for improvement:
> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 
> 

Oh, also, one relatively short term piece of this model is a proposal for 
adding an async/await model to Swift (in the form of general coroutine 
support).  Joe Groff and I wrote up a proposal for this, here:
https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619

and I have a PR with the first half of the implementation here:
https://github.com/apple/swift/pull/11501

The piece that is missing is code generation support.

-Chris

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

[swift-evolution] [Concurrency] async/await + actors

[Chris Lattner via swift-evolution]

Hi all,

As Ted mentioned in his email, it is great to finally kick off discussions for 
what concurrency should look like in Swift.  This will surely be an epic 
multi-year journey, but it is more important to find the right design than to 
get there fast.

I’ve been advocating for a specific model involving async/await and actors for 
many years now.  Handwaving only goes so far, so some folks asked me to write 
them down to make the discussion more helpful and concrete.  While I hope these 
ideas help push the discussion on concurrency forward, this isn’t in any way 
meant to cut off other directions: in fact I hope it helps give proponents of 
other designs a model to follow: a discussion giving extensive rationale, 
combined with the long term story arc to show that the features fit together.

Anyway, here is the document, I hope it is useful, and I’d love to hear 
comments and suggestions for improvement:
https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782

-Chris

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

Re: [swift-evolution] pitch: Unified libc import (again)

[Taylor Swift via swift-evolution]

On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar 
wrote:

>
> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I know this has come up before without any action, but having the
> standard C library be packaged under `Darwin` on OSX and `Glibc` under
> Linux is something that’s really becoming an issue as the Swift package
> ecosystem matures. Right now a lot of packages are a lot less portable than
> they could be because somewhere along the dependency line, there is a
> package that only imports the C library for one platform. Unifying it under
> one import would allow people to write packages that are portable by
> default.
>
> What we (SwiftPM) have done for now is use a `libc` target to start by
> normalizing the name:
>   https://github.com/apple/swift-package-manager/tree/master/Sources/libc
> (and in the past, when we find missing things in Glibc getting them added
> to the compiler). Also, this name is technically a misnomer, but we
> couldn’t think of a better one (“os” might have been a good one).
>
> Unfortunately, I think this change alone is really only the tip of the
> iceberg. It would be nice to not have it the difference, but we found we
> very quickly needed several other layers on top to get to having a
> relatively stable cross-platform base:
>   https://github.com/apple/swift-package-manager/tree/master/Sources/POSIX
>   https://github.com/apple/swift-package-manager/tree/master/Sources/Basic
>
> My hope is that one minimal improvement we can get soon is multi-package
> repo support in SwiftPM, which will at least allow us to share those
> targets & functionality with other packages.
>
> > Since I think this got hung up in the past over “what constitutes” a
> universal libc, I propose a unified package should just consist of the
> functionality that is common between Darwin and Glibc right now, since
> those are the only two supported platforms anyway.
>
> What would the concrete proposal be? It isn’t trivial to determine that
> subset and make it well-defined what the exact API is. Is the proposal to
> just to pick a standard name, and reexport Darwin and Glibc from it?
>

I don’t know if it’s actually this simple, but could it just be the symbols
that are defined in both modules?


>
> > Alternatively, Swift could make it a priority to get basic functionality
> like file IO and math functions shipped with the compiler, which would
> probably cover 98% of cases where people currently import Darwin/Glibc. A
> large portion of the standard C libraries are redundant to the Swift
> standard library anyway.
>
> I’m not sure I agree with these statements about the percentages. For some
> clients (I’m biased, the areas I work in tend to be in this boat), what we
> largely need is good platform-agnostic access to the POSIX APIs. This is a
> hard problem to make a good cross-platform API for (esp. if Windows support
> is in your head), and which many projects struggle with (Netscape :: NSPR,
> LLVM :: libSupport, many many more).
>
> The sticking point I see is this: if the proposal is just to unify the
> name & that doesn’t actually buy us all that much (still need standard
> layers on top), then have we really solved enough of a problem to be worth
> standardizing on?
>
> +1 in general agreement with the meta-issue being an important one to
> discuss.
>

There probably is an XY issue at play here; what we *really* need is a way
to access the file system built into the standard library. (Math functions
are a separate, beleaguered topic for a different thread.) Having support
for outputting to `stderr` is also something I’d really like. Going through
Glibc/Darwin is just one way to solve this.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] pitch: Unified libc import (again)

[Taylor Swift via swift-evolution]

Python’s os.path  is a nice
abstract model for doing path manipulations. Maybe Swift could get a struct
like `Filepath` or something on which these operations could be done.

On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift  wrote:

>
>
> On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar 
> wrote:
>
>>
>> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > I know this has come up before without any action, but having the
>> standard C library be packaged under `Darwin` on OSX and `Glibc` under
>> Linux is something that’s really becoming an issue as the Swift package
>> ecosystem matures. Right now a lot of packages are a lot less portable than
>> they could be because somewhere along the dependency line, there is a
>> package that only imports the C library for one platform. Unifying it under
>> one import would allow people to write packages that are portable by
>> default.
>>
>> What we (SwiftPM) have done for now is use a `libc` target to start by
>> normalizing the name:
>>   https://github.com/apple/swift-package-manager/tree/master/Sources/libc
>> (and in the past, when we find missing things in Glibc getting them added
>> to the compiler). Also, this name is technically a misnomer, but we
>> couldn’t think of a better one (“os” might have been a good one).
>>
>> Unfortunately, I think this change alone is really only the tip of the
>> iceberg. It would be nice to not have it the difference, but we found we
>> very quickly needed several other layers on top to get to having a
>> relatively stable cross-platform base:
>>   https://github.com/apple/swift-package-manager/tree/master/
>> Sources/POSIX
>>   https://github.com/apple/swift-package-manager/tree/master/
>> Sources/Basic
>>
>> My hope is that one minimal improvement we can get soon is multi-package
>> repo support in SwiftPM, which will at least allow us to share those
>> targets & functionality with other packages.
>>
>> > Since I think this got hung up in the past over “what constitutes” a
>> universal libc, I propose a unified package should just consist of the
>> functionality that is common between Darwin and Glibc right now, since
>> those are the only two supported platforms anyway.
>>
>> What would the concrete proposal be? It isn’t trivial to determine that
>> subset and make it well-defined what the exact API is. Is the proposal to
>> just to pick a standard name, and reexport Darwin and Glibc from it?
>>
>
> I don’t know if it’s actually this simple, but could it just be the
> symbols that are defined in both modules?
>
>
>>
>> > Alternatively, Swift could make it a priority to get basic
>> functionality like file IO and math functions shipped with the compiler,
>> which would probably cover 98% of cases where people currently import
>> Darwin/Glibc. A large portion of the standard C libraries are redundant to
>> the Swift standard library anyway.
>>
>> I’m not sure I agree with these statements about the percentages. For
>> some clients (I’m biased, the areas I work in tend to be in this boat),
>> what we largely need is good platform-agnostic access to the POSIX APIs.
>> This is a hard problem to make a good cross-platform API for (esp. if
>> Windows support is in your head), and which many projects struggle with
>> (Netscape :: NSPR, LLVM :: libSupport, many many more).
>>
>> The sticking point I see is this: if the proposal is just to unify the
>> name & that doesn’t actually buy us all that much (still need standard
>> layers on top), then have we really solved enough of a problem to be worth
>> standardizing on?
>>
>> +1 in general agreement with the meta-issue being an important one to
>> discuss.
>>
>
> There probably is an XY issue at play here; what we *really* need is a
> way to access the file system built into the standard library. (Math
> functions are a separate, beleaguered topic for a different thread.) Having
> support for outputting to `stderr` is also something I’d really like. Going
> through Glibc/Darwin is just one way to solve this.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] pitch: Unified libc import (again)

[Xiaodi Wu via swift-evolution]

IMO, you’re touching on at least three or four separate topics here. Daniel
touched on several, but just some comments/questions:

* Standard error output is something that’s been discussed here previously.
I believe the last pitch had something like StandardError being added to
the standard library as a TextOutputStream.

* Foundation is supposed to be the core library that provides file system
access facilities. What’s missing, and can we add it to Foundation?

On Thu, Aug 17, 2017 at 17:50 Taylor Swift via swift-evolution <
swift-evolution@swift.org> wrote:

> Python’s os.path  is a
> nice abstract model for doing path manipulations. Maybe Swift could get a
> struct like `Filepath` or something on which these operations could be done.
>
> On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift 
> wrote:
>
>>
>>
>> On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar 
>> wrote:
>>
>>>
>>> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> >
>>> > I know this has come up before without any action, but having the
>>> standard C library be packaged under `Darwin` on OSX and `Glibc` under
>>> Linux is something that’s really becoming an issue as the Swift package
>>> ecosystem matures. Right now a lot of packages are a lot less portable than
>>> they could be because somewhere along the dependency line, there is a
>>> package that only imports the C library for one platform. Unifying it under
>>> one import would allow people to write packages that are portable by
>>> default.
>>>
>>> What we (SwiftPM) have done for now is use a `libc` target to start by
>>> normalizing the name:
>>>
>>> https://github.com/apple/swift-package-manager/tree/master/Sources/libc
>>> (and in the past, when we find missing things in Glibc getting them
>>> added to the compiler). Also, this name is technically a misnomer, but we
>>> couldn’t think of a better one (“os” might have been a good one).
>>>
>>> Unfortunately, I think this change alone is really only the tip of the
>>> iceberg. It would be nice to not have it the difference, but we found we
>>> very quickly needed several other layers on top to get to having a
>>> relatively stable cross-platform base:
>>>
>>> https://github.com/apple/swift-package-manager/tree/master/Sources/POSIX
>>>
>>> https://github.com/apple/swift-package-manager/tree/master/Sources/Basic
>>>
>>> My hope is that one minimal improvement we can get soon is multi-package
>>> repo support in SwiftPM, which will at least allow us to share those
>>> targets & functionality with other packages.
>>>
>>> > Since I think this got hung up in the past over “what constitutes” a
>>> universal libc, I propose a unified package should just consist of the
>>> functionality that is common between Darwin and Glibc right now, since
>>> those are the only two supported platforms anyway.
>>>
>>> What would the concrete proposal be? It isn’t trivial to determine that
>>> subset and make it well-defined what the exact API is. Is the proposal to
>>> just to pick a standard name, and reexport Darwin and Glibc from it?
>>>
>>
>> I don’t know if it’s actually this simple, but could it just be the
>> symbols that are defined in both modules?
>>
>>
>>>
>>> > Alternatively, Swift could make it a priority to get basic
>>> functionality like file IO and math functions shipped with the compiler,
>>> which would probably cover 98% of cases where people currently import
>>> Darwin/Glibc. A large portion of the standard C libraries are redundant to
>>> the Swift standard library anyway.
>>>
>>> I’m not sure I agree with these statements about the percentages. For
>>> some clients (I’m biased, the areas I work in tend to be in this boat),
>>> what we largely need is good platform-agnostic access to the POSIX APIs.
>>> This is a hard problem to make a good cross-platform API for (esp. if
>>> Windows support is in your head), and which many projects struggle with
>>> (Netscape :: NSPR, LLVM :: libSupport, many many more).
>>>
>>> The sticking point I see is this: if the proposal is just to unify the
>>> name & that doesn’t actually buy us all that much (still need standard
>>> layers on top), then have we really solved enough of a problem to be worth
>>> standardizing on?
>>>
>>> +1 in general agreement with the meta-issue being an important one to
>>> discuss.
>>>
>>
>> There probably is an XY issue at play here; what we *really* need is a
>> way to access the file system built into the standard library. (Math
>> functions are a separate, beleaguered topic for a different thread.) Having
>> support for outputting to `stderr` is also something I’d really like. Going
>> through Glibc/Darwin is just one way to solve this.
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolut

[swift-evolution] [Concurrency] Signals — reactive-like threads

[Félix Fischer via swift-evolution]

I haven’t used Async-Await ever, so the following will probably be moot.
But here I go:

I learned concurrency at Uni with C#. Most of it was meh/okay. The gist of
it is this:
- You have instances of Threads. Each one recieves a function to start in.
When they return, they end.
- Threads can be synchronized with “locks”. Basically, mutex.
- Threads can be syncronized with Monitors (idk how they work, it was kinda
cumbersome when I was taught).

And finally, a golden nugget:
- Threads can wait for signals/events. Signals are doors where threads wait
for someone to open the door and let them keep going.
Signals can be resat automatically (letting only one thread pass before
locking again) or manually.
Their design is pretty nice because they are a lot like single UI
event-driven tools (from reactive programming).

Everything else in C# threading at the time was pretty much meh. And
error-prone, if you only used locks. But I think Signals were a golden
nugget in a way. How would they fare in current multithreaded programming?
Idk. I have to read a lot about the state of the art now.

Thanks Chris for your manifesto. I’m reading it right now :)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] pitch: Unified libc import (again)

[Taylor Swift via swift-evolution]

I don’t think the “is this library functionality or standard library
functionality” argument is worth having, but if stdout and stdin are
first-class citizens in the Swift world, so should stderr.

As for bringing Foundation into the discussion, you can’t really talk about
Foundation without also talking about the mountains of problems that come
with the monolith pattern. But that’s a completely different conversation
to be had.

On Thu, Aug 17, 2017 at 7:13 PM, Xiaodi Wu  wrote:

> IMO, you’re touching on at least three or four separate topics here.
> Daniel touched on several, but just some comments/questions:
>
> * Standard error output is something that’s been discussed here
> previously. I believe the last pitch had something like StandardError being
> added to the standard library as a TextOutputStream.
>
> * Foundation is supposed to be the core library that provides file system
> access facilities. What’s missing, and can we add it to Foundation?
>
> On Thu, Aug 17, 2017 at 17:50 Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Python’s os.path  is a
>> nice abstract model for doing path manipulations. Maybe Swift could get a
>> struct like `Filepath` or something on which these operations could be done.
>>
>> On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift 
>> wrote:
>>
>>>
>>>
>>> On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar 
>>> wrote:
>>>

 > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <
 swift-evolution@swift.org> wrote:
 >
 > I know this has come up before without any action, but having the
 standard C library be packaged under `Darwin` on OSX and `Glibc` under
 Linux is something that’s really becoming an issue as the Swift package
 ecosystem matures. Right now a lot of packages are a lot less portable than
 they could be because somewhere along the dependency line, there is a
 package that only imports the C library for one platform. Unifying it under
 one import would allow people to write packages that are portable by
 default.

 What we (SwiftPM) have done for now is use a `libc` target to start by
 normalizing the name:
   https://github.com/apple/swift-package-manager/tree/
 master/Sources/libc
 (and in the past, when we find missing things in Glibc getting them
 added to the compiler). Also, this name is technically a misnomer, but we
 couldn’t think of a better one (“os” might have been a good one).

 Unfortunately, I think this change alone is really only the tip of the
 iceberg. It would be nice to not have it the difference, but we found we
 very quickly needed several other layers on top to get to having a
 relatively stable cross-platform base:
   https://github.com/apple/swift-package-manager/tree/
 master/Sources/POSIX
   https://github.com/apple/swift-package-manager/tree/
 master/Sources/Basic

 My hope is that one minimal improvement we can get soon is
 multi-package repo support in SwiftPM, which will at least allow us to
 share those targets & functionality with other packages.

 > Since I think this got hung up in the past over “what constitutes” a
 universal libc, I propose a unified package should just consist of the
 functionality that is common between Darwin and Glibc right now, since
 those are the only two supported platforms anyway.

 What would the concrete proposal be? It isn’t trivial to determine that
 subset and make it well-defined what the exact API is. Is the proposal to
 just to pick a standard name, and reexport Darwin and Glibc from it?

>>>
>>> I don’t know if it’s actually this simple, but could it just be the
>>> symbols that are defined in both modules?
>>>
>>>

 > Alternatively, Swift could make it a priority to get basic
 functionality like file IO and math functions shipped with the compiler,
 which would probably cover 98% of cases where people currently import
 Darwin/Glibc. A large portion of the standard C libraries are redundant to
 the Swift standard library anyway.

 I’m not sure I agree with these statements about the percentages. For
 some clients (I’m biased, the areas I work in tend to be in this boat),
 what we largely need is good platform-agnostic access to the POSIX APIs.
 This is a hard problem to make a good cross-platform API for (esp. if
 Windows support is in your head), and which many projects struggle with
 (Netscape :: NSPR, LLVM :: libSupport, many many more).

 The sticking point I see is this: if the proposal is just to unify the
 name & that doesn’t actually buy us all that much (still need standard
 layers on top), then have we really solved enough of a problem to be worth
 standardizing on?

 +1 in general agreement with the meta-issue being an important one to
 discuss.
>>>

Re: [swift-evolution] [Concurrency] async/await + actors

[Rod Brown via swift-evolution]

Hi Chris,

I love what I’ve read so far. I just have one curiosity from my cursory look 
over the proposal.

It seems that in transitioning API to an Async Await system, the completion 
handler’s type becomes the return type. How would you handle bridging in 
Foundation API that already has a return type, eg URLSession returns you data 
tasks, and then fires a completion handler. Perhaps I missed something. I’m 
sure you could always form a tuple as well, just curious the thoughts on that.

Thanks,

Rod

> On 18 Aug 2017, at 8:25 am, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Aug 17, 2017, at 3:24 PM, Chris Lattner  wrote:
>> 
>> Hi all,
>> 
>> As Ted mentioned in his email, it is great to finally kick off discussions 
>> for what concurrency should look like in Swift.  This will surely be an epic 
>> multi-year journey, but it is more important to find the right design than 
>> to get there fast.
>> 
>> I’ve been advocating for a specific model involving async/await and actors 
>> for many years now.  Handwaving only goes so far, so some folks asked me to 
>> write them down to make the discussion more helpful and concrete.  While I 
>> hope these ideas help push the discussion on concurrency forward, this isn’t 
>> in any way meant to cut off other directions: in fact I hope it helps give 
>> proponents of other designs a model to follow: a discussion giving extensive 
>> rationale, combined with the long term story arc to show that the features 
>> fit together.
>> 
>> Anyway, here is the document, I hope it is useful, and I’d love to hear 
>> comments and suggestions for improvement:
>> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
> 
> Oh, also, one relatively short term piece of this model is a proposal for 
> adding an async/await model to Swift (in the form of general coroutine 
> support).  Joe Groff and I wrote up a proposal for this, here:
> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619
> 
> and I have a PR with the first half of the implementation here:
> https://github.com/apple/swift/pull/11501
> 
> The piece that is missing is code generation support.
> 
> -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] [Concurrency] async/await + actors

[William Jon Shipley via swift-evolution]

I’m curious about this statement at the end in "alternatives":

> The proposed design eliminates the problem of calling an API (without knowing 
> it is async) and getting a Future back instead of the expected T result 
> type. C# addresses this by suggesting that all async methods have their name 
> be suffixed with Async, which is suboptimal.

Not that I necessarily think always returning Futures would be good (or bad), 
but it seems to me like since we’re required to use the “await” keyword now, 
we’d just have some similar keyword in an always-Future-returning universe, 
like:

let image = future makeImage()

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

Re: [swift-evolution] [Concurrency] async/await + actors

[William Jon Shipley via swift-evolution]

Oh, I see that this is addressed in the “ x = await (await foo()).bar()” 
example. That IS ugly.

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

Re: [swift-evolution] [Concurrency] async/await + actors

[Rod Brown via swift-evolution]

> On 18 Aug 2017, at 9:56 am, Rod Brown via swift-evolution 
>  wrote:
> 
> 
> Hi Chris,
> 
> I love what I’ve read so far. I just have one curiosity from my cursory look 
> over the proposal.
> 
> It seems that in transitioning API to an Async Await system, the completion 
> handler’s type becomes the return type. How would you handle bridging in 
> Foundation API that already has a return type, eg URLSession returns you data 
> tasks, and then fires a completion handler. Perhaps I missed something. I’m 
> sure you could always form a tuple as well, just curious the thoughts on that.

Just as a follow up, thinking this through I’m not sure combining it with this 
completion handler argument tuple is helpful here, because you generally want 
access to the data task during execution for cancellation, progress handling 
etc.

The Async await system doesn’t seem to work well with handling setting 
something and allowing duplicate return types at different times like a lot of 
the foundation API is written, does it? I’m not sure how this is solved in C#.


> 
> Thanks,
> 
> Rod
> 
>> On 18 Aug 2017, at 8:25 am, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Aug 17, 2017, at 3:24 PM, Chris Lattner  wrote:
>>> 
>>> Hi all,
>>> 
>>> As Ted mentioned in his email, it is great to finally kick off discussions 
>>> for what concurrency should look like in Swift.  This will surely be an 
>>> epic multi-year journey, but it is more important to find the right design 
>>> than to get there fast.
>>> 
>>> I’ve been advocating for a specific model involving async/await and actors 
>>> for many years now.  Handwaving only goes so far, so some folks asked me to 
>>> write them down to make the discussion more helpful and concrete.  While I 
>>> hope these ideas help push the discussion on concurrency forward, this 
>>> isn’t in any way meant to cut off other directions: in fact I hope it helps 
>>> give proponents of other designs a model to follow: a discussion giving 
>>> extensive rationale, combined with the long term story arc to show that the 
>>> features fit together.
>>> 
>>> Anyway, here is the document, I hope it is useful, and I’d love to hear 
>>> comments and suggestions for improvement:
>>> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
>> 
>> Oh, also, one relatively short term piece of this model is a proposal for 
>> adding an async/await model to Swift (in the form of general coroutine 
>> support).  Joe Groff and I wrote up a proposal for this, here:
>> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619
>> 
>> and I have a PR with the first half of the implementation here:
>> https://github.com/apple/swift/pull/11501
>> 
>> The piece that is missing is code generation support.
>> 
>> -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] pitch: Unified libc import (again)

[Xiaodi Wu via swift-evolution]

On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift  wrote:

> I don’t think the “is this library functionality or standard library
> functionality” argument is worth having, but if stdout and stdin are
> first-class citizens in the Swift world, so should stderr.
>
> As for bringing Foundation into the discussion, you can’t really talk
> about Foundation without also talking about the mountains of problems that
> come with the monolith pattern. But that’s a completely different
> conversation to be had.
>

I'm not sure what you're getting at here, but I don't believe you've
addressed my question, which is: it's been firmly decided that I/O belongs
in Foundation, and Foundation does in fact offer such facilities--what is
missing from those facilities, and how can we fill it out?


On Thu, Aug 17, 2017 at 7:13 PM, Xiaodi Wu  wrote:
>
>> IMO, you’re touching on at least three or four separate topics here.
>> Daniel touched on several, but just some comments/questions:
>>
>> * Standard error output is something that’s been discussed here
>> previously. I believe the last pitch had something like StandardError being
>> added to the standard library as a TextOutputStream.
>>
>> * Foundation is supposed to be the core library that provides file system
>> access facilities. What’s missing, and can we add it to Foundation?
>>
>> On Thu, Aug 17, 2017 at 17:50 Taylor Swift via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Python’s os.path  is a
>>> nice abstract model for doing path manipulations. Maybe Swift could get a
>>> struct like `Filepath` or something on which these operations could be done.
>>>
>>> On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift 
>>> wrote:
>>>


 On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar >>> > wrote:

>
> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I know this has come up before without any action, but having the
> standard C library be packaged under `Darwin` on OSX and `Glibc` under
> Linux is something that’s really becoming an issue as the Swift package
> ecosystem matures. Right now a lot of packages are a lot less portable 
> than
> they could be because somewhere along the dependency line, there is a
> package that only imports the C library for one platform. Unifying it 
> under
> one import would allow people to write packages that are portable by
> default.
>
> What we (SwiftPM) have done for now is use a `libc` target to start by
> normalizing the name:
>   https://github.com/apple/swift-package-manager/tree/master/
> Sources/libc
> (and in the past, when we find missing things in Glibc getting them
> added to the compiler). Also, this name is technically a misnomer, but we
> couldn’t think of a better one (“os” might have been a good one).
>
> Unfortunately, I think this change alone is really only the tip of the
> iceberg. It would be nice to not have it the difference, but we found we
> very quickly needed several other layers on top to get to having a
> relatively stable cross-platform base:
>   https://github.com/apple/swift-package-manager/tree/master/
> Sources/POSIX
>   https://github.com/apple/swift-package-manager/tree/master/
> Sources/Basic
>
> My hope is that one minimal improvement we can get soon is
> multi-package repo support in SwiftPM, which will at least allow us to
> share those targets & functionality with other packages.
>
> > Since I think this got hung up in the past over “what constitutes” a
> universal libc, I propose a unified package should just consist of the
> functionality that is common between Darwin and Glibc right now, since
> those are the only two supported platforms anyway.
>
> What would the concrete proposal be? It isn’t trivial to determine
> that subset and make it well-defined what the exact API is. Is the 
> proposal
> to just to pick a standard name, and reexport Darwin and Glibc from it?
>

 I don’t know if it’s actually this simple, but could it just be the
 symbols that are defined in both modules?


>
> > Alternatively, Swift could make it a priority to get basic
> functionality like file IO and math functions shipped with the compiler,
> which would probably cover 98% of cases where people currently import
> Darwin/Glibc. A large portion of the standard C libraries are redundant to
> the Swift standard library anyway.
>
> I’m not sure I agree with these statements about the percentages. For
> some clients (I’m biased, the areas I work in tend to be in this boat),
> what we largely need is good platform-agnostic access to the POSIX APIs.
> This is a hard problem to make a good cross-platform API for (esp. if
> Windows support is in your head)

Re: [swift-evolution] [Concurrency] async/await + actors

[William Jon Shipley via swift-evolution]

I think the comments on “prettify()” are from an earlier version of the sample 
code? The way it’s called it doesn’t look like it’d access theList at all.

  actor TableModel {
let mainActor : TheMainActor
var theList : [String] = [] {
  didSet {
mainActor.updateTableView(theList)
  }
}

init(mainActor: TheMainActor) { self.mainActor = mainActor }

// this checks to see if all the entries in the list are capitalized:
// if so, it capitalize the string before returning it to encourage
// capitalization consistency in the list.
func prettify(_ x : String) -> String {
  // ... details omitted, it just pokes theList directly ...
}

actor func add(entry: String) {
  theList.append(prettify(entry))
}
  }

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

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Erica Sadun via swift-evolution]

What people are doing is taking a real set of values (1, 2, 3, 4, 5, for 
example), then discarding them via `_ in`, which is different from `Void -> T` 
or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,  
UIColor.red, { x: Int in x^x }). There are too many semantic shifts away from 
"I would like to collect the execution of this closure n times" for it to sit 
comfortably.

-- E


> On Aug 17, 2017, at 3:53 PM, Xiaodi Wu  wrote:
> 
> This is, I would argue, much too limiting in the way of semantics and not at 
> all required by “map”. It’s unclear to me how _any_ result with reference 
> semantics or any function with side effects could be used in a way that 
> comports with that definition.
> 
> On the other hand, just as y = 0x is a function, { _ in Foo() } is a closure 
> that very much does project from a domain to a range. I’m not sure I 
> understand what wins are to be had by having “collect {}” as a synonym for 
> “map { _ in }”.
> 
> On Thu, Aug 17, 2017 at 16:01 Erica Sadun via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> On Aug 17, 2017, at 12:04 PM, Max Moiseev > > wrote:
>> 
>> 
>>> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Also, for those of you here who haven't heard my previous rant on the 
>>> subject, I dislike using map for generating values that don't depend on 
>>> transforming a domain to a range. (It has been argued that `_ in` is 
>>> mapping from `Void`, but I still dislike it immensely)
>> 
>> Can you please elaborate why (or maybe point me at the rant)? 
> 
> 
> Summary:
> 
> . Since this application is a generator and not a transformative function, 
> `map` is a misfit to usage semantics. It breaks the contract that map means 
> to project from a domain to a range via a function. More languages 
> conventionally use `collect` than `map` to collect n applications of a 
> generator closure
> 
> -- 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] [Concurrency] async/await + actors

[Xiaodi Wu via swift-evolution]

On Thu, Aug 17, 2017 at 5:25 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Aug 17, 2017, at 3:24 PM, Chris Lattner  wrote:
>
> Hi all,
>
> As Ted mentioned in his email, it is great to finally kick off discussions
> for what concurrency should look like in Swift.  This will surely be an
> epic multi-year journey, but it is more important to find the right design
> than to get there fast.
>
> I’ve been advocating for a specific model involving async/await and actors
> for many years now.  Handwaving only goes so far, so some folks asked me to
> write them down to make the discussion more helpful and concrete.  While I
> hope these ideas help push the discussion on concurrency forward, this
> isn’t in any way meant to cut off other directions: in fact I hope it helps
> give proponents of other designs a model to follow: a discussion giving
> extensive rationale, combined with the long term story arc to show that the
> features fit together.
>
> Anyway, here is the document, I hope it is useful, and I’d love to hear
> comments and suggestions for improvement:
> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
>
>
> Oh, also, one relatively short term piece of this model is a proposal for
> adding an async/await model to Swift (in the form of general coroutine
> support).  Joe Groff and I wrote up a proposal for this, here:
> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619
>
> and I have a PR with the first half of the implementation here:
> https://github.com/apple/swift/pull/11501
>
> The piece that is missing is code generation support.
>

Hi Chris et al,

This is definitely a great initial model.

To clarify, are the authors proponents of the syntax shown in the body of
the draft--async, throws, async throws--or of the alternative design listed
below that is "probably the right set of tradeoffs"--async, throws,
async(nonthrowing)?

Naively, to me, the observation that in your introduction you've separated
`async` and `throws` suggests that keeping the two orthogonal to each other
is the more teachable design. I appreciate how there is an intimate
connection between `async` and `throws`, but it seems to me that
`async(nonthrowing)` is a highly unintuitive result--_especially_ since the
rationale for not outright making `async` a subtype of `throws` is that
asynchronous non-throwing functions are a key Cocoa idiom.

Other than that, I would hope that the primitive functions `beginAsync`,
etc., are indeed exposed outside the standard library; agree that their
names could use some light bikeshedding :)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Xiaodi Wu via swift-evolution]

On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun  wrote:

> What people are doing is taking a real set of values (1, 2, 3, 4, 5, for
> example), then discarding them via `_ in`, which is different from `Void ->
> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,
>  UIColor.red, { x: Int in x^x }). There are too many semantic shifts away
> from "I would like to collect the execution of this closure n times" for it
> to sit comfortably.
>

What arguments might help to alleviate this discomfort? Clearly, functions
exist that can map this delightfully heterogeneous domain to some sort of
range that the user wants. Would you feel better if we wrote instead the
following?

```
repeatElement((), count: 5).map { UIView() }
```

-- E
>
>
> On Aug 17, 2017, at 3:53 PM, Xiaodi Wu  wrote:
>
> This is, I would argue, much too limiting in the way of semantics and not
> at all required by “map”. It’s unclear to me how _any_ result with
> reference semantics or any function with side effects could be used in a
> way that comports with that definition.
>
> On the other hand, just as y = 0x is a function, { _ in Foo() } is a
> closure that very much does project from a domain to a range. I’m not sure
> I understand what wins are to be had by having “collect {}” as a synonym
> for “map { _ in }”.
>
> On Thu, Aug 17, 2017 at 16:01 Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Aug 17, 2017, at 12:04 PM, Max Moiseev  wrote:
>>
>>
>> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Also, for those of you here who haven't heard my previous rant on the
>> subject, I dislike using map for generating values that don't depend on
>> transforming a domain to a range. (It has been argued that `_ in` is
>> mapping from `Void`, but I still dislike it immensely)
>>
>>
>> Can you please elaborate why (or maybe point me at the rant)?
>>
>>
>>
>> Summary:
>>
>> . Since this application is a generator and not a transformative
>> function, `map` is a misfit to usage semantics. It breaks the contract that
>> map means to project from a domain to a range via a function. More
>> languages conventionally use `collect` than `map` to collect n applications
>> of a generator closure
>>
>> -- 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] Improve `init(repeating:count)`

[Erica Sadun via swift-evolution]

> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu  wrote:
> 
> On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun  > wrote:
> What people are doing is taking a real set of values (1, 2, 3, 4, 5, for 
> example), then discarding them via `_ in`, which is different from `Void -> 
> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,  
> UIColor.red, { x: Int in x^x }). There are too many semantic shifts away from 
> "I would like to collect the execution of this closure n times" for it to sit 
> comfortably.
> 
> What arguments might help to alleviate this discomfort? Clearly, functions 
> exist that can map this delightfully heterogeneous domain to some sort of 
> range that the user wants. Would you feel better if we wrote instead the 
> following?
> 
> ```
> repeatElement((), count: 5).map { UIView() }
> ```

My favorite solution is the array initializer. Something along the lines of 
`Array(count n: Int, generator: () -> T)`. I'm not sure it _quite_ reaches 
standard library but I think it is a solid way to say "produce a collection 
with a generator run n times". It's a common  task. I was asking around about 
this, and found that a lot of us who work with both macOS and iOS and want to 
stress test interfaces do this very often. Other use cases include "give me n 
random numbers", "give me n records from this database", etc. along similar 
lines.

The difference between this and the current `Array(repeating:count:)` 
initializer is switching the arguments and using a trailing closure  (or an 
autoclosure) rather than a set value. That API was designed without the 
possibility that you might want to repeat a generator, so there's a bit of 
linguistic turbulence.

-- E

>> On Aug 17, 2017, at 3:53 PM, Xiaodi Wu > > wrote:
>> 
>> This is, I would argue, much too limiting in the way of semantics and not at 
>> all required by “map”. It’s unclear to me how _any_ result with reference 
>> semantics or any function with side effects could be used in a way that 
>> comports with that definition.
>> 
>> On the other hand, just as y = 0x is a function, { _ in Foo() } is a closure 
>> that very much does project from a domain to a range. I’m not sure I 
>> understand what wins are to be had by having “collect {}” as a synonym for 
>> “map { _ in }”.
>> 
>> On Thu, Aug 17, 2017 at 16:01 Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Aug 17, 2017, at 12:04 PM, Max Moiseev >> > wrote:
>>> 
>>> 
 On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Also, for those of you here who haven't heard my previous rant on the 
 subject, I dislike using map for generating values that don't depend on 
 transforming a domain to a range. (It has been argued that `_ in` is 
 mapping from `Void`, but I still dislike it immensely)
>>> 
>>> Can you please elaborate why (or maybe point me at the rant)? 
>> 
>> 
>> Summary:
>> 
>> . Since this application is a generator and not a transformative function, 
>> `map` is a misfit to usage semantics. It breaks the contract that map means 
>> to project from a domain to a range via a function. More languages 
>> conventionally use `collect` than `map` to collect n applications of a 
>> generator closure
>> 
>> -- 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] Improve `init(repeating:count)`

[Xiaodi Wu via swift-evolution]

On Thu, Aug 17, 2017 at 8:06 PM, Erica Sadun  wrote:

>
> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu  wrote:
>
> On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun  wrote:
>
>> What people are doing is taking a real set of values (1, 2, 3, 4, 5, for
>> example), then discarding them via `_ in`, which is different from `Void ->
>> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,
>>  UIColor.red, { x: Int in x^x }). There are too many semantic shifts away
>> from "I would like to collect the execution of this closure n times" for it
>> to sit comfortably.
>>
>
> What arguments might help to alleviate this discomfort? Clearly, functions
> exist that can map this delightfully heterogeneous domain to some sort of
> range that the user wants. Would you feel better if we wrote instead the
> following?
>
> ```
> repeatElement((), count: 5).map { UIView() }
> ```
>
>
> My favorite solution is the array initializer. Something along the lines
> of `Array(count n: Int, generator: () -> T)`. I'm not sure it _quite_
> reaches standard library but I think it is a solid way to say "produce a
> collection with a generator run n times". It's a common  task. I was asking
> around about this, and found that a lot of us who work with both macOS and
> iOS and want to stress test interfaces do this very often. Other use cases
> include "give me n random numbers", "give me n records from this database",
> etc. along similar lines.
>
> The difference between this and the current `Array(repeating:count:)`
> initializer is switching the arguments and using a trailing closure  (or an
> autoclosure) rather than a set value. That API was designed without the
> possibility that you might want to repeat a generator, so there's a bit of
> linguistic turbulence.
>

...but, again, why would such an API be superior to `map`, which is already
widely used and clear? My point above was that, if your problem with using
`(0..<5).map { _ in UIView() }` is the discarding of a set of values (which
I argue is semantically unproblematic in the first place, since it's still
mapping from a domain to a range), then `repeatElement((), count: 5).map {
UIView() }` produces the same result without violating your stipulated
semantics.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Robert Bennett via swift-evolution]

Xiaodi, you pretty much took the words out of my mouth. I was going to suggest 
a Count collection whose Element was Void and with the sole initializer init(_ 
count: Int). The type would just contain its count and pretty much fake its 
collection interface, in the sense that no elements are actually stored. Then 
you could do Count(3).map { UIView() }

> On Aug 17, 2017, at 9:06 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu  wrote:
>> 
>>> On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun  wrote:
>>> What people are doing is taking a real set of values (1, 2, 3, 4, 5, for 
>>> example), then discarding them via `_ in`, which is different from `Void -> 
>>> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,  
>>> UIColor.red, { x: Int in x^x }). There are too many semantic shifts away 
>>> from "I would like to collect the execution of this closure n times" for it 
>>> to sit comfortably.
>> 
>> What arguments might help to alleviate this discomfort? Clearly, functions 
>> exist that can map this delightfully heterogeneous domain to some sort of 
>> range that the user wants. Would you feel better if we wrote instead the 
>> following?
>> 
>> ```
>> repeatElement((), count: 5).map { UIView() }
>> ```
> 
> My favorite solution is the array initializer. Something along the lines of 
> `Array(count n: Int, generator: () -> T)`. I'm not sure it _quite_ reaches 
> standard library but I think it is a solid way to say "produce a collection 
> with a generator run n times". It's a common  task. I was asking around about 
> this, and found that a lot of us who work with both macOS and iOS and want to 
> stress test interfaces do this very often. Other use cases include "give me n 
> random numbers", "give me n records from this database", etc. along similar 
> lines.
> 
> The difference between this and the current `Array(repeating:count:)` 
> initializer is switching the arguments and using a trailing closure  (or an 
> autoclosure) rather than a set value. That API was designed without the 
> possibility that you might want to repeat a generator, so there's a bit of 
> linguistic turbulence.
> 
> -- E
> 
 On Aug 17, 2017, at 3:53 PM, Xiaodi Wu  wrote:
 
 This is, I would argue, much too limiting in the way of semantics and not 
 at all required by “map”. It’s unclear to me how _any_ result with 
 reference semantics or any function with side effects could be used in a 
 way that comports with that definition.
 
 On the other hand, just as y = 0x is a function, { _ in Foo() } is a 
 closure that very much does project from a domain to a range. I’m not sure 
 I understand what wins are to be had by having “collect {}” as a synonym 
 for “map { _ in }”.
 
 On Thu, Aug 17, 2017 at 16:01 Erica Sadun via swift-evolution 
  wrote:
> 
>>> On Aug 17, 2017, at 12:04 PM, Max Moiseev  wrote:
>>> 
>>> 
>>> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> Also, for those of you here who haven't heard my previous rant on the 
>>> subject, I dislike using map for generating values that don't depend on 
>>> transforming a domain to a range. (It has been argued that `_ in` is 
>>> mapping from `Void`, but I still dislike it immensely)
>> 
>> Can you please elaborate why (or maybe point me at the rant)? 
> 
> 
> Summary:
> 
> . Since this application is a generator and not a transformative 
> function, `map` is a misfit to usage semantics. It breaks the contract 
> that map means to project from a domain to a range via a function. More 
> languages conventionally use `collect` than `map` to collect n 
> applications of a generator closure
> 
> -- 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Erica Sadun via swift-evolution]

`repeatElement((), count: 5)` is better than `1 ... 5`, but `Count(3).map({ 
UIView() })` is far more elegant.  I'd still probably go with an array 
initializer or `5.elements(of: UIView())`. I don't think I'm overstating how 
common this pattern is, and `Array(repeating:count:)` feels _close_ but not 
close enough.

-- E

> On Aug 17, 2017, at 7:13 PM, Robert Bennett  wrote:
> 
> Xiaodi, you pretty much took the words out of my mouth. I was going to 
> suggest a Count collection whose Element was Void and with the sole 
> initializer init(_ count: Int). The type would just contain its count and 
> pretty much fake its collection interface, in the sense that no elements are 
> actually stored. Then you could do Count(3).map { UIView() }
> 
> On Aug 17, 2017, at 9:06 PM, Erica Sadun via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun >> > wrote:
>>> What people are doing is taking a real set of values (1, 2, 3, 4, 5, for 
>>> example), then discarding them via `_ in`, which is different from `Void -> 
>>> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,  
>>> UIColor.red, { x: Int in x^x }). There are too many semantic shifts away 
>>> from "I would like to collect the execution of this closure n times" for it 
>>> to sit comfortably.
>>> 
>>> What arguments might help to alleviate this discomfort? Clearly, functions 
>>> exist that can map this delightfully heterogeneous domain to some sort of 
>>> range that the user wants. Would you feel better if we wrote instead the 
>>> following?
>>> 
>>> ```
>>> repeatElement((), count: 5).map { UIView() }
>>> ```
>> 
>> My favorite solution is the array initializer. Something along the lines of 
>> `Array(count n: Int, generator: () -> T)`. I'm not sure it _quite_ 
>> reaches standard library but I think it is a solid way to say "produce a 
>> collection with a generator run n times". It's a common  task. I was asking 
>> around about this, and found that a lot of us who work with both macOS and 
>> iOS and want to stress test interfaces do this very often. Other use cases 
>> include "give me n random numbers", "give me n records from this database", 
>> etc. along similar lines.
>> 
>> The difference between this and the current `Array(repeating:count:)` 
>> initializer is switching the arguments and using a trailing closure  (or an 
>> autoclosure) rather than a set value. That API was designed without the 
>> possibility that you might want to repeat a generator, so there's a bit of 
>> linguistic turbulence.
>> 
>> -- E
>> 
 On Aug 17, 2017, at 3:53 PM, Xiaodi Wu >>> > wrote:
 
 This is, I would argue, much too limiting in the way of semantics and not 
 at all required by “map”. It’s unclear to me how _any_ result with 
 reference semantics or any function with side effects could be used in a 
 way that comports with that definition.
 
 On the other hand, just as y = 0x is a function, { _ in Foo() } is a 
 closure that very much does project from a domain to a range. I’m not sure 
 I understand what wins are to be had by having “collect {}” as a synonym 
 for “map { _ in }”.
 
 On Thu, Aug 17, 2017 at 16:01 Erica Sadun via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> On Aug 17, 2017, at 12:04 PM, Max Moiseev  > wrote:
> 
> 
>> On Aug 17, 2017, at 10:05 AM, Erica Sadun via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Also, for those of you here who haven't heard my previous rant on the 
>> subject, I dislike using map for generating values that don't depend on 
>> transforming a domain to a range. (It has been argued that `_ in` is 
>> mapping from `Void`, but I still dislike it immensely)
> 
> Can you please elaborate why (or maybe point me at the rant)? 
 
 
 Summary:
 
 . Since this application is a generator and not a transformative function, 
 `map` is a misfit to usage semantics. It breaks the contract that map 
 means to project from a domain to a range via a function. More languages 
 conventionally use `collect` than `map` to collect n applications of a 
 generator closure
 
 -- 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] Improve `init(repeating:count)`

[Xiaodi Wu via swift-evolution]

On Thu, Aug 17, 2017 at 8:25 PM, Erica Sadun  wrote:

> `repeatElement((), count: 5)` is better than `1 ... 5`, but
> `Count(3).map({ UIView() })` is far more elegant.  I'd still probably go
> with an array initializer or `5.elements(of: UIView())`. I don't think I'm
> overstating how common this pattern is, and `Array(repeating:count:)` feels
> _close_ but not close enough.
>

The first two have the benefit of being currently existing APIs; they
capture the semantics perfectly, as I've argued, and I simply don't see how
they are impaired in elegance in any way--certainly not enough to justify a
standard library addition to create a third way of spelling the same thing.
Ultimately, any user is free to define something like:

```
func * (lhs: Int, rhs: @autoclosure () throws -> T) rethrows -> [T] {
  return try repeatElement((), count: lhs).map { try rhs() }
}

5 * UIView()
```
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Concurrency] async/await + actors

[Chris Lattner via swift-evolution]

> On Aug 17, 2017, at 4:56 PM, Rod Brown  wrote:
> 
> 
> Hi Chris,
> 
> I love what I’ve read so far. I just have one curiosity from my cursory look 
> over the proposal.
> 
> It seems that in transitioning API to an Async Await system, the completion 
> handler’s type becomes the return type. How would you handle bridging in 
> Foundation API that already has a return type, eg URLSession returns you data 
> tasks, and then fires a completion handler. Perhaps I missed something. I’m 
> sure you could always form a tuple as well, just curious the thoughts on that.

Ah, e.g. this one:

extension URLSession {

/*
 * data task convenience methods.  These methods create tasks that
 * bypass the normal delegate calls for response and data delivery,
 * and provide a simple cancelable asynchronous interface to receiving
 * data.  Errors will be returned in the NSURLErrorDomain, 
 * see .  The delegate, if any, will still be
 * called for authentication challenges.
 */
open func dataTask(with request: URLRequest, completionHandler: @escaping 
(Data?, URLResponse?, Error?) -> Swift.Void) -> URLSessionDataTask
}

Returning a tuple is an option, but probably wouldn’t provide the right 
semantics.  The URLSessionDataTask is supposed to be available immediately, not 
just when the completion handler is called.  The most conservative thing to do 
is to not have the importer change these.  If they should have async semantics, 
they can be manually handled with an overlay.

In any case, I wasn’t aware of those APIs, thanks for pointing them out.  I 
added a mention of this to the proposal!

-Chris


> 
> Thanks,
> 
> Rod
> 
> On 18 Aug 2017, at 8:25 am, Chris Lattner via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On Aug 17, 2017, at 3:24 PM, Chris Lattner >> > wrote:
>>> 
>>> Hi all,
>>> 
>>> As Ted mentioned in his email, it is great to finally kick off discussions 
>>> for what concurrency should look like in Swift.  This will surely be an 
>>> epic multi-year journey, but it is more important to find the right design 
>>> than to get there fast.
>>> 
>>> I’ve been advocating for a specific model involving async/await and actors 
>>> for many years now.  Handwaving only goes so far, so some folks asked me to 
>>> write them down to make the discussion more helpful and concrete.  While I 
>>> hope these ideas help push the discussion on concurrency forward, this 
>>> isn’t in any way meant to cut off other directions: in fact I hope it helps 
>>> give proponents of other designs a model to follow: a discussion giving 
>>> extensive rationale, combined with the long term story arc to show that the 
>>> features fit together.
>>> 
>>> Anyway, here is the document, I hope it is useful, and I’d love to hear 
>>> comments and suggestions for improvement:
>>> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 
>>> 
>> 
>> Oh, also, one relatively short term piece of this model is a proposal for 
>> adding an async/await model to Swift (in the form of general coroutine 
>> support).  Joe Groff and I wrote up a proposal for this, here:
>> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 
>> 
>> 
>> and I have a PR with the first half of the implementation here:
>> https://github.com/apple/swift/pull/11501 
>> 
>> 
>> The piece that is missing is code generation support.
>> 
>> -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] [Concurrency] async/await + actors

[Chris Lattner via swift-evolution]

> On Aug 17, 2017, at 5:47 PM, William Jon Shipley  
> wrote:
> 
> I think the comments on “prettify()” are from an earlier version of the 
> sample code? The way it’s called it doesn’t look like it’d access theList at 
> all.

The body of the function is omitted :-)

The idea of the goofy example is that it walks through theList to see if the 
existing entries are capitalized.  If so, it capitalizes the string, if not it 
returns the string unmodified.

-Chris



> 
>   actor TableModel {
> let mainActor : TheMainActor
> var theList : [String] = [] {
>   didSet {
> mainActor.updateTableView(theList)
>   }
> }
> 
> init(mainActor: TheMainActor) { self.mainActor = mainActor }
> 
> // this checks to see if all the entries in the list are capitalized:
> // if so, it capitalize the string before returning it to encourage
> // capitalization consistency in the list.
> func prettify(_ x : String) -> String {
>   // ... details omitted, it just pokes theList directly ...
> }
> 
> actor func add(entry: String) {
>   theList.append(prettify(entry))
> }
>   }
> 

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

Re: [swift-evolution] [Concurrency] async/await + actors

[Chris Lattner via swift-evolution]

On Aug 17, 2017, at 5:51 PM, Xiaodi Wu  wrote:
> 
> Oh, also, one relatively short term piece of this model is a proposal for 
> adding an async/await model to Swift (in the form of general coroutine 
> support).  Joe Groff and I wrote up a proposal for this, here:
> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 
> 
> 
> and I have a PR with the first half of the implementation here:
> https://github.com/apple/swift/pull/11501 
> 
> 
> The piece that is missing is code generation support.
> 
> Hi Chris et al,
> 
> This is definitely a great initial model.
> 
> To clarify, are the authors proponents of the syntax shown in the body of the 
> draft--async, throws, async throws--or of the alternative design listed below 
> that is "probably the right set of tradeoffs"--async, throws, 
> async(nonthrowing)?

I believe that Joe is in favor of making async imply throws, but I’ll let him 
speak to why.

I’m weakly in favor of it, because I believe it will lead to a simpler system 
in practice.  It seems that many async operations should also throw, so a 
design where async implies throw seems like it would skew to the right thing.  
Not just on the declaration side, but also on the marker side, because instead 
of “try await” everywhere, we could make await imply try.  Another reason is 
that this would lead to a simpler actor model, where we’d probably just bake 
the “reliability” stuff directly into the base actor model, since all the async 
APIs can throw already.

That said, I don’t feel like I have enough data to have a strong opinion on it. 
 The missing link for me is exactly how pervasive the non-throwing cocoa 
completion handlers are.  If it turns out that people would have to confront 
"async(nonthrowing)” in practice (as opposed to being an obscure corner that 
the compiler implementers have to care about) then it is probably the wrong 
design.

> Naively, to me, the observation that in your introduction you've separated 
> `async` and `throws` suggests that keeping the two orthogonal to each other 
> is the more teachable design. I appreciate how there is an intimate 
> connection between `async` and `throws`, but it seems to me that 
> `async(nonthrowing)` is a highly unintuitive result--_especially_ since the 
> rationale for not outright making `async` a subtype of `throws` is that 
> asynchronous non-throwing functions are a key Cocoa idiom.

Agreed.

> Other than that, I would hope that the primitive functions `beginAsync`, 
> etc., are indeed exposed outside the standard library; agree that their names 
> could use some light bikeshedding :)

+1!

-Chris


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

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Erica Sadun via swift-evolution]

> On Aug 17, 2017, at 7:38 PM, Xiaodi Wu  wrote:
> 
> On Thu, Aug 17, 2017 at 8:25 PM, Erica Sadun  > wrote:
> `repeatElement((), count: 5)` is better than `1 ... 5`, but `Count(3).map({ 
> UIView() })` is far more elegant.  I'd still probably go with an array 
> initializer or `5.elements(of: UIView())`. I don't think I'm overstating how 
> common this pattern is, and `Array(repeating:count:)` feels _close_ but not 
> close enough.
> 
> The first two have the benefit of being currently existing APIs;

I'm pretty sure Count isn't an  existing API. And as I said before, while I 
don't think this rises to stdlib inclusion, it's been a common problem domain 
for people both inside and outside Apple so it deserves a full discussion.

That said, `Count` is neat. It encapsulates an idea in a way that I haven't 
seen in Swift. 

-- E


> they capture the semantics perfectly, as I've argued, and I simply don't see 
> how they are impaired in elegance in any way--certainly not enough to justify 
> a standard library addition to create a third way of spelling the same thing. 
> Ultimately, any user is free to define something like:
> 
> ```
> func * (lhs: Int, rhs: @autoclosure () throws -> T) rethrows -> [T] {
>   return try repeatElement((), count: lhs).map { try rhs() }
> }
> 
> 5 * UIView()
> ```
> 

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

Re: [swift-evolution] [Concurrency] async/await + actors

[Yuta Koshizawa via swift-evolution]

I think we also need `reasync` like `rethrows`.

extension Sequence {
func map(_ transform: (Element) async throws -> T) reasync
rethrows -> [T] { ... }
}

let urls: [URL] = ...
let foos: [Foo] = await try urls.map { await try downloadFoo($0) }

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

Re: [swift-evolution] [Concurrency] async/await + actors

[Matthew Johnson via swift-evolution]

Hi Chris,

This is fantastic!  Thanks for taking the time to write down your thoughts.  
It’s exciting to get a glimpse at the (possible) road ahead.

In the manifesto you talk about restrictions on passing functions across an 
actor message.  You didn’t discuss pure functions, presumably because Swift 
doesn’t have them yet.  I imagine that if (hopefully when) Swift has compiler 
support for verifying pure functions these would also be safe to pass across an 
actor message.  Is that correct?

The async / await proposal looks very nice.  One minor syntax question - did 
you consider `async func` instead of placing `async` in the same syntactic 
location as `throws`?  I can see arguments for both locations and am curious if 
you and Joe had any discussion about this.

One related topic that isn’t discussed is type errors.  Many third party 
libraries use a Result type with typed errors.  Moving to an async / await 
model without also introducing typed errors into Swift would require giving up 
something that is highly valued by many Swift developers.  Maybe Swift 5 is the 
right time to tackle typed errors as well.  I would be happy to help with 
design and drafting a proposal but would need collaborators on the 
implementation side.

Matthew


> On Aug 17, 2017, at 5:25 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Aug 17, 2017, at 3:24 PM, Chris Lattner > > wrote:
>> 
>> Hi all,
>> 
>> As Ted mentioned in his email, it is great to finally kick off discussions 
>> for what concurrency should look like in Swift.  This will surely be an epic 
>> multi-year journey, but it is more important to find the right design than 
>> to get there fast.
>> 
>> I’ve been advocating for a specific model involving async/await and actors 
>> for many years now.  Handwaving only goes so far, so some folks asked me to 
>> write them down to make the discussion more helpful and concrete.  While I 
>> hope these ideas help push the discussion on concurrency forward, this isn’t 
>> in any way meant to cut off other directions: in fact I hope it helps give 
>> proponents of other designs a model to follow: a discussion giving extensive 
>> rationale, combined with the long term story arc to show that the features 
>> fit together.
>> 
>> Anyway, here is the document, I hope it is useful, and I’d love to hear 
>> comments and suggestions for improvement:
>> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 
>> 
> 
> Oh, also, one relatively short term piece of this model is a proposal for 
> adding an async/await model to Swift (in the form of general coroutine 
> support).  Joe Groff and I wrote up a proposal for this, here:
> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 
> 
> 
> and I have a PR with the first half of the implementation here:
> https://github.com/apple/swift/pull/11501 
> 
> 
> The piece that is missing is code generation support.
> 
> -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: Unified libc import (again)

[Taylor Swift via swift-evolution]

Okay I can sense this thread getting derailed so I’ll try to address your
comments one by one.

* stderr should go wherever stdin and stdout go. Since it’d be silly for a
function like `print(_:separator:terminator:)` or `
readLine(strippingNewline:)` to live anywhere but the standard library,
then it stands to reason that the stderr version should also live in the
standard library.

* Foundation is “supposed” to be the core library that does these things,
but this isn’t a good thing. Rationale:

* Foundation is literally an Objective C framework that’s written with
Swift syntax. The classes extend *NSObject*. You use them by *subclassing*
them and overriding open methods. This is patently unswifty. Even parts of
Foundation that look swifty on the outside (like `URL`) are still backed by
NS reference types internally.

* To fix this would require a complete rewrite from the ground up,
that’s more than a straight port from the Objective C framework. Many on
this list have also expressed desire to use this chance to redesign these
APIs. Since we’d basically have to rewrite all of it, any effort to
modernize Foundation is basically writing a new core library.

* Even if a piece of Foundation was rewritten like a real Swift
library, because of the monolith pattern, you still wind up importing a lot
of legacy code that shouldn’t be floating around your project. Using the
file system tools shouldn’t change `String`.

* Foundation’s file system capabilities are really just a class wrapper
around Glibc/Darwin functions. So in a way, Foundation is already a sort of
unified import for C, except it brings in a whole load of Objective C cruft
with it.

* Logically, this means in terms of the XY problem, Foundation is on
the Y side. Foundation is what happens if you rely on Swift’s C interop to
get the job done instead of building a true Swift solution, which would
involve Swift quarterbacking all the nasty system calls, instead of
Glibc/Darwin doing it.

In conclusion,

* What we need is a modern Swift solution for accessing file systems.

* What we have to do right now is leverage Swift’s C interop to use
Glibc/Darwin, while handing imports and platform inconsistencies manually.

* Eventually, the ideal would be for Swift to handle that in Swift, instead
of delegating to a platform-dependent C library, or at least standardize
things so that a swifty Swift library imports the right C library for you,
and exports a platform-independent set of symbols to the user, or a higher
level API.

* Foundation is in many ways the worst of both worlds. It handles the
Glibc/Darwin import for us, but at the cost of an aging framework that runs
against the grain of good Swift design idioms.

On Thu, Aug 17, 2017 at 8:16 PM, Xiaodi Wu  wrote:

> On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift 
> wrote:
>
>> I don’t think the “is this library functionality or standard library
>> functionality” argument is worth having, but if stdout and stdin are
>> first-class citizens in the Swift world, so should stderr.
>>
>> As for bringing Foundation into the discussion, you can’t really talk
>> about Foundation without also talking about the mountains of problems that
>> come with the monolith pattern. But that’s a completely different
>> conversation to be had.
>>
>
> I'm not sure what you're getting at here, but I don't believe you've
> addressed my question, which is: it's been firmly decided that I/O belongs
> in Foundation, and Foundation does in fact offer such facilities--what is
> missing from those facilities, and how can we fill it out?
>
>
> On Thu, Aug 17, 2017 at 7:13 PM, Xiaodi Wu  wrote:
>>
>>> IMO, you’re touching on at least three or four separate topics here.
>>> Daniel touched on several, but just some comments/questions:
>>>
>>> * Standard error output is something that’s been discussed here
>>> previously. I believe the last pitch had something like StandardError being
>>> added to the standard library as a TextOutputStream.
>>>
>>> * Foundation is supposed to be the core library that provides file
>>> system access facilities. What’s missing, and can we add it to Foundation?
>>>
>>> On Thu, Aug 17, 2017 at 17:50 Taylor Swift via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Python’s os.path  is a
 nice abstract model for doing path manipulations. Maybe Swift could get a
 struct like `Filepath` or something on which these operations could be 
 done.

 On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift 
 wrote:

>
>
> On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar <
> daniel_dun...@apple.com> wrote:
>
>>
>> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > I know this has come up before without any action, but having the
>> standard C library be packaged under `Darwin` on OSX and `Glibc` under
>> Linux is something

Re: [swift-evolution] pitch: Unified libc import (again)

[Xiaodi Wu via swift-evolution]

On Thu, Aug 17, 2017 at 22:06 Taylor Swift  wrote:

> Okay I can sense this thread getting derailed so I’ll try to address your
> comments one by one.
>
> * stderr should go wherever stdin and stdout go. Since it’d be silly for
> a function like `print(_:separator:terminator:)` or `
> readLine(strippingNewline:)` to live anywhere but the standard library,
> then it stands to reason that the stderr version should also live in the
> standard library.
>

FWIW, FileHandle.standardInput, FileHandle.standardError,
FileHandle.standardOutput, and FileHandle.nullDevice all live in Foundation.


> * Foundation is “supposed” to be the core library that does these things,
> but this isn’t a good thing. Rationale:
>
> * Foundation is literally an Objective C framework that’s written with
> Swift syntax. The classes extend *NSObject*. You use them by *subclassing*
> them and overriding open methods. This is patently unswifty. Even parts
> of Foundation that look swifty on the outside (like `URL`) are still
> backed by NS reference types internally.
>
> * To fix this would require a complete rewrite from the ground up,
> that’s more than a straight port from the Objective C framework. Many on
> this list have also expressed desire to use this chance to redesign these
> APIs. Since we’d basically have to rewrite all of it, any effort to
> modernize Foundation is basically writing a new core library.
>
> * Even if a piece of Foundation was rewritten like a real Swift
> library, because of the monolith pattern, you still wind up importing a lot
> of legacy code that shouldn’t be floating around your project. Using the
> file system tools shouldn’t change `String`.
>
> * Foundation’s file system capabilities are really just a class wrapper
> around Glibc/Darwin functions. So in a way, Foundation is already a sort of
> unified import for C, except it brings in a whole load of Objective C cruft
> with it.
>
> * Logically, this means in terms of the XY problem, Foundation is on
> the Y side. Foundation is what happens if you rely on Swift’s C interop to
> get the job done instead of building a true Swift solution, which would
> involve Swift quarterbacking all the nasty system calls, instead of
> Glibc/Darwin doing it.
>
> In conclusion,
>
> * What we need is a modern Swift solution for accessing file systems.
>
> * What we have to do right now is leverage Swift’s C interop to use
> Glibc/Darwin, while handing imports and platform inconsistencies manually.
>
> * Eventually, the ideal would be for Swift to handle that in Swift,
> instead of delegating to a platform-dependent C library, or at least
> standardize things so that a swifty Swift library imports the right C
> library for you, and exports a platform-independent set of symbols to the
> user, or a higher level API.
>
> * Foundation is in many ways the worst of both worlds. It handles the
> Glibc/Darwin import for us, but at the cost of an aging framework that runs
> against the grain of good Swift design idioms.
>

As has been stated on this list by the core team, replacing Foundation or
duplicating its functionality is a non-goal of the Swift project. The major
focus of several initial proposals, and a considerable amount of effort on
this list, was precisely to modernize Foundation so as to offer APIs that
conform to Swift guidelines. This work remains ongoing, as there are a
number of Foundation value types that have yet to be designed or
implemented. And there is a whole open source project devoted to Foundation
becoming a viable cross-platform library.

So given these parameters, let's return to what you are talking about: what
is deficient about Swift's core file system APIs, and how would you suggest
that we address these deficiencies, given that the core team has stated
that it is not up for debate that any such changes would be part of
Foundation?


On Thu, Aug 17, 2017 at 8:16 PM, Xiaodi Wu  wrote:
>
>> On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift 
>> wrote:
>>
>>> I don’t think the “is this library functionality or standard library
>>> functionality” argument is worth having, but if stdout and stdin are
>>> first-class citizens in the Swift world, so should stderr.
>>>
>>> As for bringing Foundation into the discussion, you can’t really talk
>>> about Foundation without also talking about the mountains of problems that
>>> come with the monolith pattern. But that’s a completely different
>>> conversation to be had.
>>>
>>
>> I'm not sure what you're getting at here, but I don't believe you've
>> addressed my question, which is: it's been firmly decided that I/O belongs
>> in Foundation, and Foundation does in fact offer such facilities--what is
>> missing from those facilities, and how can we fill it out?
>>
>>
>> On Thu, Aug 17, 2017 at 7:13 PM, Xiaodi Wu  wrote:
>>>
 IMO, you’re touching on at least three or four separate topics here.
 Daniel touched on several, but just some comments/questions:

 * Standard error output is s

Re: [swift-evolution] [Concurrency] async/await + actors

[John McCall via swift-evolution]

> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Aug 17, 2017, at 4:56 PM, Rod Brown > > wrote:
>> 
>> 
>> Hi Chris,
>> 
>> I love what I’ve read so far. I just have one curiosity from my cursory look 
>> over the proposal.
>> 
>> It seems that in transitioning API to an Async Await system, the completion 
>> handler’s type becomes the return type. How would you handle bridging in 
>> Foundation API that already has a return type, eg URLSession returns you 
>> data tasks, and then fires a completion handler. Perhaps I missed something. 
>> I’m sure you could always form a tuple as well, just curious the thoughts on 
>> that.
> 
> Ah, e.g. this one:
> 
> extension URLSession {
> 
> /*
>  * data task convenience methods.  These methods create tasks that
>  * bypass the normal delegate calls for response and data delivery,
>  * and provide a simple cancelable asynchronous interface to receiving
>  * data.  Errors will be returned in the NSURLErrorDomain, 
>  * see .  The delegate, if any, will still be
>  * called for authentication challenges.
>  */
> open func dataTask(with request: URLRequest, completionHandler: @escaping 
> (Data?, URLResponse?, Error?) -> Swift.Void) -> URLSessionDataTask
> }
> 
> Returning a tuple is an option, but probably wouldn’t provide the right 
> semantics.  The URLSessionDataTask is supposed to be available immediately, 
> not just when the completion handler is called.  The most conservative thing 
> to do is to not have the importer change these.  If they should have async 
> semantics, they can be manually handled with an overlay.
> 
> In any case, I wasn’t aware of those APIs, thanks for pointing them out.  I 
> added a mention of this to the proposal!

Arguably these could be converted to return both the formal return value and a 
future.  That would be a rather heroic rule for automatic import, though.

John.

> 
> -Chris
> 
> 
>> 
>> Thanks,
>> 
>> Rod
>> 
>> On 18 Aug 2017, at 8:25 am, Chris Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
 On Aug 17, 2017, at 3:24 PM, Chris Lattner >>> > wrote:
 
 Hi all,
 
 As Ted mentioned in his email, it is great to finally kick off discussions 
 for what concurrency should look like in Swift.  This will surely be an 
 epic multi-year journey, but it is more important to find the right design 
 than to get there fast.
 
 I’ve been advocating for a specific model involving async/await and actors 
 for many years now.  Handwaving only goes so far, so some folks asked me 
 to write them down to make the discussion more helpful and concrete.  
 While I hope these ideas help push the discussion on concurrency forward, 
 this isn’t in any way meant to cut off other directions: in fact I hope it 
 helps give proponents of other designs a model to follow: a discussion 
 giving extensive rationale, combined with the long term story arc to show 
 that the features fit together.
 
 Anyway, here is the document, I hope it is useful, and I’d love to hear 
 comments and suggestions for improvement:
 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 
 
>>> 
>>> Oh, also, one relatively short term piece of this model is a proposal for 
>>> adding an async/await model to Swift (in the form of general coroutine 
>>> support).  Joe Groff and I wrote up a proposal for this, here:
>>> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 
>>> 
>>> 
>>> and I have a PR with the first half of the implementation here:
>>> https://github.com/apple/swift/pull/11501 
>>> 
>>> 
>>> The piece that is missing is code generation support.
>>> 
>>> -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] [Pitch] Improve `init(repeating:count)`

[Taylor Swift via swift-evolution]

On Thu, Aug 17, 2017 at 9:06 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu  wrote:
>
> On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun  wrote:
>
>> What people are doing is taking a real set of values (1, 2, 3, 4, 5, for
>> example), then discarding them via `_ in`, which is different from `Void ->
>> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,
>>  UIColor.red, { x: Int in x^x }). There are too many semantic shifts away
>> from "I would like to collect the execution of this closure n times" for it
>> to sit comfortably.
>>
>
> What arguments might help to alleviate this discomfort? Clearly, functions
> exist that can map this delightfully heterogeneous domain to some sort of
> range that the user wants. Would you feel better if we wrote instead the
> following?
>
> ```
> repeatElement((), count: 5).map { UIView() }
> ```
>
>
> My favorite solution is the array initializer. Something along the lines
> of `Array(count n: Int, generator: () -> T)`. I'm not sure it _quite_
> reaches standard library but I think it is a solid way to say "produce a
> collection with a generator run n times". It's a common  task. I was asking
> around about this, and found that a lot of us who work with both macOS and
> iOS and want to stress test interfaces do this very often. Other use cases
> include "give me n random numbers", "give me n records from this database",
> etc. along similar lines.
>
> The difference between this and the current `Array(repeating:count:)`
> initializer is switching the arguments and using a trailing closure  (or an
> autoclosure) rather than a set value. That API was designed without the
> possibility that you might want to repeat a generator, so there's a bit of
> linguistic turbulence.
>
> -- E
>
>
To me at least, this is a very i-Centric complaint, since I can barely
remember the last time I needed something like this for anything that
didn’t involve UIKit. What you’re asking for is API sugar for generating
reference types with less typing. The problem is it’s hugely disruptive to
user’s mental model of how Swift operates, to say the least. When I read a
function signature like Array.init(count:object:) or whatever, I expect
that if a referency type is passed to the object parameter, the *pointer*
gets copied `count` times, and the reference count incremented accordingly.
I don’t expect the object itself to get deepcopied. That’s why the use of
@autoclosure is strongly recommended against
,
and why it only appears in things relating to debugging like
assert(condition:message:file:line:), which are mentally separated from the
rest of Swift.

Doing this with a function is less disruptive, but if you ask me, it
expands API surface area without offering any real benefit. As people have
pointed out, we already have a perfectly good idiom in (0 ..< n).map{ _ in
UIView() }. I never understood why certain people complain about
“discarding the domain”, but have no problem writing things like this:

for _ in 0 ..< n
{
//
}

If you’re truly allergic to map{ _ in UIView() }, might I suggest the
following:

var array:[UIView] = []
array.reserveCapacity(n)
for _ in 0 ..< n
{
{ array.append(UIView()) }()
}

That’s really all an array initializer that takes a block is really doing.
Or just use map.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] pitch: Unified libc import (again)

[Taylor Swift via swift-evolution]

On Thu, Aug 17, 2017 at 11:19 PM, Xiaodi Wu  wrote:

> On Thu, Aug 17, 2017 at 22:06 Taylor Swift  wrote:
>
>> Okay I can sense this thread getting derailed so I’ll try to address your
>> comments one by one.
>>
>> * stderr should go wherever stdin and stdout go. Since it’d be silly for
>> a function like `print(_:separator:terminator:)` or `
>> readLine(strippingNewline:)` to live anywhere but the standard library,
>> then it stands to reason that the stderr version should also live in the
>> standard library.
>>
>
> FWIW, FileHandle.standardInput, FileHandle.standardError,
> FileHandle.standardOutput, and FileHandle.nullDevice all live in Foundation.
>

Yet, we have print and readLine, but no printError.


>
>
>> * Foundation is “supposed” to be the core library that does these things,
>> but this isn’t a good thing. Rationale:
>>
>> * Foundation is literally an Objective C framework that’s written
>> with Swift syntax. The classes extend *NSObject*. You use them by
>> *subclassing* them and overriding open methods. This is patently
>> unswifty. Even parts of Foundation that look swifty on the outside (like `
>> URL`) are still backed by NS reference types internally.
>>
>> * To fix this would require a complete rewrite from the ground up,
>> that’s more than a straight port from the Objective C framework. Many on
>> this list have also expressed desire to use this chance to redesign these
>> APIs. Since we’d basically have to rewrite all of it, any effort to
>> modernize Foundation is basically writing a new core library.
>>
>> * Even if a piece of Foundation was rewritten like a real Swift
>> library, because of the monolith pattern, you still wind up importing a lot
>> of legacy code that shouldn’t be floating around your project. Using the
>> file system tools shouldn’t change `String`.
>>
>> * Foundation’s file system capabilities are really just a class wrapper
>> around Glibc/Darwin functions. So in a way, Foundation is already a sort of
>> unified import for C, except it brings in a whole load of Objective C cruft
>> with it.
>>
>> * Logically, this means in terms of the XY problem, Foundation is on
>> the Y side. Foundation is what happens if you rely on Swift’s C interop to
>> get the job done instead of building a true Swift solution, which would
>> involve Swift quarterbacking all the nasty system calls, instead of
>> Glibc/Darwin doing it.
>>
>> In conclusion,
>>
>> * What we need is a modern Swift solution for accessing file systems.
>>
>> * What we have to do right now is leverage Swift’s C interop to use
>> Glibc/Darwin, while handing imports and platform inconsistencies manually.
>>
>> * Eventually, the ideal would be for Swift to handle that in Swift,
>> instead of delegating to a platform-dependent C library, or at least
>> standardize things so that a swifty Swift library imports the right C
>> library for you, and exports a platform-independent set of symbols to the
>> user, or a higher level API.
>>
>> * Foundation is in many ways the worst of both worlds. It handles the
>> Glibc/Darwin import for us, but at the cost of an aging framework that runs
>> against the grain of good Swift design idioms.
>>
>
> As has been stated on this list by the core team, replacing Foundation or
> duplicating its functionality is a non-goal of the Swift project. The major
> focus of several initial proposals, and a considerable amount of effort on
> this list, was precisely to modernize Foundation so as to offer APIs that
> conform to Swift guidelines. This work remains ongoing, as there are a
> number of Foundation value types that have yet to be designed or
> implemented. And there is a whole open source project devoted to Foundation
> becoming a viable cross-platform library.
>
> So given these parameters, let's return to what you are talking about:
> what is deficient about Swift's core file system APIs, and how would you
> suggest that we address these deficiencies, given that the core team has
> stated that it is not up for debate that any such changes would be part of
> Foundation?
>

This probably isn’t the answer you were looking for, but, as explained,
*all* of it is deficient, so long as you still have to subclass FileManager
and catch CocoaErrors. The problem with Foundation is it tries to offer
core library features and support bridging to Cocoa types at the same time.
Those two goals aren’t very compatible. That’s why there’s such a day and
night difference between stdlib and “pure swift” code, and Foundation code.

So, within the parameters, I would suggest

* rewriting the Foundation file system API types as value and protocol
types, retire the delegate-driven pattern, and *drop* ReferenceConvertible
conformance.

* value types should be trivial value types, with the possible
exception of file streams which need to be closed.

* separate it as much as possible from other Foundation types, so as to
help disentangle the library from NSNumber and Date.

* inseparab

Re: [swift-evolution] [Concurrency] async/await + actors

[Zach Waldowski via swift-evolution]

On Thu, Aug 17, 2017, at 10:04 PM, Chris Lattner via swift-evolution wrote:> 
That said, I don’t feel like I have enough data to have a strong
> opinion on it.  The missing link for me is exactly how pervasive the
> non-throwing cocoa completion handlers are.  If it turns out that
> people would have to confront "async(nonthrowing)” in practice (as
> opposed to being an obscure corner that the compiler implementers have
> to care about) then it is probably the wrong design.
It may be helpful to look at data points outside of Cocoa. We use a
Future framework that distinguishes between plain old `Future` and
`Future>`. In a back-of-the-hand calculation, about 10% of our
futures don’t use  Result. It’s rarer, but it is useful; it aligns well
with the Error manifesto’s notion of a domain failures.
I think I’m overall in favor of an implicitly throwing model, though.
Not only is it cleaner, but it’ll simplify all sorts of abstractions.
f.ex: In our use of this framework, collecting up errors or
cancellations for an array of tasks is a perennial problem. `Future`
(and similarly `async -> T?`) can be plenty useful, but I’m not sure
they pull their weight enough to deserve occupying the best syntax.
(Huge, huge +1 to the whole shebang, though. Let’s just do this!!!)

Sincerely,
  Zachary Waldowski
  z...@waldowski.me


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

Re: [swift-evolution] [Concurrency] async/await + actors

[Yuta Koshizawa via swift-evolution]

I think we also need `reasync` like `rethrows`.


Sorry, I found it was referred in "rethrows could be generalized to support
potentially async operations".

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

Re: [swift-evolution] [Concurrency] async/await + actors

[Chris Lattner via swift-evolution]

> On Aug 17, 2017, at 7:28 PM, Yuta Koshizawa  wrote:
> 
> I think we also need `reasync` like `rethrows`.
> 
> extension Sequence {
> func map(_ transform: (Element) async throws -> T) reasync 
> rethrows -> [T] { ... }
> }
> 
> let urls: [URL] = ...
> let foos: [Foo] = await try urls.map { await try downloadFoo($0) }

That is mentioned in Potential Future Directions at the end.  It can certainly 
be done, but it comes with tradeoffs, and it seems better to settle on the 
design the basic proposal first.

-Chris


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

Re: [swift-evolution] [Concurrency] async/await + actors

[Chris Lattner via swift-evolution]

On Aug 17, 2017, at 7:39 PM, Matthew Johnson  wrote:
> This is fantastic!  Thanks for taking the time to write down your thoughts.  
> It’s exciting to get a glimpse at the (possible) road ahead.

Happy to.

> In the manifesto you talk about restrictions on passing functions across an 
> actor message.  You didn’t discuss pure functions, presumably because Swift 
> doesn’t have them yet.  I imagine that if (hopefully when) Swift has compiler 
> support for verifying pure functions these would also be safe to pass across 
> an actor message.  Is that correct?

Correct.  The proposal is specifically/intentionally designed to be light on 
type system additions, but there are many that could make it better in various 
ways.  The logic for this approach is that I expect *a lot* of people will be 
writing mostly straight-forward concurrent code, and that goal is harmed by 
presenting significant type system hurdles for them to jump over, because that 
implies a higher learning curve.

This is why the proposal doesn’t focus on a provably memory safe system: If 
someone slaps “ValueSemantical” on a type that doesn’t obey, they will break 
the invariants of the system.  There are lots of ways to solve that problem 
(e.g. the capabilities system in Pony) but it introduces a steep learning curve.

I haven’t thought a lot about practically getting pure functions into Swift, 
because it wasn’t clear what problems it would solve (which couldn’t be solved 
another way).  You’re right though that this could be an interesting motivator. 

> The async / await proposal looks very nice.  One minor syntax question - did 
> you consider `async func` instead of placing `async` in the same syntactic 
> location as `throws`?  I can see arguments for both locations and am curious 
> if you and Joe had any discussion about this.

I don’t think that Joe and I discussed that option.  We discussed several other 
designs (including a more C# like model where async functions implicitly return 
Future), but he convinced me that it is better to focus language support on the 
coroutine transformation (leaving futures and other APIs to the library), then 
you pretty quickly want async to work the same way as throws (including marking 
etc).  Once it works the same way, it follows that the syntax should be similar 
- particularly if async ends up implying throws.

That said, if you have a strong argument for why this is perhaps the wrong 
choice, lets talk about it!

-Chris

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

Re: [swift-evolution] typed throws

[Chris Lattner via swift-evolution]

Splitting this off into its own thread:

> On Aug 17, 2017, at 7:39 PM, Matthew Johnson  wrote:
> One related topic that isn’t discussed is type errors.  Many third party 
> libraries use a Result type with typed errors.  Moving to an async / await 
> model without also introducing typed errors into Swift would require giving 
> up something that is highly valued by many Swift developers.  Maybe Swift 5 
> is the right time to tackle typed errors as well.  I would be happy to help 
> with design and drafting a proposal but would need collaborators on the 
> implementation side.

Typed throws is something we need to settle one way or the other, and I agree 
it would be nice to do that in the Swift 5 cycle.

For the purposes of this sub-discussion, I think there are three kinds of code 
to think about: 
1) large scale API like Cocoa which evolve (adding significant functionality) 
over the course of many years and can’t break clients. 
2) the public API of shared swiftpm packages, whose lifecycle may rise and fall 
- being obsoleted and replaced by better packages if they encounter a design 
problem.  
3) internal APIs and applications, which are easy to change because the 
implementations and clients of the APIs are owned by the same people.

These each have different sorts of concerns, and we hope that something can 
start out as #3 but work its way up the stack gracefully.

Here is where I think things stand on it:
- There is consensus that untyped throws is the right thing for a large scale 
API like Cocoa.  NSError is effectively proven here.  Even if typed throws is 
introduced, Apple is unlikely to adopt it in their APIs for this reason.
- There is consensus that untyped throws is the right default for people to 
reach for for public package (#2).
- There is consensus that Java and other systems that encourage lists of throws 
error types lead to problematic APIs for a variety of reasons.
- There is disagreement about whether internal APIs (#3) should use it.  It 
seems perfect to be able to write exhaustive catches in this situation, since 
everything in knowable. OTOH, this could encourage abuse of error handling in 
cases where you really should return an enum instead of using throws.
- Some people are concerned that introducing typed throws would cause people to 
reach for it instead of using untyped throws for public package APIs.
- Some people think that while it might be useful in some narrow cases, the 
utility isn’t high enough to justify making the language more complex 
(complexity that would intrude on the APIs of result types, futures, etc)

I’m sure there are other points in the discussion that I’m forgetting.

One thing that I’m personally very concerned about is in the systems 
programming domain.  Systems code is sort of the classic example of code that 
is low-level enough and finely specified enough that there are lots of knowable 
things, including the failure modes.  Beyond expressivity though, our current 
model involves boxing thrown values into an Error existential, something that 
forces an implicit memory allocation when the value is large.  Unless this is 
fixed, I’m very concerned that we’ll end up with a situation where certain 
kinds of systems code (i.e., that which cares about real time guarantees) will 
not be able to use error handling at all.  

JohnMC has some ideas on how to change code generation for ‘throws’ to avoid 
this problem, but I don’t understand his ideas enough to know if they are 
practical and likely to happen or not.

-Chris


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

Re: [swift-evolution] typed throws

[John McCall via swift-evolution]

> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution 
>  wrote:
> Splitting this off into its own thread:
> 
>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson  wrote:
>> One related topic that isn’t discussed is type errors.  Many third party 
>> libraries use a Result type with typed errors.  Moving to an async / await 
>> model without also introducing typed errors into Swift would require giving 
>> up something that is highly valued by many Swift developers.  Maybe Swift 5 
>> is the right time to tackle typed errors as well.  I would be happy to help 
>> with design and drafting a proposal but would need collaborators on the 
>> implementation side.
> 
> Typed throws is something we need to settle one way or the other, and I agree 
> it would be nice to do that in the Swift 5 cycle.
> 
> For the purposes of this sub-discussion, I think there are three kinds of 
> code to think about: 
> 1) large scale API like Cocoa which evolve (adding significant functionality) 
> over the course of many years and can’t break clients. 
> 2) the public API of shared swiftpm packages, whose lifecycle may rise and 
> fall - being obsoleted and replaced by better packages if they encounter a 
> design problem.  
> 3) internal APIs and applications, which are easy to change because the 
> implementations and clients of the APIs are owned by the same people.
> 
> These each have different sorts of concerns, and we hope that something can 
> start out as #3 but work its way up the stack gracefully.
> 
> Here is where I think things stand on it:
> - There is consensus that untyped throws is the right thing for a large scale 
> API like Cocoa.  NSError is effectively proven here.  Even if typed throws is 
> introduced, Apple is unlikely to adopt it in their APIs for this reason.
> - There is consensus that untyped throws is the right default for people to 
> reach for for public package (#2).
> - There is consensus that Java and other systems that encourage lists of 
> throws error types lead to problematic APIs for a variety of reasons.
> - There is disagreement about whether internal APIs (#3) should use it.  It 
> seems perfect to be able to write exhaustive catches in this situation, since 
> everything in knowable. OTOH, this could encourage abuse of error handling in 
> cases where you really should return an enum instead of using throws.
> - Some people are concerned that introducing typed throws would cause people 
> to reach for it instead of using untyped throws for public package APIs.

Even for non-public code.  The only practical merit of typed throws I have ever 
seen someone demonstrate is that it would let them use contextual lookup in a 
throw or catch.  People always say "I'll be able to exhaustively switch over my 
errors", and then I ask them to show me where they want to do that, and they 
show me something that just logs the error, which of course does not require 
typed throws.  Every.  Single.  Time.

Sometimes we then go on to have a conversation about wrapping errors in other 
error types, and that can be interesting, but now we're talking about adding a 
big, messy feature just to get "safety" guarantees for a fairly minor need.

Programmers often have an instinct to obsess over error taxonomies that is very 
rarely directed at solving any real problem; it is just self-imposed busy-work.

> - Some people think that while it might be useful in some narrow cases, the 
> utility isn’t high enough to justify making the language more complex 
> (complexity that would intrude on the APIs of result types, futures, etc)
> 
> I’m sure there are other points in the discussion that I’m forgetting.
> 
> One thing that I’m personally very concerned about is in the systems 
> programming domain.  Systems code is sort of the classic example of code that 
> is low-level enough and finely specified enough that there are lots of 
> knowable things, including the failure modes.

Here we are using "systems" to mean "embedded systems and kernels".  And 
frankly even a kernel is a large enough system that they don't want to 
exhaustively switch over failures; they just want the static guarantees that go 
along with a constrained error type.

> Beyond expressivity though, our current model involves boxing thrown values 
> into an Error existential, something that forces an implicit memory 
> allocation when the value is large.  Unless this is fixed, I’m very concerned 
> that we’ll end up with a situation where certain kinds of systems code (i.e., 
> that which cares about real time guarantees) will not be able to use error 
> handling at all.  
> 
> JohnMC has some ideas on how to change code generation for ‘throws’ to avoid 
> this problem, but I don’t understand his ideas enough to know if they are 
> practical and likely to happen or not.

Essentially, you give Error a tagged-pointer representation to allow 
payload-less errors on non-generic error types to be allocated globally, and 
then you can (1) tell

Re: [swift-evolution] [Concurrency] async/await + actors

[Brent Royal-Gordon via swift-evolution]

> On Aug 17, 2017, at 3:24 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Anyway, here is the document, I hope it is useful, and I’d love to hear 
> comments and suggestions for improvement:
> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782


I think you're selecting the right approaches and nailing many of the details, 
but I have a lot of questions and thoughts. A few notes before I start:

* I only did one pass through this, so I probably missed or misunderstood some 
things. Sorry.
* I think the document may have evolved since I started reading, so some of 
this may be out of date.
* I haven't yet read the rest of the thread—this email is already long enough.
* I have a lot of experience with Cocoa-style callback-based concurrency, a 
little bit (unfortunately) with Javascript Promises, and basically none with 
async/await. I've never worked with a language that formally supported actors, 
although I've used similar patterns in Swift and Objective-C.

# async/await

I like the choice of async/await, and I agree that it's pretty much where 
mainstream languages have ended up. But there are a few things you seem to 
gloss over. You may simply have decided those details were too specific for 
such a sweeping manifesto, but I wanted to point them out in case you missed 
them.

## Dispatching back to the original queue

You correctly identify one of the problems with completion blocks as being that 
you can't tell which queue the completion will run on, but I don't think you 
actually discuss a solution to that in the async/await section. Do you think 
async/await can solve that? How? Does GCD even have the primitives needed? 
(`dispatch_get_current_queue()` was deprecated long ago and has never been 
available in Swift.)

Or do you see this as the province of actors? If so, how does that work? Does 
every piece of code inherently run inside one actor or another? Or does the 
concurrency system only get you on the right queue if you explicitly use 
actors? Can arbitrary classes "belong to" an actor, so that e.g. callbacks into 
a view controller inherently go to the main queue/actor?

(If you *do* need actors to get sensible queue behavior, I'm not the biggest 
fan of that; we could really use that kind of thing in many, many places that 
aren't actors.)

## Delayed `await`

Most languages I've seen with async/await seem to allow you to delay the 
`await` call to do parallel work, but I don't see anything similar in your 
examples. Do you envision that happening? What's the type of the intermediate 
value, and what can you do with it? Can you return it to a caller?

## Error handling

Do you imagine that `throws` and `async` would be orthogonal to one another? If 
so, I suspect that we could benefit from adding typed `throws` and making 
`Never` a subtype of `Error`, which would allow us to handle this through the 
generics system.

(Also, I notice that a fire-and-forget message can be thought of as an `async` 
method returning `Never`, even though the computation *does* terminate 
eventually. I'm not sure how to handle that, though)

## Legacy interop

Another big topic I don't see discussed much is interop with existing APIs. I 
think it's really important that we expose existing completion-based Cocoa APIs 
with async/await. This ideally means automatic translation, much like we did 
with errors. Moreover, I think we probably need to apply this translation to 
Swift 4 libraries when you're using them from Swift 5+ (assuming this makes 
Swift 5).

## Implementation

The legacy interop requirement tends to lean towards a particular model where 
`await` calls are literally translated into completion blocks passed to the 
original function. But there are other options, like generating a wrapper that 
translates calls with completions into calls returning promises, and `await` is 
translated into a promise call. Or we could do proper continuations, but as I 
understand it, that has impacts further up the call stack, so I'm not sure how 
you'd make that work when some of the calls on the stack are from other 
languages.

# Actors

I haven't used actors before, but they look like a really promising model, much 
better than Go's channels. I do have a couple of concerns, though.

## Interop, again

There are a few actor-like types in the frameworks—the WatchKit UI classes are 
the clearest examples—but I'm not quite worried about them. What I'm more 
concerned with is how this might interoperate with Cocoa delegates. Certain 
APIs, like `URLSession`, either take a delegate and queue or take a delegate 
and call it on arbitrary queues; these seem like excellent candidates for 
actor-ization, especially when the calls are all one-way. But that means we 
need to be able to create "actor protocols" or something. It's also hard to 
square with the common Cocoa (anti?)pattern of implementing delegate protocols 
on a controller—you would want that controller to also be an actor.

I don't have any

Re: [swift-evolution] pitch: Unified libc import (again)

[Brent Royal-Gordon via swift-evolution]

> On Aug 17, 2017, at 8:20 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> * stderr should go wherever stdin and stdout go. Since it’d be silly for a 
> function like `print(_:separator:terminator:)` or 
> `readLine(strippingNewline:)` to live anywhere but the standard library, then 
> it stands to reason that the stderr version should also live in the standard 
> library.
> 
> FWIW, FileHandle.standardInput, FileHandle.standardError, 
> FileHandle.standardOutput, and FileHandle.nullDevice all live in Foundation.

And, since they're read-only, are fundamentally incompatible with 
`print(…to:)`, which requires its `output` parameter to be passed `inout`.

-- 
Brent Royal-Gordon
Architechies

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

[swift-evolution] [Concurrency] async/await + actors: cancellation

[Jan Tuitman via swift-evolution]

Hi,


After reading Chris Lattners proposal for async/await I wonder if the proposal 
has any way to cancel outstanding tasks.

I saw these two:

@IBAction func buttonDidClick(sender:AnyObject) {
  // 1
  beginAsync {
// 2
let image = await processImage()
imageView.image = image
  }
  // 3
} 


And:

/// Shut down the current coroutine and give its memory back to the
/// shareholders.
func abandon() async -> Never {
  await suspendAsync { _ = $0 }
}


Now, if I understand this correctly, the second thing is abandoning the task 
from the context of the task by basically preventing the implicit callback of 
abandon() to ever be called.

But I don't see any way how the beginAsync {} block can be canceled after a 
certain amount of time by the synchronous thread/context that is running at 
location //3

shouldn't beginAsync return something which can be checked if the block passed 
in to it is finished/ waiting/ ...? and which has a method to cancel it?
I know Thread.cancel (which existed in some programming languages) is evil 
because you never know where it stops, but it seems strange to me, that there 
is no way to communicate with the running process in //2.

Then there is this example:

func processImageData() async throws -> Image {
  startProgressBar()
  defer {
// This will be called when error is thrown, when all operations
// complete and a result is returned, or when the coroutine is
// abandoned. We don't want to leave the progress bar animating if
// work has stopped.
stopProgressBar()
  }

let dataResource  = try await loadWebResource("dataprofile.txt")
  let imageResource = try await loadWebResource("imagedata.dat")
  do {
let imageTmp= try await decodeImage(dataResource, imageResource)
  } catch _ as CorruptedImage {
// Give up hope now.
await abandon()
  }
  return try await dewarpAndCleanupImage(imageTmp)
}


this seems to wrap other asynchronous functions in a new async function so it 
can add the defer logic and abandon logic, but this seems to me only adding 
more checking of the spawned process and thus not sufficient enough to deal 
with an external reason in location //3 (for example the process running //3 
receives an event that the app is about to be quitted). 

so I am a bit confused here, am I missing something? How would //2 be canceled 
from location //3, or how would //3 trigger an abandoment inside //2 ?

Jan Tuitman

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