Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

2016-01-06 Thread Greg Parker via swift-evolution
> On Jan 5, 2016, at 8:50 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Taking inspiration from syntax used for methods in classes that override >> methods in superclasses, require methods that override dynamically >> dispatched default implementations

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

2016-01-05 Thread Greg Parker via swift-evolution
I think it is a bug :-) That's not what backquotes are for. It ought to be either supported without the backquotes or banned regardless of backquotes. > On Jan 5, 2016, at 8:34 PM, Jacob Bandes-Storch wrote: > > Yes, it seems to use the strong shadowing variable. (The

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

2016-01-05 Thread Greg Parker via swift-evolution
Does further use of self after that actually use a strong shadowing variable? Or does it go back to the weak reference it already had as if the shadow were not there? > On Jan 5, 2016, at 8:26 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > Wow! I didn't

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

2016-01-05 Thread Greg Parker via swift-evolution
> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution > wrote: > >> On Jan 5, 2016, at 11:52 AM, Douglas Gregor > > wrote: >> >> There are better mechanisms for this than +load. But one would have to deal >>

Re: [swift-evolution] Proposal: Support for commit comments

2015-12-21 Thread Greg Parker via swift-evolution
> On Dec 21, 2015, at 2:53 PM, Amir Michail via swift-evolution > wrote: > >> On Dec 21, 2015, at 5:38 PM, Douglas Gregor wrote: >> >>> On Dec 21, 2015, at 11:07 AM, Amir Michail via swift-evolution >>> wrote: >>>

Re: [swift-evolution] Lambda function syntax

2015-12-22 Thread Greg Parker via swift-evolution
> On Dec 22, 2015, at 3:45 PM, Alexander Regueiro via swift-evolution > wrote: > > I’ve also explained the big problem with trailing closures already. And > closures are really *not* control flow statements, so treating like them is > just a fallacy and source of

Re: [swift-evolution] Final by default for classes and methods

2015-12-22 Thread Greg Parker via swift-evolution
> On Dec 22, 2015, at 11:31 AM, Kevin Ballard via swift-evolution > wrote: > > UIKit classes aren't subclassable because of a lack of sealed-by-default, > they're subclassable because until very recently there was no way to mark > classes as not being subclassable.

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

