[swift-evolution] [Pitch] improve import sentence: allow import specific nested types

[Cao Jiannan via swift-evolution]

Now Swift 3 allow us import specific enum/struct from module, but it only allow 
us import top-level declaration.

For example:

in MyFoudnation framework:

public struct Time {
public struct DateOnly {}
}

in App target:
I can only
 
import struct MyFoundation.Time

But I cannot 

import struct MyFoundation.Time.DateOnly

So allow developer import nested types

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

Re: [swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

[Jay Abbott via swift-evolution]

Yes - this is totally confusing. CharacterSet and Set are
completely different things with different semantics.

I don't know the history, but is CharacterSet simply to have a Swift
equivalent of NSCharacterSet? That seems to be what it is, but since Swift
redefined characters in a better way, this should be removed or called
something else to avoid confusion. You shouldn't have to qualify what you
mean by 'character' in a type name because it diverges from the definition
in the rest of the language.

On Thu, 29 Sep 2016 at 04:48 Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, Sep 28, 2016 at 10:34 PM, Xiaodi Wu  wrote:
>
>> On Wed, Sep 28, 2016 at 10:23 PM, Charles Srstka via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Sep 28, 2016, at 9:57 PM, Erica Sadun via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> D'erp. I missed that. And that's an unambiguous answer.
>>>
>>> So let me move on to part B of the pitch: I think CharacterSets are
>>> broken.
>>>
>>> Xiaodi Wu: "isn't the problem you're presenting really an argument that
>>> the type should be fleshed out to handle characters (grapheme clusters)
>>> containing more than one Unicode scalar?"
>>>
>>>
>>> It seems that it already does handle such characters:
>>>
>>> (done in Objective-C so we can log the length of the range as a count of
>>> UTF-16 code units)
>>>
>>> #import 
>>>
>>> int main(int argc, char *argv[]) {
>>> @autoreleasepool {
>>> NSCharacterSet *bikeSet = [NSCharacterSet
>>> characterSetWithCharactersInString:@""];
>>> NSString *str = @"foobar";
>>>
>>>
>>> NSRange range = [str rangeOfCharacterFromSet:bikeSet];
>>>
>>>
>>> NSLog(@"location: %lu length: %lu", range.location, range.length
>>> );
>>> }
>>> }
>>>
>>> - - - - - - -
>>>
>>> *2016-09-28 22:20:00.622471 test[15577:2433912] location: 3 length: 2*
>>> *Program ended with exit code: 0*
>>>
>>> - - - - - - -
>>>
>>> As we can see, the character from the set is recognized as consisting of
>>> two code units. There are a few bugs in the system, though. See the
>>> cocoa-dev thread “Where is my bicycle?” from about a year ago:
>>> http://prod.lists.apple.com/archives/cocoa-dev/2015/Apr/msg00074.html
>>>
>>
>> The bike emoji might be two code units, but it is one Unicode scalar
>> (U+1F6B2). However, the Canadian flag emoji, for instance, is two Unicode
>> scalars (U+1F1E8 U+1F1E6) but nonetheless one character.
>>
>
> To illustrate in code how CharacterSet doesn't actually handle characters
> made up of multiple Unicode scalars:
>
> ```
> import Foundation
>
> let str1 = ""
> let first = CharacterSet(charactersIn: str1) // this actually crashes
> corelibs-foundation
> let str2 = ""
> let second = CharacterSet(charactersIn: str2)
> let intersection = first.intersection(second)
> print(intersection.isEmpty)
> // actual output: false
> // obviously, if we were really dealing with characters, the intersection
> should be empty
> ```
>
>
>> Charles
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Conditional conformances

[Russ Bishop via swift-evolution]

> On Sep 26, 2016, at 5:18 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Conditional conformances
> 
>  
> Disallow
>  overlapping conformances
> 
> With conditional conformances, it is possible to express that a given generic 
> type can conform to the same protocol in two different ways, depending on the 
> capabilities of its type arguments. For example:
> 
> …
> 
> Note that, for an arbitrary type T, there are four potential answers to the 
> question of whether SomeWrapper conforms to Equatable:
> 
> No, it does not conform because T is neither Equatable nor HasIdentity.
> Yes, it conforms via the first extension of SomeWrapper because T conforms to 
> Equatable.
> Yes, it conforms via the second extension of SomeWrapper because T conforms 
> to HasIdentity.
> Ambiguity, because T conforms to both Equatable and HasIdentity.
> It is due to the possibility of #4 occurring that we refer to the two 
> conditional conformances in the example as overlapping. There are designs 
> that would allow one to address the ambiguity
> 
> …
> 
> For these reasons, this proposal bans overlapping conformances entirely. 

What other designs were considered and rejected? It seems like some kind of 
escape hatch would be preferred if you happen to get into this situation, 
though you make some really good points about the pitfalls.

Just to clarify when you say “bans” do you mean if Wrapped: Equatable & 
HasIdentity then SomeWrapper is not Equatable, or do you mean you get a compile 
error because there are two constrained conformances SomeWrapper: Equatable? 
What would be the problem with allowing multiple conformances to Equatable so 
long as the constraints are disjoint or the concrete type only adopts one of 
the available protocols?

>  
> Implied
>  conditional conformances
> 
> Stating conformance to a protocol implicitly states conformances to any of 
> the protocols that it inherits. This is the case in Swift today, although 
> most developers likely don't realize the rules it follows. For example:
> 
> protocol P { }
> protocol Q : P { }
> protocol R : P { }
> 
> struct X1 { }
> struct X2 { }
> struct X3 { }
> 
> extension X1: Q { }  // implies conformance to P
> 
> extension X2: Q { }  // would imply conformance to P, but...
> extension X2: P { }  // explicitly-stated conformance to P "wins"
> 
> extension X3: Q { }  // implies conformance to P
> extension X3: R { }  // also implies conformance to P
>  // one will "win"; which is unspecified
On X2 you’re declaring a redundant conformance to P but any protocol extensions 
will prefer Q and the compiler won’t let you redefine any members so you’ll 
have an incomplete conformance. Any explicit conformances (on the type or in 
extensions) are preferred over the defaults from the protocol extension, but 
that’s not new. I must be missing something, how would this be visible in Swift 
3?

On X3, multiple implementations in protocol extensions are errors today and the 
resolution is to provide an explicit implementation on X3.




> With conditional conformances, the question of which extension "wins" the 
> implied conformance begins to matter, because the extensions might have 
> different constraints on them. For example:
> 
> struct X4 { }
> 
> extension X4: Q where T: Q { }  // implies conformance to P
> extension X4: R where T: R { }  // error: implies overlapping conformance to P
> Both of these constrained extensions imply a conformance to P, but the actual 
> P implied conformances to P are overlapping and, therefore, result in an 
> error.
> 
If the related P conformance were inherited from conformance to Q or R then the 
rules would (IMHO) make more sense. Wouldn’t the extra rule you need simply be 
that either Q or R must provide a complete conformance to P (no mix-n-match)? 

If T implements Q & P why not just ignore T: P which means the X4: R extension 
is no longer relevant. 

It seems like the tricky case is T: P and the same question applies - why not 
just ignore the extensions (X4 in that scenario doesn’t implement Q, R, or 
P). 


Not allowing ambiguity seems like it solves the “which one” problem and 
requiring an extension to provide the entire implementation (no mix-n-match) 
cuts down on the cleverness problem.




> However, in cases where there is a reasonable ordering between the two 
> constrained extensions (i.e., one is more specialized than the other), the 
> less specialized constrained extension should "win" the implied conformance. 
> Continuing the example from above:
> 
> protocol S: R { }
> 
> struct X5 { }
> 
> extension X5: R where T: R { }  // "wins" implied conformance to P, because
> extension X5: S where T: S { }  // the extension where "T: S" is more 

Re: [swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

[Xiaodi Wu via swift-evolution]

On Wed, Sep 28, 2016 at 10:34 PM, Xiaodi Wu  wrote:

> On Wed, Sep 28, 2016 at 10:23 PM, Charles Srstka via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Sep 28, 2016, at 9:57 PM, Erica Sadun via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> D'erp. I missed that. And that's an unambiguous answer.
>>
>> So let me move on to part B of the pitch: I think CharacterSets are
>> broken.
>>
>> Xiaodi Wu: "isn't the problem you're presenting really an argument that
>> the type should be fleshed out to handle characters (grapheme clusters)
>> containing more than one Unicode scalar?"
>>
>>
>> It seems that it already does handle such characters:
>>
>> (done in Objective-C so we can log the length of the range as a count of
>> UTF-16 code units)
>>
>> #import 
>>
>> int main(int argc, char *argv[]) {
>> @autoreleasepool {
>> NSCharacterSet *bikeSet = [NSCharacterSet
>> characterSetWithCharactersInString:@""];
>> NSString *str = @"foobar";
>>
>>
>> NSRange range = [str rangeOfCharacterFromSet:bikeSet];
>>
>>
>> NSLog(@"location: %lu length: %lu", range.location, range.length
>> );
>> }
>> }
>>
>> - - - - - - -
>>
>> *2016-09-28 22:20:00.622471 test[15577:2433912] location: 3 length: 2*
>> *Program ended with exit code: 0*
>>
>> - - - - - - -
>>
>> As we can see, the character from the set is recognized as consisting of
>> two code units. There are a few bugs in the system, though. See the
>> cocoa-dev thread “Where is my bicycle?” from about a year ago:
>> http://prod.lists.apple.com/archives/cocoa-dev/2015/Apr/msg00074.html
>>
>
> The bike emoji might be two code units, but it is one Unicode scalar
> (U+1F6B2). However, the Canadian flag emoji, for instance, is two Unicode
> scalars (U+1F1E8 U+1F1E6) but nonetheless one character.
>

To illustrate in code how CharacterSet doesn't actually handle characters
made up of multiple Unicode scalars:

```
import Foundation

let str1 = ""
let first = CharacterSet(charactersIn: str1) // this actually crashes
corelibs-foundation
let str2 = ""
let second = CharacterSet(charactersIn: str2)
let intersection = first.intersection(second)
print(intersection.isEmpty)
// actual output: false
// obviously, if we were really dealing with characters, the intersection
should be empty
```


> Charles
>>
>>
>> ___
>> 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: Renaming CharacterSet to UnicodeScalarSet

[Xiaodi Wu via swift-evolution]

On Wed, Sep 28, 2016 at 10:23 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> On Sep 28, 2016, at 9:57 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> D'erp. I missed that. And that's an unambiguous answer.
>
> So let me move on to part B of the pitch: I think CharacterSets are broken.
>
> Xiaodi Wu: "isn't the problem you're presenting really an argument that
> the type should be fleshed out to handle characters (grapheme clusters)
> containing more than one Unicode scalar?"
>
>
> It seems that it already does handle such characters:
>
> (done in Objective-C so we can log the length of the range as a count of
> UTF-16 code units)
>
> #import 
>
> int main(int argc, char *argv[]) {
> @autoreleasepool {
> NSCharacterSet *bikeSet = [NSCharacterSet
> characterSetWithCharactersInString:@""];
> NSString *str = @"foobar";
>
>
> NSRange range = [str rangeOfCharacterFromSet:bikeSet];
>
>
> NSLog(@"location: %lu length: %lu", range.location, range.length);
> }
> }
>
> - - - - - - -
>
> *2016-09-28 22:20:00.622471 test[15577:2433912] location: 3 length: 2*
> *Program ended with exit code: 0*
>
> - - - - - - -
>
> As we can see, the character from the set is recognized as consisting of
> two code units. There are a few bugs in the system, though. See the
> cocoa-dev thread “Where is my bicycle?” from about a year ago:
> http://prod.lists.apple.com/archives/cocoa-dev/2015/Apr/msg00074.html
>

The bike emoji might be two code units, but it is one Unicode scalar
(U+1F6B2). However, the Canadian flag emoji, for instance, is two Unicode
scalars (U+1F1E8 U+1F1E6) but nonetheless one character.

Charles
>
>
> ___
> 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] associated objects

[Charles Constant via swift-evolution]

-1 for me, but...

> I’m aware of how associated objects work, I’m not aware of why they are
particularly useful in Swift

If stored properties in Extensions aren't useful, why would anything else
in an Extension be useful either? I gather there are reasons it is
impractical to implement them, but saying there's no benefit to them is
like arguing against allowing methods in Extensions, or computed
properties.

My own reason for wanting stored properties in Extensions, is that it would
allow me to organize my classes according to their features. I'm working on
drag and drop at the moment, and I would find it much less confusing in
future, if I could keep all the related properties and methods I'm creating
isolated in a single file. It would also allow me to reuse the same View in
other projects that don't require Drag and Drop *as is.* Otherwise, when I
reuse the class, I'll have to either carry along stored properties I don't
need, or carefully weed them out.

> we have to do better than ObjC

That's the reason I'm against the proposal, too. If we allow stored
properties they should be first-class citizens (assuming that is
technically possible, I don't understand enough about how Frameworks
etc are compiled to know if it would cause issues). I already avoid
Associated Objects because I worry the additional complexity will make my
apps harder to debug if there are memory or performance issues, so the
thought of baking them into Swift doesn't really appeal to me.




On Wed, Sep 28, 2016 at 6:52 PM, Robert Widmann via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Sep 28, 2016, at 11:26 AM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I have implemented Associated Objects (and values) in pure swift here:
> https://github.com/j-h-a/AssociatedObjects
>
> The README is very short and straight-forward so I won't re-describe it
> here.
>
> The implementation isn't great, but it's a small and simple proof of
> concept. I have further extended this (not in GH, but very simple and happy
> to share if anyone cares) to add dynamic methods using closures onto
> individual object instances. Useful for user interactions, or adding
> 'actions' to objects.
>
> I'd like to propose that this or something similar be added to the
> standard library. It could potentially even be added to AnyObject so that
> developers can use it without having to declare an extension for whichever
> classes they want to use it on.
>
> As mentioned, this can easily be extended (either in the standard library
> or by developers) to add closures dynamically to any object, or to any
> class, which could serve as a useful way for those not concerned with type
> safety and the like to get some dynamic behaviour in there in the shorter
> term. With a little language support it could even be used to implement
> stored properties in extensions very easily.
>
>
> I’m not convinced by this explanation.  You haven’t shown me any cases
> where this feature is absolutely necessary, merely enumerated features.
> I’m aware of how associated objects work, I’m not aware of why they are
> particularly useful in Swift and I’d like to be given something to the
> contrary.
>
> As for the point about dismissing type safety: There is no precedent in
> the language for type-unsafe operations to be exposed wholesale to the end
> user like this.  At the very least you should tag the API as Unsafe
> Associated Objects and now you’re stuck explaining why you’d like to stick
> a completely unsafe feature into a language that touts “Safety by
> Default”.  It feels like pining for the Objective-C days of old, and I
> happen to think that that’s fine, but we have to do better than ObjC, not
> have features for the sake of features.
>
>
> A better implementation would need some language changes - specifically
> deinit hooks (has that ever been discussed?) because of the way weak
> references are lazily zeroed. Another implementation improvement might
> lazily add the dictionary to each object instead of storing it globally -
> not sure if this would have ABI implications.
>
>
> That kind of implementation would be space-inefficient - all Swift classes
> now automatically incur an extra pointer-sized allocation per instance.  It
> absolutely has ABI implications too because now we have to track an extra
> part of the header for an object and standardize on access patterns for the
> associated objects table.
>
> Interested in feedback and thoughts :)
> ___
> 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

Re: [swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

[Charles Srstka via swift-evolution]

> On Sep 28, 2016, at 9:57 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> D'erp. I missed that. And that's an unambiguous answer.
> 
> So let me move on to part B of the pitch: I think CharacterSets are broken.
> 
>> Xiaodi Wu: "isn't the problem you're presenting really an argument that the 
>> type should be fleshed out to handle characters (grapheme clusters) 
>> containing more than one Unicode scalar?"

It seems that it already does handle such characters:

(done in Objective-C so we can log the length of the range as a count of UTF-16 
code units)

#import 

int main(int argc, char *argv[]) {
@autoreleasepool {
NSCharacterSet *bikeSet = [NSCharacterSet 
characterSetWithCharactersInString:@""];
NSString *str = @"foobar";

NSRange range = [str rangeOfCharacterFromSet:bikeSet];

NSLog(@"location: %lu length: %lu", range.location, range.length);
}
}

- - - - - - -

2016-09-28 22:20:00.622471 test[15577:2433912] location: 3 length: 2
Program ended with exit code: 0

- - - - - - -

As we can see, the character from the set is recognized as consisting of two 
code units. There are a few bugs in the system, though. See the cocoa-dev 
thread “Where is my bicycle?” from about a year ago: 
http://prod.lists.apple.com/archives/cocoa-dev/2015/Apr/msg00074.html 


Charles

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

Re: [swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

[Erica Sadun via swift-evolution]

On Sep 28, 2016, at 6:14 PM, Ben Rimmington  wrote:
> 
> 
>> On 28 Sep 2016, at 22:27, Erica Sadun wrote:
>> 
>> Why not rename `CharacterSet` to `UnicodeScalarSe`t, and update the 
>> initializers
>> to reflect they're being initialized from the unicode scalars in strings and 
>> ranges?
> 
> I agree, but `UnicodeScalarSet` was rejected during the SE-0069 discussion:
> 
> 
> 
> -- Ben
> 

D'erp. I missed that. And that's an unambiguous answer.

So let me move on to part B of the pitch: I think CharacterSets are broken.

> Xiaodi Wu: "isn't the problem you're presenting really an argument that the 
> type should be fleshed out to handle characters (grapheme clusters) 
> containing more than one Unicode scalar?"

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

Re: [swift-evolution] associated objects

[Robert Widmann via swift-evolution]

> On Sep 28, 2016, at 11:26 AM, Jay Abbott via swift-evolution 
>  wrote:
> 
> I have implemented Associated Objects (and values) in pure swift here:
> https://github.com/j-h-a/AssociatedObjects 
> 
> 
> The README is very short and straight-forward so I won't re-describe it here.
> 
> The implementation isn't great, but it's a small and simple proof of concept. 
> I have further extended this (not in GH, but very simple and happy to share 
> if anyone cares) to add dynamic methods using closures onto individual object 
> instances. Useful for user interactions, or adding 'actions' to objects.
> 
> I'd like to propose that this or something similar be added to the standard 
> library. It could potentially even be added to AnyObject so that developers 
> can use it without having to declare an extension for whichever classes they 
> want to use it on.
> 
> As mentioned, this can easily be extended (either in the standard library or 
> by developers) to add closures dynamically to any object, or to any class, 
> which could serve as a useful way for those not concerned with type safety 
> and the like to get some dynamic behaviour in there in the shorter term. With 
> a little language support it could even be used to implement stored 
> properties in extensions very easily.

I’m not convinced by this explanation.  You haven’t shown me any cases where 
this feature is absolutely necessary, merely enumerated features.  I’m aware of 
how associated objects work, I’m not aware of why they are particularly useful 
in Swift and I’d like to be given something to the contrary.  

As for the point about dismissing type safety: There is no precedent in the 
language for type-unsafe operations to be exposed wholesale to the end user 
like this.  At the very least you should tag the API as Unsafe Associated 
Objects and now you’re stuck explaining why you’d like to stick a completely 
unsafe feature into a language that touts “Safety by Default”.  It feels like 
pining for the Objective-C days of old, and I happen to think that that’s fine, 
but we have to do better than ObjC, not have features for the sake of features.

> 
> A better implementation would need some language changes - specifically 
> deinit hooks (has that ever been discussed?) because of the way weak 
> references are lazily zeroed. Another implementation improvement might lazily 
> add the dictionary to each object instead of storing it globally - not sure 
> if this would have ABI implications.
> 

That kind of implementation would be space-inefficient - all Swift classes now 
automatically incur an extra pointer-sized allocation per instance.  It 
absolutely has ABI implications too because now we have to track an extra part 
of the header for an object and standardize on access patterns for the 
associated objects table.

> Interested in feedback and thoughts :)
> ___
> 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] $self

[Sean Heber via swift-evolution]

Yeah, hard to say how extreme it needs to be to justify this sort of change. 
Does running into unintentional retain cycles when using closures for event 
handlers *constantly* count as extreme? :)

In a typical garbage collected language, using closures like this is common and 
a non-issue, but in Swift the ownership in these situations is something you 
have to actively think about which is a distraction when you want to spend your 
time thinking about what you're building instead. It reminds me of manual 
memory management (which of course it is).

l8r
Sean 

Sent from my iPad

> On Sep 28, 2016, at 7:48 PM, Jay Abbott  wrote:
> 
> Sean, yeah that's kind of what I was suggesting for @escaping closures - it 
> should be the default... but it is a breaking change and as Chris pointed out 
> that would need extreme justification... plus it would be a behaviour change 
> with no syntax change, so code that was never "upgraded" would be very 
> difficult to tell the original intention. I like the idea but I don't know if 
> I can come up with "extreme justification" for it.
> 
>> On Thu, 29 Sep 2016 at 01:46 Sean Heber  wrote:
>> Now that I think about this, wouldn't that be a better default behavior? All 
>> captures are this "required" type which means all closures are typed as 
>> optional. To override that behavior, you'd have to explicitly declare a weak 
>> or unowned capture instead and if you did that for all reference captures, 
>> the closure's type would be non-optional as they are now. Seems like that'd 
>> be safer. I'll shut up now.
>> 
>> l8r
>> Sean
>> 
>> Sent from my iPad
>> 
>>> On Sep 28, 2016, at 7:25 PM, Sean Heber  wrote:
>>> 
>>> Pretty sure this is all way out of scope, but something about this made me 
>>> think about this idea (which maybe isn't unique or is maybe even 
>>> unworkable), but imagine something like where a new capture type is added 
>>> such as "required" (for lack of another name right now). And the way this 
>>> works is similar to unowned, but it makes the entire closure "weak" in such 
>>> a way that the moment any of the required captures go nil, any references 
>>> to that closure instance also effectively become nil.
>>> 
>>> So modifying the example:
>>> 
>>> func viewDidLoad() {
>>> self.loginForm.onSubmit = {[required self]
>>>  let f = self.loginForm
>>>  self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
>>> }
>>> }
>>> 
>>> So in this case, "required self" means self is effectively "unowned" but 
>>> any references to this closure would have to be weak optional like: weak 
>>> var onSubmit: (()->Void)? So that when the view controller gets 
>>> deallocated, the closure goes with it and references become nil.
>>> 
>>> l8r
>>> Sean
>>> 
>>> Sent from my iPad
>>> 
 On Sep 28, 2016, at 6:42 PM, Jay Abbott via swift-evolution 
  wrote:
 
 It could potentially be a breaking change if the default for @escaping 
 closures were made to be weak-capturing.
 
 Since the weak-capturing pattern is only really desirable for @escaping 
 closures, and (I think) it would be the usual preference, could @escaping 
 also imply weak-capturing for all references (not just self)? Then there 
 would be another syntax for strong-capturing-escaping closures. 
 Non-escaping closures could a) strongly capture references; or b) existing 
 strong references stay strong and weak ones stay weak, meaning no 
 ref-counts need to change at all when passing them.
 
 
> On Thu, 29 Sep 2016 at 00:06 Paul Jack via swift-evolution 
>  wrote:
> So previously there were a few threads on the "strong self/weak self
> dance" but they didn't seem to get anywhere. For instance:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
> 
> ...and possibly others.
> 
> I'd like to propose something even easier (and more specific) than all
> of the above discussions. Specifically, I'd like to introduce a new
> automagic closure variable, $self, whose presence in a closure would
> cause that closure to weakly capture self in a safe manner.
> 
> As a concrete example, let's imagine a UIViewController for a login
> form. Under this proposal, the following code:
> 
> func viewDidLoad() {
> self.loginForm.onSubmit = {
>  let f = $self.loginForm
>  $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
> }
> }
> 
> ...would be treated by the compiler as equivalent to:
> 
> func viewDidLoad() {
> self.loginForm.onSubmit = {
>  [weak self] in
>  

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Kevin Ballard via swift-evolution]

There's more uses for enumerated() than just producing Array indices.

-Kevin

On Wed, Sep 28, 2016, at 05:49 PM, Colin Barrett via swift-evolution wrote:
> Definitely well motivated. It seems like having both .enumerated() and
> .indexed() methods would still leave open the possibility of novices
> using .enumerated and making the same mistake as before. I realize
> that because of where .enumerated() sits it has to work the way it
> does, but is there perhaps a better design (with constrained
> extensions?) for a single method that can give an Int for a Sequence
> and an appropriate Index for a Collection?
>
> -Colin
>
>> On Sep 28, 2016, at 1:55 PM, Erica Sadun via swift-evolution > evolut...@swift.org> wrote:
>>
>> Gist here:
>> https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
>>
>> Introducing indexed() collections


>>  * Proposal: TBD
>>  * Author: Erica Sadun[1], Nate Cook[2], Jacob Bandes-Storch[3],
>>Kevin Ballard[4]
>>  * Status: TBD
>>  * Review manager: TBD
>> Introduction
>> This proposal introduces indexed() to the standard library, a method
>> on collections that returns an (index, element) tuple sequence.
>> Swift-evolution thread: TBD[5]
>> Motivation
>> The standard library's enumerated() method returns a sequence of
>> pairs enumerating a sequence. The pair's first member is a
>> monotonically incrementing integer starting at zero, and the second
>> member is the corresponding element of the sequence. When working
>> with arrays, the integer is coincidentally the same type and value as
>> an Array index but the enumerated value is not generated with index-
>> specific semantics. This may lead to confusion when developers
>> attempt to subscript a non-array collection with enumerated integers.
>> It can introduce serious bugs when developers use enumerated()-based
>> integer subscripting with non-zero-based array slices.
>> Indices have a specific, fixed meaning in Swift, which are used to
>> create valid collection subscripts. This proposal introduces
>> indexed() to produce a more semantically relevant sequence by pairing
>> a collection's indices with its members. While it is trivial to
>> create a solution in Swift, the most common developer approach shown
>> here calculates indexes twice:


>> extension Collection { /// Returns a sequence of pairs (*idx*, *x*),
>> where *idx* represents a /// consecutive collection index, and *x*
>> represents an element of /// the sequence. func indexed() ->
>> Zip2Sequence { return zip(indices, self) } }
>>
>> Incrementing an index in some collections can be unnecessarily
>> costly. In a lazy filtered collection, an index increment is
>> potentially O(N). We feel this is better addressed introducing a new
>> function into the Standard Library to provide a more efficient design
>> that avoids the attractive nuisance of the "obvious" solution.
>> Detailed Design
>> Our vision of indexed() bypasses duplicated index generation with
>> their potentially high computation costs. We'd create an iterator
>> that calculates each index once and then applies that index to
>> subscript the collection. Implementation would take place through
>> IndexedSequence, similar to EnumeratedSequence.
>> Impact on Existing Code
>> This proposal is purely additive and has no impact on existing code.
>> Alternatives Considered
>> Not yet
>> ___
>> 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


Links:

  1. https://github.com/erica
  2. https://github.com/natecook1000
  3. https://github.com/jtbandes
  4. https://github.com/kballard
  5. https://gist.github.com/erica/tbd
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] $self

[Charles Srstka via swift-evolution]

> On Sep 28, 2016, at 7:48 PM, Jay Abbott via swift-evolution 
>  wrote:
> 
> Sean, yeah that's kind of what I was suggesting for @escaping closures - it 
> should be the default... but it is a breaking change and as Chris pointed out 
> that would need extreme justification... plus it would be a behaviour change 
> with no syntax change, so code that was never "upgraded" would be very 
> difficult to tell the original intention. I like the idea but I don't know if 
> I can come up with "extreme justification" for it.

How do reference cycles created by accidental implicit captures rank in the 
list of commonly encountered runtime issues? It’s gotta be high, isn’t it? 
Especially if you limit the scope to memory leaks—it seems every time I’ve had 
to track down one of those since ARC came out, it’s been either an unintended 
closure capture or something KVO-related.

Closures are, for me, the #1 time that I switch to super-defensive coding mode. 
Requiring explicit semantics to capture variables would surely reduce a lot of 
memory issues, and also fix crashes that could be caused by objects being 
deallocated in the wrong order. The quality of code in general would improve. 
Is that extreme? I don’t know, but I certainly wouldn’t complain if it happened.

Charles

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

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Colin Barrett via swift-evolution]

Definitely well motivated. It seems like having both .enumerated() and 
.indexed() methods would still leave open the possibility of novices using 
.enumerated and making the same mistake as before. I realize that because of 
where .enumerated() sits it has to work the way it does, but is there perhaps a 
better design (with constrained extensions?) for a single method that can give 
an Int for a Sequence and an appropriate Index for a Collection?

-Colin

> On Sep 28, 2016, at 1:55 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Gist here: https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2 
> 
> 
> Introducing indexed() collections
> 
> Proposal: TBD
> Author: Erica Sadun , Nate Cook 
> , Jacob Bandes-Storch 
> , Kevin Ballard 
> Status: TBD
> Review manager: TBD
>  
> Introduction
> 
> This proposal introduces indexed() to the standard library, a method on 
> collections that returns an (index, element) tuple sequence.
> 
> Swift-evolution thread: TBD 
>  
> Motivation
> 
> The standard library's enumerated() method returns a sequence of pairs 
> enumerating a sequence. The pair's first member is a monotonically 
> incrementing integer starting at zero, and the second member is the 
> corresponding element of the sequence. When working with arrays, the integer 
> is coincidentally the same type and value as an Array index but the 
> enumerated value is not generated with index-specific semantics. This may 
> lead to confusion when developers attempt to subscript a non-array collection 
> with enumerated integers. It can introduce serious bugs when developers use 
> enumerated()-based integer subscripting with non-zero-based array slices.
> 
> Indices have a specific, fixed meaning in Swift, which are used to create 
> valid collection subscripts. This proposal introduces indexed() to produce a 
> more semantically relevant sequence by pairing a collection's indices with 
> its members. While it is trivial to create a solution in Swift, the most 
> common developer approach shown here calculates indexes twice: 
> 
> extension Collection {
> /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents a
> /// consecutive collection index, and *x* represents an element of
> /// the sequence.
> func indexed() -> Zip2Sequence {
> return zip(indices, self)
> }
> }
> Incrementing an index in some collections can be unnecessarily costly. In a 
> lazy filtered collection, an index increment is potentially O(N). We feel 
> this is better addressed introducing a new function into the Standard Library 
> to provide a more efficient design that avoids the attractive nuisance of the 
> "obvious" solution.
> 
>  
> Detailed
>  Design
> 
> Our vision of indexed() bypasses duplicated index generation with their 
> potentially high computation costs. We'd create an iterator that calculates 
> each index once and then applies that index to subscript the collection. 
> Implementation would take place through IndexedSequence, similar to 
> EnumeratedSequence.
> 
>  
> Impact
>  on Existing Code
> 
> This proposal is purely additive and has no impact on existing code.
> 
>  
> Alternatives
>  Considered
> 
> Not yet
> ___
> 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] $self

[Jay Abbott via swift-evolution]

Sean, yeah that's kind of what I was suggesting for @escaping closures - it
should be the default... but it is a breaking change and as Chris pointed
out that would need extreme justification... plus it would be a behaviour
change with no syntax change, so code that was never "upgraded" would be
very difficult to tell the original intention. I like the idea but I don't
know if I can come up with "extreme justification" for it.

On Thu, 29 Sep 2016 at 01:46 Sean Heber  wrote:

> Now that I think about this, wouldn't that be a better default behavior?
> All captures are this "required" type which means all closures are typed as
> optional. To override that behavior, you'd have to explicitly declare a
> weak or unowned capture instead and if you did that for all reference
> captures, the closure's type would be non-optional as they are now. Seems
> like that'd be safer. I'll shut up now.
>
> l8r
> Sean
>
> Sent from my iPad
>
> On Sep 28, 2016, at 7:25 PM, Sean Heber  wrote:
>
> Pretty sure this is all way out of scope, but something about this made me
> think about this idea (which maybe isn't unique or is maybe even
> unworkable), but imagine something like where a new capture type is added
> such as "required" (for lack of another name right now). And the way this
> works is similar to unowned, but it makes the entire closure "weak" in such
> a way that the moment any of the required captures go nil, any references
> to that closure instance also effectively become nil.
>
> So modifying the example:
>
> func viewDidLoad() {
> self.loginForm.onSubmit = {[required self]
>  let f = self.loginForm
>  self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
> }
> }
>
> So in this case, "required self" means self is effectively "unowned" but
> any references to this closure would have to be weak optional like: weak
> var onSubmit: (()->Void)? So that when the view controller gets
> deallocated, the closure goes with it and references become nil.
>
> l8r
> Sean
>
> Sent from my iPad
>
> On Sep 28, 2016, at 6:42 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It could potentially be a breaking change if the default for @escaping
> closures were made to be weak-capturing.
>
> Since the weak-capturing pattern is only really desirable for @escaping
> closures, and (I think) it would be the usual preference, could @escaping
> also imply weak-capturing for all references (not just self)? Then there
> would be another syntax for strong-capturing-escaping closures.
> Non-escaping closures could a) strongly capture references; or b) existing
> strong references stay strong and weak ones stay weak, meaning no
> ref-counts need to change at all when passing them.
>
>
> On Thu, 29 Sep 2016 at 00:06 Paul Jack via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> So previously there were a few threads on the "strong self/weak self
>> dance" but they didn't seem to get anywhere. For instance:
>>
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
>>
>> ...and possibly others.
>>
>> I'd like to propose something even easier (and more specific) than all
>> of the above discussions. Specifically, I'd like to introduce a new
>> automagic closure variable, $self, whose presence in a closure would
>> cause that closure to weakly capture self in a safe manner.
>>
>> As a concrete example, let's imagine a UIViewController for a login
>> form. Under this proposal, the following code:
>>
>> func viewDidLoad() {
>> self.loginForm.onSubmit = {
>>  let f = $self.loginForm
>>  $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
>> }
>> }
>>
>> ...would be treated by the compiler as equivalent to:
>>
>> func viewDidLoad() {
>> self.loginForm.onSubmit = {
>>  [weak self] in
>>  if let selfie = self {
>>  let f = selfie.loginForm
>>  selfie.startLoginRequest(email:f.email.text,
>>  pwd:f.pwd.text)
>>  }
>> }
>> }
>>
>> Note the "if let" there: If self no longer exists, the closure does not
>> execute at all, but if self does exist, then it exists for the entirety
>> of the execution of the closure (ie, self won't vanish as a side-effect
>> of some statement in the closure.) I think these semantics obey the
>> principle of least surprise; $self can be treated by the developer as a
>> strong reference.
>>
>> However, that does mean that $self can only be used in a closure that's
>> (a) Void or (b) Optional. In the latter case, returning nil when self
>> doesn't exist seems like reasonable/expected behavior.
>>
>> It would be a compile-time error to use both $self and normal self in
>> the same closure.
>>
>> I'd like to keep this 

Re: [swift-evolution] $self

[Sean Heber via swift-evolution]

Now that I think about this, wouldn't that be a better default behavior? All 
captures are this "required" type which means all closures are typed as 
optional. To override that behavior, you'd have to explicitly declare a weak or 
unowned capture instead and if you did that for all reference captures, the 
closure's type would be non-optional as they are now. Seems like that'd be 
safer. I'll shut up now.

l8r
Sean

Sent from my iPad

> On Sep 28, 2016, at 7:25 PM, Sean Heber  wrote:
> 
> Pretty sure this is all way out of scope, but something about this made me 
> think about this idea (which maybe isn't unique or is maybe even unworkable), 
> but imagine something like where a new capture type is added such as 
> "required" (for lack of another name right now). And the way this works is 
> similar to unowned, but it makes the entire closure "weak" in such a way that 
> the moment any of the required captures go nil, any references to that 
> closure instance also effectively become nil.
> 
> So modifying the example:
> 
> func viewDidLoad() {
> self.loginForm.onSubmit = {[required self]
>  let f = self.loginForm
>  self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
> }
> }
> 
> So in this case, "required self" means self is effectively "unowned" but any 
> references to this closure would have to be weak optional like: weak var 
> onSubmit: (()->Void)? So that when the view controller gets deallocated, the 
> closure goes with it and references become nil.
> 
> l8r
> Sean
> 
> Sent from my iPad
> 
>> On Sep 28, 2016, at 6:42 PM, Jay Abbott via swift-evolution 
>>  wrote:
>> 
>> It could potentially be a breaking change if the default for @escaping 
>> closures were made to be weak-capturing.
>> 
>> Since the weak-capturing pattern is only really desirable for @escaping 
>> closures, and (I think) it would be the usual preference, could @escaping 
>> also imply weak-capturing for all references (not just self)? Then there 
>> would be another syntax for strong-capturing-escaping closures. Non-escaping 
>> closures could a) strongly capture references; or b) existing strong 
>> references stay strong and weak ones stay weak, meaning no ref-counts need 
>> to change at all when passing them.
>> 
>> 
>>> On Thu, 29 Sep 2016 at 00:06 Paul Jack via swift-evolution 
>>>  wrote:
>>> So previously there were a few threads on the "strong self/weak self
>>> dance" but they didn't seem to get anywhere. For instance:
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
>>> 
>>> ...and possibly others.
>>> 
>>> I'd like to propose something even easier (and more specific) than all
>>> of the above discussions. Specifically, I'd like to introduce a new
>>> automagic closure variable, $self, whose presence in a closure would
>>> cause that closure to weakly capture self in a safe manner.
>>> 
>>> As a concrete example, let's imagine a UIViewController for a login
>>> form. Under this proposal, the following code:
>>> 
>>> func viewDidLoad() {
>>> self.loginForm.onSubmit = {
>>>  let f = $self.loginForm
>>>  $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
>>> }
>>> }
>>> 
>>> ...would be treated by the compiler as equivalent to:
>>> 
>>> func viewDidLoad() {
>>> self.loginForm.onSubmit = {
>>>  [weak self] in
>>>  if let selfie = self {
>>>  let f = selfie.loginForm
>>>  selfie.startLoginRequest(email:f.email.text,
>>>  pwd:f.pwd.text)
>>>  }
>>> }
>>> }
>>> 
>>> Note the "if let" there: If self no longer exists, the closure does not
>>> execute at all, but if self does exist, then it exists for the entirety
>>> of the execution of the closure (ie, self won't vanish as a side-effect
>>> of some statement in the closure.) I think these semantics obey the
>>> principle of least surprise; $self can be treated by the developer as a
>>> strong reference.
>>> 
>>> However, that does mean that $self can only be used in a closure that's
>>> (a) Void or (b) Optional. In the latter case, returning nil when self
>>> doesn't exist seems like reasonable/expected behavior.
>>> 
>>> It would be a compile-time error to use both $self and normal self in
>>> the same closure.
>>> 
>>> I'd like to keep this simple, meaning $self always does the above and
>>> nothing else. So, if you need an unowned self, you still need the
>>> original syntax; if your closure needs a non-Optional return type, you
>>> still need the original syntax; etc.
>>> 
>>> Thoughts?
>>> 
>>> -Paul
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> 

Re: [swift-evolution] $self

[Jay Abbott via swift-evolution]

I think Sean's idea for [required refName] on this is the better one in
terms of syntax and clarity of what's going on. It's fairly clear that the
required refs are weak but become strong during the closure execution, and
that since they're 'required' the closure goes away if they do.

In practice, with lazy zeroing I think it would not be viable to zero the
closure ref until calling it was attempted and the strong ref on its
required captures failed.
One for the 'deferred' pile I guess :P

On Thu, 29 Sep 2016 at 01:27 Chris Lattner  wrote:

> On Sep 28, 2016, at 4:42 PM, Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It could potentially be a breaking change if the default for @escaping
> closures were made to be weak-capturing.
>
>
> Ok, but source breaking changes need extreme justification.  A primary
> goal of Swift 3 was to provide source compatibility going forward.
>
> -Chris
>
>
>
> Since the weak-capturing pattern is only really desirable for @escaping
> closures, and (I think) it would be the usual preference, could @escaping
> also imply weak-capturing for all references (not just self)? Then there
> would be another syntax for strong-capturing-escaping closures.
> Non-escaping closures could a) strongly capture references; or b) existing
> strong references stay strong and weak ones stay weak, meaning no
> ref-counts need to change at all when passing them.
>
>
> On Thu, 29 Sep 2016 at 00:06 Paul Jack via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> So previously there were a few threads on the "strong self/weak self
>> dance" but they didn't seem to get anywhere. For instance:
>>
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
>>
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
>>
>> ...and possibly others.
>>
>> I'd like to propose something even easier (and more specific) than all
>> of the above discussions. Specifically, I'd like to introduce a new
>> automagic closure variable, $self, whose presence in a closure would
>> cause that closure to weakly capture self in a safe manner.
>>
>> As a concrete example, let's imagine a UIViewController for a login
>> form. Under this proposal, the following code:
>>
>> func viewDidLoad() {
>> self.loginForm.onSubmit = {
>>  let f = $self.loginForm
>>  $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
>> }
>> }
>>
>> ...would be treated by the compiler as equivalent to:
>>
>> func viewDidLoad() {
>> self.loginForm.onSubmit = {
>>  [weak self] in
>>  if let selfie = self {
>>  let f = selfie.loginForm
>>  selfie.startLoginRequest(email:f.email.text,
>>  pwd:f.pwd.text)
>>  }
>> }
>> }
>>
>> Note the "if let" there: If self no longer exists, the closure does not
>> execute at all, but if self does exist, then it exists for the entirety
>> of the execution of the closure (ie, self won't vanish as a side-effect
>> of some statement in the closure.) I think these semantics obey the
>> principle of least surprise; $self can be treated by the developer as a
>> strong reference.
>>
>> However, that does mean that $self can only be used in a closure that's
>> (a) Void or (b) Optional. In the latter case, returning nil when self
>> doesn't exist seems like reasonable/expected behavior.
>>
>> It would be a compile-time error to use both $self and normal self in
>> the same closure.
>>
>> I'd like to keep this simple, meaning $self always does the above and
>> nothing else. So, if you need an unowned self, you still need the
>> original syntax; if your closure needs a non-Optional return type, you
>> still need the original syntax; etc.
>>
>> Thoughts?
>>
>> -Paul
>> ___
>> 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] Refactor Metatypes

[Colin Barrett via swift-evolution]

First off, I agree with Nevin (up-thread) that this is a much clearer version 
of the previous proposal, well done.

> On Sep 28, 2016, at 6:18 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Formatted version: 
> https://github.com/DevAndArtist/swift-evolution/blob/refactor_metatypes/proposals/0126-refactor-metatypes.md
>  
> 
> Refactor Metatypes
> 
> Proposal: SE–0126 
> 
> Authors: Adrian Zubarev , Anton Zhilin 
> , Brent Royal-Gordon 
> Status: Revision
> Review manager: Chris Lattner 
> Revision: 2
> Previous Revisions: 1 
> 
> Introduction
> 
> This proposal removes .Type and .Protocol in favor of two generic-style 
> syntaxes and aligns global type(of:) function (SE–0096) to match the changes.
> 
> Swift-evolution thread (post Swift 3): 
> 
> [Pitch] Refactor Metatypes 
> 
> Older swift-evolution threads: [1] 
> ,
>  [2] 
> ,
>  [3] 
> 
> Motivation
> 
> Every type T has an instance, accessible through T.self, which represents the 
> type itself. Like all instances in Swift, this “type instance” itself has a 
> type, which is referred to as its “metatype”. The metatype of T is written 
> T.Type. The instance members of the metatype are the same as the static or 
> class members of the type.
> 
> Metatypes have subtype relationships which reflect the types they represent. 
> For instance, given these types:
> 
> protocol Proto {}
> class Base {}
> class Derived: Base, Proto {}
> Derived.Type is a subtype of both Base.Type and Proto.Type (and Any.Type). 
> That means that Derived.self can be used anywhere a Derived.Type, Base.Type, 
> Proto.Type, or Any.Type is called for.
> 
> Unfortunately, this simple picture is complicated by protocols. Proto.self is 
> actually of type Proto.Protocol, not type Proto.Type. This is necessary 
> because the protocol does not, and cannot, conform to itself; it requires 
> conforming types to provide static members, but it doesn’t actually provide 
> those members itself. Proto.Type still exists, but it is the supertype of all 
> types conforming to the protocol.
> 
> Making this worse, a generic type always uses T.Type to refer to the type of 
> T.self. So when Proto is bound to a generic parameter P, P.Type is the same 
> as Proto.Protocol.
> 
> This shifting of types is complicated and confusing; we seek to clean up this 
> area.
> 
> We also believe that, in the long term, the dot syntax will prevent us from 
> implementing certain future enhancements that might be valuable:
> 
> Moving the implementation of metatypes at least partly into the standard 
> library.
> Adding members available on all type instances for features like read-write 
> reflection or memory layout information.
> Conforming metatypes to protocols like Hashable or CustomStringConvertible.
> Offering straightforward syntaxes for dynamic features like looking up types 
> by name.
> Proposed solution
> 
> We abolish .Type and .Protocol in favor of two generic-style syntaxes:
> 
> Type is the concrete type of T.self. A Type only ever has one instance, 
> T.self; even if T has a subtype U, Type is not a subtype of Type.
> 
> Subtype is the supertype of all Types whose instances are subtypes of T, 
> including T itself:
> 
> If T is a struct or enum, then Type is the only subtype of Subtype.
> 
> If T is a class, then Type and the Types of all subclasses of T are 
> subtypes of Subtype.
> 
> If T is a protocol, then the Types of all concrete types conforming to T are 
> subtypes of Subtype. Type is not itself a subtype of Subtype, or of 
> any Subtype other than Subtype.
> 
I’m having trouble reconciling this with rule #2 above, which states that 
“Subtype is the supertype of all Types whose instances are subtypes of T, 
including T itself.” Which one is wrong, or am I confused?

One thing I haven’t understood the motivation for exactly is what someone would 
be able to do with a Proto.self. Dynamic conformance checking? For a concrete 
T, having its .self seems useful for doing dynamic casts and such, but I don’t 
understand why for a Proto you need to have both. You did a good job of 
explaining why T.Protocol and T.Type are different, but not why both of them 
need to exist. So you could definitely do more to spell out the use-cases here.
> Structural types follow the subtype/supertype relationships of their 
> constituent types. For 

Re: [swift-evolution] $self

[Chris Lattner via swift-evolution]

> On Sep 28, 2016, at 4:42 PM, Jay Abbott via swift-evolution 
>  wrote:
> 
> It could potentially be a breaking change if the default for @escaping 
> closures were made to be weak-capturing.

Ok, but source breaking changes need extreme justification.  A primary goal of 
Swift 3 was to provide source compatibility going forward.

-Chris


> 
> Since the weak-capturing pattern is only really desirable for @escaping 
> closures, and (I think) it would be the usual preference, could @escaping 
> also imply weak-capturing for all references (not just self)? Then there 
> would be another syntax for strong-capturing-escaping closures. Non-escaping 
> closures could a) strongly capture references; or b) existing strong 
> references stay strong and weak ones stay weak, meaning no ref-counts need to 
> change at all when passing them.
> 
> 
> On Thu, 29 Sep 2016 at 00:06 Paul Jack via swift-evolution 
> > wrote:
> So previously there were a few threads on the "strong self/weak self
> dance" but they didn't seem to get anywhere. For instance:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
>  
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
>  
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
>  
> 
> 
> ...and possibly others.
> 
> I'd like to propose something even easier (and more specific) than all
> of the above discussions. Specifically, I'd like to introduce a new
> automagic closure variable, $self, whose presence in a closure would
> cause that closure to weakly capture self in a safe manner.
> 
> As a concrete example, let's imagine a UIViewController for a login
> form. Under this proposal, the following code:
> 
> func viewDidLoad() {
> self.loginForm.onSubmit = {
>  let f = $self.loginForm
>  $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
> }
> }
> 
> ...would be treated by the compiler as equivalent to:
> 
> func viewDidLoad() {
> self.loginForm.onSubmit = {
>  [weak self] in
>  if let selfie = self {
>  let f = selfie.loginForm
>  selfie.startLoginRequest(email:f.email.text,
>  pwd:f.pwd.text)
>  }
> }
> }
> 
> Note the "if let" there: If self no longer exists, the closure does not
> execute at all, but if self does exist, then it exists for the entirety
> of the execution of the closure (ie, self won't vanish as a side-effect
> of some statement in the closure.) I think these semantics obey the
> principle of least surprise; $self can be treated by the developer as a
> strong reference.
> 
> However, that does mean that $self can only be used in a closure that's
> (a) Void or (b) Optional. In the latter case, returning nil when self
> doesn't exist seems like reasonable/expected behavior.
> 
> It would be a compile-time error to use both $self and normal self in
> the same closure.
> 
> I'd like to keep this simple, meaning $self always does the above and
> nothing else. So, if you need an unowned self, you still need the
> original syntax; if your closure needs a non-Optional return type, you
> still need the original syntax; etc.
> 
> Thoughts?
> 
> -Paul
> ___
> 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] $self

[Sean Heber via swift-evolution]

Pretty sure this is all way out of scope, but something about this made me 
think about this idea (which maybe isn't unique or is maybe even unworkable), 
but imagine something like where a new capture type is added such as "required" 
(for lack of another name right now). And the way this works is similar to 
unowned, but it makes the entire closure "weak" in such a way that the moment 
any of the required captures go nil, any references to that closure instance 
also effectively become nil.

So modifying the example:

func viewDidLoad() {
self.loginForm.onSubmit = {[required self]
 let f = self.loginForm
 self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
}
}

So in this case, "required self" means self is effectively "unowned" but any 
references to this closure would have to be weak optional like: weak var 
onSubmit: (()->Void)? So that when the view controller gets deallocated, the 
closure goes with it and references become nil.

l8r
Sean

Sent from my iPad

> On Sep 28, 2016, at 6:42 PM, Jay Abbott via swift-evolution 
>  wrote:
> 
> It could potentially be a breaking change if the default for @escaping 
> closures were made to be weak-capturing.
> 
> Since the weak-capturing pattern is only really desirable for @escaping 
> closures, and (I think) it would be the usual preference, could @escaping 
> also imply weak-capturing for all references (not just self)? Then there 
> would be another syntax for strong-capturing-escaping closures. Non-escaping 
> closures could a) strongly capture references; or b) existing strong 
> references stay strong and weak ones stay weak, meaning no ref-counts need to 
> change at all when passing them.
> 
> 
>> On Thu, 29 Sep 2016 at 00:06 Paul Jack via swift-evolution 
>>  wrote:
>> So previously there were a few threads on the "strong self/weak self
>> dance" but they didn't seem to get anywhere. For instance:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
>> 
>> ...and possibly others.
>> 
>> I'd like to propose something even easier (and more specific) than all
>> of the above discussions. Specifically, I'd like to introduce a new
>> automagic closure variable, $self, whose presence in a closure would
>> cause that closure to weakly capture self in a safe manner.
>> 
>> As a concrete example, let's imagine a UIViewController for a login
>> form. Under this proposal, the following code:
>> 
>> func viewDidLoad() {
>> self.loginForm.onSubmit = {
>>  let f = $self.loginForm
>>  $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
>> }
>> }
>> 
>> ...would be treated by the compiler as equivalent to:
>> 
>> func viewDidLoad() {
>> self.loginForm.onSubmit = {
>>  [weak self] in
>>  if let selfie = self {
>>  let f = selfie.loginForm
>>  selfie.startLoginRequest(email:f.email.text,
>>  pwd:f.pwd.text)
>>  }
>> }
>> }
>> 
>> Note the "if let" there: If self no longer exists, the closure does not
>> execute at all, but if self does exist, then it exists for the entirety
>> of the execution of the closure (ie, self won't vanish as a side-effect
>> of some statement in the closure.) I think these semantics obey the
>> principle of least surprise; $self can be treated by the developer as a
>> strong reference.
>> 
>> However, that does mean that $self can only be used in a closure that's
>> (a) Void or (b) Optional. In the latter case, returning nil when self
>> doesn't exist seems like reasonable/expected behavior.
>> 
>> It would be a compile-time error to use both $self and normal self in
>> the same closure.
>> 
>> I'd like to keep this simple, meaning $self always does the above and
>> nothing else. So, if you need an unowned self, you still need the
>> original syntax; if your closure needs a non-Optional return type, you
>> still need the original syntax; etc.
>> 
>> Thoughts?
>> 
>> -Paul
>> ___
>> 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: Renaming CharacterSet to UnicodeScalarSet

[Ben Rimmington via swift-evolution]

> On 28 Sep 2016, at 22:27, Erica Sadun wrote:
> 
> Why not rename `CharacterSet` to `UnicodeScalarSe`t, and update the 
> initializers
> to reflect they're being initialized from the unicode scalars in strings and 
> ranges?

I agree, but `UnicodeScalarSet` was rejected during the SE-0069 discussion:



-- Ben

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

Re: [swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

[Xiaodi Wu via swift-evolution]

Afaik, every Unicode scalar can be its own character, so IMO it's not
bothersome that there are overloads that take Unicode scalar arguments.
However, since the stated purpose of the type is to be a set of characters,
isn't the problem you're presenting really an argument that the type should
be fleshed out to handle characters (grapheme clusters) containing more
than one Unicode scalar?


On Wed, Sep 28, 2016 at 18:43 Erica Sadun  wrote:

> On Sep 28, 2016, at 3:58 PM, Xiaodi Wu  wrote:
>
>
> Is this really correct? Character and UnicodeScalar are not synonyms. The
> Character type represents a character made up of one or more Unicode
> scalars (i.e. an extended grapheme cluster). Is a CharacterSet a set of
> Unicode-compliant characters that happens to be restricted to those
> characters each made up of only a single Unicode scalar, or is it meant to
> be a set of Unicode scalars? My read of the Foundation documentation is
> that it is the former.
>
>
> http://i.imgur.com/h6W5kYc.jpg
>
> http://i.imgur.com/q50PSld.jpg
>
> -- E
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

[Erica Sadun via swift-evolution]

On Sep 28, 2016, at 3:58 PM, Xiaodi Wu  wrote:
> 
> Is this really correct? Character and UnicodeScalar are not synonyms. The 
> Character type represents a character made up of one or more Unicode scalars 
> (i.e. an extended grapheme cluster). Is a CharacterSet a set of 
> Unicode-compliant characters that happens to be restricted to those 
> characters each made up of only a single Unicode scalar, or is it meant to be 
> a set of Unicode scalars? My read of the Foundation documentation is that it 
> is the former.

http://i.imgur.com/h6W5kYc.jpg 

http://i.imgur.com/q50PSld.jpg 

-- E


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

Re: [swift-evolution] $self

[Jay Abbott via swift-evolution]

It could potentially be a breaking change if the default for @escaping
closures were made to be weak-capturing.

Since the weak-capturing pattern is only really desirable for @escaping
closures, and (I think) it would be the usual preference, could @escaping
also imply weak-capturing for all references (not just self)? Then there
would be another syntax for strong-capturing-escaping closures.
Non-escaping closures could a) strongly capture references; or b) existing
strong references stay strong and weak ones stay weak, meaning no
ref-counts need to change at all when passing them.


On Thu, 29 Sep 2016 at 00:06 Paul Jack via swift-evolution <
swift-evolution@swift.org> wrote:

> So previously there were a few threads on the "strong self/weak self
> dance" but they didn't seem to get anywhere. For instance:
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
>
> ...and possibly others.
>
> I'd like to propose something even easier (and more specific) than all
> of the above discussions. Specifically, I'd like to introduce a new
> automagic closure variable, $self, whose presence in a closure would
> cause that closure to weakly capture self in a safe manner.
>
> As a concrete example, let's imagine a UIViewController for a login
> form. Under this proposal, the following code:
>
> func viewDidLoad() {
> self.loginForm.onSubmit = {
>  let f = $self.loginForm
>  $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
> }
> }
>
> ...would be treated by the compiler as equivalent to:
>
> func viewDidLoad() {
> self.loginForm.onSubmit = {
>  [weak self] in
>  if let selfie = self {
>  let f = selfie.loginForm
>  selfie.startLoginRequest(email:f.email.text,
>  pwd:f.pwd.text)
>  }
> }
> }
>
> Note the "if let" there: If self no longer exists, the closure does not
> execute at all, but if self does exist, then it exists for the entirety
> of the execution of the closure (ie, self won't vanish as a side-effect
> of some statement in the closure.) I think these semantics obey the
> principle of least surprise; $self can be treated by the developer as a
> strong reference.
>
> However, that does mean that $self can only be used in a closure that's
> (a) Void or (b) Optional. In the latter case, returning nil when self
> doesn't exist seems like reasonable/expected behavior.
>
> It would be a compile-time error to use both $self and normal self in
> the same closure.
>
> I'd like to keep this simple, meaning $self always does the above and
> nothing else. So, if you need an unowned self, you still need the
> original syntax; if your closure needs a non-Optional return type, you
> still need the original syntax; etc.
>
> Thoughts?
>
> -Paul
> ___
> 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] $self

[Chris Lattner via swift-evolution]

> On Sep 28, 2016, at 4:05 PM, Paul Jack via swift-evolution 
>  wrote:
> 
> So previously there were a few threads on the "strong self/weak self
> dance" but they didn't seem to get anywhere. For instance:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html
> 
> ...and possibly others.
> 
> I'd like to propose something even easier (and more specific) than all
> of the above discussions. Specifically, I'd like to introduce a new
> automagic closure variable, $self, whose presence in a closure would
> cause that closure to weakly capture self in a safe manner.

This is an additive proposal, so we’d prefer for you to hold off until we get 
the core work for Swift 4 stage 1 under control.  We need to focus on making 
sure ABI and Source Stability takes priority.

-Chris

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

[swift-evolution] $self

[Paul Jack via swift-evolution]

So previously there were a few threads on the "strong self/weak self
dance" but they didn't seem to get anywhere. For instance:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008713.html
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010759.html
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html

...and possibly others.

I'd like to propose something even easier (and more specific) than all
of the above discussions. Specifically, I'd like to introduce a new
automagic closure variable, $self, whose presence in a closure would
cause that closure to weakly capture self in a safe manner.

As a concrete example, let's imagine a UIViewController for a login
form. Under this proposal, the following code:

func viewDidLoad() {
self.loginForm.onSubmit = {
 let f = $self.loginForm
 $self.startLoginRequest(email:f.email.text, pwd:f.pwd.text)
}
}

...would be treated by the compiler as equivalent to:

func viewDidLoad() {
self.loginForm.onSubmit = {
 [weak self] in
 if let selfie = self {
 let f = selfie.loginForm
 selfie.startLoginRequest(email:f.email.text,
 pwd:f.pwd.text)
 }
}
}

Note the "if let" there: If self no longer exists, the closure does not
execute at all, but if self does exist, then it exists for the entirety
of the execution of the closure (ie, self won't vanish as a side-effect
of some statement in the closure.) I think these semantics obey the
principle of least surprise; $self can be treated by the developer as a
strong reference.

However, that does mean that $self can only be used in a closure that's
(a) Void or (b) Optional. In the latter case, returning nil when self
doesn't exist seems like reasonable/expected behavior.

It would be a compile-time error to use both $self and normal self in
the same closure.

I'd like to keep this simple, meaning $self always does the above and
nothing else. So, if you need an unowned self, you still need the
original syntax; if your closure needs a non-Optional return type, you
still need the original syntax; etc.

Thoughts?

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

Re: [swift-evolution] [Proposal draft] Conditional conformances

[Douglas Gregor via swift-evolution]

> On Sep 28, 2016, at 1:28 PM, plx via swift-evolution 
>  wrote:
> 
> It’s good to see this starting to happen!
> 
> Is the decision on "no-overlapping-conformances” something that’s seen-as set 
> in stone permanently, set in stone for the near future, or perhaps at least 
> somewhat open to reconsideration at the present moment?

There hasn’t been a decision per se, so it that sense it’s open to 
reconsideration.

I have a strong *personal* bias against overlapping conformances, because I 
feel that the amount of complexity that they introduce into the language and 
its implementation far outweigh any benefits. Additionally, they enable use 
cases (e.g., static metaprogramming-ish tricks) that I feel would be actively 
harmful to the Swift language’s understandability. Generics systems can get 
very complicated very quickly, so any extension needs to be strongly motivated 
by use cases to matter to all or most Swift developers.

- Doug

> 
>> On Sep 26, 2016, at 7:18 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Conditional conformances
>> 
>> Proposal: SE- 
>> 
>> Author: Doug Gregor 
>> Review Manager: TBD
>> Status: Awaiting review
>> During the review process, add the following fields as needed:
>> 
>> Decision Notes: Rationale 
>> , Additional Commentary 
>> 
>> Bugs: SR- , SR- 
>> 
>> Previous Revision: 1 
>> 
>> Previous Proposal: SE- 
>> 
>>  
>> Introduction
>> 
>> Conditional conformances express the notion that a generic type will conform 
>> to a particular protocol only when it's type arguments meet certain 
>> requirements. For example, the Array collection can implement the Equatable 
>> protocol only when its elements are themselves Equatable, which can be 
>> expressed via the following conditional conformance on Equatable:
>> 
>> extension Array: Equatable where Element: Equatable {
>>   static func ==(lhs: Array, rhs: Array) -> Bool { ... }
>> }
>> This feature is part of the generics manifesto 
>> 
>>  because it's something that fits naturally into the generics model and is 
>> expected to have a high impact on the Swift standard library.
>> 
>> Swift-evolution thread: TBD: Discussion thread topic for that proposal 
>> 
>>  
>> Motivation
>> 
>> Conditional conformances address a hole in the composability of the generics 
>> system. Continuing the Array example from above, it's always been the case 
>> that one could use the == operator on two arrays of Equatable type, e.g., 
>> [Int]() == [Int]() would succeed. However, it doesn't compose: arrays of 
>> arrays of Equatable types cannot be compared (e.g.,[Int] 
>> ==
>>  [Int] 
>> will
>>  fail to compile) because, even though there is an==for arrays of 
>> Equatabletype, the arrays themselves are neverEquatable`.
>> 
>> Conditional conformances are particularly powerful when building generic 
>> adapter types, which are intended to reflect the capabilities of their type 
>> arguments. For example, consider the "lazy" functionality of the Swift 
>> standard library's collections: using the lazy member of a sequence produces 
>> a lazy adapter that conforms to the Sequence protocol, while using the lazy 
>> member of a collection produces a lazy adapter that conforms to the 
>> Collection protocol. In Swift 3, the only way to model this is with 
>> different types. For example, the Swift standard library has four similar 
>> generic types to handle a lazy collection: LazySequence, LazyCollection, 
>> LazyBidirectionalCollection, and LazyRandomAccessCollection. The Swift 
>> standard library uses overloading of the lazy property to decide among these:
>> 
>> extension Sequence {
>>   var lazy: LazySequence { ... }
>> }
>> 
>> extension Collection {
>>   var lazy: LazyCollection { ... }
>> }
>> 
>> extension BidirectionalCollection {
>>   var lazy: LazyBidirectionalCollection { ... }
>> }
>> 
>> 

Re: [swift-evolution] [Review] SE-0143: Conditional Conformances

[Robert Widmann via swift-evolution]

~Robert Widmann

2016/09/28 18:15、Joe Groff via swift-evolution  
のメッセージ:

> What is your evaluation of the proposal?
Strong +1.  There's no proposal I believe would have a greater positive impact 
on the Swift community at this point than conditional conformances.
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Absolutely. 
> Does this proposal fit well with the feel and direction of Swift?
Yes.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Conditional conformances are mostly par for the course in other languages that 
enable ad hoc polymorphism 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
I went so far as to fake conditional conformances by encoding them with indexed 
protocol witnesses to see what it's like without them.  [I'd like to delete 
that code].
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Joe
> 
> Review Manager
> 
Kudos Doug.  I'm so happy this is happening.

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

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Tim Vermeulen via swift-evolution]

> On 28 Sep 2016, at 23:44, Kevin Ballard  wrote:
> 
> On Wed, Sep 28, 2016, at 02:10 PM, Tim Vermeulen wrote:
>> 
>>> On 28 Sep 2016, at 23:03, Kevin Ballard >> > wrote:
>>> 
>>> On Wed, Sep 28, 2016, at 02:02 PM, Tim Vermeulen wrote:
 
> On 28 Sep 2016, at 22:57, Kevin Ballard  > wrote:
> 
> On Wed, Sep 28, 2016, at 01:54 PM, Tim Vermeulen wrote:
>> 
>>> On 28 Sep 2016, at 22:46, Kevin Ballard >> > wrote:
>>> 
>>> That's a bunch of complexity for no benefit. Why would you ever use 
>>> this as a collection?
>> 
>> I think there is a benefit. Something like 
>> `collection.indexed().reversed()` would benefit from that, and I think 
>> that could be useful.
> 
> Perhaps, though you could just say `collection.reversed().indexed()` 
> instead.
 
 This isn’t necessarily the same though, is it? The reversed collection 
 might use different indices than the original collection.
>>> 
>>> Either way you write it you're dealing with reversed indices.
>> 
>> `collection.indexed().reversed()` will contain indices from the original 
>> collection (but in reversed order). `collection.reversed().indexed()` will 
>> contain indices from the collection returned by `reversed()`, which may have 
>> a different type than `Base.Index`. It’s a distinction.
>> 
>> This would compile:
>> 
>> let characters = "Swift".characters
>> 
>> for (index, character) in characters.indexed().reversed() {
>> print(characters[index], character)
>> }
>> 
>> This wouldn’t:
>> 
>> let characters = "Swift".characters
>> 
>> for (index, character) in characters.reversed().indexed() {
>> print(characters[index], character)
>> }
> 
> Oh you're right.
> 
> Still, it's a fair amount of complexity (handling bidirectional and 
> random-access collections on top of the regular collection) and I'm not sure 
> it's worth the complexity just for reversed().

It’s very straight-forward to simply forward all requirements to the base 
collection. I just wrote it out, and it might even be less complex than the 
sequence approach, because we don’t need a custom iterator.

> After all, you can always fall back to the slightly uglier
> 
> for index in characters.indices.reversed() {
> let character = characters[index]
> ...
> }

You could, but don’t forget that writing `characters.indexed().reversed()` in 
the case of `IndexedSequence` would still have the result you’d expect. It’s 
simply less efficient than necessary. Most people probably wouldn’t even 
realise that the more readable approach isn’t the most efficient one, here.

> 
> And it's worth pointing out that enumerated() doesn't return a collection but 
> nobody's been clamoring for reversed() support there.
> 
> -Kevin
> 
>>> 
>>> -Kevin
>>> 
>>> The whole point is to be used in a for loop. If it was a collection 
>>> then you'd need to have an index for that collection, so now you have 
>>> an index that lets you get the index for another collection, which is 
>>> pretty useless because you could just be using that underlying index to 
>>> begin with.
>> 
>> Rather than introducing a new index for this, we can simply use the 
>> index of the base collection for subscripting.
> 
> That's actually a good idea, and if we do make it a collection this is 
> probably how we should handle it. But I still argue that the ability to 
> make something a collection doesn't mean it should be a collection, if 
> there's no good reason for anyone to actually try to use it as such.
> 
> -Kevin
> 
>>> On Wed, Sep 28, 2016, at 01:38 PM, Tim Vermeulen via swift-evolution 
>>> wrote:
 +1 for `indexed()`, but I’m not sure about `IndexedSequence`. Why not 
 `IndexedCollection`, which could also conform to Collection? With 
 conditional conformances to BidirectionalCollection and 
 RandomAccessCollection. This wouldn’t penalise the performance with 
 respect to a simple `IndexedSequence`, would it?
 
> Gist 
> here:https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2 
> 
> 
> Introducingindexed()collections
> Proposal: TBD
> Author:Erica Sadun(https://github.com/erica 
> ),Nate Cook(https://github.com/natecook1000 
> ),Jacob 
> Bandes-Storch(https://github.com/jtbandes 
> ),Kevin 
> Ballard(https://github.com/kballard )
> Status: TBD
> Review manager: TBD
> 
> Introduction
> 
> This proposal introducesindexed()to the standard library, a method on 

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[plx via swift-evolution]

> On Sep 28, 2016, at 4:47 PM, Kevin Ballard  wrote:
> 
> On Wed, Sep 28, 2016, at 02:27 PM, plx via swift-evolution wrote:
>> +1 to have something *like* this, but a few questions.
>> 
>> Is there a specific reason `IndexedSequence` isn’t `IndexedCollection`, 
>> conforming to `Collection` (and once conditional conformances are available 
>> picking up `BidirectionalCollection` and `RandomAccessCollection` when 
>> possible?).
> 
> This is already being discussed in this thread, but the simple answer is that 
> adds complexity and it's not obvious that it's worth the additional 
> complexity.

As it can be done as trivial, "pass-through" boilerplate:

  struct IndexedCollection :Collection {
typealias Index = C.Index
typealias Indices = C.Indices

let base: C
  
subscript(i: Index) -> (Index,C.Iterator.Element) { return (i,base[i]) }
  
}

…(and so on and so forth) it’s about as trivial to implement as any 
`Collection` is going to be…which is why I was a bit surprised it wasn’t part 
of the proposal.

If you’re worried about performance vis-a-vis lazy collections you could also 
store the `base.indices` and use it instead of `base` but even that should 
leave the implementation almost entirely boilerplate-ish.

Sure it’s a bit annoying to write it all out but I’m not seeing a lot of 
complexity really; I might be missing something?

> 
>> Secondly, can you provide more detail on the proposed implementation? 
>> 
>> Are you just walking the index forward and subscripting the base in the 
>> iterator, or something fancier?
> 
> Yeah, that's what it would be. Something like
> 
> sequence(state: base.indices, next: {
> guard let idx = $0.next() else { return nil }
> return (idx, base[idx])
> })
> 
> except done as a concrete type.

I assume the above is closer to this?

> sequence(state: base.indices.makeIterator(), next: {
> guard let idx = $0.next() else { return nil }
> return (idx, base[idx])
> })

The way the proposal was worried I was concerned the “only calculate each index 
once” bit would be a bit expensive when not really necessary, but deferring to 
the implementation of `indices` seems perfectly reasonable to me.

> 
> -Kevin
> 
>>> On Sep 28, 2016, at 12:55 PM, Erica Sadun via swift-evolution 
>>> > wrote:
>>> 
>>> Gist here: https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2 
>>> 
>>> 
>>> Introducing indexed() collections
>>> 
>>> Proposal: TBD
>>> Author: Erica Sadun , Nate Cook 
>>> , Jacob Bandes-Storch 
>>> , Kevin Ballard 
>>> Status: TBD
>>> Review manager: TBD
>>>  
>>> Introduction
>>> 
>>> This proposal introduces indexed() to the standard library, a method on 
>>> collections that returns an (index, element) tuple sequence.
>>> 
>>> Swift-evolution thread: TBD 
>>>  
>>> Motivation
>>> 
>>> The standard library's enumerated() method returns a sequence of pairs 
>>> enumerating a sequence. The pair's first member is a monotonically 
>>> incrementing integer starting at zero, and the second member is the 
>>> corresponding element of the sequence. When working with arrays, the 
>>> integer is coincidentally the same type and value as an Array index but the 
>>> enumerated value is not generated with index-specific semantics. This may 
>>> lead to confusion when developers attempt to subscript a non-array 
>>> collection with enumerated integers. It can introduce serious bugs when 
>>> developers use enumerated()-based integer subscripting with non-zero-based 
>>> array slices.
>>> 
>>> Indices have a specific, fixed meaning in Swift, which are used to create 
>>> valid collection subscripts. This proposal introduces indexed() to produce 
>>> a more semantically relevant sequence by pairing a collection's indices 
>>> with its members. While it is trivial to create a solution in Swift, the 
>>> most common developer approach shown here calculates indexes twice: 
>>> 
>>> extension Collection {
>>> /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents a
>>> /// consecutive collection index, and *x* represents an element of
>>> /// the sequence.
>>> func indexed() -> Zip2Sequence {
>>> return zip(indices, self)
>>> }
>>> }
>>> 
>>> Incrementing an index in some collections can be unnecessarily costly. In a 
>>> lazy filtered collection, an index increment is potentially O(N). We feel 
>>> this is better addressed introducing a new function into the Standard 
>>> Library to provide a more efficient design that avoids the attractive 
>>> nuisance of 

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Nevin Brackett-Rozinsky via swift-evolution]

I like Sean’s idea.

Nevin

On Wed, Sep 28, 2016 at 2:34 PM, Sean Heber via swift-evolution <
swift-evolution@swift.org> wrote:

> This might just be me being silly, but is there any way to be able to do
> something like this instead:
>
> for (index, value) in sequence {
> }
>
> Maybe by adding another variant of makeIterator() that only differs by the
> return type or something like that?
>
> I sort of dislike that enumerated() and indexed() would co-exist and
> potentially lead to really subtle bugs when getting them confused.
> Obviously removing enumerated() would be a breaking change, though, and
> maybe it has valuable uses that I’m not really thinking about (although it
> seems to me that the index/value pair is what you want like, 99% of the
> time and plenty of people - myself included - have been using the index of
> enumerated() as an array index even though that’s technically maybe not
> quite ‘correct').
>
> l8r
> Sean
>
>
> > On Sep 28, 2016, at 12:55 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Gist here: https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3
> f2
> >
> > Introducing indexed() collections
> >
> >   • Proposal: TBD
> >   • Author: Erica Sadun, Nate Cook, Jacob Bandes-Storch, Kevin
> Ballard
> >   • Status: TBD
> >   • Review manager: TBD
> > Introduction
> >
> > This proposal introduces indexed() to the standard library, a method on
> collections that returns an (index, element) tuple sequence.
> >
> > Swift-evolution thread: TBD
> >
> > Motivation
> >
> > The standard library's enumerated() method returns a sequence of pairs
> enumerating a sequence. The pair's first member is a monotonically
> incrementing integer starting at zero, and the second member is the
> corresponding element of the sequence. When working with arrays, the
> integer is coincidentally the same type and value as an Array index but the
> enumerated value is not generated with index-specific semantics. This may
> lead to confusion when developers attempt to subscript a non-array
> collection with enumerated integers. It can introduce serious bugs when
> developers use enumerated()-based integer subscripting with non-zero-based
> array slices.
> >
> > Indices have a specific, fixed meaning in Swift, which are used to
> create valid collection subscripts. This proposal introduces indexed() to
> produce a more semantically relevant sequence by pairing a collection's
> indices with its members. While it is trivial to create a solution in
> Swift, the most common developer approach shown here calculates indexes
> twice:
> >
> > extension Collection {
> > /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents
> a
> > /// consecutive collection index, and *x* represents an element of
> > /// the sequence.
> > func indexed() -> Zip2Sequence {
> > return zip(indices, self)
> > }
> > }
> >
> > Incrementing an index in some collections can be unnecessarily costly.
> In a lazy filtered collection, an index increment is potentially O(N). We
> feel this is better addressed introducing a new function into the Standard
> Library to provide a more efficient design that avoids the attractive
> nuisance of the "obvious" solution.
> >
> > Detailed Design
> >
> > Our vision of indexed() bypasses duplicated index generation with their
> potentially high computation costs. We'd create an iterator that calculates
> each index once and then applies that index to subscript the collection.
> Implementation would take place through IndexedSequence, similar to
> EnumeratedSequence.
> >
> > Impact on Existing Code
> >
> > This proposal is purely additive and has no impact on existing code.
> >
> > Alternatives Considered
> >
> > Not yet
> > ___
> > 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: Renaming CharacterSet to UnicodeScalarSet

[Xiaodi Wu via swift-evolution]

Is this really correct? Character and UnicodeScalar are not synonyms. The
Character type represents a character made up of one or more Unicode
scalars (i.e. an extended grapheme cluster). Is a CharacterSet a set of
Unicode-compliant characters that happens to be restricted to those
characters each made up of only a single Unicode scalar, or is it meant to
be a set of Unicode scalars? My read of the Foundation documentation is
that it is the former.


On Wed, Sep 28, 2016 at 4:27 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> Chris: "*Also, it is worth saying that any source breaking change still
> has to have an *
> *ultra-compelling reason to be worth considering.  Despite having a
> framework to *
> *support some source breaking changes, we still want to minimize them
> where *
> *ever possible.*"
>
> Since it seems to be open season on introducing a few, highly focused
> breaking changes, let me throw this one out there.
>
> *Pitch: Renaming CharacterSet to UnicodeScalarSet*
>
> In Swift, String is defined as "a Unicode string value." and a
> "CharacterSet"
> represents a set of Unicode-compliant characters.
>
> A CharacterSet's initializers are:
>
>- init()
>- init(S)
>- init(arrayLiteral: UnicodeScalar...)
>- init(bitmapRepresentation: Data)
>- init(charactersIn: ClosedRange)
>- init(charactersIn: String)
>- init(charactersIn: Range)
>- init?(contentsOfFile: String)
>
>
> Why not rename `CharacterSet` to `UnicodeScalarSe`t, and update the
> initializers
> to reflect they're being initialized from the unicode scalars in strings
> and ranges?
> I think the few places where the word `character` is left mentioned (in
> convenience
> properties) can be better named from `punctuationCharacters` to
> `punctuation`,
> `controlCharacters` to `controlAndFormat`, etc.
>
> -- 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] [Proposal draft] Introducing `indexed()` collections

[Kevin Ballard via swift-evolution]

On Wed, Sep 28, 2016, at 02:27 PM, plx via swift-evolution wrote:
> +1 to have something *like* this, but a few questions.
>
> Is there a specific reason `IndexedSequence` isn’t
> `IndexedCollection`, conforming to `Collection` (and once conditional
> conformances are available picking up `BidirectionalCollection` and
> `RandomAccessCollection` when possible?).

This is already being discussed in this thread, but the simple answer is
that adds complexity and it's not obvious that it's worth the additional
complexity.

> Secondly, can you provide more detail on the proposed implementation?
>
> Are you just walking the index forward and subscripting the base in
> the iterator, or something fancier?

Yeah, that's what it would be. Something like

sequence(state: base.indices, next: {
guard let idx = $0.next() else { return nil }
return (idx, base[idx])
})

except done as a concrete type.

-Kevin

>> On Sep 28, 2016, at 12:55 PM, Erica Sadun via swift-evolution > evolut...@swift.org> wrote:
>>
>> Gist here:
>> https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
>>
>> Introducing indexed() collections


>>  * Proposal: TBD
>>  * Author: Erica Sadun[1], Nate Cook[2], Jacob Bandes-Storch[3],
>>Kevin Ballard[4]
>>  * Status: TBD
>>  * Review manager: TBD
>> Introduction
>> This proposal introduces indexed() to the standard library, a method
>> on collections that returns an (index, element) tuple sequence.
>> Swift-evolution thread: TBD[5]
>> Motivation
>> The standard library's enumerated() method returns a sequence of
>> pairs enumerating a sequence. The pair's first member is a
>> monotonically incrementing integer starting at zero, and the second
>> member is the corresponding element of the sequence. When working
>> with arrays, the integer is coincidentally the same type and value as
>> an Array index but the enumerated value is not generated with index-
>> specific semantics. This may lead to confusion when developers
>> attempt to subscript a non-array collection with enumerated integers.
>> It can introduce serious bugs when developers use enumerated()-based
>> integer subscripting with non-zero-based array slices.
>> Indices have a specific, fixed meaning in Swift, which are used to
>> create valid collection subscripts. This proposal introduces
>> indexed() to produce a more semantically relevant sequence by pairing
>> a collection's indices with its members. While it is trivial to
>> create a solution in Swift, the most common developer approach shown
>> here calculates indexes twice:


>> extension Collection { /// Returns a sequence of pairs (*idx*, *x*),
>> where *idx* represents a /// consecutive collection index, and *x*
>> represents an element of /// the sequence. func indexed() ->
>> Zip2Sequence { return zip(indices, self) } }
>>
>> Incrementing an index in some collections can be unnecessarily
>> costly. In a lazy filtered collection, an index increment is
>> potentially O(N). We feel this is better addressed introducing a new
>> function into the Standard Library to provide a more efficient design
>> that avoids the attractive nuisance of the "obvious" solution.
>> Detailed Design
>> Our vision of indexed() bypasses duplicated index generation with
>> their potentially high computation costs. We'd create an iterator
>> that calculates each index once and then applies that index to
>> subscript the collection. Implementation would take place through
>> IndexedSequence, similar to EnumeratedSequence.
>> Impact on Existing Code
>> This proposal is purely additive and has no impact on existing code.
>> Alternatives Considered
>> Not yet
>> ___
>> 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


Links:

  1. https://github.com/erica
  2. https://github.com/natecook1000
  3. https://github.com/jtbandes
  4. https://github.com/kballard
  5. https://gist.github.com/erica/tbd
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Kevin Ballard via swift-evolution]

On Wed, Sep 28, 2016, at 02:10 PM, Tim Vermeulen wrote:
>
>> On 28 Sep 2016, at 23:03, Kevin Ballard  wrote:
>>
>> On Wed, Sep 28, 2016, at 02:02 PM, Tim Vermeulen wrote:
>>>
 On 28 Sep 2016, at 22:57, Kevin Ballard  wrote:

 On Wed, Sep 28, 2016, at 01:54 PM, Tim Vermeulen wrote:
>
>> On 28 Sep 2016, at 22:46, Kevin Ballard  wrote:
>>
>> That's a bunch of complexity for no benefit. Why would you ever
>> use this as a collection?
>
> I think there is a benefit. Something like
> `collection.indexed().reversed()` would benefit from that, and I
> think that could be useful.

 Perhaps, though you could just say
 `collection.reversed().indexed()` instead.
>>>
>>> This isn’t necessarily the same though, is it? The reversed
>>> collection might use different indices than the original collection.
>>
>> Either way you write it you're dealing with reversed indices.
>
> `collection.indexed().reversed()` will contain indices from the
> original collection (but in reversed order).
> `collection.reversed().indexed()` will contain indices from the
> collection returned by `reversed()`, which may have a different type
> than `Base.Index`. It’s a distinction.
>
> This would compile:
>
> let characters = "Swift".characters
>
> for (index, character) in characters.indexed().reversed() {
> print(characters[index], character)
> }
>
> This wouldn’t:
>
> let characters = "Swift".characters
>
> for (index, character) in characters.reversed().indexed() {
> print(characters[index], character)
> }

Oh you're right.

Still, it's a fair amount of complexity (handling bidirectional and random-
access collections on top of the regular collection) and I'm not sure
it's worth the complexity just for reversed(). After all, you can always
fall back to the slightly uglier

for index in characters.indices.reversed() {
let character = characters[index]
...
}

And it's worth pointing out that enumerated() doesn't return a
collection but nobody's been clamoring for reversed() support there.

-Kevin

>>
>> -Kevin
>>
>> The whole point is to be used in a for loop. If it was a
>> collection then you'd need to have an index for that collection,
>> so now you have an index that lets you get the index for another
>> collection, which is pretty useless because you could just be
>> using that underlying index to begin with.
>
> Rather than introducing a new index for this, we can simply use
> the index of the base collection for subscripting.

 That's actually a good idea, and if we do make it a collection this
 is probably how we should handle it. But I still argue that the
 ability to make something a collection doesn't mean it should be a
 collection, if there's no good reason for anyone to actually try to
 use it as such.

 -Kevin

>> On Wed, Sep 28, 2016, at 01:38 PM, Tim Vermeulen via swift-
>> evolution wrote:
>>> +1 for `indexed()`, but I’m not sure about `IndexedSequence`.
>>> Why not `IndexedCollection`, which could also conform to
>>> Collection? With conditional conformances to
>>> BidirectionalCollection and RandomAccessCollection. This
>>> wouldn’t penalise the performance with respect to a simple
>>> `IndexedSequence`, would it?
>>>
 Gist here:
 https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2

 Introducingindexed()collections
 Proposal: TBD
 Author:Erica Sadun(https://github.com/erica),Nate Cook
 (https://github.com/natecook1000),Jacob Bandes-Storch
 (https://github.com/jtbandes),Kevin Ballard
 (https://github.com/kballard)
 Status: TBD
 Review manager: TBD

 Introduction

 This proposal introducesindexed()to the standard library, a
 method on collections that returns an (index, element) tuple
 sequence.


 Swift-evolution thread:TBD(https://gist.github.com/erica/tbd)

 Motivation

 The standard library'senumerated()method returns a sequence of
 pairs enumerating a sequence. The pair's first member is a
 monotonically incrementing integer starting at zero, and the
 second member is the corresponding element of the sequence.
 When working with arrays, the integer is coincidentally the
 same type and value as anArrayindex but the enumerated value is
 not generated with index-specific semantics. This may lead to
 confusion when developers attempt to subscript a non-array
 collection with enumerated integers. It can introduce serious
 bugs when developers useenumerated()-based integer subscripting
 with non-zero-based array slices.


 Indices have a specific, fixed meaning in Swift, which are used
 to create 

[swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

[Erica Sadun via swift-evolution]

Chris: "Also, it is worth saying that any source breaking change still has to 
have an 
ultra-compelling reason to be worth considering.  Despite having a framework to 
support some source breaking changes, we still want to minimize them where 
ever possible."

Since it seems to be open season on introducing a few, highly focused
breaking changes, let me throw this one out there.

Pitch: Renaming CharacterSet to UnicodeScalarSet

In Swift, String is defined as "a Unicode string value." and a "CharacterSet" 
represents a set of Unicode-compliant characters.

A CharacterSet's initializers are:
init()
init(S)
init(arrayLiteral: UnicodeScalar...)
init(bitmapRepresentation: Data)
init(charactersIn: ClosedRange)
init(charactersIn: String)
init(charactersIn: Range)
init?(contentsOfFile: String)

Why not rename `CharacterSet` to `UnicodeScalarSe`t, and update the initializers
to reflect they're being initialized from the unicode scalars in strings and 
ranges?
I think the few places where the word `character` is left mentioned (in 
convenience
properties) can be better named from `punctuationCharacters` to `punctuation`, 
`controlCharacters` to `controlAndFormat`, etc.

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

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[plx via swift-evolution]

+1 to have something *like* this, but a few questions.

Is there a specific reason `IndexedSequence` isn’t `IndexedCollection`, 
conforming to `Collection` (and once conditional conformances are available 
picking up `BidirectionalCollection` and `RandomAccessCollection` when 
possible?).

Secondly, can you provide more detail on the proposed implementation? 

Are you just walking the index forward and subscripting the base in the 
iterator, or something fancier?

> On Sep 28, 2016, at 12:55 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Gist here: https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2 
> 
> 
> Introducing indexed() collections
> 
> Proposal: TBD
> Author: Erica Sadun , Nate Cook 
> , Jacob Bandes-Storch 
> , Kevin Ballard 
> Status: TBD
> Review manager: TBD
>  
> Introduction
> 
> This proposal introduces indexed() to the standard library, a method on 
> collections that returns an (index, element) tuple sequence.
> 
> Swift-evolution thread: TBD 
>  
> Motivation
> 
> The standard library's enumerated() method returns a sequence of pairs 
> enumerating a sequence. The pair's first member is a monotonically 
> incrementing integer starting at zero, and the second member is the 
> corresponding element of the sequence. When working with arrays, the integer 
> is coincidentally the same type and value as an Array index but the 
> enumerated value is not generated with index-specific semantics. This may 
> lead to confusion when developers attempt to subscript a non-array collection 
> with enumerated integers. It can introduce serious bugs when developers use 
> enumerated()-based integer subscripting with non-zero-based array slices.
> 
> Indices have a specific, fixed meaning in Swift, which are used to create 
> valid collection subscripts. This proposal introduces indexed() to produce a 
> more semantically relevant sequence by pairing a collection's indices with 
> its members. While it is trivial to create a solution in Swift, the most 
> common developer approach shown here calculates indexes twice: 
> 
> extension Collection {
> /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents a
> /// consecutive collection index, and *x* represents an element of
> /// the sequence.
> func indexed() -> Zip2Sequence {
> return zip(indices, self)
> }
> }
> Incrementing an index in some collections can be unnecessarily costly. In a 
> lazy filtered collection, an index increment is potentially O(N). We feel 
> this is better addressed introducing a new function into the Standard Library 
> to provide a more efficient design that avoids the attractive nuisance of the 
> "obvious" solution.
> 
>  
> Detailed
>  Design
> 
> Our vision of indexed() bypasses duplicated index generation with their 
> potentially high computation costs. We'd create an iterator that calculates 
> each index once and then applies that index to subscript the collection. 
> Implementation would take place through IndexedSequence, similar to 
> EnumeratedSequence.
> 
>  
> Impact
>  on Existing Code
> 
> This proposal is purely additive and has no impact on existing code.
> 
>  
> Alternatives
>  Considered
> 
> Not yet
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Tim Vermeulen via swift-evolution]

> On 28 Sep 2016, at 23:03, Kevin Ballard  wrote:
> 
> On Wed, Sep 28, 2016, at 02:02 PM, Tim Vermeulen wrote:
>> 
>>> On 28 Sep 2016, at 22:57, Kevin Ballard  wrote:
>>> 
>>> On Wed, Sep 28, 2016, at 01:54 PM, Tim Vermeulen wrote:
 
> On 28 Sep 2016, at 22:46, Kevin Ballard  wrote:
> 
> That's a bunch of complexity for no benefit. Why would you ever use this 
> as a collection?
 
 I think there is a benefit. Something like 
 `collection.indexed().reversed()` would benefit from that, and I think 
 that could be useful.
>>> 
>>> Perhaps, though you could just say `collection.reversed().indexed()` 
>>> instead.
>> 
>> This isn’t necessarily the same though, is it? The reversed collection might 
>> use different indices than the original collection.
> 
> Either way you write it you're dealing with reversed indices.

`collection.indexed().reversed()` will contain indices from the original 
collection (but in reversed order). `collection.reversed().indexed()` will 
contain indices from the collection returned by `reversed()`, which may have a 
different type than `Base.Index`. It’s a distinction.

This would compile:

let characters = "Swift".characters

for (index, character) in characters.indexed().reversed() {
print(characters[index], character)
}

This wouldn’t:

let characters = "Swift".characters

for (index, character) in characters.reversed().indexed() {
print(characters[index], character)
}

> 
> -Kevin
> 
> The whole point is to be used in a for loop. If it was a collection then 
> you'd need to have an index for that collection, so now you have an index 
> that lets you get the index for another collection, which is pretty 
> useless because you could just be using that underlying index to begin 
> with.
 
 Rather than introducing a new index for this, we can simply use the index 
 of the base collection for subscripting.
>>> 
>>> That's actually a good idea, and if we do make it a collection this is 
>>> probably how we should handle it. But I still argue that the ability to 
>>> make something a collection doesn't mean it should be a collection, if 
>>> there's no good reason for anyone to actually try to use it as such.
>>> 
>>> -Kevin
>>> 
> On Wed, Sep 28, 2016, at 01:38 PM, Tim Vermeulen via swift-evolution 
> wrote:
>> +1 for `indexed()`, but I’m not sure about `IndexedSequence`. Why not 
>> `IndexedCollection`, which could also conform to Collection? With 
>> conditional conformances to BidirectionalCollection and 
>> RandomAccessCollection. This wouldn’t penalise the performance with 
>> respect to a simple `IndexedSequence`, would it?
>> 
>>> Gist here:https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
>>> 
>>> Introducingindexed()collections
>>> Proposal: TBD
>>> Author:Erica Sadun(https://github.com/erica),Nate 
>>> Cook(https://github.com/natecook1000),Jacob 
>>> Bandes-Storch(https://github.com/jtbandes),Kevin 
>>> Ballard(https://github.com/kballard)
>>> Status: TBD
>>> Review manager: TBD
>>> 
>>> Introduction
>>> 
>>> This proposal introducesindexed()to the standard library, a method on 
>>> collections that returns an (index, element) tuple sequence.
>>> 
>>> 
>>> Swift-evolution thread:TBD(https://gist.github.com/erica/tbd)
>>> 
>>> Motivation
>>> 
>>> The standard library'senumerated()method returns a sequence of pairs 
>>> enumerating a sequence. The pair's first member is a monotonically 
>>> incrementing integer starting at zero, and the second member is the 
>>> corresponding element of the sequence. When working with arrays, the 
>>> integer is coincidentally the same type and value as anArrayindex but 
>>> the enumerated value is not generated with index-specific semantics. 
>>> This may lead to confusion when developers attempt to subscript a 
>>> non-array collection with enumerated integers. It can introduce serious 
>>> bugs when developers useenumerated()-based integer subscripting with 
>>> non-zero-based array slices.
>>> 
>>> 
>>> Indices have a specific, fixed meaning in Swift, which are used to 
>>> create valid collection subscripts. This proposal introducesindexed()to 
>>> produce a more semantically relevant sequence by pairing a 
>>> collection'sindiceswith its members. While it is trivial to create a 
>>> solution in Swift, the most common developer approach shown here 
>>> calculates indexes twice:
>>> 
>>> extension Collection {   /// Returns a sequence of pairs (*idx*, *x*), 
>>> where *idx* represents a   /// consecutive collection index, and *x* 
>>> represents an element of   /// the sequence.   func indexed() 
>>> ->Zip2Sequence{ return zip(indices, self)   } }
>>> 
>>> Incrementing an 

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Kevin Ballard via swift-evolution]

On Wed, Sep 28, 2016, at 02:02 PM, Tim Vermeulen wrote:
> 
> > On 28 Sep 2016, at 22:57, Kevin Ballard  wrote:
> > 
> > On Wed, Sep 28, 2016, at 01:54 PM, Tim Vermeulen wrote:
> >> 
> >>> On 28 Sep 2016, at 22:46, Kevin Ballard  wrote:
> >>> 
> >>> That's a bunch of complexity for no benefit. Why would you ever use this 
> >>> as a collection?
> >> 
> >> I think there is a benefit. Something like 
> >> `collection.indexed().reversed()` would benefit from that, and I think 
> >> that could be useful.
> > 
> > Perhaps, though you could just say `collection.reversed().indexed()` 
> > instead.
> 
> This isn’t necessarily the same though, is it? The reversed collection might 
> use different indices than the original collection.

Either way you write it you're dealing with reversed indices.

-Kevin

> >>> The whole point is to be used in a for loop. If it was a collection then 
> >>> you'd need to have an index for that collection, so now you have an index 
> >>> that lets you get the index for another collection, which is pretty 
> >>> useless because you could just be using that underlying index to begin 
> >>> with.
> >> 
> >> Rather than introducing a new index for this, we can simply use the index 
> >> of the base collection for subscripting.
> > 
> > That's actually a good idea, and if we do make it a collection this is 
> > probably how we should handle it. But I still argue that the ability to 
> > make something a collection doesn't mean it should be a collection, if 
> > there's no good reason for anyone to actually try to use it as such.
> > 
> > -Kevin
> > 
> >>> On Wed, Sep 28, 2016, at 01:38 PM, Tim Vermeulen via swift-evolution 
> >>> wrote:
>  +1 for `indexed()`, but I’m not sure about `IndexedSequence`. Why not 
>  `IndexedCollection`, which could also conform to Collection? With 
>  conditional conformances to BidirectionalCollection and 
>  RandomAccessCollection. This wouldn’t penalise the performance with 
>  respect to a simple `IndexedSequence`, would it?
>  
> > Gist here:https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
> > 
> > Introducingindexed()collections
> > Proposal: TBD
> > Author:Erica Sadun(https://github.com/erica),Nate 
> > Cook(https://github.com/natecook1000),Jacob 
> > Bandes-Storch(https://github.com/jtbandes),Kevin 
> > Ballard(https://github.com/kballard)
> > Status: TBD
> > Review manager: TBD
> > 
> > Introduction
> > 
> > This proposal introducesindexed()to the standard library, a method on 
> > collections that returns an (index, element) tuple sequence.
> > 
> > 
> > Swift-evolution thread:TBD(https://gist.github.com/erica/tbd)
> > 
> > Motivation
> > 
> > The standard library'senumerated()method returns a sequence of pairs 
> > enumerating a sequence. The pair's first member is a monotonically 
> > incrementing integer starting at zero, and the second member is the 
> > corresponding element of the sequence. When working with arrays, the 
> > integer is coincidentally the same type and value as anArrayindex but 
> > the enumerated value is not generated with index-specific semantics. 
> > This may lead to confusion when developers attempt to subscript a 
> > non-array collection with enumerated integers. It can introduce serious 
> > bugs when developers useenumerated()-based integer subscripting with 
> > non-zero-based array slices.
> > 
> > 
> > Indices have a specific, fixed meaning in Swift, which are used to 
> > create valid collection subscripts. This proposal introducesindexed()to 
> > produce a more semantically relevant sequence by pairing a 
> > collection'sindiceswith its members. While it is trivial to create a 
> > solution in Swift, the most common developer approach shown here 
> > calculates indexes twice:
> > 
> > extension Collection {   /// Returns a sequence of pairs (*idx*, *x*), 
> > where *idx* represents a   /// consecutive collection index, and *x* 
> > represents an element of   /// the sequence.   func indexed() 
> > ->Zip2Sequence{ return zip(indices, self)   } }
> > 
> > Incrementing an index in some collections can be unnecessarily costly. 
> > In a lazy filtered collection, an index increment is potentially O(N). 
> > We feel this is better addressed introducing a new function into the 
> > Standard Library to provide a more efficient design that avoids the 
> > attractive nuisance of the "obvious" solution.
> > 
> > Detailed Design
> > 
> > Our vision ofindexed()bypasses duplicated index generation with their 
> > potentially high computation costs. We'd create an iterator that 
> > calculates each index once and then applies that index to subscript the 
> > collection. Implementation would take place 

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Tim Vermeulen via swift-evolution]

> On 28 Sep 2016, at 22:57, Kevin Ballard  wrote:
> 
> On Wed, Sep 28, 2016, at 01:54 PM, Tim Vermeulen wrote:
>> 
>>> On 28 Sep 2016, at 22:46, Kevin Ballard  wrote:
>>> 
>>> That's a bunch of complexity for no benefit. Why would you ever use this as 
>>> a collection?
>> 
>> I think there is a benefit. Something like `collection.indexed().reversed()` 
>> would benefit from that, and I think that could be useful.
> 
> Perhaps, though you could just say `collection.reversed().indexed()` instead.

This isn’t necessarily the same though, is it? The reversed collection might 
use different indices than the original collection.

> 
>>> The whole point is to be used in a for loop. If it was a collection then 
>>> you'd need to have an index for that collection, so now you have an index 
>>> that lets you get the index for another collection, which is pretty useless 
>>> because you could just be using that underlying index to begin with.
>> 
>> Rather than introducing a new index for this, we can simply use the index of 
>> the base collection for subscripting.
> 
> That's actually a good idea, and if we do make it a collection this is 
> probably how we should handle it. But I still argue that the ability to make 
> something a collection doesn't mean it should be a collection, if there's no 
> good reason for anyone to actually try to use it as such.
> 
> -Kevin
> 
>>> On Wed, Sep 28, 2016, at 01:38 PM, Tim Vermeulen via swift-evolution wrote:
 +1 for `indexed()`, but I’m not sure about `IndexedSequence`. Why not 
 `IndexedCollection`, which could also conform to Collection? With 
 conditional conformances to BidirectionalCollection and 
 RandomAccessCollection. This wouldn’t penalise the performance with 
 respect to a simple `IndexedSequence`, would it?
 
> Gist here:https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
> 
> Introducingindexed()collections
> Proposal: TBD
> Author:Erica Sadun(https://github.com/erica),Nate 
> Cook(https://github.com/natecook1000),Jacob 
> Bandes-Storch(https://github.com/jtbandes),Kevin 
> Ballard(https://github.com/kballard)
> Status: TBD
> Review manager: TBD
> 
> Introduction
> 
> This proposal introducesindexed()to the standard library, a method on 
> collections that returns an (index, element) tuple sequence.
> 
> 
> Swift-evolution thread:TBD(https://gist.github.com/erica/tbd)
> 
> Motivation
> 
> The standard library'senumerated()method returns a sequence of pairs 
> enumerating a sequence. The pair's first member is a monotonically 
> incrementing integer starting at zero, and the second member is the 
> corresponding element of the sequence. When working with arrays, the 
> integer is coincidentally the same type and value as anArrayindex but the 
> enumerated value is not generated with index-specific semantics. This may 
> lead to confusion when developers attempt to subscript a non-array 
> collection with enumerated integers. It can introduce serious bugs when 
> developers useenumerated()-based integer subscripting with non-zero-based 
> array slices.
> 
> 
> Indices have a specific, fixed meaning in Swift, which are used to create 
> valid collection subscripts. This proposal introducesindexed()to produce 
> a more semantically relevant sequence by pairing a 
> collection'sindiceswith its members. While it is trivial to create a 
> solution in Swift, the most common developer approach shown here 
> calculates indexes twice:
> 
> extension Collection {   /// Returns a sequence of pairs (*idx*, *x*), 
> where *idx* represents a   /// consecutive collection index, and *x* 
> represents an element of   /// the sequence.   func indexed() 
> ->Zip2Sequence{ return zip(indices, self)   } }
> 
> Incrementing an index in some collections can be unnecessarily costly. In 
> a lazy filtered collection, an index increment is potentially O(N). We 
> feel this is better addressed introducing a new function into the 
> Standard Library to provide a more efficient design that avoids the 
> attractive nuisance of the "obvious" solution.
> 
> Detailed Design
> 
> Our vision ofindexed()bypasses duplicated index generation with their 
> potentially high computation costs. We'd create an iterator that 
> calculates each index once and then applies that index to subscript the 
> collection. Implementation would take place throughIndexedSequence, 
> similar toEnumeratedSequence.
> 
> Impact on Existing Code
> 
> This proposal is purely additive and has no impact on existing code.
> 
> Alternatives Considered
> Not yet
> 
> 
> 
> 
 ___
 swift-evolution mailing list
 

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Kevin Ballard via swift-evolution]

On Wed, Sep 28, 2016, at 01:54 PM, Tim Vermeulen wrote:
> 
> > On 28 Sep 2016, at 22:46, Kevin Ballard  wrote:
> > 
> > That's a bunch of complexity for no benefit. Why would you ever use this as 
> > a collection?
> 
> I think there is a benefit. Something like `collection.indexed().reversed()` 
> would benefit from that, and I think that could be useful.

Perhaps, though you could just say `collection.reversed().indexed()` instead.

> > The whole point is to be used in a for loop. If it was a collection then 
> > you'd need to have an index for that collection, so now you have an index 
> > that lets you get the index for another collection, which is pretty useless 
> > because you could just be using that underlying index to begin with.
> 
> Rather than introducing a new index for this, we can simply use the index of 
> the base collection for subscripting.

That's actually a good idea, and if we do make it a collection this is probably 
how we should handle it. But I still argue that the ability to make something a 
collection doesn't mean it should be a collection, if there's no good reason 
for anyone to actually try to use it as such.

 -Kevin

> > On Wed, Sep 28, 2016, at 01:38 PM, Tim Vermeulen via swift-evolution wrote:
> >> +1 for `indexed()`, but I’m not sure about `IndexedSequence`. Why not 
> >> `IndexedCollection`, which could also conform to Collection? With 
> >> conditional conformances to BidirectionalCollection and 
> >> RandomAccessCollection. This wouldn’t penalise the performance with 
> >> respect to a simple `IndexedSequence`, would it?
> >> 
> >>> Gist here:https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
> >>> 
> >>> Introducingindexed()collections
> >>> Proposal: TBD
> >>> Author:Erica Sadun(https://github.com/erica),Nate 
> >>> Cook(https://github.com/natecook1000),Jacob 
> >>> Bandes-Storch(https://github.com/jtbandes),Kevin 
> >>> Ballard(https://github.com/kballard)
> >>> Status: TBD
> >>> Review manager: TBD
> >>> 
> >>> Introduction
> >>> 
> >>> This proposal introducesindexed()to the standard library, a method on 
> >>> collections that returns an (index, element) tuple sequence.
> >>> 
> >>> 
> >>> Swift-evolution thread:TBD(https://gist.github.com/erica/tbd)
> >>> 
> >>> Motivation
> >>> 
> >>> The standard library'senumerated()method returns a sequence of pairs 
> >>> enumerating a sequence. The pair's first member is a monotonically 
> >>> incrementing integer starting at zero, and the second member is the 
> >>> corresponding element of the sequence. When working with arrays, the 
> >>> integer is coincidentally the same type and value as anArrayindex but the 
> >>> enumerated value is not generated with index-specific semantics. This may 
> >>> lead to confusion when developers attempt to subscript a non-array 
> >>> collection with enumerated integers. It can introduce serious bugs when 
> >>> developers useenumerated()-based integer subscripting with non-zero-based 
> >>> array slices.
> >>> 
> >>> 
> >>> Indices have a specific, fixed meaning in Swift, which are used to create 
> >>> valid collection subscripts. This proposal introducesindexed()to produce 
> >>> a more semantically relevant sequence by pairing a 
> >>> collection'sindiceswith its members. While it is trivial to create a 
> >>> solution in Swift, the most common developer approach shown here 
> >>> calculates indexes twice:
> >>> 
> >>> extension Collection {   /// Returns a sequence of pairs (*idx*, *x*), 
> >>> where *idx* represents a   /// consecutive collection index, and *x* 
> >>> represents an element of   /// the sequence.   func indexed() 
> >>> ->Zip2Sequence{ return zip(indices, self)   } }
> >>> 
> >>> Incrementing an index in some collections can be unnecessarily costly. In 
> >>> a lazy filtered collection, an index increment is potentially O(N). We 
> >>> feel this is better addressed introducing a new function into the 
> >>> Standard Library to provide a more efficient design that avoids the 
> >>> attractive nuisance of the "obvious" solution.
> >>> 
> >>> Detailed Design
> >>> 
> >>> Our vision ofindexed()bypasses duplicated index generation with their 
> >>> potentially high computation costs. We'd create an iterator that 
> >>> calculates each index once and then applies that index to subscript the 
> >>> collection. Implementation would take place throughIndexedSequence, 
> >>> similar toEnumeratedSequence.
> >>> 
> >>> Impact on Existing Code
> >>> 
> >>> This proposal is purely additive and has no impact on existing code.
> >>> 
> >>> Alternatives Considered
> >>> Not yet
> >>> 
> >>> 
> >>> 
> >>> 
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Tim Vermeulen via swift-evolution]

> On 28 Sep 2016, at 22:46, Kevin Ballard  wrote:
> 
> That's a bunch of complexity for no benefit. Why would you ever use this as a 
> collection?

I think there is a benefit. Something like `collection.indexed().reversed()` 
would benefit from that, and I think that could be useful.

> The whole point is to be used in a for loop. If it was a collection then 
> you'd need to have an index for that collection, so now you have an index 
> that lets you get the index for another collection, which is pretty useless 
> because you could just be using that underlying index to begin with.

Rather than introducing a new index for this, we can simply use the index of 
the base collection for subscripting.

> 
> -Kevin
> 
> On Wed, Sep 28, 2016, at 01:38 PM, Tim Vermeulen via swift-evolution wrote:
>> +1 for `indexed()`, but I’m not sure about `IndexedSequence`. Why not 
>> `IndexedCollection`, which could also conform to Collection? With 
>> conditional conformances to BidirectionalCollection and 
>> RandomAccessCollection. This wouldn’t penalise the performance with respect 
>> to a simple `IndexedSequence`, would it?
>> 
>>> Gist here:https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
>>> 
>>> Introducingindexed()collections
>>> Proposal: TBD
>>> Author:Erica Sadun(https://github.com/erica),Nate 
>>> Cook(https://github.com/natecook1000),Jacob 
>>> Bandes-Storch(https://github.com/jtbandes),Kevin 
>>> Ballard(https://github.com/kballard)
>>> Status: TBD
>>> Review manager: TBD
>>> 
>>> Introduction
>>> 
>>> This proposal introducesindexed()to the standard library, a method on 
>>> collections that returns an (index, element) tuple sequence.
>>> 
>>> 
>>> Swift-evolution thread:TBD(https://gist.github.com/erica/tbd)
>>> 
>>> Motivation
>>> 
>>> The standard library'senumerated()method returns a sequence of pairs 
>>> enumerating a sequence. The pair's first member is a monotonically 
>>> incrementing integer starting at zero, and the second member is the 
>>> corresponding element of the sequence. When working with arrays, the 
>>> integer is coincidentally the same type and value as anArrayindex but the 
>>> enumerated value is not generated with index-specific semantics. This may 
>>> lead to confusion when developers attempt to subscript a non-array 
>>> collection with enumerated integers. It can introduce serious bugs when 
>>> developers useenumerated()-based integer subscripting with non-zero-based 
>>> array slices.
>>> 
>>> 
>>> Indices have a specific, fixed meaning in Swift, which are used to create 
>>> valid collection subscripts. This proposal introducesindexed()to produce a 
>>> more semantically relevant sequence by pairing a collection'sindiceswith 
>>> its members. While it is trivial to create a solution in Swift, the most 
>>> common developer approach shown here calculates indexes twice:
>>> 
>>> extension Collection {   /// Returns a sequence of pairs (*idx*, *x*), 
>>> where *idx* represents a   /// consecutive collection index, and *x* 
>>> represents an element of   /// the sequence.   func indexed() 
>>> ->Zip2Sequence{ return zip(indices, self)   } }
>>> 
>>> Incrementing an index in some collections can be unnecessarily costly. In a 
>>> lazy filtered collection, an index increment is potentially O(N). We feel 
>>> this is better addressed introducing a new function into the Standard 
>>> Library to provide a more efficient design that avoids the attractive 
>>> nuisance of the "obvious" solution.
>>> 
>>> Detailed Design
>>> 
>>> Our vision ofindexed()bypasses duplicated index generation with their 
>>> potentially high computation costs. We'd create an iterator that calculates 
>>> each index once and then applies that index to subscript the collection. 
>>> Implementation would take place throughIndexedSequence, similar 
>>> toEnumeratedSequence.
>>> 
>>> Impact on Existing Code
>>> 
>>> This proposal is purely additive and has no impact on existing code.
>>> 
>>> Alternatives Considered
>>> Not yet
>>> 
>>> 
>>> 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Tim Vermeulen via swift-evolution]

This wasn’t the default behaviour because `enumerated()` is a method for the 
`Sequence` protocol, which doesn’t have any indices. Integers are the only 
thing that make sense there. But I agree that this should have been part of the 
standard library already.

> +1.One of those things where you wonder why this wasn't the default behavior.
> 
> ~Robert Widmann
> 
> 2016/09/28 14:23、Nevin Brackett-Rozinsky via 
> swift-evolutionのメッセージ:
> 
> > +1, I have been mildly surprised that this was not already present.
> > 
> > My workaround heretofore has been:
> > 
> > for idx in abc.indices {
> > let val = abc[i]
> > // do something with idx and val
> > }
> > 
> > Nevin
> > 
> > 
> > On Wed, Sep 28, 2016 at 1:55 PM, Erica Sadun via 
> > swift-evolutionwrote:
> > > Gist here:https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
> > > 
> > > Introducingindexed()collections
> > > Proposal: TBD
> > > Author:Erica Sadun(https://github.com/erica),Nate 
> > > Cook(https://github.com/natecook1000),Jacob 
> > > Bandes-Storch(https://github.com/jtbandes),Kevin 
> > > Ballard(https://github.com/kballard)
> > > Status: TBD
> > > Review manager: TBD
> > > 
> > > Introduction
> > > 
> > > This proposal introducesindexed()to the standard library, a method on 
> > > collections that returns an (index, element) tuple sequence.
> > > 
> > > 
> > > Swift-evolution thread:TBD(https://gist.github.com/erica/tbd)
> > > 
> > > Motivation
> > > 
> > > The standard library'senumerated()method returns a sequence of pairs 
> > > enumerating a sequence. The pair's first member is a monotonically 
> > > incrementing integer starting at zero, and the second member is the 
> > > corresponding element of the sequence. When working with arrays, the 
> > > integer is coincidentally the same type and value as anArrayindex but the 
> > > enumerated value is not generated with index-specific semantics. This may 
> > > lead to confusion when developers attempt to subscript a non-array 
> > > collection with enumerated integers. It can introduce serious bugs when 
> > > developers useenumerated()-based integer subscripting with non-zero-based 
> > > array slices.
> > > 
> > > 
> > > Indices have a specific, fixed meaning in Swift, which are used to create 
> > > valid collection subscripts. This proposal introducesindexed()to produce 
> > > a more semantically relevant sequence by pairing a 
> > > collection'sindiceswith its members. While it is trivial to create a 
> > > solution in Swift, the most common developer approach shown here 
> > > calculates indexes twice:
> > > 
> > > extension Collection {   /// Returns a sequence of pairs (*idx*, *x*), 
> > > where *idx* represents a   /// consecutive collection index, and *x* 
> > > represents an element of   /// the sequence.   func indexed() 
> > > ->Zip2Sequence{ return zip(indices, self)   } }
> > > 
> > > Incrementing an index in some collections can be unnecessarily costly. In 
> > > a lazy filtered collection, an index increment is potentially O(N). We 
> > > feel this is better addressed introducing a new function into the 
> > > Standard Library to provide a more efficient design that avoids the 
> > > attractive nuisance of the "obvious" solution.
> > > 
> > > Detailed Design
> > > 
> > > Our vision ofindexed()bypasses duplicated index generation with their 
> > > potentially high computation costs. We'd create an iterator that 
> > > calculates each index once and then applies that index to subscript the 
> > > collection. Implementation would take place throughIndexedSequence, 
> > > similar toEnumeratedSequence.
> > > 
> > > Impact on Existing Code
> > > 
> > > This proposal is purely additive and has no impact on existing code.
> > > 
> > > Alternatives Considered
> > > Not yet
> > > 
> > > 
> > > 
> > > ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > 
> > 
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Conditional conformances

[plx via swift-evolution]

It’s good to see this starting to happen!

Is the decision on "no-overlapping-conformances” something that’s seen-as set 
in stone permanently, set in stone for the near future, or perhaps at least 
somewhat open to reconsideration at the present moment?

> On Sep 26, 2016, at 7:18 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Conditional conformances
> 
> Proposal: SE- 
> 
> Author: Doug Gregor 
> Review Manager: TBD
> Status: Awaiting review
> During the review process, add the following fields as needed:
> 
> Decision Notes: Rationale 
> , Additional Commentary 
> 
> Bugs: SR- , SR- 
> 
> Previous Revision: 1 
> 
> Previous Proposal: SE- 
> 
>  
> Introduction
> 
> Conditional conformances express the notion that a generic type will conform 
> to a particular protocol only when it's type arguments meet certain 
> requirements. For example, the Array collection can implement the Equatable 
> protocol only when its elements are themselves Equatable, which can be 
> expressed via the following conditional conformance on Equatable:
> 
> extension Array: Equatable where Element: Equatable {
>   static func ==(lhs: Array, rhs: Array) -> Bool { ... }
> }
> This feature is part of the generics manifesto 
> 
>  because it's something that fits naturally into the generics model and is 
> expected to have a high impact on the Swift standard library.
> 
> Swift-evolution thread: TBD: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> Conditional conformances address a hole in the composability of the generics 
> system. Continuing the Array example from above, it's always been the case 
> that one could use the == operator on two arrays of Equatable type, e.g., 
> [Int]() == [Int]() would succeed. However, it doesn't compose: arrays of 
> arrays of Equatable types cannot be compared (e.g.,[Int] 
> ==
>  [Int] 
> will
>  fail to compile) because, even though there is an==for arrays of 
> Equatabletype, the arrays themselves are neverEquatable`.
> 
> Conditional conformances are particularly powerful when building generic 
> adapter types, which are intended to reflect the capabilities of their type 
> arguments. For example, consider the "lazy" functionality of the Swift 
> standard library's collections: using the lazy member of a sequence produces 
> a lazy adapter that conforms to the Sequence protocol, while using the lazy 
> member of a collection produces a lazy adapter that conforms to the 
> Collection protocol. In Swift 3, the only way to model this is with different 
> types. For example, the Swift standard library has four similar generic types 
> to handle a lazy collection: LazySequence, LazyCollection, 
> LazyBidirectionalCollection, and LazyRandomAccessCollection. The Swift 
> standard library uses overloading of the lazy property to decide among these:
> 
> extension Sequence {
>   var lazy: LazySequence { ... }
> }
> 
> extension Collection {
>   var lazy: LazyCollection { ... }
> }
> 
> extension BidirectionalCollection {
>   var lazy: LazyBidirectionalCollection { ... }
> }
> 
> extension RandomAccessCollection {
>   var lazy: LazyRandomAccessCollection { ... }
> }
> This approach causes an enormous amount of repetition, and doesn't scale well 
> because each more-capable type has to re-implement (or somehow forward the 
> implementation of) all of the APIs of the less-capable versions. With 
> conditional conformances, one can provide a single generic wrapper type whose 
> basic requirements meet the lowest common denominator (e.g., Sequence), but 
> which scale their capabilities with their type argument (e.g., the 
> LazySequence conforms to Collection when the type argument does, and so on).
> 
>  
> Proposed
>  solution
> 
> In a nutshell, the proposed solution is to allow a constrained extension of a 
> struct, enum, or 

Re: [swift-evolution] [Proposal draft] Conditional conformances

[Jordan Rose via swift-evolution]

> On Sep 28, 2016, at 9:51, Douglas Gregor  wrote:
> 
> 
>> On Sep 27, 2016, at 5:06 PM, Jordan Rose > > wrote:
>> 
>> Great job thinking this all through (as usual), and I’ll be very happy to 
>> have Optional and Array become Equatable. Here’s some of my thoughts on the 
>> library evolution aspect of this:
>> 
>> - Removing a conditional conformance isn’t allowed, obviously.
>> - Adding a conditional conformance is just like adding an unconditional 
>> conformance—it needs availability info.
> 
> Right. The main wrinkle I see here is that, when you add a conditional 
> conformance, you will effectively end up with overlapping conformances when 
> running an old application against a new library. Do you want me to capture 
> these cases in the proposal in a section on “Resilience” or “Library 
> Evolution”, like I’ve tried to capture the effect on ABI Stability? (I think 
> that makes sense)

Sure, yes please. (I think the main point is that the "conditional" doesn't 
make a difference here.)


> 
>> - It would be nice™ if making a conditional conformance more general was 
>> allowed. Since the plan doesn't allow overlapping conformances, I think this 
>> is actually implementable: just don’t put the constraints in the symbol 
>> name. I don’t know how to represent the backwards-deploying aspects of this 
>> right now, so it probably makes sense to forbid it today, but I think it 
>> would be nice if the implementation left the door open.
> 
> Yeah. It’s a different set of witness tables that one would need to gather to 
> use the conditional conformance in the newer version of the library vs. in an 
> older version of a library. That’s okay if we leave the 
> witness-table-gathering to the runtime, but not so great if we statically 
> provide the witness tables.

This confuses me. Why aren't we just using the minimal (unconditional) 
conformance representation, and then pulling the associated type witness tables 
out dynamically? Is that significantly more expensive? (Am I just missing 
something?)


> 
> 
>> On that note, what happens here?
>> 
>> // Module Lib
>> public protocol Base {}
>> public protocol Sub: Base {}
>> public protocol Special: Sub {}
>> 
>> public struct Impl {}
>> extension Impl: Special where T: Special {}
>> 
>> 
>> // Module Client
>> import Lib
>> 
>> extension Impl: Sub where T: Sub {}
>> 
>> I think this gets rejected because Impl already has a conformance to Sub—the 
>> extension in Client, despite being less specialized, shows up too late to 
>> actually declare this conformance “better”. Is that correct?
> 
> Correct. Impl has a conformance to ‘Sub’ in Lib; Client cannot declare a new 
> one, because it overlaps.  Had all of this code been in one module, it would 
> be well-formed, because the implied conformance to ’Sub’ in the first 
> extension would lose to the explicit conformance to Sub in the second 
> (less-specialized) extension.

Thanks!

Jordan

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

Re: [swift-evolution] associated objects

[Jay Abbott via swift-evolution]

Hey Robert,

Well the example I gave was stored properties in extensions - that is they
can be easily implemented as calculated properties that actually use
associated objects/values to store their value. The other one is
per-instance actions, programmers can dynamically add an action (closure)
to any instance (for example decide where it needs to be sent and add a
closure with the key "send"), then that action can be performed later by
retrieving whatever is in "send" and calling it - basically whenever
functionality rather than data needs to be moved around.

I agree it's not an efficient or type-safe system, but of course any
developer using it is doing so at run-time so they know there's no
type-checking going on and should take measures to ensure only the correct
types are put into any situation (or check it themselves). It *can* be
implemented without affecting the ABI - as my example code shows, I'm just
not sure if this is a good way to do it.

I'm not sure what you mean about obj-c associated objects having a slow
deallocation path, is there a learning-point from the obj-c implementation
that helps here? If so I don't know it :) I don't think you would try to
make it type-safe as it's a dynamic feature and you'd expect the users to
do that themselves - sure there could be ways to use reflection to help
out, but is this necessary?

As noted in the README - deinit hooks would enable an implementation that
doesn't need to do the internal clean-up. So it works as-is, but could be
improved with some language features.


On Wed, 28 Sep 2016 at 19:46 Goffredo Marocchi  wrote:

>
>
> Sent from my iPhone
>
> On 28 Sep 2016, at 17:27, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Have you got a significant use-case for this that absolutely can't be
> solved by extensions or subclassing?
>
> This does have ABI impact but more concerning for me is the performance
> impact and that the existing API is not type safe.
>
> Using associated objects in ObjC gets you read through the slowest
> possible deallocation paths and means the runtime is effectively tracking
> an extra table of pointer tables per object-with-associations.  To make
> this kind of pattern type safe you would, for example, need to keep track
> metatype pointers too and use the dynamic cast machinery to check the type
> on retrieval.
>
>
> If observers, whose lifetime is longer than the the observed objects' one,
> were notified when the observed object is deallocated then I would agree
> with you about safety concerns trumping usability... but as it is right now
> a nice mechanism like KVO is made trickier to use than it should be without
> associated objects (KVO leakage is quite a scary concept :)).
>
>
> ~Robert Widmann
>
> 2016/09/28 11:26、Jay Abbott via swift-evolution 
> のメッセージ:
>
> I have implemented Associated Objects (and values) in pure swift here:
> https://github.com/j-h-a/AssociatedObjects
>
> The README is very short and straight-forward so I won't re-describe it
> here.
>
> The implementation isn't great, but it's a small and simple proof of
> concept. I have further extended this (not in GH, but very simple and happy
> to share if anyone cares) to add dynamic methods using closures onto
> individual object instances. Useful for user interactions, or adding
> 'actions' to objects.
>
> I'd like to propose that this or something similar be added to the
> standard library. It could potentially even be added to AnyObject so that
> developers can use it without having to declare an extension for whichever
> classes they want to use it on.
>
> As mentioned, this can easily be extended (either in the standard library
> or by developers) to add closures dynamically to any object, or to any
> class, which could serve as a useful way for those not concerned with type
> safety and the like to get some dynamic behaviour in there in the shorter
> term. With a little language support it could even be used to implement
> stored properties in extensions very easily.
>
> A better implementation would need some language changes - specifically
> deinit hooks (has that ever been discussed?) because of the way weak
> references are lazily zeroed. Another implementation improvement might
> lazily add the dictionary to each object instead of storing it globally -
> not sure if this would have ABI implications.
>
> Interested in feedback and thoughts :)
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Jay Abbott via swift-evolution]

One (potentially dumb) question...

If the actual indices are needed inside the loop, presumably this means
they will be used in the loop, perhaps to mutate it, and if the collection
is mutated won't that either invalidate (or change the relative
correspondence of) the others indices, because the collection accessed in
the loop will be the mutated one whereas the indices refer to the copy that
was taken at the start when the 'for' statement was evaluated?



On Wed, 28 Sep 2016 at 19:34 Sean Heber via swift-evolution <
swift-evolution@swift.org> wrote:

> This might just be me being silly, but is there any way to be able to do
> something like this instead:
>
> for (index, value) in sequence {
> }
>
> Maybe by adding another variant of makeIterator() that only differs by the
> return type or something like that?
>
> I sort of dislike that enumerated() and indexed() would co-exist and
> potentially lead to really subtle bugs when getting them confused.
> Obviously removing enumerated() would be a breaking change, though, and
> maybe it has valuable uses that I’m not really thinking about (although it
> seems to me that the index/value pair is what you want like, 99% of the
> time and plenty of people - myself included - have been using the index of
> enumerated() as an array index even though that’s technically maybe not
> quite ‘correct').
>
> l8r
> Sean
>
>
> > On Sep 28, 2016, at 12:55 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Gist here:
> https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
> >
> > Introducing indexed() collections
> >
> >   • Proposal: TBD
> >   • Author: Erica Sadun, Nate Cook, Jacob Bandes-Storch, Kevin
> Ballard
> >   • Status: TBD
> >   • Review manager: TBD
> > Introduction
> >
> > This proposal introduces indexed() to the standard library, a method on
> collections that returns an (index, element) tuple sequence.
> >
> > Swift-evolution thread: TBD
> >
> > Motivation
> >
> > The standard library's enumerated() method returns a sequence of pairs
> enumerating a sequence. The pair's first member is a monotonically
> incrementing integer starting at zero, and the second member is the
> corresponding element of the sequence. When working with arrays, the
> integer is coincidentally the same type and value as an Array index but the
> enumerated value is not generated with index-specific semantics. This may
> lead to confusion when developers attempt to subscript a non-array
> collection with enumerated integers. It can introduce serious bugs when
> developers use enumerated()-based integer subscripting with non-zero-based
> array slices.
> >
> > Indices have a specific, fixed meaning in Swift, which are used to
> create valid collection subscripts. This proposal introduces indexed() to
> produce a more semantically relevant sequence by pairing a collection's
> indices with its members. While it is trivial to create a solution in
> Swift, the most common developer approach shown here calculates indexes
> twice:
> >
> > extension Collection {
> > /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents
> a
> > /// consecutive collection index, and *x* represents an element of
> > /// the sequence.
> > func indexed() -> Zip2Sequence {
> > return zip(indices, self)
> > }
> > }
> >
> > Incrementing an index in some collections can be unnecessarily costly.
> In a lazy filtered collection, an index increment is potentially O(N). We
> feel this is better addressed introducing a new function into the Standard
> Library to provide a more efficient design that avoids the attractive
> nuisance of the "obvious" solution.
> >
> > Detailed Design
> >
> > Our vision of indexed() bypasses duplicated index generation with their
> potentially high computation costs. We'd create an iterator that calculates
> each index once and then applies that index to subscript the collection.
> Implementation would take place through IndexedSequence, similar to
> EnumeratedSequence.
> >
> > Impact on Existing Code
> >
> > This proposal is purely additive and has no impact on existing code.
> >
> > Alternatives Considered
> >
> > Not yet
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Conditional conformances

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 28 Sep 2016, at 19:45, Douglas Gregor  wrote:
> 
> 
>> On Sep 28, 2016, at 11:40 AM, Goffredo Marocchi  wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 28 Sep 2016, at 17:51, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Sep 27, 2016, at 5:06 PM, Jordan Rose  wrote:
 
 Great job thinking this all through (as usual), and I’ll be very happy to 
 have Optional and Array become Equatable. Here’s some of my thoughts on 
 the library evolution aspect of this:
 
 - Removing a conditional conformance isn’t allowed, obviously.
 - Adding a conditional conformance is just like adding an unconditional 
 conformance—it needs availability info.
>>> 
>>> Right. The main wrinkle I see here is that, when you add a conditional 
>>> conformance, you will effectively end up with overlapping conformances when 
>>> running an old application against a new library. Do you want me to capture 
>>> these cases in the proposal in a section on “Resilience” or “Library 
>>> Evolution”, like I’ve tried to capture the effect on ABI Stability? (I 
>>> think that makes sense)
>>> 
 - It would be nice™ if making a conditional conformance more general was 
 allowed. Since the plan doesn't allow overlapping conformances, I think 
 this is actually implementable: just don’t put the constraints in the 
 symbol name. I don’t know how to represent the backwards-deploying aspects 
 of this right now, so it probably makes sense to forbid it today, but I 
 think it would be nice if the implementation left the door open.
>>> 
>>> Yeah. It’s a different set of witness tables that one would need to gather 
>>> to use the conditional conformance in the newer version of the library vs. 
>>> in an older version of a library. That’s okay if we leave the 
>>> witness-table-gathering to the runtime, but not so great if we statically 
>>> provide the witness tables.
>>> 
>> 
>> Would this be a case in which the win by having this feature and letting the 
>> runtime gather the witness tables offset the losses from doing his 
>> operations at runtime? I would like to think that in cases like this there 
>> is at least the option to opt for more flexibility.
> 
> 
> I’m sure we can find a reasonable solution to this that doesn’t incur a 
> significant runtime penalty, e.g., by teaching the runtime conformance 
> specialization machinery to handle a “redirecting” specialization that maps 
> from the requirements of the older (more specialized) version to the 
> requirements of the newer (less specialized) version.
> 
>   - Doug
> 

Very glad to hear that Doug :).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Conditional conformances

[Douglas Gregor via swift-evolution]

> On Sep 28, 2016, at 11:40 AM, Goffredo Marocchi  wrote:
> 
> 
> 
> Sent from my iPhone
> 
> On 28 Sep 2016, at 17:51, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> 
>>> On Sep 27, 2016, at 5:06 PM, Jordan Rose >> > wrote:
>>> 
>>> Great job thinking this all through (as usual), and I’ll be very happy to 
>>> have Optional and Array become Equatable. Here’s some of my thoughts on the 
>>> library evolution aspect of this:
>>> 
>>> - Removing a conditional conformance isn’t allowed, obviously.
>>> - Adding a conditional conformance is just like adding an unconditional 
>>> conformance—it needs availability info.
>> 
>> Right. The main wrinkle I see here is that, when you add a conditional 
>> conformance, you will effectively end up with overlapping conformances when 
>> running an old application against a new library. Do you want me to capture 
>> these cases in the proposal in a section on “Resilience” or “Library 
>> Evolution”, like I’ve tried to capture the effect on ABI Stability? (I think 
>> that makes sense)
>> 
>>> - It would be nice™ if making a conditional conformance more general was 
>>> allowed. Since the plan doesn't allow overlapping conformances, I think 
>>> this is actually implementable: just don’t put the constraints in the 
>>> symbol name. I don’t know how to represent the backwards-deploying aspects 
>>> of this right now, so it probably makes sense to forbid it today, but I 
>>> think it would be nice if the implementation left the door open.
>> 
>> Yeah. It’s a different set of witness tables that one would need to gather 
>> to use the conditional conformance in the newer version of the library vs. 
>> in an older version of a library. That’s okay if we leave the 
>> witness-table-gathering to the runtime, but not so great if we statically 
>> provide the witness tables.
>> 
> 
> Would this be a case in which the win by having this feature and letting the 
> runtime gather the witness tables offset the losses from doing his operations 
> at runtime? I would like to think that in cases like this there is at least 
> the option to opt for more flexibility.


I’m sure we can find a reasonable solution to this that doesn’t incur a 
significant runtime penalty, e.g., by teaching the runtime conformance 
specialization machinery to handle a “redirecting” specialization that maps 
from the requirements of the older (more specialized) version to the 
requirements of the newer (less specialized) version.

- Doug

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

Re: [swift-evolution] [Draft] Availability by Swift version

[Dave Abrahams via swift-evolution]

on Thu Sep 22 2016, Graydon Hoare  wrote:

> Hi,
>
> The following is a proposal for a very minor extension of the @available 
> system. Hopefully uncontroversial!
>
> Thanks,
>
> -Graydon
>
> # Availability by Swift version
>
> * Proposal: [SE-](-available-by-swift-version.md)
> * Authors: [Graydon Hoare](https://github.com/graydon)
> * Review Manager: TBD
> * Status: **Awaiting review**
>
> ## Introduction
>
> Swift's existing `@available(...)` attribute indicates the lifecycle of a
> given declaration, either unconditionally or relative to a particular
> platform or OS version range.
>
> It does not currently support indicating declaration lifecycle relative to
> Swift language versions. This proposal seeks to extend it to do so.
>
> ## Motivation
>
> As the Swift language progresses from one version to the next, some
> declarations will be added, renamed, deprecated or removed from the
> standard library. Existing code written for earlier versions of Swift will
> be supported through a `-swift-version N` command-line flag, that runs the
> compiler in a backward-compatibility mode for the specified "effective"
> language version.
>
> When running in a backward-compatibility mode, the set of available
> standard library declarations should change to match expectations of older
> code. Currently the only mechanism for testing a language version is the
> compiler-control statement `#if swift(>= N)` which is a static construct:
> it can be used to compile-out a declaration from the standard library, but
> evolving the standard library through this mechanism would necessitate
> compiling the standard library once for each supported older language
> version.
>
> It would be preferable to compile the standard library _once_ for all
> supported language versions, but make declarations _conditionally
> available_ depending on the effective language version of a _user_ of the
> library. The existing `@available(...)` attribute is similar to this
> use-case, and this proposal seeks to extend the attribute to support it.
>
> ## Proposed solution
>
> The `@available(...)` attribute will be extended to support specifying
> `swift` version numbers, in addition to its existing platform versions.
>
> As an example, an API that is removed in Swift 3.1 will be written
> as:
>
> 
> @available(swift, obsoleted: 3.1)
> class Foo {
>   //...
> }
> 
>
> When compiling _user code_ in `-swift-version 3.0` mode, this declaration
> would be available, but not when compiling in subsequent versions.
>
> ## Detailed design
>
> The token `swift` will be added to the set of valid initial arguments
> to the `@available(...)` attribute. It will be treated similarly,
> but slightly differently, than the existing platform arguments. In
> particular:
>
>   - As with platform-based availability judgments, a declaration's
> `swift` version availability will default to available-everywhere
> if unspecified.
>
>   - A declaration's `swift` version availability will be considered
> in logical conjunction with its platform-based availability.
> That is, a given declaration will be available if and only
> if it is _both_ available to the current effective `swift` version
> _and_ available to the current deployment-target platform.
>
>   - Similar to the abbreviated form of platform availability, an
> abbreviated form `@available(swift N)` will be permitted as a synonym
> for `@available(swift, introduced: N)`. However, adding `swift` to
> a platform availability abbreviation list will not be allowed. That is,
> writing the following examples is not permitted:
>
> - `@available(swift 3, *)`
> - `@available(swift 3, iOS 10, *)`
>
> This restriction is due to the fact that platform-availability lists
> are interpreted disjunctively (as a logical-_OR_ of their arguments),
> and adding a conjunct (logical-_AND_) to such a list would make
> the abbreviation potentially ambiguous to readers.
>
> ## Impact on existing code
>
> Existing code does not use this form of attribute, so will not be
> affected at declaration-site.
>
> As declarations are annotated as unavailable or obsoleted via
> this attribute, some user code may stop working, but the same risk exists
> (with a worse user experience) in today's language any time declarations
> are removed or conditionally-compiled out. The purpose of this proposal
> is to provide a better user experience around such changes, and facilitate
> backward-compatibility modes.
>
> ## Alternatives considered
>
> The main alternative is compiling libraries separately for each language
> version and using `#if swift(>=N)` to conditionally include varying APIs.
> For a library used locally within a single project, recompiling for a
> specific language version may be appropriate, but for shipping the standard
> library it is more economical to compile once with all declarations, and
> select a subset based on 

Re: [swift-evolution] [Proposal draft] Conditional conformances

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 28 Sep 2016, at 17:51, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Sep 27, 2016, at 5:06 PM, Jordan Rose  wrote:
>> 
>> Great job thinking this all through (as usual), and I’ll be very happy to 
>> have Optional and Array become Equatable. Here’s some of my thoughts on the 
>> library evolution aspect of this:
>> 
>> - Removing a conditional conformance isn’t allowed, obviously.
>> - Adding a conditional conformance is just like adding an unconditional 
>> conformance—it needs availability info.
> 
> Right. The main wrinkle I see here is that, when you add a conditional 
> conformance, you will effectively end up with overlapping conformances when 
> running an old application against a new library. Do you want me to capture 
> these cases in the proposal in a section on “Resilience” or “Library 
> Evolution”, like I’ve tried to capture the effect on ABI Stability? (I think 
> that makes sense)
> 
>> - It would be nice™ if making a conditional conformance more general was 
>> allowed. Since the plan doesn't allow overlapping conformances, I think this 
>> is actually implementable: just don’t put the constraints in the symbol 
>> name. I don’t know how to represent the backwards-deploying aspects of this 
>> right now, so it probably makes sense to forbid it today, but I think it 
>> would be nice if the implementation left the door open.
> 
> Yeah. It’s a different set of witness tables that one would need to gather to 
> use the conditional conformance in the newer version of the library vs. in an 
> older version of a library. That’s okay if we leave the 
> witness-table-gathering to the runtime, but not so great if we statically 
> provide the witness tables.
> 

Would this be a case in which the win by having this feature and letting the 
runtime gather the witness tables offset the losses from doing his operations 
at runtime? I would like to think that in cases like this there is at least the 
option to opt for more flexibility.

> 
>> On that note, what happens here?
>> 
>> // Module Lib
>> public protocol Base {}
>> public protocol Sub: Base {}
>> public protocol Special: Sub {}
>> 
>> public struct Impl {}
>> extension Impl: Special where T: Special {}
>> 
>> 
>> // Module Client
>> import Lib
>> 
>> extension Impl: Sub where T: Sub {}
>> 
>> I think this gets rejected because Impl already has a conformance to Sub—the 
>> extension in Client, despite being less specialized, shows up too late to 
>> actually declare this conformance “better”. Is that correct?
> 
> Correct. Impl has a conformance to ‘Sub’ in Lib; Client cannot declare a new 
> one, because it overlaps.  Had all of this code been in one module, it would 
> be well-formed, because the implied conformance to ’Sub’ in the first 
> extension would lose to the explicit conformance to Sub in the second 
> (less-specialized) extension.
> 
>   - Doug
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Sean Heber via swift-evolution]

This might just be me being silly, but is there any way to be able to do 
something like this instead:

for (index, value) in sequence {
}

Maybe by adding another variant of makeIterator() that only differs by the 
return type or something like that?

I sort of dislike that enumerated() and indexed() would co-exist and 
potentially lead to really subtle bugs when getting them confused. Obviously 
removing enumerated() would be a breaking change, though, and maybe it has 
valuable uses that I’m not really thinking about (although it seems to me that 
the index/value pair is what you want like, 99% of the time and plenty of 
people - myself included - have been using the index of enumerated() as an 
array index even though that’s technically maybe not quite ‘correct').

l8r
Sean


> On Sep 28, 2016, at 12:55 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Gist here: https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
> 
> Introducing indexed() collections
> 
>   • Proposal: TBD
>   • Author: Erica Sadun, Nate Cook, Jacob Bandes-Storch, Kevin Ballard
>   • Status: TBD
>   • Review manager: TBD
> Introduction
> 
> This proposal introduces indexed() to the standard library, a method on 
> collections that returns an (index, element) tuple sequence.
> 
> Swift-evolution thread: TBD
> 
> Motivation
> 
> The standard library's enumerated() method returns a sequence of pairs 
> enumerating a sequence. The pair's first member is a monotonically 
> incrementing integer starting at zero, and the second member is the 
> corresponding element of the sequence. When working with arrays, the integer 
> is coincidentally the same type and value as an Array index but the 
> enumerated value is not generated with index-specific semantics. This may 
> lead to confusion when developers attempt to subscript a non-array collection 
> with enumerated integers. It can introduce serious bugs when developers use 
> enumerated()-based integer subscripting with non-zero-based array slices.
> 
> Indices have a specific, fixed meaning in Swift, which are used to create 
> valid collection subscripts. This proposal introduces indexed() to produce a 
> more semantically relevant sequence by pairing a collection's indices with 
> its members. While it is trivial to create a solution in Swift, the most 
> common developer approach shown here calculates indexes twice: 
> 
> extension Collection {
> /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents a
> /// consecutive collection index, and *x* represents an element of
> /// the sequence.
> func indexed() -> Zip2Sequence {
> return zip(indices, self)
> }
> }
> 
> Incrementing an index in some collections can be unnecessarily costly. In a 
> lazy filtered collection, an index increment is potentially O(N). We feel 
> this is better addressed introducing a new function into the Standard Library 
> to provide a more efficient design that avoids the attractive nuisance of the 
> "obvious" solution.
> 
> Detailed Design
> 
> Our vision of indexed() bypasses duplicated index generation with their 
> potentially high computation costs. We'd create an iterator that calculates 
> each index once and then applies that index to subscript the collection. 
> Implementation would take place through IndexedSequence, similar to 
> EnumeratedSequence.
> 
> Impact on Existing Code
> 
> This proposal is purely additive and has no impact on existing code.
> 
> Alternatives Considered
> 
> Not yet
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Robert Widmann via swift-evolution]

+1.  One of those things where you wonder why this wasn't the default behavior.

~Robert Widmann

2016/09/28 14:23、Nevin Brackett-Rozinsky via swift-evolution 
 のメッセージ:

> +1, I have been mildly surprised that this was not already present.
> 
> My workaround heretofore has been:
> 
> for idx in abc.indices {
>   let val = abc[i]
>   // do something with idx and val
> }
> 
> Nevin
> 
> 
>> On Wed, Sep 28, 2016 at 1:55 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> Gist here: https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
>> 
>> Introducing indexed() collections
>> Proposal: TBD
>> Author: Erica Sadun, Nate Cook, Jacob Bandes-Storch, Kevin Ballard
>> Status: TBD
>> Review manager: TBD
>> Introduction
>> 
>> This proposal introduces indexed() to the standard library, a method on 
>> collections that returns an (index, element) tuple sequence.
>> 
>> Swift-evolution thread: TBD
>> 
>> Motivation
>> 
>> The standard library's enumerated() method returns a sequence of pairs 
>> enumerating a sequence. The pair's first member is a monotonically 
>> incrementing integer starting at zero, and the second member is the 
>> corresponding element of the sequence. When working with arrays, the integer 
>> is coincidentally the same type and value as an Array index but the 
>> enumerated value is not generated with index-specific semantics. This may 
>> lead to confusion when developers attempt to subscript a non-array 
>> collection with enumerated integers. It can introduce serious bugs when 
>> developers use enumerated()-based integer subscripting with non-zero-based 
>> array slices.
>> 
>> Indices have a specific, fixed meaning in Swift, which are used to create 
>> valid collection subscripts. This proposal introduces indexed() to produce a 
>> more semantically relevant sequence by pairing a collection's indices with 
>> its members. While it is trivial to create a solution in Swift, the most 
>> common developer approach shown here calculates indexes twice: 
>> 
>> extension Collection {
>> /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents a
>> /// consecutive collection index, and *x* represents an element of
>> /// the sequence.
>> func indexed() -> Zip2Sequence {
>> return zip(indices, self)
>> }
>> }
>> Incrementing an index in some collections can be unnecessarily costly. In a 
>> lazy filtered collection, an index increment is potentially O(N). We feel 
>> this is better addressed introducing a new function into the Standard 
>> Library to provide a more efficient design that avoids the attractive 
>> nuisance of the "obvious" solution.
>> 
>> Detailed Design
>> 
>> Our vision of indexed() bypasses duplicated index generation with their 
>> potentially high computation costs. We'd create an iterator that calculates 
>> each index once and then applies that index to subscript the collection. 
>> Implementation would take place through IndexedSequence, similar to 
>> EnumeratedSequence.
>> 
>> Impact on Existing Code
>> 
>> This proposal is purely additive and has no impact on existing code.
>> 
>> Alternatives Considered
>> 
>> Not yet
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

[Nevin Brackett-Rozinsky via swift-evolution]

+1, I have been mildly surprised that this was not already present.

My workaround heretofore has been:

for idx in abc.indices {
  let val = abc[i]
  // do something with idx and val
}

Nevin


On Wed, Sep 28, 2016 at 1:55 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> Gist here: https://gist.github.com/erica/2b2d92e6db787d001c689d3e37a7c3f2
>
> Introducing indexed() collections
>
>- Proposal: TBD
>- Author: Erica Sadun , Nate Cook
>, Jacob Bandes-Storch
>, Kevin Ballard
>
>- Status: TBD
>- Review manager: TBD
>
>
> 
> Introduction
>
> This proposal introduces indexed() to the standard library, a method on
> collections that returns an (index, element) tuple sequence.
>
> Swift-evolution thread: TBD 
> 
> Motivation
>
> The standard library's enumerated() method returns a sequence of pairs
> enumerating a sequence. The pair's first member is a monotonically
> incrementing integer starting at zero, and the second member is the
> corresponding element of the sequence. When working with arrays, the
> integer is coincidentally the same type and value as an Array index but
> the enumerated value is not generated with index-specific semantics. This
> may lead to confusion when developers attempt to subscript a non-array
> collection with enumerated integers. It can introduce serious bugs when
> developers use enumerated()-based integer subscripting with
> non-zero-based array slices.
>
> Indices have a specific, fixed meaning in Swift, which are used to create
> valid collection subscripts. This proposal introduces indexed() to
> produce a more semantically relevant sequence by pairing a collection's
> indices with its members. While it is trivial to create a solution in
> Swift, the most common developer approach shown here calculates indexes
> twice:
>
> extension Collection {
> /// Returns a sequence of pairs (*idx*, *x*), where *idx* represents a
> /// consecutive collection index, and *x* represents an element of
> /// the sequence.
> func indexed() -> Zip2Sequence {
> return zip(indices, self)
> }
> }
>
> Incrementing an index in some collections can be unnecessarily costly. In
> a lazy filtered collection, an index increment is potentially O(N). We feel
> this is better addressed introducing a new function into the Standard
> Library to provide a more efficient design that avoids the attractive
> nuisance of the "obvious" solution.
>
> Detailed
> Design
>
> Our vision of indexed() bypasses duplicated index generation with their
> potentially high computation costs. We'd create an iterator that calculates
> each index once and then applies that index to subscript the collection.
> Implementation would take place through IndexedSequence, similar to
> EnumeratedSequence.
>
> Impact
> on Existing Code
>
> This proposal is purely additive and has no impact on existing code.
>
> Alternatives
> Considered
> Not yet
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] draft proposals should be easier to find

[David Waite via swift-evolution]

I think other projects use issue trackers for these sorts of topics (rather 
than mailing lists) primarily for the ability to capture summaries, allow 
searching, capture relationships (duplicates ,etc), and indicate something is 
deferred to a particular milestone (say swift 4 phase 2). 

Not to segue the mailing list vs forum discussion again.

-DW

> On Sep 28, 2016, at 11:42 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Sep 28, 2016, at 8:34 AM, Jay Abbott via swift-evolution 
>>  wrote:
>> 
>> I don't really understand this concept of only accepting proposals for a 
>> specific round. I saw some ideas that were suitable for future rounds of 
>> proposals but not right now... Why aren't they captured in a better format 
>> than the mailing list archive? If you don't want to be distracted by future 
>> things then capture them as proposals but file them out of the way a bit so 
>> that people can see they exist - I would have thought this would decrease 
>> distractions from people bringing them up again.
> 
> We have a list of frequently rejected proposals.  I think it would be 
> reasonable to have an index of discussions and even written proposals in 
> areas of topics that are “deferred” because they are out of scope for the 
> current release, but not rejected.
> 
> -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] draft proposals should be easier to find

[Chris Lattner via swift-evolution]

> On Sep 28, 2016, at 8:34 AM, Jay Abbott via swift-evolution 
>  wrote:
> 
> I don't really understand this concept of only accepting proposals for a 
> specific round. I saw some ideas that were suitable for future rounds of 
> proposals but not right now... Why aren't they captured in a better format 
> than the mailing list archive? If you don't want to be distracted by future 
> things then capture them as proposals but file them out of the way a bit so 
> that people can see they exist - I would have thought this would decrease 
> distractions from people bringing them up again.

We have a list of frequently rejected proposals.  I think it would be 
reasonable to have an index of discussions and even written proposals in areas 
of topics that are “deferred” because they are out of scope for the current 
release, but not rejected.

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

Re: [swift-evolution] [Pitch] Refactor Metatypes

[Nevin Brackett-Rozinsky via swift-evolution]

Let me first say that this new draft does a great job of explaining the
current situation and the goals of the proposal. The revised “Motivation”
section in particular is very clearly written and introduces the concepts
effectively.

I found the previous versions to be highly confusing, and I did not
understand from them what was being proposed and why. After reading this
one, I feel that I finally comprehend the situation, both in terms of how
metatypes behave today and how the authors would like them to work.

This is still an area where I do not have much expertise, so I look forward
to hearing what better-versed people think of the overall approach as well
as the specific details.

Nevin



On Wed, Sep 28, 2016 at 6:18 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Formatted version: https://github.com/DevAndArtist/swift-evolution/
> blob/refactor_metatypes/proposals/0126-refactor-metatypes.md
> --
> Refactor Metatypes
>
>- Proposal: SE–0126
>
>- Authors: Adrian Zubarev , Anton
>Zhilin , Brent Royal-Gordon
>
>- Status: *Revision*
>- Review manager: Chris Lattner 
>- Revision: 2
>- Previous Revisions: 1
>
> 
>
> Introduction
>
> This proposal removes .Type and .Protocol in favor of two generic-style
> syntaxes and aligns global type(of:) function (SE–0096) to match the
> changes.
>
> Swift-evolution thread (post Swift 3):
>
>- [Pitch] Refactor Metatypes
>
> Older swift-evolution threads: [1]
> ,
> [2]
> ,
> [3]
> 
> Motivation
>
> Every type T has an instance, accessible through T.self, which represents
> the type itself. Like all instances in Swift, this “type instance” itself
> has a type, which is referred to as its “metatype”. The metatype of T is
> written T.Type. The instance members of the metatype are the same as the
> static or class members of the type.
>
> Metatypes have subtype relationships which reflect the types they
> represent. For instance, given these types:
>
> protocol Proto {}
> class Base {}
> class Derived: Base, Proto {}
>
> Derived.Type is a subtype of both Base.Type and Proto.Type (and Any.Type).
> That means that Derived.self can be used anywhere a Derived.Type,
> Base.Type, Proto.Type, or Any.Type is called for.
>
> Unfortunately, this simple picture is complicated by protocols. Proto.self
> is actually of type Proto.Protocol, not type Proto.Type. This is
> necessary because the protocol does not, and cannot, conform to itself; it
> requires conforming types to provide static members, but it doesn’t
> actually provide those members itself. Proto.Type still exists, but it is
> the supertype of all types conforming to the protocol.
>
> Making this worse, a generic type always uses T.Type to refer to the type
> of T.self. So when Proto is bound to a generic parameter P, P.Type is the
> same as Proto.Protocol.
>
> This shifting of types is complicated and confusing; we seek to clean up
> this area.
>
> We also believe that, in the long term, the dot syntax will prevent us
> from implementing certain future enhancements that might be valuable:
>
>- Moving the implementation of metatypes at least partly into the
>standard library.
>- Adding members available on all type instances for features like
>read-write reflection or memory layout information.
>- Conforming metatypes to protocols like Hashable or
>CustomStringConvertible.
>- Offering straightforward syntaxes for dynamic features like looking
>up types by name.
>
> Proposed solution
>
> We abolish .Type and .Protocol in favor of two generic-style syntaxes:
>
>-
>
>Type is the concrete type of T.self. A Type only ever has one
>instance, T.self; even if T has a subtype U, Type is not a subtype
>of Type.
>-
>
>Subtype is the supertype of all Types whose instances are subtypes
>of T, including T itself:
>-
>
>If T is a struct or enum, then Type is the only subtype of
>Subtype.
>-
>
>If T is a class, then Type and the Types of all subclasses of T are
>subtypes of Subtype.
>-
>
>If T is a protocol, then the Types of all concrete types conforming to
>T are subtypes of Subtype. Type is not itself a subtype of
>Subtype, or of any Subtype other than Subtype.
>-
>
>Structural types follow the subtype/supertype relationships of their
>

Re: [swift-evolution] [Proposal draft] Conditional conformances

[Douglas Gregor via swift-evolution]

> On Sep 28, 2016, at 2:55 AM, Anton Zhilin  wrote:
> 
> I find the limitation of non-intersection of conditional conformance 
> reqirements quite limiting. Can it be lifted in case there are no overloaded 
> functions between extensions?
> 
> protocol A { func foo() }
> protocol B { func bar() }
> 
> extension Array: A where Element: A {
> func foo() { return self.first!.foo() }
> }
> extension Array: B where Element: B {
> func bar() { return self.first!.bar() }
> }
> 
> let arr: Array
> arr.foo()
> 
> What is ambiguous here?

Nothing. These conformances are not overlapping, because A and B are 
independent protocols. The first extension declares a conditional conformance 
to A, the second declares a conditional conformance to B.

- Doug

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

Re: [swift-evolution] associated objects

[Robert Widmann via swift-evolution]

Have you got a significant use-case for this that absolutely can't be solved by 
extensions or subclassing?

This does have ABI impact but more concerning for me is the performance impact 
and that the existing API is not type safe.  

Using associated objects in ObjC gets you read through the slowest possible 
deallocation paths and means the runtime is effectively tracking an extra table 
of pointer tables per object-with-associations.  To make this kind of pattern 
type safe you would, for example, need to keep track metatype pointers too and 
use the dynamic cast machinery to check the type on retrieval.

~Robert Widmann

2016/09/28 11:26、Jay Abbott via swift-evolution  
のメッセージ:

> I have implemented Associated Objects (and values) in pure swift here:
> https://github.com/j-h-a/AssociatedObjects
> 
> The README is very short and straight-forward so I won't re-describe it here.
> 
> The implementation isn't great, but it's a small and simple proof of concept. 
> I have further extended this (not in GH, but very simple and happy to share 
> if anyone cares) to add dynamic methods using closures onto individual object 
> instances. Useful for user interactions, or adding 'actions' to objects.
> 
> I'd like to propose that this or something similar be added to the standard 
> library. It could potentially even be added to AnyObject so that developers 
> can use it without having to declare an extension for whichever classes they 
> want to use it on.
> 
> As mentioned, this can easily be extended (either in the standard library or 
> by developers) to add closures dynamically to any object, or to any class, 
> which could serve as a useful way for those not concerned with type safety 
> and the like to get some dynamic behaviour in there in the shorter term. With 
> a little language support it could even be used to implement stored 
> properties in extensions very easily.
> 
> A better implementation would need some language changes - specifically 
> deinit hooks (has that ever been discussed?) because of the way weak 
> references are lazily zeroed. Another implementation improvement might lazily 
> add the dictionary to each object instead of storing it globally - not sure 
> if this would have ABI implications.
> 
> Interested in feedback and thoughts :)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] draft proposals should be easier to find

[Jay Abbott via swift-evolution]

Maybe my wording and use of the word 'proposal' is all wrong. I still think
there's an issue that could be addressed though. Don't get me wrong - I
think the level of documentation available on swift.org about the community
process, different streams (evolution/dev/etc.) is all fantastic, still it
can be improved. This is one of those issues that it's very difficult to
see as an issue at all from the inside. I think just knowing that a
particular subject is being discussed - even if it's not a concrete or even
a draft proposal - would help people, a) to not waste their own time and
that of the list with duplicate ideas; and b) to feel more comfortable
about getting involved. Maybe an ideas board that people can +1 or -1 would
help instead - or at least keep poorly researched discussion at bay?

On Wed, 28 Sep 2016 at 16:54 Xiaodi Wu  wrote:

> I think the idea is that proposals submitted to GitHub are supposed to
> have already gone through a robust round of discussion, but the community
> can't be adequately engaged in that discussion if the topic is out of
> scope. In that case, there shouldn't be anything to capture as a proposal;
> anything written down won't have gone through the right process to bring it
> up to that point.
>
> On Wed, Sep 28, 2016 at 10:34 Jay Abbott via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I don't really understand this concept of only accepting proposals for a
>> specific round. I saw some ideas that were suitable for future rounds of
>> proposals but not right now... Why aren't they captured in a better format
>> than the mailing list archive? If you don't want to be distracted by future
>> things then capture them as proposals but file them out of the way a bit so
>> that people can see they exist - I would have thought this would decrease
>> distractions from people bringing them up again.
>>
>> On Wed, 28 Sep 2016 at 16:14 Robert Widmann 
>> wrote:
>>
>>> There's a difference between "was once discussed here" and "had a
>>> proposal submitted to Github for consideration".  If many people are
>>> producing the same ideas for proposals that exist on GitHub that poses a
>>> more pressing risk.  But it is easier to search GitHub for such proposals
>>> than the list.  For draft proposals that haven't made it yet, as long as
>>> they fall within the guidelines for proposals of a specific round, there's
>>> no reason you shouldn't be able to dig the discussion back up again and
>>> just talk about it.  Who knows, maybe you'll get a proposal submitted to
>>> GitHub that way with your name on it too - at the very least you'll learn
>>> something.  In a strange way, I guess, I'm saying we might not need this.
>>> If somebody replies "by the by, we discussed this " it's not meant to
>>> dismiss you as unoriginal.  You can use that old thread as a further
>>> jumping off point if you wish to continue discussion.
>>>
>>> tl;dr Keeping track of every idea pitched here would quickly grow...
>>> unmaintainable.
>>>
>>> ~Robert Widmann
>>>
>>> 2016/09/28 11:03、Jay Abbott via swift-evolution <
>>> swift-evolution@swift.org> のメッセージ:
>>>
>>> Hello,
>>>
>>> I had an idea and eventually discovered trawling through the archives of
>>> this list that quite a few other people have had the same idea and it has
>>> been discussed. Multiple times. This was not easy to discover, and judging
>>> from some of the messages I came across other people hadn't found and read
>>> them.
>>>
>>> I imagine this is frustrating and potentially time-consuming for the
>>> list, with people proposing or reopening ideas that have already been
>>> discussed, and it's likely frustrating for those people trying to get
>>> involved too, possibly discouraging them from participating further.
>>>
>>> I have some ideas about how to solve/mitigate this, not sure if they are
>>> any good, but I'd be interested to hear your thoughts.
>>>
>>> 1. Add a draft-proposals directory to the swift-evolution repo. People
>>> would still discuss it here first, then add a draft and send a PR.
>>>
>>> Pros:
>>> Easy to find and search; Easy to link to; Things that are suitable for
>>> future discussion/review would have a place to live until their time;
>>> Commonly proposed already have a place, but uncommon ones could live here;
>>> Could be categorised (perhaps in sub-directories or by renaming files to
>>> have a different prefix) for "not viable" "yes, write it up and move to
>>> proposals" "consider later" "no, never" etc.
>>>
>>> Cons:
>>> Would get big and might need some cleaning from time to time; More PRs
>>> to deal with - although a quick scan is all that would be needed;
>>>
>>> 2. Add a currently_proposed.md file. This would have a similar purpose,
>>> but would be 3 lines only - Title (link to mailing list archive of
>>> discussion), Description (one-line), Status/comment.
>>>
>>> Pros and Cons are basically the same as 1.
>>>
>>> 3. Add a separate category to 

Re: [swift-evolution] draft proposals should be easier to find

[Jay Abbott via swift-evolution]

I don't really understand this concept of only accepting proposals for a
specific round. I saw some ideas that were suitable for future rounds of
proposals but not right now... Why aren't they captured in a better format
than the mailing list archive? If you don't want to be distracted by future
things then capture them as proposals but file them out of the way a bit so
that people can see they exist - I would have thought this would decrease
distractions from people bringing them up again.

On Wed, 28 Sep 2016 at 16:14 Robert Widmann 
wrote:

> There's a difference between "was once discussed here" and "had a proposal
> submitted to Github for consideration".  If many people are producing the
> same ideas for proposals that exist on GitHub that poses a more pressing
> risk.  But it is easier to search GitHub for such proposals than the list.
> For draft proposals that haven't made it yet, as long as they fall within
> the guidelines for proposals of a specific round, there's no reason you
> shouldn't be able to dig the discussion back up again and just talk about
> it.  Who knows, maybe you'll get a proposal submitted to GitHub that way
> with your name on it too - at the very least you'll learn something.  In a
> strange way, I guess, I'm saying we might not need this.  If somebody
> replies "by the by, we discussed this " it's not meant to dismiss you
> as unoriginal.  You can use that old thread as a further jumping off point
> if you wish to continue discussion.
>
> tl;dr Keeping track of every idea pitched here would quickly grow...
> unmaintainable.
>
> ~Robert Widmann
>
> 2016/09/28 11:03、Jay Abbott via swift-evolution 
> のメッセージ:
>
> Hello,
>
> I had an idea and eventually discovered trawling through the archives of
> this list that quite a few other people have had the same idea and it has
> been discussed. Multiple times. This was not easy to discover, and judging
> from some of the messages I came across other people hadn't found and read
> them.
>
> I imagine this is frustrating and potentially time-consuming for the list,
> with people proposing or reopening ideas that have already been discussed,
> and it's likely frustrating for those people trying to get involved too,
> possibly discouraging them from participating further.
>
> I have some ideas about how to solve/mitigate this, not sure if they are
> any good, but I'd be interested to hear your thoughts.
>
> 1. Add a draft-proposals directory to the swift-evolution repo. People
> would still discuss it here first, then add a draft and send a PR.
>
> Pros:
> Easy to find and search; Easy to link to; Things that are suitable for
> future discussion/review would have a place to live until their time;
> Commonly proposed already have a place, but uncommon ones could live here;
> Could be categorised (perhaps in sub-directories or by renaming files to
> have a different prefix) for "not viable" "yes, write it up and move to
> proposals" "consider later" "no, never" etc.
>
> Cons:
> Would get big and might need some cleaning from time to time; More PRs to
> deal with - although a quick scan is all that would be needed;
>
> 2. Add a currently_proposed.md file. This would have a similar purpose,
> but would be 3 lines only - Title (link to mailing list archive of
> discussion), Description (one-line), Status/comment.
>
> Pros and Cons are basically the same as 1.
>
> 3. Add a separate category to the bug tracker for proposals.
>
> Pros: ?
> Cons: ?
>
> Not sure how that's currently used, or if mixing up dev and evolution
> related items is acceptable or not, so I'm not sure if this is
> viable/practical.
>
> ___
> 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] associated objects

[Jay Abbott via swift-evolution]

I have implemented Associated Objects (and values) in pure swift here:
https://github.com/j-h-a/AssociatedObjects

The README is very short and straight-forward so I won't re-describe it
here.

The implementation isn't great, but it's a small and simple proof of
concept. I have further extended this (not in GH, but very simple and happy
to share if anyone cares) to add dynamic methods using closures onto
individual object instances. Useful for user interactions, or adding
'actions' to objects.

I'd like to propose that this or something similar be added to the standard
library. It could potentially even be added to AnyObject so that developers
can use it without having to declare an extension for whichever classes
they want to use it on.

As mentioned, this can easily be extended (either in the standard library
or by developers) to add closures dynamically to any object, or to any
class, which could serve as a useful way for those not concerned with type
safety and the like to get some dynamic behaviour in there in the shorter
term. With a little language support it could even be used to implement
stored properties in extensions very easily.

A better implementation would need some language changes - specifically
deinit hooks (has that ever been discussed?) because of the way weak
references are lazily zeroed. Another implementation improvement might
lazily add the dictionary to each object instead of storing it globally -
not sure if this would have ABI implications.

Interested in feedback and thoughts :)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] draft proposals should be easier to find

[Robert Widmann via swift-evolution]

There's a difference between "was once discussed here" and "had a proposal 
submitted to Github for consideration".  If many people are producing the same 
ideas for proposals that exist on GitHub that poses a more pressing risk.  But 
it is easier to search GitHub for such proposals than the list.  For draft 
proposals that haven't made it yet, as long as they fall within the guidelines 
for proposals of a specific round, there's no reason you shouldn't be able to 
dig the discussion back up again and just talk about it.  Who knows, maybe 
you'll get a proposal submitted to GitHub that way with your name on it too - 
at the very least you'll learn something.  In a strange way, I guess, I'm 
saying we might not need this.  If somebody replies "by the by, we discussed 
this " it's not meant to dismiss you as unoriginal.  You can use that old 
thread as a further jumping off point if you wish to continue discussion.

tl;dr Keeping track of every idea pitched here would quickly grow... 
unmaintainable.

~Robert Widmann

2016/09/28 11:03、Jay Abbott via swift-evolution  
のメッセージ:

> Hello,
> 
> I had an idea and eventually discovered trawling through the archives of this 
> list that quite a few other people have had the same idea and it has been 
> discussed. Multiple times. This was not easy to discover, and judging from 
> some of the messages I came across other people hadn't found and read them.
> 
> I imagine this is frustrating and potentially time-consuming for the list, 
> with people proposing or reopening ideas that have already been discussed, 
> and it's likely frustrating for those people trying to get involved too, 
> possibly discouraging them from participating further.
> 
> I have some ideas about how to solve/mitigate this, not sure if they are any 
> good, but I'd be interested to hear your thoughts.
> 
> 1. Add a draft-proposals directory to the swift-evolution repo. People would 
> still discuss it here first, then add a draft and send a PR.
> 
> Pros:
> Easy to find and search; Easy to link to; Things that are suitable for future 
> discussion/review would have a place to live until their time; Commonly 
> proposed already have a place, but uncommon ones could live here; Could be 
> categorised (perhaps in sub-directories or by renaming files to have a 
> different prefix) for "not viable" "yes, write it up and move to proposals" 
> "consider later" "no, never" etc.
> 
> Cons:
> Would get big and might need some cleaning from time to time; More PRs to 
> deal with - although a quick scan is all that would be needed;
> 
> 2. Add a currently_proposed.md file. This would have a similar purpose, but 
> would be 3 lines only - Title (link to mailing list archive of discussion), 
> Description (one-line), Status/comment.
> 
> Pros and Cons are basically the same as 1.
> 
> 3. Add a separate category to the bug tracker for proposals.
> 
> Pros: ?
> Cons: ?
> 
> Not sure how that's currently used, or if mixing up dev and evolution related 
> items is acceptable or not, so I'm not sure if this is viable/practical.
> 
> ___
> 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] draft proposals should be easier to find

[Jay Abbott via swift-evolution]

Hello,

I had an idea and eventually discovered trawling through the archives of
this list that quite a few other people have had the same idea and it has
been discussed. Multiple times. This was not easy to discover, and judging
from some of the messages I came across other people hadn't found and read
them.

I imagine this is frustrating and potentially time-consuming for the list,
with people proposing or reopening ideas that have already been discussed,
and it's likely frustrating for those people trying to get involved too,
possibly discouraging them from participating further.

I have some ideas about how to solve/mitigate this, not sure if they are
any good, but I'd be interested to hear your thoughts.

1. Add a draft-proposals directory to the swift-evolution repo. People
would still discuss it here first, then add a draft and send a PR.

Pros:
Easy to find and search; Easy to link to; Things that are suitable for
future discussion/review would have a place to live until their time;
Commonly proposed already have a place, but uncommon ones could live here;
Could be categorised (perhaps in sub-directories or by renaming files to
have a different prefix) for "not viable" "yes, write it up and move to
proposals" "consider later" "no, never" etc.

Cons:
Would get big and might need some cleaning from time to time; More PRs to
deal with - although a quick scan is all that would be needed;

2. Add a currently_proposed.md file. This would have a similar purpose, but
would be 3 lines only - Title (link to mailing list archive of discussion),
Description (one-line), Status/comment.

Pros and Cons are basically the same as 1.

3. Add a separate category to the bug tracker for proposals.

Pros: ?
Cons: ?

Not sure how that's currently used, or if mixing up dev and evolution
related items is acceptable or not, so I'm not sure if this is
viable/practical.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Java-style annotations (attributes?)

[Rick Mann via swift-evolution]

> On Sep 27, 2016, at 20:24 , Chris Lattner  wrote:
> 
> 
>> On Sep 27, 2016, at 5:02 PM, Rick Mann via swift-evolution 
>>  wrote:
>> 
>> I did a little googling, but didn't find this specific question being asked. 
>> I've had the question in my head for a while now, so I apologize if I 
>> already brought this up.
>> 
>> Will Swift ever support introspectable Java-style annotations? I think the 
>> current syntactic construct is called an Attribute, but they'd be 
>> customizable, created in much the same way as classes are.
> 
> Hi Rick,
> 
> This is something that many people are aware of and is commonly requested.  
> It isn’t on the short-term todo list (which is oriented around ABI stability 
> at the moment) but is something that many folks are interested in adding at 
> some point.

Thank you, that's great news.

In case you're interested, this is why I want it. I'd really like to see 
Baratine re-implemented in pure Swift:

http://baratine.io

If you can spare the time, I highly recommend checking out the Getting Started. 
It's revolutionary for web services.


-- 
Rick Mann
rm...@latencyzero.com


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

[swift-evolution] [Pitch] Refactor Metatypes

[Adrian Zubarev via swift-evolution]

Formatted version: 
https://github.com/DevAndArtist/swift-evolution/blob/refactor_metatypes/proposals/0126-refactor-metatypes.md

Refactor Metatypes

Proposal: SE–0126
Authors: Adrian Zubarev, Anton Zhilin, Brent Royal-Gordon
Status: Revision
Review manager: Chris Lattner
Revision: 2
Previous Revisions: 1
Introduction

This proposal removes .Type and .Protocol in favor of two generic-style 
syntaxes and aligns global type(of:) function (SE–0096) to match the changes.

Swift-evolution thread (post Swift 3):

[Pitch] Refactor Metatypes
Older swift-evolution threads: [1], [2], [3]

Motivation

Every type T has an instance, accessible through T.self, which represents the 
type itself. Like all instances in Swift, this “type instance” itself has a 
type, which is referred to as its “metatype”. The metatype of T is written 
T.Type. The instance members of the metatype are the same as the static or 
class members of the type.

Metatypes have subtype relationships which reflect the types they represent. 
For instance, given these types:

protocol Proto {}
class Base {}
class Derived: Base, Proto {}
Derived.Type is a subtype of both Base.Type and Proto.Type (and Any.Type). That 
means that Derived.self can be used anywhere a Derived.Type, Base.Type, 
Proto.Type, or Any.Type is called for.

Unfortunately, this simple picture is complicated by protocols. Proto.self is 
actually of type Proto.Protocol, not type Proto.Type. This is necessary because 
the protocol does not, and cannot, conform to itself; it requires conforming 
types to provide static members, but it doesn’t actually provide those members 
itself. Proto.Type still exists, but it is the supertype of all types 
conforming to the protocol.

Making this worse, a generic type always uses T.Type to refer to the type of 
T.self. So when Proto is bound to a generic parameter P, P.Type is the same as 
Proto.Protocol.

This shifting of types is complicated and confusing; we seek to clean up this 
area.

We also believe that, in the long term, the dot syntax will prevent us from 
implementing certain future enhancements that might be valuable:

Moving the implementation of metatypes at least partly into the standard 
library.
Adding members available on all type instances for features like read-write 
reflection or memory layout information.
Conforming metatypes to protocols like Hashable or CustomStringConvertible.
Offering straightforward syntaxes for dynamic features like looking up types by 
name.
Proposed solution

We abolish .Type and .Protocol in favor of two generic-style syntaxes:

Type is the concrete type of T.self. A Type only ever has one instance, 
T.self; even if T has a subtype U, Type is not a subtype of Type.

Subtype is the supertype of all Types whose instances are subtypes of T, 
including T itself:

If T is a struct or enum, then Type is the only subtype of Subtype.

If T is a class, then Type and the Types of all subclasses of T are subtypes 
of Subtype.

If T is a protocol, then the Types of all concrete types conforming to T are 
subtypes of Subtype. Type is not itself a subtype of Subtype, or of 
any Subtype other than Subtype.

Structural types follow the subtype/supertype relationships of their 
constituent types. For instance:

Type<(NSString, NSString)> is a subtype of Subtype<(NSObject, NSObject)>

Metatypes of functions are a little bit more special (the subtyping relation on 
functions flips around for parameter types):

Type<(Any) -> Void> is a subtype of Subtype<(Int) -> Void> etc.
Type<(Void) -> Int> is a subtype of Subtype<(Void) -> Any>
In this new notation, some of our existing standard library functions would 
have signatures like:

func unsafeBitCast(_: T, to type: Type) -> U
func ==(t0: Subtype?, t1: Subtype?) -> Bool
func type(of: T) -> Subtype // SE-0096
That last example, type(of:), is rather interesting, because it is actually a 
magic syntax rather than a function. We propose to align this syntax with Type 
and Subtype by renaming it to Subtype(of:). We believe this is clearer about 
both the type and meaning of the operation.

let anInstance: NSObject = NSString()
let aClass: Subtype = Subtype(of: anInstance)

print(aClass) // => NSString
More details:

Every static or class member of T which can be called on all subtypes is an 
instance member of Subtype. That includes:

Static/class properties and methods

Required initializers (as methods named init)

Unbound instance methods

The Type of a concrete type T has all of the members required by Subtype, 
plus non-required initializers.

The Type of a protocol T includes only unbound instance methods of T.

If T conforms to P, then Subtype is a subtype of Subtype, even if T is a 
protocol.

The type of Subtype.self is Type.

The type of Type.self is Type, which is not a subtype of any type 
except Subtype. There is an infinite regress of Type<...>s.

Subtypes are abstract types similar to class-bound protocols; they, too, 
support 

Re: [swift-evolution] [Proposal draft] Conditional conformances

[Anton Zhilin via swift-evolution]

I find the limitation of non-intersection of conditional conformance
reqirements quite limiting. Can it be lifted in case there are no
overloaded functions between extensions?

protocol A { func foo() }
protocol B { func bar() }

extension Array: A where Element: A {
func foo() { return self.first!.foo() }
}
extension Array: B where Element: B {
func bar() { return self.first!.bar() }
}

let arr: Array
arr.foo()

What is ambiguous here? When we see arr.foo(), we know it's from Array: A
extension, regardless of T, and we just have to check the requirement of
that extension.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Out of Scope Issues

[Haravikk via swift-evolution]

During the Swift 3.0 cycle I had a couple of pull requests marked as out of 
scope for current release, and I was wondering what the procedure is for having 
them untagged for reconsideration? Or should I resubmit them?

The two in question were:
https://github.com/apple/swift-evolution/pull/366
https://github.com/apple/swift-evolution/pull/367

But there are other previously out of scope issues I'm interested in as well.

Also, is there a description somewhere of exactly what's in scope for the next 
stage? The front-page for the swift-evolution github project seems to still be 
focused on Swift 3.0, is there a permanent description somewhere? I haven't 
been as active on the list lately so apologies if I've just missed it!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution