Re: [swift-evolution] [Review] SE-0057: Importing Objective-C Lightweight Generics

[Douglas Gregor via swift-evolution]

> On Mar 31, 2016, at 2:40 PM, Andrew Bennett via swift-evolution 
>  wrote:
> 
> A few quick questions:
> 
>  * Is there a swift-evolution discussion thread? It's marked as TODO 
> currently.

Thanks for catching that. The thread is here:

http://thread.gmane.org/gmane.comp.lang.swift.evolution/2886

and I’ve updated the proposal with a link.

>  * What if you want your generic parameter to be a protocol instead of a 
> class?

The generic parameter itself can be required to conform to @objc protocols; the 
generic argument will be able to be an @objc protocol when the protocol 
conforms to itself.

- Doug

> 
> Thanks!
> Andrew Bennett
> 
> On Friday, 1 April 2016, Chris Lattner via swift-evolution 
> > wrote:
> Hello Swift community,
> 
> The review of "Importing Objective-C Lightweight Generics" begins now and 
> runs through April 5. The proposal is available here:
> 
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a 
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> 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] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs 
Accordingly" begins now and runs through April 5, 2016. The proposal is 
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md
Reply text

Other replies
 What goes 
into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

Doug Gregor

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Guillaume Lessard via swift-evolution]

> On 31 mars 2016, at 22:01, Chris Lattner via swift-evolution 
>  wrote:
> 
> Protocol requirements with default (no-op) implementations already satisfy 
> that design goal, no?

They do, but that is not clear for everyone. And after protocol extensions 
appeared with 2.0, it took a little while to make that leap...

Documentation-wise, maybe the current “Optional Protocol Requirements” section 
should be moved from “The Swift Programming Language” to “Using Swift with 
Cocoa and Objective-C”. It would make it clearer that the feature exists for 
Objective-C interop. At the very least, moving that section to after the 
“Protocol Extensions" section would at least present the more important feature 
first.

Cheers,
Guillaume Lessard

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Brent Royal-Gordon via swift-evolution]

> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md

>   • What is your evaluation of the proposal?

In favor. This is a simple, clean win—there's not much else to say about it.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. This kind of inconsistency encourages subtle confusion.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Can't think of anything relevant.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick read of this latest draft, but I participated in the discussion as well.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

With these names we lose consistency. The current scheme makes it very
clear that each next level is a subset of the previous level. With
"internal", fileprivate looks out of place.

We have several goals for all the names:
1) obvious
2) using standard terms
3) short
4) consistent

This discussion shows that we cannot have all of them. We have to pick
something at the expense of something else.

For me, the order of importance is 2, 4, 1, 3, and I am pretty sure that
with this order

public
moduleprivate
fileprivate
private

is the best so far.

public
internal
fileprivate
private

is not as consistent. It's also not as obvious, given that many people
proposed to use internal to mean fileprivate. The biggest advantages of
these names are that there is less change and short words. If these are the
most important goals, then my original proposal is even better:

public
internal
private
scoped

It's a non-breaking change, everything retains its meaning, the added name
is very clear, and all the names are very short. The biggest problem here
is "private" -- it's not the most private that the language provides, and
most people would expect that.

Here is another one like that (it solves the "private" problem at the
expense of using non-standard terms):

public
internal
local
scoped

My main point is that we cannot have everything. We have to pick the order
of importance.

We heard many times that "short" is not the goal of Swift. Instead, it's
clarity. If this is the case, then I think

public
moduleprivate
fileprivate
private

is the clearest we've seen. Nobody could possibly be confused about the
meaning of these names. I doubt that moduleprivate will be required to
spell out in any style guide, but even so, it's not so bad. We have many
frequently used class names that are much longer.

On Thu, Mar 31, 2016 at 12:22 AM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 23, 2016, at 10:13 PM, Chris Lattner  wrote:
> > How about we continue this trend, and follow other existing Swift
> keywords that merge two lowercase words (associatedtype, typealias, etc),
> and use:
> >
> >   public
> >   moduleprivate
> >   fileprivate
> >   private
> >
> > The advantages, as I see them are:
> > 1) We keep public and private meaning the “right” and “obvious” things.
> > 2) The declmodifiers “read” correctly.
> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
> awkward parenthesized keyword approach.
> > 4) The unusual ones would be “googable”.
> > 5) Support for named submodules could be “dropped in” by putting the
> submodule name/path in parens: private(foo.bar.baz) or
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
> natural than putting keywords in parens.
>
> I’ve seen a number of concerns on this list about moduleprivate, and how
> it penalizes folks who want to explicitly write their access control.  I’ve
> come to think that there is yes-another possible path forward here (which I
> haven’t seen mentioned so far):
>
> public
> internal
> fileprivate
> private
>
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) Compared to Swift 2, there is almost no change.  The only thing that
> changes is that some uses of Swift 2 “private” will be migrated to
> “fileprivate”, which makes the intent of the code much more clear.
> 4) fileprivate is the unusual and
> not-really-precedented-in-other-languages modifier, and it would still be
> “googable”.
> 5) The addresses the “excessively long” declmodifier problem that several
> people are concerned with.
> 6) Support for named submodules could be “dropped in” by parameterizing
> “internal”.
>
> Thoughts?
>
> -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] [swift-evolution-announce] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Chris Lattner via swift-evolution]

> On Mar 31, 2016, at 2:24 PM, Shawn Erickson via swift-evolution 
>  wrote:
> 
> 
> 
> On Thu, Mar 31, 2016 at 9:43 AM Chris Lattner  > wrote:
> That said, this is the sort of proposal that can have a profound impact on 
> the actual experience using unaudited APIs.  The core team believes that the 
> experience will be good, but we would like to get some experience moving a 
> couple of existing projects (both low-level code that interacts with C, and 
> an “App” project working with high level frameworks) to see what the impact 
> is in practice.  If something unexpected comes up, we will revisit this, and 
> potentially reject it later.
> 
> On the topic of unaudited APIs. Does a recommended way exist that I as say a 
> user of on an unaudited C API / library can add attributes to the C API for 
> my use in Swift? (e.g. code that I don't own, I just use)
> 
> It is likely a number of C APIs won't get attributed for improved use in 
> Swift by the authors so having a good way that the community could overlay 
> attributes for the benefit of Swift could be helpful.

We have a facility for doing this (called “API notes”).  The problem is that it 
is currently hacked together to solve specific problems, not something that is 
really properly designed.

I know that many people would like to see this situation get improved, and make 
it a first class feature of the swift experience.

-Chris

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Chris Lattner via swift-evolution]

> On Mar 31, 2016, at 11:49 AM, Yuval Tal via swift-evolution 
>  wrote:
> 
> None taken. However, most of the delegate concept of UIKit relies heavily on 
> this "nonsensical" requirement. It is impossible for someone to implement a 
> control in swift which is "in the spirit" of UIKit, meaning the control has a 
> delegate, with several methods that share the same name with different 
> parameters, some are required and some are optional. I think it is not fair 
> to tell users that they cannot implement something that is such a common and 
> repeating pattern in the core. 

Protocol requirements with default (no-op) implementations already satisfy that 
design goal, no?

-Chris

> 
> On Thu, Mar 31, 2016 at 2:23 PM, Dave Abrahams via swift-evolution 
> > wrote:
> 
> on Wed Mar 30 2016, Yuval Tal  > wrote:
> 
> > Hi,
> >
> > I find that optional protocol methods to be very useful. However,
> > there is a caveat -- it needs to be mapped to @objc.  This puts a set
> > of limitations, such as: structures cannot be used as parameters as it
> > does not map to objective-c. What do you think about removing the
> > requirement of using @objc and allow to create optional methods
> > without these limitations?
> 
> Caveat: this is going to be strongly-worded; sorry in advance.  I think
> (no offense intended) it's a terrible idea.  The whole notion of an
> “optional requirement” is nonsensical to begin with, and the use of
> optional protocol requirements encourages a style of programming that
> lifts the responsibility of the protocol designer for careful design at
> the expense of clients of the protocol.  There are better ways to do
> things; let's not propagate this anti-pattern any further than it's
> already gone.
> 
> --
> Dave
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Matthew Johnson via swift-evolution]

> 
> What is your evaluation of the proposal?
+1.  The current behavior is surprising in a somewhat confusing way.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes

> Does this proposal fit well with the feel and direction of Swift?
Yes

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I haven’t used a language with leading dot shorthand so I don’t have a point of 
comparison.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Followed the thread on the mailing list and read the proposal.

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Matthew Johnson via swift-evolution]

> On Mar 31, 2016, at 5:51 PM, David Waite via swift-evolution 
>  wrote:
> 
> +1
> 
> We need to support optional methods in @objc protocols because it is required 
> for interoperability. However, there are in my experience only reasons for an 
> optional protocol method:
> 
> - There is a very common default behavior for a delegate (such as return 
> immediately with a value of 0/nil/false) which would be a burden to require 
> everyone to implement. We can instead accomplish this with protocol extensions
> 
> - The absence of a method in a delegate indicates a behavior that is 
> otherwise impossible for the delegate to implement. The easiest example of 
> this would be  tableView:heightForRowAtIndexPath:, where the absence triggers 
> an optimization where UITableView.rowHeight is used for all math, and its 
> presence means that performance will be degraded, and the delegate will be 
> called repeatedly for every single index path in order to figure out the 
> table positioning/scroll height. I believe this has been shown to be much 
> better solved via an optional additional protocol conformance to indicate 
> that you are supporting a different ‘class’ of behavior, in this case that 
> might be something like UITableViewVaribleHeightDelegate.

+1.  I am not fully pleased with the design of the UITableViewDelegate and 
UITableViewDataSource protocols and this is one point that is problematic.  It 
makes it impossible to implement a generic delegate that might sometimes need 
to have variable row height, but in other cases should take the fast path.

> 
> I’d hate for there to be a push for optional protocol methods just because it 
> can be confusing which methods are required in swift protocol implementations 
> (vs defaulted by a protocol extension).
> 
> -DW
> 
>> On Mar 31, 2016, at 12:23 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Wed Mar 30 2016, Yuval Tal  wrote:
>> 
>>> Hi,
>>> 
>>> I find that optional protocol methods to be very useful. However,
>>> there is a caveat -- it needs to be mapped to @objc.  This puts a set
>>> of limitations, such as: structures cannot be used as parameters as it
>>> does not map to objective-c. What do you think about removing the
>>> requirement of using @objc and allow to create optional methods
>>> without these limitations?
>> 
>> Caveat: this is going to be strongly-worded; sorry in advance.  I think
>> (no offense intended) it's a terrible idea.  The whole notion of an
>> “optional requirement” is nonsensical to begin with, and the use of
>> optional protocol requirements encourages a style of programming that
>> lifts the responsibility of the protocol designer for careful design at
>> the expense of clients of the protocol.  There are better ways to do
>> things; let's not propagate this anti-pattern any further than it's
>> already gone.
>> 
>> --
>> Dave
>> 
>> ___
>> 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] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0056 "Allow trailing closures in `guard` conditions" begins 
now and runs through April 5, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md
Reply text

Other replies
 What goes 
into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

Doug Gregor

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Wallacy via swift-evolution]

I have to say, I'm not very happy with the progress of this topic ..
Let me explain:
I'm Swift user from day 1. A few weeks after, even with the limitations of
language, had an application in production.

One of the "cool" features that regularly use in my application is the
"file private" access level. Is very better (in practice) than C++
friendly, and enable a lot of different manners to think in our code design.

For example: I have a "hand shake" file, wen two specific types extension
knows about specift (and private) functions to do this "hand shake".

So, my problem is, after almost two years using Swift, "public", "internal"
and "private" is just "so obvious" and very easy to understand, change the
"old" private to something else is not very good.

I can understand the need to "more private" than current private, but who
need this feature?
* devs which do not want declare this "important" type in a different file.
* devs which want to declare more than one type per file to make some "
*friendly*" relationship, but not share some other specific information.
* devs which want to declare more than one type per file and *not* make any
relationship with these types different than public.

Also, I'm not expert, but the actual swift access control appear to enable
some good compiler optimizations, and works very well with top level
objects.

So my proposal is:

- *public* (do not change)
- *internal* (do not change)
- *private* (do not change)
- *protect* (new)

Why protect?

*First*, I believe that is a good word to identify a property that will be
accessed in a specific scope.
*Second*, it will only be used when the person declaring more than one type
in a single file and does not want to share any specific property. I think
this person opt to share the same file for more than one type, the "scope"
access control will be less used than current private (file based) because
a think there less "super private" properties between between those types
for the rest of the module.
*Third*, although I believe that Swift not need (and will not get) access
control only to subtypes, simply update this "protect" is enough (task for
another proposal). And even if the protect switch to "also" share
properties between subtypes, only those who want to put all subtypes in the
same file will lose.

Is impossible to make everyone happy anyway... And i think is good choose
the path which "extends" the rationale of the Swift access control over
these two years instead say "file based access control is now not so
important".



Em qui, 31 de mar de 2016 às 01:22, Chris Lattner via swift-evolution <
swift-evolution@swift.org> escreveu:

> On Mar 23, 2016, at 10:13 PM, Chris Lattner  wrote:
> > How about we continue this trend, and follow other existing Swift
> keywords that merge two lowercase words (associatedtype, typealias, etc),
> and use:
> >
> >   public
> >   moduleprivate
> >   fileprivate
> >   private
> >
> > The advantages, as I see them are:
> > 1) We keep public and private meaning the “right” and “obvious” things.
> > 2) The declmodifiers “read” correctly.
> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
> awkward parenthesized keyword approach.
> > 4) The unusual ones would be “googable”.
> > 5) Support for named submodules could be “dropped in” by putting the
> submodule name/path in parens: private(foo.bar.baz) or
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
> natural than putting keywords in parens.
>
> I’ve seen a number of concerns on this list about moduleprivate, and how
> it penalizes folks who want to explicitly write their access control.  I’ve
> come to think that there is yes-another possible path forward here (which I
> haven’t seen mentioned so far):
>
> public
> internal
> fileprivate
> private
>
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) Compared to Swift 2, there is almost no change.  The only thing that
> changes is that some uses of Swift 2 “private” will be migrated to
> “fileprivate”, which makes the intent of the code much more clear.
> 4) fileprivate is the unusual and
> not-really-precedented-in-other-languages modifier, and it would still be
> “googable”.
> 5) The addresses the “excessively long” declmodifier problem that several
> people are concerned with.
> 6) Support for named submodules could be “dropped in” by parameterizing
> “internal”.
>
> Thoughts?
>
> -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] [swift-evolution-announce] [Review] SE-0057: Importing Objective-C Lightweight Generics

[Brent Royal-Gordon via swift-evolution]

>   * What is your evaluation of the proposal?

I like it, but I have a couple of minor issues with the details.

The first is that type discovery does not support the full richness of either 
language's type system. Both languages allow a type to be either a class or a 
group of protocols, and Objective-C even allows one class + N protocols. I 
believe these methods should permit any valid Objective-C generic type to be 
expressed. That could be achieved by having two methods (plus class method 
variants):

- (nullable Class)classForGenericArgumentAtIndex:(NSUInteger)index; 
// nil means id
- 
(NSArray*)protocolsForGenericArgumentAtIndex:(NSUInteger)index;

The second is the issue of extensions. Rather than rejecting the use of the 
generic type parameter, I think we would be better off treating it as though it 
were a nested typealias. That is, when you write this:

@interface MySet<__covariant ObjectType: id> : NSObject

Then MySet.ObjectType is NSCopying. That would allow you to use ObjectType in 
extensions without particularly caring whether or not you were working with 
full generics.

The third is that I'm troubled by the invisibility of this feature given its 
limitations. I understand why you don't want to implement full type erasure, 
but there should at least be some suggestion of the semantics in the generated 
headers:

class MySet<@erased ObjectType: NSCopying>: NSObject

@erased does not have to actually work in user-written code—it's just there in 
the generated header to mark the type parameter's special semantics.

Finally, this is a severable issue, but I think it's worth mentioning: it would 
be very helpful to expose generic classes back to Objective-C somehow. One of 
my projects has a CaseInsensitiveDictionary type written in Swift; I have 
reference-typed NSObject subclasses to expose it to Objective-C, but these 
can't be generic. Even lightweight generics, even exposed only to Objective-C, 
would make this code a lot better.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. I've missed this type information in Swift.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Swift's interop concerns are pretty unique, in my experience.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Well, I've been drafting this email for several hours. Does that count?

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-evolution-announce] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Russ Bishop via swift-evolution]

This seems like it would be a useful facility in general - the community may be 
able to provide audited headers even if the maintainers of the original project 
have zero interest in merging those changes. That burden is unreasonably high 
if it requires constant merging of the headers.

Russ

> On Mar 31, 2016, at 2:24 PM, Shawn Erickson via swift-evolution 
>  wrote:
> 
> 
> 
> On Thu, Mar 31, 2016 at 9:43 AM Chris Lattner  > wrote:
> That said, this is the sort of proposal that can have a profound impact on 
> the actual experience using unaudited APIs.  The core team believes that the 
> experience will be good, but we would like to get some experience moving a 
> couple of existing projects (both low-level code that interacts with C, and 
> an “App” project working with high level frameworks) to see what the impact 
> is in practice.  If something unexpected comes up, we will revisit this, and 
> potentially reject it later.
> 
> On the topic of unaudited APIs. Does a recommended way exist that I as say a 
> user of on an unaudited C API / library can add attributes to the C API for 
> my use in Swift? (e.g. code that I don't own, I just use)
> 
> It is likely a number of C APIs won't get attributed for improved use in 
> Swift by the authors so having a good way that the community could overlay 
> attributes for the benefit of Swift could be helpful.
> 
> Anything better then cloning headers?
> 
> -Shawn
> ___
> 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] [pre-proposal] Automatic unwrapper boolean properties using unless keyword

[David Waite via swift-evolution]

> On Mar 31, 2016, at 3:54 PM, Guilherme Torres Castro via swift-evolution 
>  wrote:

> Example:
> if !myList?.isEmpty { print("Ok") }

Swift originally had Optionals be boolean evaluable. Unfortunately, nil does 
not always mean false, and assuming so by default can mask issues. I believe 
there may have also been an issue with types being promoted to optional and 
then evaluated as true.

One option here is to use a new custom prefix operator to indicate you desire 
optional == false behavior. I chose “??” in the code below:

prefix operator ?? {}

prefix func ??(arg:Bool?) -> Bool {
  return arg ?? false
}

let data:[String:Bool?] = ["nil": nil, "true": true, "false": false]

for (key, value) in data {
  if ??value {
print(key)
  }
} # prints true

I don’t think a negated form is as clear, since this is a shortcut for two 
checks. However, I wrote one for completeness:

prefix operator ‽‽ {}
prefix func ‽‽(arg:Bool?) -> Bool {
  return !(arg ?? false)
}

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

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

[Max Howell via swift-evolution]

I have updated the proposal with everyone’s feedback:

SwiftPM System Module Search Paths
Proposal: SE- 

Author: Max Howell 
Status: Awaiting review
Review manager: Anders Bertelrud
 
Introduction

Swift is able to import C libraries in the same manner as Swift libraries.

For this to occur the library must be represented by a clang module-map file.

The current system for using these module-map files with SwiftPM works, but 
with a number of caveats that must be addressed.

 
Motivation

The current implementation of system module packages have a number of problems:

Install locations vary across platforms and modulemap files require absolute 
paths
/usr/lib:/usr/local/lib is not always a sufficient -L search path
/usr/include:/usr/local/include is not always a sufficient -I C compiler search 
path
Installing the system library is left up to the end-user to figure out
For example to import a module map representing the GTK library, the include 
search path must be supplemented with -I/usr/include/gtk so that a number of 
includes in the gtk.h header can be sourced for the complete modular definition 
of GTK.

For example to import a module map representing the GTK library a user must 
first have a copy of GTK and its headers installed. On Debian based systems the 
install name for this system package is libgtk-3-0-dev which is not entirely 
intuitive.

For example, Homebrew and MacPorts on OS X install to prefixes other than /usr. 
.modulemap files must specify headers with absolute paths. The standard we 
encourage with modulemaps is for the headers to be specified with an assumed 
prefix of /usr, but you will not find eg. jpeglib.h at /usr/include/jpeglib.h 
if it is installed with Homebrew or MacPorts.

 
Proposed
 Solution

We propose that SwiftPM gains the ability to use the cross-platform pkg-config 
tool so that it can query pkg-config for the missing path and flag arguments.

We propose that SwiftPM gains the ability to use the cross-platform pkg-config 
tool to identify when the system package is not installed to a /usr and in such 
a case preprocess the modulemap changing the prefix it uses.

We propose that Package.swift is supplemented with metadata that provides the 
package-install-name for specific platforms.

 
Detailed
 Design

 
Solving
 Path/Flags Issues

Some of our problems can be solved by using the cross platform tool: pkg-config.

A C package can provide a pkg-config file (.pc) which describes:

Its install location
Supplementary C-flags that should be used when compiling against this library
Supplementary C-flags that should be used when linking against this library
If SwiftPM used the .pc file that comes with packages, this solves problems 1 
through 3.

Of the tickets we currently have open describing issues using 
Swift-system-module-packages, reading the .pc file would fix all of them.

It is a convention to name the .pc file after the library link-name, so we can 
determine which .pc file to ask pkg-configfor by parsing the .modulemap file in 
the Swift package. However sometimes this is not true, (eg. GTK-3 on Ubuntu), 
so we will make it possible to specify the .pc file name in Package.swift.

pkg-config is not currently a dependency of the Swift toolchain, and thus to 
avoid depending on it we will schedule work to interpret .pc files without 
requiring pkg-config to be installed. The file format for .pc files is simple 
and standard so despite reinventing the wheel, this is a low risk choice.

 
Providing
 Package Install Names

Package.swift would be supplemented like so:

let package = Package(
name: "CFoo",
providers: .Brew(installName: "foo"),
.Apt(installName: "libfoo-dev"),
  .PkgConfig("foo.pc"),
)
Thus, in the event of build failure for modules that depend on this package we 
provide additional help to the user:

error: failed to build module `bar'
note: you may need to install `foo' using your system-packager:

apt-get install libfoo-dev

Re: [swift-evolution] [pre-proposal] Automatic unwrapper boolean properties using unless keyword

[Charles Srstka via swift-evolution]

> On Mar 31, 2016, at 5:04 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> What I often do is use ?? to provide a default (usually false).
> 
> if myList?.isEmpty ?? false {
> print(“Empty”)
> } else {
> print(“Not empty”)
> }

That’s what I get for writing a reply quickly; in this particular case the 
default should probably be true, since you probably want to treat a nil list as 
empty.

if myList?.isEmpty ?? true {
print(“Empty”)
} else {
print(“Not empty”)
}

Charles

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[David Waite via swift-evolution]

+1

We need to support optional methods in @objc protocols because it is required 
for interoperability. However, there are in my experience only reasons for an 
optional protocol method:

- There is a very common default behavior for a delegate (such as return 
immediately with a value of 0/nil/false) which would be a burden to require 
everyone to implement. We can instead accomplish this with protocol extensions

- The absence of a method in a delegate indicates a behavior that is otherwise 
impossible for the delegate to implement. The easiest example of this would be  
tableView:heightForRowAtIndexPath:, where the absence triggers an optimization 
where UITableView.rowHeight is used for all math, and its presence means that 
performance will be degraded, and the delegate will be called repeatedly for 
every single index path in order to figure out the table positioning/scroll 
height. I believe this has been shown to be much better solved via an optional 
additional protocol conformance to indicate that you are supporting a different 
‘class’ of behavior, in this case that might be something like 
UITableViewVaribleHeightDelegate.

I’d hate for there to be a push for optional protocol methods just because it 
can be confusing which methods are required in swift protocol implementations 
(vs defaulted by a protocol extension).

-DW

> On Mar 31, 2016, at 12:23 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Mar 30 2016, Yuval Tal  wrote:
> 
>> Hi,
>> 
>> I find that optional protocol methods to be very useful. However,
>> there is a caveat -- it needs to be mapped to @objc.  This puts a set
>> of limitations, such as: structures cannot be used as parameters as it
>> does not map to objective-c. What do you think about removing the
>> requirement of using @objc and allow to create optional methods
>> without these limitations?
> 
> Caveat: this is going to be strongly-worded; sorry in advance.  I think
> (no offense intended) it's a terrible idea.  The whole notion of an
> “optional requirement” is nonsensical to begin with, and the use of
> optional protocol requirements encourages a style of programming that
> lifts the responsibility of the protocol designer for careful design at
> the expense of clients of the protocol.  There are better ways to do
> things; let's not propagate this anti-pattern any further than it's
> already gone.
> 
> --
> Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matt Whiteside via swift-evolution]

> So, proposal one (and 1b), more technical sounding
> 
> public
> internal (or intramodule)
> intrafile
> private
`intrafile` and `intramodule` sound esoteric to me.

I like these ones better:

public
moduleonly
fileonly
private//aka, scopeonly? unfortunate that this isn’t automatically clear 



Tino’s suggestion is also interesting:

visible(public)
visible(module)
visible(file)
visible(scope)
visible(file, ModuleA, File.swift)

But I think the paren syntax suggested earlier is equivalent, and would be the 
clearest to both experienced and beginning developers:

public
private(module)
private(file)
private(scope)

If parens are a no-go, perhaps the following could work:

public
privatetomodule
privatetofile
privatetoscope

I’m not a huge fan of `fileprivate` or `moduleprivate`, because they seem like 
strange non-words.

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

Re: [swift-evolution] [pre-proposal] Automatic unwrapper boolean properties using unless keyword

[Charles Srstka via swift-evolution]

What I often do is use ?? to provide a default (usually false).

if myList?.isEmpty ?? false {
print(“Empty”)
} else {
print(“Not empty”)
}

The other thing you can do, of course, is to use a ‘where’ statement:

if let list = myList where list.isEmpty {
print(“Empty”)
} else {
print(“Not empty”)
}

Charles

> On Mar 31, 2016, at 4:54 PM, Guilherme Torres Castro via swift-evolution 
>  wrote:
> 
> Hello,
> 
> This is a Idea I got from Objetive-C, where nil is evaluate no false, this 
> feature can keep the code clean. For example:
> 
> if (![myList isEmpty]) { ... }
> Will evaluate true or false even if myList is nil.
> I know that Swift is not Design to work like Objetive-C, but sometimes this 
> make the code cleaner.  
> 
> Example:
> if !myList?.isEmpty { print("Ok") }
> This is much more cleaner and easy to read than:
> 
> if !(myList != nill && mylist!.isEmpty) { print("Ok") }
> Moreover the tip from the Xcode (when you type the  lead user to generate 
> wrong code when you type this code :
> 
> if !((myList?.isEmpty)) != nil { print("Ok") }
> As you can see the suggestion made by the Xcode will not work, because event 
> if the list is empty the expression will return true.
> 
> My ideia is to use some special syntax that permit optional to be evaluate to 
> boolean expression. Those syntax may be like in ruby 
> . 
> 
> 
> code if condition
> So the code from the example will be:
> 
> print ("Ok") if !myList?.isEmpty
> Or using the unless keyword:
> 
> unless myList?.isEmpty print("not empty") else print "empty"
> 
> I didn't spent much time thinking about the syntax keyword, because I want to 
> know first if you will consider a great addition to the language, if so, we 
> can work on details and a formal proposal.
> 
> 
> 
> ___
> 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] Draft Proposal SwiftPM System Module Search Paths

[Max Howell via swift-evolution]

> On Mar 26, 2016, at 12:15 PM, Ankit Agarwal  > wrote:
> 
> It is a convention to name the .pc file after the library link-name, so we 
> can determine which .pc file to ask pkg-config for by parsing the .modulemap 
> file in the Swift package.
> 
> what about the cases where .pc file doesn't matches the link-name from 
> modulemap for eg : gtk+2 or 3 has these link-names: `link "gtk-2.0"`, `link 
> "gtk-3.0"` and .pc files are `gtk+-2.0.pc`, `gtk+-3.0.pc`
> 
> One option could be an optional in Package -> `pkgconfig: "gtk+-2.0"`
> 
> 
> 
> Probably not in scope of this proposal, I noticed that pkg-config can give 
> versions of the system libs, would it be a good idea for user to mention a 
> version range of system lib while creating the modulemap wrapper package.

Our decision here was that if you have CFoo then CFoo2 is the name of the 
package for the major version bump to 2.

The rationale for this is: this is how it basically works in the C library 
packaging system currently.

Major version bumps are much rarer and the approach taken by system packagers 
has been to make entirely new packages for them. Even the .pc files are 
versioned thus, at least, this is all I’ve ever seen.

It’s not clean, but we’re building on top of what is there.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Shawn Erickson via swift-evolution]

On Thu, Mar 31, 2016 at 9:43 AM Chris Lattner  wrote:

> That said, this is the sort of proposal that can have a profound impact on
> the actual experience using unaudited APIs.  The core team believes that
> the experience will be good, but we would like to get some experience
> moving a couple of existing projects (both low-level code that interacts
> with C, and an “App” project working with high level frameworks) to see
> what the impact is in practice.  If something unexpected comes up, we will
> revisit this, and potentially reject it later.
>

On the topic of unaudited APIs. Does a recommended way exist that I as say
a user of on an unaudited C API / library can add attributes to the C API
for my use in Swift? (e.g. code that I don't own, I just use)

It is likely a number of C APIs won't get attributed for improved use in
Swift by the authors so having a good way that the community could overlay
attributes for the benefit of Swift could be helpful.

Anything better then cloning headers?

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Developer via swift-evolution]

To be fair, the "spirit of UIKit" that you mention comes from a time and 
language that encouraged OO and OO alone.  Optional methods are, more often 
than not, backed by gigantic bit fields that keep track of whether or not the 
delegate actually conforms to the entirety of a protocol, which opens up a huge 
vector for bugs and complicates the internal logic of the control.  I think 
Swift gives us a better opportunity to rethink the old approach not encourage 
it, don't you think?

For example, using a method returning an optional (or even better, a proper 
value) means you can give a proper semantics for what it means to not implement 
a particular method rather than "no selector here".  

~Robert Widmann

2016/03/31 14:49、Yuval Tal via swift-evolution  
のメッセージ:

> None taken. However, most of the delegate concept of UIKit relies heavily on 
> this "nonsensical" requirement. It is impossible for someone to implement a 
> control in swift which is "in the spirit" of UIKit, meaning the control has a 
> delegate, with several methods that share the same name with different 
> parameters, some are required and some are optional. I think it is not fair 
> to tell users that they cannot implement something that is such a common and 
> repeating pattern in the core. 
> 
>> On Thu, Mar 31, 2016 at 2:23 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> on Wed Mar 30 2016, Yuval Tal  wrote:
>> 
>> > Hi,
>> >
>> > I find that optional protocol methods to be very useful. However,
>> > there is a caveat -- it needs to be mapped to @objc.  This puts a set
>> > of limitations, such as: structures cannot be used as parameters as it
>> > does not map to objective-c. What do you think about removing the
>> > requirement of using @objc and allow to create optional methods
>> > without these limitations?
>> 
>> Caveat: this is going to be strongly-worded; sorry in advance.  I think
>> (no offense intended) it's a terrible idea.  The whole notion of an
>> “optional requirement” is nonsensical to begin with, and the use of
>> optional protocol requirements encourages a style of programming that
>> lifts the responsibility of the protocol designer for careful design at
>> the expense of clients of the protocol.  There are better ways to do
>> things; let's not propagate this anti-pattern any further than it's
>> already gone.
>> 
>> --
>> Dave
>> 
>> ___
>> 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] Make optional protocol methods first class citizens

[Sean Heber via swift-evolution]

> Caveat: this is going to be strongly-worded; sorry in advance.  I think
> (no offense intended) it's a terrible idea.  The whole notion of an
> “optional requirement” is nonsensical to begin with, and the use of
> optional protocol requirements encourages a style of programming that
> lifts the responsibility of the protocol designer for careful design at
> the expense of clients of the protocol.  There are better ways to do
> things; let's not propagate this anti-pattern any further than it's
> already gone.

This is why my suggestion to solve this required the protocol to include 
default values for any optional function with a return value - I don’t think 
that a function should be optional as in “no presence” or even in a way that 
the caller can identify if the function is or isn’t defined, but just optional 
as in “it has a clear documented default.” I don’t agree that the caller of an 
optional protocol function should be able to tell if the function is present or 
not - the protocol itself should be defined as if all functions are there, but 
the “optional-ness” is then no worse than default values on function parameters 
- but that might just be me.

Perhaps a better term for my way of thinking about it would be “default” rather 
than optional:

protocol UIGestureRecognizerDelegate {
 default func gestureRecognizerShouldBegin(gestureRecognizer: 
UIGestureRecognizer) -> Bool = true
 // etc
}

l8r
Sean

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Yuval Tal via swift-evolution]

None taken. However, most of the delegate concept of UIKit relies heavily
on this "nonsensical" requirement. It is impossible for someone to
implement a control in swift which is "in the spirit" of UIKit, meaning the
control has a delegate, with several methods that share the same name with
different parameters, some are required and some are optional. I think it
is not fair to tell users that they cannot implement something that is such
a common and repeating pattern in the core.

On Thu, Mar 31, 2016 at 2:23 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Wed Mar 30 2016, Yuval Tal  wrote:
>
> > Hi,
> >
> > I find that optional protocol methods to be very useful. However,
> > there is a caveat -- it needs to be mapped to @objc.  This puts a set
> > of limitations, such as: structures cannot be used as parameters as it
> > does not map to objective-c. What do you think about removing the
> > requirement of using @objc and allow to create optional methods
> > without these limitations?
>
> Caveat: this is going to be strongly-worded; sorry in advance.  I think
> (no offense intended) it's a terrible idea.  The whole notion of an
> “optional requirement” is nonsensical to begin with, and the use of
> optional protocol requirements encourages a style of programming that
> lifts the responsibility of the protocol designer for careful design at
> the expense of clients of the protocol.  There are better ways to do
> things; let's not propagate this anti-pattern any further than it's
> already gone.
>
> --
> Dave
>
> ___
> 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] [Review] SE-0057: Importing Objective-C Lightweight Generics

[Zach Waldowski via swift-evolution]

Responses inline!

Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Thu, Mar 31, 2016, at 02:11 PM, Chris Lattner via swift-evolution
wrote:
>   * What is your evaluation of the proposal?

The strongest of +1's. It will allow much greater flexibility for the
bridge, both in our own code and Apple's frameworks.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. Like SE-0055, it's mildly ironic that these new features can
occasionally be more expressive or compiler-checked by Clang than by
Swift.

>   * Does this proposal fit well with the feel and direction of Swift?

At the high-level, absolutely. More generics = safer and smarter code.

At the lower-level, I'm somewhat concerned about the mismatch between
the Swift side of lightweight generics vs. honest-to-god Swift generics.
As an instructor, I worry that the limitations may make learning
generics even more hairy. Considering "Restrictions on uses of
Objective-C parameterized classes" (while all the restrictions
completely make sense), I wonder how difficult it'll be to explain why
in a given specific instance (i.e., pulling a value out of a [String:
AnyObject]) can't be casted.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

I've used type-erased generics before in other languages. While not
preferable when you have something like Swift's implementation, this is
acceptable for a bridge.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I've been considering the effects of this feature since bridging came to
ObjC, really excited to see it. Quick glance at the proposal itself.

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

A couple of questions, since this proposal hasn't had the regular
Evolution run-through:

1. The section "Importing unspecialized types" makes reference to
defaulting to the unbound requirement when something isn't annotated in
Objective-C. This is notably something that isn't true in Swift at
present (i.e., a T: ErrorType can't be satisfied by ErrorType). Would
this be a change that comes generalized to Swift, or is just true of the
lightweight generics bridge.

2. How undefined is the undefined behavior in things coming from
Objective-C? If something is exposed into Swift as one type bounds, but
for legacy or bug reasons, another class is pushed across the bridge,
precisely what color will the resulting explosion be at runtime?

3. Re: "Opting in to type argument discovery", how would initialization
look for GKComponentSystem? Having to do
GKComponentSystem(componentClass: SomeType.self) would be
pretty onerous. Would this have to be treated in the overlay framework
too as well?

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Erica Sadun via swift-evolution]

> On Mar 31, 2016, at 12:29 PM, Stephen Canon via swift-evolution 
>  wrote:
> 
> I also don’t think that such a loop is particularly useful.  For 
> floating-point types, something like stride(from: T, to: T, steps: Int) seems 
> safer and more workable to me (this is just my immediate reaction, I haven’t 
> thought this through in detail, and am likely to change my mind if someone 
> makes a good case).


While I do not object to n-steps, allowing a step difference is equally 
important in my opinion.
"I want to sample every n deciRuncibles" versus "I want to sample 8 times 
between 1 deciRuncible 
and 10 deciRuncibles"

I disagree that the former is less useful than the latter.

-- E

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Brandon Knope via swift-evolution]

I'd be okay with this, but I do think having a private and fileprivate will 
confuse people considering they both have private in their names

Brandon 

Sent from my iPad

> On Mar 31, 2016, at 12:22 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  wrote:
>> How about we continue this trend, and follow other existing Swift keywords 
>> that merge two lowercase words (associatedtype, typealias, etc), and use:
>> 
>>public
>>moduleprivate
>>fileprivate
>>private
>> 
>> The advantages, as I see them are:
>> 1) We keep public and private meaning the “right” and “obvious” things.
>> 2) The declmodifiers “read” correctly.
>> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
>> parenthesized keyword approach.
>> 4) The unusual ones would be “googable”.
>> 5) Support for named submodules could be “dropped in” by putting the 
>> submodule name/path in parens: private(foo.bar.baz) or 
>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
>> natural than putting keywords in parens.
> 
> I’ve seen a number of concerns on this list about moduleprivate, and how it 
> penalizes folks who want to explicitly write their access control.  I’ve come 
> to think that there is yes-another possible path forward here (which I 
> haven’t seen mentioned so far):
> 
> public
> internal
> fileprivate
> private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) Compared to Swift 2, there is almost no change.  The only thing that 
> changes is that some uses of Swift 2 “private” will be migrated to 
> “fileprivate”, which makes the intent of the code much more clear.
> 4) fileprivate is the unusual and not-really-precedented-in-other-languages 
> modifier, and it would still be “googable”.
> 5) The addresses the “excessively long” declmodifier problem that several 
> people are concerned with.
> 6) Support for named submodules could be “dropped in” by parameterizing 
> “internal”.
> 
> Thoughts?
> 
> -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] Feature proposal: Range operator with step

[Rainer Brockerhoff via swift-evolution]

On 3/31/16 15:29, Stephen Canon via swift-evolution wrote:
> 
>> On Mar 31, 2016, at 11:16 AM, Rainer Brockerhoff via swift-evolution 
>>  wrote:
>>
>> On 3/31/16 15:06, Dave Abrahams via swift-evolution wrote:
>>>...
>>> I think I want to hear Steve Canon's input on this one.  I defer to him
>>> on most things numeric.
>>
>> In particular, should Steve confirm that the IEEE754 Decimal128 format
>> is being worked on, and if simple decimal constants like those in
>>  `for i in stride(from: 0.0, to: DBL_MAX, by: DBL_MIN) { }`
>> will be type-inferred as Decimal128, all that would "just work".
> 
> Decimal is something that I would like to see happen.  However, I
> would not expect any such proposal to result in that loop being type
> inferred to Decimal, since the to: and by: values are explicitly
> (binary floating-point) Doubles.

Oopsie. Pressed 'send' accidentally before re-editing this to
for i in stride(from: 0.0, to: 1.0, by: 0.1)...
Sorry about that.

> I also don’t think that such a loop is particularly useful.  For
> floating-point types, something like stride(from: T, to: T, steps:
> Int) seems safer and more workable to me (this is just my immediate
> reaction, I haven’t thought this through in detail, and am likely to
> change my mind if someone makes a good case).

`steps:` is OK for me too, though certain people would probably be
compelled to write, say,
stride(from: floatA, to: floatB, steps: (floatB-floatA/0.1) )
perish forbid.

-- 
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Stephen Canon via swift-evolution]

> On Mar 31, 2016, at 11:16 AM, Rainer Brockerhoff via swift-evolution 
>  wrote:
> 
> On 3/31/16 15:06, Dave Abrahams via swift-evolution wrote:
>> 
>> on Thu Mar 31 2016, Xiaodi Wu  wrote:
>> 
>>> Thoughts on an edge case: so long as it's possible to use
>>> `stride(from:to:by:)` with Double, we'll need to figure out what
>>> happens when you have `stride(from: 0.0, to: DBL_MAX, by: DBL_MIN)`.
>>> Bounds may be unknown at compile time, obviously.
>>> 
>>> Currently (this is by reasoning through the code, not actually
>>> observing it run), `for i in stride(from: 0.0, to: DBL_MAX, by:
>>> DBL_MIN) { }` degenerates into an infinite loop once you reach
>>> sufficient large values such that `current + stride == current`, which
>>> for a stride of DBL_MIN should happen pretty quickly.
>>> 
>>> In Erica's proposed floating point Stride, an Int is used to count
>>> iterations (and iterations need to be counted in order to avoid
>>> accumulating error). Thus, one must break from `for i in stride(from:
>>> 0.0, to: DBL_MAX, by: DBL_MIN) { }` before the iteration counter
>>> overflows or it will trap. IMO, trapping at some point is fine, but I
>>> think a limit of Int.max iterations might be rather arbitrary for a
>>> StrideTo (or whatever it will be named) and I'm not sure how
>>> one can justify why the behavior of StrideTo would change from
>>> machine to machine based on the size of Int.
>>> 
>>> I've been waffling between using an Int counter as Erica does or a
>>> counter of type Strideable.Stride in `StrideTo>> Strideable.Stride : FloatingPoint>`. In the latter alternative, no
>>> trapping occurs, but error begins to accumulate when the iteration
>>> counter is too large to represent integers exactly (e.g., 2^53 for
>>> Double). In that case, `for i in stride(from: 0.0, to: DBL_MAX, by:
>>> DBL_MIN) { }` degenerates into an infinite loop eventually (once
>>> `iterationCount + 1.0 == iterationCount`) and never traps, which I'm
>>> not sure I like, but a limit of 2^53 iterations bears at least a
>>> rational connection to Double and is known at compile time independent
>>> of the supplied bounds. We could alternatively return nil on reaching
>>> 2^53 iterations, trap, etc.
>>> 
>>> Comments?
>> 
>> I think I want to hear Steve Canon's input on this one.  I defer to him
>> on most things numeric.
> 
> In particular, should Steve confirm that the IEEE754 Decimal128 format
> is being worked on, and if simple decimal constants like those in
>   `for i in stride(from: 0.0, to: DBL_MAX, by: DBL_MIN) { }`
> will be type-inferred as Decimal128, all that would "just work".

Decimal is something that I would like to see happen.  However, I would not 
expect any such proposal to result in that loop being type inferred to Decimal, 
since the to: and by: values are explicitly (binary floating-point) Doubles.

I also don’t think that such a loop is particularly useful.  For floating-point 
types, something like stride(from: T, to: T, steps: Int) seems safer and more 
workable to me (this is just my immediate reaction, I haven’t thought this 
through in detail, and am likely to change my mind if someone makes a good 
case).

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Dave Abrahams via swift-evolution]

on Wed Mar 30 2016, Yuval Tal  wrote:

> Hi,
>
> I find that optional protocol methods to be very useful. However,
> there is a caveat -- it needs to be mapped to @objc.  This puts a set
> of limitations, such as: structures cannot be used as parameters as it
> does not map to objective-c. What do you think about removing the
> requirement of using @objc and allow to create optional methods
> without these limitations?

Caveat: this is going to be strongly-worded; sorry in advance.  I think
(no offense intended) it's a terrible idea.  The whole notion of an
“optional requirement” is nonsensical to begin with, and the use of
optional protocol requirements encourages a style of programming that
lifts the responsibility of the protocol designer for careful design at
the expense of clients of the protocol.  There are better ways to do
things; let's not propagate this anti-pattern any further than it's
already gone.

-- 
Dave

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

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

[Dave Abrahams via swift-evolution]

on Wed Mar 30 2016, Jeremy Pereira  wrote:

>> On 25 Mar 2016, at 23:00, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> In the low level world, there is no such thing as an invalid
>>> address; both 0x0 and ~0x0 are perfectly valid byte pointers. So
>>> using something else than 0x0 for Swift invalid pointer just
>>> shuffle the problem around.
>> 
>> Let me state it this way: You cannot write a fully-conforming C
>> compiler for a platform which does not have some way to represent an
>> invalid pointer.
>
> This is not true.
>
> In both C99 and C11, the result of dereferencing an invalid pointer
> (of which the null pointer is one example) 

The null pointer is valid, it's just not dereferenceable.  Invalid
pointers can't even be compared with one another.

> is undefined behaviour. This means it is perfectly fine for the null
> pointer to be represented by a bit pattern that is also a valid
> address and for the compiler not to bother generating a check that the
> pointer is not null.
>
>> However C does it, Swift can do the same thing.
>
> C does it by sweeping the problem under the carpet of undefined behaviour.
>
>> 
>> -- 
>> 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

-- 
Dave

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

[swift-evolution] [Review] SE-0057: Importing Objective-C Lightweight Generics

[Chris Lattner via swift-evolution]

Hello Swift community,

The review of "Importing Objective-C Lightweight Generics" begins now and runs 
through April 5. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at:
https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review 
manager.


What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


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

Re: [swift-evolution] Feature proposal: Range operator with step

[Dave Abrahams via swift-evolution]

on Thu Mar 31 2016, Xiaodi Wu  wrote:

> Thoughts on an edge case: so long as it's possible to use
> `stride(from:to:by:)` with Double, we'll need to figure out what
> happens when you have `stride(from: 0.0, to: DBL_MAX, by: DBL_MIN)`.
> Bounds may be unknown at compile time, obviously.
>
> Currently (this is by reasoning through the code, not actually
> observing it run), `for i in stride(from: 0.0, to: DBL_MAX, by:
> DBL_MIN) { }` degenerates into an infinite loop once you reach
> sufficient large values such that `current + stride == current`, which
> for a stride of DBL_MIN should happen pretty quickly.
>
> In Erica's proposed floating point Stride, an Int is used to count
> iterations (and iterations need to be counted in order to avoid
> accumulating error). Thus, one must break from `for i in stride(from:
> 0.0, to: DBL_MAX, by: DBL_MIN) { }` before the iteration counter
> overflows or it will trap. IMO, trapping at some point is fine, but I
> think a limit of Int.max iterations might be rather arbitrary for a
> StrideTo (or whatever it will be named) and I'm not sure how
> one can justify why the behavior of StrideTo would change from
> machine to machine based on the size of Int.
>
> I've been waffling between using an Int counter as Erica does or a
> counter of type Strideable.Stride in `StrideTo Strideable.Stride : FloatingPoint>`. In the latter alternative, no
> trapping occurs, but error begins to accumulate when the iteration
> counter is too large to represent integers exactly (e.g., 2^53 for
> Double). In that case, `for i in stride(from: 0.0, to: DBL_MAX, by:
> DBL_MIN) { }` degenerates into an infinite loop eventually (once
> `iterationCount + 1.0 == iterationCount`) and never traps, which I'm
> not sure I like, but a limit of 2^53 iterations bears at least a
> rational connection to Double and is known at compile time independent
> of the supplied bounds. We could alternatively return nil on reaching
> 2^53 iterations, trap, etc.
>
> Comments?

I think I want to hear Steve Canon's input on this one.  I defer to him
on most things numeric.

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

Re: [swift-evolution] SetAlgebra naming update

[Dave Abrahams via swift-evolution]

on Thu Mar 31 2016, Thorsten Seitz  wrote:

> Am 30. März 2016 um 17:48 schrieb Dave Abrahams :
>
> on Wed Mar 30 2016, Thorsten Seitz  wrote:
>
> Am 30.03.2016 um 16:49 schrieb Dave Abrahams 
> :
>
> on Wed Mar 30 2016, Thorsten Seitz 
>  wrote:
>
> That's certainly an improvement, but why 
> "formIntersection" instead of
>
> "intersect" (in analogy to "subtract")?
>
> 1. Consistency with union, which is more closely related than 
> subtract.
>
> I'd prefer consistency with the verb rule here
>
> Which rule is that? As far as I can tell, this is consistent with all
> the rules.
>
> "Those with side-effects should read as imperative verb phrases"

“form ” is an imperative verb phrase.

> I expect a common verb to be chosen over an awkward, constructed one,
> although I have to admit that the verb "intersect" is used only very
> seldom if at all in set theory or geometry.  Therefore you might have
> a point with "intersect" having the wrong implication, but see below.
>
> (using formXXX only as last resort).
>
> Though I prefer not to, you can look at this as a last resort if you
> like; the alternative you're proposing has the wrong implication, so it
> is not a candidate. It would be like using “remainder” as a verb for
> integers. Yes, it's a legitimate verb, but it means the wrong thing
> (see retail).
>
> 2. "Intersect" actually has the wrong meaning as an 
> imperative. If you
>
> tell set A to intersect set B, and then ask whether A intersects B
>
> (!A.isDisjoint(with: B)), you would expect an answer of true.
>
> Sorry, but I do not agree. With that reasoning I would have to expect
>
> a.intersection(b) to be not empty.
>
> Yes, that's exactly what I'm saying. If you tell A to intersect B,
> presumably when the call completes, A intersects B (i.e. has a non-empty
> intersection). That would imply an implementation like, e.g.
>
> With a.intersection(b) I meant to extend your reasoning to the
> non-mutating method. 
>
> You surely do not expect the intersection of a and b to be non-empty
> when calling the non-mutating method? 

No I do not.

> Then why should you expect that in the mutating case?  

for the same reason that 

shape1.encloses(shape2)

might return true or false but

shape1.enclose(shape2)

has to change shape1 so it encloses shape2.

> Is it because the noun implies a current state whereas the verb should
> be read as a command demanding to create a certain state? (I'm not a
> native speaker, so please bear with me)

I think that's a pretty good explanation.

HTH,

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu via swift-evolution]

Thoughts on an edge case: so long as it's possible to use
`stride(from:to:by:)` with Double, we'll need to figure out what
happens when you have `stride(from: 0.0, to: DBL_MAX, by: DBL_MIN)`.
Bounds may be unknown at compile time, obviously.

Currently (this is by reasoning through the code, not actually
observing it run), `for i in stride(from: 0.0, to: DBL_MAX, by:
DBL_MIN) { }` degenerates into an infinite loop once you reach
sufficient large values such that `current + stride == current`, which
for a stride of DBL_MIN should happen pretty quickly.

In Erica's proposed floating point Stride, an Int is used to count
iterations (and iterations need to be counted in order to avoid
accumulating error). Thus, one must break from `for i in stride(from:
0.0, to: DBL_MAX, by: DBL_MIN) { }` before the iteration counter
overflows or it will trap. IMO, trapping at some point is fine, but I
think a limit of Int.max iterations might be rather arbitrary for a
StrideTo (or whatever it will be named) and I'm not sure how
one can justify why the behavior of StrideTo would change from
machine to machine based on the size of Int.

I've been waffling between using an Int counter as Erica does or a
counter of type Strideable.Stride in `StrideTo`. In the latter alternative, no
trapping occurs, but error begins to accumulate when the iteration
counter is too large to represent integers exactly (e.g., 2^53 for
Double). In that case, `for i in stride(from: 0.0, to: DBL_MAX, by:
DBL_MIN) { }` degenerates into an infinite loop eventually (once
`iterationCount + 1.0 == iterationCount`) and never traps, which I'm
not sure I like, but a limit of 2^53 iterations bears at least a
rational connection to Double and is known at compile time independent
of the supplied bounds. We could alternatively return nil on reaching
2^53 iterations, trap, etc.

Comments?


On Wed, Mar 30, 2016 at 1:42 PM, Dave Abrahams  wrote:
>
> on Tue Mar 29 2016, Xiaodi Wu  wrote:
>
>> On Tue, Mar 29, 2016 at 7:48 PM, Dave Abrahams  wrote:
>>>
>>> on Tue Mar 29 2016, Xiaodi Wu  wrote:
>>>
 Relatedly, while you're tackling this big revision:

>>
 I've tried to play around with what it would take to write a generic
 non-error-accumulating striding method, and afaict, it would be
 enormously cleaner if Strideable types are guaranteed to have + and *
 (well, Strideable.Stride needs *, to be more accurate),
>>>
>>> That should happen automatically, since it conforms to SignedNumber,
>>> when we get the Integer protocols updated (project currently on hold while
>>> we land this other revision).
>>>
 since the iterator needs to be able to compute end = start + iteration
 * stride.
>>>
>>> Don't you need division too if you're going to do this?
>>
>> I didn't seem to ever need division. See attached playground (which
>> borrows shamelessly from existing code and Erica's proposal, and which
>> is written in Swift 2.2 because that's what I had handy).
>
> I guess it depends what semantics you want.  Maybe the semantics that
> need division are better suited to a different API:
>
>   (a..
 Is that going to be exposed somewhere in the cascade of numeric
 protocols that culminate in Strideable?
>>>
>>> That's not in the plan.  I'm pretty sure we want UnsafePointer to be
>>> Strideable and we don't want it to have multiplication or division.
>>
>> You're right. The type itself doesn't need to have multiplication or
>> division. In fact, writing this, I'm going back and changing my
>> playground a bit. It's sufficient that UnsafePointer.Stride can be
>> multiplied, and if SignedNumber conformance will guarantee
>> multiplication for all conforming types, we're all set for floating
>> point.
>>
>>>
>>> I was thinking the StrideSequence (or some such) should be exposed as an
>>> associated type of the Strideable, so it can be as efficient as possible
>>> when no FP error is possible.  We don't want to spend divisions on
>>> striding over Ints.
>>
>> Right, multiplication or division best avoided here. Not sure what the
>> associated type StrideSequence would be for though?
>
> Well, the multiplications can likely be optimized away, so maybe it's a
> non-issue. It's really worth looking at the code you get at -O, to see
> if we can avoid complicating the API.
>
> The thinking was that a Strideable type could have a StrideSequence with
> a default of StrideByAdding, while FloatingPoint types would use
> StrideSequence = StrideByMultiplying.
>
>> Are you aiming for one StrideTo type and one StrideThrough type
>> instead of two apiece
>
> Either way would be reasonable, depending on how well it optimizes.
>
>> , one for floating point and one for integer?
>
> No, one for FP and one for most everything else.
>
>> I've been lazy and overloading `stride(from:to:by:)` instead, but
>> there's a lot of repeated code.
>>
>>>
 On Mon, Mar 28, 2016 at 7:45 PM Dave Abrahams via 

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

[Javier Soto via swift-evolution]

I have never taken advantage of this. In fact, I didn't know this was
possible until just now :) and I would've definitely found it confusing to
see a function call with "out of order" parameters.
On Thu, Mar 31, 2016 at 7:58 AM Developer via swift-evolution <
swift-evolution@swift.org> wrote:

> +1
>
> ~Robert Widmann
>
> 2016/03/31 10:26、Jeff Kelley via swift-evolution <
> swift-evolution@swift.org> のメッセージ:
>
> I have never taken advantage of this, personally. Given that there isn’t
> anything that this feature enables that can’t be done if it’s removed—aside
> from reordering arguments—I’d be in favor of removing it for simplicity’s
> sake.
>
> Jeff Kelley
>
> slauncha...@gmail.com | @SlaunchaMan  |
> jeffkelley.org
>
> On Mar 30, 2016, at 12:59 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Many people are surprised when they find out defaulted parameters can be
> reordered, unlike required arguments. This special case adds complexity to
> the language, and runs against our general trend of treating argument
> labels as a significant part of an API's name, and preferring a single way
> of writing API calls. I think it's worth revisiting this design choice—is
> the special case worth the complexity? How many people take advantage of
> default argument reordering?
>
> -Joe
>
> ___
> 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
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Chris Lattner via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md

The review of SE-0054 "Abolish ImplicitlyUnwrappedOptional type" ran from Mar 
25…30, 2016. The proposal has been *accepted, pending implementation 
experience*:

There is generally positive feedback on the proposal, as it keeps the good 
behaviors of the existing T! type syntax (including support for importing 
un-nullability-audited APIs, support for 2-phase initialization patterns, etc) 
while dramatically reducing the confusion and surprise that they introduce as 
they trickle through type inference.  The core team sees significant value in 
having a simple and predictable model that can be explained concisely. 

That said, this is the sort of proposal that can have a profound impact on the 
actual experience using unaudited APIs.  The core team believes that the 
experience will be good, but we would like to get some experience moving a 
couple of existing projects (both low-level code that interacts with C, and an 
“App” project working with high level frameworks) to see what the impact is in 
practice.  If something unexpected comes up, we will revisit this, and 
potentially reject it later.  Chris Willmore is working on an implementation of 
this now, so we should know in the next week or two.

Thank you to Chris Willmore for driving this forward!

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

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

[Thorsten Seitz via swift-evolution]

> Am 31.03.2016 um 17:51 schrieb Joe Groff :
> 
>> 
>> On Mar 30, 2016, at 11:31 PM, Thorsten Seitz  wrote:
>> 
>> 
>> 
>> Am 31. März 2016 um 05:15 schrieb Andrey Tarantsov via swift-evolution 
>> :
>> 
 The problem with protected is that it provides virtually no protection at 
 all; you can trivially expose it in a derived class
>>> 
>>> +
>>> 
 Extensions further dilute the enforceability of "protected", since anyone 
 would be able to use an extension to dump methods into a class's namespace 
 and access its supposedly-protected bits.
>>> 
>>> I don't understand the need to protect against exposing something 
>>> deliberately. We don't have a goal of restricting other developers, we're 
>>> only saving them from accidental mistakes.
>> 
>> Totally agree, access control is not intended to be protection against 
>> hacking. If a derived class wants to expose something then that is 
>> absolutely fine as long as it makes sense for the derived class.
> 
> My point is that "protected" *isn't* access control. If we added it, it would 
> have to be as an independent modifier. Private/internal/public fundamentally 
> affect semantics—private and internal code is only accessible within a 
> module, so we have full knowledge of their use sites at compile time and can 
> be more permissive with extensions, implicit constructors, and other 
> features. Public API can be used by arbitrary unknown external code so 
> requires additional restrictions to ensure that the interface remains stable. 
> "Only usable by subclasses" is an orthogonal axis to this—if a method is only 
> usable by external subclasses, it requires all of the same restrictions as 
> public code. If a method is only usable by subclasses within the module, it 
> can behave like a private or internal method.

Ah, now I understand what you mean! Thanks for clarifying!
I agree that this has to be taken into account when defining what „protected“ 
means and how it interacts with other parts of the language.

-Thorsten


> 
> -Joe
> 
>> 
>> 
 If a method was marked private in the base class, then it is very likely 
 that the name of the method, the design of its argument list and its 
 return value did not go through the same detailed design review as if the 
 method would have been meant to be part of the class’ interface from the 
 start. So it’s rather unlikely that increasing the visibility in an 
 override is good idea and in the spirit of the original writer of the 
 private method.
>>> 
>>> The design review and whether something is a good idea is left as a 
>>> responsibility for those subclasses that choose to expose methods. The 
>>> intentions of the original class author don't override the intentions of 
>>> the subclass author.
>> 
>> Exactly.
>> 
>> -Thorsten

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

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

[Joe Groff via swift-evolution]

> On Mar 30, 2016, at 11:31 PM, Thorsten Seitz  wrote:
> 
> 
> 
> Am 31. März 2016 um 05:15 schrieb Andrey Tarantsov via swift-evolution 
> :
> 
>>> The problem with protected is that it provides virtually no protection at 
>>> all; you can trivially expose it in a derived class
>> 
>> +
>> 
>>> Extensions further dilute the enforceability of "protected", since anyone 
>>> would be able to use an extension to dump methods into a class's namespace 
>>> and access its supposedly-protected bits.
>> 
>> I don't understand the need to protect against exposing something 
>> deliberately. We don't have a goal of restricting other developers, we're 
>> only saving them from accidental mistakes.
> 
> Totally agree, access control is not intended to be protection against 
> hacking. If a derived class wants to expose something then that is absolutely 
> fine as long as it makes sense for the derived class.

My point is that "protected" *isn't* access control. If we added it, it would 
have to be as an independent modifier. Private/internal/public fundamentally 
affect semantics—private and internal code is only accessible within a module, 
so we have full knowledge of their use sites at compile time and can be more 
permissive with extensions, implicit constructors, and other features. Public 
API can be used by arbitrary unknown external code so requires additional 
restrictions to ensure that the interface remains stable. "Only usable by 
subclasses" is an orthogonal axis to this—if a method is only usable by 
external subclasses, it requires all of the same restrictions as public code. 
If a method is only usable by subclasses within the module, it can behave like 
a private or internal method.