2016-06-03 Thread Greg Parker via swift-evolution
> On Jun 1, 2016, at 5:42 PM, Matthew Johnson via swift-evolution > wrote: > >> On Jun 1, 2016, at 5:02 PM, Vladimir.S via swift-evolution >> wrote: >> >>> in other words, we could consider allowing this: >>> func foo(bar: (.fit |

Re: [swift-evolution] [Pitch] Circling back to `with`

2016-05-31 Thread Greg Parker via swift-evolution
> On May 27, 2016, at 5:19 PM, Brent Royal-Gordon via swift-evolution > wrote: > >>> - A plain `with` whose closure parameter is not mutable and which is marked >>> `@discardableResult`. >> >> I would like to see this version restricted to AnyObject. It has

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

2016-03-21 Thread Greg Parker via swift-evolution
> On Mar 16, 2016, at 11:46 PM, Adrian Kashivskyy via swift-evolution > wrote: > > @Jed, > >> That said, the problem isn’t necessarily difficult to solve — it’s just that >> it’s important that it actually be solved at the same time the feature is >> rolled out. >

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

2016-03-21 Thread Greg Parker via swift-evolution
> On Mar 19, 2016, at 12:46 AM, Dmitri Gribenko via swift-evolution > wrote: > > Hi Ted, > > Thank you for starting this thread. I agree that removing the C-style > for loop has degraded the readability and clarity of some of numerics > code. > > In the feedback

Re: [swift-evolution] [Idea] Add forced conversion for Error catching pattern matching

2016-03-21 Thread Greg Parker via swift-evolution
> On Mar 20, 2016, at 1:26 PM, Tyler Fleming Cloutier via swift-evolution > wrote: > > Also as a brief aside, it’s not super intuitive to me that the syntax for the > catch pattern matching wildcard is > > catch _ > > whereas it is > > default > > for

Re: [swift-evolution] Mutability for Foundation types in Swift

2016-04-22 Thread Greg Parker via swift-evolution
> On Apr 22, 2016, at 2:36 PM, Charles Srstka via swift-evolution > wrote: > > One comment: > > "In the most common case where a developer does not provide a custom > reference type, then the backing store is our existing NSData and > NSMutableData

Re: [swift-evolution] Rewrite imported C function signatures

2016-04-25 Thread Greg Parker via swift-evolution
> On Mar 26, 2016, at 2:00 PM, Brent Royal-Gordon via swift-evolution > wrote: > > If that's all you want, maybe we can have an attribute which says "prefer > this version over that one": > > @preferred(since: 3.0, over: socket(_: Int32, _: Int32, _: Int32)

Re: [swift-evolution] Winding down the Swift 3 release

2016-05-17 Thread Greg Parker via swift-evolution
> On May 17, 2016, at 3:45 PM, Eric Wing via swift-evolution > wrote: > > So I don’t mind (too much) if it takes longer to get a stable ABI. It > makes my life harder, but on the flip-side, I don’t want to be stuck > with yet another broken language and ABI. I want

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

2016-05-06 Thread Greg Parker via swift-evolution
> On May 3, 2016, at 8:53 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0073: Marking closures as executing exactly once" begins > now and runs through May 9. The proposal is available here: > > >

Re: [swift-evolution] [Pitch] Fully eliminate implicit bridging conversions in Swift 3

2016-04-19 Thread Greg Parker via swift-evolution
> On Apr 18, 2016, at 8:21 PM, Joe Pamer via swift-evolution > wrote: > > I propose that we fully eliminate implicit bridging conversions in Swift 3. > This would mean that some users might have to introduce introduce a few more > ‘as’ casts in their code, but we

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

2016-04-19 Thread Greg Parker via swift-evolution
> On Apr 14, 2016, at 4:55 PM, Stephen Canon via swift-evolution > wrote: > > /// `true` iff the signbit of `self` is set. Implements the IEEE 754 > /// `signbit` operation. > /// > /// Note that this is not the same as `self < 0`. In particular, this >

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

2016-04-18 Thread Greg Parker via swift-evolution
> On Apr 14, 2016, at 10:07 PM, Stephen Canon via swift-evolution > wrote: > >> On Apr 14, 2016, at 8:34 PM, Brent Royal-Gordon >> wrote: >> >>> Stephen Canon wrote: >>> >>> public protocol Arithmetic >> >> Is there a rationale for the

Re: [swift-evolution] A case for postponing ABI stability

2017-01-27 Thread Greg Parker via swift-evolution
> On Jan 27, 2017, at 2:57 AM, Charlie Monroe via swift-evolution > wrote: > >> On Jan 27, 2017, at 11:35 AM, Tino Heth via swift-evolution >> > wrote: >> >>> I don’t disagree with your overall point, but

Re: [swift-evolution] A case for postponing ABI stability

2017-01-27 Thread Greg Parker via swift-evolution
> On Jan 27, 2017, at 9:19 AM, Tino Heth <2...@gmx.de> wrote: > >> It would mean for Apple (and others who'd distribute compiled frameworks) to >> maintain several code bases of the same framework given that they would need >> to maintain backward compatibility and hence wouldn't be able to

Re: [swift-evolution] A case for postponing ABI stability

2017-01-26 Thread Greg Parker via swift-evolution
> On Jan 26, 2017, at 2:15 PM, David Sweeris via swift-evolution > wrote: > >> On Jan 26, 2017, at 13:02, Rick Mann via swift-evolution >> wrote: >> >> Thanks for that, that's helpful. >> >> My concern, of course, is the obvious one:

Re: [swift-evolution] Pitch: Replacement for FileHandle

2017-02-16 Thread Greg Parker via swift-evolution
Please take off-topic discussion elsewhere. Thank you. > On Feb 16, 2017, at 3:35 PM, Maxim Veksler via swift-evolution > wrote: > > An off-topic suggestion on radar bugs: > > Instead of closing as "dupe" why not call it "merged" into a known issue ? > > Same

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

2017-01-17 Thread Greg Parker via swift-evolution
> On Jan 17, 2017, at 3:28 AM, Alex Blewitt via swift-evolution > wrote: > >> On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution >> wrote: >> >>> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution >>>

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

2016-08-24 Thread Greg Parker via swift-evolution
> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution > wrote: > > Proposed solution > > When an Optional value is bridged to an Objective-C object, if it contains > some value, that value should be bridged; otherwise, NSNull or another > sentinel

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0140: Bridge Optional As Its Payload Or NSNull

2016-09-12 Thread Greg Parker via swift-evolution
> On Sep 12, 2016, at 3:39 PM, Douglas Gregor wrote: > > As an amendment to SE-0140, Swift will produce a warning when an optional > value is converted to a value of type Any, e.g., > > MyClass().doSomething(stringOpt) // warning: optional value of type > ‘String?’

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

2016-10-05 Thread Greg Parker via swift-evolution
> On Oct 5, 2016, at 6:38 PM, Brent Royal-Gordon via swift-evolution > wrote: > > Now, as for naming: I like using the leading "C" convention ("CLibc") because > it leaves us room for introducing an overlaid version of the module in the > future without breaking

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

2016-11-15 Thread Greg Parker via swift-evolution
> On Nov 15, 2016, at 6:42 PM, Charles Srstka via swift-evolution > wrote: > >> On Nov 15, 2016, at 7:27 PM, Karl via swift-evolution >> > wrote: >> >> In Objective-C, asking whether or not an object

Re: [swift-evolution] Getting a list of protocol conformers

2016-11-17 Thread Greg Parker via swift-evolution
> On Nov 15, 2016, at 7:53 PM, Jonathan Hull via swift-evolution > wrote: > > I would like to be able to get, at runtime, an array of all types conforming > to a particular protocol. (Similarly, I would like to be able to get an > array of all subtypes of a given

Re: [swift-evolution] Throws? and throws!

2017-01-12 Thread Greg Parker via swift-evolution
> On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull > > wrote: >> >> Also, ‘try’ is still required to explicitly mark a potential error >> propagation

Re: [swift-evolution] [Proposal] Factory Initializers

2017-03-20 Thread Greg Parker via swift-evolution
> On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution > wrote: > > Hi again everyone! > > Now that Swift 4 Stage 2 proposals are being considered, I thought it might > be time to revisit this proposal and see if it might align with the goals set > forth

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

2017-03-20 Thread Greg Parker via swift-evolution
> On Mar 20, 2017, at 4:54 PM, Douglas Gregor wrote: > > Hello Swift community, > > The review of SE-0159 "Fix Private Access Levels" begins now and runs through > March 27, 2017. The proposal is available here: > >

Re: [swift-evolution] [Draft] Hasher & HashVisitable

2017-03-14 Thread Greg Parker via swift-evolution
> On Mar 14, 2017, at 12:01 PM, David Sweeris via swift-evolution > wrote: > > Are we committed to having `hashValue` always be an `Int`, or could it be an > associated type like `(Int, Int, Int, Int)`? Seems like especially for > something like a BigNum type or

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0168: Multi-Line String Literals

2017-04-06 Thread Greg Parker via swift-evolution
> On Apr 6, 2017, at 12:35 PM, Joe Groff wrote: > > Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > >

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

2017-03-07 Thread Greg Parker via swift-evolution
> On Mar 7, 2017, at 3:49 PM, Jaden Geller via swift-evolution > wrote: > > It’s worth mentioning that the normal let binding can be used for pattern > matching: > let (a, b, c) = foo() > > This nicely parallels the existing case syntax: > if case let .blah(a,

Re: [swift-evolution] [Pitch] Guard/Catch

2017-07-10 Thread Greg Parker via swift-evolution
> On Jul 10, 2017, at 1:51 AM, David Hart via swift-evolution > wrote: > > I know we can’t do much about it now, but if optional binding had used the > same syntax as it does in pattern matching, we wouldn’t be having this > discussion: > > guard let x = try

Re: [swift-evolution] [Request for Feedback] Providing defaults for reading and writing.

2017-07-10 Thread Greg Parker via swift-evolution
> On Jul 10, 2017, at 5:16 PM, William Shipley via swift-evolution > wrote: > > (Note the horrible hack on KeyedEncodingContainer where I had to special-case > arrays of s, I guess because the compiler doesn’t know an array of > s is Equatable itself?) Correct.

Re: [swift-evolution] SE-0181 : should c++ be written "cxx" or "cpp" ?

2017-07-12 Thread Greg Parker via swift-evolution
> On Jul 12, 2017, at 10:21 AM, Trevör ANNE DENISE via swift-evolution > wrote: > > After quickly reading "SE-0181: Package Manager C/C++ Language Standard > Support" I noticed that as Swift doesn't support "+" sign in identifiers, the > format "cxx" was used (as

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

2017-08-18 Thread Greg Parker via swift-evolution
> On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution > wrote: > > On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift > wrote: > I don’t think the “is this library functionality or standard library >

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

2017-06-08 Thread Greg Parker via swift-evolution
> On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution > wrote: > > 1. Arbitrary `self` Assignments In Intializers > > The first ideas is to allow `self = nil` inside failable initializers > (essentially making `self` look like `inout Self?` instead of

Re: [swift-evolution] Implicit truncation

2017-05-30 Thread Greg Parker via swift-evolution
> On May 26, 2017, at 12:04 AM, Xiaodi Wu via swift-evolution > wrote: > > I've often wondered if even just "bitPattern" might suffice, as the > truncating or extending of it should not be particularly surprising. Being explicit about bit pattern truncation or

Re: [swift-evolution] floating point numbers implicit conversion

2017-06-16 Thread Greg Parker via swift-evolution
> On Jun 16, 2017, at 10:35 AM, David Waite via swift-evolution > wrote: > > Has it been proposed to eventually make CGFloat into a typealias for Double > to reduce the amount of explicit conversion necessary? (I realize as a > proposal this would be better suited

Re: [swift-evolution] [Pitch] Introduction of `weak/unowned` closures

2017-06-13 Thread Greg Parker via swift-evolution
> On Jun 10, 2017, at 2:42 PM, Paul Cantrell via swift-evolution > wrote: > > Being able to specify things about closure capturing at the API level could > do wonders for Siesta — though its problems may be beyond the scope of what’s > proposed here (or what’s

Re: [swift-evolution] [Proposal] Random Unification

2017-10-04 Thread Greg Parker via swift-evolution
> On Oct 3, 2017, at 11:44 PM, Jonathan Hull via swift-evolution > wrote: > > I like the idea of splitting it into 2 separate “Random” proposals. > > The first would have Xiaodi’s built-in CSPRNG which only has the interface: > > On FixedWidthInteger: >

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

2017-10-02 Thread Greg Parker via swift-evolution
> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution > wrote: > inlinable declarations can only reference other public declarations. This is > because they can be emitted into the client binary, and are therefore limited > to referencing symbols that the

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

2017-10-16 Thread Greg Parker via swift-evolution
> On Oct 16, 2017, at 1:08 PM, Xiaodi Wu via swift-evolution > wrote: > > On Mon, Oct 16, 2017 at 13:15 David Sweeris > wrote: > > On Oct 16, 2017, at 09:21, Michael Ilseman

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

2017-11-15 Thread Greg Parker via swift-evolution
> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution > wrote: > >> On Nov 15, 2017, at 3:05 PM, Tino Heth via swift-evolution >> > wrote: >> >> Odd… exactly that is the reason why I think filterMap

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

2017-11-15 Thread Greg Parker via swift-evolution
> On Nov 15, 2017, at 5:53 PM, John McCall <rjmcc...@apple.com> wrote: > >> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Nov 15, 2017, a

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

2017-11-28 Thread Greg Parker via swift-evolution
> On Nov 27, 2017, at 8:57 AM, Mathew Huusko V via swift-evolution > wrote: > > You're saying that there is universally no inherent difference, and that all > calls "determine if you have called it" correctly, but then picked one of > only a handful of cases in

Re: [swift-evolution] [Proposal] Random Unification

2017-11-27 Thread Greg Parker via swift-evolution
> On Nov 22, 2017, at 8:55 PM, Alejandro Alonso via swift-evolution > wrote: > > I pushed some updates to the proposal with a reflected API, but I do not > agree that we should rid the API of T.random just because some users will > misuse it. I think the correct

Re: [swift-evolution] [Proposal] Random Unification

2017-12-02 Thread Greg Parker via swift-evolution
> On Dec 2, 2017, at 1:09 PM, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon > wrote: >> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution >>

[swift-evolution] Renaming SwiftObject

2018-01-04 Thread Greg Parker via swift-evolution
SwiftObject is an Objective-C class that is the base class of all "pure Swift" class types. It needs to be renamed for the Swift stable ABI in order to avoid ObjC class name collisions between the stable ABI's Swift runtime and the runtime embedded into existing Swift apps. I suggest

Re: [swift-evolution] Renaming SwiftObject

2018-01-08 Thread Greg Parker via swift-evolution
Object in Java than a compatibility shim with Objective-C. > > Saagar Jha > >> On Jan 4, 2018, at 19:10, Greg Parker via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> SwiftObject is an Objective-C class t

Re: [swift-evolution] Incremental ABI stability

2018-01-10 Thread Greg Parker via swift-evolution
> On Jan 9, 2018, at 6:50 PM, Jon Hull via swift-evolution > wrote: > >> On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via swift-evolution >> wrote: >> >> I’m just spitballing here, and I’m not an expert on matters of ABI, however