Re: [swift-evolution] Incremental ABI stability

> 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

Re: [swift-evolution] Renaming SwiftObject

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

[swift-evolution] Renaming SwiftObject

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] [Proposal] Random Unification

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

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

> 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

> 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] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

> 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] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

> 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] [Draft] Rename Sequence.elementsEqual

> 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] [Proposal] Random Unification

> 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

> 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] pitch: Unified libc import (again)

> 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] SE-0181 : should c++ be written "cxx" or "cpp" ?

> 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] [Request for Feedback] Providing defaults for reading and writing.

> 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] [Pitch] Guard/Catch

> 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] floating point numbers implicit conversion

> 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

> 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] Uniform Initialization Syntax

> 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

> 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] [swift-evolution-announce] [Review] SE-0168: Multi-Line String Literals

> 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] [Proposal] Factory Initializers

> 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

> 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

> 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] [Pitch] Introducing `Unwrappable` protocol

> 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: Replacement for FileHandle

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] A case for postponing ABI stability

> 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

> 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

> 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] Preconditions aborting process in server scenarios [was: Throws? and throws!]

> 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] Throws? and throws!

> 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] Getting a list of protocol conformers

> 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] Will Swift ever support optional methods without @objc?

> 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] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

> 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] [swift-evolution-announce] [Accepted] SE-0140: Bridge Optional As Its Payload Or NSNull

> 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] [Proposal draft] Bridge Optional As Its Payload Or NSNull

> 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] Ad hoc enums / options

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

> 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] Winding down the Swift 3 release

> 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

> 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] Rewrite imported C function signatures

> 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] Mutability for Foundation types in Swift

> 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] [Pitch] Fully eliminate implicit bridging conversions in Swift 3

> 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

> 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

> 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] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> 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] [Idea] Add forced conversion for Error catching pattern matching

> 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] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

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

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

> 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] Lambda function syntax

> 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

> 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] Proposal: Support for commit comments

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