-Joe

> 
> 
>>> If a method was marked private in the base class, then it is very likely 
>>> that the name of the method, the design of its argument list and its return 
>>> value did not go through the same detailed design review as if the method 
>>> would have been meant to be part of the class’ interface from the start. So 
>>> it’s rather unlikely that increasing the visibility in an override is good 
>>> idea and in the spirit of the original writer of the private method.
>> 
>> The design review and whether something is a good idea is left as a 
>> responsibility for those subclasses that choose to expose methods. The 
>> intentions of the original class author don't override the intentions of the 
>> subclass author.
> 
> Exactly.
> 
> -Thorsten

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

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

[Taras Zakharko via swift-evolution]

This is what happens if you don’t follow the swift-evolution list for a while… 
I have send a very similar suggestion to the list today (but mine focuses more 
on methods). Didn’t mean to plagiarise your idea, sorry! Maybe we should bring 
the two of them together. 

Best, 

 Taras

> On 23 Mar 2016, at 11:13, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> If you've written enums before, you've no doubt noticed the irritating 
> phenomenon of `switch self` being absolutely everywhere. I first discovered 
> this in some of my very first Swift code, code so old we were still using the 
> `T[]` shorthand syntax:
> 
>enum Suit: Int {
>case Hearts, Spades, Diamonds, Clubs
> 
>static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }
> 
>var description: String {
>switch(self) {
>case .Hearts:
>return "♥️"
>case .Spades:
>return "♠️"
>case .Diamonds:
>return "♦️"
>case .Clubs:
>return "♣️"
>}
>}
> 
>var isRed: Bool {
>switch(self) {
>case .Hearts, .Diamonds:
>return true
>case .Spades, .Clubs:
>return false
>}
>}
>}
> 
> It would be nice if we could somehow eliminate that. I have two suggestions:
> 
> * Implicitly switch on `self` at the top level of a function or accessor (or 
> at least an enum one with top-level `case` statements).
> 
>enum Suit: Int {
>case Hearts, Spades, Diamonds, Clubs
> 
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
> 
>var description: String {
>case .Hearts:
>return "♥️"
>case .Spades:
>return "♠️"
>case .Diamonds:
>return "♦️"
>case .Clubs:
>return "♣️"
>}
> 
>var isRed: Bool {
>case .Hearts, .Diamonds:
>return true
>case .Spades, .Clubs:
>return false
>}
>}
> 
> * Allow you to attach member definitions to particular cases. It would be an 
> error if they didn't all define the same members, unless there was a 
> top-level catchall.
> 
>enum Suit: Int {
>var isRed: Bool { return false }
> 
>case Hearts {
>let description: String { return "♥️" }
>let isRed: Bool { return true }
>}
>case Spades {
>let description: String { return  "♠️" }
>}
>case Diamonds {
>let description: String { return  "♦️" }
>let isRed: Bool { return true }
>}
>case Clubs {
>let description: String { return  "♣️" }
>}
> 
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
>}
> 
> Any thoughts? This has, to be honest, bothered me since approximately the 
> third day I used the language; I'd love to address it sooner or later.
> 
> -- 
> 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] [Proposal] Make optional protocol methods first class citizens

[Sean Heber via swift-evolution]

Some ideas I was thinking about for optional protocol functions was you’d 
declare it like this:

protocol UIGestureRecognizerDelegate {
  optional func gestureRecognizerShouldBegin(gestureRecognizer: 
UIGestureRecognizer) -> Bool = true
}

If you put “optional” there, the compiler would auto-generate an empty function 
in a protocol extension in your module as if you had specified one yourself. If 
the function has a return value, you would be required to specify the default 
return value in the protocol which provides automatic documentation of the 
default, too. (It would be an error to have an optional function with a return 
value that doesn’t have a default value specified in the protocol.) (I am not 
currently in favor of supplying a default implementation body inside of a 
protocol as has been discussed some previously.)

If you provide a default implementation of an optional protocol function in a 
protocol extension in the same module as the protocol itself is declared in, it 
would be an error and you’d have to make the function non-optional or get rid 
of your conflicting protocol extension implementation. If the protocol was 
declared in a different module, then that restriction would be lifted since 
presumably you’re providing a default implementation via protocol extension on 
purpose.

l8r
Sean


> On Mar 31, 2016, at 1:34 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> Just a thought: optional methods could be modeled by methods in a protocol 
> that return optional closures.
> 
> -Thorsten
> 
> 
> Am 31. März 2016 um 04:42 schrieb Andrey Tarantsov via swift-evolution 
> :
> 
>> I'm missing those optional methods too, but protocol extensions sound like a 
>> better solution for this.
>> 
>> (For those suggesting a separate protocol, consider UITableView. How many 
>> protocols would it take to model all the optional delegate methods as 
>> separate protocols? Certainly more than 10, perhaps a few dozen.)
>> 
>> I would welcome a standardized way to document the methods as 
>> optional-to-implement, though, beyond just requiring a protocol extension. 
>> My ideal option would be to allow the optional keyword and change it to 
>> simply require a default implementation in a protocol extension.
>> 
>> If we don't want a language change, then perhaps a conventional doc tag?
>> 
>> A.
>> 
>> 
>>> On Mar 30, 2016, at 8:08 PM, Yuval Tal via swift-evolution 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> I find that optional protocol methods to be very useful. However, there is 
>>> a caveat -- it needs to be mapped to @objc. This puts a set of limitations, 
>>> such as: structures cannot be used as parameters as it does not map to 
>>> objective-c. What do you think about removing the requirement of using 
>>> @objc and allow to create optional methods without these limitations?
>>> 
>>> Thank you,
>>> 
>>> -Yuval
>>> ___
>>> 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] Enforce argument order for defaulted parameters

[Developer via swift-evolution]

+1

~Robert Widmann

2016/03/31 10:26、Jeff Kelley via swift-evolution  
のメッセージ:

> I have never taken advantage of this, personally. Given that there isn’t 
> anything that this feature enables that can’t be done if it’s removed―aside 
> from reordering arguments―I’d be in favor of removing it for simplicity’s 
> sake.
> 
> Jeff Kelley
> 
> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org
> 
>> On Mar 30, 2016, at 12:59 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> Many people are surprised when they find out defaulted parameters can be 
>> reordered, unlike required arguments. This special case adds complexity to 
>> the language, and runs against our general trend of treating argument labels 
>> as a significant part of an API's name, and preferring a single way of 
>> writing API calls. I think it's worth revisiting this design choice―is the 
>> special case worth the complexity? How many people take advantage of default 
>> argument reordering?
>> 
>> -Joe
> ___
> 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] allowing to specify optionality with type inference

[Erica Sadun via swift-evolution]

> On Mar 24, 2016, at 4:22 AM, Hugues Bernet-Rollande via swift-evolution 
>  wrote:
> ```
> var a:String? = String()
> // or
> var b = String() as String?
> // or
> var c:Optional = String()
> ```

When I need to force an optional (primarily for sample code) I can do this 
already:

```
var myOptionalString = Optional("")
```

In this example, `myOptionalString ` picks up the type as well as the 
optionality.
Does this not meet your requirement of "Allowing to specify only the 
optionality part of 
a variable type while still having the actual wrapped type infered by the 
assignement" in existing
Swift?

Beyond that, can you offer any compelling use-cases that motivate this change?

-- E


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

Re: [swift-evolution] Deprecating Trailing Closures

[Erica Sadun via swift-evolution]

> On Mar 31, 2016, at 5:56 AM, Radosław Pietruszewski  wrote:
>> I follow the "Rule of Kevin", which is not language enforced. Parens around 
>> functional 
>> closures (->T), not around procedural (->Void) ones.  This promotes 
>> "language construct"-like 
>> Void calls, avoids compiler parsing issues when chaining (or using "guard", 
>> "if", etc). It lets
>> me know instantly how the closure is used. 
>> 
>> While I was originally reluctant to adopt it, its advantages have become 
>> self-evident over time. 
>> This ends up being slightly wordier, especially in the few cases you need to 
>> use argument labels. 
>> 
>> I think it's worth it.
> 
> I don’t follow the Rule of Kevin myself, although I’m not against it either, 
> and I see why some people would like it.
> 
> But, if we’re going to have trailing closures at all (which seems desirable 
> for creating things that look like language features), enforcement based on 
> syntactic preference doesn’t make sense to me.
> 
> This really reminds me of a “remove implicit self” discussion. Some people 
> (me included) were against, because they disliked the noisiness of “self” 
> everywhere. Others argued that the implicitness is somewhat unsafe. A valid 
> position to take. But it’s a kind of thing teams can use a linter for, if 
> they want to enforce it as a rule.
> 
> Trailing closures seem like a similar thing. We could remove it altogether 
> (although I think that would be a shame), or let’s just leave it up to 
> preference (and developing guidelines) on where to use them.
> 
> Best,
> — Radek

Following a style rule is just like using a linter. It's not language mandated 
and I have not argued for enforcement.

-- E

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

Re: [swift-evolution] Deprecating Trailing Closures

[Thorsten Seitz via swift-evolution]

Am 25.03.2016 um 13:44 schrieb Brent Royal-Gordon via swift-evolution 
:

>>>let foo = myArray
>>>.filter { $0 & 1 == 1 }
>>>.map { $0 + 1 }
>>>.reduce(0) { $0 + $1 }
>> 
>> This doesn’t really seem much neater or more readable to me than:
>> 
>>let foo = myArray
>>.filter({ $0 & 1 == 1 })
>>.map({ $0 + 1 })
>>.reduce(0, { $0 + $1 })
> 
> I, on the other hand, cannot imagine how you would not see a difference 
> between the two. The paren-less form is *far* more readable to me; when you 
> put a parenthesis and a curly bracket next to each other, the curly bracket 
> disappears and I can no longer see that the expression is a closure.

Same for me!
 

> Swift generally doesn't mandate any particular style. I think this is a good 
> time to continue that tradition.

Indeed.

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Michel Fortin via swift-evolution]

Or maybe we could just abolish of file-private. It's not like it'd be 100% 
gone: private declarations at the root of a file will always be equivalent to 
file-private. For non-root things that need to be accessible within the file 
you can use `internal`, which is more accessible than before but still bounded 
to the current module.


> Le 31 mars 2016 à 0:22, Chris Lattner via swift-evolution 
>  a écrit :
> 
> On Mar 23, 2016, at 10:13 PM, Chris Lattner  wrote:
>> How about we continue this trend, and follow other existing Swift keywords 
>> that merge two lowercase words (associatedtype, typealias, etc), and use:
>> 
>>  public
>>  moduleprivate
>>  fileprivate
>>  private
>> 
>> The advantages, as I see them are:
>> 1) We keep public and private meaning the “right” and “obvious” things.
>> 2) The declmodifiers “read” correctly.
>> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
>> parenthesized keyword approach.
>> 4) The unusual ones would be “googable”.
>> 5) Support for named submodules could be “dropped in” by putting the 
>> submodule name/path in parens: private(foo.bar.baz) or 
>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
>> natural than putting keywords in parens.
> 
> I’ve seen a number of concerns on this list about moduleprivate, and how it 
> penalizes folks who want to explicitly write their access control.  I’ve come 
> to think that there is yes-another possible path forward here (which I 
> haven’t seen mentioned so far):
> 
> public
> internal
> fileprivate
> private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) Compared to Swift 2, there is almost no change.  The only thing that 
> changes is that some uses of Swift 2 “private” will be migrated to 
> “fileprivate”, which makes the intent of the code much more clear.
> 4) fileprivate is the unusual and not-really-precedented-in-other-languages 
> modifier, and it would still be “googable”.
> 5) The addresses the “excessively long” declmodifier problem that several 
> people are concerned with.
> 6) Support for named submodules could be “dropped in” by parameterizing 
> “internal”.
> 
> Thoughts?
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] Deprecating Trailing Closures

[Thorsten Seitz via swift-evolution]

> Am 24.03.2016 um 22:31 schrieb Andrey Tarantsov via swift-evolution 
> :
> 
>> I use trailing closures all the time because I find the brackets too noisy, 
>> like ; at the end of a line is too noisy. The sort of code I use is:
>> 
>> let foo = myArray
>> .filter { $0 & 1 == 1 }
>> .map { $0 + 1 }
>> .reduce(0) { $0 + $1 } 
> 
> +1 to this. Please don't remove them, they're great.

+1 from me as well.

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

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Thorsten Seitz via swift-evolution]

Well said, Brent!

-Thorsten 

Am 23.03.2016 um 02:25 schrieb Brent Royal-Gordon via swift-evolution 
:

>> These may be compact, but some programmer may fell that they are not in 
>> control: do these "stdlib" seq(), c.filter() pre-calculate all the entries 
>> (wasting precious cpu cycle if one break out early)  or are each value 
>> dynamically created? Having an explicit legacy loop format gives a feel of 
>> control. So something like
>> 
>> for i from 2 to 1_000_000 by 1 where i % 2 != 0 while foundCount < 5 { 
>> print(i); foundCount +=1 }
>> 
>> sounds less magical and seems easier to predict than
>> 
>> for i in 2.stride(to:1_000_000, by:1).filter({ $0 % 2 != 0}).prefix(5) { 
>> print(i) }
>> 
>> and is still quite readable, even if it mixes for loop, while loop and even 
>> simple condition.
> 
> First of all, this example sucks. There are *many* ways to write it with 
> existing features which would be more understandable than the pile of random 
> code in your `for` loop. Here are a few:
> 
>for i in stride(from: 2, to: 1_000_000, by: 1) where i % 2 == 0 {
>print(i)
>foundCount += 1
>if foundCount >= 5 { break }
>}
> 
>for i in stride(from: 2, to: 1_000_000, by: 2) {
>print(i)
>foundCount += 1
>if foundCount >= 5 { break }
>}
> 
>for i in stride(from: 2, to: 1_000_000, by: 2).prefix(5) {
>print(i)
>}
> 
> I know you're trying to illustrate some features you'd like on the `for` 
> loop, but by choosing this example you're not realy challenging your proposal 
> enough for its disadvantages to be illustrated well. For instance, one thing 
> `stride` cannot currently do is apply a step that doesn't involve addition, 
> for instance by multiplying the number. But your `by` keyword suffers from 
> the same problem! To really add anything new, your proposal would have to be 
> vastly more complicated than what you describe here. It's not fair to say 
> "look how much simpler this is" while sweeping the actual complexity under 
> the rug.
> 
>> Sorry if the example is a bit dumb as is; but I was too lazy to provide some 
>> nice code instead of the simple print.
>> Can anyone tell if the filter.prefix above is lazy and that each number is 
>> create one by one?
>> The fact that using 1_000_000 above caused my playground to crash, seems to 
>> indicate that the list of number is pre-generated.
> 
> Yes, I can tell you without looking at anything that the second example is 
> greedy. `stride` acts lazy (it returns an instance which, when iterated over, 
> produces the values), but `filter` is greedy unless you explicitly use 
> `lazy`. If you don't know this, you can tell by looking at `filter`'s return 
> type, which is an Array.
> 
> Your "explicit" syntax, on the other hand, seems totally out of control. 
> Where do these features come from? What happens when you find something else 
> you want to do in a loop? Do you invent another keyword and give it a new 
> syntax? This *still* doesn't give you enough flexibility to express a `for` 
> loop which doubles the number; is that going to require a new keyword? How 
> many keywords is it going to take? Is anyone ever going to learn what all 
> these keywords mean? Are you going to have to re-read The Swift Programming 
> Language to decode every moderately complicated `for` loop?
> 
> (And how am I supposed to mentally parse your sea of undifferentiated 
> alphanumerics? Punctuation in a programming language helps you understand the 
> role of each part of it; your proposal's lack of punctuation makes it 
> difficult to read.)
> 
> The function/method-based approach requires a little more syntax and a little 
> more understanding of what's going on. But has huge advantages that I think 
> you're unfairly ignoring:
> 
> * It is simple. The `for` loop itself is quite uncomplicated. The only extra 
> features it has are the `case` clause, which can't be easily duplicated in 
> another way, and the `where` clause, which I've honestly never been totally 
> happy with.
> * It is reusable. Calls like `stride`, `filter` and `prefix` can be used even 
> outside a `for` loop.
> * It is extensible. If you need something new, you can add it, and it will be 
> just as accessible as anything the standard library's designers dreamed up.
> * It is documentable. By using functions and methods instead of keywords, 
> it's easier to look up what a particular feature does.
> * It is sustainable. If we have some kind of really specific looping 
> mechanism like you propose, every little feature we want will need a specific 
> design, evolution proposal, and implementation by the compiler team. That is 
> a completely unrealistic plan. Not even the C `for` loop took this 
> approach—it provided a *general* mechanism for plugging your own logic into a 
> loop.
> 
> Ultimately, piling on new keywords every time you think of a tiny variation 
> is simply bad language 

Re: [swift-evolution] Deprecating Trailing Closures

[Radosław Pietruszewski via swift-evolution]

> I think requring trailing closures to be @noescape would take away some very 
> compelling use cases for them. In particular, you would lose the ability to 
> use trailing closures for asynchronous code, like completion functions. I, 
> for one, would be sad to lose those—they are often some of the largest, most 
> block-like pieces of code that you put into a closure.

I, too, would be sad about that — but aside from a syntactic/stylistic choice, 
there aren’t any important-to-the-compiler semantics conveyed by the trailing 
closure, are there?

> 
> At the same time, many of the things which people seem to think shouldn't be 
> trailing closures, like `map` blocks, seem like good candidates for early 
> returns or other control flow.

I *don’t* think `map` blocks should be able to control the outside scope. Map 
should map, that is transform. `forEach` should probably be able to do outside 
function control flow, and the use of trailing closure would be consistent with 
the Rule of Kevin.

> Basically, if you imagine a Venn diagram of "closures it would be useful to 
> break out of early" and "closures you might want to use trailing closure 
> syntax with", I don't think there's a particularly large amount of overlap 
> between the two circles.

Aside from `map`, do you have other examples where there is no overlap?

— Radek

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Pierre Monod-Broca via swift-evolution]

I like :

- public
- modulewide or moduleprivate or internal
- filewide or fileprivate
- private

I really dislike interfile because the word exists and means something else
I dislike intermodule, inmodule and infile because I don't find them intuitive 
at all.

I prefer the -wide flavors because they're shorter than the -private flavors, 
and because -wide is an existing suffix in english.
Internal has the advantage of no modification but if we want to change it, now 
is the time.


> Le 31 mars 2016 à 11:10, Ross O'Brien via swift-evolution 
>  a écrit :
> 
> > public
> > internal
> > interfile
> > private
> 
> Linguistically, I really like this direction. 'interfile' is one word, it 
> reads as an adjective, it can be used in conversation (this has interfile 
> visibility), and it's clear about where its visibility ends.
> 
> It just doesn't mean what you think it means.
> 
> 'inter' means 'between'. See: 'intergalactic', 'interstellar', 
> 'international', 'internet'. So 'interfile' would have to mean 'visible 
> between files' - i.e. an interfile symbol in one file is visible in another 
> file. The prefix you're looking for, meaning 'internal', is 'intra' (see: 
> 'intravenous', 'intranet').
> 
> So the scale would become:
> 
> public / intermodule
> internal / intramodule / interfile
> intrafile
> private
> 
> 
> On Thu, Mar 31, 2016 at 6:04 AM, Paul Ossenbruggen via swift-evolution 
> > wrote:
> public
> internal
> interfile
> private
> 
> still googleable and very clear its scope and meaning, nice latin root. 
> Doesn’t overload “private”, slightly shorter.
> 
> 
> > On Mar 30, 2016, at 9:46 PM, Thorsten Seitz via swift-evolution 
> > > wrote:
> >
> > Looks good to me.
> >
> > -Thorsten
> >
> >> Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution 
> >> >:
> >>
> >>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  >>> > wrote:
> >>> How about we continue this trend, and follow other existing Swift 
> >>> keywords that merge two lowercase words (associatedtype, typealias, etc), 
> >>> and use:
> >>>
> >>>   public
> >>>   moduleprivate
> >>>   fileprivate
> >>>   private
> >>>
> >>> The advantages, as I see them are:
> >>> 1) We keep public and private meaning the “right” and “obvious” things.
> >>> 2) The declmodifiers “read” correctly.
> >>> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
> >>> parenthesized keyword approach.
> >>> 4) The unusual ones would be “googable”.
> >>> 5) Support for named submodules could be “dropped in” by putting the 
> >>> submodule name/path in parens: private(foo.bar.baz) or 
> >>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
> >>> natural than putting keywords in parens.
> >>
> >> I’ve seen a number of concerns on this list about moduleprivate, and how 
> >> it penalizes folks who want to explicitly write their access control.  
> >> I’ve come to think that there is yes-another possible path forward here 
> >> (which I haven’t seen mentioned so far):
> >>
> >> public
> >> internal
> >> fileprivate
> >> private
> >>
> >> The advantages, as I see them are:
> >> 1) We keep public and private meaning the “right” and “obvious” things.
> >> 2) The declmodifiers “read” correctly.
> >> 3) Compared to Swift 2, there is almost no change.  The only thing that 
> >> changes is that some uses of Swift 2 “private” will be migrated to 
> >> “fileprivate”, which makes the intent of the code much more clear.
> >> 4) fileprivate is the unusual and 
> >> not-really-precedented-in-other-languages modifier, and it would still be 
> >> “googable”.
> >> 5) The addresses the “excessively long” declmodifier problem that several 
> >> people are concerned with.
> >> 6) Support for named submodules could be “dropped in” by parameterizing 
> >> “internal”.
> >>
> >> Thoughts?
> >>
> >> -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 
> 
> 
> ___
> swift-evolution 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Ted F.A. van Gaalen via swift-evolution]

Grüezi wohl Taras

you wrote:

> I find it quite irritating that you keep repeating these untrue facts. Again: 
> both for loops compile to exactly the same code. 


Alas, I don’t understand you irritation, 
but it is your irritation, not mine.

Please note again, that “for ... in …”  always has 
some sort of collection type as its argument..
At run time, the content of a collection 
is in most cases unpredictable.
Ergo: this implies that in these cases,
the compiler cannot optimize the collection 
part of the “for … in …” statement out of the way. 
In an attempt to overcome this restriction, 
it would need to analyze all entities that have 
influenced the content of the collection, 
which is virtually impossible.
 
I do not understand your aversion against 
the for loop I brought forward, as it does not 
conflict at all with the “for ... in …” construct 
and probably also does not stand in the way 
of possible future extensions that could be 
added to the "for in..” construct. 

E.g. For similar reasons one could be irritated by 
the brave attempts of some of us to supply 
most peculiar variants of “Strides", seemingly,
at least as seen from my limited perspective,
to compensate the loss of the classical for-loop’s
facilities...  
In spite of all this being very fascinating and 
creative, to me, this effort is comparable with
trying to climb the Eiffel tower, equipped
with boxing gloves and diving fins.
it could irritate me.. However it does not,
for the mere reason that I do not fully 
understand their motives and logical grounds...
Nevertheless, they might -or might not- 
have good reasons to do so, as we no 
doubt will find out sooner or later...
In any case, this does affect the collection-based
“for … in …” only, and has no impact on the 
“for v from v1 to v2 by vstep” 
that I am proposing. 



> Collection-based for loop can express exactly the same semantics, so why do 
> you need a new construct when you already have a perfectly good one to do the 
> job? 


For the simple reason that there are no collections involved: 
I have very clearly described and motivated it. 
Please read it again, thank you.

By the way, it is not a new construct as it has been
existing for decades.

I took the liberty to read about you on the internet. Interesting.

I’ve read that you have a degree in linguistics, 
which makes me assume that of all people, 
you’d understand that in most languages 
there are many different ways to express something,
and that the way to express or say something 
is mostly determined by contextual aspects... 
So in the light of this very specific knowledge
that you have, I fail to understand what your
objections are against the presence of 
two slightly different for-loop variants
that can co-exist easily and are effective,
each in its own different context?  

Last but not least, you might find this interesting:
(although I am almost sure you have read it before)

http://blog.oxforddictionaries.com/2014/09/george-orwell-newspeak/

and then most particularly in this text: 

“Newspeak goals and real-world ramifications”

I cannot completely clear myself from the association
of this with the removal of certain Swift language 
elements..


Met vriendelijke groeten.
TedvG


 

> On 31.03.2016, at 10:11, Taras Zakharko  wrote:
> 
> 
>> On 30 Mar 2016, at 22:05, Ted F.A. van Gaalen via swift-evolution 
>> > wrote:
>> 
>> Again I need to emphasize very strongly that this for-loop really 
>> has absolutely 
>>  nothing, nada, zilch, niente, nichts, niets, niks, rien, zero, nenio,
>> to do with the: 
>> 
>> for i in stride(…. 
>> 
>> or any other for in… variant working with collections.
> 
> Of course it does. Collection-based for loop can express exactly the same 
> semantics, so why do you need a new construct when you already have a 
> perfectly good one to do the job? 
> 

>> 
>> but, once again - 
>> provided you don’t want to do other operations
>> on the generated collection before iterating -  
>> a collection is used here totally unnecessary, 
>> which puts a burden on performance because the contents 
>> of a collection are unpredictable 
> 
> I find it quite irritating that you keep repeating these untrue facts. Again: 
> both for loops compile to exactly the same code. 
> 
>> It is also tedious to write and (as a matter of my personal taste) downright 
>> ugly.
> 
> Right, because 
> 
>  for d in stride(from:10, to: 5, by: 0-.1, tolerance: 0.01) 
> 
> is that much more tedious to write than what you propose
> 
> Best, 
> 
>  Taras
> 
> 

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

Re: [swift-evolution] Deprecating Trailing Closures

[Radosław Pietruszewski via swift-evolution]

I have to admit I’m quite fond of the trailing closure syntax. This is partly 
because of my earlier experiences with Ruby. But partly I just really found it 
more readable to see a separation between a regular function call, with just 
normal parameters passed in, and higher order functions, like the `map` example 
you’ve made. Having two sets of parentheses/braces like foo({ … }) really makes 
them blend in and I don’t notice the curly braces as much. Having a stylistic 
separation between:

foo(argument)
foo { code }

helps me catch the difference between the two.

But it is a stylistic choice. Like I mentioned in a different reply, if we’re 
going to have trailing closures at all, I don’t see a point in enforcing this 
other than with a linter.

* * *

The only way I see this working is if the trailing closure syntax has *other* 
semantics as well. For example, there’s been a discussion about allowing 
specially marked closures to return/break/continue in the scope of the caller 
function, not the closure’s scope (like Ruby’s blocks do). Now, that would make 
a bit more sense. You’d have a special attribute (can’t think of a name, but 
let’s stick with your @trailing), that would imply:

- required trailing closure syntax
- @noescape, I think
- and return/break/continue affects outside functions

And you could use that to make your own pseudo-language-constructs. This would 
enforce trailing closure syntax, and nothing else could use trailing closure 
syntax.

Now, I wouldn’t be super happy about not being able to write `map { foo }` 
myself  — but _that_ proposal would make sense to me. It wouldn’t just be 
enforcement of a stylistic choice, but the syntax would actually convey some 
important semantics.

What do you think?

— Radek

> On 24 Mar 2016, at 14:57, Haravikk via swift-evolution 
>  wrote:
> 
> When I started using Swift I was initially very enthusiastic about trailing 
> closures, but I’ve actually kind of gone off them somewhat and I’d like to 
> discuss why.
> 
> Firstly, here are two ways to write a common example using the .map() method:
> 
>   let foo = myArray.map { $0 + 1 }
>   let foo = myArray.map({ $0 + 1 })
> 
> It’s tough to say that the first form is any neater than the second, other 
> than the second having more brackets. However, the first form is somewhat 
> ambiguous, as .map in this case looks like a property rather than a method, 
> it also visually looks like a statement, followed by a closure rather than 
> the two things logically being related. Of course it’s quick to learn that 
> these are related, but for consistency I’m starting to now prefer the use of 
> parenthesis in almost all cases.
> 
> The other advantage of trailing closures is the omission of the label, but 
> trailing closures aren’t strictly necessary for this, as we can already omit 
> external labels for parameters if we want to, and the example above shows 
> that a trailing closure isn’t necessary for this. The only real difference is 
> that the trailing closure form makes a label optional, because you can either 
> provide the closure with label in parenthesis (if the label is required) or 
> omit it by trailing, like so:
> 
>   something.someMethod(foo: 1, predicate: { $0 < $1})
>   something.someMethod(foo: 1) { $0 < $1}
> 
> However this kind of arbitrarily makes the following impossible:
> 
>   something.someMethod(foo: 1, { $0 < $1 })
> 
> With this in mind it seems to me that we might be better served by the 
> ability to make external labels optional, as this would allow us to be just 
> as succinct, while being completely clear about what is being passed into 
> this method.
> 
> 
> The only real remaining advantage that I see to trailing closures is the 
> ability to define pseudo language constructs, for example:
> 
>   func repeatUntilEmpty(collection:C, @noescape _ 
> body:() throws -> Void) rethrows { while !collection.isEmpty { body() } }
>   repeatUntilEmpty(myArray) {
>   /* Do something over and over until myArray is empty */
>   }
> 
> Which I think is a pretty uncommon type of structure, but could be useful in 
> some specialised situations. To support this though we could easily use a new 
> @trailing attribute instead to indicate that the closure can be used in this 
> way. My example isn’t very good as I can’t think of a case that really, 
> really needs this, but I think they’re probably out there.
> 
> 
> To summarise, having come down off my initial enthusiasm for trailing 
> closures I’m not sure that they really add that much syntactically, 
> especially in the most common cases, while actually being a little ambiguous 
> looking and adding inconsistency to the language. I think they should remain 
> for the less common cases that can really benefit from them, but as a feature 
> that is opted into, so that we can go for consistency by default.
> 
> I’m interested to hear other 

Re: [swift-evolution] Deprecating Trailing Closures

[Radosław Pietruszewski via swift-evolution]

>> I’m not proposing to remove them entirely, in fact your lock example is a 
>> perfect example of when a trailing closure makes the most sense, as a form 
>> of customised language feature. But I’m wondering if perhaps cases like 
>> these should be created using an attribute that specifically enables it? 
>> e.g- your definition could become:
>> 
>>  func protect(action: @trailing (Void) -> Void) { … }
>> 
>> It’s other cases like common usages of .map() and similar methods where I’ve 
>> found myself using the closure in its trailing form less and less, and am 
>> not as sure if it’s really needed, or may actually be more of a detriment to 
>> the language than a benefit.
> 
> I follow the "Rule of Kevin", which is not language enforced. Parens around 
> functional 
> closures (->T), not around procedural (->Void) ones.  This promotes "language 
> construct"-like 
> Void calls, avoids compiler parsing issues when chaining (or using "guard", 
> "if", etc). It lets
> me know instantly how the closure is used. 
> 
> While I was originally reluctant to adopt it, its advantages have become 
> self-evident over time. 
> This ends up being slightly wordier, especially in the few cases you need to 
> use argument labels. 
> 
> I think it's worth it.

I don’t follow the Rule of Kevin myself, although I’m not against it either, 
and I see why some people would like it.

But, if we’re going to have trailing closures at all (which seems desirable for 
creating things that look like language features), enforcement based on 
syntactic preference doesn’t make sense to me.

This really reminds me of a “remove implicit self” discussion. Some people (me 
included) were against, because they disliked the noisiness of “self” 
everywhere. Others argued that the implicitness is somewhat unsafe. A valid 
position to take. But it’s a kind of thing teams can use a linter for, if they 
want to enforce it as a rule.

Trailing closures seem like a similar thing. We could remove it altogether 
(although I think that would be a shame), or let’s just leave it up to 
preference (and developing guidelines) on where to use them.

Best,
— Radek___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] allowing to specify optionality with type inference

