Re: [swift-evolution] final + lazy + fileprivate modifiers

[Goffredo Marocchi via swift-evolution]

I think it would be a step back as it again oversimplifies access control IMHO. 
If we touch access control we should aim to improve it from both a library 
implementation point of view but for a user point of view as well.

Sent from my iPhone

> On 16 Feb 2017, at 06:20, Chris Lattner via swift-evolution 
>  wrote:
> 
> On Feb 14, 2017, at 11:46 PM, Jean-Daniel via swift-evolution 
>  wrote:
 Keeping with the spirit of Swift and staying consistent with its design, I 
 see two plausible meanings for private:
 
 Private could mean either:
> ...
 (2) accessible only to the current type/scope and to extensions to that 
 type that are in the current file.
>>> 
>>> I think (2) is worth discussing. My 2 cents:
>>> 
>>> Pros
>>> • Solves a high percentage of use cases of fileprivate
>>> • Type-scope proponents retain some of the safety
>>> 
>>> Cons
>>> • Less straight forward to explain
>>> • Access to different type/scope in same file not possible anymore
>> 
>> Which means that if we choose 2, we must keep fileprivate.
>> Being able to access other type private members in the same file is an 
>> important feature that can’t be easily replaced, so it would badely break 
>> existing code if we remove it.
> 
> Yeah, I think you’re right, which sinks the whole idea: we should aim to 
> (re)simplify the access control model.  (2) is also problematic because it 
> doesn’t allow the private members to be used by other things in the same 
> file.  E.g. use a private member of Foo in an extension on String.
> 
> IMO, removing fileprivate and making private match Swift 2 semantics seems 
> like the more promising approach.
> 
> -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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Rien via swift-evolution]

> On 16 Feb 2017, at 03:45, David Smith  wrote:
> 
>> 
>> On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution 
>>  wrote:
>> 
>>> 
>>> On 15 Feb 2017, at 17:02, Matthew Johnson  wrote:
>>> 
 
 On Feb 15, 2017, at 9:59 AM, Rien  wrote:
 
> 
> On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:
> 
>> 
>> On Feb 15, 2017, at 9:35 AM, Rien  wrote:
>> 
>> 
>>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
  wrote:
 
 
> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> 
> Our philosophy in general, however, is to default to the behavior 
> which preserves the most flexibility for the library designer.
 
 Actually, I thought the philosophy was to preserver type safety. When 
 did that change?
 
 Also, when was the library designer prioritised ahead of the 
 application developer?
 
 
> Both open and non-open classes are common, but we chose to give 
> non-open classes the `public` keyword because that's the 
> flexibility-preserving option.
 
 No it isn’t, it’s the flexibility restricting option. The consumer of 
 an open class can subclass it. The consumer of a public class cannot 
 subclass it. How is the second more flexible than the first?
>>> 
>>> It reduces complexity for the library author by allowing them to 
>>> opt-out of the complexity involved in supporting unknown, user-defined 
>>> subclasses.  It is important to allow libraries to have this 
>>> flexibility. They are free to declare a class `open` if they want to 
>>> allow subclassing. It’s even possibly for a library to declare all 
>>> classes `open` if it wishes to do so.  But *requiring* that would 
>>> reduce the design space libraries are allowed to explore and / or 
>>> introduce fragility by moving the subclass restriction to a comment.
>>> 
>> 
>> Why would a library author want to prohibit subclasses?
>> A library user can always wrap the class and subclass the wrapper.
> 
> This is composition, not inheritance.  The most important difference is 
> that a wrapper cannot override methods, it can only wrap and / or forward 
> them.  This means that when the superclass calls a method on `self` that 
> method *always* invokes its version of that method rather than a subclass 
> override.  This is a very important difference.
> 
 
 Agreed, however that does not answer the question why would a library 
 developer want to disallow subclassing?
 I do not see a use case for that. I.e. a feature that cannot be 
 implemented without it. (without “open”)
>>> 
>>> The feature it enables is more robust libraries and the ability for library 
>>> authors to better reason about their code.  You may not find this benefit 
>>> enough to be worth a language feature, but many of us do.
>> 
>> You start of with a claim “more robust libraries”.
>> I would really like to know the “how” of that. How does it make a library 
>> more robust?
>> 
>> I do write libraries myself, and if there is something I am missing, I very 
>> much would like to know.
>> 
>> Regards,
>> Rien.
> 
> The usual thing I've run into in practice follows this general pattern:
> 
> • A non-threadsafe class is introduced
> • Years or decades pass
> • Someone (me) tries to make the class threadsafe by adding locking
> • In the intervening years, subclasses have been introduced that override 
> methods now called while holding a lock, and reentrantly call back into other 
> methods that take the lock
> 
> I've worked around this using recursive mutexes in some cases, but in more 
> extreme cases the subclass synchronously called out to another thread, and 
> that thread reentered the lock.
> 
> A defensive rule I've adopted in some new code is "public methods are not 
> allowed to call other public methods", which avoids reentrancy issues, but 
> also makes subclassing somewhat useless since the work is being done by 
> private non-overridable methods.
> 
>   David
> 

That is imo a good usage of this feature “because it exists”.
However, on my list, it would fall short of making the feature “necessary”.

Like many access level “problems” they don’t really make something possible, 
they just document what should not be done. And since nobody RTFM 
(stackoverflow) that may seem like enough to justify something. However it can 
never replaced knowledge.

Regards,
Rien

Site: 

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Charlie Monroe via swift-evolution]

> On Feb 16, 2017, at 7:18 AM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> 
>> On Feb 15, 2017, at 3:45 PM, Tony Parker via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Feb 15, 2017, at 2:25 PM, Charles Srstka >> > wrote:
>>> 
 On Feb 15, 2017, at 3:11 PM, Itai Ferber > wrote:
 
 FYI, Tony is the manager of the Foundation team. :)
 We care very much about making sure that the experience of using our 
 framework is a positive one — the more Radars we get, the better we can 
 prioritize improving APIs that are not working as well as they could be 
 for our users. Even if the Radar gets duped to an existing one, thats one 
 more +1 for that Radar saying "this is a problem".
 
>>> Yeah I know, but it’s a frustrating experience, spending a half hour 
>>> writing a detailed bug report (sometimes with videos attached to 
>>> demonstrate the issue), just to effectively do the same thing as spending 5 
>>> seconds to hit the +1 button on most issue trackers you come across.
>>> 
>>> Especially since you never find out what happened to the original bug 
>>> report. You can see if it’s open or closed, but did they fix it in some 
>>> internal build? Did they decide it “behaves correctly?” Did somebody just 
>>> skim your report, and mistakenly attach it to some other, unrelated issue? 
>>> There’s no way to know.
 I will search for your old Radar, but in any case, please do file a new 
 one about this, and about any other issues you have, because we are indeed 
 listening.
 
>>> 
>>> I was pretty sure I'd submitted something way, way back in the misty days 
>>> of yore, but I can’t find it. I’ve filed a couple of new ones: 
>>> rdar://30543037  and rdar://30543133 .
>>> 
>>> Charles
>>> 
>> 
>> Thanks for filing these.
>> 
>> Sometimes, for process reasons, we do indeed mark bugs as dupes of other 
>> ones. Usually the polite thing to do is to dupe to the earliest filed one. 
>> Sometimes this comes across with an appearance of not caring to the filer of 
>> the new bug,
> 
> At the risk of getting off-topic, I think it would defuse a lot of developer 
> frustration around that to just show the status (open/fixed/wontfix/correct) 
> of the root bug.  Filed radar 30551245 suggesting as much ;-)

Wouldn't it be possible for Apple to add a checkbox next to the issue that the 
reporter can check consenting the issue becoming public? I fully understand 
that many of the issues reported are confidential (security issues, attached 
code, etc.); but there are many, many, many issues that I'd be comfortable with 
becoming public so that others can just +1 them and see their status; or even 
comment on them, suggest workarounds. Something like OpenRadar does...

> 
>> but our intent is simply to consolidate the reports we have so that we know 
>> that the issue is serious.
>> 
>> We do not make API changes without going through a vigorous review process, 
>> to avoid churn for the many clients above us. The flip side is that this can 
>> take some time. I’m sure you understand that all software engineering is 
>> about tradeoffs.
>> 
>> All of that said, we’ll take a look at these and see what improvements we 
>> can make here. As I said, I’m not a fan of exception-based API.
>> 
>> - Tony
>> 
>> 
>> ___
>> 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] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

[Chris Lattner via swift-evolution]

On Feb 15, 2017, at 6:02 AM, Sadiq via swift-evolution 
 wrote:
> I would like to suggest to change Logical NOT Operator from ! to something 
> else. 
> It will increase the readability of the code and will avoid any confusion 
> with the symbol used for force unwrapping of optional values. 
> It would be easier for new programmers to learn Swift as the first language. 
> I don't understand the rational behind using the same operator for two 
> different purposes. 

Source breaking changes like this have to be motivated by an overwhelming 
reason to be worth changing in Swift 4.  Surface level syntax changes like this 
were the purview of Swift 3, and are very unlikely to make the cut in Swift 4.

-Chris

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Chris Lattner via swift-evolution]

On Feb 14, 2017, at 11:46 PM, Jean-Daniel via swift-evolution 
 wrote:
>>> Keeping with the spirit of Swift and staying consistent with its design, I 
>>> see two plausible meanings for private:
>>> 
>>> Private could mean either:
...
>>> (2) accessible only to the current type/scope and to extensions to that 
>>> type that are in the current file.
>> 
>> I think (2) is worth discussing. My 2 cents:
>> 
>> Pros
>> • Solves a high percentage of use cases of fileprivate
>> • Type-scope proponents retain some of the safety
>> 
>> Cons
>> • Less straight forward to explain
>> • Access to different type/scope in same file not possible anymore
> 
> Which means that if we choose 2, we must keep fileprivate.
> Being able to access other type private members in the same file is an 
> important feature that can’t be easily replaced, so it would badely break 
> existing code if we remove it.

Yeah, I think you’re right, which sinks the whole idea: we should aim to 
(re)simplify the access control model.  (2) is also problematic because it 
doesn’t allow the private members to be used by other things in the same file.  
E.g. use a private member of Foo in an extension on String.

IMO, removing fileprivate and making private match Swift 2 semantics seems like 
the more promising approach.

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

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Kevin Nattinger via swift-evolution]

> On Feb 15, 2017, at 3:45 PM, Tony Parker via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 15, 2017, at 2:25 PM, Charles Srstka > > wrote:
>> 
>>> On Feb 15, 2017, at 3:11 PM, Itai Ferber >> > wrote:
>>> 
>>> FYI, Tony is the manager of the Foundation team. :)
>>> We care very much about making sure that the experience of using our 
>>> framework is a positive one — the more Radars we get, the better we can 
>>> prioritize improving APIs that are not working as well as they could be for 
>>> our users. Even if the Radar gets duped to an existing one, thats one more 
>>> +1 for that Radar saying "this is a problem".
>>> 
>> Yeah I know, but it’s a frustrating experience, spending a half hour writing 
>> a detailed bug report (sometimes with videos attached to demonstrate the 
>> issue), just to effectively do the same thing as spending 5 seconds to hit 
>> the +1 button on most issue trackers you come across.
>> 
>> Especially since you never find out what happened to the original bug 
>> report. You can see if it’s open or closed, but did they fix it in some 
>> internal build? Did they decide it “behaves correctly?” Did somebody just 
>> skim your report, and mistakenly attach it to some other, unrelated issue? 
>> There’s no way to know.
>>> I will search for your old Radar, but in any case, please do file a new one 
>>> about this, and about any other issues you have, because we are indeed 
>>> listening.
>>> 
>> 
>> I was pretty sure I'd submitted something way, way back in the misty days of 
>> yore, but I can’t find it. I’ve filed a couple of new ones: rdar://30543037 
>>  and rdar://30543133 .
>> 
>> Charles
>> 
> 
> Thanks for filing these.
> 
> Sometimes, for process reasons, we do indeed mark bugs as dupes of other 
> ones. Usually the polite thing to do is to dupe to the earliest filed one. 
> Sometimes this comes across with an appearance of not caring to the filer of 
> the new bug,

At the risk of getting off-topic, I think it would defuse a lot of developer 
frustration around that to just show the status (open/fixed/wontfix/correct) of 
the root bug.  Filed radar 30551245 suggesting as much ;-)

> but our intent is simply to consolidate the reports we have so that we know 
> that the issue is serious.
> 
> We do not make API changes without going through a vigorous review process, 
> to avoid churn for the many clients above us. The flip side is that this can 
> take some time. I’m sure you understand that all software engineering is 
> about tradeoffs.
> 
> All of that said, we’ll take a look at these and see what improvements we can 
> make here. As I said, I’m not a fan of exception-based API.
> 
> - Tony
> 
> 
> ___
> 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] [Pitch] consistent public access modifiers (value subtyping digression)

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 15, 2017, at 8:17 PM, Jordan Rose  wrote:
> 
> 
>>> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution 
>>>  wrote:
>>> 
>>> Having loosely followed this discussion, the way I'm thinking of ‘closed’ 
>>> is as a modifier which would let you switch over something from outside the 
>>> module in which it is declared.
>>> 
>>> From outside the declaring module:
>>> • A closed enum's cases can be exhaustively switched.
>>> • A closed protocol's conforming types can be exhaustively switched.
>>> • A closed class's subclasses can be exhaustively switched.
>>> 
>>> If this is correct, I can't help but think ‘closed’ is describing something 
>>> subtly different in each case - picking and choosing the ‘important’ 
>>> relationship for each type, while protocols already have a subtyping 
>>> relationship, and it sounds like there's possibility for enum subtyping in 
>>> the future.
>>> 
>>> I'd rather keep ‘open’ (and a potential future ‘closed’) purely describing 
>>> the subtyping relationship, and have some other means of labelling 
>>> conformance and cases as switchable.
>> 
>> I am drafting a manifesto-style document regarding value subtyping which 
>> will make it clear how value subtypes fit into the picture.  This document 
>> covers the relationship of enum cases with value subtyping and will show 
>> clearly how enum cases are analogous to subclasses.
> 
> I'm not sure how it fits your document, but I suspect value subtyping is 
> pretty much not at all a source-compatibility or binary-compatibility 
> concern. I think the only reasonable implementation here would be to perform 
> conversions (unidirectional or bidirectional?),

I meant to reply to this in my last message.  Yes, the only sensible 
implementation I can think of is via conversion, which may be possible to 
optimize away in some cases where the supertype is representationally 
compatible with the subtype.  Bidirectional conversion / inout wouldn't make 
sense.  If you allow the supertype to mutate you may end up with a value that 
is not representable by the subtype.

> which means that the subtyping is almost entirely a client-side feature and 
> the only potential dynamic operation would be using 'as?' with a generic 
> type. This is very different from protocols and classes, which perform 
> dynamic dispatch to method implementations present on their subtypes.
> 
> That is, the only effect of making a type "non-open" with respect to value 
> subtyping would be to cut down on potential costs of 'as?'.
> 
> Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] consistent public access modifiers (value subtyping digression)

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 15, 2017, at 8:17 PM, Jordan Rose  wrote:
> 
> 
>>> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution 
>>>  wrote:
>>> 
>>> Having loosely followed this discussion, the way I'm thinking of ‘closed’ 
>>> is as a modifier which would let you switch over something from outside the 
>>> module in which it is declared.
>>> 
>>> From outside the declaring module:
>>> • A closed enum's cases can be exhaustively switched.
>>> • A closed protocol's conforming types can be exhaustively switched.
>>> • A closed class's subclasses can be exhaustively switched.
>>> 
>>> If this is correct, I can't help but think ‘closed’ is describing something 
>>> subtly different in each case - picking and choosing the ‘important’ 
>>> relationship for each type, while protocols already have a subtyping 
>>> relationship, and it sounds like there's possibility for enum subtyping in 
>>> the future.
>>> 
>>> I'd rather keep ‘open’ (and a potential future ‘closed’) purely describing 
>>> the subtyping relationship, and have some other means of labelling 
>>> conformance and cases as switchable.
>> 
>> I am drafting a manifesto-style document regarding value subtyping which 
>> will make it clear how value subtypes fit into the picture.  This document 
>> covers the relationship of enum cases with value subtyping and will show 
>> clearly how enum cases are analogous to subclasses.
> 
> I'm not sure how it fits your document, but I suspect value subtyping is 
> pretty much not at all a source-compatibility or binary-compatibility 
> concern. I think the only reasonable implementation here would be to perform 
> conversions (unidirectional or bidirectional?), which means that the 
> subtyping is almost entirely a client-side feature and the only potential 
> dynamic operation would be using 'as?' with a generic type. This is very 
> different from protocols and classes, which perform dynamic dispatch to 
> method implementations present on their subtypes.
> 
> That is, the only effect of making a type "non-open" with respect to value 
> subtyping would be to cut down on potential costs of 'as?'.

Thanks for the replies Jordan.  I haven't had a chance to closely look at your 
enum post yet - hopefully tomorrow.

I am not sure how relevant the ideas in my document are to language ABI but I 
suspect you are right that they are not very relevant there.  I am less certain 
about the standard library (and haven't done any work to try and asses that 
either).  

My thought is to share a manifesto-style document and ask the community to try 
to identify anything that might be relevant and keep the immediate conversation 
focused on that.  The rest will have to wait until the time is right.

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[David Smith via swift-evolution]

> On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution 
>  wrote:
> 
>> 
>> On 15 Feb 2017, at 17:02, Matthew Johnson  wrote:
>> 
>>> 
>>> On Feb 15, 2017, at 9:59 AM, Rien  wrote:
>>> 
 
 On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:
 
> 
> On Feb 15, 2017, at 9:35 AM, Rien  wrote:
> 
> 
>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 
 Our philosophy in general, however, is to default to the behavior 
 which preserves the most flexibility for the library designer.
>>> 
>>> Actually, I thought the philosophy was to preserver type safety. When 
>>> did that change?
>>> 
>>> Also, when was the library designer prioritised ahead of the 
>>> application developer?
>>> 
>>> 
 Both open and non-open classes are common, but we chose to give 
 non-open classes the `public` keyword because that's the 
 flexibility-preserving option.
>>> 
>>> No it isn’t, it’s the flexibility restricting option. The consumer of 
>>> an open class can subclass it. The consumer of a public class cannot 
>>> subclass it. How is the second more flexible than the first?
>> 
>> It reduces complexity for the library author by allowing them to opt-out 
>> of the complexity involved in supporting unknown, user-defined 
>> subclasses.  It is important to allow libraries to have this 
>> flexibility. They are free to declare a class `open` if they want to 
>> allow subclassing. It’s even possibly for a library to declare all 
>> classes `open` if it wishes to do so.  But *requiring* that would reduce 
>> the design space libraries are allowed to explore and / or introduce 
>> fragility by moving the subclass restriction to a comment.
>> 
> 
> Why would a library author want to prohibit subclasses?
> A library user can always wrap the class and subclass the wrapper.
 
 This is composition, not inheritance.  The most important difference is 
 that a wrapper cannot override methods, it can only wrap and / or forward 
 them.  This means that when the superclass calls a method on `self` that 
 method *always* invokes its version of that method rather than a subclass 
 override.  This is a very important difference.
 
>>> 
>>> Agreed, however that does not answer the question why would a library 
>>> developer want to disallow subclassing?
>>> I do not see a use case for that. I.e. a feature that cannot be implemented 
>>> without it. (without “open”)
>> 
>> The feature it enables is more robust libraries and the ability for library 
>> authors to better reason about their code.  You may not find this benefit 
>> enough to be worth a language feature, but many of us do.
> 
> You start of with a claim “more robust libraries”.
> I would really like to know the “how” of that. How does it make a library 
> more robust?
> 
> I do write libraries myself, and if there is something I am missing, I very 
> much would like to know.
> 
> Regards,
> Rien.

The usual thing I've run into in practice follows this general pattern:

• A non-threadsafe class is introduced
• Years or decades pass
• Someone (me) tries to make the class threadsafe by adding locking
• In the intervening years, subclasses have been introduced that override 
methods now called while holding a lock, and reentrantly call back into other 
methods that take the lock

I've worked around this using recursive mutexes in some cases, but in more 
extreme cases the subclass synchronously called out to another thread, and that 
thread reentered the lock.

A defensive rule I've adopted in some new code is "public methods are not 
allowed to call other public methods", which avoids reentrancy issues, but also 
makes subclassing somewhat useless since the work is being done by private 
non-overridable methods.

David


> 
>> 
>>> 
>>> Rien.
>>> 
> 
> There are cases where subclassing does not make sense. And thus 
> preventing subclasses adds information for those users that don’t RTFM. 
> But that imo is not worth the impact extra complexity places on all other 
> users.
> 
> Rien.
> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> 

Re: [swift-evolution] [Pitch] consistent public access modifiers - protocols

[Jordan Rose via swift-evolution]

> On Feb 10, 2017, at 12:23, Matthew Johnson  wrote:
> 
> 
>> On Feb 10, 2017, at 12:52 PM, Jordan Rose > > wrote:
>> 
>> Hi, Matthew. Thank you for bringing up these issues. I'm going to break my 
>> feedback up into separate messages, because I think really the enum and 
>> protocol cases are unrelated. Open classes refer to classes that can be 
>> subclassed from clients of the current module, and similarly open protocols 
>> would be protocols that can be adopted from clients of the current module. 
>> Public-but-not-open classes cannot be subclassed from outside the current 
>> module, but they can still be subclassed within the module. By contrast, 
>> "open" enums can grow new cases in new versions of the library, but clients 
>> still can't add cases. (That's not a totally unreasonable feature to ever 
>> consider, but it's not the one we need now.)
> 
> Hi Jordan.  Thanks for replying to my post!
> 
> I understand the current behavior of `open` and how it would work for 
> protocols.  I also understand the vocabulary that has been used in talking 
> about “open” enums thus far.  What I am trying to point out is that there are 
> inconsistencies in the vocabulary we’ve been using thus far.  
> 
> The ideas of “open” and “closed” both talk about who is able to add to the 
> set of cases / subclasses / conforming types.  `public` (without annotation) 
> also does this.  But we haven’t been using the terms consistently - we use a 
> different meaning depending on which kind of entity we’re talking about.
> 
> For example, as you pointed out, `open` currently means both a module *and* 
> its clients can add new subclasses.  It doesn’t seem right to use this same 
> terminology to mean the module can add cases to an enum but clients *can’t* 
> add new cases to the enum.  I understand that “open” enums in the sense of 
> the current meaning of the `open` keyword are not a feature we need right 
> away.  I noted that this is specifically not proposed in my pitch.  But if we 
> ever *do* add this feature, `open enum` seems like the right way to spell it 
> (probably just using the existing case syntax in an extension to add cases in 
> the client).
> 
> It’s also worth pointing out that `public` currently has three distinct 
> meanings:
> * `public` enums *cannot* have a new case added in a future version of the 
> library is without a breaking change
> * `public` classes *can* have a new subclass added in a future version of the 
> library without a breaking change, but clients cannot add subclasses
> * `public` protocols have the same semantics as `open` classes, allowing 
> clients to add conforming types

* public structs *can* have new fields added
* public functions *can* add new parameters, as long as they have defaults, if 
you are careful about it
* public types *can* have new subtypes added
* public types *can* have new conformances added, although today that will 
break people and we need to do something about that (on another thread)

I think this is just a false equivalence. Adding cases to an enum within a 
module is fundamentally different from adding subclasses to a class outside the 
module. We should not be trying to jam enums into the same keyword that classes 
use just because I happened to use that term when writing the Library Evolution 
doc, even if it is a reasonable term for the thing.

(Matthew was very quick about replying to my first message and I was very slow 
with the second, and I think I already made this point better there. But for 
cross-referencing purposes it made sense to mention it here too.)


>> P.S. For classes, note that 'final' is essentially a performance 
>> optimization at this point. I'm not even sure we should bother displaying it 
>> in generated interfaces (although the compiler should still be able to take 
>> advantage of it in clients).
> 
> `final` can be pretty useful when reasoning about code.  It’s more than just 
> a performance optimization.  It also represents a compiler proof about our 
> code.

Ah, sorry, yes: 'final' is totally useful within a module to have the property 
enforced. It's just not super interesting outside the module. (It doesn't even 
mean there are no subclasses in all cases; features like KVO use a dynamic 
subclass in their implementation.)

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

Re: [swift-evolution] [Pitch] consistent public access modifiers (value subtyping digression)

[Jordan Rose via swift-evolution]

> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 13, 2017, at 11:28 AM, James Froggatt via swift-evolution 
>>  wrote:
>> 
>> Having loosely followed this discussion, the way I'm thinking of ‘closed’ is 
>> as a modifier which would let you switch over something from outside the 
>> module in which it is declared.
>> 
>> From outside the declaring module:
>> • A closed enum's cases can be exhaustively switched.
>> • A closed protocol's conforming types can be exhaustively switched.
>> • A closed class's subclasses can be exhaustively switched.
>> 
>> If this is correct, I can't help but think ‘closed’ is describing something 
>> subtly different in each case - picking and choosing the ‘important’ 
>> relationship for each type, while protocols already have a subtyping 
>> relationship, and it sounds like there's possibility for enum subtyping in 
>> the future.
>> 
>> I'd rather keep ‘open’ (and a potential future ‘closed’) purely describing 
>> the subtyping relationship, and have some other means of labelling 
>> conformance and cases as switchable.
> 
> I am drafting a manifesto-style document regarding value subtyping which will 
> make it clear how value subtypes fit into the picture.  This document covers 
> the relationship of enum cases with value subtyping and will show clearly how 
> enum cases are analogous to subclasses.

I'm not sure how it fits your document, but I suspect value subtyping is pretty 
much not at all a source-compatibility or binary-compatibility concern. I think 
the only reasonable implementation here would be to perform conversions 
(unidirectional or bidirectional?), which means that the subtyping is almost 
entirely a client-side feature and the only potential dynamic operation would 
be using 'as?' with a generic type. This is very different from protocols and 
classes, which perform dynamic dispatch to method implementations present on 
their subtypes.

That is, the only effect of making a type "non-open" with respect to value 
subtyping would be to cut down on potential costs of 'as?'.

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Jordan Rose via swift-evolution]

> On Feb 13, 2017, at 09:28, James Froggatt via swift-evolution 
>  wrote:
> 
> Having loosely followed this discussion, the way I'm thinking of ‘closed’ is 
> as a modifier which would let you switch over something from outside the 
> module in which it is declared.
> 
> From outside the declaring module:
> • A closed enum's cases can be exhaustively switched.
> • A closed protocol's conforming types can be exhaustively switched.
> • A closed class's subclasses can be exhaustively switched.
> 
> If this is correct, I can't help but think ‘closed’ is describing something 
> subtly different in each case - picking and choosing the ‘important’ 
> relationship for each type, while protocols already have a subtyping 
> relationship, and it sounds like there's possibility for enum subtyping in 
> the future.
> 
> I'd rather keep ‘open’ (and a potential future ‘closed’) purely describing 
> the subtyping relationship, and have some other means of labelling 
> conformance and cases as switchable.

This is definitely not correct. A "closed" enum's cases can be exhaustively 
switched from any module, but a non-open protocol's conforming types or 
non-open class's subclasses cannot be exhaustively switched from anywhere 
except the defining module (because there may be internal subclasses).

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Jordan Rose via swift-evolution]

> On Feb 14, 2017, at 18:16, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> So, perhaps I'm being simplistic here, but--
> 
> At the end of the day, aren't we simply trying to enable a resiliency 
> feature? Could it not be said that an enum where future added cases aren't 
> source-breaking is a more resilient enum?
> 
> Since there is consensus that the status quo is desirable for a lot of use 
> cases, couldn't we keep spelling it "public enum" and just spell this 
> proposed more resilient enum "@resilient public enum"?

Not quite. Resilience is about making changes that aren't source-breaking also 
not ABI-breaking (within reason, balanced against performance implications). 
"Open" vs. "non-open" enums also affect modules distributed as source—is it a 
source-breaking change to add a new case or not?

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Jordan Rose via swift-evolution]

> On Feb 12, 2017, at 21:52, Slava Pestov via swift-evolution 
>  wrote:
> 
> Also, note that there will be at least one other similar annotation, but for 
> structs — the evolution document calls it @fixedContents. We want a way to 
> declare that the set of stored properties in a struct will never change, 
> allowing clients to make assumptions about its layout. Unlike @closed enums, 
> @fixedContents structs mostly behave the same. The one important difference 
> is that it will be possible to define designated initializers of 
> @fixedContents structs inside extensions from another module.

The "@fixedContents mostly doesn't change the behavior of a struct" makes me 
think it is unimportant for these two annotations to have the same name.

Jordan

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Jordan Rose via swift-evolution]

> The Library Evolution document isn’t gospel; it’s more like a collection of 
> musings and aspirations, so I don’t think we should be bound by the syntax it 
> uses.

Agreed on this very local point. :-) There are some deliberately ugly names in 
there so that we don't end up using that syntax.

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

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Tony Parker via swift-evolution]

