Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

It looks like there are 2 views being discussed Import System : just masks the difference in platform specific names Import Libc : a true attempt at a swift specific view of credible c runtime equivalent The first one would be easy to do now and would alleviate all the mindless #if...#endif we

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

Regards LM (From mobile) > On Jul 6, 2016, at 8:28 PM, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi there > > From the perspective from many active programmers > that use Swift (not objective C anymore) I am not > very happy by having to change > program source all the time: >

[swift-evolution] [Pitch] Removing the empty initialiser requirement from RangeReplaceableCollection

This is a follow up from this swift-users thread: https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160704/002489.html As it stands, RangeReplaceableCollection requires an implementation for init(), which is used in the default implementations of (as far as I can tell) init(_:), init(

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Regards LM (From mobile) > On Jul 6, 2016, at 10:39 PM, Tino Heth via swift-evolution > wrote: > > >> If you have a ParentClass and a SubClass, and the ParentClass is sealed >> while the SubClass is subclassable. What happens? No matter how this >> question is answered, I don't like the an

Re: [swift-evolution] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)

> On Jul 7, 2016, at 12:46 AM, Jordan Rose via swift-evolution > wrote: > > >> On Jul 6, 2016, at 11:03, Jacob Bandes-Storch via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> * Remove unsafeAddressOf. "We are not aware of any real use cases for it. If >> there are a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 7, 2016, at 1:10 AM, Ricardo Parada via swift-evolution > wrote: > > In the motivation section performance is 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. There kind of was

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

func needsCallback(callback: (a: Int, b: Int) -> Void) { callback(a: 1,b: 2) } func needsCallback(callback: (Int, Int) -> Void) { callback(1, 2) } Is the first one will be forbidden? So you'd like to keep the second one? > 在 2016年7月7日，11:06，Chris Lattner via swift-evolution > 写道： >

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

I'd rather like let bar = foo as (a:c:) to limit the possibility of bar not uncleared way. > >> 在 2016年7月7日，12:11，Félix Cloutier 写道： >> >> I personally find that { foo(a: $0, c: $1) } is an already simple enough way >> to solve that problem. >> >> Félix >> >>> Le 6 juil. 2016 à 20:50:17, C

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

> On Jul 6, 2016, at 9:16 PM, Pyry Jahkola wrote: > > I think one more thing needs clarification. Shouldn't the "defaulted" > `rounded()` and `round()` be defined as protocol extension methods *without* > the possibility to override the default rounding mode in a conforming type? > Like so: >

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

I think one more thing needs clarification. Shouldn't the "defaulted" `rounded()` and `round()` be defined as protocol extension methods *without* the possibility to override the default rounding mode in a conforming type? Like so: public protocol FloatingPoint { ... func rounde

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

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 beha

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

I personally find that { foo(a: $0, c: $1) } is an already simple enough way to solve that problem. Félix > Le 6 juil. 2016 à 20:50:17, Cao, Jiannan via swift-evolution > a écrit : > > l'd like the way of Python to handle the function signature.Assign lost other > possibility of that functio

Re: [swift-evolution] Dropping Comparable requirement for indices

> On Jul 6, 2016, at 20:41, Dave Abrahams via swift-evolution > wrote: > > There is no way, AFAIK, to implement important algorithms like rotate > binarySearch and several others, without having some representation of > position within a collection. Do you need indices to be explicitly comparab

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

l'd like the way of Python to handle the function signature.Assign lost other possibility of that function: foo(b:c:) foo(a:c:) foo(a:b:) foo(a:) foo(b:) foo(c:) foo() very weird. > 在 2016年7月7日，11:36，Douglas Gregor 写道： > > >> On Jul 6, 2016, at 8:34 PM, frog...@163.com wrote: >> >> so how

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

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md The review of "SE-0113: Add integral rounding functions to FloatingPoint " ran from June 30 ... July 5, 2016. The proposal has been *accepted*: The community and core team a

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

