[swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

[Brad Hilton via swift-evolution]

+1. Feels more Swifty to keep things simple when additional complexity isn’t 
warrented.

> Hello Swift community,
> 
> 
> The review of SE-0191 "Eliminate IndexDistance from Collection" begins now 
> and runs through December 3, 2017. The proposal is available here:
> 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.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/0191-eliminate-indexdistance.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
> 
> 
> Review Manager
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] SE-0171: Reduce with inout

[Brad Hilton via swift-evolution]

+1. Would love to see this in the standard library both for it’s improved 
performance and succinctness.

> Hello Swift community,
> 
> The review of “SE-0171:Reduce with inout" begins now and runs through the 
> Friday after next, April 14th. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md(https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.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 
> themessage:
> 
> Proposal 
> link:https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md(https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.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 
> athttps://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> Ben Cohen
> Review Manager
> 
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] SE-165: Dictionary & Set Enhancements

[Brad Hilton via swift-evolution]

+1. These are great, swifty additions to the standard library. Good job Nate 
Cook!

> Hello, Swift community!
> 
> The review of "SE-165: Dictionary&Set Enhancements" begins now and runs 
> through next Tuesday, April 11th. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.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/0165-dict.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,
> 
> Ben Cohen
> Review Manager
> 
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Unify the way properties and methods work to make key-value coding more natural

[Brad Hilton via swift-evolution]

I like the .get syntax better than \
I’d be okay with the slightly more verbose .getter
Foo.a could return a tuple: (getter: (Foo) -> () -> A, setter: (Foo) -> (A) -> 
())

> Recently I’ve seen some upcoming changes for #keyPath, but the whole things 
> look a bit messy to me. Today I came up with a simple idea of code 
> generation, but I thought maybe it would be nice to make this a part of the 
> language?
> 
> Look at this code:
> 
> publicclassFoo {
> publicvara:Int=0
> }
> 
> publicfinalclassProperty{
> publicvar`get`: (U) ->() ->V
> publicvar`set`: (U) ->(V) ->Void
> 
> publicinit(getter:@escaping(U) ->() ->V, setter:@escaping(U) ->(V) ->Void) {
> self.get = getter
> self.set = setter
> }
> }
> 
> // Generated code
> publicextensionFoo{
> publicstaticleta:Property= {
> returnProperty(getter: { instance ->(Void) ->Intin
> return{returninstance.a} },
> setter: { instance ->(Int) ->Voidin
> return{ value ->Voidininstance.a = value } })
> }()
> }
> 
> letfoo = Foo()
> foo.a =5
> 
> let_a = Foo.a.get(foo)()
> print(_a)
> 
> Foo.a.set(foo)(10)
> print(foo.a)
> 
> 
> The idea is to make properties work the same way the methods work right now. 
> That will allow things like tweening properties in the game engine, by simply 
> passing the property to some sort of ActionManager.
> 
> Of course, this can be achieved by code-generator, but I bet this will be 
> very ineffecient in terms of performance.
> 
> The only draw back here from top of my head: It will be impossible to have 
> instance- and static- variables with the same name.
> 
> What do you think about this?___
> 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-0167: Swift Encoders

[Brad Hilton via swift-evolution]

-1. I left my feedback for this proposal and SE-0166 on the other thread, but 
TLDR; I think this is premature until we add true reflection capabilities
to Swift.

> Hello Swift community,
> 
> 
> The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
> 2017. The proposal is available here:
> 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
> Note that this proposal is closely related to (and dependent on)SE-0166: 
> Swift 
> Archival&Serialization(https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md).
>  Please read and review that proposal as well!
> 
> 
> 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/0167-swift-encoders.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
> 
> 
> Review Manager
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0166: Swift Archival & Serialization

[Brad Hilton via swift-evolution]

-1. I support the motivation, but I think this proposal and SE-0167 are too 
premature.

Don’t get me wrong, I think that Swift leaves much to be desired as far as 
serialization/deserialization goes. However I think that these proposals are 
putting the cart before the horse. I think we first need to add genuine 
reflection APIs before adding encoding/decoding capabilities to the stdlib. 
Reflection will substantially simply most serialization/deserialization task. 
These APIs borrow too much Cocoa’s native archiving capabilities for my taste 
and I’d rather not introduce something that may be considered legacy in the 
future.


> Hello Swift community,
> 
> 
> The review of SE-0166 "Swift Archival&Serialization" begins now and runs 
> through April 12, 2017. The proposal is available here:
> 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.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/0166-swift-archival-serialization.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
> 
> 
> Review Manager
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Brad Hilton via swift-evolution]