> On Feb 15, 2017, at 2:25 PM, Charles Srstka  wrote:
> 
>> On Feb 15, 2017, at 3:11 PM, Itai Ferber > > wrote:
>> 
>> FYI, Tony is the manager of the Foundation team. :)
>> We care very much about making sure that the experience of using our 
>> framework is a positive one — the more Radars we get, the better we can 
>> prioritize improving APIs that are not working as well as they could be for 
>> our users. Even if the Radar gets duped to an existing one, thats one more 
>> +1 for that Radar saying "this is a problem".
>> 
> Yeah I know, but it’s a frustrating experience, spending a half hour writing 
> a detailed bug report (sometimes with videos attached to demonstrate the 
> issue), just to effectively do the same thing as spending 5 seconds to hit 
> the +1 button on most issue trackers you come across.
> 
> Especially since you never find out what happened to the original bug report. 
> You can see if it’s open or closed, but did they fix it in some internal 
> build? Did they decide it “behaves correctly?” Did somebody just skim your 
> report, and mistakenly attach it to some other, unrelated issue? There’s no 
> way to know.
>> I will search for your old Radar, but in any case, please do file a new one 
>> about this, and about any other issues you have, because we are indeed 
>> listening.
>> 
> 
> I was pretty sure I'd submitted something way, way back in the misty days of 
> yore, but I can’t find it. I’ve filed a couple of new ones: rdar://30543037 
>  and rdar://30543133 .
> 
> Charles
> 

Thanks for filing these.

Sometimes, for process reasons, we do indeed mark bugs as dupes of other ones. 
Usually the polite thing to do is to dupe to the earliest filed one. Sometimes 
this comes across with an appearance of not caring to the filer of the new bug, 
but our intent is simply to consolidate the reports we have so that we know 
that the issue is serious.

We do not make API changes without going through a vigorous review process, to 
avoid churn for the many clients above us. The flip side is that this can take 
some time. I’m sure you understand that all software engineering is about 
tradeoffs.

All of that said, we’ll take a look at these and see what improvements we can 
make here. As I said, I’m not a fan of exception-based API.

- Tony


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

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

[Haravikk via swift-evolution]

> On 15 Feb 2017, at 22:44, Nicolas Fezans via swift-evolution 
>  wrote:
> 
> > 3: maybe ~ is a better fit?
> 
> just for information this is in line with Matlab in which the following three 
> "not"-related syntax exist:
> a) ~ as a prefix operator for not
> b) not as a function
> c) ~= as an infix operator for "is not equal to"
> 
> I see pros and cons for each option and have a very slight preference for ~ 
> over !.
> 
> I would however avoid ¬ because I would not like to have a character that is 
> not directly accessible on most keyboards for something as simple as a not 
> operation, even if I like these maths notations very much.
> 
> If it would be decided to keep ! I could imagine that  adding syntax 
> coloration in code editors to make both uses of ! look a bit different would 
> help beginners and newcomers. This is more complicated to do than the typical 
> syntax coloration logic in text editors (syntax must be understood for doing 
> that), but this should not be a problem in Xcode.
> 
> If ~ would be preferred, I would recommend to continue accepting ! for one or 
> more versions of swift but with a warning recommending to change it (we do 
> not need to make a source breaking change when it is possible to continue 
> accepting it and to mark it as obsolete)

Tilde is already used in Swift for bit-flipping, though actually on a boolean 
type (if you treat it as 1-bit) bit-flipping and logical NOT are equivalent, 
and you can't use logical NOT an Ints at the moment anyway.
So tilde could be a good option, however the ~= operator also already exists in 
Swift for pattern matching, so couldn't be used as a replacement for !=, unless 
there's a better operator for pattern matching (personally I don't like using 
an operator for pattern matching at all but maybe that's just me).

>> On 15 Feb 2017, at 22:28, Derrick Ho via swift-evolution 
>> > wrote:
>> 
>> There is no need to change it
>> 
>> Since the context basically disambiguates the meaning of !
>> 
>> The next best thing is to compare it to false
>> 
>> (val == false) // same as !val
>> On Wed, Feb 15, 2017 at 3:02 PM David Waite via swift-evolution 
>> > wrote:
>> If someone came with a nice syntax I’d be for this. I can’t imagine what 
>> that would be.
>> 
>> I doubt there is an alternate prefix or postfix operator that would pass 
>> muster, due to ‘!’ already meaning the appropriate thing in so many 
>> languages, and swift only supporting symbolic operators.
>> 
>> I can’t think of a method on boolean which would read properly either, e.g.
>> 
>>  if isValid.not() {…}
>> 
>> The closest I could think to a decent bike shed color would be a global 
>> function:
>> 
>>  if not(isValid) {…}
>> 
>> -DW
>> 
>>> On Feb 15, 2017, at 11:10 AM, Robert Widmann via swift-evolution 
>>> > wrote:
>>> 
>>> So you've identified the problem, but what do you propose as a solution 
>>> here?  
>>> 
>>> It should be noted that a (non-stdlib) language-level answer to this 
>>> question has already been discussed and rejected 
>>> (https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html
>>>  
>>> ).
>>> 
>>> ~Robert Widmann
>>> 
>>> 2017/02/15 9:02、Sadiq via swift-evolution >> > のメッセージ:
>>> 
 Hello,
 
 I would like to suggest to change Logical NOT Operator from ! to something 
 else. 
 It will increase the readability of the code and will avoid any confusion 
 with the symbol used for force unwrapping of optional values. 
 It would be easier for new programmers to learn Swift as the first 
 language. 
 I don't understand the rational behind using the same operator for two 
 different purposes. 
 
 Thanks and Regards,
 Mohammad Sadiq
 ___
 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

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

[Nicolas Fezans via swift-evolution]

> 3: maybe ~ is a better fit?

just for information this is in line with Matlab in which the following
three "not"-related syntax exist:
a) ~ as a prefix operator for not
b) not as a function
c) ~= as an infix operator for "is not equal to"

I see pros and cons for each option and have a very slight preference for ~
over !.

I would however avoid ¬ because I would not like to have a character that
is not directly accessible on most keyboards for something as simple as a
not operation, even if I like these maths notations very much.

If it would be decided to keep ! I could imagine that  adding syntax
coloration in code editors to make both uses of ! look a bit different
would help beginners and newcomers. This is more complicated to do than the
typical syntax coloration logic in text editors (syntax must be understood
for doing that), but this should not be a problem in Xcode.

If ~ would be preferred, I would recommend to continue accepting ! for one
or more versions of swift but with a warning recommending to change it (we
do not need to make a source breaking change when it is possible to
continue accepting it and to mark it as obsolete)


Nicolas


On Wed, 15 Feb 2017 at 22:55, André “Zephyz” Videla via swift-evolution <
swift-evolution@swift.org> wrote:

> As of today, this is possible:
>
> prefix operator ¬
> prefix func ¬ (value: Bool) -> Bool {
> return !value
> }
>
> let t = true
> let f = ¬t
>
> I have to admit that I quite like this but it has a couple drawbacks:
> 1: if you've never seen the ¬ operator in math it makes no more sense than
> "!"
> 2: It's quite tricky to find on your keyboard depending on your layout
> 3: maybe ~ is a better fit?
>
> Seems like a lot of work for a very small improvement. But I'm all for it.
>
> André
>
>
> On 15 Feb 2017, at 22:28, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> There is no need to change it
>
> Since the context basically disambiguates the meaning of !
>
> The next best thing is to compare it to false
>
> (val == false) // same as !val
> On Wed, Feb 15, 2017 at 3:02 PM David Waite via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If someone came with a nice syntax I’d be for this. I can’t imagine what
> that would be.
>
> I doubt there is an alternate prefix or postfix operator that would pass
> muster, due to ‘!’ already meaning the appropriate thing in so many
> languages, and swift only supporting symbolic operators.
>
> I can’t think of a method on boolean which would read properly either, e.g.
>
> if isValid.not() {…}
>
> The closest I could think to a decent bike shed color would be a global
> function:
>
> if not(isValid) {…}
>
> -DW
>
> On Feb 15, 2017, at 11:10 AM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> So you've identified the problem, but what do you propose as a solution
> here?
>
> It should be noted that a (non-stdlib) language-level answer to this
> question has already been discussed and rejected (
> https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html
> ).
>
> ~Robert Widmann
>
> 2017/02/15 9:02、Sadiq via swift-evolution 
> のメッセージ:
>
> Hello,
>
> I would like to suggest to change Logical NOT Operator from ! to something
> else.
> It will increase the readability of the code and will avoid any confusion
> with the symbol used for force unwrapping of optional values.
> It would be easier for new programmers to learn Swift as the first
> language.
> I don't understand the rational behind using the same operator for two
> different purposes.
>
> Thanks and Regards,
> Mohammad Sadiq
>
> ___
> 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
>
>
> ___
> 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] Pitch: Replacement for FileHandle

[Charles Srstka via swift-evolution]

> On Feb 15, 2017, at 3:11 PM, Itai Ferber  wrote:
> 
> FYI, Tony is the manager of the Foundation team. :)
> We care very much about making sure that the experience of using our 
> framework is a positive one — the more Radars we get, the better we can 
> prioritize improving APIs that are not working as well as they could be for 
> our users. Even if the Radar gets duped to an existing one, thats one more +1 
> for that Radar saying "this is a problem".
> 
Yeah I know, but it’s a frustrating experience, spending a half hour writing a 
detailed bug report (sometimes with videos attached to demonstrate the issue), 
just to effectively do the same thing as spending 5 seconds to hit the +1 
button on most issue trackers you come across.

Especially since you never find out what happened to the original bug report. 
You can see if it’s open or closed, but did they fix it in some internal build? 
Did they decide it “behaves correctly?” Did somebody just skim your report, and 
mistakenly attach it to some other, unrelated issue? There’s no way to know.
> I will search for your old Radar, but in any case, please do file a new one 
> about this, and about any other issues you have, because we are indeed 
> listening.
> 

I was pretty sure I'd submitted something way, way back in the misty days of 
yore, but I can’t find it. I’ve filed a couple of new ones: rdar://30543037 
 and rdar://30543133 .

Charles

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

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Matthew Johnson via swift-evolution]

> On Feb 15, 2017, at 4:16 PM, David Hart  wrote:
> 
> 
>> On 15 Feb 2017, at 23:15, Matthew Johnson > > wrote:
>> 
>>> 
>>> On Feb 15, 2017, at 4:12 PM, David Hart >> > wrote:
>>> 
 
 On 15 Feb 2017, at 16:31, Matthew Johnson > wrote:
 
 
> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution 
> > wrote:
> 
> 
>> On Feb 14, 2017, at 3:20 AM, David Hart > > wrote:
>> 
>> 
>> On 14 Feb 2017, at 09:25, Goffredo Marocchi > > wrote:
>> 
>>> I disagree with that as well as I still think we are damaging the 
>>> language each time we take a known concept (like access levels) and 
>>> give new meanings to the same keywords. I still look baffled at the 
>>> redefinition of do and the addition of repeat for example...
>>> 
>>> Private, the way it was before, was an admittedly curious take on how 
>>> most languages mean by private and we have jumped through a lot of 
>>> hoops to justify why we did not start with Java/C++/C# like access 
>>> control and augmented it instead of redefining things, omitting others, 
>>> and then constantly pulling the language left and right with not a lot 
>>> of permanent consensus either way as this discussion and others before 
>>> show.
>> 
>> It's a curious take, but it is a curious take is perfectly coherent with 
>> Swift extensions. How else would you access private implementation 
>> details from an extension? But putting it in the same file, instead of 
>> having to resort to an internal access level.
> 
> Right.  Swift is its own language distinct from Java/C++/etc.  While it 
> is intentionally designed to remain familiar (and thus reuses many 
> keywords across the language family), it often does so with slightly 
> different meaning / behavior.  Consider ‘throw’ for example.
> 
> Keeping with the spirit of Swift and staying consistent with its design, 
> I see two plausible meanings for private:
> 
> Private could mean either:
> 1) private to the file (Swift 2 semantics)
> 2) accessible only to the current type/scope and to extensions to that 
> type that are in the current file.
> 
> I don’t think we’ve ever evaluated and debated approach #2 systematically.
 
 I think #2 is an interesting meaning for `private`.  It would have a 
 little bit more similarity to type-scoped `private` in other languages.  
 It would also be applicable in the vast majority of cases where 
 `fileprivate` is currently required.
 
 That said, we very much need a file-scoped access modifier.  This is by 
 far the most important as it allows us to encapsulate access to state that 
 needs to be accessed by more than one type.  I think most people could 
 probably live with `fileprivate` for these use cases if they were allowed 
 to use `private` for the majority of use cases where access is both within 
 a file *and* within the same type.
 
 However, as Brent points out, the SE-0025 meaning of `private` has 
 important use cases.  I would be sad to see these go.  
 
 The big lesson I have taken away from our experience with SE-0025 is that 
 `private` should have remained relevant as the “soft default” file-scoped 
 access modifier but it does not play well with extensions.  It is very 
 common to implement a type using several extensions in the same file and 
 despite having important use cases, SE-0025 `private` does not allow for 
 this.  This means we should not have taken the `private` keyword and 
 instead should have persisted in finding it a name that we can all live 
 with.
 
 If we could come up with a good name for this (not at all a sure thing) I 
 think the best way forward would be:
 
 * retain `fileprivate` - its slight awkwardness will be more acceptable if 
 it indicates a more rare / unusual use case
 * make `private` have the semantics of #2 - it will without question be 
 the right choice in the majority of use cases
 * give scoped access control a new keyword - we still have the ability for 
 tighter encapsulation when necessary and a less common keyword will better 
 highlight that intent 
>>> 
>>> I’d be very strongly against adding yet another private accessor. I brought 
>>> this all up to simplify the access-story, and this goes completely against 
>>> that goal.
>> 
>> Yes, I understand that a lot of people feel strongly that way.  I don’t 
>> expect this to be adopted, I just wanted to offer my 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[David Hart via swift-evolution]

> On 15 Feb 2017, at 23:15, Matthew Johnson  wrote:
> 
>> 
>> On Feb 15, 2017, at 4:12 PM, David Hart > > wrote:
>> 
>>> 
>>> On 15 Feb 2017, at 16:31, Matthew Johnson >> > wrote:
>>> 
>>> 
 On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution 
 > wrote:
 
 
> On Feb 14, 2017, at 3:20 AM, David Hart  > wrote:
> 
> 
> On 14 Feb 2017, at 09:25, Goffredo Marocchi  > wrote:
> 
>> I disagree with that as well as I still think we are damaging the 
>> language each time we take a known concept (like access levels) and give 
>> new meanings to the same keywords. I still look baffled at the 
>> redefinition of do and the addition of repeat for example...
>> 
>> Private, the way it was before, was an admittedly curious take on how 
>> most languages mean by private and we have jumped through a lot of hoops 
>> to justify why we did not start with Java/C++/C# like access control and 
>> augmented it instead of redefining things, omitting others, and then 
>> constantly pulling the language left and right with not a lot of 
>> permanent consensus either way as this discussion and others before show.
> 
> It's a curious take, but it is a curious take is perfectly coherent with 
> Swift extensions. How else would you access private implementation 
> details from an extension? But putting it in the same file, instead of 
> having to resort to an internal access level.
 
 Right.  Swift is its own language distinct from Java/C++/etc.  While it is 
 intentionally designed to remain familiar (and thus reuses many keywords 
 across the language family), it often does so with slightly different 
 meaning / behavior.  Consider ‘throw’ for example.
 
 Keeping with the spirit of Swift and staying consistent with its design, I 
 see two plausible meanings for private:
 
 Private could mean either:
 1) private to the file (Swift 2 semantics)
 2) accessible only to the current type/scope and to extensions to that 
 type that are in the current file.
 
 I don’t think we’ve ever evaluated and debated approach #2 systematically.
>>> 
>>> I think #2 is an interesting meaning for `private`.  It would have a little 
>>> bit more similarity to type-scoped `private` in other languages.  It would 
>>> also be applicable in the vast majority of cases where `fileprivate` is 
>>> currently required.
>>> 
>>> That said, we very much need a file-scoped access modifier.  This is by far 
>>> the most important as it allows us to encapsulate access to state that 
>>> needs to be accessed by more than one type.  I think most people could 
>>> probably live with `fileprivate` for these use cases if they were allowed 
>>> to use `private` for the majority of use cases where access is both within 
>>> a file *and* within the same type.
>>> 
>>> However, as Brent points out, the SE-0025 meaning of `private` has 
>>> important use cases.  I would be sad to see these go.  
>>> 
>>> The big lesson I have taken away from our experience with SE-0025 is that 
>>> `private` should have remained relevant as the “soft default” file-scoped 
>>> access modifier but it does not play well with extensions.  It is very 
>>> common to implement a type using several extensions in the same file and 
>>> despite having important use cases, SE-0025 `private` does not allow for 
>>> this.  This means we should not have taken the `private` keyword and 
>>> instead should have persisted in finding it a name that we can all live 
>>> with.
>>> 
>>> If we could come up with a good name for this (not at all a sure thing) I 
>>> think the best way forward would be:
>>> 
>>> * retain `fileprivate` - its slight awkwardness will be more acceptable if 
>>> it indicates a more rare / unusual use case
>>> * make `private` have the semantics of #2 - it will without question be the 
>>> right choice in the majority of use cases
>>> * give scoped access control a new keyword - we still have the ability for 
>>> tighter encapsulation when necessary and a less common keyword will better 
>>> highlight that intent 
>> 
>> I’d be very strongly against adding yet another private accessor. I brought 
>> this all up to simplify the access-story, and this goes completely against 
>> that goal.
> 
> Yes, I understand that a lot of people feel strongly that way.  I don’t 
> expect this to be adopted, I just wanted to offer my opinion.

Sorry if I came across as violent in my response, I was just being passionate 
:) Your opinion is of great value to me!

>> 
>>> I understand that there probably aren’t too many people in the community 
>>> 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Matthew Johnson via swift-evolution]

> On Feb 15, 2017, at 4:12 PM, David Hart  wrote:
> 
>> 
>> On 15 Feb 2017, at 16:31, Matthew Johnson > > wrote:
>> 
>> 
>>> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Feb 14, 2017, at 3:20 AM, David Hart > wrote:
 
 
 On 14 Feb 2017, at 09:25, Goffredo Marocchi > wrote:
 
> I disagree with that as well as I still think we are damaging the 
> language each time we take a known concept (like access levels) and give 
> new meanings to the same keywords. I still look baffled at the 
> redefinition of do and the addition of repeat for example...
> 
> Private, the way it was before, was an admittedly curious take on how 
> most languages mean by private and we have jumped through a lot of hoops 
> to justify why we did not start with Java/C++/C# like access control and 
> augmented it instead of redefining things, omitting others, and then 
> constantly pulling the language left and right with not a lot of 
> permanent consensus either way as this discussion and others before show.
 
 It's a curious take, but it is a curious take is perfectly coherent with 
 Swift extensions. How else would you access private implementation details 
 from an extension? But putting it in the same file, instead of having to 
 resort to an internal access level.
>>> 
>>> Right.  Swift is its own language distinct from Java/C++/etc.  While it is 
>>> intentionally designed to remain familiar (and thus reuses many keywords 
>>> across the language family), it often does so with slightly different 
>>> meaning / behavior.  Consider ‘throw’ for example.
>>> 
>>> Keeping with the spirit of Swift and staying consistent with its design, I 
>>> see two plausible meanings for private:
>>> 
>>> Private could mean either:
>>> 1) private to the file (Swift 2 semantics)
>>> 2) accessible only to the current type/scope and to extensions to that type 
>>> that are in the current file.
>>> 
>>> I don’t think we’ve ever evaluated and debated approach #2 systematically.
>> 
>> I think #2 is an interesting meaning for `private`.  It would have a little 
>> bit more similarity to type-scoped `private` in other languages.  It would 
>> also be applicable in the vast majority of cases where `fileprivate` is 
>> currently required.
>> 
>> That said, we very much need a file-scoped access modifier.  This is by far 
>> the most important as it allows us to encapsulate access to state that needs 
>> to be accessed by more than one type.  I think most people could probably 
>> live with `fileprivate` for these use cases if they were allowed to use 
>> `private` for the majority of use cases where access is both within a file 
>> *and* within the same type.
>> 
>> However, as Brent points out, the SE-0025 meaning of `private` has important 
>> use cases.  I would be sad to see these go.  
>> 
>> The big lesson I have taken away from our experience with SE-0025 is that 
>> `private` should have remained relevant as the “soft default” file-scoped 
>> access modifier but it does not play well with extensions.  It is very 
>> common to implement a type using several extensions in the same file and 
>> despite having important use cases, SE-0025 `private` does not allow for 
>> this.  This means we should not have taken the `private` keyword and instead 
>> should have persisted in finding it a name that we can all live with.
>> 
>> If we could come up with a good name for this (not at all a sure thing) I 
>> think the best way forward would be:
>> 
>> * retain `fileprivate` - its slight awkwardness will be more acceptable if 
>> it indicates a more rare / unusual use case
>> * make `private` have the semantics of #2 - it will without question be the 
>> right choice in the majority of use cases
>> * give scoped access control a new keyword - we still have the ability for 
>> tighter encapsulation when necessary and a less common keyword will better 
>> highlight that intent 
> 
> I’d be very strongly against adding yet another private accessor. I brought 
> this all up to simplify the access-story, and this goes completely against 
> that goal.

Yes, I understand that a lot of people feel strongly that way.  I don’t expect 
this to be adopted, I just wanted to offer my opinion.

> 
>> I understand that there probably aren’t too many people in the community 
>> willing to see this level of churn in access modifiers, and probably many 
>> who would view this introduction of "yet another” private access modifier to 
>> be excessive and complex so I don’t plan to push this.  But that is my two 
>> cents about what I think would be ideal.  `private` would be used most of 
>> the time and we would 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[David Hart via swift-evolution]

> On 15 Feb 2017, at 16:31, Matthew Johnson  wrote:
> 
> 
>> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Feb 14, 2017, at 3:20 AM, David Hart >> > wrote:
>>> 
>>> 
>>> On 14 Feb 2017, at 09:25, Goffredo Marocchi >> > wrote:
>>> 
 I disagree with that as well as I still think we are damaging the language 
 each time we take a known concept (like access levels) and give new 
 meanings to the same keywords. I still look baffled at the redefinition of 
 do and the addition of repeat for example...
 
 Private, the way it was before, was an admittedly curious take on how most 
 languages mean by private and we have jumped through a lot of hoops to 
 justify why we did not start with Java/C++/C# like access control and 
 augmented it instead of redefining things, omitting others, and then 
 constantly pulling the language left and right with not a lot of permanent 
 consensus either way as this discussion and others before show.
>>> 
>>> It's a curious take, but it is a curious take is perfectly coherent with 
>>> Swift extensions. How else would you access private implementation details 
>>> from an extension? But putting it in the same file, instead of having to 
>>> resort to an internal access level.
>> 
>> Right.  Swift is its own language distinct from Java/C++/etc.  While it is 
>> intentionally designed to remain familiar (and thus reuses many keywords 
>> across the language family), it often does so with slightly different 
>> meaning / behavior.  Consider ‘throw’ for example.
>> 
>> Keeping with the spirit of Swift and staying consistent with its design, I 
>> see two plausible meanings for private:
>> 
>> Private could mean either:
>> 1) private to the file (Swift 2 semantics)
>> 2) accessible only to the current type/scope and to extensions to that type 
>> that are in the current file.
>> 
>> I don’t think we’ve ever evaluated and debated approach #2 systematically.
> 
> I think #2 is an interesting meaning for `private`.  It would have a little 
> bit more similarity to type-scoped `private` in other languages.  It would 
> also be applicable in the vast majority of cases where `fileprivate` is 
> currently required.
> 
> That said, we very much need a file-scoped access modifier.  This is by far 
> the most important as it allows us to encapsulate access to state that needs 
> to be accessed by more than one type.  I think most people could probably 
> live with `fileprivate` for these use cases if they were allowed to use 
> `private` for the majority of use cases where access is both within a file 
> *and* within the same type.
> 
> However, as Brent points out, the SE-0025 meaning of `private` has important 
> use cases.  I would be sad to see these go.  
> 
> The big lesson I have taken away from our experience with SE-0025 is that 
> `private` should have remained relevant as the “soft default” file-scoped 
> access modifier but it does not play well with extensions.  It is very common 
> to implement a type using several extensions in the same file and despite 
> having important use cases, SE-0025 `private` does not allow for this.  This 
> means we should not have taken the `private` keyword and instead should have 
> persisted in finding it a name that we can all live with.
> 
> If we could come up with a good name for this (not at all a sure thing) I 
> think the best way forward would be:
> 
> * retain `fileprivate` - its slight awkwardness will be more acceptable if it 
> indicates a more rare / unusual use case
> * make `private` have the semantics of #2 - it will without question be the 
> right choice in the majority of use cases
> * give scoped access control a new keyword - we still have the ability for 
> tighter encapsulation when necessary and a less common keyword will better 
> highlight that intent 

I’d be very strongly against adding yet another private accessor. I brought 
this all up to simplify the access-story, and this goes completely against that 
goal.

> I understand that there probably aren’t too many people in the community 
> willing to see this level of churn in access modifiers, and probably many who 
> would view this introduction of "yet another” private access modifier to be 
> excessive and complex so I don’t plan to push this.  But that is my two cents 
> about what I think would be ideal.  `private` would be used most of the time 
> and we would still have the ability to widen or narrow visibility where 
> necessary, with a more esoteric keyword that draws a reader’s attention.
> 
> 
>> 
>> -Chris
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> 

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

[André “Zephyz” Videla via swift-evolution]

As of today, this is possible:

prefix operator ¬
prefix func ¬ (value: Bool) -> Bool {
return !value
}

let t = true
let f = ¬t

I have to admit that I quite like this but it has a couple drawbacks:
1: if you've never seen the ¬ operator in math it makes no more sense than "!"
2: It's quite tricky to find on your keyboard depending on your layout
3: maybe ~ is a better fit?

Seems like a lot of work for a very small improvement. But I'm all for it.

André


> On 15 Feb 2017, at 22:28, Derrick Ho via swift-evolution 
>  wrote:
> 
> There is no need to change it
> 
> Since the context basically disambiguates the meaning of !
> 
> The next best thing is to compare it to false
> 
> (val == false) // same as !val
> On Wed, Feb 15, 2017 at 3:02 PM David Waite via swift-evolution 
> > wrote:
> If someone came with a nice syntax I’d be for this. I can’t imagine what that 
> would be.
> 
> I doubt there is an alternate prefix or postfix operator that would pass 
> muster, due to ‘!’ already meaning the appropriate thing in so many 
> languages, and swift only supporting symbolic operators.
> 
> I can’t think of a method on boolean which would read properly either, e.g.
> 
>   if isValid.not() {…}
> 
> The closest I could think to a decent bike shed color would be a global 
> function:
> 
>   if not(isValid) {…}
> 
> -DW
> 
>> On Feb 15, 2017, at 11:10 AM, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>> So you've identified the problem, but what do you propose as a solution 
>> here?  
>> 
>> It should be noted that a (non-stdlib) language-level answer to this 
>> question has already been discussed and rejected 
>> (https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html 
>> ).
>> 
>> ~Robert Widmann
>> 
>> 2017/02/15 9:02、Sadiq via swift-evolution > > のメッセージ:
>> 
>>> Hello,
>>> 
>>> I would like to suggest to change Logical NOT Operator from ! to something 
>>> else. 
>>> It will increase the readability of the code and will avoid any confusion 
>>> with the symbol used for force unwrapping of optional values. 
>>> It would be easier for new programmers to learn Swift as the first 
>>> language. 
>>> I don't understand the rational behind using the same operator for two 
>>> different purposes. 
>>> 
>>> Thanks and Regards,
>>> Mohammad Sadiq
>>> ___
>>> 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

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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Joanna Carter via swift-evolution]

> This definition of `scoped` is actually much different than the current 
> `private` which restricts visibility to the *current* scope.  Your definition 
> allows visibility in an unlimited number of scopes that just happen to be of 
> the same type.  I don’t think `scoped` is a good name for this.

Agreed

> `private(type)` would be a better name if we were going to make this a 
> modification of the existing access modifiers.  However, I don’t think this 
> is the right direction.  If we’re going to have an access modifier that means 
> “in the same file *and* the same type” I think that should simply be called 
> `private` (a “soft default”).  If we’re going to have something between 
> `internal` and `fileprivate` I think it would be better to explore submodules 
> than introduce something like `internal(type)`.

I remember discussions earlier in Swift's history about bracketed keywords and 
it is my opinion that, when you consider other such syntax, such as public 
private(set) var … , this could, all too soon, get very confusing.

--
Joanna Carter
Carter Consulting

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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Joanna Carter via swift-evolution]

> 
> Here's an idea in three points:
> 
> 1. Return to the Swift 2 definition of `private`.
> 2. Introduce `scoped` to limit the visibility to within the same type, 
> subtype, or extension.
> 3. Allow mixing the two.
> 
> So you have:
> 
>   private // current file
>   private scoped  // current file, in the same type, subtype, or ext.
>   internal// current module
>   internal scoped // current module, in the same type, subtype, or ext.
>   public  // external modules
>   public scoped   // maybe we want that one?
> 
> Since `internal` is implied, using `scoped` alone would be equivalent to 
> `internal scoped`.
> 
> Swift 3's private could be mapped to `private scoped` to achieve (almost) the 
> same results and thus preserve source compatibility.

Without wishing to offend, this seems to be creating a lot more keywords for 
people to try and get their heads around. I am a firm believer in KISS and 
would like to see the bare minimum of keywords for scopes, so as not to confuse 
the elderly, frail, young, inexperienced, etc ;-)

--
Joanna Carter
Carter Consulting

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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Joanna Carter via swift-evolution]

> Was surprised that you expressed exactly what I'm thinking about this subject.
> 
> I do believe even in Swift we need a way to say "only code that *knows* what 
> it does should see this" and to not force us to write(and manage) the the 
> code in same file.
> Yes, some implementation details that shouldn't be used by "users" of the 
> type, but can be used by "extenders" of our type. At least in the same module.

Indeed. I spent a number of years designing and implementing a very large 
framework (in C#) for a company who had a small team of developers of varying 
skill levels and, whether they were working on the framework or on the app that 
used the framework, the number one consideration had to be ensuring that they 
were not able to break something that was already tested and approved, 
inadvertently, whilst working on another part of the project. this was 
especially relevant to work being done on classes that derived from base 
classes or classes that implemented interfaces (protocols).

With the present state of Swift, I would not be as confident handing out such 
tasks to a team using this language.

> While reading, the question was raised(if was discussed, let me know pls): 
> what if we extend the meaning of 'private' to 'visible to current type/scope 
> and subtypes and extensions in the *same module*' ?
> This will help us to split types by files, help to better model access policy 
> for fields/methods(i.e. only scope that can know about details can see them) 
> while 'private' still will be hidden outside of the module even for 
> subclasses/extensions.

Hmm. I really don't like the idea of extending private to mean anything other 
than inside the declaring scope. I was one of those who was disappointed with 
the Swift 2 definition of it being file scope, having seen the abuse and 
generally bad code that developers fall into when allowed that freedom. In 
Delphi, I have seen some horrendously large files that contained everything but 
the kitchen sink ; when I asked the developer why he had done it, he said it 
was because, otherwise, he couldn't access the private members of a base class 
(he didn't understand the concept of protected visibility 8-)

> Actually I still believe we need current 'private' and additionally some 
> 'protected' with meaning "access from subtype, or extension" probably with 
> this limitation: "only in the same module". But suggested extended 'private' 
> will be also OK for me.

And this is where I find myself. My suggestion was to try to integrate the idea 
of "protected" within class hierarchies with the need for privileged access for 
extensions to other types, whether they be in the same module or not.

Hence the name "extensible" to signify whether you were extending a class by 
inheritance or any other type with an extension, we would only need the one 
keyword to clearly express the concept.

--
Joanna Carter
Carter Consulting

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

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

[Derrick Ho via swift-evolution]

There is no need to change it

Since the context basically disambiguates the meaning of !

The next best thing is to compare it to false

(val == false) // same as !val
On Wed, Feb 15, 2017 at 3:02 PM David Waite via swift-evolution <
swift-evolution@swift.org> wrote:

> If someone came with a nice syntax I’d be for this. I can’t imagine what
> that would be.
>
> I doubt there is an alternate prefix or postfix operator that would pass
> muster, due to ‘!’ already meaning the appropriate thing in so many
> languages, and swift only supporting symbolic operators.
>
> I can’t think of a method on boolean which would read properly either, e.g.
>
> if isValid.not() {…}
>
> The closest I could think to a decent bike shed color would be a global
> function:
>
> if not(isValid) {…}
>
> -DW
>
> On Feb 15, 2017, at 11:10 AM, Robert Widmann via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> So you've identified the problem, but what do you propose as a solution
> here?
>
> It should be noted that a (non-stdlib) language-level answer to this
> question has already been discussed and rejected (
> https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html
> ).
>
> ~Robert Widmann
>
> 2017/02/15 9:02、Sadiq via swift-evolution 
> のメッセージ:
>
> Hello,
>
> I would like to suggest to change Logical NOT Operator from ! to something
> else.
> It will increase the readability of the code and will avoid any confusion
> with the symbol used for force unwrapping of optional values.
> It would be easier for new programmers to learn Swift as the first
> language.
> I don't understand the rational behind using the same operator for two
> different purposes.
>
> Thanks and Regards,
> Mohammad Sadiq
>
> ___
> 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] Pitch: Replacement for FileHandle

[Itai Ferber via swift-evolution]

FYI, Tony is the manager of the Foundation team. :)
We care very much about making sure that the experience of using our 
framework is a positive one — the more Radars we get, the better we 
can prioritize improving APIs that are not working as well as they could 
be for our users. Even if the Radar gets duped to an existing one, thats 
one more +1 for that Radar saying "this is a problem".


I will search for your old Radar, but in any case, please do file a new 
one about this, and about any other issues you have, because we are 
indeed listening.


On 15 Feb 2017, at 10:41, Charles Srstka via swift-evolution wrote:

> On Feb 15, 2017, at 10:52 AM, Tony Parker  
wrote:


Hi Charles,

Have you happened to file a radar for Foundation that I can look up 
(for both this and process)?


We are working hard on making sure that our API is right for Swift, 
and areas like this where we can make fairly trivial improvements are 
things that we can try to prioritize. As you say, the purpose of 
swift-corelibs-foundation is to present a unified API and prevent the 
need to fork. That means the best possible solution is to improve the 
API in Objective-C (where exceptions-as-control flow is wrong too) 
first, and then naturally flow that into Swift.


Thanks,
- Tony


Honestly? I don’t remember. I feel like I would have sometime around 
2005 or 2006 or so, since that’s probably about when this first 
started bothering me, but it’s been a decade, so my memory is hazy. 
I do know that in the meantime, “considered harmful”-type articles 
have been written about these classes, like this one from eight years 
ago:


https://mikeash.com/pyblog/friday-qa-2009-11-13-dangerous-cocoa-calls.html 



If you think it will actually prompt someone to change this, I’d be 
happy to write up a new one, although I figure it would almost 
certainly just get flagged as a duplicate.


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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[David Waite via swift-evolution]

Types have a ton of different implicit/explicit “API”, and access control 
modifiers often implicitly define that API:

- API for everyone to use when dealing with your concrete type (“public”)
- API for module code when you have related, coupled types that need a higher 
degree of knowledge (“internal”)
- API for within the implementation of the type itself (“fileprivate”/“private”)
- API to other code to interact with your type in a more general manner 
(protocol implementation)
- You also have two versions of each of these - instance and static/class-level 
properties/methods (including initializers)
- Each of these can also have stability aspects - which versions of a framework 
support the API, whether the API is deprecated or obsoleted, etc. (exposed 
partially today via “#available")

And classes add even more!:
- Whether subclassing is allowed (‘final’)
- API for subclasses to use for their implementation, but not meant for general 
usage (typically “protected")
- API which subclasses are allowed to override to implement new logic (“open")
- API which subclasses are forbidden to override because they define business 
logic used by coupled code ("final"/"closed")
- API which subclasses are required to override (typically “abstract" base 
classes - Swift and Objective C seem to prefer Delegates instead)

(I’m probably forgetting a few)

So access levels serve three main purposes:
1. to define these API so that a developer interacting with your type knows 
what is or is not (for instance) a subclass knows what it is or is not allowed 
to change, code using your types know what is or is not safe to call, etc.
2. to try to enforce these API to be used  only by the intend audience
3. to prevent reliance on implementation details as a stable API

Obviously not all of these cases need compiler-enforcement of the API - nor 
could you have a simple enough system for general purpose consumption which 
attempted to do so. In the case language features do not document the 
stakeholders or behavior of the API, regular documentation and processes should 
attempt to do so. 

This IMHO was the majority of the argument against SE-0025 - that if you are 
already in the same file, you must know the implementation details well enough 
to know what is or is not safe API. If developers were putting too much code 
within a single file was a case for a level above fileprivate, not below it. 
This why I personally pushed to defer until there was a submodule design.

The public/internal/private model is nice because it mirrors code locality, and 
thus is focused on enforcement of safety. If some other code depends on 
implementation details of my type that I don’t want to expose to the world, 
that code is going to be in the same module or even the same file. Hiding 
implementation details is enforcement for safety.

Classes obviously provide an explosion of complexity in defining behavior 
because of the additional relationship with sub- and super-classes. I generally 
push people away from designing their packages to rely on subclassing (instead 
preferring protocols and aggregation) because keeping this complexity straight 
and having a good design that reduces coupling is so difficult when dealing 
with subclassing.

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

Re: [swift-evolution] Does protocol support add to an object's size?

[Slava Pestov via swift-evolution]

Values of concrete type always have the same size regardless of what protocols 
the type conforms to.

Slava
 
> On Feb 15, 2017, at 9:51 AM, Daryle Walker via swift-evolution 
>  wrote:
> 
> I don't know how protocol support works. I asking because I want to maintain 
> the stride of an array being the total count times the stride of the element, 
> which would complicate nominal arrays if adding protocols to one breaks that. 
> 
> Sent from my iPhone
> ___
> 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] Simplifying Access Using 'Hidden'

[Jean-Daniel via swift-evolution]

> Le 15 févr. 2017 à 16:37, Michel Fortin via swift-evolution 
>  a écrit :
> 
>> 
>> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution 
>>  a écrit :
>> 
>> On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote:
 The beauty of Swift 2's access modifiers was that they were based
 around files and modules, explicitly rejecting types and scopes as
 units for determining visibility. It seems at base there's a group of
 people who reject that decision altogether. Hence, new `private`,
 proposals around `protected`, `friend`, `hidden`, `extensible`, etc.
>>> 
>>> I suppose, for those coming from an Objective-C only background, any
>>> extra visibilities are seen as a bonus.
>>> 
>>> For those coming from a Pascal background, file-based visibility seems
>>> more natural.
>>> 
>>> But for those of us who have used languages like C++ and C#, losing the
>>> visibilities that we have been used to can seriously affect how we think
>>> and design stuff.
>>> 
>> 
>> Was surprised that you expressed exactly what I'm thinking about this 
>> subject.
>> 
>> I do believe even in Swift we need a way to say "only code that *knows* what 
>> it does should see this" and to not force us to write(and manage) the the 
>> code in same file.
>> Yes, some implementation details that shouldn't be used by "users" of the 
>> type, but can be used by "extenders" of our type. At least in the same 
>> module.
>> 
>> While reading, the question was raised(if was discussed, let me know pls): 
>> what if we extend the meaning of 'private' to 'visible to current type/scope 
>> and subtypes and extensions in the *same module*' ?
>> This will help us to split types by files, help to better model access 
>> policy for fields/methods(i.e. only scope that can know about details can 
>> see them) while 'private' still will be hidden outside of the module even 
>> for subclasses/extensions.
>> 
>> So, we'll have such situation:
>> 
>> "modifier" -> "can be accessed from"
>> ---
>> public -> outside of the mondule
>> internal -> inside the module only
>> fileprivate -> the same file only
>> private -> the same type/scope, or subtype, or extension in the same module. 
>> I.e. some kind of 'internal' but scope-oriented.
>> 
>> Actually I still believe we need current 'private' and additionally some 
>> 'protected' with meaning "access from subtype, or extension" probably with 
>> this limitation: "only in the same module". But suggested extended 'private' 
>> will be also OK for me.
>> 
>> Thoughts?
> 
> Here's an idea in three points:
> 
> 1. Return to the Swift 2 definition of `private`.
> 2. Introduce `scoped` to limit the visibility to within the same type, 
> subtype, or extension.
> 3. Allow mixing the two.
> 


Alternative plan:

1. Return to the Swift 2 definition of `private`.
2. Work on submodule.
3. Work on visibility.

As the visibility and the way the code is structures will be a major goal of 
submodule, I don’t think it is worth investing more time on Access visibility 
until we know more about submodules.



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

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

[David Waite via swift-evolution]

If someone came with a nice syntax I’d be for this. I can’t imagine what that 
would be.

I doubt there is an alternate prefix or postfix operator that would pass 
muster, due to ‘!’ already meaning the appropriate thing in so many languages, 
and swift only supporting symbolic operators.

I can’t think of a method on boolean which would read properly either, e.g.

if isValid.not() {…}

The closest I could think to a decent bike shed color would be a global 
function:

if not(isValid) {…}

-DW

> On Feb 15, 2017, at 11:10 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
> So you've identified the problem, but what do you propose as a solution here? 
>  
> 
> It should be noted that a (non-stdlib) language-level answer to this question 
> has already been discussed and rejected 
> (https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html 
> ).
> 
> ~Robert Widmann
> 
> 2017/02/15 9:02、Sadiq via swift-evolution  > のメッセージ:
> 
>> Hello,
>> 
>> I would like to suggest to change Logical NOT Operator from ! to something 
>> else. 
>> It will increase the readability of the code and will avoid any confusion 
>> with the symbol used for force unwrapping of optional values. 
>> It would be easier for new programmers to learn Swift as the first language. 
>> I don't understand the rational behind using the same operator for two 
>> different purposes. 
>> 
>> Thanks and Regards,
>> Mohammad Sadiq
>> ___
>> 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] [Pitch] consistent public access modifiers

[Adrian Zubarev via swift-evolution]

Not a huge response, but how about locked?



-- 
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 20:31:30, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:


> On Feb 14, 2017, at 3:43 AM, Brent Royal-Gordon  
> wrote:
>  
>> On Feb 13, 2017, at 7:45 AM, Matthew Johnson  wrote:
>>  
>> If you look closely, when most people say “closed enum” they mean a fixed, 
>> complete set of cases that are all public. But when people say “closed 
>> protocol” they don’t actually mean a fixed, complete set of conformances 
>> that are all public. They simply mean clients cannot add conformances. This 
>> is the semantic contract of resilient enums, not closed enums.
>  
> Yes, our traditional terminology here has been a little bit confused.
>  
>>> What I instead suggest is that we think of a closed enum as being like a 
>>> fragile (non-resilient) struct. In both cases, you are committing to a 
>>> particular design for the type. So I think we should give them both the 
>>> same keyword—something like:
>>>  
>>> @fixed struct Person {
>>> var name: String
>>> var birthDate: Date
>>> }
>>> @fixed enum Edge {
>>> case start
>>> case end
>>> }
>>>  
>>  
>> You omitted public here. Does that mean you intend for `@fixed` to imply 
>> public visibility? If so, I could get behind this. But I am curious why you 
>> made it an attribute rather than a keyword.
>  
> No, I'm sorry, I meant to say `@fixed public struct` and `@fixed public 
> enum`. I don't think `@fixed` implies public-ness, either, so it would need 
> to be paired with a `public` keyword. There *may* be keywords we could use 
> that would, like `exposed`, but I'm not sure we want to make this feature so 
> prominent, and I'm not sure how that would work with classes you want to both 
> expose and permit subclassing of. (Would that be `exposed open class Foo`?)

I thought of a couple of other possible keywords. I had previously mentioned 
`complete` as an alternative to `closed`. Another option that goes in this 
direction is `total` - it borrows from the mathematical notion of a total 
function. I’m not sure how I feel about this option and it still doesn’t 
necessarily imply “more public than public” very strongly (only in the sense 
that its totality is known to all which is a rather weak sense).

Another possibility is `transparent`. This does imply “more public than public” 
a some sense that is similar to `open`. I know `@transparent` (or something 
like that) has been used as an unsupported(?) attribute hinting to the compiler 
that a function should be made available for inlining (what is the current 
status of this?). The meaning of this attribute is in some ways similar to the 
meaning you ascribe to `fixed`. In all cases, this is only meaningful for 
`public` entities so it feels like a promising direction.  

The one thing that makes me somewhat uncomfortable with this approach is that 
in the context of structs and functions it has no semantic impact on user code 
- it is only an optimization, while for enums it wold make a important semantic 
difference to user code. I’m not sure we should use the same syntax for 
something that is sometimes an optimization and sometimes is semantically 
meaningful. This concern is relevant regardless of what the keyword is called.

>  
>>> I don't see it mentioned here (maybe I just missed it), but even though we 
>>> *could* do exhaustiveness checking on non-open protocols, I'm not convinced 
>>> that's a good idea. Usually when you have several types conforming to a 
>>> protocol, you should access type-specific behavior through polymorphism, 
>>> not by switching on the protocol. A protocol is supposed to represent a 
>>> behavior, not just mark a type in some arbitrary way.
>>  
>> I agree that you should usually be adding polymorphism, but preventing 
>> exhaustive switch on what is effectively a style argument seems like an 
>> unnecessary restriction to me. There will be times when it could be used to 
>> good effect. I think the community has done a pretty good job of figuring 
>> out how to use Swift’s many features well and don’t believe it would be 
>> frequently abused.
>  
> I agree we shouldn't change the language to *prevent* bad style. But this 
> would go beyond that—we'd be putting specific engineering effort solely into 
> *enabling* bad style. At minimum, this should fall so far down our to-do list 
> that we'll probably never get to it.
>  
>>> I still support this general approach. One spelling could simply be 
>>> `@nonopen`. Although if we don't use `closed`, we could simply use 
>>> `@closed` like I suggested—here it really *would* be an antonym to `open`.
>>  
>> I like the idea of using `@nonopen` for the transitional attribute. Both 
>> because it “removes the openness” that `public protocol` currently implies. 
>> In that sense it is probably the most accurate term we could find and it’s 
>> also pretty 

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 14, 2017, at 3:43 AM, Brent Royal-Gordon  
> wrote:
> 
>> On Feb 13, 2017, at 7:45 AM, Matthew Johnson  wrote:
>> 
>> If you look closely, when most people say “closed enum” they mean a fixed, 
>> complete set of cases that are all public.  But when people say “closed 
>> protocol” they don’t actually mean a fixed, complete set of conformances 
>> that are all public.  They simply mean clients cannot add conformances.  
>> This is the semantic contract of resilient enums, not closed enums.
> 
> Yes, our traditional terminology here has been a little bit confused.
> 
>>> What I instead suggest is that we think of a closed enum as being like a 
>>> fragile (non-resilient) struct. In both cases, you are committing to a 
>>> particular design for the type. So I think we should give them both the 
>>> same keyword—something like:
>>> 
>>> @fixed struct Person {
>>> var name: String
>>> var birthDate: Date
>>> }
>>> @fixed enum Edge {
>>> case start
>>> case end
>>> }
>>> 
>> 
>> You omitted public here.  Does that mean you intend for `@fixed` to imply 
>> public visibility?  If so, I could get behind this.  But I am curious why 
>> you made it an attribute rather than a keyword.
> 
> No, I'm sorry, I meant to say `@fixed public struct` and `@fixed public 
> enum`. I don't think `@fixed` implies public-ness, either, so it would need 
> to be paired with a `public` keyword. There *may* be keywords we could use 
> that would, like `exposed`, but I'm not sure we want to make this feature so 
> prominent, and I'm not sure how that would work with classes you want to both 
> expose and permit subclassing of. (Would that be `exposed open class Foo`?)

I thought of a couple of other possible keywords.  I had previously mentioned 
`complete` as an alternative to `closed`.  Another option that goes in this 
direction is `total` - it borrows from the mathematical notion of a total 
function.  I’m not sure how I feel about this option and it still doesn’t 
necessarily imply “more public than public” very strongly (only in the sense 
that its totality is known to all which is a rather weak sense).

Another possibility is `transparent`.  This does imply “more public than 
public” a some sense that is similar to `open`.  I know `@transparent` (or 
something like that) has been used as an unsupported(?) attribute hinting to 
the compiler that a function should be made available for inlining (what is the 
current status of this?).  The meaning of this attribute is in some ways 
similar to the meaning you ascribe to `fixed`.  In all cases, this is only 
meaningful for `public` entities so it feels like a promising direction.  

The one thing that makes me somewhat uncomfortable with this approach is that 
in the context of structs and functions it has no semantic impact on user code 
- it is only an optimization, while for enums it wold make a important semantic 
difference to user code.  I’m not sure we should use the same syntax for 
something that is sometimes an optimization and sometimes is semantically 
meaningful.  This concern is relevant regardless of what the keyword is called.

> 
>>> I don't see it mentioned here (maybe I just missed it), but even though we 
>>> *could* do exhaustiveness checking on non-open protocols, I'm not convinced 
>>> that's a good idea. Usually when you have several types conforming to a 
>>> protocol, you should access type-specific behavior through polymorphism, 
>>> not by switching on the protocol. A protocol is supposed to represent a 
>>> behavior, not just mark a type in some arbitrary way.
>> 
>> I agree that you should usually be adding polymorphism, but preventing 
>> exhaustive switch on what is effectively a style argument seems like an 
>> unnecessary restriction to me.  There will be times when it could be used to 
>> good effect.  I think the community has done a pretty good job of figuring 
>> out how to use Swift’s many features well and don’t believe it would be 
>> frequently abused.
> 
> I agree we shouldn't change the language to *prevent* bad style. But this 
> would go beyond that—we'd be putting specific engineering effort solely into 
> *enabling* bad style. At minimum, this should fall so far down our to-do list 
> that we'll probably never get to it.
> 
>>> I still support this general approach. One spelling could simply be 
>>> `@nonopen`. Although if we don't use `closed`, we could simply use 
>>> `@closed` like I suggested—here it really *would* be an antonym to `open`.
>> 
>> I like the idea of using `@nonopen` for the transitional attribute.  Both 
>> because it “removes the openness” that `public protocol` currently implies.  
>> In that sense it is probably the most accurate term we could find and it’s 
>> also pretty concise.
> 
> It also sounds a little bit awkward, which is normally a reason not to use 
> it, but perhaps that's 

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Rien via swift-evolution]

> 
> On 15 Feb 2017, at 19:27, Adrian Zubarev  
> wrote:
> 
> Inline:
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 15. Februar 2017 um 19:11:12, Rien (r...@balancingrock.nl) schrieb:
> 
>> 
>> > On 15 Feb 2017, at 18:09, Adrian Zubarev  
>> > wrote: 
>> > 
>> > As I already said: 
>> > 
>> > • To make that feature happen, we need the protocol to be public 
>> > (regardless if you can conform to it or not). 
>> > • Today you can conform to every protocol because in reality they are open 
>> > today. 
>> > • If we remove the property requirement from the protocol the client can 
>> > conform it to any type and break my API by calling the subscript with a 
>> > wrong type: document["something", NSObject()] (assuming extension NSObject 
>> > : SubscriptParameterType). 
>> > • That forces me to create a requirement for the protocol which solves the 
>> > issue in my cases, however there might exist other issues, which could be 
>> > far more complicated than mine is. 
>> > • That also implies I have make the enum public. 
>> > • Which follows by the fact that I’m creating unnecessary copy operations 
>> > to wrap every instance that conforms to my protocol into an enum case. 
>> > From internal API perspective I also have to unwrap the enum case. 
>> > Instead if we had consistent public vs. open behavior, I could make the 
>> > protocol public (but-not-open), remove the requirement from it completely, 
>> > remove the enum completely and simply cast to Int or String because as the 
>> > author of the library I would know that the client won’t be able to 
>> > conform to my protocol. 
>> > 
>> > Importing my library will show the client only this: 
>> > 
>> > extension Int : SubscriptParameterType {} 
>> > extension String : SubscriptParameterType {} 
>> > 
>> > 
>> 
>> Ok, thanks, I think I get it now. So you showed the work-around rather than 
>> the problem :-) 
>> However you could also implement this by creating two subscript operations, 
>> one for integer and one for string. 
> No not really, the idea behind this approach is carefully crafted. Plus I do 
> not want optional chaining between subscripts, this is messy 
> `document[“string”]?[10]?[“key”]`.

Yes, but there are always more ways to skin a cat :-)
In my SwifterJSON I do use both an int and a string subscript and have solved 
the optional chaining (rather ugly… but it works).
Also, I overloaded the pipe (“|”) operator that allows me to do away with the 
array notation like this: … = json | ”books” | 3 | “title"


> 
>> 
>> 
>> So while I agree that this might serve as an example on why a 
>> non-confirmable protocol might be useful, my original question still stands: 
>> how can subclassing create “brittle” libraries? 
> If one would want the client user only to use subclasses of a certain 
> superclass of the same library for whatever reasons. These subclasses might 
> interact with each other internally (which is not meant to be public by any 
> means). `final public` will not make it happen because then you couldn’t 
> create any of these subclasses at all.
> 
> You’re asking here such a general question that simply cannot be answered 
> easily. I also could ask everyone why on earth would be want to hide anything 
> from the client? Lets make everything public, if the client breaks something 
> it’s his fault. <— Clearly not the way to go right? A distinction between 
> `public` and `open` adds more flexibility to solve issues that previously 
> might not had any good solutions.

It does, I am not doubting that at all.
But there are always costs, adding an extra keyword and an extra access layer 
adds complexity, adds possibilities for errors, leads to more testing, 
increases cognitive load, steepens the learning curve etc etc. And it does so 
for ALL swift users. Possibly far outweighing the benefits that accrue to 
(maybe) just a few developers.

(Like the infamous tax problem: people won’t spend much effort to change the 
tax system and pay $1 a year less in taxes, but the one organisation/person 
receiving all those dollars has a huge incentive and will spend -if necessary- 
all his time to keep the system as is)

> 
>> 
>> 
>> Also note that adding an extra access level did nothing to prevent brittle 
>> libraries… that task is still with the developer. 
>> 
>> PS, this is not an educational list, so … :-) 
> Being sarcastic? 

No, not really. I just wanted to draw attention to the fact that there is no 
obligation whatsoever to teach me.
So thank you for taking the time!

In your debt,
Rien.

> 
>> 
>> 
>> Regards, 
>> Rien. 
>> 
>> > 
>> > 
>> > -- 
>> > Adrian Zubarev 
>> > Sent with Airmail 
>> > 
>> > Am 15. Februar 2017 um 17:50:41, Rien (r...@balancingrock.nl) schrieb: 
>> > 
>> >> 
>> >> > On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution 
>> >> >  wrote: 
>> >> >  
>> >> > A short example where I personally wanted 

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Charles Srstka via swift-evolution]

> On Feb 15, 2017, at 10:52 AM, Tony Parker  wrote:
> 
> Hi Charles,
> 
> Have you happened to file a radar for Foundation that I can look up (for both 
> this and process)?
> 
> We are working hard on making sure that our API is right for Swift, and areas 
> like this where we can make fairly trivial improvements are things that we 
> can try to prioritize. As you say, the purpose of swift-corelibs-foundation 
> is to present a unified API and prevent the need to fork. That means the best 
> possible solution is to improve the API in Objective-C (where 
> exceptions-as-control flow is wrong too) first, and then naturally flow that 
> into Swift.
> 
> Thanks,
> - Tony

Honestly? I don’t remember. I feel like I would have sometime around 2005 or 
2006 or so, since that’s probably about when this first started bothering me, 
but it’s been a decade, so my memory is hazy. I do know that in the meantime, 
“considered harmful”-type articles have been written about these classes, like 
this one from eight years ago:

https://mikeash.com/pyblog/friday-qa-2009-11-13-dangerous-cocoa-calls.html 


If you think it will actually prompt someone to change this, I’d be happy to 
write up a new one, although I figure it would almost certainly just get 
flagged as a duplicate.

Charles

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Adrian Zubarev via swift-evolution]

If you happen not to bump into these issues yet, then simply call yourself 
lucky. ;)

-- 
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 19:27:06, Adrian Zubarev 
(adrian.zuba...@devandartist.com) schrieb:

Inline:

-- 
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 19:11:12, Rien (r...@balancingrock.nl) schrieb:


> On 15 Feb 2017, at 18:09, Adrian Zubarev  
> wrote: 
> 
> As I already said: 
> 
> • To make that feature happen, we need the protocol to be public (regardless 
> if you can conform to it or not). 
> • Today you can conform to every protocol because in reality they are open 
> today. 
> • If we remove the property requirement from the protocol the client can 
> conform it to any type and break my API by calling the subscript with a wrong 
> type: document["something", NSObject()] (assuming extension NSObject : 
> SubscriptParameterType). 
> • That forces me to create a requirement for the protocol which solves the 
> issue in my cases, however there might exist other issues, which could be far 
> more complicated than mine is. 
> • That also implies I have make the enum public. 
> • Which follows by the fact that I’m creating unnecessary copy operations to 
> wrap every instance that conforms to my protocol into an enum case. From 
> internal API perspective I also have to unwrap the enum case. 
> Instead if we had consistent public vs. open behavior, I could make the 
> protocol public (but-not-open), remove the requirement from it completely, 
> remove the enum completely and simply cast to Int or String because as the 
> author of the library I would know that the client won’t be able to conform 
> to my protocol. 
> 
> Importing my library will show the client only this: 
> 
> extension Int : SubscriptParameterType {} 
> extension String : SubscriptParameterType {} 
> 
> 

Ok, thanks, I think I get it now. So you showed the work-around rather than the 
problem :-) 
However you could also implement this by creating two subscript operations, one 
for integer and one for string. 
No not really, the idea behind this approach is carefully crafted. Plus I do 
not want optional chaining between subscripts, this is messy 
`document[“string”]?[10]?[“key”]`.



So while I agree that this might serve as an example on why a non-confirmable 
protocol might be useful, my original question still stands: how can 
subclassing create “brittle” libraries? 
If one would want the client user only to use subclasses of a certain 
superclass of the same library for whatever reasons. These subclasses might 
interact with each other internally (which is not meant to be public by any 
means). `final public` will not make it happen because then you couldn’t create 
any of these subclasses at all.

You’re asking here such a general question that simply cannot be answered 
easily. I also could ask everyone why on earth would be want to hide anything 
from the client? Lets make everything public, if the client breaks something 
it’s his fault. <— Clearly not the way to go right? A distinction between 
`public` and `open` adds more flexibility to solve issues that previously might 
not had any good solutions.



Also note that adding an extra access level did nothing to prevent brittle 
libraries… that task is still with the developer. 

PS, this is not an educational list, so … :-) 
Being sarcastic? 



Regards, 
Rien. 

> 
> 
> -- 
> Adrian Zubarev 
> Sent with Airmail 
> 
> Am 15. Februar 2017 um 17:50:41, Rien (r...@balancingrock.nl) schrieb: 
> 
>> 
>> > On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution 
>> >  wrote: 
>> >  
>> > A short example where I personally wanted a public-but-not-open protocol: 
>> >  
>> > public protocol SubscriptParameterType { 
>> >  
>> > // This property was needed to prevent the client from breaking 
>> > // the library by conforming to the protocol, but I'd like to  
>> > // keep it invisible for the client, or even better prevent the 
>> > // client from conforming to the protocol. 
>> > var parameter: Document.SubscriptParameter { get } 
>> > } 
>> >  
>> > extension Document { 
>> >  
>> > public enum SubscriptParameter { 
>> >  
>> > case string(String) 
>> > case integer(Int) 
>> > } 
>> > } 
>> >  
>> > extension String : SubscriptParameterType { 
>> >  
>> > public var parameter: Document.SubscriptParameter { 
>> >  
>> > return .string(self) 
>> > } 
>> > } 
>> >  
>> > extension Int : SubscriptParameterType { 
>> >  
>> > public var parameter: Document.SubscriptParameter { 
>> >  
>> > return .integer(self) 
>> > } 
>> > } 
>> >  
>> > // Somewhere inside the `Document` type 
>> > public subscript(firstKey: String, parameters: SubscriptParameterType...) 
>> > -> Value? { … } 
>> >  
>> > That implementation enables more safe queries of my Document type like 
>> > document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather 
>> > than 

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Adrian Zubarev via swift-evolution]

Inline:

-- 
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 19:11:12, Rien (r...@balancingrock.nl) schrieb:


> On 15 Feb 2017, at 18:09, Adrian Zubarev  
> wrote: 
> 
> As I already said: 
> 
> • To make that feature happen, we need the protocol to be public (regardless 
> if you can conform to it or not). 
> • Today you can conform to every protocol because in reality they are open 
> today. 
> • If we remove the property requirement from the protocol the client can 
> conform it to any type and break my API by calling the subscript with a wrong 
> type: document["something", NSObject()] (assuming extension NSObject : 
> SubscriptParameterType). 
> • That forces me to create a requirement for the protocol which solves the 
> issue in my cases, however there might exist other issues, which could be far 
> more complicated than mine is. 
> • That also implies I have make the enum public. 
> • Which follows by the fact that I’m creating unnecessary copy operations to 
> wrap every instance that conforms to my protocol into an enum case. From 
> internal API perspective I also have to unwrap the enum case. 
> Instead if we had consistent public vs. open behavior, I could make the 
> protocol public (but-not-open), remove the requirement from it completely, 
> remove the enum completely and simply cast to Int or String because as the 
> author of the library I would know that the client won’t be able to conform 
> to my protocol. 
> 
> Importing my library will show the client only this: 
> 
> extension Int : SubscriptParameterType {} 
> extension String : SubscriptParameterType {} 
> 
> 

Ok, thanks, I think I get it now. So you showed the work-around rather than the 
problem :-) 
However you could also implement this by creating two subscript operations, one 
for integer and one for string. 
No not really, the idea behind this approach is carefully crafted. Plus I do 
not want optional chaining between subscripts, this is messy 
`document[“string”]?[10]?[“key”]`.



So while I agree that this might serve as an example on why a non-confirmable 
protocol might be useful, my original question still stands: how can 
subclassing create “brittle” libraries? 
If one would want the client user only to use subclasses of a certain 
superclass of the same library for whatever reasons. These subclasses might 
interact with each other internally (which is not meant to be public by any 
means). `final public` will not make it happen because then you couldn’t create 
any of these subclasses at all.

You’re asking here such a general question that simply cannot be answered 
easily. I also could ask everyone why on earth would be want to hide anything 
from the client? Lets make everything public, if the client breaks something 
it’s his fault. <— Clearly not the way to go right? A distinction between 
`public` and `open` adds more flexibility to solve issues that previously might 
not had any good solutions.



Also note that adding an extra access level did nothing to prevent brittle 
libraries… that task is still with the developer. 

PS, this is not an educational list, so … :-) 
Being sarcastic? 



Regards, 
Rien. 

> 
> 
> -- 
> Adrian Zubarev 
> Sent with Airmail 
> 
> Am 15. Februar 2017 um 17:50:41, Rien (r...@balancingrock.nl) schrieb: 
> 
>> 
>> > On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution 
>> >  wrote: 
>> >  
>> > A short example where I personally wanted a public-but-not-open protocol: 
>> >  
>> > public protocol SubscriptParameterType { 
>> >  
>> > // This property was needed to prevent the client from breaking 
>> > // the library by conforming to the protocol, but I'd like to  
>> > // keep it invisible for the client, or even better prevent the 
>> > // client from conforming to the protocol. 
>> > var parameter: Document.SubscriptParameter { get } 
>> > } 
>> >  
>> > extension Document { 
>> >  
>> > public enum SubscriptParameter { 
>> >  
>> > case string(String) 
>> > case integer(Int) 
>> > } 
>> > } 
>> >  
>> > extension String : SubscriptParameterType { 
>> >  
>> > public var parameter: Document.SubscriptParameter { 
>> >  
>> > return .string(self) 
>> > } 
>> > } 
>> >  
>> > extension Int : SubscriptParameterType { 
>> >  
>> > public var parameter: Document.SubscriptParameter { 
>> >  
>> > return .integer(self) 
>> > } 
>> > } 
>> >  
>> > // Somewhere inside the `Document` type 
>> > public subscript(firstKey: String, parameters: SubscriptParameterType...) 
>> > -> Value? { … } 
>> >  
>> > That implementation enables more safe queries of my Document type like 
>> > document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather 
>> > than document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”] 
>> 
>> I see how that makes queries better. 
>> However what I do not see is how making the protocol “open” would make this 
>> less safe. 
>> (I do not see a reason to make it open either, 

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

[Sadiq via swift-evolution]

If that's the case, force unwrapping can be done with a different symbol.
Personally I like '!' for force unwrapping.

On Wed, Feb 15, 2017 at 11:45 PM, Jose Cheyo Jimenez 
wrote:

> https://lists.swift.org/pipermail/swift-evolution/
> 2015-December/32.html
>
> Swift tries to be part of the C family of languages so keeping all the
> familiar symbols is on purpose. See the ?: operator.
>
>
> On Feb 15, 2017, at 10:01 AM, Sadiq  wrote:
>
> I tried to find it there. I did not find it. You mean here
>
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
>
> right?
>
> On Wed, Feb 15, 2017 at 11:27 PM, Jose Cheyo Jimenez 
> wrote:
>
>> Hi Mohammad,
>>
>> This has been proposed before. Please see the commonly rejected section
>> in the GitHub repo for Swift Evolution.
>>
>> Thanks!
>>
>>
>> On Feb 15, 2017, at 6:02 AM, Sadiq via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hello,
>>
>> I would like to suggest to change Logical NOT Operator from ! to
>> something else.
>> It will increase the readability of the code and will avoid any confusion
>> with the symbol used for force unwrapping of optional values.
>> It would be easier for new programmers to learn Swift as the first
>> language.
>> I don't understand the rational behind using the same operator for two
>> different purposes.
>>
>> Thanks and Regards,
>> Mohammad Sadiq
>>
>> ___
>> 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] [Pitch] consistent public access modifiers

[Adrian Zubarev via swift-evolution]

I’ll try again to make it a little bit more simpler.

Assume we want to implement my feature to support document["string_literal", 
stringInstance, integerInstance, 42] where the first parameter type is always a 
String but the types follow afterward are either a String or an Int (literals 
should be supported too).

// Module A
// Today only `public` is allowed on protocols.
// `public protocol` means almost the same as `open class`.
// One is 'you can conform to it outside module A'
// the other is 'you can subclass to it outside module A'

// First idea
public SubscriptParameterType {}
extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}

extension Document {
 
public subscript(firstKey: String, parameters: SubscriptParameterType...) 
-> Value? {  
 
// CAST any instance of `SubscriptParameterType` to Int or String
}
}

// Module B
extension NSObject : SubscriptParameterType {}

// Lets try breaking module A
document["test", NSObject()] // Runtime error, because something unexpected 
happened in module A

// The reason is we let the client (module B) the ability to conform to our 
type without any requirements.

// To solve that issue we need TODAY a requirement on our protocol 
`SubscriptParameterType` (see my previous post)
// I already mentioned that the workaround creates unnecessary boilerplate in 
my library.

// We could clean everything up iff we had consistent `public` vs. `open` 
behavior. I will use `pulic-but-not-open` and `open` annotation now.

pulic-but-not-open SubscriptParameterType {}
extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}

// Module B
extension NSObject : SubscriptParameterType {} // Error, 
`SubscriptParameterType` is closed and cannot be conformed to outside module A!!
This feature is ridiculously powerful.



-- 
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 18:57:50, Rien via swift-evolution 
(swift-evolution@swift.org) schrieb:


> On 15 Feb 2017, at 17:45, Matthew Johnson  wrote:
>  
>  
>> On Feb 15, 2017, at 10:35 AM, Rien  wrote:
>>  
>>>  
>>> On 15 Feb 2017, at 17:02, Matthew Johnson  wrote:
>>>  
  
 On Feb 15, 2017, at 9:59 AM, Rien  wrote:
  
>  
> On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:
>  
>>  
>> On Feb 15, 2017, at 9:35 AM, Rien  wrote:
>>  
>>  
>>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>>>  wrote:
>>>  
>>>  
 On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
  wrote:
  
  
> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
>  wrote:
>  
>  
> Our philosophy in general, however, is to default to the behavior 
> which preserves the most flexibility for the library designer.
  
 Actually, I thought the philosophy was to preserver type safety. When 
 did that change?
  
 Also, when was the library designer prioritised ahead of the 
 application developer?
  
  
> Both open and non-open classes are common, but we chose to give 
> non-open classes the `public` keyword because that's the 
> flexibility-preserving option.
  
 No it isn’t, it’s the flexibility restricting option. The consumer of 
 an open class can subclass it. The consumer of a public class cannot 
 subclass it. How is the second more flexible than the first?
>>>  
>>> It reduces complexity for the library author by allowing them to 
>>> opt-out of the complexity involved in supporting unknown, user-defined 
>>> subclasses. It is important to allow libraries to have this 
>>> flexibility. They are free to declare a class `open` if they want to 
>>> allow subclassing. It’s even possibly for a library to declare all 
>>> classes `open` if it wishes to do so. But *requiring* that would reduce 
>>> the design space libraries are allowed to explore and / or introduce 
>>> fragility by moving the subclass restriction to a comment.
>>>  
>>  
>> Why would a library author want to prohibit subclasses?
>> A library user can always wrap the class and subclass the wrapper.
>  
> This is composition, not inheritance. The most important difference is 
> that a wrapper cannot override methods, it can only wrap and / or forward 
> them. This means that when the superclass calls a method on `self` that 
> method *always* invokes its version of that method rather than a subclass 
> override. This is a very important difference.
>  
  
 Agreed, however that does not answer the 

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Rien via swift-evolution]

> On 15 Feb 2017, at 18:09, Adrian Zubarev  
> wrote:
> 
> As I already said:
> 
>   • To make that feature happen, we need the protocol to be public 
> (regardless if you can conform to it or not).
>   • Today you can conform to every protocol because in reality they are 
> open today.
>   • If we remove the property requirement from the protocol the client 
> can conform it to any type and break my API by calling the subscript with a 
> wrong type: document["something", NSObject()] (assuming extension NSObject : 
> SubscriptParameterType).
>   • That forces me to create a requirement for the protocol which solves 
> the issue in my cases, however there might exist other issues, which could be 
> far more complicated than mine is.
>   • That also implies I have make the enum public.
>   • Which follows by the fact that I’m creating unnecessary copy 
> operations to wrap every instance that conforms to my protocol into an enum 
> case. From internal API perspective I also have to unwrap the enum case.
> Instead if we had consistent public vs. open behavior, I could make the 
> protocol public (but-not-open), remove the requirement from it completely, 
> remove the enum completely and simply cast to Int or String because as the 
> author of the library I would know that the client won’t be able to conform 
> to my protocol.
> 
> Importing my library will show the client only this:
> 
> extension Int : SubscriptParameterType {}
> extension String : SubscriptParameterType {}
> 
> 

Ok, thanks, I think I get it now. So you showed the work-around rather than the 
problem :-)
However you could also implement this by creating two subscript operations, one 
for integer and one for string.

So while I agree that this might serve as an example on why a non-confirmable 
protocol might be useful, my original question still stands: how can 
subclassing create “brittle” libraries?

Also note that adding an extra access level did nothing to prevent brittle 
libraries… that task is still with the developer.

PS, this is not an educational list, so … :-)

Regards,
Rien.

> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 15. Februar 2017 um 17:50:41, Rien (r...@balancingrock.nl) schrieb:
> 
>> 
>> > On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution 
>> >  wrote: 
>> >  
>> > A short example where I personally wanted a public-but-not-open protocol: 
>> >  
>> > public protocol SubscriptParameterType { 
>> >  
>> > // This property was needed to prevent the client from breaking 
>> > // the library by conforming to the protocol, but I'd like to  
>> > // keep it invisible for the client, or even better prevent the 
>> > // client from conforming to the protocol. 
>> > var parameter: Document.SubscriptParameter { get } 
>> > } 
>> >  
>> > extension Document { 
>> >  
>> > public enum SubscriptParameter { 
>> >  
>> > case string(String) 
>> > case integer(Int) 
>> > } 
>> > } 
>> >  
>> > extension String : SubscriptParameterType { 
>> >  
>> > public var parameter: Document.SubscriptParameter { 
>> >  
>> > return .string(self) 
>> > } 
>> > } 
>> >  
>> > extension Int : SubscriptParameterType { 
>> >  
>> > public var parameter: Document.SubscriptParameter { 
>> >  
>> > return .integer(self) 
>> > } 
>> > } 
>> >  
>> > // Somewhere inside the `Document` type 
>> > public subscript(firstKey: String, parameters: SubscriptParameterType...) 
>> > -> Value? { … } 
>> >  
>> > That implementation enables more safe queries of my Document type like 
>> > document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather 
>> > than document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”] 
>> 
>> I see how that makes queries better. 
>> However what I do not see is how making the protocol “open” would make this 
>> less safe. 
>> (I do not see a reason to make it open either, but that is not the question) 
>> 
>> It may be obvious to everyone else, but I don’t see it. Am I suffering from 
>> a brain freeze?. 
>> 
>> Regards, 
>> Rien. 
>> 
>> 
>> > . 
>> >  
>> 
>> >  
>> >  
>> >  
>> > --  
>> > Adrian Zubarev 
>> > Sent with Airmail 
>> >  
>> > Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution 
>> > (swift-evolution@swift.org) schrieb: 
>> >  
>> >>  
>> >>> On Feb 15, 2017, at 9:59 AM, Rien  wrote: 
>> >>>  
>>   
>>  On 15 Feb 2017, at 16:45, Matthew Johnson  
>>  wrote: 
>>   
>> >  
>> > On Feb 15, 2017, at 9:35 AM, Rien  wrote: 
>> >  
>> >  
>> >> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>> >>  wrote: 
>> >>  
>> >>  
>> >>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
>> >>>  wrote: 
>> >>>  
>> >>>  
>>  On 15 Feb 2017, at 11:11, Brent Royal-Gordon via 

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

[Robert Widmann via swift-evolution]

So you've identified the problem, but what do you propose as a solution here?  

It should be noted that a (non-stdlib) language-level answer to this question 
has already been discussed and rejected 
(https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html).

~Robert Widmann

2017/02/15 9:02、Sadiq via swift-evolution  のメッセージ:

> Hello,
> 
> I would like to suggest to change Logical NOT Operator from ! to something 
> else. 
> It will increase the readability of the code and will avoid any confusion 
> with the symbol used for force unwrapping of optional values. 
> It would be easier for new programmers to learn Swift as the first language. 
> I don't understand the rational behind using the same operator for two 
> different purposes. 
> 
> Thanks and Regards,
> Mohammad Sadiq
> ___
> 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] [Pitch] consistent public access modifiers

[Rien via swift-evolution]

> On 15 Feb 2017, at 17:45, Matthew Johnson  wrote:
> 
> 
>> On Feb 15, 2017, at 10:35 AM, Rien  wrote:
>> 
>>> 
>>> On 15 Feb 2017, at 17:02, Matthew Johnson  wrote:
>>> 
 
 On Feb 15, 2017, at 9:59 AM, Rien  wrote:
 
> 
> On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:
> 
>> 
>> On Feb 15, 2017, at 9:35 AM, Rien  wrote:
>> 
>> 
>>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
  wrote:
 
 
> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> 
> Our philosophy in general, however, is to default to the behavior 
> which preserves the most flexibility for the library designer.
 
 Actually, I thought the philosophy was to preserver type safety. When 
 did that change?
 
 Also, when was the library designer prioritised ahead of the 
 application developer?
 
 
> Both open and non-open classes are common, but we chose to give 
> non-open classes the `public` keyword because that's the 
> flexibility-preserving option.
 
 No it isn’t, it’s the flexibility restricting option. The consumer of 
 an open class can subclass it. The consumer of a public class cannot 
 subclass it. How is the second more flexible than the first?
>>> 
>>> It reduces complexity for the library author by allowing them to 
>>> opt-out of the complexity involved in supporting unknown, user-defined 
>>> subclasses.  It is important to allow libraries to have this 
>>> flexibility. They are free to declare a class `open` if they want to 
>>> allow subclassing. It’s even possibly for a library to declare all 
>>> classes `open` if it wishes to do so.  But *requiring* that would 
>>> reduce the design space libraries are allowed to explore and / or 
>>> introduce fragility by moving the subclass restriction to a comment.
>>> 
>> 
>> Why would a library author want to prohibit subclasses?
>> A library user can always wrap the class and subclass the wrapper.
> 
> This is composition, not inheritance.  The most important difference is 
> that a wrapper cannot override methods, it can only wrap and / or forward 
> them.  This means that when the superclass calls a method on `self` that 
> method *always* invokes its version of that method rather than a subclass 
> override.  This is a very important difference.
> 
 
 Agreed, however that does not answer the question why would a library 
 developer want to disallow subclassing?
 I do not see a use case for that. I.e. a feature that cannot be 
 implemented without it. (without “open”)
>>> 
>>> The feature it enables is more robust libraries and the ability for library 
>>> authors to better reason about their code.  You may not find this benefit 
>>> enough to be worth a language feature, but many of us do.
>> 
>> You start of with a claim “more robust libraries”.
>> I would really like to know the “how” of that. How does it make a library 
>> more robust?
>> 
>> I do write libraries myself, and if there is something I am missing, I very 
>> much would like to know.
> 
> This topic was well explored during the discussion and review of the proposal 
> that introduced `open`.  If you would really like to know I suggest you take 
> some time to read through that discussion.

I did (proposal 117), while it was mentioned a few times “if not carefully 
designed for subclassing” there is no example on how open vs public prevents 
anything.

Mind you, it could be argued that the default of “internal” instead of “open” 
can prevent something (though I still don’t know what). But adding “open” does 
imo not prevent anything.

Besides: a monkey with a tool is still a monkey.

I.e. devs that now start using “open” vs “public” because it all is a hassle to 
figure out what should be “internal”, “public” or “open” will still make the 
same errors (which ones?) as before.
Thus while there is a lot of bad code around (partly mine!) that does not 
disappear because the default is not “not subclassable”.

(PS: I am still trying to get my head around Adrian’s example)

Regards,
Rien.

> 
>> 
>> Regards,
>> Rien.
>> 
>>> 
 
 Rien.
 
>> 
>> There are cases where subclassing does not make sense. And thus 
>> preventing subclasses adds information for those users that don’t RTFM. 
>> But that imo is not worth the impact extra complexity places on all 
>> other users.
>> 
>> Rien.

Re: [swift-evolution] final + lazy + fileprivate modifiers

[David Waite via swift-evolution]

> On Feb 15, 2017, at 5:00 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Keeping with the spirit of Swift and staying consistent with its design, I 
>> see two plausible meanings for private:
>> 
>> Private could mean either:
>> 1) private to the file (Swift 2 semantics)
>> 2) accessible only to the current type/scope and to extensions to that type 
>> that are in the current file.
>> 
>> I don’t think we’ve ever evaluated and debated approach #2 systematically.
> 
> For what it's worth:
> 
> I was opposed to SE-0025, but since I lost, I have tried to use `private` 
> wherever it made sense, rather than fighting with the language.
> 
> Sometimes, the change of keyword makes no difference. Other times, it's a 
> hassle, because I have to switch between `private` and `fileprivate` as I 
> redesign things, with little perceived benefit. I'd say the split between 
> these is about 50/50.

My experience has been the same.

> On a few occasions, I *have* genuinely appreciated the SE-0025 version of 
> `private`. These involved cases where I wanted to ensure that instance 
> variables were only manipulated in certain ways, using interfaces I had 
> specifically designed to handle them correctly. For instance, I might have 
> two parallel arrays, and I wanted to make sure that I only added or removed 
> elements from both arrays at once. I could do this with `fileprivate` by 
> splitting the type into two files, but it was more convenient to do it in one.

I generally keep one type to a file (although I make an exception as needed for 
nested types). As such, my expectation has been that someone editing the file 
is editing the type, and thus is required to understand the implementation 
details of the type. 

I don’t know of any way to have a compiler enforce that a developer understand 
what they are doing when working within an implementation. I don’t even think 
private helps as a cue to a developer that they are thinking with sensitive 
implementation details, because private and fileprivate behave so similar, and 
because fileprivate used to be private.

Generally, if I were to want to mark characteristics of a type as unsafe to 
depend on/manipulate directly, it is the properties of the type. This is 
because in swift there isn’t really a distinction between an exposed property 
and a private data field other than access level.

> 
> In these cases, switching to #2 would *completely* defeat the purpose of 
> using `private`, because the extensions would be able to directly manipulate 
> the private instance variables. I would no longer gain any benefit at all 
> from `private`. All of my uses would either fall into "makes no difference" 
> or "it's a hassle”.

My case with SE-0025 was that it should be deferred until decisions around 
submodules were made. I still think if submodules are a potential feature, they 
can impact how code is structured enough that they could have supplanted the 
need for one of private/fileprivate with a submodule-level access control. If 
submodules are a probable feature, it makes sense to make any tweaks to access 
control to be part of that feature.

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

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Vladimir.S via swift-evolution]

Inline

On 15.02.2017 18:37, Michel Fortin wrote:



Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution 
 a écrit :

On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote:

The beauty of Swift 2's access modifiers was that they were based
around files and modules, explicitly rejecting types and scopes as
units for determining visibility. It seems at base there's a group of
people who reject that decision altogether. Hence, new `private`,
proposals around `protected`, `friend`, `hidden`, `extensible`, etc.


I suppose, for those coming from an Objective-C only background, any
extra visibilities are seen as a bonus.

For those coming from a Pascal background, file-based visibility seems
more natural.

But for those of us who have used languages like C++ and C#, losing the
visibilities that we have been used to can seriously affect how we think
and design stuff.



Was surprised that you expressed exactly what I'm thinking about this subject.

I do believe even in Swift we need a way to say "only code that *knows* what it does 
should see this" and to not force us to write(and manage) the the code in same file.
Yes, some implementation details that shouldn't be used by "users" of the type, but can 
be used by "extenders" of our type. At least in the same module.

While reading, the question was raised(if was discussed, let me know pls): what 
if we extend the meaning of 'private' to 'visible to current type/scope and 
subtypes and extensions in the *same module*' ?
This will help us to split types by files, help to better model access policy 
for fields/methods(i.e. only scope that can know about details can see them) 
while 'private' still will be hidden outside of the module even for 
subclasses/extensions.

So, we'll have such situation:

"modifier" -> "can be accessed from"
---
public -> outside of the mondule
internal -> inside the module only
fileprivate -> the same file only
private -> the same type/scope, or subtype, or extension in the same module. 
I.e. some kind of 'internal' but scope-oriented.

Actually I still believe we need current 'private' and additionally some 'protected' with meaning 
"access from subtype, or extension" probably with this limitation: "only in the same 
module". But suggested extended 'private' will be also OK for me.

Thoughts?


Here's an idea in three points:

1. Return to the Swift 2 definition of `private`.
2. Introduce `scoped` to limit the visibility to within the same type, subtype, 
or extension.
3. Allow mixing the two.

So you have:

private // current file
private scoped  // current file, in the same type, subtype, or ext.
internal// current module
internal scoped // current module, in the same type, subtype, or ext.
public  // external modules
public scoped   // maybe we want that one?

Since `internal` is implied, using `scoped` alone would be equivalent to 
`internal scoped`.

Swift 3's private could be mapped to `private scoped` to achieve (almost) the 
same results and thus preserve source compatibility.



Yes, I thought that we probably need the ability to specify "at any place 
in current file"(to work from "friend" types) and "in any subtype(?) and 
extension outside of the file". But I don't actually like the suggested 
composition of modifiers, too complicated as for me.


Well.. probably I would be happy with such schema:
public/open - as currently
internal - as currently
fileprivate - as currently
private - as currently + "in any subtype or extension in the same module"
protected(or other keyword) - as fileprivate + private, i.e."in this file 
and in any subtype/extension in other files, in the same module"

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

[swift-evolution] [Accepted] SE-0152: Package Manager Tools Version

[Anders Bertelrud via swift-evolution]

Proposal Link:  
https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md

The review of SE-0152 "Package Manager Tools Version" ran from February 7 until 
February 14.  There wasn't much discussion on the mailing list, but we did 
receive some off-list feedback that was supportive.  The proposal is accepted 
for Swift 4.

Thanks to everyone who participated!

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

[swift-evolution] [Accepted] SE-0151: Package Manager Swift Language Compatibility Version

[Anders Bertelrud via swift-evolution]

Proposal Link:  
https://github.com/apple/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatibility-version.md

The review of SE-0151 "Package Manager Swift Language Compatibility Version" 
ran from February 7 until February 14.  There wasn't much discussion on the 
mailing list, but we did receive some off-list feedback that was supportive.  
The proposal is accepted for Swift 4

Thanks to everyone who participated!

- Anders
Review Manager

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

[swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

[Sadiq via swift-evolution]

Hello,

I would like to suggest to change Logical NOT Operator from ! to something
else.
It will increase the readability of the code and will avoid any confusion
with the symbol used for force unwrapping of optional values.
It would be easier for new programmers to learn Swift as the first
language.
I don't understand the rational behind using the same operator for two
different purposes.

Thanks and Regards,
Mohammad Sadiq
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Adrian Zubarev via swift-evolution]

To summarize everything, I think whenever we get submodules in Swift having a 
consistent public vs. open behavior would have a great impact when some of us 
will work on huge (team) projects.

I do not actively support the idea of @closed. I see its benefits, but first I 
need to get my head around it’s complete behavior (on all different types, on 
their members). That said I’ll be more quite on that problem. :)



-- 
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 18:09:52, Adrian Zubarev 
(adrian.zuba...@devandartist.com) schrieb:

As I already said:

To make that feature happen, we need the protocol to be public (regardless if 
you can conform to it or not).
Today you can conform to every protocol because in reality they are open today.
If we remove the property requirement from the protocol the client can conform 
it to any type and break my API by calling the subscript with a wrong type: 
document["something", NSObject()] (assuming extension NSObject : 
SubscriptParameterType).
That forces me to create a requirement for the protocol which solves the issue 
in my cases, however there might exist other issues, which could be far more 
complicated than mine is.
That also implies I have make the enum public.
Which follows by the fact that I’m creating unnecessary copy operations to wrap 
every instance that conforms to my protocol into an enum case. From internal 
API perspective I also have to unwrap the enum case.
Instead if we had consistent public vs. open behavior, I could make the 
protocol public (but-not-open), remove the requirement from it completely, 
remove the enum completely and simply cast to Int or String because as the 
author of the library I would know that the client won’t be able to conform to 
my protocol.

Importing my library will show the client only this:

extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}


-- 
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 17:50:41, Rien (r...@balancingrock.nl) schrieb:


> On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution 
>  wrote:
>
> A short example where I personally wanted a public-but-not-open protocol:
>
> public protocol SubscriptParameterType {
>
> // This property was needed to prevent the client from breaking
> // the library by conforming to the protocol, but I'd like to
> // keep it invisible for the client, or even better prevent the
> // client from conforming to the protocol.
> var parameter: Document.SubscriptParameter { get }
> }
>
> extension Document {
>
> public enum SubscriptParameter {
>
> case string(String)
> case integer(Int)
> }
> }
>
> extension String : SubscriptParameterType {
>
> public var parameter: Document.SubscriptParameter {
>
> return .string(self)
> }
> }
>
> extension Int : SubscriptParameterType {
>
> public var parameter: Document.SubscriptParameter {
>
> return .integer(self)
> }
> }
>
> // Somewhere inside the `Document` type
> public subscript(firstKey: String, parameters: SubscriptParameterType...) -> 
> Value? { … }
>
> That implementation enables more safe queries of my Document type like 
> document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than 
> document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”]

I see how that makes queries better.
However what I do not see is how making the protocol “open” would make this 
less safe.
(I do not see a reason to make it open either, but that is not the question)

It may be obvious to everyone else, but I don’t see it. Am I suffering from a 
brain freeze?.

Regards,
Rien.


> .
>

>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution 
> (swift-evolution@swift.org) schrieb:
>
>>
>>> On Feb 15, 2017, at 9:59 AM, Rien  wrote:
>>>

 On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:

>
> On Feb 15, 2017, at 9:35 AM, Rien  wrote:
>
>
>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>>  wrote:
>>
>>
>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
>>>  wrote:
>>>
>>>
 On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
  wrote:


 Our philosophy in general, however, is to default to the behavior 
 which preserves the most flexibility for the library designer.
>>>
>>> Actually, I thought the philosophy was to preserver type safety. When 
>>> did that change?
>>>
>>> Also, when was the library designer prioritised ahead of the 
>>> application developer?
>>>
>>>
 Both open and non-open classes are common, but we chose to give 
 non-open classes the `public` keyword because that's the 
 flexibility-preserving option.

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Adrian Zubarev via swift-evolution]

As I already said:

To make that feature happen, we need the protocol to be public (regardless if 
you can conform to it or not).
Today you can conform to every protocol because in reality they are open today.
If we remove the property requirement from the protocol the client can conform 
it to any type and break my API by calling the subscript with a wrong type: 
document["something", NSObject()] (assuming extension NSObject : 
SubscriptParameterType).
That forces me to create a requirement for the protocol which solves the issue 
in my cases, however there might exist other issues, which could be far more 
complicated than mine is.
That also implies I have make the enum public.
Which follows by the fact that I’m creating unnecessary copy operations to wrap 
every instance that conforms to my protocol into an enum case. From internal 
API perspective I also have to unwrap the enum case.
Instead if we had consistent public vs. open behavior, I could make the 
protocol public (but-not-open), remove the requirement from it completely, 
remove the enum completely and simply cast to Int or String because as the 
author of the library I would know that the client won’t be able to conform to 
my protocol.

Importing my library will show the client only this:

extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}


-- 
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 17:50:41, Rien (r...@balancingrock.nl) schrieb:


> On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution 
>  wrote:  
>  
> A short example where I personally wanted a public-but-not-open protocol:  
>  
> public protocol SubscriptParameterType {  
>  
> // This property was needed to prevent the client from breaking  
> // the library by conforming to the protocol, but I'd like to  
> // keep it invisible for the client, or even better prevent the  
> // client from conforming to the protocol.  
> var parameter: Document.SubscriptParameter { get }  
> }  
>  
> extension Document {  
>  
> public enum SubscriptParameter {  
>  
> case string(String)  
> case integer(Int)  
> }  
> }  
>  
> extension String : SubscriptParameterType {  
>  
> public var parameter: Document.SubscriptParameter {  
>  
> return .string(self)  
> }  
> }  
>  
> extension Int : SubscriptParameterType {  
>  
> public var parameter: Document.SubscriptParameter {  
>  
> return .integer(self)  
> }  
> }  
>  
> // Somewhere inside the `Document` type  
> public subscript(firstKey: String, parameters: SubscriptParameterType...) -> 
> Value? { … }  
>  
> That implementation enables more safe queries of my Document type like 
> document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than 
> document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”]  

I see how that makes queries better.  
However what I do not see is how making the protocol “open” would make this 
less safe.  
(I do not see a reason to make it open either, but that is not the question)  

It may be obvious to everyone else, but I don’t see it. Am I suffering from a 
brain freeze?.  

Regards,  
Rien.  


> .  
>  

>  
>  
>  
> --  
> Adrian Zubarev  
> Sent with Airmail  
>  
> Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution 
> (swift-evolution@swift.org) schrieb:  
>  
>>  
>>> On Feb 15, 2017, at 9:59 AM, Rien  wrote:  
>>>  
  
 On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:  
  
>  
> On Feb 15, 2017, at 9:35 AM, Rien  wrote:  
>  
>  
>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>>  wrote:  
>>  
>>  
>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
>>>  wrote:  
>>>  
>>>  
 On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
  wrote:  
  
  
 Our philosophy in general, however, is to default to the behavior 
 which preserves the most flexibility for the library designer.  
>>>  
>>> Actually, I thought the philosophy was to preserver type safety. When 
>>> did that change?  
>>>  
>>> Also, when was the library designer prioritised ahead of the 
>>> application developer?  
>>>  
>>>  
 Both open and non-open classes are common, but we chose to give 
 non-open classes the `public` keyword because that's the 
 flexibility-preserving option.  
>>>  
>>> No it isn’t, it’s the flexibility restricting option. The consumer of 
>>> an open class can subclass it. The consumer of a public class cannot 
>>> subclass it. How is the second more flexible than the first?  
>>  
>> It reduces complexity for the library author by allowing them to opt-out 
>> of the complexity involved in supporting 

Re: [swift-evolution] Pitch: Replacement for FileHandle

[Tony Parker via swift-evolution]

Hi Charles,

Have you happened to file a radar for Foundation that I can look up (for both 
this and process)?

We are working hard on making sure that our API is right for Swift, and areas 
like this where we can make fairly trivial improvements are things that we can 
try to prioritize. As you say, the purpose of swift-corelibs-foundation is to 
present a unified API and prevent the need to fork. That means the best 
possible solution is to improve the API in Objective-C (where 
exceptions-as-control flow is wrong too) first, and then naturally flow that 
into Swift.

Thanks,
- Tony

> On Feb 14, 2017, at 12:46 PM, Charles Srstka  wrote:
> 
>> On Feb 14, 2017, at 1:05 PM, Tony Parker > > wrote:
>> 
>> Hi Charles,
>> 
>> For both this and the Process proposal - why would we not just improve the 
>> API on the existing types instead of renaming them?
>> 
>> - Tony
> 
> 1) The Objective-C Foundation isn’t open source. It’s now 14 years since the 
> introduction of NSError, and those types still throw exceptions when they hit 
> runtime errors, despite the community consistently complaining about this 
> during the intervening decade and a half. I just don’t think it’s going to 
> happen. Those of us that asked for the change have mostly given up and 
> resigned ourselves to either writing our own file handle classes or using 
> exception handling for these things years ago (I would presume the problem is 
> backwards compatibility; there might be some legacy code out there that 
> depends on the exceptions being thrown, and that might prevent the change—an 
> issue that doesn’t exist for Swift code, since it can’t catch exceptions). 
> The Swift solution would start from code which is open-source, meaning that 
> implementation could be done by the community, without depending on the 
> Foundation team.
> 
> 2) For any changes that are made to the API for the Objective-C types, the 
> same changes will have to be made to the corelibs types anyway for 
> cross-platform source compatibility. Presumably, the unimplemented parts in 
> corelibs are going to need to be implemented as well in order for that 
> project to be complete. So why not kill two birds with one stone?
> 
> Charles
> 

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Rien via swift-evolution]

> On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> A short example where I personally wanted a public-but-not-open protocol:
> 
> public protocol SubscriptParameterType {
>  
> // This property was needed to prevent the client from breaking
> // the library by conforming to the protocol, but I'd like to  
> // keep it invisible for the client, or even better prevent the
> // client from conforming to the protocol.
> var parameter: Document.SubscriptParameter { get }
> }
> 
> extension Document {
>  
> public enum SubscriptParameter {
>  
> case string(String)
> case integer(Int)
> }
> }
> 
> extension String : SubscriptParameterType {
>  
> public var parameter: Document.SubscriptParameter {
>  
> return .string(self)
> }
> }
> 
> extension Int : SubscriptParameterType {
>  
> public var parameter: Document.SubscriptParameter {
>  
> return .integer(self)
> }
> }
> 
> // Somewhere inside the `Document` type
> public subscript(firstKey: String, parameters: SubscriptParameterType...) -> 
> Value? { … }
> 
> That implementation enables more safe queries of my Document type like 
> document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than 
> document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”]

I see how that makes queries better.
However what I do not see is how making the protocol “open” would make this 
less safe.
(I do not see a reason to make it open either, but that is not the question)

It may be obvious to everyone else, but I don’t see it. Am I suffering from a 
brain freeze?.

Regards,
Rien.


> .
> 

> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> 
>>> On Feb 15, 2017, at 9:59 AM, Rien  wrote:
>>> 
 
 On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:
 
> 
> On Feb 15, 2017, at 9:35 AM, Rien  wrote:
> 
> 
>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 
 Our philosophy in general, however, is to default to the behavior 
 which preserves the most flexibility for the library designer.
>>> 
>>> Actually, I thought the philosophy was to preserver type safety. When 
>>> did that change?
>>> 
>>> Also, when was the library designer prioritised ahead of the 
>>> application developer?
>>> 
>>> 
 Both open and non-open classes are common, but we chose to give 
 non-open classes the `public` keyword because that's the 
 flexibility-preserving option.
>>> 
>>> No it isn’t, it’s the flexibility restricting option. The consumer of 
>>> an open class can subclass it. The consumer of a public class cannot 
>>> subclass it. How is the second more flexible than the first?
>> 
>> It reduces complexity for the library author by allowing them to opt-out 
>> of the complexity involved in supporting unknown, user-defined 
>> subclasses.  It is important to allow libraries to have this 
>> flexibility. They are free to declare a class `open` if they want to 
>> allow subclassing. It’s even possibly for a library to declare all 
>> classes `open` if it wishes to do so.  But *requiring* that would reduce 
>> the design space libraries are allowed to explore and / or introduce 
>> fragility by moving the subclass restriction to a comment.
>> 
> 
> Why would a library author want to prohibit subclasses?
> A library user can always wrap the class and subclass the wrapper.
 
 This is composition, not inheritance.  The most important difference is 
 that a wrapper cannot override methods, it can only wrap and / or forward 
 them.  This means that when the superclass calls a method on `self` that 
 method *always* invokes its version of that method rather than a subclass 
 override.  This is a very important difference.
 
>>> 
>>> Agreed, however that does not answer the question why would a library 
>>> developer want to disallow subclassing?
>>> I do not see a use case for that. I.e. a feature that cannot be implemented 
>>> without it. (without “open”)
>> 
>> The feature it enables is more robust libraries and the ability for library 
>> authors to better reason about their code.  You may not find this benefit 
>> enough to be worth a language feature, but many of us do.
>> 
>>> 
>>> Rien.
>>> 

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 15, 2017, at 10:35 AM, Rien  wrote:
> 
>> 
>> On 15 Feb 2017, at 17:02, Matthew Johnson  wrote:
>> 
>>> 
>>> On Feb 15, 2017, at 9:59 AM, Rien  wrote:
>>> 
 
 On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:
 
> 
> On Feb 15, 2017, at 9:35 AM, Rien  wrote:
> 
> 
>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 
 Our philosophy in general, however, is to default to the behavior 
 which preserves the most flexibility for the library designer.
>>> 
>>> Actually, I thought the philosophy was to preserver type safety. When 
>>> did that change?
>>> 
>>> Also, when was the library designer prioritised ahead of the 
>>> application developer?
>>> 
>>> 
 Both open and non-open classes are common, but we chose to give 
 non-open classes the `public` keyword because that's the 
 flexibility-preserving option.
>>> 
>>> No it isn’t, it’s the flexibility restricting option. The consumer of 
>>> an open class can subclass it. The consumer of a public class cannot 
>>> subclass it. How is the second more flexible than the first?
>> 
>> It reduces complexity for the library author by allowing them to opt-out 
>> of the complexity involved in supporting unknown, user-defined 
>> subclasses.  It is important to allow libraries to have this 
>> flexibility. They are free to declare a class `open` if they want to 
>> allow subclassing. It’s even possibly for a library to declare all 
>> classes `open` if it wishes to do so.  But *requiring* that would reduce 
>> the design space libraries are allowed to explore and / or introduce 
>> fragility by moving the subclass restriction to a comment.
>> 
> 
> Why would a library author want to prohibit subclasses?
> A library user can always wrap the class and subclass the wrapper.
 
 This is composition, not inheritance.  The most important difference is 
 that a wrapper cannot override methods, it can only wrap and / or forward 
 them.  This means that when the superclass calls a method on `self` that 
 method *always* invokes its version of that method rather than a subclass 
 override.  This is a very important difference.
 
>>> 
>>> Agreed, however that does not answer the question why would a library 
>>> developer want to disallow subclassing?
>>> I do not see a use case for that. I.e. a feature that cannot be implemented 
>>> without it. (without “open”)
>> 
>> The feature it enables is more robust libraries and the ability for library 
>> authors to better reason about their code.  You may not find this benefit 
>> enough to be worth a language feature, but many of us do.
> 
> You start of with a claim “more robust libraries”.
> I would really like to know the “how” of that. How does it make a library 
> more robust?
> 
> I do write libraries myself, and if there is something I am missing, I very 
> much would like to know.

This topic was well explored during the discussion and review of the proposal 
that introduced `open`.  If you would really like to know I suggest you take 
some time to read through that discussion.

> 
> Regards,
> Rien.
> 
>> 
>>> 
>>> Rien.
>>> 
> 
> There are cases where subclassing does not make sense. And thus 
> preventing subclasses adds information for those users that don’t RTFM. 
> But that imo is not worth the impact extra complexity places on all other 
> users.
> 
> Rien.
> 
>>> 
>>> 
>>> ___
>>> 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] Simplifying Access Using 'Hidden'

[Michel Fortin via swift-evolution]

> Le 15 févr. 2017 à 10:52, Matthew Johnson  a écrit :
> 
> 
>> On Feb 15, 2017, at 9:37 AM, Michel Fortin via swift-evolution 
>>  wrote:
>> 
>> 
>>> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution 
>>>  a écrit :
>>> 
>>> On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote:
> The beauty of Swift 2's access modifiers was that they were based
> around files and modules, explicitly rejecting types and scopes as
> units for determining visibility. It seems at base there's a group of
> people who reject that decision altogether. Hence, new `private`,
> proposals around `protected`, `friend`, `hidden`, `extensible`, etc.
 
 I suppose, for those coming from an Objective-C only background, any
 extra visibilities are seen as a bonus.
 
 For those coming from a Pascal background, file-based visibility seems
 more natural.
 
 But for those of us who have used languages like C++ and C#, losing the
 visibilities that we have been used to can seriously affect how we think
 and design stuff.
 
>>> 
>>> Was surprised that you expressed exactly what I'm thinking about this 
>>> subject.
>>> 
>>> I do believe even in Swift we need a way to say "only code that *knows* 
>>> what it does should see this" and to not force us to write(and manage) the 
>>> the code in same file.
>>> Yes, some implementation details that shouldn't be used by "users" of the 
>>> type, but can be used by "extenders" of our type. At least in the same 
>>> module.
>>> 
>>> While reading, the question was raised(if was discussed, let me know pls): 
>>> what if we extend the meaning of 'private' to 'visible to current 
>>> type/scope and subtypes and extensions in the *same module*' ?
>>> This will help us to split types by files, help to better model access 
>>> policy for fields/methods(i.e. only scope that can know about details can 
>>> see them) while 'private' still will be hidden outside of the module even 
>>> for subclasses/extensions.
>>> 
>>> So, we'll have such situation:
>>> 
>>> "modifier" -> "can be accessed from"
>>> ---
>>> public -> outside of the mondule
>>> internal -> inside the module only
>>> fileprivate -> the same file only
>>> private -> the same type/scope, or subtype, or extension in the same 
>>> module. I.e. some kind of 'internal' but scope-oriented.
>>> 
>>> Actually I still believe we need current 'private' and additionally some 
>>> 'protected' with meaning "access from subtype, or extension" probably with 
>>> this limitation: "only in the same module". But suggested extended 
>>> 'private' will be also OK for me.
>>> 
>>> Thoughts?
>> 
>> Here's an idea in three points:
>> 
>> 1. Return to the Swift 2 definition of `private`.
>> 2. Introduce `scoped` to limit the visibility to within the same type, 
>> subtype, or extension.
>> 3. Allow mixing the two.
>> 
>> So you have:
>> 
>>  private // current file
>>  private scoped  // current file, in the same type, subtype, or ext.
>>  internal// current module
>>  internal scoped // current module, in the same type, subtype, or ext.
>>  public  // external modules
>>  public scoped   // maybe we want that one?
>> 
>> Since `internal` is implied, using `scoped` alone would be equivalent to 
>> `internal scoped`.
>> 
>> Swift 3's private could be mapped to `private scoped` to achieve (almost) 
>> the same results and thus preserve source compatibility.
> 
> This definition of `scoped` is actually much different than the current 
> `private` which restricts visibility to the *current* scope.  Your definition 
> allows visibility in an unlimited number of scopes that just happen to be of 
> the same type.  I don’t think `scoped` is a good name for this.  

I was using the definition of `private` from Vladimir.S's post quoted above 
because this is basically an extension of his idea. You're right that `scoped` 
might not be the best word for this.

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Rien via swift-evolution]

> On 15 Feb 2017, at 17:02, Matthew Johnson  wrote:
> 
>> 
>> On Feb 15, 2017, at 9:59 AM, Rien  wrote:
>> 
>>> 
>>> On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:
>>> 
 
 On Feb 15, 2017, at 9:35 AM, Rien  wrote:
 
 
> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Our philosophy in general, however, is to default to the behavior which 
>>> preserves the most flexibility for the library designer.
>> 
>> Actually, I thought the philosophy was to preserver type safety. When 
>> did that change?
>> 
>> Also, when was the library designer prioritised ahead of the application 
>> developer?
>> 
>> 
>>> Both open and non-open classes are common, but we chose to give 
>>> non-open classes the `public` keyword because that's the 
>>> flexibility-preserving option.
>> 
>> No it isn’t, it’s the flexibility restricting option. The consumer of an 
>> open class can subclass it. The consumer of a public class cannot 
>> subclass it. How is the second more flexible than the first?
> 
> It reduces complexity for the library author by allowing them to opt-out 
> of the complexity involved in supporting unknown, user-defined 
> subclasses.  It is important to allow libraries to have this flexibility. 
> They are free to declare a class `open` if they want to allow 
> subclassing. It’s even possibly for a library to declare all classes 
> `open` if it wishes to do so.  But *requiring* that would reduce the 
> design space libraries are allowed to explore and / or introduce 
> fragility by moving the subclass restriction to a comment.
> 
 
 Why would a library author want to prohibit subclasses?
 A library user can always wrap the class and subclass the wrapper.
>>> 
>>> This is composition, not inheritance.  The most important difference is 
>>> that a wrapper cannot override methods, it can only wrap and / or forward 
>>> them.  This means that when the superclass calls a method on `self` that 
>>> method *always* invokes its version of that method rather than a subclass 
>>> override.  This is a very important difference.
>>> 
>> 
>> Agreed, however that does not answer the question why would a library 
>> developer want to disallow subclassing?
>> I do not see a use case for that. I.e. a feature that cannot be implemented 
>> without it. (without “open”)
> 
> The feature it enables is more robust libraries and the ability for library 
> authors to better reason about their code.  You may not find this benefit 
> enough to be worth a language feature, but many of us do.

You start of with a claim “more robust libraries”.
I would really like to know the “how” of that. How does it make a library more 
robust?

I do write libraries myself, and if there is something I am missing, I very 
much would like to know.

Regards,
Rien.

> 
>> 
>> Rien.
>> 
 
 There are cases where subclassing does not make sense. And thus preventing 
 subclasses adds information for those users that don’t RTFM. But that imo 
 is not worth the impact extra complexity places on all other users.
 
 Rien.
 
>> 
>> 
>> ___
>> 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] [Pitch] consistent public access modifiers

[Adrian Zubarev via swift-evolution]

A short example where I personally wanted a public-but-not-open protocol:

public protocol SubscriptParameterType {
 
// This property was needed to prevent the client from breaking
// the library by conforming to the protocol, but I'd like to  
// keep it invisible for the client, or even better prevent the
// client from conforming to the protocol.
var parameter: Document.SubscriptParameter { get }
}

extension Document {
 
public enum SubscriptParameter {
 
case string(String)
case integer(Int)
}
}

extension String : SubscriptParameterType {
 
public var parameter: Document.SubscriptParameter {
 
return .string(self)
}
}

extension Int : SubscriptParameterType {
 
public var parameter: Document.SubscriptParameter {
 
return .integer(self)
}
}

// Somewhere inside the `Document` type
public subscript(firstKey: String, parameters: SubscriptParameterType...) -> 
Value? { … }
That implementation enables more safe queries of my Document type like 
document["key1", intIndexInstance, stringKeyInstance, 10, "key"] rather than 
document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key"].



-- 
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 17:03:32, Matthew Johnson via swift-evolution 
(swift-evolution@swift.org) schrieb:


On Feb 15, 2017, at 9:59 AM, Rien  wrote:


On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:


On Feb 15, 2017, at 9:35 AM, Rien  wrote:


On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
 wrote:


On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
 wrote:


On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
 wrote:


Our philosophy in general, however, is to default to the behavior which 
preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that 
change?

Also, when was the library designer prioritised ahead of the application 
developer?


Both open and non-open classes are common, but we chose to give non-open 
classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open 
class can subclass it. The consumer of a public class cannot subclass it. How 
is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the 
complexity involved in supporting unknown, user-defined subclasses.  It is 
important to allow libraries to have this flexibility. They are free to declare 
a class `open` if they want to allow subclassing. It’s even possibly for a 
library to declare all classes `open` if it wishes to do so.  But *requiring* 
that would reduce the design space libraries are allowed to explore and / or 
introduce fragility by moving the subclass restriction to a comment.


Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance.  The most important difference is that a 
wrapper cannot override methods, it can only wrap and / or forward them.  This 
means that when the superclass calls a method on `self` that method *always* 
invokes its version of that method rather than a subclass override.  This is a 
very important difference.


Agreed, however that does not answer the question why would a library developer 
want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented 
without it. (without “open”)

The feature it enables is more robust libraries and the ability for library 
authors to better reason about their code.  You may not find this benefit 
enough to be worth a language feature, but many of us do.


Rien.


There are cases where subclassing does not make sense. And thus preventing 
subclasses adds information for those users that don’t RTFM. But that imo is 
not worth the impact extra complexity places on all other users.

Rien.



___
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] Rules for structs default/memberwise initializers

[Dimitri Racordon via swift-evolution]

Thanks Matthew.

That’s a quite elaborated proposal!
I’ll be sure to keep an eye on it as we move forward.

Dimitri



On 15 Feb 2017, at 16:57, Matthew Johnson 
> wrote:

Hi Dimitri,

You may be interested in taking a look at a proposal I introduced about a year 
ago which was deferred.  Memberwise initialization is a topic we intend to 
revisit eventually.  This may happen in phase 2 of the Swift 4 effort, or may 
not happen until Swift 5.

https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md

Matthew

On Feb 15, 2017, at 9:38 AM, Dimitri Racordon via swift-evolution 
> wrote:

Hello community!

While writing a Swift introduction tutorial for students, I’ve been stumbling 
upon the rules for struct default and memberwise initializers.
I failed to find explanations in Apple’s language guide, but as far as I could 
observe, I think the rules don’t fit interesting use-cases.

Here are the cases that I was able to identify (I hope you don’t mind 
millennials and their obligatory Pokemon references):

First, as documented in Apple’s guide, structs that doesn’t define any 
initializer and have no default values receive a memberwise initializer:

typealias Species = (number: Int, name: String)

struct Pokemon {
let species: Species
var level: Int
var nickname: String
}

let bulby = Pokemon(species: (001, "Bulbasaur"), level: 1, nickname: "bulby")

Structs that define a default value for all their properties receive a default 
initializer:

struct Pokemon {
let species: Species = (001, "Bulbasaur")
var level: Int = 1
var nickname: String = "bulby"
}

let bulby = Pokemon()

Now digging a bit deeper, I noticed that they also seem to receive an 
initializer for their non-constant properties:

let bulby = Pokemon(level: 1, nickname: "bulby")

If no value is provided for one (or several) of its variable properties, they 
receives an initializer for all their variable properties:

struct Pokemon {
let species: Species = (001, "Bulbasaur")
var level: Int = 1
var nickname: String
}

let bulby = Pokemon(level: 1, nickname: "bulby")

Finally, if they're given a default value for their variable properties but not 
for their constant properties, they receive the full memberwise initializer 
only:

struct Pokemon {
let species: Species
var level: Int = 1
var nickname: String = "bulby"
}

let bulby = Pokemon(species: (001, "Bulbasaur"), level: 1, nickname: "bulby")

If the two extreme cases sounds perfectly valid to me (no default value vs all 
default values), the mixed situations do not.
In particular, it seems strange that a struct without a default value for its 
constant property, but one for all its variable properties receives the 
memberwise initializer only. I guess that would be a common “mixed situation” 
case, yet the provided initializer is actually useless.

Receiving the full memberwise initializer is fine, but I would also expect to 
receive some kind of "partial memberwise” initializer for all properties 
(constants or variables) that are not defined:

struct Pokemon {
let species: Species
var level: Int = 1
var nickname: String = "bulby"
}

let bulby = Pokemon(species: (001, "Bulbasaur”))
print(bulby)
// Prints "Pokemon(species: (1, "Bulbasaur"), level: 1, nickname: "bulby")"

Besides, that would avoid some tedious initializer definitions. Indeed, If I 
want to get the desired result, I have to write this kind of initializer:

struct Pokemon {
let species: Species
var level: Int = 1
var nickname: String = "bulby"

init(species: Species, level: Int? = nil, nickname: String? = nil) {
self.species = species

if level != nil {
self.level = level!
}

if nickname != nil {
self.nickname = nickname!
}
}
}

In addition to be rather wordy, it arguably destroys the purpose of defining a 
default value for variable properties in the first place, since imho this 
approach is clearer (unless maybe for some more complicated structs with 
multiple layers of initializer delegation):

struct Pokemon {
let species: Species
var level: Int
var nickname: String

init(species: Species, level: Int = 1, nickname: String = "bulby") {
self.species = species
self.level = level
self.nickname = nickname
}
}

Thanks.

Dimitri Racordon

___
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] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 15, 2017, at 9:59 AM, Rien  wrote:
> 
>> 
>> On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:
>> 
>>> 
>>> On Feb 15, 2017, at 9:35 AM, Rien  wrote:
>>> 
>>> 
 On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
  wrote:
 
 
> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
> 
>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> 
>> Our philosophy in general, however, is to default to the behavior which 
>> preserves the most flexibility for the library designer.
> 
> Actually, I thought the philosophy was to preserver type safety. When did 
> that change?
> 
> Also, when was the library designer prioritised ahead of the application 
> developer?
> 
> 
>> Both open and non-open classes are common, but we chose to give non-open 
>> classes the `public` keyword because that's the flexibility-preserving 
>> option.
> 
> No it isn’t, it’s the flexibility restricting option. The consumer of an 
> open class can subclass it. The consumer of a public class cannot 
> subclass it. How is the second more flexible than the first?
 
 It reduces complexity for the library author by allowing them to opt-out 
 of the complexity involved in supporting unknown, user-defined subclasses. 
  It is important to allow libraries to have this flexibility. They are 
 free to declare a class `open` if they want to allow subclassing. It’s 
 even possibly for a library to declare all classes `open` if it wishes to 
 do so.  But *requiring* that would reduce the design space libraries are 
 allowed to explore and / or introduce fragility by moving the subclass 
 restriction to a comment.
 
>>> 
>>> Why would a library author want to prohibit subclasses?
>>> A library user can always wrap the class and subclass the wrapper.
>> 
>> This is composition, not inheritance.  The most important difference is that 
>> a wrapper cannot override methods, it can only wrap and / or forward them.  
>> This means that when the superclass calls a method on `self` that method 
>> *always* invokes its version of that method rather than a subclass override. 
>>  This is a very important difference.
>> 
> 
> Agreed, however that does not answer the question why would a library 
> developer want to disallow subclassing?
> I do not see a use case for that. I.e. a feature that cannot be implemented 
> without it. (without “open”)

The feature it enables is more robust libraries and the ability for library 
authors to better reason about their code.  You may not find this benefit 
enough to be worth a language feature, but many of us do.

> 
> Rien.
> 
>>> 
>>> There are cases where subclassing does not make sense. And thus preventing 
>>> subclasses adds information for those users that don’t RTFM. But that imo 
>>> is not worth the impact extra complexity places on all other users.
>>> 
>>> Rien.
>>> 
> 
> 
> ___
> 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] [Pitch] consistent public access modifiers

[Rien via swift-evolution]

> On 15 Feb 2017, at 16:45, Matthew Johnson  wrote:
> 
>> 
>> On Feb 15, 2017, at 9:35 AM, Rien  wrote:
>> 
>> 
>>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
  wrote:
 
 
> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> 
> Our philosophy in general, however, is to default to the behavior which 
> preserves the most flexibility for the library designer.
 
 Actually, I thought the philosophy was to preserver type safety. When did 
 that change?
 
 Also, when was the library designer prioritised ahead of the application 
 developer?
 
 
> Both open and non-open classes are common, but we chose to give non-open 
> classes the `public` keyword because that's the flexibility-preserving 
> option.
 
 No it isn’t, it’s the flexibility restricting option. The consumer of an 
 open class can subclass it. The consumer of a public class cannot subclass 
 it. How is the second more flexible than the first?
>>> 
>>> It reduces complexity for the library author by allowing them to opt-out of 
>>> the complexity involved in supporting unknown, user-defined subclasses.  It 
>>> is important to allow libraries to have this flexibility. They are free to 
>>> declare a class `open` if they want to allow subclassing.  It’s even 
>>> possibly for a library to declare all classes `open` if it wishes to do so. 
>>>  But *requiring* that would reduce the design space libraries are allowed 
>>> to explore and / or introduce fragility by moving the subclass restriction 
>>> to a comment.
>>> 
>> 
>> Why would a library author want to prohibit subclasses?
>> A library user can always wrap the class and subclass the wrapper.
> 
> This is composition, not inheritance.  The most important difference is that 
> a wrapper cannot override methods, it can only wrap and / or forward them.  
> This means that when the superclass calls a method on `self` that method 
> *always* invokes its version of that method rather than a subclass override.  
> This is a very important difference.
> 

Agreed, however that does not answer the question why would a library developer 
want to disallow subclassing?
I do not see a use case for that. I.e. a feature that cannot be implemented 
without it. (without “open”)

Rien.

>> 
>> There are cases where subclassing does not make sense. And thus preventing 
>> subclasses adds information for those users that don’t RTFM. But that imo is 
>> not worth the impact extra complexity places on all other users.
>> 
>> Rien.
>> 
 
 
 ___
 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] Rules for structs default/memberwise initializers

[Matthew Johnson via swift-evolution]

Hi Dimitri,

You may be interested in taking a look at a proposal I introduced about a year 
ago which was deferred.  Memberwise initialization is a topic we intend to 
revisit eventually.  This may happen in phase 2 of the Swift 4 effort, or may 
not happen until Swift 5.

https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md

Matthew

> On Feb 15, 2017, at 9:38 AM, Dimitri Racordon via swift-evolution 
>  wrote:
> 
> Hello community!
> 
> While writing a Swift introduction tutorial for students, I’ve been stumbling 
> upon the rules for struct default and memberwise initializers.
> I failed to find explanations in Apple’s language guide, but as far as I 
> could observe, I think the rules don’t fit interesting use-cases.
> 
> Here are the cases that I was able to identify (I hope you don’t mind 
> millennials and their obligatory Pokemon references):
> 
> First, as documented in Apple’s guide, structs that doesn’t define any 
> initializer and have no default values receive a memberwise initializer:
> 
> typealias Species = (number: Int, name: String)
> 
> struct Pokemon {
> let species: Species
> var level: Int
> var nickname: String
> }
> 
> let bulby = Pokemon(species: (001, "Bulbasaur"), level: 1, nickname: "bulby")
> 
> Structs that define a default value for all their properties receive a 
> default initializer:
> 
> struct Pokemon {
> let species: Species = (001, "Bulbasaur")
> var level: Int = 1
> var nickname: String = "bulby"
> }
> 
> let bulby = Pokemon()
> 
> Now digging a bit deeper, I noticed that they also seem to receive an 
> initializer for their non-constant properties:
> 
> let bulby = Pokemon(level: 1, nickname: "bulby")
> 
> If no value is provided for one (or several) of its variable properties, they 
> receives an initializer for all their variable properties:
> 
> struct Pokemon {
> let species: Species = (001, "Bulbasaur")
> var level: Int = 1
> var nickname: String
> }
> 
> let bulby = Pokemon(level: 1, nickname: "bulby")
> 
> Finally, if they're given a default value for their variable properties but 
> not for their constant properties, they receive the full memberwise 
> initializer only:
> 
> struct Pokemon {
> let species: Species
> var level: Int = 1
> var nickname: String = "bulby"
> }
> 
> let bulby = Pokemon(species: (001, "Bulbasaur"), level: 1, nickname: "bulby")
> 
> If the two extreme cases sounds perfectly valid to me (no default value vs 
> all default values), the mixed situations do not.
> In particular, it seems strange that a struct without a default value for its 
> constant property, but one for all its variable properties receives the 
> memberwise initializer only. I guess that would be a common “mixed situation” 
> case, yet the provided initializer is actually useless.
> 
> Receiving the full memberwise initializer is fine, but I would also expect to 
> receive some kind of "partial memberwise” initializer for all properties 
> (constants or variables) that are not defined:
> 
> struct Pokemon {
> let species: Species
> var level: Int = 1
> var nickname: String = "bulby"
> }
> 
> let bulby = Pokemon(species: (001, "Bulbasaur”))
> print(bulby)
> // Prints "Pokemon(species: (1, "Bulbasaur"), level: 1, nickname: "bulby")"
> 
> Besides, that would avoid some tedious initializer definitions. Indeed, If I 
> want to get the desired result, I have to write this kind of initializer:
> 
> struct Pokemon {
> let species: Species
> var level: Int = 1
> var nickname: String = "bulby"
> 
> init(species: Species, level: Int? = nil, nickname: String? = nil) {
> self.species = species
> 
> if level != nil {
> self.level = level!
> }
> 
> if nickname != nil {
> self.nickname = nickname!
> }
> }
> }
> 
> In addition to be rather wordy, it arguably destroys the purpose of defining 
> a default value for variable properties in the first place, since imho this 
> approach is clearer (unless maybe for some more complicated structs with 
> multiple layers of initializer delegation):
> 
> struct Pokemon {
> let species: Species
> var level: Int
> var nickname: String
> 
> init(species: Species, level: Int = 1, nickname: String = "bulby") {
> self.species = species
> self.level = level
> self.nickname = nickname
> }
> }
> 
> Thanks.
> 
> Dimitri Racordon
> 
> ___
> 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] Simplifying Access Using 'Hidden'

[Matthew Johnson via swift-evolution]

> On Feb 15, 2017, at 9:37 AM, Michel Fortin via swift-evolution 
>  wrote:
> 
> 
>> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution 
>>  a écrit :
>> 
>> On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote:
 The beauty of Swift 2's access modifiers was that they were based
 around files and modules, explicitly rejecting types and scopes as
 units for determining visibility. It seems at base there's a group of
 people who reject that decision altogether. Hence, new `private`,
 proposals around `protected`, `friend`, `hidden`, `extensible`, etc.
>>> 
>>> I suppose, for those coming from an Objective-C only background, any
>>> extra visibilities are seen as a bonus.
>>> 
>>> For those coming from a Pascal background, file-based visibility seems
>>> more natural.
>>> 
>>> But for those of us who have used languages like C++ and C#, losing the
>>> visibilities that we have been used to can seriously affect how we think
>>> and design stuff.
>>> 
>> 
>> Was surprised that you expressed exactly what I'm thinking about this 
>> subject.
>> 
>> I do believe even in Swift we need a way to say "only code that *knows* what 
>> it does should see this" and to not force us to write(and manage) the the 
>> code in same file.
>> Yes, some implementation details that shouldn't be used by "users" of the 
>> type, but can be used by "extenders" of our type. At least in the same 
>> module.
>> 
>> While reading, the question was raised(if was discussed, let me know pls): 
>> what if we extend the meaning of 'private' to 'visible to current type/scope 
>> and subtypes and extensions in the *same module*' ?
>> This will help us to split types by files, help to better model access 
>> policy for fields/methods(i.e. only scope that can know about details can 
>> see them) while 'private' still will be hidden outside of the module even 
>> for subclasses/extensions.
>> 
>> So, we'll have such situation:
>> 
>> "modifier" -> "can be accessed from"
>> ---
>> public -> outside of the mondule
>> internal -> inside the module only
>> fileprivate -> the same file only
>> private -> the same type/scope, or subtype, or extension in the same module. 
>> I.e. some kind of 'internal' but scope-oriented.
>> 
>> Actually I still believe we need current 'private' and additionally some 
>> 'protected' with meaning "access from subtype, or extension" probably with 
>> this limitation: "only in the same module". But suggested extended 'private' 
>> will be also OK for me.
>> 
>> Thoughts?
> 
> Here's an idea in three points:
> 
> 1. Return to the Swift 2 definition of `private`.
> 2. Introduce `scoped` to limit the visibility to within the same type, 
> subtype, or extension.
> 3. Allow mixing the two.
> 
> So you have:
> 
>   private // current file
>   private scoped  // current file, in the same type, subtype, or ext.
>   internal// current module
>   internal scoped // current module, in the same type, subtype, or ext.
>   public  // external modules
>   public scoped   // maybe we want that one?
> 
> Since `internal` is implied, using `scoped` alone would be equivalent to 
> `internal scoped`.
> 
> Swift 3's private could be mapped to `private scoped` to achieve (almost) the 
> same results and thus preserve source compatibility.

This definition of `scoped` is actually much different than the current 
`private` which restricts visibility to the *current* scope.  Your definition 
allows visibility in an unlimited number of scopes that just happen to be of 
the same type.  I don’t think `scoped` is a good name for this.  

`private(type)` would be a better name if we were going to make this a 
modification of the existing access modifiers.  However, I don’t think this is 
the right direction.  If we’re going to have an access modifier that means “in 
the same file *and* the same type” I think that should simply be called 
`private` (a “soft default”).  If we’re going to have something between 
`internal` and `fileprivate` I think it would be better to explore submodules 
than introduce something like `internal(type)`.

> 
> -- 
> Michel Fortin
> https://michelf.ca
> 
> ___
> 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] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 15, 2017, at 9:35 AM, Rien  wrote:
> 
> 
>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 
 Our philosophy in general, however, is to default to the behavior which 
 preserves the most flexibility for the library designer.
>>> 
>>> Actually, I thought the philosophy was to preserver type safety. When did 
>>> that change?
>>> 
>>> Also, when was the library designer prioritised ahead of the application 
>>> developer?
>>> 
>>> 
 Both open and non-open classes are common, but we chose to give non-open 
 classes the `public` keyword because that's the flexibility-preserving 
 option.
>>> 
>>> No it isn’t, it’s the flexibility restricting option. The consumer of an 
>>> open class can subclass it. The consumer of a public class cannot subclass 
>>> it. How is the second more flexible than the first?
>> 
>> It reduces complexity for the library author by allowing them to opt-out of 
>> the complexity involved in supporting unknown, user-defined subclasses.  It 
>> is important to allow libraries to have this flexibility.  They are free to 
>> declare a class `open` if they want to allow subclassing.  It’s even 
>> possibly for a library to declare all classes `open` if it wishes to do so.  
>> But *requiring* that would reduce the design space libraries are allowed to 
>> explore and / or introduce fragility by moving the subclass restriction to a 
>> comment.
>> 
> 
> Why would a library author want to prohibit subclasses?
> A library user can always wrap the class and subclass the wrapper.

This is composition, not inheritance.  The most important difference is that a 
wrapper cannot override methods, it can only wrap and / or forward them.  This 
means that when the superclass calls a method on `self` that method *always* 
invokes its version of that method rather than a subclass override.  This is a 
very important difference.

> 
> There are cases where subclassing does not make sense. And thus preventing 
> subclasses adds information for those users that don’t RTFM. But that imo is 
> not worth the impact extra complexity places on all other users.
> 
> Rien.
> 
>>> 
>>> 
>>> ___
>>> 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] final + lazy + fileprivate modifiers

[T.J. Usiyan via swift-evolution]

"Either keep it or drop it, but don't keep fiddling with it." sums up my
position well.

On Wed, Feb 15, 2017 at 7:00 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Keeping with the spirit of Swift and staying consistent with its design,
> I see two plausible meanings for private:
> >
> > Private could mean either:
> > 1) private to the file (Swift 2 semantics)
> > 2) accessible only to the current type/scope and to extensions to that
> type that are in the current file.
> >
> > I don’t think we’ve ever evaluated and debated approach #2
> systematically.
>
> For what it's worth:
>
> I was opposed to SE-0025, but since I lost, I have tried to use `private`
> wherever it made sense, rather than fighting with the language.
>
> Sometimes, the change of keyword makes no difference. Other times, it's a
> hassle, because I have to switch between `private` and `fileprivate` as I
> redesign things, with little perceived benefit. I'd say the split between
> these is about 50/50.
>
> On a few occasions, I *have* genuinely appreciated the SE-0025 version of
> `private`. These involved cases where I wanted to ensure that instance
> variables were only manipulated in certain ways, using interfaces I had
> specifically designed to handle them correctly. For instance, I might have
> two parallel arrays, and I wanted to make sure that I only added or removed
> elements from both arrays at once. I could do this with `fileprivate` by
> splitting the type into two files, but it was more convenient to do it in
> one.
>
> In these cases, switching to #2 would *completely* defeat the purpose of
> using `private`, because the extensions would be able to directly
> manipulate the private instance variables. I would no longer gain any
> benefit at all from `private`. All of my uses would either fall into "makes
> no difference" or "it's a hassle".
>
> I do not support the idea of changing `private` to mean #2. Doing so would
> eliminate the few decent use cases I've found for `private`. Either keep it
> or drop it, but don't keep fiddling with it.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> 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] Simplifying Access Using 'Hidden'

[Michel Fortin via swift-evolution]

> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution 
>  a écrit :
> 
> On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote:
>>> The beauty of Swift 2's access modifiers was that they were based
>>> around files and modules, explicitly rejecting types and scopes as
>>> units for determining visibility. It seems at base there's a group of
>>> people who reject that decision altogether. Hence, new `private`,
>>> proposals around `protected`, `friend`, `hidden`, `extensible`, etc.
>> 
>> I suppose, for those coming from an Objective-C only background, any
>> extra visibilities are seen as a bonus.
>> 
>> For those coming from a Pascal background, file-based visibility seems
>> more natural.
>> 
>> But for those of us who have used languages like C++ and C#, losing the
>> visibilities that we have been used to can seriously affect how we think
>> and design stuff.
>> 
> 
> Was surprised that you expressed exactly what I'm thinking about this subject.
> 
> I do believe even in Swift we need a way to say "only code that *knows* what 
> it does should see this" and to not force us to write(and manage) the the 
> code in same file.
> Yes, some implementation details that shouldn't be used by "users" of the 
> type, but can be used by "extenders" of our type. At least in the same module.
> 
> While reading, the question was raised(if was discussed, let me know pls): 
> what if we extend the meaning of 'private' to 'visible to current type/scope 
> and subtypes and extensions in the *same module*' ?
> This will help us to split types by files, help to better model access policy 
> for fields/methods(i.e. only scope that can know about details can see them) 
> while 'private' still will be hidden outside of the module even for 
> subclasses/extensions.
> 
> So, we'll have such situation:
> 
> "modifier" -> "can be accessed from"
> ---
> public -> outside of the mondule
> internal -> inside the module only
> fileprivate -> the same file only
> private -> the same type/scope, or subtype, or extension in the same module. 
> I.e. some kind of 'internal' but scope-oriented.
> 
> Actually I still believe we need current 'private' and additionally some 
> 'protected' with meaning "access from subtype, or extension" probably with 
> this limitation: "only in the same module". But suggested extended 'private' 
> will be also OK for me.
> 
> Thoughts?

Here's an idea in three points:

1. Return to the Swift 2 definition of `private`.
2. Introduce `scoped` to limit the visibility to within the same type, subtype, 
or extension.
3. Allow mixing the two.

So you have:

private // current file
private scoped  // current file, in the same type, subtype, or ext.
internal// current module
internal scoped // current module, in the same type, subtype, or ext.
public  // external modules
public scoped   // maybe we want that one?

Since `internal` is implied, using `scoped` alone would be equivalent to 
`internal scoped`.

Swift 3's private could be mapped to `private scoped` to achieve (almost) the 
same results and thus preserve source compatibility.

-- 
Michel Fortin
https://michelf.ca

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

[swift-evolution] Rules for structs default/memberwise initializers

[Dimitri Racordon via swift-evolution]

Hello community!

While writing a Swift introduction tutorial for students, I’ve been stumbling 
upon the rules for struct default and memberwise initializers.
I failed to find explanations in Apple’s language guide, but as far as I could 
observe, I think the rules don’t fit interesting use-cases.

Here are the cases that I was able to identify (I hope you don’t mind 
millennials and their obligatory Pokemon references):

First, as documented in Apple’s guide, structs that doesn’t define any 
initializer and have no default values receive a memberwise initializer:

typealias Species = (number: Int, name: String)

struct Pokemon {
let species: Species
var level: Int
var nickname: String
}

let bulby = Pokemon(species: (001, "Bulbasaur"), level: 1, nickname: "bulby")

Structs that define a default value for all their properties receive a default 
initializer:

struct Pokemon {
let species: Species = (001, "Bulbasaur")
var level: Int = 1
var nickname: String = "bulby"
}

let bulby = Pokemon()

Now digging a bit deeper, I noticed that they also seem to receive an 
initializer for their non-constant properties:

let bulby = Pokemon(level: 1, nickname: "bulby")

If no value is provided for one (or several) of its variable properties, they 
receives an initializer for all their variable properties:

struct Pokemon {
let species: Species = (001, "Bulbasaur")
var level: Int = 1
var nickname: String
}

let bulby = Pokemon(level: 1, nickname: "bulby")

Finally, if they're given a default value for their variable properties but not 
for their constant properties, they receive the full memberwise initializer 
only:

struct Pokemon {
let species: Species
var level: Int = 1
var nickname: String = "bulby"
}

let bulby = Pokemon(species: (001, "Bulbasaur"), level: 1, nickname: "bulby")

If the two extreme cases sounds perfectly valid to me (no default value vs all 
default values), the mixed situations do not.
In particular, it seems strange that a struct without a default value for its 
constant property, but one for all its variable properties receives the 
memberwise initializer only. I guess that would be a common “mixed situation” 
case, yet the provided initializer is actually useless.

Receiving the full memberwise initializer is fine, but I would also expect to 
receive some kind of "partial memberwise” initializer for all properties 
(constants or variables) that are not defined:

struct Pokemon {
let species: Species
var level: Int = 1
var nickname: String = "bulby"
}

let bulby = Pokemon(species: (001, "Bulbasaur”))
print(bulby)
// Prints "Pokemon(species: (1, "Bulbasaur"), level: 1, nickname: "bulby")"

Besides, that would avoid some tedious initializer definitions. Indeed, If I 
want to get the desired result, I have to write this kind of initializer:

struct Pokemon {
let species: Species
var level: Int = 1
var nickname: String = "bulby"

init(species: Species, level: Int? = nil, nickname: String? = nil) {
self.species = species

if level != nil {
self.level = level!
}

if nickname != nil {
self.nickname = nickname!
}
}
}

In addition to be rather wordy, it arguably destroys the purpose of defining a 
default value for variable properties in the first place, since imho this 
approach is clearer (unless maybe for some more complicated structs with 
multiple layers of initializer delegation):

struct Pokemon {
let species: Species
var level: Int
var nickname: String

init(species: Species, level: Int = 1, nickname: String = "bulby") {
self.species = species
self.level = level
self.nickname = nickname
}
}

Thanks.

Dimitri Racordon

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Rien via swift-evolution]

> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Our philosophy in general, however, is to default to the behavior which 
>>> preserves the most flexibility for the library designer.
>> 
>> Actually, I thought the philosophy was to preserver type safety. When did 
>> that change?
>> 
>> Also, when was the library designer prioritised ahead of the application 
>> developer?
>> 
>> 
>>> Both open and non-open classes are common, but we chose to give non-open 
>>> classes the `public` keyword because that's the flexibility-preserving 
>>> option.
>> 
>> No it isn’t, it’s the flexibility restricting option. The consumer of an 
>> open class can subclass it. The consumer of a public class cannot subclass 
>> it. How is the second more flexible than the first?
> 
> It reduces complexity for the library author by allowing them to opt-out of 
> the complexity involved in supporting unknown, user-defined subclasses.  It 
> is important to allow libraries to have this flexibility.  They are free to 
> declare a class `open` if they want to allow subclassing.  It’s even possibly 
> for a library to declare all classes `open` if it wishes to do so.  But 
> *requiring* that would reduce the design space libraries are allowed to 
> explore and / or introduce fragility by moving the subclass restriction to a 
> comment.
> 

Why would a library author want to prohibit subclasses?
A library user can always wrap the class and subclass the wrapper.

There are cases where subclassing does not make sense. And thus preventing 
subclasses adds information for those users that don’t RTFM. But that imo is 
not worth the impact extra complexity places on all other users.

Rien.

>> 
>> 
>> ___
>> 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] final + lazy + fileprivate modifiers

[Matthew Johnson via swift-evolution]

> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Feb 14, 2017, at 3:20 AM, David Hart > > wrote:
>> 
>> 
>> On 14 Feb 2017, at 09:25, Goffredo Marocchi > > wrote:
>> 
>>> I disagree with that as well as I still think we are damaging the language 
>>> each time we take a known concept (like access levels) and give new 
>>> meanings to the same keywords. I still look baffled at the redefinition of 
>>> do and the addition of repeat for example...
>>> 
>>> Private, the way it was before, was an admittedly curious take on how most 
>>> languages mean by private and we have jumped through a lot of hoops to 
>>> justify why we did not start with Java/C++/C# like access control and 
>>> augmented it instead of redefining things, omitting others, and then 
>>> constantly pulling the language left and right with not a lot of permanent 
>>> consensus either way as this discussion and others before show.
>> 
>> It's a curious take, but it is a curious take is perfectly coherent with 
>> Swift extensions. How else would you access private implementation details 
>> from an extension? But putting it in the same file, instead of having to 
>> resort to an internal access level.
> 
> Right.  Swift is its own language distinct from Java/C++/etc.  While it is 
> intentionally designed to remain familiar (and thus reuses many keywords 
> across the language family), it often does so with slightly different meaning 
> / behavior.  Consider ‘throw’ for example.
> 
> Keeping with the spirit of Swift and staying consistent with its design, I 
> see two plausible meanings for private:
> 
> Private could mean either:
> 1) private to the file (Swift 2 semantics)
> 2) accessible only to the current type/scope and to extensions to that type 
> that are in the current file.
> 
> I don’t think we’ve ever evaluated and debated approach #2 systematically.

I think #2 is an interesting meaning for `private`.  It would have a little bit 
more similarity to type-scoped `private` in other languages.  It would also be 
applicable in the vast majority of cases where `fileprivate` is currently 
required.

That said, we very much need a file-scoped access modifier.  This is by far the 
most important as it allows us to encapsulate access to state that needs to be 
accessed by more than one type.  I think most people could probably live with 
`fileprivate` for these use cases if they were allowed to use `private` for the 
majority of use cases where access is both within a file *and* within the same 
type.

However, as Brent points out, the SE-0025 meaning of `private` has important 
use cases.  I would be sad to see these go.  

The big lesson I have taken away from our experience with SE-0025 is that 
`private` should have remained relevant as the “soft default” file-scoped 
access modifier but it does not play well with extensions.  It is very common 
to implement a type using several extensions in the same file and despite 
having important use cases, SE-0025 `private` does not allow for this.  This 
means we should not have taken the `private` keyword and instead should have 
persisted in finding it a name that we can all live with.

If we could come up with a good name for this (not at all a sure thing) I think 
the best way forward would be:

* retain `fileprivate` - its slight awkwardness will be more acceptable if it 
indicates a more rare / unusual use case
* make `private` have the semantics of #2 - it will without question be the 
right choice in the majority of use cases
* give scoped access control a new keyword - we still have the ability for 
tighter encapsulation when necessary and a less common keyword will better 
highlight that intent 

I understand that there probably aren’t too many people in the community 
willing to see this level of churn in access modifiers, and probably many who 
would view this introduction of "yet another” private access modifier to be 
excessive and complex so I don’t plan to push this.  But that is my two cents 
about what I think would be ideal.  `private` would be used most of the time 
and we would still have the ability to widen or narrow visibility where 
necessary, with a more esoteric keyword that draws a reader’s attention.


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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
> 
>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> 
>> Our philosophy in general, however, is to default to the behavior which 
>> preserves the most flexibility for the library designer.
> 
> Actually, I thought the philosophy was to preserver type safety. When did 
> that change?
> 
> Also, when was the library designer prioritised ahead of the application 
> developer?
> 
> 
>> Both open and non-open classes are common, but we chose to give non-open 
>> classes the `public` keyword because that's the flexibility-preserving 
>> option.
> 
> No it isn’t, it’s the flexibility restricting option. The consumer of an open 
> class can subclass it. The consumer of a public class cannot subclass it. How 
> is the second more flexible than the first?

It reduces complexity for the library author by allowing them to opt-out of the 
complexity involved in supporting unknown, user-defined subclasses.  It is 
important to allow libraries to have this flexibility.  They are free to 
declare a class `open` if they want to allow subclassing.  It’s even possibly 
for a library to declare all classes `open` if it wishes to do so.  But 
*requiring* that would reduce the design space libraries are allowed to explore 
and / or introduce fragility by moving the subclass restriction to a comment.

> 
> 
> ___
> 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] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 15, 2017, at 5:52 AM, Jeremy Pereira  
> wrote:
> 
> 
>> On 15 Feb 2017, at 02:16, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> So, perhaps I'm being simplistic here, but--
>> 
>> At the end of the day, aren't we simply trying to enable a resiliency 
>> feature? Could it not be said that an enum where future added cases aren't 
>> source-breaking is a more resilient enum?
>> 
>> Since there is consensus that the status quo is desirable for a lot of use 
>> cases, couldn't we keep spelling it "public enum" and just spell this 
>> proposed more resilient enum "@resilient public enum”?
> 
> If it’s got to be done, this is the best solution, but to my mind, it 
> shouldn’t be done at all. 
> 
> There is no way that a library designer can possibly determine what 
> constitutes “resilient” behaviour on the part of the client software. Maybe 
> adding a default clause is the right thing, but maybe the default clause does 
> something that it shouldn’t for some new enumeration cases. As the client 
> software designer, my only defence is an exhaustive switch statement that 
> relies on the compiler to tell me the it is no longer exhaustive. Yes, it 
> means software in the field will crash until I distribute a new version but 
> that is often preferable to other silent consequences. I really do not want 
> to be forced to add a default to a switch that might reduce the safety of my 
> software.
> 
> Adding new cases to any enumeration where the client software is meant to 
> take different actions based on the different cases is source breaking. End 
> of story. No point in trying to mark them as resilient.
> 
> Adding cases to enumerations that are meant to be passed in to the library 
> e.g. an enumeration that specifies a compositing operation or a string 
> encoding may well not be source breaking (how can you tell in every case?) 
> but it’s unlikely that the client is going to be testing those enumerations 
> in a switch statement anyway.

In order to support adding cases to enums meant to be passed in to a library we 
have to introduce some kind of syntax to distinguish these enums from enums 
that are not resilient.  We’ve been discussing options for how to do this.

> 
> 
> 
>> On Tue, Feb 14, 2017 at 10:09 Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>>> On Feb 14, 2017, at 3:43 AM, Brent Royal-Gordon  
>>> wrote:
>>> 
 On Feb 13, 2017, at 7:45 AM, Matthew Johnson  
 wrote:
 
 If you look closely, when most people say “closed enum” they mean a fixed, 
 complete set of cases that are all public.  But when people say “closed 
 protocol” they don’t actually mean a fixed, complete set of conformances 
 that are all public.  They simply mean clients cannot add conformances.  
 This is the semantic contract of resilient enums, not closed enums.
>>> 
>>> Yes, our traditional terminology here has been a little bit confused.
>>> 
> What I instead suggest is that we think of a closed enum as being like a 
> fragile (non-resilient) struct. In both cases, you are committing to a 
> particular design for the type. So I think we should give them both the 
> same keyword—something like:
> 
>@fixed struct Person {
>var name: String
>var birthDate: Date
>}
>@fixed enum Edge {
>case start
>case end
>}
> 
 
 You omitted public here.  Does that mean you intend for `@fixed` to imply 
 public visibility?  If so, I could get behind this.  But I am curious why 
 you made it an attribute rather than a keyword.
>>> 
>>> No, I'm sorry, I meant to say `@fixed public struct` and `@fixed public 
>>> enum`. I don't think `@fixed` implies public-ness, either, so it would need 
>>> to be paired with a `public` keyword. There *may* be keywords we could use 
>>> that would, like `exposed`
>> 
>> I agree that `fixed` (and `closed`) don’t imply `public` in terms of the 
>> colloquial meaning of the words and there is a reasonable case that `open` 
>> does.  I’m not sure I like `exposed`, but maybe it’s possible to find a 
>> keyword that would more directly imply `public`.
>> 
>>> , but I'm not sure we want to make this feature so prominent,
>> 
>> I have some trouble getting on board with requiring an annotation *in 
>> addition* to `public` for the reasons I have already stated, and which led 
>> to `open` becoming an access modifier rather than an annotation.  It’s 
>> possible I could be convinced otherwise, but I think it would require data 
>> showing that this really is a rare edge case.  If the relatively frequency 
>> of closed vs resilient enums is reasonably similar to the relative frequency 
>> of public vs open enums I think there is a strong case to make them carry 
>> the same syntactic weight, as we did 

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson via swift-evolution]

> On Feb 15, 2017, at 5:11 AM, Brent Royal-Gordon  
> wrote:
> 
>> On Feb 14, 2017, at 6:16 PM, Xiaodi Wu  wrote:
>> 
>> So, perhaps I'm being simplistic here, but--
>> 
>> At the end of the day, aren't we simply trying to enable a resiliency 
>> feature? Could it not be said that an enum where future added cases aren't 
>> source-breaking is a more resilient enum?
>> 
>> Since there is consensus that the status quo is desirable for a lot of use 
>> cases, couldn't we keep spelling it "public enum" and just spell this 
>> proposed more resilient enum "@resilient public enum"?
> 
> Our philosophy in general, however, is to default to the behavior which 
> preserves the most flexibility for the library designer. Both open and 
> non-open classes are common, but we chose to give non-open classes the 
> `public` keyword because that's the flexibility-preserving option. Resilient 
> enums are definitely the more flexible option, so by that rule, they should 
> have plain `public`.
> 
> I think that, if enums were a brand-new feature being introduced for the 
> first time in Swift 4, there would be no question that `public enum` ought to 
> give you a resilient enum. The only good reason not to do that is source 
> compatibility. So we need to decide: Which of these principles is more 
> important to us?
> 
> 1. "Defaults for public symbols should preserve as much flexibility for 
> designers as possible."
> 
> 2. "Swift 3 code should compile in Swift 4 without deprecation warnings, 
> unmodified and without a version compatibility flag, whenever possible.”

It’s also worth re-iterating the point I have made about inconsistent semantics 
for `public`, and that this problem as well as your first point also impacts 
protocols.  That means we have two reasons to make a change and both impact 
protocols and enums.  We also have a very reasonable way to introduce the 
changes necessary to solve these problems.

I think the changes are worth making, and certainly worthy of at least bringing 
a proposal to review.

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] [Discussion] Variadics as an Attribute

[Tino Heth via swift-evolution]

>> There is a lot of design overlap. That is the reason why I think we should 
>> vision variadics as a whole in its future rather than simply repaint … 
>> postfix to a type annotation keyword @variadics. This will only close the 
>> doors for some features we might want to add in a future version of Swift.
>> 
> This seems like an entirely separate feature to me; unless the intention is 
> to go back to the old style of treating function arguments as a tuple I don't 
> see why they should need to be related?

This was my first thought as well: imho it doesn't make sense to discard a good 
idea because of a vague hope that there might be something better (in, I'd 
expect, two or three years from now…).

Maybe you could explain a little bit how the feature you are hoping for should 
work, and why there would be interference?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Simplifying Access Using 'Hidden'

[Vladimir.S via swift-evolution]

On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote:

The beauty of Swift 2's access modifiers was that they were based
around files and modules, explicitly rejecting types and scopes as
units for determining visibility. It seems at base there's a group of
people who reject that decision altogether. Hence, new `private`,
proposals around `protected`, `friend`, `hidden`, `extensible`, etc.


I suppose, for those coming from an Objective-C only background, any
extra visibilities are seen as a bonus.

For those coming from a Pascal background, file-based visibility seems
more natural.

But for those of us who have used languages like C++ and C#, losing the
visibilities that we have been used to can seriously affect how we think
and design stuff.



Was surprised that you expressed exactly what I'm thinking about this subject.

I do believe even in Swift we need a way to say "only code that *knows* 
what it does should see this" and to not force us to write(and manage) the 
the code in same file.
Yes, some implementation details that shouldn't be used by "users" of the 
type, but can be used by "extenders" of our type. At least in the same module.


While reading, the question was raised(if was discussed, let me know pls): 
what if we extend the meaning of 'private' to 'visible to current 
type/scope and subtypes and extensions in the *same module*' ?
This will help us to split types by files, help to better model access 
policy for fields/methods(i.e. only scope that can know about details can 
see them) while 'private' still will be hidden outside of the module even 
for subclasses/extensions.


So, we'll have such situation:

"modifier" -> "can be accessed from"
---
public -> outside of the mondule
internal -> inside the module only
fileprivate -> the same file only
private -> the same type/scope, or subtype, or extension in the same 
module. I.e. some kind of 'internal' but scope-oriented.


Actually I still believe we need current 'private' and additionally some 
'protected' with meaning "access from subtype, or extension" probably with 
this limitation: "only in the same module". But suggested extended 
'private' will be also OK for me.


Thoughts?

Vladimir.


FMPOV, it would seem that one of the "features" of Swift is a much more
protocol and struct approach to design. Instead of using class
inheritance to add functionality to an entity, we are encouraged to use
extensions.

But, in so doing, those of us who are used to inheritance find that we
can no longer limit visibility to a "hierarchy" but, instead, when we
want to extend a type whilst accessing "privileged" members, we either
have to put all our extensions in the same file as the base type, or
raise the visibility of those privileged members to internal scope, thus
allowing code anywhere in the same module to access and/or mutate it.

I have read https://developer.apple.com/swift/blog/?id=11 and I can see
the reasoning against protected explained there but…

Once again, I see the "it was good enough for Objective-C" reasoning
being a strong driver here but, this is Swift, where things can be done
differently/better.

Allowing internal scope visibility is less of a problem when you are the
only one writing the module and know intimately the intent and purpose
of everything but when working in a team environment, it is all too easy
for another developer to start "interfering" with your carefully
designed logic by using it in ways that you had not anticipated.

I can understand the reasoning behind not using the concept of protected
visibility but still feel that there are times when restricting
visibility only to extending entities, whether that be subclasses of a
class or extensions of any type, including structs and enums.


I would also like to argue that the use of open vs public for classes is
quite confusing when we already have the option of marking a class or
its members as final ; which seems to do much the same as leaving a
class as public.

Except open is not truly a restriction of visibility, it is more a
restriction on inheritance.

To quote the above blog, "In contrast, protected conflates access with
inheritance". Surely "open" also conflates access with inheritance? It
affects, not what external code can see but how the inheritance chain is
controlled, as does final. In fact, I would dare to say that the
difference between open/public and final is possibly too fine to be of
sufficient importance to justify the existence of both ; or, at least,
it is sufficiently confusing to encourage newer developers to throw
their hands up in despair and simply leave everything as internal or
public until they stumble across a compilation error.

The only real difference I can make out between open/public and final is
that, once again, open/public is more module-based, whereas final is
class based.

Why, when we are allowed final as a class only modifier, can't we have
protected as a class only visibility?

Re: [swift-evolution] [Discussion] Variadics as an Attribute

[T.J. Usiyan via swift-evolution]

+1

I don't see tuples as a better solution for this without substantial work.
Even after all of that work, I am not convinced that tuples would be a
better solution.

On Wed, Feb 15, 2017 at 7:16 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> –1 for me, I’ll explain in a moment.
>
> To help you find the old topic you can use the *proof-of-concept*
> Discourse setup from Nate Cook: http://discourse.natecook.com/
> t/proposal-variadics-as-attribute/2075/20
>
> The link above also reflects Chris Lattners opinion on this topic.
> --
>
> I gave the topic a down vote not because I don’t like the proposal, but
> because I personally see variadics go into the direction of tuples.
> Especially I’d love to see some more talk about tuples in combination of
> generic variadics (see here: https://github.com/apple/
> swift/blob/master/docs/GenericsManifesto.md#variadic-generics).
>
> There is a lot of design overlap. That is the reason why I think we should
> vision variadics as a whole in its future rather than simply repaint …
> postfix to a type annotation keyword @variadics. This will only close the
> doors for some features we might want to add in a future version of Swift.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 15. Februar 2017 um 12:43:49, Haravikk via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Immediate followup, but is there something wrong with the gmane site that
> we've been using to provide links to mailing list discussions?
> I can't seem to get a list of recent topics so I can find out what the new
> discussion link should be.
>
> On 15 Feb 2017, at 11:38, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm posting this as a new discussion topic for my earlier proposal of
> Variadics as an Attribute. I would have reused the old topic but I have no
> idea how to do that on a mailing list once the messages are gone (I don't
> keep them for long); I'm looking forward to the possible switch to
> Discourse!
>
> The idea behind the proposal is fairly simple; to do away with the current
> unique syntax for declaring variadic functions/methods, while retaining the
> ability to call methods in the same way. In other words, instead of
> declaring a method with an ellipsis, you would declare it just like any
> other method, but add the @variadic attribute, enabling the ability to call
> it just like you would call a variadic now.
>
> Since this isn't strictly a code-breaking change (existing code can be
> converted automatically) I'm unsure of when to issue a new pull request, so
> I'll stick with a discussion to hammer out any lingering issues with the
> proposal for just now. Here it is:
>
> https://github.com/Haravikk/swift-evolution/blob/
> 1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/-
> variadics-as-attribute.md
>
> Variadics as Attribute
>
>- Proposal: SE-
>
> 
>- Author: Haravikk 
>- Status: Awaiting review
>- Review manager: TBD
>
>
> 
> Introduction
>
> This proposal seeks to redesign the current, unique variadic function
> declaration syntax to use an attribute instead, with a goal of unifying
> standard and variadic function declarations.
>
> 
> Motivation
>
> Variadics are essentially a call-site feature enabling a function to be
> called as if it is being provided with multiple arguments, rather than a
> single list argument. However instead of being implemented as some kind of
> switch, variadics have a unique declaration syntax that separates them
> uncessarily from standard function declarations. Currently this also means
> that redundancy is required in order to allow a function to be called both
> with an explicit array, and in the variadic style.
>
> Proposed
> solution
>
> To unify both regular and variadic function declarations this proposal
> seeks to replace the unique trailing elipsis declaration syntax with a new
> @variadic attribute on regular function declarations, enabling optional
> variadic syntax at the call site.
>
> In short this proposal would replace:
>
> func someFunc(_ values:Int...) { … }
>
> With the following:
>
> func someFunc(_ values:@variadic [Int]) { … }
>
>
> Detailed
> design
>
> The trailing elipsis declaration syntax will be removed, with a fixit
> providing a replacement to the new attribute-based syntax. The new
> @variadic attribute can be placed on 

Re: [swift-evolution] [Discussion] Variadics as an Attribute

[Haravikk via swift-evolution]

> On 15 Feb 2017, at 12:16, Adrian Zubarev  
> wrote:
> 
> I gave the topic a down vote not because I don’t like the proposal, but 
> because I personally see variadics go into the direction of tuples. 
> Especially I’d love to see some more talk about tuples in combination of 
> generic variadics (see here: 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics
>  
> ).
> 
> There is a lot of design overlap. That is the reason why I think we should 
> vision variadics as a whole in its future rather than simply repaint … 
> postfix to a type annotation keyword @variadics. This will only close the 
> doors for some features we might want to add in a future version of Swift.
> 
This seems like an entirely separate feature to me; unless the intention is to 
go back to the old style of treating function arguments as a tuple I don't see 
why they should need to be related?

Variable-width tuples would still be compiled down to fixed widths at some 
point (based on the number of types you pass).
Variadic functions however are just syntactic sugar for passing an array, 
currently minus the ability to actually pass an array.

I don't think they're similar at all; repurposing of ellipsis to variadic 
generics/tuples isn't something I'm opposed to (though I still don't like the 
ambiguity with ranges), because to me it doesn't seem like an overlapping 
feature at all.

Put another way; variadic generics is a way to allow developers to specify 
multiple types and arbitrary-width tuples, variadic functions just let 
developers call a method without using square braces. Why does the latter 
warrant a unique syntax that effectively creates a special class of function 
lacking the ability to specify collection type?

> Am 15. Februar 2017 um 12:43:49, Haravikk via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
>> Immediate followup, but is there something wrong with the gmane site that 
>> we've been using to provide links to mailing list discussions?
>> I can't seem to get a list of recent topics so I can find out what the new 
>> discussion link should be.
>> 
>>> On 15 Feb 2017, at 11:38, Haravikk via swift-evolution 
>>> > wrote:
>>> 
>>> I'm posting this as a new discussion topic for my earlier proposal of 
>>> Variadics as an Attribute. I would have reused the old topic but I have no 
>>> idea how to do that on a mailing list once the messages are gone (I don't 
>>> keep them for long); I'm looking forward to the possible switch to 
>>> Discourse!
>>> 
>>> The idea behind the proposal is fairly simple; to do away with the current 
>>> unique syntax for declaring variadic functions/methods, while retaining the 
>>> ability to call methods in the same way. In other words, instead of 
>>> declaring a method with an ellipsis, you would declare it just like any 
>>> other method, but add the @variadic attribute, enabling the ability to call 
>>> it just like you would call a variadic now.
>>> 
>>> Since this isn't strictly a code-breaking change (existing code can be 
>>> converted automatically) I'm unsure of when to issue a new pull request, so 
>>> I'll stick with a discussion to hammer out any lingering issues with the 
>>> proposal for just now. Here it is:
>>> 
>>> https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/-variadics-as-attribute.md
>>>  
>>> 
>>> 
>>> Variadics as Attribute
>>> Proposal: SE- 
>>> 
>>> Author: Haravikk 
>>> Status: Awaiting review
>>> Review manager: TBD
>>>  
>>> Introduction
>>> 
>>> This proposal seeks to redesign the current, unique variadic function 
>>> declaration syntax to use an attribute instead, with a goal of unifying 
>>> standard and variadic function declarations.
>>> 
>>>  
>>> Motivation
>>> 
>>> Variadics are essentially a call-site feature enabling a function to be 
>>> called as if it is being provided with multiple arguments, rather than a 
>>> single list argument. However instead of being implemented as some kind of 
>>> switch, variadics have a unique declaration syntax that separates them 
>>> uncessarily from standard function declarations. Currently this also means 
>>> that redundancy is required in order to allow a function to be called both 
>>> with an explicit array, and 

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Adrian Zubarev via swift-evolution]

That’s the other side of the coin, but it does not prevent you from putting 
anything you’d like to as your profile picture. The point I’m trying to make is 
that I don’t think anyone wants to moderate such content, but that’s only a 
personal preference of mine. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 13:30:53, Brent Royal-Gordon (br...@architechies.com) 
schrieb:

> On Feb 9, 2017, at 6:17 AM, Adrian Zubarev via swift-evolution 
>  wrote:  
>  
> Personally I’d prefer (if possible) that we’d remove profile pictures from 
> the forum and simply have only full names (colored?) + some kind of 
> annotation (e.g. Core Team, etc.). Profile pictures are only gimmicks that 
> does not contribute to anything at all.  

Personally, in mediums which offer profile pictures, I usually recognize people 
by profile picture, not by name. The more you can communicate without reading, 
the better.  

--  
Brent Royal-Gordon  
Architechies  

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

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

[Brent Royal-Gordon via swift-evolution]

> On Feb 9, 2017, at 6:17 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Personally I’d prefer (if possible) that we’d remove profile pictures from 
> the forum and simply have only full names (colored?) + some kind of 
> annotation (e.g. Core Team, etc.). Profile pictures are only gimmicks that 
> does not contribute to anything at all.

Personally, in mediums which offer profile pictures, I usually recognize people 
by profile picture, not by name. The more you can communicate without reading, 
the better.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Discussion] Variadics as an Attribute

[Adrian Zubarev via swift-evolution]

–1 for me, I’ll explain in a moment.

To help you find the old topic you can use the proof-of-concept Discourse setup 
from Nate Cook: 
http://discourse.natecook.com/t/proposal-variadics-as-attribute/2075/20

The link above also reflects Chris Lattners opinion on this topic.

I gave the topic a down vote not because I don’t like the proposal, but because 
I personally see variadics go into the direction of tuples. Especially I’d love 
to see some more talk about tuples in combination of generic variadics (see 
here: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics).

There is a lot of design overlap. That is the reason why I think we should 
vision variadics as a whole in its future rather than simply repaint … postfix 
to a type annotation keyword @variadics. This will only close the doors for 
some features we might want to add in a future version of Swift.



-- 
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 12:43:49, Haravikk via swift-evolution 
(swift-evolution@swift.org) schrieb:

Immediate followup, but is there something wrong with the gmane site that we've 
been using to provide links to mailing list discussions?
I can't seem to get a list of recent topics so I can find out what the new 
discussion link should be.

On 15 Feb 2017, at 11:38, Haravikk via swift-evolution 
 wrote:

I'm posting this as a new discussion topic for my earlier proposal of Variadics 
as an Attribute. I would have reused the old topic but I have no idea how to do 
that on a mailing list once the messages are gone (I don't keep them for long); 
I'm looking forward to the possible switch to Discourse!

The idea behind the proposal is fairly simple; to do away with the current 
unique syntax for declaring variadic functions/methods, while retaining the 
ability to call methods in the same way. In other words, instead of declaring a 
method with an ellipsis, you would declare it just like any other method, but 
add the @variadic attribute, enabling the ability to call it just like you 
would call a variadic now.

Since this isn't strictly a code-breaking change (existing code can be 
converted automatically) I'm unsure of when to issue a new pull request, so 
I'll stick with a discussion to hammer out any lingering issues with the 
proposal for just now. Here it is:

https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/-variadics-as-attribute.md

Variadics as Attribute
Proposal: SE-
Author: Haravikk
Status: Awaiting review
Review manager: TBD
Introduction

This proposal seeks to redesign the current, unique variadic function 
declaration syntax to use an attribute instead, with a goal of unifying 
standard and variadic function declarations.

Motivation

Variadics are essentially a call-site feature enabling a function to be called 
as if it is being provided with multiple arguments, rather than a single list 
argument. However instead of being implemented as some kind of switch, 
variadics have a unique declaration syntax that separates them uncessarily from 
standard function declarations. Currently this also means that redundancy is 
required in order to allow a function to be called both with an explicit array, 
and in the variadic style.

Proposed solution

To unify both regular and variadic function declarations this proposal seeks to 
replace the unique trailing elipsis declaration syntax with a new @variadic 
attribute on regular function declarations, enabling optional variadic syntax 
at the call site.

In short this proposal would replace:

func someFunc(_ values:Int...) { … }
With the following:

func someFunc(_ values:@variadic [Int]) { … }
Detailed design

The trailing elipsis declaration syntax will be removed, with a fixit providing 
a replacement to the new attribute-based syntax. The new @variadic attribute 
can be placed on any one function parameter with a type of Array (or 
[Foo]), enabling the optional use of variadic declaration at the call site.

For example:

func someFunc(_ values:@variadic [Int]) { … }
Can be called in any of the following forms:

someFunc(1, 2, 3, 4, 5)   // Fixed length variadic call
someFunc([1, 2, 3, 4, 5]) // Fixed length array call
someFunc(foo) // Dynamic array call passing the Array variable foo
Advantages

Unifies standard and variadic function declarations, eliminating a unique 
syntax that is arguably unnecessary.
The type of the variadic parameter is absolutely explicit.
Enables calling of a variadic function with dynamic arrays, without the need 
for additional special syntax.
No redundant overloads to enable both call styles (one declaration provides 
both).
Enables further extension to support more collection types now or in future 
(see Proposed Extension below).
Moves the variadic feature declaration from syntax into the attributes list, 
which should aid discoverability (and simplify syntax very slightly).
The attribute is 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Brent Royal-Gordon via swift-evolution]

> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Keeping with the spirit of Swift and staying consistent with its design, I 
> see two plausible meanings for private:
> 
> Private could mean either:
> 1) private to the file (Swift 2 semantics)
> 2) accessible only to the current type/scope and to extensions to that type 
> that are in the current file.
> 
> I don’t think we’ve ever evaluated and debated approach #2 systematically.

For what it's worth:

I was opposed to SE-0025, but since I lost, I have tried to use `private` 
wherever it made sense, rather than fighting with the language.

Sometimes, the change of keyword makes no difference. Other times, it's a 
hassle, because I have to switch between `private` and `fileprivate` as I 
redesign things, with little perceived benefit. I'd say the split between these 
is about 50/50.

On a few occasions, I *have* genuinely appreciated the SE-0025 version of 
`private`. These involved cases where I wanted to ensure that instance 
variables were only manipulated in certain ways, using interfaces I had 
specifically designed to handle them correctly. For instance, I might have two 
parallel arrays, and I wanted to make sure that I only added or removed 
elements from both arrays at once. I could do this with `fileprivate` by 
splitting the type into two files, but it was more convenient to do it in one.

In these cases, switching to #2 would *completely* defeat the purpose of using 
`private`, because the extensions would be able to directly manipulate the 
private instance variables. I would no longer gain any benefit at all from 
`private`. All of my uses would either fall into "makes no difference" or "it's 
a hassle".

I do not support the idea of changing `private` to mean #2. Doing so would 
eliminate the few decent use cases I've found for `private`. Either keep it or 
drop it, but don't keep fiddling with it.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Jeremy Pereira via swift-evolution]

> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> 
> Our philosophy in general, however, is to default to the behavior which 
> preserves the most flexibility for the library designer.

Actually, I thought the philosophy was to preserver type safety. When did that 
change?

Also, when was the library designer prioritised ahead of the application 
developer?


> Both open and non-open classes are common, but we chose to give non-open 
> classes the `public` keyword because that's the flexibility-preserving option.

No it isn’t, it’s the flexibility restricting option. The consumer of an open 
class can subclass it. The consumer of a public class cannot subclass it. How 
is the second more flexible than the first?


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

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Jeremy Pereira via swift-evolution]

> On 15 Feb 2017, at 02:16, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> So, perhaps I'm being simplistic here, but--
> 
> At the end of the day, aren't we simply trying to enable a resiliency 
> feature? Could it not be said that an enum where future added cases aren't 
> source-breaking is a more resilient enum?
> 
> Since there is consensus that the status quo is desirable for a lot of use 
> cases, couldn't we keep spelling it "public enum" and just spell this 
> proposed more resilient enum "@resilient public enum”?

If it’s got to be done, this is the best solution, but to my mind, it shouldn’t 
be done at all. 

There is no way that a library designer can possibly determine what constitutes 
“resilient” behaviour on the part of the client software. Maybe adding a 
default clause is the right thing, but maybe the default clause does something 
that it shouldn’t for some new enumeration cases. As the client software 
designer, my only defence is an exhaustive switch statement that relies on the 
compiler to tell me the it is no longer exhaustive. Yes, it means software in 
the field will crash until I distribute a new version but that is often 
preferable to other silent consequences. I really do not want to be forced to 
add a default to a switch that might reduce the safety of my software.

Adding new cases to any enumeration where the client software is meant to take 
different actions based on the different cases is source breaking. End of 
story. No point in trying to mark them as resilient.

Adding cases to enumerations that are meant to be passed in to the library e.g. 
an enumeration that specifies a compositing operation or a string encoding may 
well not be source breaking (how can you tell in every case?) but it’s unlikely 
that the client is going to be testing those enumerations in a switch statement 
anyway.



> On Tue, Feb 14, 2017 at 10:09 Matthew Johnson via swift-evolution 
>  wrote:
> 
> > On Feb 14, 2017, at 3:43 AM, Brent Royal-Gordon  
> > wrote:
> >
> >> On Feb 13, 2017, at 7:45 AM, Matthew Johnson  
> >> wrote:
> >>
> >> If you look closely, when most people say “closed enum” they mean a fixed, 
> >> complete set of cases that are all public.  But when people say “closed 
> >> protocol” they don’t actually mean a fixed, complete set of conformances 
> >> that are all public.  They simply mean clients cannot add conformances.  
> >> This is the semantic contract of resilient enums, not closed enums.
> >
> > Yes, our traditional terminology here has been a little bit confused.
> >
> >>> What I instead suggest is that we think of a closed enum as being like a 
> >>> fragile (non-resilient) struct. In both cases, you are committing to a 
> >>> particular design for the type. So I think we should give them both the 
> >>> same keyword—something like:
> >>>
> >>> @fixed struct Person {
> >>> var name: String
> >>> var birthDate: Date
> >>> }
> >>> @fixed enum Edge {
> >>> case start
> >>> case end
> >>> }
> >>>
> >>
> >> You omitted public here.  Does that mean you intend for `@fixed` to imply 
> >> public visibility?  If so, I could get behind this.  But I am curious why 
> >> you made it an attribute rather than a keyword.
> >
> > No, I'm sorry, I meant to say `@fixed public struct` and `@fixed public 
> > enum`. I don't think `@fixed` implies public-ness, either, so it would need 
> > to be paired with a `public` keyword. There *may* be keywords we could use 
> > that would, like `exposed`
> 
> I agree that `fixed` (and `closed`) don’t imply `public` in terms of the 
> colloquial meaning of the words and there is a reasonable case that `open` 
> does.  I’m not sure I like `exposed`, but maybe it’s possible to find a 
> keyword that would more directly imply `public`.
> 
> > , but I'm not sure we want to make this feature so prominent,
> 
> I have some trouble getting on board with requiring an annotation *in 
> addition* to `public` for the reasons I have already stated, and which led to 
> `open` becoming an access modifier rather than an annotation.  It’s possible 
> I could be convinced otherwise, but I think it would require data showing 
> that this really is a rare edge case.  If the relatively frequency of closed 
> vs resilient enums is reasonably similar to the relative frequency of public 
> vs open enums I think there is a strong case to make them carry the same 
> syntactic weight, as we did with `open`.
> 
> > and I'm not sure how that would work with classes you want to both expose 
> > and permit subclassing of. (Would that be `exposed open class Foo`?)
> 
> 
> Can you elaborate on what you mean by "classes you want to both expose and 
> permit subclassing of”?  Do you mean commit to the set of fields being fixed 
> like you indicated with a struct?  If so, I’m not sure that is a valuable 
> 

Re: [swift-evolution] [Discussion] Variadics as an Attribute

[Haravikk via swift-evolution]

Immediate followup, but is there something wrong with the gmane site that we've 
been using to provide links to mailing list discussions?
I can't seem to get a list of recent topics so I can find out what the new 
discussion link should be.

> On 15 Feb 2017, at 11:38, Haravikk via swift-evolution 
>  wrote:
> 
> I'm posting this as a new discussion topic for my earlier proposal of 
> Variadics as an Attribute. I would have reused the old topic but I have no 
> idea how to do that on a mailing list once the messages are gone (I don't 
> keep them for long); I'm looking forward to the possible switch to Discourse!
> 
> The idea behind the proposal is fairly simple; to do away with the current 
> unique syntax for declaring variadic functions/methods, while retaining the 
> ability to call methods in the same way. In other words, instead of declaring 
> a method with an ellipsis, you would declare it just like any other method, 
> but add the @variadic attribute, enabling the ability to call it just like 
> you would call a variadic now.
> 
> Since this isn't strictly a code-breaking change (existing code can be 
> converted automatically) I'm unsure of when to issue a new pull request, so 
> I'll stick with a discussion to hammer out any lingering issues with the 
> proposal for just now. Here it is:
> 
> https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/-variadics-as-attribute.md
>  
> 
> 
> Variadics as Attribute
> 
> Proposal: SE- 
> 
> Author: Haravikk 
> Status: Awaiting review
> Review manager: TBD
> 
>  
> Introduction
> 
> This proposal seeks to redesign the current, unique variadic function 
> declaration syntax to use an attribute instead, with a goal of unifying 
> standard and variadic function declarations.
> 
> 
>  
> Motivation
> 
> Variadics are essentially a call-site feature enabling a function to be 
> called as if it is being provided with multiple arguments, rather than a 
> single list argument. However instead of being implemented as some kind of 
> switch, variadics have a unique declaration syntax that separates them 
> uncessarily from standard function declarations. Currently this also means 
> that redundancy is required in order to allow a function to be called both 
> with an explicit array, and in the variadic style.
> 
> 
>  
> Proposed
>  solution
> 
> To unify both regular and variadic function declarations this proposal seeks 
> to replace the unique trailing elipsis declaration syntax with a new 
> @variadic attribute on regular function declarations, enabling optional 
> variadic syntax at the call site.
> 
> In short this proposal would replace:
> 
> func someFunc(_ values:Int...) { … }
> With the following:
> 
> func someFunc(_ values:@variadic [Int]) { … }
> 
>  
> Detailed
>  design
> 
> The trailing elipsis declaration syntax will be removed, with a fixit 
> providing a replacement to the new attribute-based syntax. The new @variadic 
> attribute can be placed on any one function parameter with a type of 
> Array (or [Foo]), enabling the optional use of variadic declaration at 
> the call site.
> 
> For example:
> 
> func someFunc(_ values:@variadic [Int]) { … }
> Can be called in any of the following forms:
> 
> someFunc(1, 2, 3, 4, 5)   // Fixed length variadic call
> someFunc([1, 2, 3, 4, 5]) // Fixed length array call
> someFunc(foo) // Dynamic array call passing the Array variable foo
> 
>  
> Advantages
> 
> Unifies standard and variadic function declarations, eliminating a unique 
> syntax that is arguably unnecessary.
> The type of the variadic parameter is absolutely explicit.
> Enables calling of a variadic function with dynamic arrays, without the need 
> for additional special syntax.
> No redundant overloads to enable both call styles (one declaration provides 
> both).
> Enables further extension to support more collection types now or in future 
> (see Proposed Extension below).
> Moves the variadic feature declaration from syntax into the attributes list, 
> which should aid discoverability (and simplify syntax very slightly).
> The attribute is more 

[swift-evolution] [Discussion] Variadics as an Attribute

[Haravikk via swift-evolution]

I'm posting this as a new discussion topic for my earlier proposal of Variadics 
as an Attribute. I would have reused the old topic but I have no idea how to do 
that on a mailing list once the messages are gone (I don't keep them for long); 
I'm looking forward to the possible switch to Discourse!

The idea behind the proposal is fairly simple; to do away with the current 
unique syntax for declaring variadic functions/methods, while retaining the 
ability to call methods in the same way. In other words, instead of declaring a 
method with an ellipsis, you would declare it just like any other method, but 
add the @variadic attribute, enabling the ability to call it just like you 
would call a variadic now.

Since this isn't strictly a code-breaking change (existing code can be 
converted automatically) I'm unsure of when to issue a new pull request, so 
I'll stick with a discussion to hammer out any lingering issues with the 
proposal for just now. Here it is:

https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/-variadics-as-attribute.md

Variadics as Attribute

Proposal: SE- 

Author: Haravikk 
Status: Awaiting review
Review manager: TBD

 
Introduction

This proposal seeks to redesign the current, unique variadic function 
declaration syntax to use an attribute instead, with a goal of unifying 
standard and variadic function declarations.


 
Motivation

Variadics are essentially a call-site feature enabling a function to be called 
as if it is being provided with multiple arguments, rather than a single list 
argument. However instead of being implemented as some kind of switch, 
variadics have a unique declaration syntax that separates them uncessarily from 
standard function declarations. Currently this also means that redundancy is 
required in order to allow a function to be called both with an explicit array, 
and in the variadic style.


 
Proposed
 solution

To unify both regular and variadic function declarations this proposal seeks to 
replace the unique trailing elipsis declaration syntax with a new @variadic 
attribute on regular function declarations, enabling optional variadic syntax 
at the call site.

In short this proposal would replace:

func someFunc(_ values:Int...) { … }
With the following:

func someFunc(_ values:@variadic [Int]) { … }

 
Detailed
 design

The trailing elipsis declaration syntax will be removed, with a fixit providing 
a replacement to the new attribute-based syntax. The new @variadic attribute 
can be placed on any one function parameter with a type of Array (or 
[Foo]), enabling the optional use of variadic declaration at the call site.

For example:

func someFunc(_ values:@variadic [Int]) { … }
Can be called in any of the following forms:

someFunc(1, 2, 3, 4, 5)   // Fixed length variadic call
someFunc([1, 2, 3, 4, 5]) // Fixed length array call
someFunc(foo) // Dynamic array call passing the Array variable foo

 
Advantages

Unifies standard and variadic function declarations, eliminating a unique 
syntax that is arguably unnecessary.
The type of the variadic parameter is absolutely explicit.
Enables calling of a variadic function with dynamic arrays, without the need 
for additional special syntax.
No redundant overloads to enable both call styles (one declaration provides 
both).
Enables further extension to support more collection types now or in future 
(see Proposed Extension below).
Moves the variadic feature declaration from syntax into the attributes list, 
which should aid discoverability (and simplify syntax very slightly).
The attribute is more explicit about what it does (provides a name that can be 
searched).

 
Ambiguity

One technical issue with this change is the introduction of ambiguity as 
follows:

someFunc(_ values:@variadic [Any]) { … }
someFunc([1]) // Is this an array call of [1] or a variadic call of [[1]]?
someFunc(foo) // If foo is an array, is this an array call of foo, or a 
variadic call of [foo]?
However, this issue is only exhibited when the type of variadic is Any (or 
another type that can represent both an array of elements and the elements 
themselves) and only when there is 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 15, 2017, at 1:34 AM, Dietmar Planitzer via swift-evolution 
>  wrote:
> 
> I do like approach #2. It would play well with extensions, look very familiar 
> to how private works in other main stream languages and it wouldn’t get in 
> the way of a possible future refinement of extensions to this model:
> 
> a) 1st party extension (extension defined and owned by the type owner): 
> extension is defined in the same module as the base type:
> 
> - allows access to private type properties and functions even if the base 
> type and extension are in different files
 This is not part of #2, only extensions to that type that are in the current 
file have access to private. 



> - allows the definition of stored properties for value and class types.
> 
> b) 3rd party extension (extension is defined and owned by the _user_ of a 
> type): extension is defined in a parent module and the base type is defined 
> in a sub-module:
> 
> - forbids access to private properties and functions from the imported type
> - forbids the definition of stored properties for value types
> - MAY allow the definition of stored properties on class types (haven’t 
> really convinced myself that this would be a good idea)
> 
> “parent module” would either mean the application that links against a module 
> (what is supported today) but also the parent module of a sub-module 
> (potential future addition).
> 
> 
> Regards,
> 
> Dietmar Planitzer
> 
> 
>> On Feb 14, 2017, at 21:31, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 14, 2017, at 3:20 AM, David Hart  wrote:
>>> 
>>> 
>>> On 14 Feb 2017, at 09:25, Goffredo Marocchi  wrote:
>>> 
 I disagree with that as well as I still think we are damaging the language 
 each time we take a known concept (like access levels) and give new 
 meanings to the same keywords. I still look baffled at the redefinition of 
 do and the addition of repeat for example...
 
 Private, the way it was before, was an admittedly curious take on how most 
 languages mean by private and we have jumped through a lot of hoops to 
 justify why we did not start with Java/C++/C# like access control and 
 augmented it instead of redefining things, omitting others, and then 
 constantly pulling the language left and right with not a lot of permanent 
 consensus either way as this discussion and others before show.
>>> 
>>> It's a curious take, but it is a curious take is perfectly coherent with 
>>> Swift extensions. How else would you access private implementation details 
>>> from an extension? But putting it in the same file, instead of having to 
>>> resort to an internal access level.
>> 
>> Right.  Swift is its own language distinct from Java/C++/etc.  While it is 
>> intentionally designed to remain familiar (and thus reuses many keywords 
>> across the language family), it often does so with slightly different 
>> meaning / behavior.  Consider ‘throw’ for example.
>> 
>> Keeping with the spirit of Swift and staying consistent with its design, I 
>> see two plausible meanings for private:
>> 
>> Private could mean either:
>> 1) private to the file (Swift 2 semantics)
>> 2) accessible only to the current type/scope and to extensions to that type 
>> that are in the current file.
>> 
>> I don’t think we’ve ever evaluated and debated approach #2 systematically.
>> 
>> -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] Simplifying Access Using 'Hidden'

[Joanna Carter via swift-evolution]

> The beauty of Swift 2's access modifiers was that they were based around 
> files and modules, explicitly rejecting types and scopes as units for 
> determining visibility. It seems at base there's a group of people who reject 
> that decision altogether. Hence, new `private`, proposals around `protected`, 
> `friend`, `hidden`, `extensible`, etc.

I suppose, for those coming from an Objective-C only background, any extra 
visibilities are seen as a bonus.

For those coming from a Pascal background, file-based visibility seems more 
natural.

But for those of us who have used languages like C++ and C#, losing the 
visibilities that we have been used to can seriously affect how we think and 
design stuff.

FMPOV, it would seem that one of the "features" of Swift is a much more 
protocol and struct approach to design. Instead of using class inheritance to 
add functionality to an entity, we are encouraged to use extensions.

But, in so doing, those of us who are used to inheritance find that we can no 
longer limit visibility to a "hierarchy" but, instead, when we want to extend a 
type whilst accessing "privileged" members, we either have to put all our 
extensions in the same file as the base type, or raise the visibility of those 
privileged members to internal scope, thus allowing code anywhere in the same 
module to access and/or mutate it.

I have read https://developer.apple.com/swift/blog/?id=11 and I can see the 
reasoning against protected explained there but…

Once again, I see the "it was good enough for Objective-C" reasoning being a 
strong driver here but, this is Swift, where things can be done 
differently/better.

Allowing internal scope visibility is less of a problem when you are the only 
one writing the module and know intimately the intent and purpose of everything 
but when working in a team environment, it is all too easy for another 
developer to start "interfering" with your carefully designed logic by using it 
in ways that you had not anticipated.

I can understand the reasoning behind not using the concept of protected 
visibility but still feel that there are times when restricting visibility only 
to extending entities, whether that be subclasses of a class or extensions of 
any type, including structs and enums.


I would also like to argue that the use of open vs public for classes is quite 
confusing when we already have the option of marking a class or its members as 
final ; which seems to do much the same as leaving a class as public.

Except open is not truly a restriction of visibility, it is more a restriction 
on inheritance.

To quote the above blog, "In contrast, protected conflates access with 
inheritance". Surely "open" also conflates access with inheritance? It affects, 
not what external code can see but how the inheritance chain is controlled, as 
does final. In fact, I would dare to say that the difference between 
open/public and final is possibly too fine to be of sufficient importance to 
justify the existence of both ; or, at least, it is sufficiently confusing to 
encourage newer developers to throw their hands up in despair and simply leave 
everything as internal or public until they stumble across a compilation error.

The only real difference I can make out between open/public and final is that, 
once again, open/public is more module-based, whereas final is class based.

Why, when we are allowed final as a class only modifier, can't we have 
protected as a class only visibility?

Or, as I have mentioned previously, should we have a much more "Swifty" version 
of protected that allows more concisely defined visibility, not only within 
class hierarchies, but also within the full range of Swift "hierarchies", 
otherwise known as extensions?

My suggestion of "extensible" is intended to replace the perceived need for 
"protected" for classes, whilst unifying that concept of privileged access 
within a class hierarchy, with a similar, and increasingly demanded, privileged 
access for extensions of all types.

To elucidate further :

Before Swift, if we wanted a hierarchy of types, all with common base 
behaviour, without having to write the same code in every type, we were limited 
to using classes with their visibilities of private, protected and public.

Now Swift encourages us to declare protocols, which can have extensions that 
can define base behaviour, as long as that behaviour doesn't include stored 
data. We can then "inherit" that behaviour either in classes, structs or enums 
that implement the "base" protocol.

So, an interesting question is : should we look at getting rid of class 
inheritance altogether in favour of "protocol-based inheritance"?


Oh, and finally for this post, can anyone please tell me exactly what 
fileprivate brings to the table?

To my mind, although it allows access to private members of another type, it 
also requires that any type, wishing to take advantage of that privilege, has 
to be declared in the same file 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Tino Heth via swift-evolution]

> 1) private to the file (Swift 2 semantics)
> 2) accessible only to the current type/scope and to extensions to that type 
> that are in the current file.

Imho the old model had the benefit that it made things like C++ "friend" 
superfluous, so I prefer 1) over 2).
It is simpler, and from a pragmatic standpoint, it is much more useful:
You can always put code into another file if you don't want it to access 
private stuff.

2) Solves the problem of encapsulation for playgrounds, but that could be done 
in other ways — there could be an #eof statement for playgrounds, and maybe 
Swift will even have improved namespaces in the future...___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] consistent public access modifiers

[Brent Royal-Gordon via swift-evolution]

> On Feb 14, 2017, at 6:16 PM, Xiaodi Wu  wrote:
> 
> So, perhaps I'm being simplistic here, but--
> 
> At the end of the day, aren't we simply trying to enable a resiliency 
> feature? Could it not be said that an enum where future added cases aren't 
> source-breaking is a more resilient enum?
> 
> Since there is consensus that the status quo is desirable for a lot of use 
> cases, couldn't we keep spelling it "public enum" and just spell this 
> proposed more resilient enum "@resilient public enum"?

Our philosophy in general, however, is to default to the behavior which 
preserves the most flexibility for the library designer. Both open and non-open 
classes are common, but we chose to give non-open classes the `public` keyword 
because that's the flexibility-preserving option. Resilient enums are 
definitely the more flexible option, so by that rule, they should have plain 
`public`.

I think that, if enums were a brand-new feature being introduced for the first 
time in Swift 4, there would be no question that `public enum` ought to give 
you a resilient enum. The only good reason not to do that is source 
compatibility. So we need to decide: Which of these principles is more 
important to us?

1. "Defaults for public symbols should preserve as much flexibility for 
designers as possible."

2. "Swift 3 code should compile in Swift 4 without deprecation warnings, 
unmodified and without a version compatibility flag, whenever possible."

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] array splatting for variadic parameters

[Tino Heth via swift-evolution]

> I didn't get an especially positive response to the proposal at the time, but 
> it is still very much my preferred solution.


I'm convinced that the timing had a very huge impact on the reaction:
It was a very busy period, and I had a strong impression that people just 
wanted to limit the workload for the next milestone.

Imho "…"-variadics are a C-legacy that is a much worse fit for Swift than 
things that have been abandoned during times with higher motivation for such 
changes (I'm thinking of the for-loop and the increment/decrement operators).

For me, the change not only removes a strange syntax and type oddity, making 
Swift easier to understand — it also makes the language more powerful without 
additional cost.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

[Pranshu Goyal via swift-evolution]

+1

On 15 February 2017 at 15:12, Dietmar Planitzer via swift-evolution <
swift-evolution@swift.org> wrote:

> I would love to see this - and the sooner the better :)
>
> I think that the fact that Swift makes a type-level distinction between
> optional and non-optional makes it easier to trip yourself up when you work
> with Cocoa APIs that use pseudo-optionality, compared to when you work with
> ObjC. In ObjC you are aware 100% of the time that optionality is always
> represented in some way or another and that you have to expected
> inconsistency in the representation of optionality. So you keep this in
> mind and look out for it. But in Swift it’s easy to slide into the
> assumption that all APIs which return something that’s technically optional
> do indeed represent this as an optional type rather than some special
> integer value, float value or singleton object.
>
>
> Regards,
>
> Dietmar Planitzer
>
> > On Feb 14, 2017, at 11:08, Philippe Hausler via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > The feature in this case I would claim is independent of the adopters.
> Personally I think this would be a useful feature to allow for better
> exposition into swift but also more robust objective-c APIs.
> >
> > Something to consider here is that not all NSUIntegers can be
> NSNotFound, sometimes the return value is 0. It would be interesting to
> consider that _Nullable would be parameterized via a constant expression.
> This is a straw man refinement here (the exact spelling would be something
> we would have to audit the way it is implemented and likely use macros to
> compose the right nullability concepts)
> >
> > Lets take for example this API:
> >
> > + (NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream
> *)stream format:(NSPropertyListFormat)format 
> options:(NSPropertyListWriteOptions)opt
> error:(out NSError **)error;
> >
> > The return value here would be 0 if an error occurs. So the nullability
> value would be 0.
> >
> > + (nullable(0) NSInteger)writePropertyList:(id)plist
> toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format
> options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;
> >
> > But other APIs like you indicated:
> >
> > - (NSUInteger)indexOfObject:(ObjectType)anObject;
> >
> > Could be converted to:
> >
> > - (nullable(NSNotFound) NSUInteger)indexOfObject:(ObjectType)anObject;
> >
> > Which would immediately be an indication to the reader what the “null”
> value would be represented as. Of course your concept of type aliases might
> be a decent way to group concepts together but if lets say there was an
> index type for NSArray; obviously you might want a index return value to be
> nullable but it would be a bit confusing to take a nullable parameter into
> certain APIs.
> >
> > Given a concept of NSArrayIndex as you suggested (that being nullable)
> would have the problem that
> >
> > - (ObjectType)objectAtIndex:(NSUInteger)index;
> >
> > Would either incorrectly indicate it would be nullable or it would have
> a different type.
> >
> > There would be other cases where structural types might need a nullable
> placeholder value, e.g. NSRange with a location of NSNotFound and a length
> of 0 (however that strictly isn’t correct since it is just the location
> that indicates null-ness.. but that is probably more of an implementation
> detail and should probably be corrected imho).
> >
> > There could also be cases where an API returns either an object of a
> specific type or NSNull as a placeholder. This would be nice to be able to
> express as a nullable type especially in generics. For example:
> `NSArray<_Nullable(NSNull *) Foo *> *` could be a neat way to express
> `Array` which cannot be expressed currently.
> >
> > Overall I think this could really reduce some of the overlays for all
> the frameworks on Mac OS X and iOS, improve the expressivity of Objective-C
> APIs, offer more accurate bridged representations, and generally give API
> authors an opportunity to more correctly represent what should be exposed
> in Swift without needing to write overlays that could easily have poor
> interaction with things like subclassing or delegation.
> >
> > As a side note: I am not certain if the parameterization of nullability
> annotations would even be possible in the current compiler implementations
> or if it would be easier to use an attribute instead (that would be left to
> implementation detail).
> >
> > I would guess that if this feature would be available it would take a
> combined effort from all API maintainers to annotate their return values
> and any un-annotated shouldn’t be exposed as a IOU since they have non nil
> values already. Furthermore the timeframe to do so would probably be
> independent of the implementation of this type of feature.
> >
> > Those caveats aside - I think it would be a fantastic tool in the
> toolbox!
> >
> >> On Feb 14, 2017, at 10:41 AM, Jeff Kelley via swift-evolution <
> 

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

[Dietmar Planitzer via swift-evolution]

I would love to see this - and the sooner the better :)

I think that the fact that Swift makes a type-level distinction between 
optional and non-optional makes it easier to trip yourself up when you work 
with Cocoa APIs that use pseudo-optionality, compared to when you work with 
ObjC. In ObjC you are aware 100% of the time that optionality is always 
represented in some way or another and that you have to expected inconsistency 
in the representation of optionality. So you keep this in mind and look out for 
it. But in Swift it’s easy to slide into the assumption that all APIs which 
return something that’s technically optional do indeed represent this as an 
optional type rather than some special integer value, float value or singleton 
object.


Regards,

Dietmar Planitzer

> On Feb 14, 2017, at 11:08, Philippe Hausler via swift-evolution 
>  wrote:
> 
> The feature in this case I would claim is independent of the adopters. 
> Personally I think this would be a useful feature to allow for better 
> exposition into swift but also more robust objective-c APIs.
> 
> Something to consider here is that not all NSUIntegers can be NSNotFound, 
> sometimes the return value is 0. It would be interesting to consider that 
> _Nullable would be parameterized via a constant expression. This is a straw 
> man refinement here (the exact spelling would be something we would have to 
> audit the way it is implemented and likely use macros to compose the right 
> nullability concepts)
> 
> Lets take for example this API:
> 
> + (NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream *)stream 
> format:(NSPropertyListFormat)format options:(NSPropertyListWriteOptions)opt 
> error:(out NSError **)error;
> 
> The return value here would be 0 if an error occurs. So the nullability value 
> would be 0.
> 
> + (nullable(0) NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream 
> *)stream format:(NSPropertyListFormat)format 
> options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;
> 
> But other APIs like you indicated:
> 
> - (NSUInteger)indexOfObject:(ObjectType)anObject;
> 
> Could be converted to:
> 
> - (nullable(NSNotFound) NSUInteger)indexOfObject:(ObjectType)anObject;
> 
> Which would immediately be an indication to the reader what the “null” value 
> would be represented as. Of course your concept of type aliases might be a 
> decent way to group concepts together but if lets say there was an index type 
> for NSArray; obviously you might want a index return value to be nullable but 
> it would be a bit confusing to take a nullable parameter into certain APIs.
> 
> Given a concept of NSArrayIndex as you suggested (that being nullable) would 
> have the problem that 
> 
> - (ObjectType)objectAtIndex:(NSUInteger)index;
> 
> Would either incorrectly indicate it would be nullable or it would have a 
> different type. 
> 
> There would be other cases where structural types might need a nullable 
> placeholder value, e.g. NSRange with a location of NSNotFound and a length of 
> 0 (however that strictly isn’t correct since it is just the location that 
> indicates null-ness.. but that is probably more of an implementation detail 
> and should probably be corrected imho).
> 
> There could also be cases where an API returns either an object of a specific 
> type or NSNull as a placeholder. This would be nice to be able to express as 
> a nullable type especially in generics. For example: 
> `NSArray<_Nullable(NSNull *) Foo *> *` could be a neat way to express 
> `Array` which cannot be expressed currently.
> 
> Overall I think this could really reduce some of the overlays for all the 
> frameworks on Mac OS X and iOS, improve the expressivity of Objective-C APIs, 
> offer more accurate bridged representations, and generally give API authors 
> an opportunity to more correctly represent what should be exposed in Swift 
> without needing to write overlays that could easily have poor interaction 
> with things like subclassing or delegation.
> 
> As a side note: I am not certain if the parameterization of nullability 
> annotations would even be possible in the current compiler implementations or 
> if it would be easier to use an attribute instead (that would be left to 
> implementation detail).
> 
> I would guess that if this feature would be available it would take a 
> combined effort from all API maintainers to annotate their return values and 
> any un-annotated shouldn’t be exposed as a IOU since they have non nil values 
> already. Furthermore the timeframe to do so would probably be independent of 
> the implementation of this type of feature. 
> 
> Those caveats aside - I think it would be a fantastic tool in the toolbox!
> 
>> On Feb 14, 2017, at 10:41 AM, Jeff Kelley via swift-evolution 
>>  wrote:
>> 
>> On Mon, Feb 13, 2017 at 11:53 PM, Rod Brown  wrote:
>> I think the biggest problem we're going 

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Dietmar Planitzer via swift-evolution]

I do like approach #2. It would play well with extensions, look very familiar 
to how private works in other main stream languages and it wouldn’t get in the 
way of a possible future refinement of extensions to this model:

a) 1st party extension (extension defined and owned by the type owner): 
extension is defined in the same module as the base type:

- allows access to private type properties and functions even if the base type 
and extension are in different files
- allows the definition of stored properties for value and class types

b) 3rd party extension (extension is defined and owned by the _user_ of a 
type): extension is defined in a parent module and the base type is defined in 
a sub-module:

- forbids access to private properties and functions from the imported type
- forbids the definition of stored properties for value types
- MAY allow the definition of stored properties on class types (haven’t really 
convinced myself that this would be a good idea)

“parent module” would either mean the application that links against a module 
(what is supported today) but also the parent module of a sub-module (potential 
future addition).


Regards,

Dietmar Planitzer


> On Feb 14, 2017, at 21:31, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Feb 14, 2017, at 3:20 AM, David Hart  wrote:
>> 
>> 
>> On 14 Feb 2017, at 09:25, Goffredo Marocchi  wrote:
>> 
>>> I disagree with that as well as I still think we are damaging the language 
>>> each time we take a known concept (like access levels) and give new 
>>> meanings to the same keywords. I still look baffled at the redefinition of 
>>> do and the addition of repeat for example...
>>> 
>>> Private, the way it was before, was an admittedly curious take on how most 
>>> languages mean by private and we have jumped through a lot of hoops to 
>>> justify why we did not start with Java/C++/C# like access control and 
>>> augmented it instead of redefining things, omitting others, and then 
>>> constantly pulling the language left and right with not a lot of permanent 
>>> consensus either way as this discussion and others before show.
>> 
>> It's a curious take, but it is a curious take is perfectly coherent with 
>> Swift extensions. How else would you access private implementation details 
>> from an extension? But putting it in the same file, instead of having to 
>> resort to an internal access level.
> 
> Right.  Swift is its own language distinct from Java/C++/etc.  While it is 
> intentionally designed to remain familiar (and thus reuses many keywords 
> across the language family), it often does so with slightly different meaning 
> / behavior.  Consider ‘throw’ for example.
> 
> Keeping with the spirit of Swift and staying consistent with its design, I 
> see two plausible meanings for private:
> 
> Private could mean either:
> 1) private to the file (Swift 2 semantics)
> 2) accessible only to the current type/scope and to extensions to that type 
> that are in the current file.
> 
> I don’t think we’ve ever evaluated and debated approach #2 systematically.
> 
> -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

Re: [swift-evolution] array splatting for variadic parameters

[Dimitri Racordon via swift-evolution]

> "Splatting" as the OP suggests is a simpler solution, but leaves variadics 
> limited to a unique syntax with no control over type;


I also your prefer the proposal than my initial suggestion.

> I could of course be biased, but then I've never really supported variadics 
> as a feature in the first place 


To be perfectly honest, I’m not the biggest zealot of variadics neither =D

However, I spend most of my time writing libraries for people unfamiliar with 
programming, or even computer science in general. As a result, I often provide 
them with "domain specific languages” embedded in some host language. Swift 
fits that job extremely well, thanks to many of its features; variadics are one 
of them.

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

Re: [swift-evolution] array splatting for variadic parameters

[Haravikk via swift-evolution]

> On 14 Feb 2017, at 20:43, Anton Zhilin via swift-evolution 
>  wrote:
> 
> 2017-02-14 18:32 GMT+03:00 Dimitri Racordon via swift-evolution 
> >:
> 
> 
> 
> The proposal is indeed really interesting.
> I would love to see if it could get a second round of discussion.
> 
> However, I failed to understand the syntax of the proposed extension. Where 
> would be defined the label and parameter names? Is this just a typo?
> 
> func someFunc 
> 
> “Obviously”, the Collection variant should look like:
> 
> func someFunc(_ values: 
> @variadic C) { … }
> And the others are analagous.
> 

Thanks for the correction, not entirely sure how that mistake made it into the 
proposal!

I didn't get an especially positive response to the proposal at the time, but 
it is still very much my preferred solution.


"Splatting" as the OP suggests is a simpler solution, but leaves variadics 
limited to a unique syntax with no control over type; I'm also not keen on 
re-using ellipsis as an operator for it, since it's also used for handling 
ranges, though that's not a major overlap. But still, part of why I made my 
proposal is that splatting feels more like a workaround to a problem of there 
not being a proper array/sequence/etc. signature for the function.

I could of course be biased, but then I've never really supported variadics as 
a feature in the first place ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] final + lazy + fileprivate modifiers

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Feb 14, 2017, at 3:20 AM, David Hart > > wrote:
>> 
>> 
>> On 14 Feb 2017, at 09:25, Goffredo Marocchi > > wrote:
>> 
>>> I disagree with that as well as I still think we are damaging the language 
>>> each time we take a known concept (like access levels) and give new 
>>> meanings to the same keywords. I still look baffled at the redefinition of 
>>> do and the addition of repeat for example...
>>> 
>>> Private, the way it was before, was an admittedly curious take on how most 
>>> languages mean by private and we have jumped through a lot of hoops to 
>>> justify why we did not start with Java/C++/C# like access control and 
>>> augmented it instead of redefining things, omitting others, and then 
>>> constantly pulling the language left and right with not a lot of permanent 
>>> consensus either way as this discussion and others before show.
>> 
>> It's a curious take, but it is a curious take is perfectly coherent with 
>> Swift extensions. How else would you access private implementation details 
>> from an extension? But putting it in the same file, instead of having to 
>> resort to an internal access level.
> 
> Right.  Swift is its own language distinct from Java/C++/etc.  While it is 
> intentionally designed to remain familiar (and thus reuses many keywords 
> across the language family), it often does so with slightly different meaning 
> / behavior.  Consider ‘throw’ for example.
> 
> Keeping with the spirit of Swift and staying consistent with its design, I 
> see two plausible meanings for private:
> 
> Private could mean either:
> 1) private to the file (Swift 2 semantics)
> 2) accessible only to the current type/scope and to extensions to that type 
> that are in the current file.
> 
> I don’t think we’ve ever evaluated and debated approach #2 systematically.

+1 for #2

I think #2 strikes a really good balance and addresses all the uses of 
file-private for me personally. I don’t think the argument of trying to prevent 
people from accessing private members or methods in an extension stands 
specially when those extension live in the same file. If I really want 
something to be private then I can declare that inside an extension in which 
case other extension could not reach it. 


// File.swift
struct MyType {
private func myMethod(){}
}

extension MyType {
private func myMethodCantBeSeen(){}
func myExtenMethod1(){
myMethod() // Okay #2, in Swift 3 this method needs to be fileprivate
}
}

extension MyType {
func myExtenMethod2(){
myMethodCantBeSeen()// inaccessible due to private protection level
}
}
// end of File.swift



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