Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

> On Dec 9, 2016, at 11:50 AM, Dave Abrahams via swift-evolution > wrote: > > > on Fri Dec 09 2016, Andrew Trick wrote: > >>> On Dec 9, 2016, at 10:27 AM, Dave Abrahams via swift-evolution >> wrote: >>> >>>

Re: [swift-evolution] [Review] SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer

> On Dec 12, 2016, at 1:32 PM, Andrew Trick wrote: > >> >> On Dec 7, 2016, at 10:07 PM, Douglas Gregor via swift-evolution >> > wrote: >> >> Hello Swift community, >> >> The review of SE-0147 "Move

Re: [swift-evolution] It's the little things..

On Mon, Dec 12, 2016 at 6:15 PM, John Holdsworth via swift-evolution < swift-evolution@swift.org> wrote: > As the festive season approaches I thought I’d write a brain dump > of a few things I'd hope Santa could bring in his bag for Swift 3.1. > No big ideas, just things that bug me day to day

[swift-evolution] It's the little things..

As the festive season approaches I thought I’d write a brain dump of a few things I'd hope Santa could bring in his bag for Swift 3.1. No big ideas, just things that bug me day to day and would be backward source compatible. I’m sure it’s been discussed before but I wish static and class vars and

Re: [swift-evolution] Partial class declaration

I agree that partial classes would be a handy way to help split up an implementation, and perhaps also of assistance if you want really tight/clean access control within a class, using fileprivate. But this does not replace the need for stored properties in extensions. For example (I have done

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

> On 12 Dec 2016, at 07:23, Benjamin Spratling via swift-evolution > wrote: > > > > -Ben > > Sent from my iPhone. > >> On Dec 11, 2016, at 11:43 PM, Brian Gesiak wrote: > >> Maybe your goal is to ensure that other programmers don't

Re: [swift-evolution] [Review] SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer

> On Dec 12, 2016, at 6:30 PM, Ben Cohen wrote: > > >> On Dec 12, 2016, at 1:32 PM, Andrew Trick > > wrote: >> >>> >>> On Dec 7, 2016, at 10:07 PM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] It's the little things..

Sent from my iPhone > On Dec 12, 2016, at 16:15, John Holdsworth via swift-evolution > wrote: > > I’d like to raise again the idea of optionality when referencing a key or > calling a function could be possible using a ? i.e instead of > >let a = key != nil ?

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

An interesting reading about testing private members: https://cocoacasts.com/how-to-unit-test-private-methods-in-swift/ > Le 12 déc. 2016 à 06:10, Derrick Ho via swift-evolution > a écrit : > > It

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

> On Dec 12, 2016, at 2:17 AM, Rien wrote: > That is a very elusive goal. > The best way to do this is through hiring competent people… If nothing else, I would hope that we can agree that enabling the testing of all our design choices is a goal. Towards that, my goal

Re: [swift-evolution] Details of what source compatibility with Swift 3 means

Hi All, Does anyone have feedback before this becomes the plan of record for Swift 3.x and Swift 4? The Apple team has reviewed this already but I wanted to make sure we didn’t miss some important cases. Thanks, Ewa > On Nov 30, 2016, at 12:27 PM, ematej...@apple.com wrote: > > Hi, > > One

Re: [swift-evolution] [Review] SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer

> On Dec 7, 2016, at 10:07 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0147 "Move UnsafeMutablePointer.initialize(from:) to > UnsafeMutableBufferPointer" begins now and runs through December 12, 2016. > The

Re: [swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

> On Dec 12, 2016, at 2:09 PM, Joe Groff via swift-evolution > wrote: > > >> On Dec 12, 2016, at 12:59 PM, Charles Srstka > > wrote: >> >>> On Dec 12, 2016, at 2:46 PM, Joe Groff >>

Re: [swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

> On Dec 12, 2016, at 12:12 PM, Charles Srstka via swift-evolution > wrote: > > I’ve been trying to figure out the rationale for why the code below behaves > the way it does for some time: > > import Foundation > > class C: NSObject { > dynamic var foo: Int

Re: [swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

> On Dec 12, 2016, at 2:46 PM, Joe Groff wrote: > > Everything *can* be bridged to an object as a result of SE-0116 > ("id-as-Any"), so there's no longer such a thing as a "non-bridgable value > type”. Ah, so that arbitrary Swift types can be stashed in Objective-C userInfo

Re: [swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

> On Dec 12, 2016, at 12:59 PM, Charles Srstka wrote: > >> On Dec 12, 2016, at 2:46 PM, Joe Groff > > wrote: >> >> Everything *can* be bridged to an object as a result of SE-0116 >> ("id-as-Any"), so there's no longer such

Re: [swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

> On Dec 12, 2016, at 3:09 PM, Joe Groff wrote: > >> On Dec 12, 2016, at 12:59 PM, Charles Srstka > > wrote: >> >>> On Dec 12, 2016, at 2:46 PM, Joe Groff >> > wrote: >>>

[swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

I’ve been trying to figure out the rationale for why the code below behaves the way it does for some time: import Foundation class C: NSObject { dynamic var foo: Int { return 5 } dynamic func bar() -> Int { return 6 } } struct S {} let c = C() let s = S() print(c is

Re: [swift-evolution] Why is AnyObject's bridging so weird in Swift 3?

> On Dec 12, 2016, at 2:12 PM, Charles Srstka via swift-evolution > wrote: > > print((c as AnyObject?)?.bar() as Any) // Optional(6) > print((s as AnyObject?)?.bar() as Any) // crash! -[_SwiftValue bar]: > unrecognized selector sent to instance 0x5432109876543210