Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

I can, but it felt more odd to me than a blank line. But that's debatable. > On 20 Jul 2017, at 01:40, Chris Lattner wrote: > > >> On Jul 17, 2017, at 4:43 AM, David Hart via swift-evolution >> wrote: >> >> To add a data point, I migrated the

Re: [swift-evolution] [Revision] Fixing SE-0177: Add clamp(to:) to the stdlib

Sorry, it's been a while but I don't understand your reply. As far as I can tell, nothing has changed since June: the revised proposal continues to propose an API that is not protocol-based, and the alternative continues to propose additions to RangeExpression that do not make sense, as partial

Re: [swift-evolution] [Revision] Fixing SE-0177: Add clamp(to:) to the stdlib

Xiaodi, Sorry for the delay and thanks for replying! Well, as to if this meets the standard thats something more subjective than objective so after hearing a few opinions (hopefully differing) the community could piece together a cleaner image of if this is a good idea or not. >From the

Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

> On Jul 17, 2017, at 4:43 AM, David Hart via swift-evolution > wrote: > > To add a data point, I migrated the Swift Package Manager to use Swift 4’s > multi-line strings this weekend. Nearly all of the resulting multi-line > strings required an ending new-line,

Re: [swift-evolution] [swift-evolution-announce] SE-0183 - Substring performance affordances

> > The review of "Substring performance affordances" begins now and runs > through July 21, 2017. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0183-substring-affordances.md > > • What is your evaluation of the proposal? Generally

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

> On Jul 19, 2017, at 11:13 AM, Taylor Swift wrote: > > What about `value:`? > > `ptr.initialize(value: value)` > `ptr.initialize(value: value, count: 13)` > `ptr.initialize(as: UInt16.self, at: 0, value: value, count: 13)` Works for me if it’s reasonably consistent with

[swift-evolution] [Accepted with Revision] SE-0181: Package Manager C/C++ Language Standard Support

The review of SE-0181: Package Manager C/C++ Language Standard Support ran from July 11...14, 2017. The proposal has been accepted for Swift 4. There was support for the general feature, with some discussion of the spelling. We chose to accept the proposal mostly unmodified: 1. While we agreed

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

What about `value:`? `ptr.initialize(value: value)` `ptr.initialize(value: value, count: 13)` `ptr.initialize(as: UInt16.self, at: 0, value: value, count: 13)` On Wed, Jul 19, 2017 at 12:01 PM, Andrew Trick wrote: > > On Jul 18, 2017, at 9:42 PM, Taylor Swift

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

> On Jul 18, 2017, at 9:42 PM, Taylor Swift wrote: > > 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)` Right. Given the default `count`

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

Another valid reason to nullify implicitly unwrapped optional would be to free up some memory. I don’t think we want to disallow this behavior. If you really need to be unable to assign nil to an implicitly unwrapped optional, you can fake it using this code. S.value acts like an implicitly

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

Implicitly unwrapped optionals are often used when the optional system is a little complicated around one of your variables. Some of those times are variables that are nil-resettable (where you set nil, and it internally does something to use that as a reset case) or initialisation issues

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

FWIW, the label should be "repeating". On Tue, Jul 18, 2017 at 11:42 PM, Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: > 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: