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

[Kelvin Ma via swift-evolution]

On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu  wrote:

> On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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])
>>
>
> Fully embracing slice notation and SwiftLint style, this could be:
>
> newBuffer[...].moveInitialize(from: buffer[zero...])
> newBuffer[zero...].moveInitialize(from: buffer[..

Is the solo ellipsis operator even valid Swift syntax? And I agree this
would look nice, but as others have mentioned, Swift has the convention
that the one-sided slice operators are equivalent to start ...
endIndex and startIndex
... end. And that seems to strongly suggest that the method would
initialize the entire range which is not what we want to communicate.


>
> 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.
>>
>
> Would you mind rewriting these examples in a more common Swift style (for
> instance, SwiftLint/GitHub style)? Everyone is entitled to write code how
> they please, but it’s much easier to compare how things “look” when the
> overall formatting is more familiar.
>

I mean the purpose of the example is to compare the call sites of the
actual buffer methods. ignoring the function signatures and instead getting
distracted by brace placement seems like the kind of bikeshedding we should
be discouraging lol.


>
>
>> ___
>> 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

[Slava Pestov via swift-evolution]

> On Oct 10, 2017, at 1:00 PM, Slava Pestov  wrote:
> 
>> 
>> On Oct 9, 2017, at 10:54 AM, Jordan Rose  wrote:
>> 
>> 
>> 
>>> 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.)
> 
> I’m minorly opposed, because it feels like a slippery slope. What about 
> function bodies? etc
> 
> func foo() -> Int { 3 } // should this be allowed?

In fact the reason I thought the original thread was about omitting the return 
type, rather than just omitting the ‘return’, is that I feel the main reason 
that single-expression closures exist is so that their type can be inferred as 
part of the expression containing the closure. Swift does not infer types 
across statement boundaries, so single expression closures exist, as a special 
case, to help you avoid declaring types in some cases.

Chris will say no, it’s about concision, and omitting the ‘return’, but deep 
down in his heart, he knows that single-expression closures were really just a 
type inference hack :-)

Slava

> 
> Slava
> 
>> 
>> Jordan

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

Re: [swift-evolution] Property Getter Return Statement

[Slava Pestov via swift-evolution]

> On Oct 9, 2017, at 10:54 AM, Jordan Rose  wrote:
> 
> 
> 
>> 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.)

I’m minorly opposed, because it feels like a slippery slope. What about 
function bodies? etc

func foo() -> Int { 3 } // should this be allowed?

Slava

> 
> 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 10 October 2017 at 07:02, Xiaodi Wu  wrote:

> This idea was discussed long ago and the present design was selected. At
> this point in Swift Evolution, source-breaking changes are in scope only if
> the status quo is demonstrably harmful.


changes like discussed are not necessarily source-breaking: you can allow
@discardableResult for a while (along with deprecating it at some point) in
addition to having a newer preferred way - should we decide there is a
preferred way.

on Mon, 09 Oct 2017 20:07:13 +0200 Tino Heth  wrote:

> As for the line-length, I don’t buy this argument, because placement of
> line breaks is just personal preference, and keywords/annotations created
> by gluing together two words should imho avoided wherever possible (not
> only because the increased character count).


+1. same here on both counts. multi-word compound and @ symbol makes names
ugly. it feels it was done intentionally to indicate a "temporary" "to be
cleaned later" nature of a feature (it is a very good choice for @objc)

and if "fileprivate" is ugly because it is two words glued together (*)
maybe there is another name for it? just "file"? "domestic" ?

Mike
(* the very concept of "file private" is a bit ugly from a traditional
languages perspective).
___
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 10, 2017, at 8:24 AM, Vladimir.S  wrote:
> 
> On 09.10.2017 20:36, Jose Cheyo Jimenez 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?
> 
> I'd like to reply with Xiaodi's words(I hope he will not be against this):
> 
> >---<
> The documentation is correct. To interpret it, you must understand that 
> extensions are not entities and therefore do not have accessibility of their 
> own; an access modifier in front of “extension” acts only as a shorthand to 
> set the default and maximum access level of contained members. This aspect of 
> Swift is not up for change, only the question of what the “private” shorthand 
> means.
> >---<
> 
> i.e. extension is another "thing" than type. You should not derive any 
> rules/expectation of how access modifiers work for extension based on rules 
> for type. This could be even(as I showed) dangerous.
> 
> Given the *definition* (and the "spirit", as I undertand it) of how access 
> modifiers work for extensions, and how this rule *differs* from access 
> modifiers for type, plus given the potential bugs produced by current rule 
> for 'private extension' but no problems if one declared 'true' private 
> extension but needs fileprivate access level, and over-complicated rules for 
> access modifiers in Swift, and given we can't have a extension of true 
> private members, especially in the light of new visibility rules for private 
> members in extensions in the same file - all this leads me to conclusion that 
> we need to make change. I understand that you have another opinion, but for 
> me, it is clear that pros of the change are much better than status quo and 
> than possible cons of the change.
> 
> I.e. I do think current situation is harmful enough to be changed now, and 
> now is the last chance to fix this for observable future(i.e. after Swift 5).
> 
> As for changing the rules for access modifiers for extensions or their 
> syntax, as Xiaodi already mentioned, this is out of scope for current 
> discussion and most likely will not be discussed ever soon.

If the main motivation for changing the rules for `private extension` is 
because it can lead to bugs, then you can not just dismiss the elephant in the 
room that is `public extension`. Accidentally leaking a public interface is 
more damaging than accidentally using an implementation detail. SE-0119 was 
about completely removing extension modifiers. 

I am all for fixing the inconsistencies but I do not believe that `private 
extension` is inconsistent. 

> 
> Actually, I feel like we start to repeat the opinions/arguments regarding the 
> subject, so probably we need to decide if we need a formal proposal. Or 
> probably we should collect even more opinions on this? Right now I feel like 
> the most opinions are positive, or I'm wrong?

Go for it. I am completely against it but lets see what the community has to 
say. 

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

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

[Tino Heth via swift-evolution]

I don’t remember all the details, but this has been discussed when results 
became „non-discardable“ by default, and afair it was even proposed as a 
possible future improvement to make the change less ugly for those who were 
fine with the original behavior.

As for the line-length, I don’t buy this argument, because placement of line 
breaks is just personal preference, and keywords/annotations created by gluing 
together two words should imho avoided wherever possible (not only because the 
increased character count).
___
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 09.10.2017 20:36, Jose Cheyo Jimenez 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?


I'd like to reply with Xiaodi's words(I hope he will not be against this):

>---<
The documentation is correct. To interpret it, you must understand that extensions are not entities and therefore do not 
have accessibility of their own; an access modifier in front of “extension” acts only as a shorthand to set the default 
and maximum access level of contained members. This aspect of Swift is not up for change, only the question of what the 
“private” shorthand means.

>---<

i.e. extension is another "thing" than type. You should not derive any rules/expectation of how access modifiers work 
for extension based on rules for type. This could be even(as I showed) dangerous.


Given the *definition* (and the "spirit", as I undertand it) of how access modifiers work for extensions, and how this 
rule *differs* from access modifiers for type, plus given the potential bugs produced by current rule for 'private 
extension' but no problems if one declared 'true' private extension but needs fileprivate access level, and 
over-complicated rules for access modifiers in Swift, and given we can't have a extension of true private members, 
especially in the light of new visibility rules for private members in extensions in the same file - all this leads me 
to conclusion that we need to make change. I understand that you have another opinion, but for me, it is clear that pros 
of the change are much better than status quo and than possible cons of the change.


I.e. I do think current situation is harmful enough to be changed now, and now is the last chance to fix this for 
observable future(i.e. after Swift 5).


As for changing the rules for access modifiers for extensions or their syntax, as Xiaodi already mentioned, this is out 
of scope for current discussion and most likely will not be discussed ever soon.


Actually, I feel like we start to repeat the opinions/arguments regarding the subject, so probably we need to decide if 
we need a formal proposal. Or probably we should collect even more opinions on this? Right now I feel like the most 
opinions are positive, or I'm wrong?


Vladimir.






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 

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

[Xiaodi Wu via swift-evolution]

On Mon, Oct 9, 2017 at 13:51 C. Keith Ray via swift-evolution <
swift-evolution@swift.org> wrote:

>
> 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".
>

No, its members are fileprivate to the file in which the extension resides.

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.
>

The documentation is correct. To interpret it, you must understand that
extensions are not entities and therefore do not have accessibility of
their own; an access modifier in front of “extension” acts only as a
shorthand to set the default and maximum access level of contained members.
This aspect of Swift is not up for change, only the question of what the
“private” shorthand means.

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 <
> swift-evolution@swift.org> wrote:
>
>
> On Oct 9, 2017, at 9:17 AM, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> 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 

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

[Xiaodi Wu via swift-evolution]

On Mon, Oct 9, 2017 at 12:36 Jose Cheyo Jimenez via swift-evolution <
swift-evolution@swift.org> wrote:

> On Oct 9, 2017, at 9:17 AM, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> 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.
>

This idea was discussed previously and rejected. It’s outside of the narrow
topic here of the meaning of “private extension” specifically.


> 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 publicfunc myFunc(){} // 
> default internal, upperbound higher it stays internal. }internal extension 
> MyOpenClass { // upper bound internalfunc myFunc2(){} // default internal}
> fileprivate extension MyOpenClass { // upper bound fileprivatefunc 
> myFunc3(){} // default internal but lowered to fileprivate}
> private extension MyOpenClass { // upper bound toplevel privatefunc 
> 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 

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

[Xiaodi Wu via swift-evolution]

This idea was discussed long ago and the present design was selected. At
this point in Swift Evolution, source-breaking changes are in scope only if
the status quo is demonstrably harmful.
On Mon, Oct 9, 2017 at 17:16 Mike Kluev via swift-evolution <
swift-evolution@swift.org> wrote:

> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <
swift-evolution@swift.org> wrote:

> 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])
>

Fully embracing slice notation and SwiftLint style, this could be:

newBuffer[...].moveInitialize(from: buffer[zero...])
newBuffer[zero...].moveInitialize(from: buffer[.. 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.
>

Would you mind rewriting these examples in a more common Swift style (for
instance, SwiftLint/GitHub style)? Everyone is entitled to write code how
they please, but it’s much easier to compare how things “look” when the
overall formatting is more familiar.


> ___
> 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