[swift-evolution] SE-1084 (B): buffer pointer partial initialization API

Hi guys, after passing SE 184 (A) , I want to get some community feedback on the next phase of our Swift pointer overhaul which is a partial initialization/deinitialization API for

Re: [swift-evolution] Pitch: Restrict Cross-module Struct Initializers

> On Oct 7, 2017, at 14:44, Chris Lattner wrote: > > >> On Oct 6, 2017, at 2:32 PM, Jordan Rose via swift-evolution >> > wrote: >> >> While working on the non-exhaustive enums proposal I had it pointed out to

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

On 9 October 2017 at 20:43, Howard Lovatt wrote: > > I would prefer something like: > > func x() -> Bool @ throws disguardableResult public async mutating > > Where @ introduces a list of space separated modifiers. > make it more English :) public async mutating

Re: [swift-evolution] Property Getter Return Statement

So you’re saying the core team _might_ consider a review if we’ve get a full proposal + implementation in Swift 5 timeframe? If yes, we only would need someone to implement my proposal. :) Am 9. Oktober 2017 um 19:54:50, Jordan Rose via swift-evolution (swift-evolution@swift.org) schrieb:

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

Personally I would prefer all the modified to go on the right, so that the declaration is sorted from most important to least left to right. EG: Instead of: @disguardableResult public async mutating func x() throws -> Bool I would prefer something like: func x() -> Bool @ throws

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html Says... "Alternatively, you can mark an extension with an explicit access-level modifier (for example, private extension) to set a new default access level for all members

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

On Sat, 7 Oct 2017 07:48:08 +0100, wrote: > So it would be: > > func() -> @discardable Bool { } > > Rather than: > > @discardableResult func() -> Bool { } > i'd say: func foo() -> discardable Bool { ... } if we were starting from scratch It could be

Re: [swift-evolution] Property Getter Return Statement

> On Oct 8, 2017, at 21:56, Slava Pestov via swift-evolution > wrote: > > > >> On Oct 7, 2017, at 7:07 AM, James Valaitis via swift-evolution >> wrote: >> >> Is it widely agreed that it is necessary to require a return statement on a

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

> On Oct 9, 2017, at 9:17 AM, Vladimir.S via swift-evolution > wrote: > > On 07.10.2017 20:17, Nevin Brackett-Rozinsky via swift-evolution wrote: >> Two weeks ago I had a fairly strong opinion about “private extension” >> behavior. After following this discussion, I

Re: [swift-evolution] Pitch: Restrict Cross-module Struct Initializers

Thanks for bringing this up. I thought of this only after posting the proposal, and I think the answer ought to be "you're exempt from this restriction if you use `@testable import`". I still want to work out that this is implementable even for future frameworks with binary compatibility

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

I agree with this, function signatures in Swift are long enough as it is, fitting them in 80 characters is hard enough already On Mon, Oct 9, 2017 at 11:14 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > async is a keyword where as @discardableResult is an attribute.

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

On 07.10.2017 20:17, Nevin Brackett-Rozinsky via swift-evolution wrote: Two weeks ago I had a fairly strong opinion about “private extension” behavior. After following this discussion, I now have no opinion on the matter. I would summarize the points on both sides as follows: For the change:

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

> On Oct 9, 2017, at 9:02 AM, Dave DeLong via swift-evolution > wrote: > > Oooo, I really like this. > > It also brings up an interesting point on the whole async discussion. Doesn’t > the async apply to the return value and not the other stuff? No, the whole

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

async is a keyword where as @discardableResult is an attribute. This pitch does not include any advantages over the current form. In fact this will rather harm the readbility because you no longer can nicely put the annotation above the function and it won’t play well with other keywords like

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

Oooo, I really like this. It also brings up an interesting point on the whole async discussion. Doesn’t the async apply to the return value and not the other stuff? IE instead of: async func getBool() → Bool It could be: func getBool() → async Bool Dave > On Oct 9, 2017, at 9:58 AM, Fil

[swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

I find it extremely cumbersome to have to precede a function declaration with such an extensive annotation such as @discardableResult Now that so many functions do need this annotation to be there, our code became so ugly. Besides, having this annotation precede the function declaration kind of

Re: [swift-evolution] RFC: structuring forums for best use for swift-evolution

Was there any progress made on this? It almost feels like were not going to move to a forum until Swift 6-7. Would be interesting to see a sign of progress here. :) Am 3. August 2017 um 23:14:16, Erica Sadun via swift-evolution (swift-evolution@swift.org) schrieb: When moving to a forum, the

Re: [swift-evolution] Property Getter Return Statement

Even I would personally want this, this request didn’t made into Swift 3, nor in Swift 4 and is clearly out of scope for Swift 5. You can read my proposal here which includes all areas where this could be allowed: