Re: [swift-evolution] Pitch: Improved Swift pointers

I agree with all of Andy’s points. I really like this and think it’s a good time to start discussing its details and moving from a pitch to a proposal. Thank you for writing it! Minor tweak: say “deprecate” instead of “remove” for APIs, which has a better connotation with respect to source

Re: [swift-evolution] Change default compiler fix for not-unwrapped Optional from ! To ?

Another example of the compiler being not so helpful: func f(completion: (()->())? = nil) { completion() } The compiler offers to insert a ! after `completion`, which is a strictly worse choice than inserting a ?. > On Jul 15, 2017, at 7:48 AM, Rod Brown

Re: [swift-evolution] Pitch: Improved Swift pointers

> On Jul 17, 2017, at 10:06 PM, Taylor Swift via swift-evolution > wrote: > > I’ve drafted a new version of the unsafe pointer proposal based on feedback > I’ve gotten from this thread. You can read it here >

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

> On Jul 17, 2017, at 3:26 AM, Félix Cloutier wrote: > > I think that you're getting ahead of yourself. Fixed-size arrays are still > useful even if they have to have been demonstrably initialized before you can > use dynamic indices with them. A ton of people have already

Re: [swift-evolution] Pitch: Improved Swift pointers

> On Jul 18, 2017, at 11:36 AM, Taylor Swift wrote: > > > fix the ordering of the arguments in > > initializeMemory(as:at:count:to:) > > I think this ordering was an attempt to avoid confusion with binding > memory where `to` refers to a type. However, it should be

Re: [swift-evolution] Pitch: Improved Swift pointers

Mmh, I think like the do while -> repeat while change it makes sense, but not enough to displace the obvious meaning of the original... but then again, I lost back then... Sent from my iPhone Begin forwarded message: > From: Andrew Trick via swift-evolution > Date:

Re: [swift-evolution] Pitch: Improved Swift pointers

On Tue, Jul 18, 2017 at 2:18 PM, Andrew Trick wrote: > > > rename count in UnsafeMutableRawBufferPointer.allocate(count:) to bytes > and add an > > alignedTo parameter to make it UnsafeMutableRawBufferPointer. > allocate(bytes:alignedTo:) > > Memory allocation is an issue unto

Re: [swift-evolution] Pitch: Improved Swift pointers

On Tue, Jul 18, 2017 at 5:20 PM, Taylor Swift wrote: > No, I just forgot about the compiler subtyping relationship. Never mind > that part then lol > > On Tue, Jul 18, 2017 at 4:40 PM, Andrew Trick wrote: > >> >> On Jul 18, 2017, at 11:36 AM, Taylor Swift

[swift-evolution] SE-0183 - Substring performance affordances

Hello Swift community, Context: One more small refinement proposal for Swift 4 strings. We are specifically not opening the floodgates for new proposals yet, this is this simply one potential small-scope refinement to an existing Swift 4 feature. The review of "Substring performance

Re: [swift-evolution] Pitch: Improved Swift pointers

No, I just forgot about the compiler subtyping relationship. Never mind that part then lol On Tue, Jul 18, 2017 at 4:40 PM, Andrew Trick wrote: > > On Jul 18, 2017, at 11:36 AM, Taylor Swift wrote: > > I'm not sure removing the need for implicit casts is

Re: [swift-evolution] Pitch: Improved Swift pointers

On Tue, Jul 18, 2017 at 4:41 PM, Michael Ilseman wrote: > > > I agree with all of Andy’s points. I really like this and think it’s a > good time to start discussing its details and moving from a pitch to a > proposal. Thank you for writing it! > > Minor tweak: say “deprecate”

Re: [swift-evolution] Pitch: Improved Swift pointers

> On Jul 18, 2017, at 11:36 AM, Taylor Swift wrote: > > I'm not sure removing the need for implicit casts is a goal. I did > that with the pointer `init` methods, but now I think that should be > cleaned up to reduce API surface. I think smaller API surface wins in > these

Re: [swift-evolution] Pitch: Improved Swift pointers

How do we feel about changing the label to `repeated:`, even in cases where `count:` is 1? This would mean that calls would read like this: `ptr.initialize(repeated: value)` A grep through the stdlib shows that this is by far the most common use case: swift-source/swift$ grep initialize\(to: .

Re: [swift-evolution] Enforce non-nil assignment to an implicitly unwrapped optional property?

Anyone has any thoughts on this? > On 16 Jul 2017, at 3:46 PM, Glen Huang via swift-evolution > wrote: > > I want to define a property for a struct/class that is nil after > initialization, but later is guaranteed to have a value after I manually > assign to it. I

Re: [swift-evolution] Change default compiler fix for not-unwrapped Optional from ! To ?

> On Jul 13, 2017, at 10:21 PM, Félix Cloutier via swift-evolution > wrote: > > How should the fix-it transform the following code to make it valid? > > func foo(bar: String) -> Int > func frob() -> String? > > func qaz() -> Int { > return foo(bar: frob()) //