Yes. I'd prefer to keep unapplied method references the same and do
properties the same way IMHO.

On Thu, Apr 6, 2017 at 12:05 PM, Douglas Gregor  wrote:

>
> On Apr 6, 2017, at 11:01 AM, Brad Hilton  wrote:
>
> -1. Not a huge fan of the back slash. Doesn’t make sense considering we
> can refer to unapplied method references without the backslash. Maybe we
> can settle on some unified syntax for both? How about Person.name.get /
> Person.name.set for getter/setter references.
>
>
> Did you read the core team’s commentary on unapplied method references?
>
> https://lists.swift.org/pipermail/swift-evolution-
> announce/2017-April/000342.html pipermail/swift-evolution-announce/2017-April/000342.html>
>
> ?
> - Doug
>
>
> Hello Swift community,
>
> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for
> Swift" begins now and runs through April 9, 2017. The revised proposal is
> available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0161-key-paths.md swift-evolution/blob/master/proposals/0161-key-paths.md>
> The core team’s feedback from the first review of this proposal can be
> viewed at:
>
> https://lists.swift.org/pipermail/swift-evolution-
> announce/2017-April/000342.html pipermail/swift-evolution-announce/2017-April/000342.html>
> 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<
> 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/0161-key-paths.md evolution/blob/master/proposals/0161-key-paths.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<
> https://github.com/apple/swift-evolution/blob/master/process.md>
> Thank you,
>
> -Doug
>
> Review Manager
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Brad Hilton via swift-evolution]

-1. Not a huge fan of the back slash. Doesn’t make sense considering we can 
refer to unapplied method references without the backslash. Maybe we can settle 
on some unified syntax for both? How about Person.name.get / Person.name.set 
for getter/setter references.

> Hello Swift community,
> 
> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
> Swift" begins now and runs through April 9, 2017. The revised proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
> The core team’s feedback from the first review of this proposal can be viewed 
> at:
> 
> https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html
> 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/0161-key-paths.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
> 
> Review Manager
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Brad Hilton via swift-evolution]

Big -1 from me. The introduction of private/fileprivate access levels was a 
huge win for Swift 3. I would really hate to see it go.

> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.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
> 
> Review Manager
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Swift4] Mailing list vs. Forum

[Brad Hilton via swift-evolution]

+1. I would love to see Swift Evolution on Slack or a forum, it would be so 
much easier to manage.

Brad

> Branching...
> 
> On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via 
> swift-evolutionmailto:swift-evolution@swift.org)>wrote:
> > On Jul 29, 2016, at 5:14 PM, Brandon 
> > Knopemailto:bkn...@me.com)>wrote:
> > >
> > >Chris, has the core team discussed opening up a forum for discussing 
> > >proposal implementations.
> > >
> > >Some of us aren't as skilled as the core team or other contributors but 
> > >would like to learn. A forum is a much easier place for us to post for 
> > >code help and to help others with their questions. I think this could help 
> > >get more involved as it would be a more comfortable format for them. Think 
> > >of how there are Apple Developer forums and not mailing lists for iOS 
> > >betas etc.
> > >
> > >I am not saying moving swift-evo to forums *yet* but I believe a lot of 
> > >the newer programmers are more comfortable with a forum format, especially 
> > >when it comes to help and discussing code.
> > >
> > >Forums for contributors would:
> > >- be more familiar for a lot of the newer and not as experienced developers
> > >- be easier to search
> > >- be easier to moderate (not really a problem yet)
> > 
> > Hi Brandon,
> > 
> > Moving from email to a forum system has come up before, but they have some 
> > disadvantages.One of major wins of email is that it is pervasive and can be 
> > adapted into other forms.For example, if you haven’t seen it yet, check out:
> > https://stylemac.com/hirundo/
> > 
> > -Chris
> > 
> We've discussed forums on swift-evolution before. Maybe it's time for another 
> go, with Swift 3 winding down.
> 
> For context, prior discussions are on this 
> thread:https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
> 
> (-1 for mailman: it's hard for me to even properly find&link to all the prior 
> discussion about mailing lists, because of how mailman's archive works...)
> 
> 
> News in the last few days is that Gmane is at least temporarily 
> disappearing:https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
> 
> 
> I'd just like to vote once again 
> forDiscourse(http://www.discourse.org/faq/#what):-Excellent web 
> interface(https://meta.discourse.org/), from the people who brought you Stack 
> Overflow(built-in search, etc.)
> - Read via email if that's your thing: it has "mailing list mode" which 
> includes 1-email-per-post, if that's your cup of tea
> -Reply via 
> email(https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099)if 
> that's your thing
> - It'sopen source(https://github.com/discourse/discourse)itself
> - I believe it has ways of getting content as JSON and/or RSS, so I'd hardly 
> say "can be adapted into other forms" is an exclusive feature of email.
> 
> And, Discourse providesfree hosting for community-friendly open-source 
> projects(http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/).
>  Istrongly 
> suspect(https://twitter.com/jtbandes/status/705886542309363712)Swift would 
> qualify for this.
> 
> 
> There have been several people on this list arguing in favor of mailing lists 
> — I encourage folks to go read the old thread for themselves.
> 
> It's worth noting there are also plenty of voices that don't get heard on 
> this list, because people just don't like using mailing lists. One 
> example:https://twitter.com/pilky/status/755105431555608580___
> 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-0117: Default classes to be non-subclassable publicly

[Brad Hilton via swift-evolution]

I completely agree with rparada and give a strong, strong, strong -1 to this 
proposal. To make classes non-subclassable by default is only going to lead to 
unanticipated pain and frustration. Also agree with other comments that 
subclassable and overridable conflate access control with class behavior. If we 
want to make it possible to define a class as non-subclassable to external 
users, I’d agree to something more consistent with existing swift access 
control like public(final) as has been proposed by other commenters. However, I 
agree that making classes final by default is a bad idea that will create a 
larger problem that it solves.

Also, just a more general complaint, I sometimes feel that the evolution list 
is being dominated by safety enthusiasts at the expense of usability advocates. 
Safety is a premier feature of Swift, but so is usability. We should be trying 
to find solutions that advance both objectives, as well as performance and 
power.

> On Jul 5, 2016, at 7:11 PM, Chris 
> Lattnermailto:clatt...@apple.com)>wrote:
> 
> > Hello Swift community,
> > 
> > The review of "SE-0117: Default classes to be non-subclassable publicly" 
> > begins now and runs through July 11. The proposal is available here:
> > 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> > 
> > * What is your evaluation of the proposal?
> -1
> 
> Perhaps because this is so different from what I have seen in other languages 
> and used for so many years. I have not worked with a language that uses 
> non-subclassable/ non-overridable as the default.
> 
> I think that by default classes should be subclassable, not the other way 
> around. I am afraid that developers will not take the time to specify which 
> methods are overridable resulting in libraries that are difficult to patch, 
> extend.
> 
> In my 26+ years of object-oriented design and programming (other languages, 
> Objective-C since 1990 and Java since 2001) I have worked with object 
> oriented libraries and subclassed methods that the authors probably never 
> anticipated. I have been able to fix problems, enhance classes by creating 
> subclasses with fixes and enhanced behavior.
> 
> In java for example I have seen that sometimes I would have been able to fix 
> bugs or enhance the existing classes had the author not chosen a method to be 
> protected or private. Sometimes they had a good reason but sometimes they 
> didn't.Is have been able to survive using an awesome library that was 
> discontinued and end-of-lifed thanks to subclassing that has allowed me to 
> fix problems and enhance over the years as the Java language kept evolving.
> 
> In general I like to design classes with methods that have a very well 
> defined purpose / logic. Such methods are potentially overridable. I find 
> that making a method private or final can be selfish / restrictive at times 
> and I choose it carefully for implementation details that are better served 
> by going through the public methods.
> 
> I think that making a class not subclassable by default is restrictive / 
> limiting / selfish.
> 
> Sometimes the extension points are clear.
> I also think that every other method with a well defined purpose / logic is 
> also potentially an extension point.
> 
> In my experience we should allow the developer to override by default.That is 
> how I design my classes and every method / property.
> 
> I use private for the stuff that is obvious that should not be exposed.
> 
> In the motivation sectionperformanceis also mentioned as driving this 
> proposal. However I don't see any study that supports that. I would like to 
> see that. This should not be taken lightly.
> 
> Let's imagine that performance is important for a library that is heavily 
> used and that the classes are not the type that you usually override. 
> Wouldn't we be better servedby being able to seal the class, i.e. "public 
> sealed class Foo"and then for the methods / properties that are clear 
> extension points should be flaggedoverridable.I would prefer something like 
> that. And I think it would be more intuitive.
> 
> 
> > * Is the problem being addressed significant enough to warrant a change to 
> > Swift?
> No.
> 
> > * Does this proposal fit well with the feel and direction of Swift?
> I think it is counter-intuitive.I don't think that reading "public class Foo" 
> would make anyone think that Foo is non-subclassable.
> 
> On the other hand, reading "public class sealed Foo" would suggest to the 
> reader that the class can be overridden but only the methods that are flagged 
> asoverridable.
> 
> If we wanted to prohibit overriding then we could use "public final class 
> Foo" without any extension points. Then nobody would be able to subclass and 
> it would be an error to try to flag a method / property as overridable.
> 
> 
> > * If you have used other languages or libraries with a similar feature, how 
> > do you feel that 

[swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

[Brad Hilton via swift-evolution]

> What is your evaluation of the proposal?
I think it’s good to have this functionality in the standard library, but it 
seems a bit inconsistent with other Swift math operators which are declared as 
global functions such as abs, max, +, -, /, *, %, etc.
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes, I believe that it would be useful to have these methods.
> Does this proposal fit well with the feel and direction of Swift?
As I mentioned before, it seems to be a departure from Swift’s other math 
operators. I think global functions such as floor(), ceil() and round() would 
be more consistent.

> Hello Swift community,
> 
> The review of "SE-0113: Add integral rounding functions to FloatingPoint" 
> begins now and runs through July 5. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.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 contribute to 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,
> 
> -Chris Lattner
> Review Manager
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

[Brad Hilton via swift-evolution]

> What is your evaluation of the proposal?

-1. Argument labels can have meaning and are very useful, especially for 
default parameter names in closures:

```// Declaration
func handleResponse(handler: (response: Response) -> ())

// Callsite
handleResponse { response in // response automatically implied as the parameter 
name, clarifying usage.
  ...
}
```

I’d prefer we leave the existing behavior or consider the alternative solution 
to prohibit implicit subtyping.

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

I don’t feel that it does. I’ve always felt that being able to declare function 
types with named parameters was a powerful feature that allowed more 
expressivity in the language.

``` // Clear that the first String argument is the message and that the second 
is the sender
let messageHandler: (message: String, sender: String) -> ()

// Not clear what these parameters are
let messageHandler: (String, String) -> ()```

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

The closest comparison I can think of are Objective-C selectors, but these are 
more powerful and type-safe. I think it’s a real strength of the language.

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

A quick reading, and I have used function declarations with and without labels 
extensively.

> Hello Swift community,
> 
> The review of "SE-0111: Remove type system significance of function argument 
> labels" begins now and runs through July 4. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.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 contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 

> * 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,
> 
> -Chris Lattner
> Review Manager
> 
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0107: UnsafeRawPointer API

[Brad Hilton via swift-evolution]

* What is your evaluation of the proposal?
-1. It seems like the author is trying to solve a non-problem. The pointer APIs 
already work very well with enough due warning that they are unsafe. This 
change will just make them even more cumbersome to work with.
* Is the problem being addressed significant enough to warrant a change to 
Swift?
No, I don’t think so, and if it were it would be too significant to be 
considered in scope for Swift 3.
* Does this proposal fit well with the feel and direction of Swift?
It’s a valid Swift API, I just feel it makes the UnsafePointer family more 
complex than it needs to be.
* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Swift’s approach to memory access has been unique in my programming experience 
and I like it for its power and simplicity.
* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I read most of the proposal and have done a lot of work with the existing 
pointer APIs. Again I feel this is adding needless complexity and doesn’t 
actually change what you can do with the API.

> Hello Swift community,
> 
> The review of “SE-0107: UnsafeRawPointer API” begins now and runs through 
> July 4, 2016. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.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 contribute to 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,
> 
> -Chris Lattner
> Review Manager
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

[Brad Hilton via swift-evolution]

+1. I agree that this could be a problem, especially if you’re importing a lot 
of similar modules.  I like the `from` keyword, as I feel that is consistent 
with the language grammer. My vote would be for proposal #4.

> Hello, everyone.
> 
> I want to discuss the problem of name ambiguity when a computed property or 
> function is defined with the same name and type in different modules. 
> Currently there’s no way to disambiguate the implementation in use cases 
> similar to the one contained in the gist below.
> 
> https://gist.github.com/paulofaria/f48d0b847a0fb7c125d163d0e349500a
> 
> The gist also contains some informal proposals. The idea is to create a 
> formal proposal based on the discussion that shall follow.
> 
> Cheers,
> Paulo ___
> 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-0041: Updating Protocol Naming Conventions for Conversions

[Brad Hilton via swift-evolution]

>* What is your evaluation of the proposal?

+1. Having consistent conventions makes sense to me. I’d prefer `Initializable` 
to `Creatable` which sounds weird to me, but otherwise sounds great.

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

I think semantic consistency is important.

> * 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 don’t know if I’ve seen a similar standard in other languages.

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

I’ve been following this proposal for weeks and if approved it will influence 
my work.


> Hello Swift community,
> 
> The review of "SE-0041: Updating Protocol Naming Conventions for Conversions" 
> begins now and runs through May 16. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.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 contribute to 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,
> 
> -Chris Lattner
> Review Manager
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

[Brad Hilton via swift-evolution]

You're right and since you can't nest any kind of type in a generic type
right, that wouldn't work even with this proposal. However, in the generics
manifesto they did say that they intend to remove that restriction. If they
do lift the restriction, they may have to leave an exception in place for
protocols.

On Thu, Apr 28, 2016 at 5:27 PM, Douglas Gregor  wrote:

>
> On Apr 28, 2016, at 10:15 AM, Brad Hilton via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Type nesting allows some convenient and straightforward semantics that we
> see inside the Swift standard library such as views on String like
> String.CharacterView, String.UnicodeScalarView, etc. However a protocol
> cannot be nested in a type and gives a non-obvious error that the
> “Declaration is only valid at file scope.” Just as other nested types allow
> proper contextual scoping, a nested protocol could make a lot sense for a
> number of patterns. For example, there are many “Delegate” protocols
> throughout the Cocoa frameworks. Here’s a controller/delegate pattern
> before and after type nesting:
>
> // Without type nesting
>
> protocol MyControllerDelegate : class {
>
> }
>
> class MyController {
>
> weak var delegate: MyControllerDelegate?
>
> }
>
> // With type nesting
>
> class MyController {
>
> weak var delegate: Delegate?
>
> protocol Delegate : class {
>
> }
>
> }
>
> Though the change is mostly semantics, it does allow an explicit
> association between My Controller and the Delegate instead of only a named
> association. It also cleans up the module name space like other nested
> types and makes associated protocols more discoverable in my opinion.
>
> I’d love to hear everyone’s thoughts.
>
>
> Note that this cannot work when any enclosing type is generic, e.g.,
>
> class MyController {
>   protocol Delegate {
> // I’ve just created a parameterized protocol!
>   }
> }
>
>
> Otherwise, I don’t see any issues with the proposal, and I like that it
> eliminates a large number of top-level names.
>
> - Doug
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Allow nested protocol declarations

[Brad Hilton via swift-evolution]

Type nesting allows some convenient and straightforward semantics that we see 
inside the Swift standard library such as views on String like 
String.CharacterView, String.UnicodeScalarView, etc. However a protocol cannot 
be nested in a type and gives a non-obvious error that the “Declaration is only 
valid at file scope.” Just as other nested types allow proper contextual 
scoping, a nested protocol could make a lot sense for a number of patterns. For 
example, there are many “Delegate” protocols throughout the Cocoa frameworks. 
Here’s a controller/delegate pattern before and after type nesting:

// Without type nesting

protocol MyControllerDelegate : class {

}

class MyController {

weak var delegate: MyControllerDelegate?

}

// With type nesting

class MyController {

weak var delegate: Delegate?

protocol Delegate : class {

}

}

Though the change is mostly semantics, it does allow an explicit association 
between My Controller and the Delegate instead of only a named association. It 
also cleans up the module name space like other nested types and makes 
associated protocols more discoverable in my opinion. 

I’d love to hear everyone’s thoughts.

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

[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

[Brad Hilton via swift-evolution]

The Completing Generics Manifesto suggests a more universal solution with 
generic value parameters which is my vote:
Generic value parameters

Currently, Swift’s generic parameters are always types. One could imagine 
allowing generic parameters that are values, e.g.,

struct MultiArray { // specify the number of dimensions 
to the array
  subscript (indices: Int...) -> T {
get {
  require(indices.count == Dimensions)
  // ...
}
}

A suitably general feature might allow us to express fixed-length array or 
vector types as a standard library component, and perhaps also allow one to 
implement a useful dimensional analysis library. Tackling this feature 
potentially means determining what it is for an expression to be a “constant 
expression” and diving into dependent-typing, hence the “maybe”.

> To better support interfacing with lower level systems, like graphics
> libraries for example, it would be helpful to support the concept of
> contiguous variables. The most common use case for this would be to create
> a Matrix struct that can be passed as data into something like Metal. This
> can be accomplished now, using something like the following:
> 
> Current Option 1:
> 
> struct Matrix2x2 {
> var m00: Float
> var m01: Float
> var m10: Float
> var m11: Float
> }
> 
> OR
> Current Option 2:
> 
> struct Matrix2x2 {
> var m: (Float, Float, Float, Float)
> }
> 
> OR
> Current Option 3:
> 
> struct Matrix2x2 {
> var m: [Float]
> }
> 
> Options 1&2 allow for the compiler to enforce the fixed number of
> elements and also for the data to be easily passed into graphics libraries
> as their memory layout is somewhat predictable using sizeof, strideof, and
> alignof. The downside is that you lose the ability to easily subscript or
> iterate the elements.
> 
> Option 3 does allow subscripting and iteration, but does not at compile
> time enforce a fixed number of elements and is not as easily passed into a
> library that expects to receive the raw data of the matrix.
> 
> 
> Contiguous Variables:
> 
> struct Matrix2x2 {
> var m: Float:2*2
> }
> 
> The variable `m` represents a series of 4 contiguous Float values. The
> specific number of values must be a compile time constant. The only needed
> functionality includes `count`, `subscript`, and iteration. To make things
> easier to implement and to help avoid confusion and more complex
> documentation, multiple dimensions are not allowed. To define multiple
> dimensions you must provide your own ordering by wrapping this type in
> another type and providing a custom subscript implementation. For example:
> 
> struct RowMajorMatrix2x2 {
> var m: Float:2*2
> 
> static let rows = 2
> static let columns = 2
> 
> subscript(row: Int, column: Int) ->Float {
> return m[column * Matrix2x2.rows + row]
> }
> }
> 
> sizeof(Matrix2x2) is 16
> strideof(Matrix2x2) is 16
> 
> m.count is essentially a compile time constant and is not stored with the
> rest of the data but is available and can also be used to do runtime bounds
> checking.
> 
> struct Vector3 {
> var v: Float:3
> }
> 
> sizeof(Vector3) is 12
> strideof(Vector3) is 12
> 
> C code should also now be able to expose data types that contain fixed
> sized arrays within them.
> 
> 
> ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution