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

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md ] John has done a tremendous job supporting this proposal; the position he’s articulated very closely matches mine. Thank you to both John and Javier. I wanted to share a

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

> On Jul 6, 2016, at 09:16, John McCall via swift-evolution > wrote: > >> On Jul 5, 2016, at 10:56 PM, Chris Lattner wrote: >>> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution >>> wrote: >>> I

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

> On Jul 1, 2016, at 3:50 PM, Dave Abrahams via swift-evolution > wrote: >> • Redesigning `prefix(upTo:)`, `prefix(through:)` and `suffix(from:)` >> as subscripts with "partial" ranges, like `people[..> `people[nil.. > Yes please; I really

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

Strong -1 from me. I think most of my thoughts on this have already been well covered by others. I’ll just note that this proposal reminds me of the fortune file entry, “Whenever you see a sign that says ‘no exit’, it means there is an exit there.” Specifically, under this proposal, whenever

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

While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s

Re: [swift-evolution] Addition of a standardError OutputStream

Right now it's more like "foo".write(to: ) but I agree that having to implement a custom stream is kind of irritating for stderr and stdout. import Cocoa var str = "Hello, playground" struct StderrStream: OutputStream { static var shared = StderrStream() func write(_ string: String) {

Re: [swift-evolution] [Proposal] Variadics as Attribute

Hi! I read through this proposal, and I have the feeling that we are trying to solve an issue with Swift from the wrong angle. IMHO Swift has one of the best implementations of variadics which has only one major downfall: passing an array as a variadic argument is not possible. Maybe it would

Re: [swift-evolution] [Proposal] Variadics as Attribute

I think if Int... === [Int] would be true, then it would introduce a new set of ambiguity and defaulting to a specific behaviour would be a "good guess" rather than a reliable logic. Best, Kristóf > On 08 Jul 2016, at 22:24, Leonardo Pessoa wrote: > > Kristof, this is the

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

on Thu Jul 07 2016, Dave Abrahams wrote: > on Wed Jul 06 2016, Jacob Bandes-Storch wrote: > >>> * *Remove unsafeAddressOf*. "We are not aware of any real use cases for >>> it. If there are any, it should be

[swift-evolution] Addition of a standardError OutputStream

Currently, it’s rather annoying to print to standard error, requiring either something low-level like fputs. I was wondering if a standardError OutputStream could be added to the standard library, so we could write something like print(“foo”, ). -- -Saagar Jha

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

Some minor points: 1. One major reason for wanting control over which targets are exported are so packages can control which parts of their API is supported for external use. This is very important to large projects undergoing active development while also trying to support a well-defined,

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

on Fri Jul 08 2016, plx wrote: >> On Jul 6, 2016, at 7:33 PM, Xiaodi Wu 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. > >

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

On Thu, Jul 7, 2016 at 2:02 PM, Kostiantyn Koval via swift-build-dev < swift-build-...@swift.org> wrote: > Hi > Thanks for the proposal, looks very nice. > > The *Package.swift* manifest files is very string typed already, (package > name, url, target names, etc) and and think that is ok in our

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

Personally I think a great compromise is just forcing the user to use the `override` keyword when subclassing in these cases. That way the library maker can mark classes that aren't supported or are internal and ideally shouldn't be used by the programmer. However we shouldn't baby sit

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

The stories I’ve seen about things Apple’s frameworks need to deal with are another. I don’t have links handy but they shouldn’t be too hard to find for anyone interested in looking. > On Jul 8, 2016, at 4:21 PM, Leonardo Pessoa wrote: > > I've sent one I currently have

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

I've sent one I currently have myself. Look back on the thread posts. L On 8 July 2016 at 18:14, Tino Heth via swift-evolution wrote: > > When was the last time you you thought "I really wish the author of that > library had restricted my options to use it"? > > > I

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

>> When was the last time you you thought "I really wish the author of that >> library had restricted my options to use it"? > > I really wish Objective-C had this feature from the start. I believe there > would have been significant benefits to Apple's platforms and ecosystem. The >

Re: [swift-evolution] [Proposal] Variadics as Attribute

Maybe we can introduce #variadic compiler magic to expand array to varidict parameters. e.g. func sum(x: Int...) let x = [1, 2, 3] sum(#variadic(x)) ___ swift-evolution mailing list swift-evolution@swift.org

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

This sounds like a scenario where you'd be using or extending an existing stdlib generic type such as Set, no? On Fri, Jul 8, 2016 at 15:53 Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > Right now I'm working on a lib for charts/plots, and I choose to create a > custom

Re: [swift-evolution] [Proposal] Variadics as Attribute

I meant only for the sake of variadics. That would "teach" the compiler to read "func x(args : Int...)" from our code and interpret it too as "func x(args ; [Int])" thus accepting lists of arguments or an array with the arguments with no additional effort from our part. L On 8 July 2016 at

Re: [swift-evolution] [Proposal] Variadics as Attribute

Kristof, this is the closest to what I've been proposing but I'm really unable to understand why it is to had to just change the compiler to recognise an array passed as argument to a variadic argument. No need for any extra keywords or complicated solutions, just make the compiler recognise that

[swift-evolution] [Discussion] Seal `T.Type` into `Type`

Hello Swift community, before Swift 3 drops I’d like to discuss if it is reasonable to consider to create a standalone type to drop/seal the T.Type magic? However this change does not play well with the proposal of dropping the .self compiler magic. Some bikeshedding: public struct Type :

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

> On Jul 6, 2016, at 7:33 PM, Xiaodi Wu 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. I am short on time (and will remain so for several more weeks) so

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

> On Jul 8, 2016, at 12:30 PM, Tino Heth via swift-evolution > wrote: > > Defaults matter, because they transmit a message: > Every rule and obstacle we add to Swift is a statement that says "we favor > bureaucracy over freedom", and this will affect the community

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

Just to relax a bit, from reading this thread I cannot help but feel a relation to Civil War. One can even say on which side everyone here would stand for real. #TeamIronMan L On 8 July 2016 at 15:13, Matthew Johnson via swift-evolution wrote: > > > Sent from my iPad

Re: [swift-evolution] [Discussion] Parentheses

Thank you all, I guess it's impossible / very hard to come up with a design without such inconsistencies and ambiguities, especially when parentheses are used for so many different things in the language. /Jens On Thu, Jul 7, 2016 at 10:33 PM, Anton Zhilin wrote: > I

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

Hey Joe, I’m +1 on the overall direction, but I have some questions/concerns about the "Ambivalent dynamic casting from Any” section. 1) When you suggest that `x as String` succeeds but `x as NSString` fails, I assume this would only be true *after* SE-0083, since otherwise we’d be violating

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

Sent from my iPad > On Jul 8, 2016, at 12:30 PM, Tino Heth <2...@gmx.de> wrote: > > >> 1. As you point out, the majority of the surface area of idiomatic Swift >> APIs are unlikely to be impacted (value types, protocols, and final >> classes). This is very likely to apply to future

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

on Thu Jul 07 2016, Taras Zakharko wrote: >> * What is your evaluation of the proposal? > > In general +1, except maybe the change of to isOrderedBefore: by: in > sort-related functions. I fear that the new label makes it less clear > that the ordering relation

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

Sent from my iPad > On Jul 8, 2016, at 12:32 PM, John McCall wrote: > >> On Jul 8, 2016, at 8:24 AM, Matthew Johnson wrote: >>> On Jul 8, 2016, at 10:05 AM, Thorsten Seitz wrote: Am 08.07.2016 um 15:59 schrieb Matthew

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

> On Jul 8, 2016, at 8:24 AM, Matthew Johnson wrote: > On Jul 8, 2016, at 10:05 AM, Thorsten Seitz > wrote: >> Am 08.07.2016 um 15:59 schrieb Matthew Johnson > >:

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

> 1. As you point out, the majority of the surface area of idiomatic Swift APIs > are unlikely to be impacted (value types, protocols, and final classes). > This is very likely to apply to future Swift-native APIs from Apple > regardless of the outcome of this proposal. > > 2. There is no

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

> On Jul 7, 2016, at 4:16 PM, Goffredo Marocchi wrote: > > > > On Thu, Jul 7, 2016 at 11:15 PM, John McCall > wrote: > n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution >

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

On Jul 8, 2016, at 10:56 AM, Dave Abrahams wrote: > > > on Fri Jul 08 2016, Jordan Rose wrote: > This reads like an English sentence, but it doesn’t have the correct meaning for me. This implies a structure that has a pre-existing “separator", and checks if

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

on Fri Jul 08 2016, Jordan Rose wrote: >>> This reads like an English sentence, but it doesn’t have the correct >>> meaning for me. This implies a structure that has a pre-existing >>> “separator", and checks if that separator matches the predicate, >>> rather than searching for an element that

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

> On Jul 7, 2016, at 17:57, Dave Abrahams wrote: > > > on Thu Jul 07 2016, Jordan Rose > wrote: > >> [Proposal: >> https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md >> ] >> >> Hi, Dave,

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

I would like to add my vote for pushing Foundation as a cross-platform compatibility layer, rather than exposing "Libc". Naturally there is flexibility in designing the APIs to be appropriately Swifty. I would also like to see higher level concepts available via Foundation, like protocols for

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

On Tue, Jul 5, 2016 at 7:11 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> 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: > > >

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

Sent from my iPad > On Jul 8, 2016, at 10:05 AM, Thorsten Seitz wrote: > > > >> Am 08.07.2016 um 15:59 schrieb Matthew Johnson : >> >> >> >> Sent from my iPad >> >>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz wrote: >>>

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

> Am 08.07.2016 um 15:59 schrieb Matthew Johnson : > > > > Sent from my iPad > >> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz wrote: >> >> >> >>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution >>>

Re: [swift-evolution] [Discussion] "try" for function that does not throw

> Xcode creates warning as you type And the warnings also tend to obscure my typing (rdar://27141386 - warning box occludes typing when trying to fix a warning). I turn live issues off (even though that kind of breaks playground error reporting - rdar://27162167 - playgrounds don't show any

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

* What is your evaluation of the proposal? Strong +1. I believe supporting public inheritance is the single most complicated thing in modern API design; thus, allowing inheritance to happen without explicit approval of the API designer is clearly a bad idea. I'm OK with the

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

Sent from my iPad > On Jul 8, 2016, at 8:48 AM, Thorsten Seitz wrote: > > > >> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution >> : >> >> >> >> Sent from my iPad >> >>> On Jul 7, 2016, at 5:15 PM, John McCall via

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

Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution : Sent from my iPad On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution wrote: n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution

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

* What is your evaluation of this proposal? A reluctant +1. I’m reluctant because I actually do love the flexibility in Obj-C to subclass where I feel appropriate, and feel the limitations of this are going to be difficult to get used to. From what I see, however, “final” as a concept makes

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

Sent from my iPad > On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution > wrote: > > n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution > wrote: >> I disagree that a stable for over 30 years of every OOP language

Re: [swift-evolution] [Discussion] Allow injection of `didSet` and `willSet`

True story, if you’re doing something heavy and there are tons of calls from your observed property you’d pay with a huge performance decrease. Personally I don’t feel like this would be something that stays in the way of having this handy feature, because it’s always up to us to balance the

Re: [swift-evolution] [Discussion] Allow injection of `didSet` and `willSet`

I also would like to mention a problem I see with this ‘feature’. Lets say this is my module: public struct A { public var member1: Int = 42 public var member2: Int = 0 { didSet { self.member1 = self.member2 } } } >From

Re: [swift-evolution] [Discussion] Allow injection of `didSet` and `willSet`

There are (were?) plans for generalized property behaviors; those would be used to implement lazy, as well as didSet/willSet, and could incorporate many other things (including injection) Of course, an option to observe variables would be handy — but there's always a price to pay, and you'll

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 8 Jul 2016, at 12:03, Leonardo Pessoa wrote: > You would have to add some extra code on the compiler to check whether you > can use that type for your variadics argument and may incur in more changes > to enable handling different classes possible. Not really; the

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

> On 6 Jul 2016, at 00:11, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > > > The goal of the review process is to improve the proposal under review > through constructive criticism and contribute to the direction of Swift. When >

Re: [swift-evolution] [Discussion] Allow injection of `didSet` and `willSet`

Thats a good point! Here is some bikeshedding: public extension UIViewController { observe public var view: UIView { willSet { // do something useful here } didSet { // do something useful here } } } An

Re: [swift-evolution] [Discussion] Allow injection of `didSet` and `willSet`

+1. This would allow us to create observers on any foreign variable. I'm far from a compiler right now but I wouldn't this syntax create a new variable instead of observing an existing one? Even if not, by reading this one could be mislead to believe so. Perhaps you should give it something to

Re: [swift-evolution] [Proposal] Variadics as Attribute

It is definitely not hard to solve any issues here (if you consider only the basic variadics). Int... is nothing more than [Int], so essentially func doSomething(args : Int...) is also just func doSomething(args : [Int]) We just have to think of it like some form of function overloading

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

I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once

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

> Chris Lattner wrote: > > 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 > >

Re: [swift-evolution] [Proposal] Variadics as Attribute

> On 8 Jul 2016, at 10:31, Pyry Jahkola wrote: > > If you take this function for example, > > func printThem(@variadic _ values: [Any]) > > then what would `values` be in the following calls, and why? > > printThem() // clearly [] > printThem(1) // clearly

Re: [swift-evolution] [Proposal] Variadics as Attribute

I'm not sure if the timing of this proposal is coincidence (I recently revived a discussion to remove variadics), but although I stated variadics are not that important, I like this idea much better than the "…"-syntax which looks like a carryover from C… "@variadic" is not only more explicit,

Re: [swift-evolution] [Accepted with revision] SE-0077 v2: Improved operator declarations

The syntax we ended up with is not really perfect from my point of view, but I assume that core team knows what they are doing :P But I still wonder if discussion on standard precedence groups is possible before Swift 3. It does not require any implementation: if we settle on something, we will

Re: [swift-evolution] [Proposal] Variadics as Attribute

I agree that we should have a way to call a variadic function with an Array at hand, without needing to take its elements apart (`foo(x[0], x[1], x[2])`) — which indeed is only practical when we statically know its length. But I fear there's a shortcoming in this proposal that hasn't been

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

> Aw. It's really bad that labels are gone for closures at the call site . > IMHO, the same principles that encourage the use of labels for "normal" > function calls should prevail here. No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been

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

Am 07. Juli 2016 um 10:10 schrieb Goffredo Marocchi via swift-evolution : Hey Charlie, The change you reference and this must work together, I have a hard time accepting that we will have a Swift 3 with this change in and no other change that balances it. If

[swift-evolution] [Discussion] Allow injection of `didSet` and `willSet`

Hello dear Swift community, I’m not sure if this was discussed before or not, but I really want to know if something like this is welcome for the future Swift version. If this topic was already discussed, I’m apologizing for bringing it back to life in a new thread. Lets say I’ve got a third

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

> Charlie Monroe wrote: > > This hasn't occurred to me until now, but this will also elminate the > following (right?): > > public typealias XUURLRequestModifier = (request: NSMutableURLRequest) -> Void > > Which is really nice since when expanded by Xcode, this automatically offers > you

Re: [swift-evolution] [Discussion] "try" for function that does not throw

A try that isn't needed is suspicious… but imho there is a problem with warnings, but that isn't primarily caused by Swift itself. Xcode creates warning as you type, and those often don't help, but just distract, as most of them aren't actually dangerous at all: - Yes, I'm not using this value

Re: [swift-evolution] Proposal: SwiftPM Target Access Control

I agree with Tanner, an AccessControl enum clearly defines the access of a target and provides flexibility for future. On Fri, Jul 8, 2016 at 3:17 AM, Tanner Nelson wrote: > Really happy to see this proposal. It will cut build times for packages > that use my library

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

> On Jul 8, 2016, at 1:01 AM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jul 06 2016, Jacob Bandes-Storch wrote: > >>> * *Remove unsafeAddressOf*. "We are not aware of any real use cases for >>> it. If there are any, it

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

This hasn't occurred to me until now, but this will also elminate the following (right?): public typealias XUURLRequestModifier = (request: NSMutableURLRequest) -> Void Which is really nice since when expanded by Xcode, this automatically offers you the "request" label for the variable so you

Re: [swift-evolution] [Proposal] Variadics as Attribute

I like this proposal. I was a bit against when the discussion around the removal of variadics arose, but I fee that this proposal takes a good whack at the problem. I have struggled with array vs. variadic arguments for several methods, ending up implementing both overloads and the variadic

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

It feels so odd especially because of the added emphasis by the core team for argument labels for Swift 3 only to have this passed. What is the pro of not having argument labels in callbacks or functions stored in properties, how does this make for good readability or consistency with instance

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

> * What is your evaluation of the proposal? In general +1, except maybe the change of to isOrderedBefore: by: in sort-related functions. I fear that the new label makes it less clear that the ordering relation is that of strict precedence. It can be particularly confusing for people

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

For JSONFusion this won't work at all, as the code base is largely Objective-C with lots of Swift-related annotations and depend on Objective-C and Swift ABI details to work. The main trick in JSONFusion is property introspection which don't play nice with Swift yet, and for JSFRemote the main