so how you call bar and get default values for a, b, c? why lost default value for that function? it is wired. > >> 在 2016年7月7日，11:29，Douglas Gregor 写道： >> >> >>> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution >>> wrote: >>> >>> Don't agree with this one. >>> >>> func foo(a:

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

> On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution > wrote: > > Don't agree with this one. > > func foo(a: Int = 0, b: Int = 1, c: Int = 2) { >print(a, b, c) > } > > foo(a: 1, c: 3) > > let bar = foo > > bar(1, 3) will different than foo(a: 1, c: 3) bar(1, 3) will result in

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

Don't agree with this one. func foo(a: Int = 0, b: Int = 1, c: Int = 2) { print(a, b, c) } foo(a: 1, c: 3) let bar = foo bar(1, 3) will different than foo(a: 1, c: 3) > 在 2016年7月7日，11:06，Chris Lattner 写道： > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposal

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

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*: The community and c

[swift-evolution] [Accepted] SE-0110: Distinguish between single-tuple and multiple-argument function types

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md The second review of "SE-0110: Distinguish between single-tuple and multiple-argument function types " ran from June 30 ... July 4, 2016. The proposal has been *accepted*: The comm

[swift-evolution] [Rejected] SE-0108: Remove associated type inference

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md The second review of "SE-0108: Remove associated type inference" ran from June 29 ... July 4, 2016. The proposal has been *rejected*: The community and core team agree that removing

Re: [swift-evolution] Dropping Comparable requirement for indices

on Wed Jul 06 2016, Haravikk wrote: >> On 6 Jul 2016, at 03:39, Dave Abrahams via swift-evolution >> wrote: >> For example, with >> Comparable indices, you can't build a linked list that supports >> restructuring (e.g. insert, delete, splice) in O(1) without invalidating >> indices... not even

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

on Tue Jul 05 2016, Dmitri Gribenko wrote: > On Tue, Jul 5, 2016 at 9:24 PM, Chris Lattner wrote: >> On Jul 5, 2016, at 6:57 PM, Dmitri Gribenko via swift-evolution >> wrote: >>> >>> Hi swift-evolution, >>> >>> Dave, Max and I have compiled a list of open issues in the standard >>> library fo

Re: [swift-evolution] [Review] SE-0118: Closure Parameter Names and Labels

