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

[Kelvin Ma via swift-evolution]

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
UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer.

You can read about the originally proposed API in the original SE 184
document
,
basically we use an at:from: system for binary memory state operations
where the at: argument supplies the start position in the destination
buffer, and the from: source argument supplies the number of elements to
copy/move into the destination.

newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])
newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..< self.zero])

Some other proposed APIs include using subscript notation, and writing a
special buffer slice type and a corresponding protocol to handle this.

newBuffer[0...].moveInitialize(from:
self.buffer[self.zero...   ])
newBuffer[self.zero ... self.zero << 1].moveInitialize(from: self.buffer[0
..< self.zero])

A hypothetical comparison of this API, the at:from: API, and the existing
plain pointer API can be found in this basic Swift queue implementation here
 if
anyone wants to see how this would look in “real” code. I’m interested in
seeing which syntax and which API is preferred as well as what people would
like to do with an expanded Swift buffer pointer toolbox.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

> 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 
>> me that structs actually currently leak implementation details across module 
>> boundaries, specifically their full set of stored properties. This only 
>> comes up in one place: when making an initializer for the struct in an 
>> extension in another module. We really want people to be able to change the 
>> stored properties in their structs between releases without it being a 
>> source break—that's half the point of computed properties—and it's also 
>> important for a struct author to be able to enforce invariants across the 
>> struct's properties. So after talking to a few other Apple Swift folks I put 
>> together this proposal:
>> 
>> https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/-restrict-cross-module-struct-initializers.md
>>  
>> 
>> 
>> This one's way smaller than the enum one, and hopefully fairly 
>> uncontroversial. Feedback welcome!
> 
> Great catch, +1 to the proposal!
> 
> Please add the point Xiodi mentions to the writing though so that the review 
> cycle adequately discusses it.  A "fragile struct” (for some definition of 
> fragility), but definitely including C structs, will have knowable stored 
> properties, and it isn’t clear that these should be subjected to this 
> restriction.  The win of the restriction in that case is the invariant point 
> you’re making.  It is best to address this head-on in the writing, and 
> mention the alternate approach in the ‘alternatives considered’ section 
> (along with why you think you’ve picked the right choice).

Good call. Updated the Alternatives Considered section with my response to 
Xiaodi, plus a specific section on C structs. (Also added the @testable part 
that Rudolf mentioned.)

Initial implementation has also been posted.

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mike Kluev via swift-evolution]

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 throwing func foo() -> discardable Bool {
...
}

Unfortunately I am not sure this is practical at this stage.
>

true :(

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Property Getter Return Statement

[Adrian Zubarev via swift-evolution]

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:



> 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 
>> one line property getter?
>>  
>> var session: AVCaptureSession { get { return layer.session } }
>>  
>> Or could we follow the convention for any other close and get rid of it? For 
>> me it seems redundant; the word `get` literally precedes the closure.
>  
> In multi-file projects, re-compiling one file that references the property 
> would necessitate type checking the body of the getter, even if the getter is 
> defined in a different source file. So one reason not to have this would be 
> to avoid slowing down type checking.

This is not correct. Omitting the "return" is different from omitting the 
property's type.

(I'm minorly in favor of allowing the 'return' to be omitted for 
single-expression getters. Not enough to be the person who implements it, but 
enough to +1 a proposal-with-implementation even in the Swift 5 timeframe.)

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Howard Lovatt via swift-evolution]

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 disguardableResult public async mutating

Where @ introduces a list of space separated modifiers. 

That’s why I also prefer:

   let x: Int // Swift

over:

   const int x // C

And moving the where clause to the end of the declaration. 

Unfortunately I am not sure this is practical at this stage. 

-- Howard. 

> On 10 Oct 2017, at 5:21 am, Mike Kluev via swift-evolution 
>  wrote:
> 
>> 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 even better if someone could perhaps find a shorter word that
>> is a synonym for the word "discardable", that would be as explicit in
>> intent as the word "discardable" is in such context, yet be written with
>> fewer characters.
> 
>  Mike
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[C. Keith Ray via swift-evolution]

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 defined within the extension. This new default can still be 
overridden within the extension for individual type members."

And...

"Private access restricts the use of an entity to the enclosing declaration, 
and to extensions of that declaration that are in the same file. Use private 
access to hide the implementation details of a specific piece of functionality 
when those details are used only within a single declaration."

So... a private extension where the main entity is in the same file has its 
members act as "fileprivate", but (we can infer that) a private extension where 
the main entity is NOT in the same file should have its members act as 
"private". 

Is that inference in accordance with the intentions of Swift's design?

If yes, then the compiler should enforce it. If not, then the documentation 
should be changed.

Does that summarize the proposal?

--
C. Keith Ray

* https://leanpub.com/wepntk <- buy my book?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Oct 9, 2017, at 10:36 AM, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> 
>> 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 now have no opinion on the 
>>> matter.
>>> I would summarize the points on both sides as follows:
>>> For the change:
>>> • It is surprising to many people that members of a private extension are 
>>> implicitly fileprivate. > • There is currently no way to make an extension 
>>> whose members default to private.
>> 
>> I'd add this:
>> * Current rule for 'private extension' can lead to bugs, when you expect 
>> that private methods will be 'true' private but they are fileprivate, so 
>> could be called from not-expected code in the same file. Inverse 
>> situation(when you need fileprivate but 'private extension' means 'true' 
>> private) - can't cause bugs, you'll be notified by the compiler if you need 
>> a 'wider' access level.
>> * The change will make the access-control rule for extensions simpler, not 
>> harder to understand.
>> * 'fileprivate' access level for methods in extension will be used by 
>> *intention*, not just because "this is how 'private extension' works". If I 
>> understand correctly, it is not the 'fileprivate' *keyword* we want to see 
>> less, but the fileprivate *access level*, which should be rare and 
>> intentional.
> 
> Top level private *is* private. Swift did not make a distinction between top 
> level private and fileprivate so why should the programmer have to choose?
> 
> If you explicitly declare something private at the top level you are going to 
> get fileprivate semantics. This is how scope private works. If you disagree 
> then that is a different conversation I think. If you wish for these not have 
> an overlap then that is definitely a different proposal?
> 
>> 
>>> Against the change:
>>> • The proposal is source-breaking.
>>> • The proposal makes “fileprivate” more common.
>> 
>> It depends on what most of Swift developers *mean* when writing 'private 
>> extension' - if they actually need 'fileprivate extension' - then yes, we'll 
>> see it more in code. But if in most cases the *intention* is to have a bunch 
>> of 'true private' methods - we'll have a small number of 'fileprivate 
>> extension'.
>> But in any case, what is the problem with this? If developer *needs* 
>> fileprivate access level for methods in extension - this will be clearly 
>> stated in code, not hidden under the cute title of 'private extension'
>> 
>>> • A private extension and a (top-level) private type both currently have 
>>> implicitly fileprivate members. The proposal breaks that symmetry.
>> 
>> Is it really good symmetry?
>> By definition, the rule for applying the access level to type is differ from 
>> the rule for extension. Here all symmetry already broken and we have 2 
>> separate rules. And from my point of view, having a symmetry in *this 
>> particular* case is a bad thing, it can lead to wrong assumptions. Don't you 
>> want to apply the same 'symmetry' rule for the code below ? :
> 
> I would be totally on board with making extensions work the same as types. So 
> instead of enforcing a default ACL, the extension would work the same way as 
> a type by just declaring the upper bound. This would effectively only allow 
> extension to lower the upper bound while still making the default ACL to 
> internal. This would also be a 

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

[Mike Kluev via swift-evolution]

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 even better if someone could perhaps find a shorter word that
> is a synonym for the word "discardable", that would be as explicit in
> intent as the word "discardable" is in such context, yet be written with
> fewer characters.
>

 Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Property Getter Return Statement

[Jordan Rose via swift-evolution]

> 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 
>> one line property getter?
>> 
>> var session: AVCaptureSession { get { return layer.session } }
>> 
>> Or could we follow the convention for any other close and get rid of it? For 
>> me it seems redundant; the word `get` literally precedes the closure.
> 
> In multi-file projects, re-compiling one file that references the property 
> would necessitate type checking the body of the getter, even if the getter is 
> defined in a different source file. So one reason not to have this would be 
> to avoid slowing down type checking.

This is not correct. Omitting the "return" is different from omitting the 
property's type.

(I'm minorly in favor of allowing the 'return' to be omitted for 
single-expression getters. Not enough to be the person who implements it, but 
enough to +1 a proposal-with-implementation even in the Swift 5 timeframe.)

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> 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 now have no opinion on the 
>> matter.
>> I would summarize the points on both sides as follows:
>> For the change:
>> • It is surprising to many people that members of a private extension are 
>> implicitly fileprivate. > • There is currently no way to make an extension 
>> whose members default to private.
> 
> I'd add this:
> * Current rule for 'private extension' can lead to bugs, when you expect that 
> private methods will be 'true' private but they are fileprivate, so could be 
> called from not-expected code in the same file. Inverse situation(when you 
> need fileprivate but 'private extension' means 'true' private) - can't cause 
> bugs, you'll be notified by the compiler if you need a 'wider' access level.
> * The change will make the access-control rule for extensions simpler, not 
> harder to understand.
> * 'fileprivate' access level for methods in extension will be used by 
> *intention*, not just because "this is how 'private extension' works". If I 
> understand correctly, it is not the 'fileprivate' *keyword* we want to see 
> less, but the fileprivate *access level*, which should be rare and 
> intentional.

Top level private *is* private. Swift did not make a distinction between top 
level private and fileprivate so why should the programmer have to choose?

If you explicitly declare something private at the top level you are going to 
get fileprivate semantics. This is how scope private works. If you disagree 
then that is a different conversation I think. If you wish for these not have 
an overlap then that is definitely a different proposal?

> 
>> Against the change:
>> • The proposal is source-breaking.
>> • The proposal makes “fileprivate” more common.
> 
> It depends on what most of Swift developers *mean* when writing 'private 
> extension' - if they actually need 'fileprivate extension' - then yes, we'll 
> see it more in code. But if in most cases the *intention* is to have a bunch 
> of 'true private' methods - we'll have a small number of 'fileprivate 
> extension'.
> But in any case, what is the problem with this? If developer *needs* 
> fileprivate access level for methods in extension - this will be clearly 
> stated in code, not hidden under the cute title of 'private extension'
> 
>> • A private extension and a (top-level) private type both currently have 
>> implicitly fileprivate members. The proposal breaks that symmetry.
> 
> Is it really good symmetry?
> By definition, the rule for applying the access level to type is differ from 
> the rule for extension. Here all symmetry already broken and we have 2 
> separate rules. And from my point of view, having a symmetry in *this 
> particular* case is a bad thing, it can lead to wrong assumptions. Don't you 
> want to apply the same 'symmetry' rule for the code below ? :

I would be totally on board with making extensions work the same as types. So 
instead of enforcing a default ACL, the extension would work the same way as a 
type by just declaring the upper bound. This would effectively only allow 
extension to lower the upper bound while still making the default ACL to 
internal. This would also be a breaking change for public extensions that 
assume their members to be public. I believe that the behavior of public 
extension is more harmful and more likely to cause bugs because you are 
exposing a public API and may not be aware of it. This would remove the ability 
of open types to be extended with a default ACL of public.  The same would 
happen to public types that are being extended with public modifier.

The below would be symmetrical but now public extension are essentially the 
same as just extension without the modifier.

open class MyOpenClass {}

public extension MyOpenClass { // upper bound public
func myFunc(){} // default internal, upperbound higher it stays internal. 
}
internal extension MyOpenClass { // upper bound internal
func myFunc2(){} // default internal
}

fileprivate extension MyOpenClass { // upper bound fileprivate
func myFunc3(){} // default internal but lowered to fileprivate
}

private extension MyOpenClass { // upper bound toplevel private
func myFunc4(){} // default internal but lowered to toplevel private
}



> 
> public class C {
>var i = 10
> }
> 
> public extension C {
>func j(){}
> }
> 
> ,as you understand 'i' is internal, while 'j()' is public. So this could be a 
> dangerous assumption.
> 
> 
>> Notable questions:
>> • Currently “open” cannot be applied to an extension at all, should we allow 
>> it?
> 
> Probably. But this should be a separate pitch/proposal.
> 
>> • Might we ever want to allow nested (non-top level) extensions, and if so 
>> how should 

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

