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

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

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

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,

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

> On Sep 26, 2016, at 5:18 PM, Douglas Gregor via swift-evolution > wrote: > > Conditional conformances > > > Disallow > overlapping conformances > >

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

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: >> >> >>

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

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

Re: [swift-evolution] associated objects

-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

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

> 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

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

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

Re: [swift-evolution] associated objects

> 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

Re: [swift-evolution] $self

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

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

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

Re: [swift-evolution] $self

> 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

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

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

Re: [swift-evolution] $self

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

Re: [swift-evolution] $self

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

Re: [swift-evolution] $self

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

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

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: >

Re: [swift-evolution] $self

> 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

Re: [swift-evolution] $self

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

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

> 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

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

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

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

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 >

Re: [swift-evolution] $self

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

Re: [swift-evolution] $self

> 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: > >

[swift-evolution] $self

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

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

> 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

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

~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. >

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

> 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:

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

> 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

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

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

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

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

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

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

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

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

[swift-evolution] Pitch: Renaming CharacterSet to UnicodeScalarSet

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

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

+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?).

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

> 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,

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

> 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

Re: [swift-evolution] associated objects

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

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

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

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

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 >>>

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

> 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

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

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:

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

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

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

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

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

+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

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

+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: >

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

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

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

> 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

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

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

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

> 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() } >

Re: [swift-evolution] associated objects

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

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

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

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

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

[swift-evolution] associated objects

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

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

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

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

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

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

> 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

[swift-evolution] [Pitch] Refactor Metatypes

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

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

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

[swift-evolution] Out of Scope Issues

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