on Wed Jul 06 2016, David Rönnqvist wrote: >>* What is your evaluation of the proposal? > > +1. These look like good improvements to me. (I'm also happy that the > map/filter/reduce naming was left out of this proposal) > > One thing I was wonder about was the capitalization of UTF8 in the

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

On 7/6/2016 1:52 AM, Chris Lattner wrote: >> On Jul 5, 2016, at 5:54 PM, Kevin Lundberg via swift-evolution >> wrote: >> >> * What is your evaluation of the proposal? >> >> -1 as is. I do not want to be constrained by authors of libraries or >> frameworks into interacting with a system in only t

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Strong +1 for me, separating access control from "open-to-subclasses" is a great feature. Leonardo's example of why final is not enough is great. My stance is that Swift should be safe by default, predictable, and the compiler should know enough about the code to actually help me and this proposa

Re: [swift-evolution] Removing Variadic Parameters.

On Wed, Jul 6, 2016 at 2:57 PM, Tino Heth via swift-evolution wrote: > Can you talk about concrete examples? Because Objective-C had no variadic > messages, it's natural that the feature isn't utilized in Cocoa Objective-C has variadic messages. I'd be surprised if any seasoned Objective-C devel

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

> On 7 Jul 2016, at 03:15, Karl wrote: > > >> On 7 Jul 2016, at 02:06, Dmitri Gribenko > > wrote: >> >> On Wed, Jul 6, 2016 at 4:21 AM, Karl > > wrote: >>> I had a PR open for this which added a Collection specialisation, but you >>> said

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

On Wed, Jul 6, 2016 at 6:15 PM, Karl wrote: > > On 7 Jul 2016, at 02:06, Dmitri Gribenko wrote: > > On Wed, Jul 6, 2016 at 4:21 AM, Karl wrote: > > I had a PR open for this which added a Collection specialisation, but you > said this could be handled in a more general way which allows for more >

Re: [swift-evolution] [Draft] Fix the Collection Partition API

on Tue Jul 05 2016, Nate Cook wrote: > Hi all, > > This is a crack at a proposal to revise the API of the collection > partition method, called out as an open issue in the standard > library. What's below is a much shorter revision of a prior proposal, > focused only on the partition method. I w

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

> On 7 Jul 2016, at 02:06, Dmitri Gribenko wrote: > > On Wed, Jul 6, 2016 at 4:21 AM, Karl wrote: >> I had a PR open for this which added a Collection specialisation, but you >> said this could be handled in a more general way which allows for more >> optimised mutations. I’m curious how this w

Re: [swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

Sent from my iPad > On Jul 6, 2016, at 6:50 PM, Dave Abrahams via swift-evolution > wrote: > > >> on Wed Jul 06 2016, Dave Abrahams wrote: >> >> Finally, as mentioned earlier we could easily supply a protocol that >> makes it no harder than conforming to IteratorProtocol is. You don't >>

Re: [swift-evolution] Dropping Comparable requirement for indices

Sent from my iPad > On Jul 6, 2016, at 7:33 PM, Xiaodi Wu via swift-evolution > wrote: > > I for one would be interested in your elaboration. Based on Dave's comments, > I'm pretty convinced that the Comparable requirement is best left in place. +1 >> On Wed, Jul 6, 2016 at 19:19 plx via s

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Sent from my iPad > On Jul 6, 2016, at 6:47 PM, Scott James Remnant wrote: > > >>> On Jul 6, 2016, at 4:34 PM, Matthew Johnson wrote: >>> >>> To give you an example of the confusion, here is code made perfectly legal >>> by SE-0025: >>> >>> public final class Example { >>> >>> over

Re: [swift-evolution] Dropping Comparable requirement for indices

I for one would be interested in your elaboration. Based on Dave's comments, I'm pretty convinced that the Comparable requirement is best left in place. On Wed, Jul 6, 2016 at 19:19 plx via swift-evolution < swift-evolution@swift.org> wrote: > My own 2c is to drop the comparable requirement. > > I

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Sent from my iPad > On Jul 6, 2016, at 6:39 PM, Scott James Remnant wrote: > > >> On Jul 6, 2016, at 4:34 PM, Matthew Johnson wrote: >> >> Many of us believe “final” is too blunt a tool. There are many cases where >> final cannot be used but you still don’t want external users subclassing

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> * What is your evaluation of the proposal? A **strong** -1 First, I have often found that you can’t always predict the way which something will need to be extended. You think you know, but are then surprised by creative uses. My favorite features of Swift/Cocoa involve retroactive modeling.

Re: [swift-evolution] Dropping Comparable requirement for indices

My own 2c is to drop the comparable requirement. I can elaborate if necessary, but wanted to at least cast my “+1” for removing the requirement. > On Jul 5, 2016, at 9:39 PM, Dave Abrahams via swift-evolution > wrote: > > > I've already raised the question here of whether we should weaken th

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

On Wed, Jul 6, 2016 at 4:21 AM, Karl wrote: > I had a PR open for this which added a Collection specialisation, but you > said this could be handled in a more general way which allows for more > optimised mutations. I’m curious how this would work; how does > `RangeReplaceableCollection.replaceSub

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

on Wed Jul 06 2016, Jacob Bandes-Storch wrote: > On Tue, Jul 5, 2016 at 10:50 PM, Dmitri Gribenko via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> > Remove unsafeAddressOf. We are not aware of any real usecases for it. If >> there are any, it should be renamed to unsafeAddress(o

[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> What is your evaluation of the proposal? Strong -1 from me. I agree that subclassing library classes that were not explicitly planned to be subclassed might sometimes lead to bugs. But just because a technique or feature of a language allows you to sometimes make mistakes, it doesn't mean it sh

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

on Wed Jul 06 2016, Karl wrote: > I’m quite interested in this point: > >> Figure out whether RangeReplaceableCollection.replaceRange should accept a >> Sequence as its argument, and if so implement it. > > At the moment `replaceSubrange` takes a sequence, No, actually at the moment it takes

Re: [swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

on Wed Jul 06 2016, Dave Abrahams wrote: > Finally, as mentioned earlier we could easily supply a protocol that > makes it no harder than conforming to IteratorProtocol is. You don't > even need to make your iteration state equatable because we can compare > counters stored in the indices. I'l

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 4:34 PM, Matthew Johnson wrote: >> >> To give you an example of the confusion, here is code made perfectly legal >> by SE-0025: >> >> public final class Example { >> >> overridable func foo() {} >> >> } > > I have no idea how you think this is related to SE-0025

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 4:34 PM, Matthew Johnson wrote: > > Many of us believe “final” is too blunt a tool. There are many cases where > final cannot be used but you still don’t want external users subclassing or > overriding. > > We would like a more precise tool for these circumstances and

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

I see two possible approaches: 1. A “import Libc” imports the platform libraries, whatever they may be, on the OS platform you are on. 2. The OS platform libraries are divided up, virtually if necessary, to expose the underlying standard interfaces without platform-specific extensions. I imagi

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 5:13 PM, Scott James Remnant wrote: > > >> On Jul 6, 2016, at 2:47 PM, Matthew Johnson > > wrote: >> >> This is not true. Public classes will *not* be “final by default”. It >> *will* be possible to subclass them within their declaring mod

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On 6 Jul 2016, at 18:09, Douglas Gregor wrote: > >> On Jul 5, 2016, at 10:35 PM, Ben Rimmington > > wrote: >> >>> On 5 Jul 2016, at 21:41, Douglas Gregor >> > wrote: >>> The following comment is incorrect, AFAIK. The `helpAnchor`

Re: [swift-evolution] [Discussion] Rename BitwiseOperations protocol

Another use case: I've got a BitArray that makes sense to conform to BitwiseOperations, but it definitely isn't a FixedWidthInteger. On Wed, Jul 6, 2016 at 17:56 Max Moiseev via swift-evolution < swift-evolution@swift.org> wrote: > OptionSets do conform to AlgebraSet but they require raw value t

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 5, 2016, at 7:11 PM, Chris Lattner 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/prop

Re: [swift-evolution] [Discussion] Rename BitwiseOperations protocol

OptionSets do conform to AlgebraSet but they require raw value type to conform to BitwiseOperations. Max > On Jul 6, 2016, at 3:44 PM, Jordan Rose wrote: > > Option sets use set notation, not bitwise notation, no? > > Jordan > >> On Jul 6, 2016, at 13:28, Max Moiseev via swift-evolution >>

Re: [swift-evolution] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)

> On Jul 6, 2016, at 11:03, Jacob Bandes-Storch via swift-evolution > wrote: > > > * Remove unsafeAddressOf. "We are not aware of any real use cases for it. If > there are any, it should be renamed to unsafeAddress(of:) to follow the > guidelines." (https://bugs.swift.org/browse/SR-1957 > <

Re: [swift-evolution] [Discussion] Rename BitwiseOperations protocol

Option sets use set notation, not bitwise notation, no? Jordan > On Jul 6, 2016, at 13:28, Max Moiseev via swift-evolution > wrote: > > FixedWidthInteger only handles the implementation for the numbers, we should > also consider OptionSet. > > I think we should keep the protocol in case some

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (binding memory to type)

> On Jul 4, 2016, at 7:52 PM, Jacob Bandes-Storch wrote: > > This is the first version of this proposal which I've had time to read. I > like it a lot overall. If I have some more time, I may try pulling the branch > and writing some code with it to see how it feels. (If we could get a > tool

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 2:47 PM, Matthew Johnson wrote: > > This is not true. Public classes will *not* be “final by default”. It > *will* be possible to subclass them within their declaring module. If they > need to be final they will still need to be marked as such. > > With that in mind,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 4:36 PM, Scott James Remnant via swift-evolution > wrote: > > >> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa > > wrote: >> >> You can also try and simplify your outlines reducing X.c and X.d to a >> single entry as it is the same rule applied to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

I don't disagree with you on 'fileprivate' and 'private' being unnecessary and we may stick to the proposal at hand and leave the 'final' issue to another proposal, should anyone else care (I myself don't mind if it sticks around - just have to not use it). As for the conflict, I don't see it. Can

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 1:41 PM, Goffredo Marocchi via swift-evolution > wrote: > Sent from my iPhone > >> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution >> wrote: >> >> In the era of increased open sourcing, easy forking, and more >> community-driven development, this concern is le

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa wrote: > > You can also try and simplify your outlines reducing X.c and X.d to a > single entry as it is the same rule applied to two different elements > of the language. Using one single keyword (such as in 'open') would > make it clearer and that

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa wrote: > > So I did get what you meant right. Now tell me: if a class or method > is internal to your module (and you know internal means only you, > throught your source code, inside your app or library can extend it), > do you really need to mark a

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> * What is your evaluation of the proposal? +1 (almost exclusively) Writing good library code is hard and a lot of code isn't actually written to be externally subclasses (and trying to plan for subclassing can be difficult). Our team also writes "final class" in a lot of places and I don't

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 3:41 PM, Goffredo Marocchi wrote: > >> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution >> wrote: >> >> In the era of increased open sourcing, easy forking, and more >> community-driven development, this concern is less severe than it used to >> be. I rarely u

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

So I did get what you meant right. Now tell me: if a class or method is internal to your module (and you know internal means only you, throught your source code, inside your app or library can extend it), do you really need to mark anything as final for any reason? Final on any non-publics is a res

Re: [swift-evolution] Dropping Comparable requirement for indices

> On 6 Jul 2016, at 03:39, Dave Abrahams via swift-evolution > wrote: > For example, with > Comparable indices, you can't build a linked list that supports > restructuring (e.g. insert, delete, splice) in O(1) without invalidating > indices... not even an unsafe linked list with reference semanti

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Sent from my iPhone > On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution > wrote: > > In the era of increased open sourcing, easy forking, and more > community-driven development, this concern is less severe than it used to be. > I rarely use any closed-sourced libraries for iOS dev

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> If you have a ParentClass and a SubClass, and the ParentClass is sealed while > the SubClass is subclassable. What happens? No matter how this question is > answered, I don't like the answer. (compile error => bad. || make it as the > user wishes => bad; what do we gain by letting ParentClass

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

>* What is your evaluation of the proposal? +1. I find this to be a solid, well reasoned proposal. I enjoyed seeing such a detailed Motivation and am looking forward to discussing the Related Proposals and Future Directions mentioned in this one. >* Is the problem being addressed signi

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> > On Jul 6, 2016, at 1:16 PM, Leonardo Pessoa wrote: > > Scott, I think your writing got a bit confuse but, if I got your > intention right, since you are the owner of the class, you may choose > to subclass it or not internally, no questions asked. No. This is how the language exists today:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 5, 2016, at 8:45 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I think Kevin Lundberg is right to worry about testability, but I don't think > that has to prevent this change. Instead, we should permit `@testable` > imports to subclass/override things that are not publicly

Re: [swift-evolution] [Discussion] Rename BitwiseOperations protocol

FixedWidthInteger only handles the implementation for the numbers, we should also consider OptionSet. I think we should keep the protocol in case someone wants to implement their own type other than an integer to be used as a raw value type in the OptionSet. As for renaming it, how about Bitwis

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> * What is your evaluation of the proposal? +1, with bikeshedding. To me, “subclassable” does not imply “public.” If I hadn’t read this proposal, I would be likely to declare an internal class subclassable, and then be shocked when it was exposed as public! If it’s part of my public API, I w

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Scott, I think your writing got a bit confuse but, if I got your intention right, since you are the owner of the class, you may choose to subclass it or not internally, no questions asked. I need no finals in my apps and I only subclass if I intend to. If you are in control of your own code, why wo

Re: [swift-evolution] Removing Variadic Parameters.

I'd be reluctant to remove variadic parameters. We've found on our team that variadic arguments are easier to read on the call site compared to array arguments, especially when it's common to pass a single value (but still possible to pass multiple values). - David > On 6 Jul 2016, at 20:38, T

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> 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 > I posted this somewhere else

Re: [swift-evolution] Removing Variadic Parameters.

> I believe variadic parameters are useful in a range of situations and > I use them myself a lot. Can you talk about concrete examples? Because Objective-C had no variadic messages, it's natural that the feature isn't utilized in Cocoa, but I doubt that it is used by many native Swift libraries

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 12:50 PM, Leonardo Pessoa wrote: > > Scott, you really got a point here: should this proposal pass, I > believe the final keyword should be removed as it would be already the > default behaviour and thus unnecessary. I don't think this is on the > proposal. > Removing the

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 6, 2016, at 12:35 PM, Leonardo Pessoa via swift-evolution > wrote: > Intention. > > IMO, intention may lead to more secure systems (and libraries). By > having to explicitly final everything I have to choose with parts of > my class/library would be locked and have to worry and check if

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Scott, you really got a point here: should this proposal pass, I believe the final keyword should be removed as it would be already the default behaviour and thus unnecessary. I don't think this is on the proposal. L On 6 July 2016 at 16:47, Scott James Remnant via swift-evolution wrote: > -1 >

Re: [swift-evolution] Dropping Comparable requirement for indices

> On Jul 5, 2016, at 9:39 PM, Dave Abrahams via swift-evolution > wrote: > > I've already raised the question here of whether we should weaken the > requirement that Collection.Index be Comparable to merely being > Equatable. > > Part of the motivation was to support data structures that othe

Re: [swift-evolution] [Review] SE-0118: Closure Parameter Names and Labels

>* What is your evaluation of the proposal? +1. These look like good improvements to me. (I'm also happy that the map/filter/reduce naming was left out of this proposal) One thing I was wonder about was the capitalization of UTF8 in the first example. Shouldn't that be s.withUTF8Buffer(proc

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

-1 This proposal makes Swift a more confusing language. Swift already has a mechanism for creating public subclassable classes and non-subclassable classes: public class SubclassableParentClass { } public final class NonSubclassableParentClass { } This mechanism also applies to methods,

Re: [swift-evolution] [Discussion] Parentheses

I'll try to rephrase my initial post a bit, perhaps it will make my point clearer: Might it be that some of the confusion regarding the evolution (design/redesign) of tuples, parameter lists, etc. stems from the fact that they all use parentheses? Or put differently: Parentheses, being used for so

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Intention. IMO, intention may lead to more secure systems (and libraries). By having to explicitly final everything I have to choose with parts of my class/library would be locked and have to worry and check if any public thing could be used to exploit it or make the system work in a way I did not

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0116: Import Objective-C id as Swift Any type

+1 “AnyObject” has always seemed to me to be quite weird in Swift, since it considers classes to be special when compared to value types. Any move to lessen its use gets my vote. A comment on Impact on existing code in the proposal: due to the nature of the bridging, it is still going to be v

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

> On Jul 5, 2016, at 10:09 AM, Magnus Ahltorp via swift-evolution > wrote: > >> 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-unsafer

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Leonardo, how is defaulting to final/sealed helping you write better libraries than having a final keyword for what you need to close instead? Sent from my iPhone On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution wrote: >> The review of "SE-0117: Default classes to be non-subclassa

Re: [swift-evolution] Removing Variadic Parameters.

-1_000_000_000 I believe variadic parameters are useful in a range of situations and I use them myself a lot. As you mentioned yourself, you never created variadic functions and you are allowed to continue working like that for as long as it suits you so. It is a choice and you and other developer

Re: [swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

on Wed Jul 06 2016, Anton Zhilin wrote: > 1. Do nothing with finiteness, because huge sequences are mostly like > infinite ones, plus because infinite loops are useful > 2. Allow collections to be infinite > 3. Do not add new fields to collections, because infinite loops are > useful No argumen

Re: [swift-evolution] Removing Variadic Parameters.

On Wed, Jul 6, 2016 at 11:38 AM Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > It's a late answer… but I wanted to be a good citizen and checked if the > topic has been discussed before; so, it seems that is not the case ;-) > > In short, I agree: > Variadic parameters are som

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

On Wed, Jul 6, 2016 at 11:30 AM, Harlan Haskins wrote: > I’ve also seen unsafeAddressOf(_:) used when interfacing with C function > pointers when the lifetime of an object is guaranteed. Many C APIs vend an > API like: > > void perform_action(void (*callback)(void *data), void *initial_data); > >

Re: [swift-evolution] Removing Variadic Parameters.

It's a late answer… but I wanted to be a good citizen and checked if the topic has been discussed before; so, it seems that is not the case ;-) In short, I agree: Variadic parameters are somewhat cool, and I think I was exited when I've seen them in C the first time… but I afair, I never created

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

Most source breaking changes will be made in Swift 3. From now on code should be mostly backwards compatible. On Wed, Jul 6, 2016 at 11:28 AM Ted F.A. van Gaalen via swift-evolution < swift-evolution@swift.org> wrote: > Hi there > > From the perspective from many active programmers > that use Swi

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

I’ve also seen unsafeAddressOf(_:) used when interfacing with C function pointers when the lifetime of an object is guaranteed. Many C APIs vend an API like: void perform_action(void (*callback)(void *data), void *initial_data); For which it is expected to use unsafeAddressOf on a class instanc

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference

> On Jul 6, 2016, at 10:43 AM, Jordan Rose wrote: > >> >> On Jul 1, 2016, at 15:53, Russ Bishop > > wrote: >> >> >>> On Jun 30, 2016, at 4:23 PM, Jordan Rose via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> [Proposal: >>> https://github.com

[swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

Hi there From the perspective from many active programmers that use Swift (not objective C anymore) I am not very happy by having to change program source all the time: Therefore after Swift 3.0 is released I’d recommend kindly: Freeze Swift For Some Time! Do Not Change AnyThing For At Le

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> Am 06.07.2016 um 01:11 schrieb Chris Lattner via swift-evolution > : > > 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-evo

Re: [swift-evolution] [Discussion] Parentheses

On 06.07.2016 20:51, Joe Groff wrote: On Jul 6, 2016, at 7:47 AM, Vladimir.S via swift-evolution wrote: On 06.07.2016 3:57, Jens Persson via swift-evolution wrote: Please feel free to ignore this naive attempt to engage in this discussion. My understanding of the history of Swift's tuples,

Re: [swift-evolution] Dropping Comparable requirement for indices

on Wed Jul 06 2016, Brent Royal-Gordon wrote: >> On Jul 5, 2016, at 7:39 PM, Dave Abrahams via swift-evolution >> wrote: >> >> Anyway, the thoughts of the community on this topic would be interesting >> to us. We need to make a decision about this very soon. > > I've wanted the Index protoco

Re: [swift-evolution] [Discussion] Cleaning up stdlib pointer and buffer routines (Open Issues Affecting Standard Library API Stability)

> * *Remove unsafeAddressOf*. "We are not aware of any real use cases for > it. If there are any, it should be renamed to unsafeAddress(of:) to follow > the guidelines." (https://bugs.swift.org/browse/SR-1957 > rdar://problem/18589289) > > Oops, I just responded to this on another thread. Pasting:

Re: [swift-evolution] Open Issues Affecting Standard Library API Stability

On Tue, Jul 5, 2016 at 10:50 PM, Dmitri Gribenko via swift-evolution < swift-evolution@swift.org> wrote: > > > Remove unsafeAddressOf. We are not aware of any real usecases for it. If > there are any, it should be renamed to unsafeAddress(of:) to follow the > guidelines. > Obvious, unless someone

  1   2   >