[Jordan Rose via swift-evolution]

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 concerns (though the 
testable-only parts don't have to be a binary-compatible interface), but you're 
right that the proposal isn't really complete without that exception. I'll add 
it today.

Jordan


> On Oct 8, 2017, at 12:49, Rudolf Adamkovič via swift-evolution 
>  wrote:
> 
> This is a great proposal.
> 
> However, it can make unit testing problematic. Let me explain.
> 
> In my unit tests, I often add initializers that set stored properties 
> directly to create structs with desired data and those are then fed into the 
> struct that’s under test. This is to test in complete isolation, without 
> invoking the “production” initializer of structs that aren’t under test. In 
> other words, I want to avoid invoking any behavior of structs that aren’t 
> directly under test.
> 
> Would the rules described in this proposal be enforced also for testing 
> targets/modules?
> 
> R+
> 
> Sent from my iPhone
> 
> On 7 Oct 2017, at 23:44, Chris Lattner via swift-evolution 
> > 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 
>>> me that structs actually currently leak implementation details across 
>>> module boundaries, specifically their full set of stored properties. This 
>>> only comes up in one place: when making an initializer for the struct in an 
>>> extension in another module. We really want people to be able to change the 
>>> stored properties in their structs between releases without it being a 
>>> source break—that's half the point of computed properties—and it's also 
>>> important for a struct author to be able to enforce invariants across the 
>>> struct's properties. So after talking to a few other Apple Swift folks I 
>>> put together this proposal:
>>> 
>>> https://github.com/jrose-apple/swift-evolution/blob/restrict-cross-module-struct-initializers/proposals/-restrict-cross-module-struct-initializers.md
>>>  
>>> 
>>> 
>>> This one's way smaller than the enum one, and hopefully fairly 
>>> uncontroversial. Feedback welcome!
>> 
>> Great catch, +1 to the proposal!
>> 
>> Please add the point Xiodi mentions to the writing though so that the review 
>> cycle adequately discusses it.  A "fragile struct” (for some definition of 
>> fragility), but definitely including C structs, will have knowable stored 
>> properties, and it isn’t clear that these should be subjected to this 
>> restriction.  The win of the restriction in that case is the invariant point 
>> you’re making.  It is best to address this head-on in the writing, and 
>> mention the alternate approach in the ‘alternatives considered’ section 
>> (along with why you think you’ve picked the right choice).
>> 
>> -Chris
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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. 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 throws, rethrows and async.
>
> @discardableResult
> funx foo() { /* ... */  }
>
> So -1 for this pitch.
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 9. Oktober 2017 um 18:02:14, Dave DeLong via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
>> 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 Ipe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> 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
>> reminds me of C rather than Swift. Since in C the function declarations
>> started by the type of the return value.
>>
>> I, therefore, think it would be much softer on the eye, and much more
>> precise in intent, to instead precede the result of a func with a simpler
>> and shorter @discardable annotation
>>
>> So it would be:
>>
>> func() -> @discardable Bool { }
>>
>> Rather than:
>>
>> @discardableResult func() -> Bool { }
>>
>> It could be even better if someone could perhaps find a shorter word that
>> is a synonym for the word "discardable", that would be as explicit in
>> intent as the word "discardable" is in such context, yet be written with
>> fewer characters.
>>
>> Swift regards,
>> Filipe Sá.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Vladimir.S via swift-evolution]

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:
• It is surprising to many people that members of a private extension are 
implicitly fileprivate. > • There is currently no way to make an extension 
whose members default to private.


I'd add this:
* Current rule for 'private extension' can lead to bugs, when you expect that private methods will be 'true' private but 
they are fileprivate, so could be called from not-expected code in the same file. Inverse situation(when you need 
fileprivate but 'private extension' means 'true' private) - can't cause bugs, you'll be notified by the compiler if you 
need a 'wider' access level.

* The change will make the access-control rule for extensions simpler, not 
harder to understand.
* 'fileprivate' access level for methods in extension will be used by *intention*, not just because "this is how 
'private extension' works". If I understand correctly, it is not the 'fileprivate' *keyword* we want to see less, but 
the fileprivate *access level*, which should be rare and intentional.




Against the change:
• The proposal is source-breaking.
• The proposal makes “fileprivate” more common.


It depends on what most of Swift developers *mean* when writing 'private extension' - if they actually need 'fileprivate 
extension' - then yes, we'll see it more in code. But if in most cases the *intention* is to have a bunch of 'true 
private' methods - we'll have a small number of 'fileprivate extension'.
But in any case, what is the problem with this? If developer *needs* fileprivate access level for methods in extension - 
this will be clearly stated in code, not hidden under the cute title of 'private extension'


• A private extension and a (top-level) private type both currently have implicitly fileprivate members. The proposal 
breaks that symmetry.


Is it really good symmetry?
By definition, the rule for applying the access level to type is differ from the rule for extension. Here all symmetry 
already broken and we have 2 separate rules. And from my point of view, having a symmetry in *this particular* case is a 
bad thing, it can lead to wrong assumptions. Don't you want to apply the same 'symmetry' rule for the code below ? :


public class C {
var i = 10
}

public extension C {
func j(){}
}

,as you understand 'i' is internal, while 'j()' is public. So this could be a 
dangerous assumption.




Notable questions:
• Currently “open” cannot be applied to an extension at all, should we allow it?


Probably. But this should be a separate pitch/proposal.


• Might we ever want to allow nested (non-top level) extensions, and if so how 
should access levels on them work?


Not sure if we need them, this is also a subject for separate pitch/proposal.
But if the rule for applying the access level for extension will be as currently(I don't believe we'll change it soon) - 
nested extensions should work the same "the access level keyword stated before the 'extension' keyword will be virtually 
copy to the beginning of each method declaration inside extension and then resolved", IMO this is a most clear 
rule we can have *in case rule for extensions is differ from rule for type".


Vladimir.



Nevin


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> 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 function including any side effects gets executed asynchronously. 
"Pure" functions could (sorta) be regarded as only having the "async" apply to 
the return value, but that mental model is incorrect and it only gives the 
right "answer" as a consequence of the function being pure.

At least, if I understand things correctly.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 throws, rethrows and 
async.  

@discardableResult  
funx foo() { /* ... */ }

So -1 for this pitch.
--  
Adrian Zubarev
Sent with Airmail  

Am 9. Oktober 2017 um 18:02:14, Dave DeLong via swift-evolution 
(swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:

>  
> 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 Ipe via swift-evolution 
> >  wrote:  
> > 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 
> > reminds me of C rather than Swift. Since in C the function declarations 
> > started by the type of the return value.  
> >  
> > I, therefore, think it would be much softer on the eye, and much more 
> > precise in intent, to instead precede the result of a func with a simpler 
> > and shorter @discardable annotation  
> >  
> > So it would be:  
> >  
> > func() -> @discardable Bool { }  
> >  
> > Rather than:  
> >  
> > @discardableResult func() -> Bool { }  
> >  
> > It could be even better if someone could perhaps find a shorter word that 
> > is a synonym for the word "discardable", that would be as explicit in 
> > intent as the word "discardable" is in such context, yet be written with 
> > fewer characters.  
> >  
> > Swift regards,  
> > Filipe Sá.
> >  
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>  
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave DeLong via swift-evolution]

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 Ipe via swift-evolution 
>  wrote:
> 
> 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 
> reminds me of C rather than Swift. Since in C the function declarations 
> started by the type of the return value.
> 
> I, therefore, think it would be much softer on the eye, and much more precise 
> in intent, to instead precede the result of a func with a simpler and shorter 
> @discardable annotation
> 
> So it would be:
> 
> func() -> @discardable Bool { } 
> 
> Rather than: 
> 
> @discardableResult func() -> Bool { } 
> 
> It could be even better if someone could perhaps find a shorter word that is 
> a synonym for the word "discardable", that would be as explicit in intent as 
> the word "discardable" is in such context, yet be written with fewer 
> characters.
> 
> Swift regards,
> Filipe Sá.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Fil Ipe via swift-evolution]

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
reminds me of C rather than Swift. Since in C the function declarations
started by the type of the return value.

I, therefore, think it would be much softer on the eye, and much more
precise in intent, to instead precede the result of a func with a simpler
and shorter @discardable annotation

So it would be:

func() -> @discardable Bool { }

Rather than:

@discardableResult func() -> Bool { }

It could be even better if someone could perhaps find a shorter word that
is a synonym for the word "discardable", that would be as explicit in
intent as the word "discardable" is in such context, yet be written with
fewer characters.

Swift regards,
Filipe Sá.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via 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 problem becomes a thread splintering to an 
overwhelming tree. I'd prefer to see a single primary thread (as in the mailing 
lists) with breakout threads for working groups. These could be built either 
around already identified areas (see manifestos) or future directions (such as 
mathematics, fp, merging features from other languages). 
I think announce should announce.  One thread, one purpose.
I think evolution should have a review forum: one thread for each proposal.
Pitches and RFC should have their own forum, with individual threads. The 
dangers here are (1) losing good ideas, (2) good ideas that are timed poorly, 
(3) redundant ideas from not having found previous discussions, (4) well 
intentioned but inappropriate ideas. Having a way to filter types 3 and 4 out 
to a subforum to raise the S:N should be possible but will require some kind of 
moderation (such as Xiodi Wu has put such effort into supporting)
Working groups need their own development area. There needs to be some sort of 
top-level organization to make this usable ("Generics", "Dispatch", 
"Calendar/Clocks/Time", "Mathematics", "Strings", "Collections", whatever), but 
there should also be a level of flexiblity. I'd recommend giving manifesto 
topics initial priority at the top level but I'd also suggest that there have 
to be some kind of effort to open a new discussion area, to limit the number of 
"ghost forums".
A SE version of a FAQ, be it "Commonly Proposed"/"Commonly Rejected" and some 
kind of Quinn-like Eskimo support for directing and moderating.

The measures of success are:

* Can track news ("announce")
* Can participate in active reviews
* Can read archived reviews
* Can pitch and develop proposals as part of a working group
* Can search for previous discussions
* Can look up whether common topics have already been hit 
* Can support a small and well-populated forum hierarchy with few orphans and 
ghosts
* Communicates that the forum is a non-social working area and a public record 
of language development.

-- E


On Aug 1, 2017, at 11:13 PM, Ted Kremenek via swift-evolution 
 wrote:

A while back a decision was reached to move from using mailing lists for 
swift-evolution to using a forum, specifically Discourse.  At the time that 
decision was made, efforts had been already well committed for supporting the 
development of Swift 4 — including efforts supporting important infrastructure 
efforts such as the source compatibility suite.  I apologize for not providing 
more transparency in why moving to a forum was being delayed.  Some things took 
longer than expected.

To be clear, the plan is to still move to Discourse, and with Swift 4 winding 
down there is now bandwidth to focus on making the transition from mailing 
lists to a forum.  As part of that transition, I’d like to get some feedback 
from the community.

There has been some good conversations on this mailing list on how 
swift-evolution can possibly evolve to better serve the needs of the community. 
 I’m not talking about whether or not we use a mailing list or a forum — that 
decision has been made.  Specifically, I’m talking about how a forum could best 
be structured to organize discussions and allow everyone to optimally 
participate.  In the move to Discourse, we have the opportunity here to 
possibly do things a bit differently than we have been so far.

For example, here are some of the questions I’m thinking about how we should be 
use a forum:

-  We currently have swift-evolution and swift-evolution-announce.  Should we 
use a specific “category” in the forum for "proposals that are in active 
review" — and possibly remove the need to have something like 
swift-evolution-announce?  

- Should we have other topical areas to organize discussions?  If so, at what 
granularity?

We can certainly figure out a lot of this over time, but I’d like some feedback 
from the community now on things they’d like to see in how we organize the 
swift-evolution forum based on experiences we’ve had with swift-evolution since 
it was created.

Please chime in on this thread if you have feedback, and focus on keeping this 
constructive.

Thanks,
Ted
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Property Getter Return Statement

[Adrian Zubarev via swift-evolution]

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: 
https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md

Here are two posts from Chris Lattner why this feature won’t come any time soon:

- 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032376.html

- 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032446.html

Am 9. Oktober 2017 um 06:56:19, Charles Srstka via swift-evolution 
(swift-evolution@swift.org) schrieb:

On Oct 7, 2017, at 12:22 PM, Tony Allevato via swift-evolution 
 wrote:

I think the important thing to consider is, what advantage would such a feature 
provide *other* than to reduce keystrokes? (I don't personally think that 
optimizing for keys pressed by itself should be a goal.)

Consistency? I know I’ve accidentally left out the ‘return’ enough times due to 
muscle memory from writing closures kicking in, and then had to go back and fix 
it. Having two different sets of rules for two very similar constructs makes 
the development process slower.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution