Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

On Wed, Jul 27, 2016 at 10:30 PM, David Owens II via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jul 27, 2016, at 7:18 PM, John McCall wrote: > > > > > >> On Jul 27, 2016, at 6:55 PM, David Owens II via swift-evolution < > swift-evolution@swift.org> wrote: >

Re: [swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

> On Jul 27, 2016, at 4:00 PM, Jacob Bandes-Storch wrote: > > I figured that sentence was in reference to the methods currently named > flatten(). > > The proposal also said that the String-based version of joined(separator:) > (which are implemented separately) should

Re: [swift-evolution] [Accepted with revision] SE-0134: Rename two UTF8-related properties on String

> On Jul 27, 2016, at 4:25 PM, Xiaodi Wu wrote: > > One PR (well, two) coming asap! Awesome, thanks Xiaodi! -Chris > On Wed, Jul 27, 2016 at 16:59 Chris Lattner via swift-evolution > > wrote: > Proposal Link:

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> On Jul 27, 2016, at 7:18 PM, John McCall wrote: > > >> On Jul 27, 2016, at 6:55 PM, David Owens II via swift-evolution >> wrote: >> >> Yes, it’s per file. It’s also added in the initial template that Xcode >> creates with your project. In

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

Yes, it’s per file. It’s also added in the initial template that Xcode creates with your project. In addition, it’s recommended by many that talk about “how to unit test in Swift.” So, to someone that is not paying scrupulous attention, there is no mechanism to prevent against this today. This

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

I’m a bit confused here… Since the result of breaching your subclassing contract is a compile-time error, how are you intending to test that using XCTest? On the other hand, if you want to write a test that subclasses the class, and uses it as a Library consumer would, why would you use

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> On Jul 27, 2016, at 8:47 PM, Brent Royal-Gordon > wrote: > >> On Jul 27, 2016, at 6:43 PM, Matthew Johnson wrote: >> >>> In a future version of Swift, we might consider refining this by requiring >>> people to apply `@testable` directly to

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> On Jul 27, 2016, at 6:43 PM, Matthew Johnson wrote: > >> In a future version of Swift, we might consider refining this by requiring >> people to apply `@testable` directly to declarations which treat something >> closed as if it's open, but it seems like even the

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> On Jul 27, 2016, at 8:36 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution >> wrote: >> >> I brought this up in review, but there seems to be a serious testability

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution > wrote: > > I brought this up in review, but there seems to be a serious testability > problem here because of how special @testable is. > > // This class is not subclassable outside of ModuleA. >

Re: [swift-evolution] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> > The third review of "SE-0177: Allow distinguishing between public access > and public overridability" ran from Active review July 21...25. The > proposal has been *accepted with revisions*. The third review of "SE-0177: Allow distinguishing between public access > and public overridability"

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

Other than warning on open methods in non-open classes, I can’t think of a good way to avoid this and still preserve the rest of the testing model. After all, @testable allows you to override internal methods too. (Just to make things clear, @testable only applies to the current file, so it’s

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

While arguably true, that's a philosophical debate. There are plenty of reasons to use @testable, and if that's what people are using, then I think there is a valid concern here. Sent from my iPhone > On Jul 27, 2016, at 5:22 PM, John McCall wrote: > >> On Jul 27, 2016,

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution > wrote: > I brought this up in review, but there seems to be a serious testability > problem here because of how special @testable is. > > // This class is not subclassable outside of ModuleA. >

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

I brought this up in review, but there seems to be a serious testability problem here because of how special @testable is. // This class is not subclassable outside of ModuleA. public class NonSubclassableParentClass { // This method is not overridable outside of ModuleA. public func

Re: [swift-evolution] [Accepted with revision] SE-0134: Rename two UTF8-related properties on String

One PR (well, two) coming asap! On Wed, Jul 27, 2016 at 16:59 Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md > > The review of "SE-0134: Rename two

Re: [swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

I figured that sentence was in reference to the methods currently named flatten(). The proposal also said that the String-based version of joined(separator:) (which are implemented separately) should have a default separator of "". There is currently no flatten() for collections of Strings.

Re: [swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

> On Jul 27, 2016, at 2:59 PM, Jacob Bandes-Storch wrote: > > Does the core team have feedback on whether Collection's > joined(separator:) should have a default separator of "", or another overload > with no parameter? "The core team prefers that it remain a distinct

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

I realize that there’s no review needed, but I actually wanted to give a hearty  to the authors and commenters of this proposal, because I genuinely think we’ve reached something good in the result. The selling point for me is this: // This is allowed since the superclass is `open`. class

Re: [swift-evolution] End of source-breaking changes for Swift 3

I noticed that while SE-0091 appears to be implemented (from a cursory glance at some of the affected types like Equatable and String), it looks like the named methods are still part of the FloatingPoint protocol and they still use global operators. Is anyone tracking the migration of that

[swift-evolution] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md The third review of "SE-0177: Allow distinguishing between public access and public overridability" ran from Active review July 21...25. The proposal has been *accepted with

[swift-evolution] [Deferred] SE-0132: Rationalizing Sequence end-operation names

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md Hello Swift Community, The review of "SE-0132: Rationalizing Sequence end-operation names" ran from July 24...26. The proposal is *deferred* from Swift 3. This is a very large proposal

Re: [swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

Does the core team have feedback on whether Collection's joined(separator:) should have a default separator of "", or another overload with no parameter? On Wed, Jul 27, 2016 at 2:56 PM, Jacob Bandes-Storch wrote: > I'll get right on it. Thanks to everyone who provided

[swift-evolution] [Accepted with revision] SE-0134: Rename two UTF8-related properties on String

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md The review of "SE-0134: Rename two UTF8-related properties on String" ran from July 24…26. The proposal has been *accepted with revision*. This proposal has two parts. The core team

Re: [swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

I'll get right on it. Thanks to everyone who provided great feedback during the review! On Wed, Jul 27, 2016 at 2:53 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal Link: >

[swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md The review of "SE-0133: Rename flatten() to joined()" ran from Active review July 24…26. The proposal has been *accepted*. This proposal had significant positive community feedback

Re: [swift-evolution] End of source-breaking changes for Swift 3

> On 27 Jul 2016, at 21:52, Jacob Bandes-Storch wrote: > > SE-0089 - Renaming String.init(_: T) > > > Has anyone worked on this? I have some time in the next couple of days and > might be

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

> On 27 Jul 2016, at 15:08, Xiaodi Wu wrote: > > Ben, while I'm broadly sympathetic to making CChar work more widely, if I > recall correctly this was a rather complex discussion topic you're raising > again. Yes, I linked to the previous threads:

Re: [swift-evolution] [swift-evolution-announce] End of source-breaking changes for Swift 3

> On Jul 27, 2016, at 12:38 PM, Ted Kremenek wrote: > > • SE-0045 - Add scan, prefix(while:), drop(while:), and iterate to the > stdlib The associated bug, SR-1516, is assigned to Russ Bishop, who said in late June that he had the non-lazy versions implemented. --

Re: [swift-evolution] End of source-breaking changes for Swift 3

> > >- SE-0089 - Renaming String.init(_: T) > > > > Has anyone worked on this? I have some time in the next couple of days and might be able to come up with an implementation in time.

Re: [swift-evolution] End of source-breaking changes for Swift 3

> SE-0104 - Protocol-oriented integers > We > used to have a prototype implementation of this, but it was removed (by > mistake?) by @moiseev a couple of weeks ago:

Re: [swift-evolution] End of source-breaking changes for Swift 3

> SE-0104 - Protocol-oriented integers > We > used to have a prototype implementation of this, but it was removed (by > mistake?) by @moiseev a couple of weeks ago:

[swift-evolution] [Accepted] SE-0129: Package Manager Test Naming Conventions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0129-package-manager-test-naming-conventions.md The review of "SE-0129: Package Manager Test Naming Conventions" ran from Active review July 22...26. The proposal has been *accepted*. There was relatively little

Re: [swift-evolution] [swift-dev] End of source-breaking changes for Swift 3

> On Jul 27, 2016, at 12:45 PM, Slava Pestov via swift-evolution > wrote: > > >> On Jul 27, 2016, at 12:38 PM, Ted Kremenek via swift-dev >> > wrote: >> >> >> SE-0092 - Typealiases in protocols and protocol

Re: [swift-evolution] [swift-dev] End of source-breaking changes for Swift 3

> On Jul 27, 2016, at 12:38 PM, Ted Kremenek via swift-dev > wrote: > > > SE-0092 - Typealiases in protocols and protocol extensions > > SE-0102 - Remove @noreturn attribute

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

I'm not sure wether the review period is actually over (or better say "turned into an internal discussion", as I haven't seen a result yet ;-), but as nobody jumped onto the "something more holistic"-train, I used my free time at the lake for some thinking… There are three degrees of freedom,

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

I'm +1 on the proposal. Félix > Le 27 juil. 2016 à 07:08:44, Xiaodi Wu via swift-evolution > a écrit : > > Ben, while I'm broadly sympathetic to making CChar work more widely, if I > recall correctly this was a rather complex discussion topic you're raising >

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

Ben, while I'm broadly sympathetic to making CChar work more widely, if I recall correctly this was a rather complex discussion topic you're raising again. Besides the unprecedented name (Unsigned is never spelled out at the moment), I wonder if all the other salient issues involved are best left

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> On Jul 27, 2016, at 5:58 AM, Brent Royal-Gordon > wrote: > >> On Jul 26, 2016, at 5:45 PM, Brent Royal-Gordon >> wrote: >> >> I'm working on an implementation (so far I just have `dropFirst` renamed, >> but I've only spent about half an

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> On Jul 26, 2016, at 5:45 PM, Brent Royal-Gordon > wrote: > > I'm working on an implementation (so far I just have `dropFirst` renamed, but > I've only spent about half an hour on it, mostly waiting for tests), but the > diff isn't really going to tell you much. Now

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

> On 25 Jul 2016, at 15:27, Ben Rimmington wrote: > > > > My suggestion for SE-0134 is to use the `utf8CString` name, overloading for > CSignedChar and CUnsignedChar: > > >

Re: [swift-evolution] asyncAfter(deadline: ...)

> On 27 Jul 2016, at 10:23, Guillaume Lessard via swift-evolution > wrote: > > Hello, > > The newer version of the libdispatch overlay (as of 8ac413a) looks good: > thanks for your work Matt! > > It replaced async(when: ) with asyncAfter(deadline: ); however

[swift-evolution] asyncAfter(deadline: ...)

Hello, The newer version of the libdispatch overlay (as of 8ac413a) looks good: thanks for your work Matt! It replaced async(when: ) with asyncAfter(deadline: ); however dictionaries say: deadline |ˈdedˌlīn| noun 1 the latest time or date by which something should be completed