[Radosław Pietruszewski via swift-evolution]

Could you give us one or two real-world examples where you’d want to do this?

I really can’t think of a situation where I would want to assign a non-optional 
to an optional variable. Even if I transform it later such that it might 
produce nil, it’s desirable to assign it to two different constants:

let a = String()
let b = a.thisMightMakeMeNil()

— Radek

> On 24 Mar 2016, at 11:22, Hugues Bernet-Rollande via swift-evolution 
>  wrote:
> 
> In a strongly typed language, such as Swift is, type inference is greatly 
> appreciated as it declutter the instance type definition.
> 
> For example, in the following statement, the compiler easily deduct the type 
> of `aString` by the return type of `String.init()`
> 
> ```
> let aString = String()
> ```
> 
> Optional are generic enum which can contain a value of a generic type or nil 
> (https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift)
> 
> Sometime you may want specify that the instance is of type optional in which 
> even if you are a the same time assigning a value to this instance.
> In which case you loose the type inference mechanism and you have to define 
> both (the optionality as well as the type). 
> For example, you may want specify an optional String with a default value.
> 
> ```
> var a:String? = String()
> // or
> var b = String() as String?
> // or
> var c:Optional = String()
> ```
> 
> But the compiler can already infer the variable type from this assignment, it 
> just miss the "optionality" of the variable.
> It would be nice to be able to express this.
> 
> Then for, I propose the following syntax evolution:
> 
> ```
> var a:? = String()
> // and/or (not recommended because more prone to typo and unclear...)
> var a = String() as?
> ```
> 
> This would allow for more synthetic optional declaration.
> 
> I've draft a proposal on my `swift-evolution` fork:
>   
> https://github.com/huguesbr/swift-evolution/blob/optionality-type-with-type-inference/proposals/0057-optionality-type-with-type-inference.md
> 
> Let me know what you think.
> 
> 
> Hugues BERNET-ROLLANDE
> 
> --
> hug...@xdev.fr
> http://www.xdev.fr
> 
> http://www.linkedin.com/in/huguesbr
> ___
> 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] Thoughts regarding readable INTENT of Loop keywords

[Pierre Monod-Broca via swift-evolution]

+1 with Taras

> Le 31 mars 2016 à 09:55, Taras Zakharko via swift-evolution 
>  a écrit :
> 
> I do not see how this is more readable. The current for loop is perfectly 
> readable and conveys the intent very well IMO: it executes a code block FOR 
> every ELEMENT that is IN a SEQUENCE. In contrast, I find your proposal rather 
> confusing: it combines a number of different constructions with different 
> semantics and generally is less transparent. 
> 
> Best, 
> 
>  Taras
> 
>> On 30 Mar 2016, at 21:54, Nathanial Burton-Bradford via swift-evolution 
>> > wrote:
>> 
>> Swift Control Flow using Loops 
>> 
>> One of Swifts strengths is clear, readable INTENT, conveyed by the languages 
>> Keyword tokens. For anyone new to programming, clear, readable intent, goes 
>> a long way in helping them master the language, by helping reduce 
>> logical/semantic errors caused by a misunderstanding of the names used in 
>> specifying the languages keyword tokens…
>> Swift’s control flow keywords can be ambiguous, in this respect, when 
>> conveying the functional intent of loop control logic, within the language.
>> 
>> I would like to open up discussion, therefore, regarding the possible 
>> renaming of Swift’s control flow keywords, with the hope that this leads to 
>> clearer INTENT regarding loops. 
>> 
>> 
>> Replace For-In with Loop Using 
>> 
>> for foo in d…y 
>> loop foo using d…y
>> 
>> For x in 1…5
>> loop x using 1…5
>> 
>> loop i=0 using i<10
>> 
>> loop i using 0..<10
>> 
>> 
>> 
>> For _ in 1 …power
>> ———->
>> loop using 1…power
>> 
>> “The underscore character (_) used in place of a loop variable causes the 
>> individual values to be ignored and does not provide access to the current 
>> value during each iteration of the loop.”
>> 
>> I feel underscore character (_) is confusing, semantically. 
>> 
>> 
>> let names = ["Anna", "Alex", "Brian", “Jack"]
>> for name in names {
>> ———-> loop names using name {
>> print("Hello, \(name)!")
>> }
>> 
>> Note : loop ARRAY using ELEMENT(S) - which is logically consistent with 
>> ‘-using’ as last keyword instance.
>> 
>> let numberOfLegs = ["spider": 8, "ant": 6, "cat": 4]
>> for (animalName, legCount) in numberOfLegs {
>> print("\(animalName)s have \(legCount) legs")
>> }
>> 
>> loop numberOfLegs using (animalName, legCount) {
>> print(“ \(animalName)s have \(legCount) Legs”)
>> }
>> 
>> Note : Again loop ARRAY using ELEMENT(S) - which is logically consistent 
>> with ‘-using’ as last keyword instance.
>> 
>> 
>> for (airportCode, airportName) in airports {
>> loop airports using (airportCode, airportName) 
>> for airportCode in airports.keys {
>> loop airports.keys using airportCode {
>>
>> for airportName in airports.values {
>> loop airports.values using airportName {
>> 
>> for value in array[1..> loop array[1..> 
>> ‘while’ using loop while 
>> 
>> loop while square < finalSquare {
>> // roll the dice
>> diceRoll += 1
>> if diceRoll == 7 { diceRoll = 1 }
>> // move by the rolled amount
>> 
>> Control transfer statements
>> 
>> repeat { 
>> ——> loop {
>> …
>> } while 
>> 
>> 
>> “Break
>> The break statement ends execution of an entire control flow statement 
>> immediately. ”
>> 
>> I propose replacing Break, in loops, with exit now (intent is explicit)
>> Note: Labeled Statements with break - 
>> break gameLoop exit now gameLoop
>> 
>> “Continue
>> The continue statement tells a loop to stop what it is doing and start again 
>> at the beginning of the next iteration through the loop.”
>> 
>> “switch character {
>> case "a", "e", "i", "o", "u", " ":
>> continue // Continue what? to next line? to end? to beginning?
>> default:
>> puzzleOutput.append(character)
>> }”
>> 
>> I propose replacing continue with next cycle or next loop
>> 
>> 
>> “switch character {
>> case "a", "e", "i", "o", "u", " ":
>> next cycle // intent is explicit
>> default:
>> puzzleOutput.append(character)
>> }”
>> 
>> Note: Labeled Statements with Continue - as per Break example, next cycle 
>> gameLoop 
>> 
>> 
>> ___
>> 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] Enforce argument order for defaulted parameters

[Radosław Pietruszewski via swift-evolution]

I think this ability to reorder labeled parameter names is more useful in a 
dynamic language like Ruby than in Swift, since Ruby doesn’t give my text 
editor the ability to autocomplete the function signature. If I’m typing the 
function and its arguments from my head, I’m more likely to forget the “right” 
order. With Swift, I’d generally start typing the name and have Xcode 
autocomplete all available parameters for me, ensuring the original order.

I think defaulted parameters are different from required parameters in that 
they’re usually not “inputs” but “options”, and therefore the order of them 
really doesn’t matter — and they’re not _really_ part of the API name. And so 
the distinction makes sense to me.

And it still makes sense to me that I would want to modify some function call 
and just add a parameter at the end, without Xcode’s assistance, and regardless 
of the original order.

So: I believe there’s utility in this feature, and the complexity to the 
language is negligible (I think a lot of people won’t really “discover” this 
feature, but will just naturally write something valid without the compiler 
bothering them needlessly). If there’s significant complexity in the 
implementation of this feature, I wouldn’t be super sad if it went away, but if 
there isn’t, I’d prefer that it stays.

— Radek

> On 30 Mar 2016, at 18:59, Joe Groff via swift-evolution 
>  wrote:
> 
> Many people are surprised when they find out defaulted parameters can be 
> reordered, unlike required arguments. This special case adds complexity to 
> the language, and runs against our general trend of treating argument labels 
> as a significant part of an API's name, and preferring a single way of 
> writing API calls. I think it's worth revisiting this design choice—is the 
> special case worth the complexity? How many people take advantage of default 
> argument reordering?
> 
> -Joe
> ___
> 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] Question about heterogeneous collections

[Haravikk via swift-evolution]

Protocols aren’t like parent-classes, they can’t be used interchangeably as 
different struct implementations of MyProtocol may have radically different 
memory footprints. I think you can define a protocol for classes only which may 
allow you to use MyProtocol as a concrete type, but personally I don’t like the 
idea of limiting a protocol in that way; the correct way to store elements of 
MyProtocol is to define a type-erased wrapper AnyMyType that takes any instance 
of MyProtocol and hides it.

Type-erased wrappers are bit of a pain in the ass to define; in fact, in the 
discussion you linked someone recommended a method using closures to do it, but 
while this is a neat way to do it, it’s very inefficient in terms of memory (if 
you have four or five methods in your protocol then suddenly the wrapper will 
be adding hundreds of bytes of overhead). The correct way to implement these is 
outlined in the following guide:

https://realm.io/news/type-erased-wrappers-in-swift/ 


This is a horrible process with a ton of boiler-plate though, so there’s 
certainly an argument to be made for features that can reduce or eliminate the 
need for this. In fact, it’d be great if protocols had type-erased wrappers 
generated automatically, as this could avoid the somewhat unintuitive cases 
like the one you’ve run into, but then it would end up hiding the complexity of 
what’s actually happening.

For example, if you want to save a bunch of different MyProtocol variations in 
a collection, then you might consider declaring them as classes with a common 
ancestor instead, then use that ancestor as your array type, as this is one of 
the advantage of classes over structs (even though I generally prefer the 
latter in most cases). Type-erased wrappers also add overhead that you should 
be aware of, but typically a lot less (if you use the boxing method, the 
closure method adds tons of overhead despite appearing much simpler).

> On 30 Mar 2016, at 18:11, Jason Sadler via swift-evolution 
>  wrote:
> 
> Hi folks,
> 
> I have an issue with using a heterogeneous array of objects conforming to a 
> protocol - I want to write an extension on Array (or CollectionType) that 
> applies only when Element : MyProtocol, but I can’t call methods in that 
> extension from an instance of [MyProtocol] because "Using ‘MyProtocol' as a 
> concrete type conforming to protocol ‘MyProtocol' is not supported”
> 
> (For more background, my full use case can be seen in this gist: 
> https://gist.github.com/sadlerjw/2cc16b4375b02fe7f400 
> )
> 
> I’ve asked about this on swift-users 
> (https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160321/001560.html
>  
> )
>  and got some good workarounds but no one was able to provide me with 
> information on any future plans in swift to address this issue - whether 
> that’s making protocols conform to themselves, or some other improved 
> approach to heterogeneous collections. I wonder if anyone here can shed some 
> light on this? (I’m new to the mailing lists, sorry!)
> 
> Thanks
> Jason
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ross O'Brien via swift-evolution]

> public
> internal
> interfile
> private

Linguistically, I really like this direction. 'interfile' is one word, it
reads as an adjective, it can be used in conversation (this has interfile
visibility), and it's clear about where its visibility ends.

It just doesn't mean what you think it means.

'inter' means 'between'. See: 'intergalactic', 'interstellar',
'international', 'internet'. So 'interfile' would have to mean 'visible
between files' - i.e. an interfile symbol in one file is visible in another
file. The prefix you're looking for, meaning 'internal', is 'intra' (see:
'intravenous', 'intranet').

So the scale would become:

public / intermodule
internal / intramodule / interfile
intrafile
private


On Thu, Mar 31, 2016 at 6:04 AM, Paul Ossenbruggen via swift-evolution <
swift-evolution@swift.org> wrote:

> public
> internal
> interfile
> private
>
> still googleable and very clear its scope and meaning, nice latin root.
> Doesn’t overload “private”, slightly shorter.
>
>
> > On Mar 30, 2016, at 9:46 PM, Thorsten Seitz via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Looks good to me.
> >
> > -Thorsten
> >
> >> Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution <
> swift-evolution@swift.org>:
> >>
> >>> On Mar 23, 2016, at 10:13 PM, Chris Lattner 
> wrote:
> >>> How about we continue this trend, and follow other existing Swift
> keywords that merge two lowercase words (associatedtype, typealias, etc),
> and use:
> >>>
> >>>   public
> >>>   moduleprivate
> >>>   fileprivate
> >>>   private
> >>>
> >>> The advantages, as I see them are:
> >>> 1) We keep public and private meaning the “right” and “obvious” things.
> >>> 2) The declmodifiers “read” correctly.
> >>> 3) The unusual ones (moduleprivate and fileprivate) don’t use the
> awkward parenthesized keyword approach.
> >>> 4) The unusual ones would be “googable”.
> >>> 5) Support for named submodules could be “dropped in” by putting the
> submodule name/path in parens: private(foo.bar.baz) or
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
> natural than putting keywords in parens.
> >>
> >> I’ve seen a number of concerns on this list about moduleprivate, and
> how it penalizes folks who want to explicitly write their access control.
> I’ve come to think that there is yes-another possible path forward here
> (which I haven’t seen mentioned so far):
> >>
> >> public
> >> internal
> >> fileprivate
> >> private
> >>
> >> The advantages, as I see them are:
> >> 1) We keep public and private meaning the “right” and “obvious” things.
> >> 2) The declmodifiers “read” correctly.
> >> 3) Compared to Swift 2, there is almost no change.  The only thing that
> changes is that some uses of Swift 2 “private” will be migrated to
> “fileprivate”, which makes the intent of the code much more clear.
> >> 4) fileprivate is the unusual and
> not-really-precedented-in-other-languages modifier, and it would still be
> “googable”.
> >> 5) The addresses the “excessively long” declmodifier problem that
> several people are concerned with.
> >> 6) Support for named submodules could be “dropped in” by parameterizing
> “internal”.
> >>
> >> Thoughts?
> >>
> >> -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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

If not interfile I can suggest infile again too.

> On Mar 31, 2016, at 12:38 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> I’ve seen a number of concerns on this list about moduleprivate, and how it 
>> penalizes folks who want to explicitly write their access control.  I’ve 
>> come to think that there is yes-another possible path forward here (which I 
>> haven’t seen mentioned so far):
>> 
>> public
>> internal
>> fileprivate
>> private
> 
> I don't like how this ends up penalizing `fileprivate` with an ugly compound 
> keyword. I feel like, with the way I tend to factor my code, I would continue 
> using it reasonably often, and it would suck to have to use an ugly keyword.
> 
> Consider some of the places where we're still going to need `fileprivate`:
> 
> * Members used by operators or other free functions.
> * Members of nested types meant to be used only by the containing type.
> * Code which splits a type up into extensions. (We want to encourage this.)
> * Code which pairs a type with an extension adding an API using that type to 
> another type. (We want to encourage this too.)
> 
> These are all things we want to encourage, and things where just making them 
> `internal` is going to be tempting. Access control is a delicate thing; using 
> tight access control imposes obvious short-term costs for subtle long-term 
> gains, and so you're always tempted to cheat by making things broader than 
> they should be for your own convenience. The only thing keeping you from 
> cheating is your own discipline.
> 
> I worry that, if `fileprivate` is a long, ugly, obscure, and cumbersome 
> keyword, and `internal` works just as well but requires no typing at all, a 
> lot of people are going to do the wrong thing. We don't want that to happen.
> 
> -- 
> 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] Thoughts regarding readable INTENT of Loop keywords

[Taras Zakharko via swift-evolution]

I do not see how this is more readable. The current for loop is perfectly 
readable and conveys the intent very well IMO: it executes a code block FOR 
every ELEMENT that is IN a SEQUENCE. In contrast, I find your proposal rather 
confusing: it combines a number of different constructions with different 
semantics and generally is less transparent. 

Best, 

 Taras

> On 30 Mar 2016, at 21:54, Nathanial Burton-Bradford via swift-evolution 
>  wrote:
> 
> Swift Control Flow using Loops 
> 
> One of Swifts strengths is clear, readable INTENT, conveyed by the languages 
> Keyword tokens. For anyone new to programming, clear, readable intent, goes a 
> long way in helping them master the language, by helping reduce 
> logical/semantic errors caused by a misunderstanding of the names used in 
> specifying the languages keyword tokens…
> Swift’s control flow keywords can be ambiguous, in this respect, when 
> conveying the functional intent of loop control logic, within the language.
> 
> I would like to open up discussion, therefore, regarding the possible 
> renaming of Swift’s control flow keywords, with the hope that this leads to 
> clearer INTENT regarding loops. 
> 
> 
> Replace For-In with Loop Using 
> 
> for foo in d…y 
> loop foo using d…y
> 
> For x in 1…5
> loop x using 1…5
> 
> loop i=0 using i<10
> 
> loop i using 0..<10
> 
> 
> 
> For _ in 1 …power
> ———->
> loop using 1…power
> 
> “The underscore character (_) used in place of a loop variable causes the 
> individual values to be ignored and does not provide access to the current 
> value during each iteration of the loop.”
> 
> I feel underscore character (_) is confusing, semantically. 
> 
> 
> let names = ["Anna", "Alex", "Brian", “Jack"]
> for name in names {
> ———-> loop names using name {
> print("Hello, \(name)!")
> }
> 
> Note : loop ARRAY using ELEMENT(S) - which is logically consistent with 
> ‘-using’ as last keyword instance.
> 
> let numberOfLegs = ["spider": 8, "ant": 6, "cat": 4]
> for (animalName, legCount) in numberOfLegs {
> print("\(animalName)s have \(legCount) legs")
> }
> 
> loop numberOfLegs using (animalName, legCount) {
> print(“ \(animalName)s have \(legCount) Legs”)
> }
> 
> Note : Again loop ARRAY using ELEMENT(S) - which is logically consistent with 
> ‘-using’ as last keyword instance.
> 
> 
> for (airportCode, airportName) in airports {
> loop airports using (airportCode, airportName) 
> for airportCode in airports.keys {
> loop airports.keys using airportCode {
>
> for airportName in airports.values {
> loop airports.values using airportName {
> 
> for value in array[1.. loop array[1.. 
> ‘while’ using loop while 
> 
> loop while square < finalSquare {
> // roll the dice
> diceRoll += 1
> if diceRoll == 7 { diceRoll = 1 }
> // move by the rolled amount
> 
> Control transfer statements
> 
> repeat { 
> ——> loop {
> …
> } while 
> 
> 
> “Break
> The break statement ends execution of an entire control flow statement 
> immediately. ”
> 
> I propose replacing Break, in loops, with exit now (intent is explicit)
> Note: Labeled Statements with break - 
> break gameLoop exit now gameLoop
> 
> “Continue
> The continue statement tells a loop to stop what it is doing and start again 
> at the beginning of the next iteration through the loop.”
> 
> “switch character {
> case "a", "e", "i", "o", "u", " ":
> continue // Continue what? to next line? to end? to beginning?
> default:
> puzzleOutput.append(character)
> }”
> 
> I propose replacing continue with next cycle or next loop
> 
> 
> “switch character {
> case "a", "e", "i", "o", "u", " ":
> next cycle // intent is explicit
> default:
> puzzleOutput.append(character)
> }”
> 
> Note: Labeled Statements with Continue - as per Break example, next cycle 
> gameLoop 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Brent Royal-Gordon via swift-evolution]

> I’ve seen a number of concerns on this list about moduleprivate, and how it 
> penalizes folks who want to explicitly write their access control.  I’ve come 
> to think that there is yes-another possible path forward here (which I 
> haven’t seen mentioned so far):
> 
> public
> internal
> fileprivate
> private

I don't like how this ends up penalizing `fileprivate` with an ugly compound 
keyword. I feel like, with the way I tend to factor my code, I would continue 
using it reasonably often, and it would suck to have to use an ugly keyword.

Consider some of the places where we're still going to need `fileprivate`:

* Members used by operators or other free functions.
* Members of nested types meant to be used only by the containing type.
* Code which splits a type up into extensions. (We want to encourage this.)
* Code which pairs a type with an extension adding an API using that type to 
another type. (We want to encourage this too.)

These are all things we want to encourage, and things where just making them 
`internal` is going to be tempting. Access control is a delicate thing; using 
tight access control imposes obvious short-term costs for subtle long-term 
gains, and so you're always tempted to cheat by making things broader than they 
should be for your own convenience. The only thing keeping you from cheating is 
your own discipline.

I worry that, if `fileprivate` is a long, ugly, obscure, and cumbersome 
keyword, and `internal` works just as well but requires no typing at all, a lot 
of people are going to do the wrong thing. We don't want that to happen.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Thorsten Seitz via swift-evolution]

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[David Hart via swift-evolution]

Perhaps it's because I'm not a native English speaker, but interfile doesn't 
read well at all to me whereas fileprivate is crystal-clear.

> On 31 Mar 2016, at 08:21, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> public
> internal
> (fileprivate | interfile)
> private
> 
> Either choice is fine with me
> 
>> On Thu, Mar 31, 2016 at 11:33 AM, Jesse Squires via swift-evolution 
>>  wrote:
>> I really like this. +1 for the following:
>> 
>> public
>> internal
>> fileprivate
>> private
>> 
>> -Jesse
>> 
>>> On Wed, Mar 30, 2016 at 9:22 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  wrote:
>>> > How about we continue this trend, and follow other existing Swift 
>>> > keywords that merge two lowercase words (associatedtype, typealias, etc), 
>>> > and use:
>>> >
>>> >   public
>>> >   moduleprivate
>>> >   fileprivate
>>> >   private
>>> >
>>> > The advantages, as I see them are:
>>> > 1) We keep public and private meaning the “right” and “obvious” things.
>>> > 2) The declmodifiers “read” correctly.
>>> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
>>> > parenthesized keyword approach.
>>> > 4) The unusual ones would be “googable”.
>>> > 5) Support for named submodules could be “dropped in” by putting the 
>>> > submodule name/path in parens: private(foo.bar.baz) or 
>>> > moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
>>> > natural than putting keywords in parens.
>>> 
>>> I’ve seen a number of concerns on this list about moduleprivate, and how it 
>>> penalizes folks who want to explicitly write their access control.  I’ve 
>>> come to think that there is yes-another possible path forward here (which I 
>>> haven’t seen mentioned so far):
>>> 
>>> public
>>> internal
>>> fileprivate
>>> private
>>> 
>>> The advantages, as I see them are:
>>> 1) We keep public and private meaning the “right” and “obvious” things.
>>> 2) The declmodifiers “read” correctly.
>>> 3) Compared to Swift 2, there is almost no change.  The only thing that 
>>> changes is that some uses of Swift 2 “private” will be migrated to 
>>> “fileprivate”, which makes the intent of the code much more clear.
>>> 4) fileprivate is the unusual and not-really-precedented-in-other-languages 
>>> modifier, and it would still be “googable”.
>>> 5) The addresses the “excessively long” declmodifier problem that several 
>>> people are concerned with.
>>> 6) Support for named submodules could be “dropped in” by parameterizing 
>>> “internal”.
>>> 
>>> Thoughts?
>>> 
>>> -Chris
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
>> -- 
>> Jesse Squires
>> 
>> blog | jessesquires.com
>> github | github.com/jessesquires
>> hexedbits | hexedbits.com
>> 
>> ___
>> 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] Protected access level / multiple class/struct/protocol APIs

[Thorsten Seitz via swift-evolution]

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[David Hart via swift-evolution]

I love those. And internal corresponds to the meaning it has in other languages.

+1

> On 31 Mar 2016, at 06:22, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  wrote:
>> How about we continue this trend, and follow other existing Swift keywords 
>> that merge two lowercase words (associatedtype, typealias, etc), and use:
>> 
>>public
>>moduleprivate
>>fileprivate
>>private
>> 
>> The advantages, as I see them are:
>> 1) We keep public and private meaning the “right” and “obvious” things.
>> 2) The declmodifiers “read” correctly.
>> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
>> parenthesized keyword approach.
>> 4) The unusual ones would be “googable”.
>> 5) Support for named submodules could be “dropped in” by putting the 
>> submodule name/path in parens: private(foo.bar.baz) or 
>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
>> natural than putting keywords in parens.
> 
> I’ve seen a number of concerns on this list about moduleprivate, and how it 
> penalizes folks who want to explicitly write their access control.  I’ve come 
> to think that there is yes-another possible path forward here (which I 
> haven’t seen mentioned so far):
> 
> public
> internal
> fileprivate
> private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) Compared to Swift 2, there is almost no change.  The only thing that 
> changes is that some uses of Swift 2 “private” will be migrated to 
> “fileprivate”, which makes the intent of the code much more clear.
> 4) fileprivate is the unusual and not-really-precedented-in-other-languages 
> modifier, and it would still be “googable”.
> 5) The addresses the “excessively long” declmodifier problem that several 
> people are concerned with.
> 6) Support for named submodules could be “dropped in” by parameterizing 
> “internal”.
> 
> Thoughts?
> 
> -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] SE-0025: Scoped Access Level, next steps

[T.J. Usiyan via swift-evolution]

public
internal
(fileprivate | interfile)
private

Either choice is fine with me

On Thu, Mar 31, 2016 at 11:33 AM, Jesse Squires via swift-evolution <
swift-evolution@swift.org> wrote:

> I really like this. +1 for the following:
>
> public
> internal
> fileprivate
> private
>
> -Jesse
>
> On Wed, Mar 30, 2016 at 9:22 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  wrote:
>> > How about we continue this trend, and follow other existing Swift
>> keywords that merge two lowercase words (associatedtype, typealias, etc),
>> and use:
>> >
>> >   public
>> >   moduleprivate
>> >   fileprivate
>> >   private
>> >
>> > The advantages, as I see them are:
>> > 1) We keep public and private meaning the “right” and “obvious” things.
>> > 2) The declmodifiers “read” correctly.
>> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
>> awkward parenthesized keyword approach.
>> > 4) The unusual ones would be “googable”.
>> > 5) Support for named submodules could be “dropped in” by putting the
>> submodule name/path in parens: private(foo.bar.baz) or
>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
>> natural than putting keywords in parens.
>>
>> I’ve seen a number of concerns on this list about moduleprivate, and how
>> it penalizes folks who want to explicitly write their access control.  I’ve
>> come to think that there is yes-another possible path forward here (which I
>> haven’t seen mentioned so far):
>>
>> public
>> internal
>> fileprivate
>> private
>>
>> The advantages, as I see them are:
>> 1) We keep public and private meaning the “right” and “obvious” things.
>> 2) The declmodifiers “read” correctly.
>> 3) Compared to Swift 2, there is almost no change.  The only thing that
>> changes is that some uses of Swift 2 “private” will be migrated to
>> “fileprivate”, which makes the intent of the code much more clear.
>> 4) fileprivate is the unusual and
>> not-really-precedented-in-other-languages modifier, and it would still be
>> “googable”.
>> 5) The addresses the “excessively long” declmodifier problem that several
>> people are concerned with.
>> 6) Support for named submodules could be “dropped in” by parameterizing
>> “internal”.
>>
>> Thoughts?
>>
>> -Chris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
>
> --
> Jesse Squires
>
> *blog* | jessesquires.com 
> *github* | github.com/jessesquires 
> *hexedbits* | hexedbits.com 
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jesse Squires via swift-evolution]

I really like this. +1 for the following:

public
internal
fileprivate
private

-Jesse

On Wed, Mar 30, 2016 at 9:22 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 23, 2016, at 10:13 PM, Chris Lattner  wrote:
> > How about we continue this trend, and follow other existing Swift
> keywords that merge two lowercase words (associatedtype, typealias, etc),
> and use:
> >
> >   public
> >   moduleprivate
> >   fileprivate
> >   private
> >
> > The advantages, as I see them are:
> > 1) We keep public and private meaning the “right” and “obvious” things.
> > 2) The declmodifiers “read” correctly.
> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
> awkward parenthesized keyword approach.
> > 4) The unusual ones would be “googable”.
> > 5) Support for named submodules could be “dropped in” by putting the
> submodule name/path in parens: private(foo.bar.baz) or
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
> natural than putting keywords in parens.
>
> I’ve seen a number of concerns on this list about moduleprivate, and how
> it penalizes folks who want to explicitly write their access control.  I’ve
> come to think that there is yes-another possible path forward here (which I
> haven’t seen mentioned so far):
>
> public
> internal
> fileprivate
> private
>
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) Compared to Swift 2, there is almost no change.  The only thing that
> changes is that some uses of Swift 2 “private” will be migrated to
> “fileprivate”, which makes the intent of the code much more clear.
> 4) fileprivate is the unusual and
> not-really-precedented-in-other-languages modifier, and it would still be
> “googable”.
> 5) The addresses the “excessively long” declmodifier problem that several
> people are concerned with.
> 6) Support for named submodules could be “dropped in” by parameterizing
> “internal”.
>
> Thoughts?
>
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Jesse Squires

*blog* | jessesquires.com 
*github* | github.com/jessesquires 
*hexedbits* | hexedbits.com 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution