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

> On Jul 5, 2016, at 6:53 PM, John McCall 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

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

> 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 the ways they

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

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

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

> On 5 Jul 2016, at 21:41, Douglas Gregor wrote: > >> The following comment is incorrect, AFAIK. The `helpAnchor` is the name >> attribute of a HTML anchor element. >> >> /// A localized message providing "help" text if the user requests help. >> var helpAnchor:

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

+1. I'd prefer the "open" keyword though, and use it as a modifier of public. El mié., 6 jul. 2016 a las 1:24, Charlie Monroe via swift-evolution (< swift-evolution@swift.org>) escribió: > Huge +1. > > Question about inheritance though: > > class A {} // Not publicly subclassable > subclassable

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

Huge +1. Question about inheritance though: class A {} // Not publicly subclassable subclassable class B: A {} // Publicly subclassable class C: B {} // Not publicly subclassable? Or is the subclassability inherited? I'm not a big fan of the subclassable keyword either since it's quite long,

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

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 for which the resolutions could result non-additive API > changes. Having a resolution

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

I hadn't considered @testable, and it may be one way to mitigate the trouble this could cause in tests, so thank you both for bringing it up as the proposal should definitely account for it. I'm curious though how this would solve the case of trying to subclass a module's class in a test where you

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

> On Jul 5, 2016, at 5:54 PM, Ben Rimmington wrote: > >> >> On 6 Jul 2016, at 01:02, Douglas Gregor > > wrote: >> >>> On Jul 5, 2016, at 5:00 PM, Ben Rimmington >> >

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

> On Jul 5, 2016, at 7:16 PM, Karl via swift-evolution > wrote: > > #1 - “extendable class”// explicitly clear about what I’m allowing The problem is that it's very clear about what you're allowing—you're allowing `extension`s. Which of course isn't *actually*

[swift-evolution] Dropping Comparable requirement for indices

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 otherwise would be expensive or impossible to implement. For example, with Comparable

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

> On 6 Jul 2016, at 01:11, Chris Lattner via swift-evolution > 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: > > >

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

This post describes the standard library team's analysis of the finite/infinite sequence issue raised by Matthew Johnson and others in http://news.gmane.org/find-root.php?message_id=1976B8AE%2dFDD1%2d4257%2dA24F%2d2AFF84115445%40anandabits.com. [Dmitri is going to write a separate post detailing

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

Sent from my iPad > On Jul 5, 2016, at 8:53 PM, John McCall via swift-evolution > wrote: > > >>> On Jul 5, 2016, at 6:45 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>>* What is your evaluation of the proposal? >>

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

Hi swift-evolution, Dave, Max and I have compiled a list of open issues in the standard library for which the resolutions could result non-additive API changes. Having a resolution (and an implementation of the resolution!) for these issues is blocking API stability.

Re: [swift-evolution] Public classes with private superclass

> On Jul 5, 2016, at 6:48 PM, Karl via swift-evolution > wrote: >> On 5 Jul 2016, at 08:49, Andre via swift-evolution >> wrote: >> >> Personally, it's perhaps more of an "aesthetic" thing I suppose but I would >> definitely prefer that my

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

> On Jul 5, 2016, at 6:45 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > I think it's ultimately a good idea. Being noncommittal about > subclassability/overridability—and thus forbidding it in public

Re: [swift-evolution] Public classes with private superclass

> On 5 Jul 2016, at 08:49, Andre via swift-evolution > wrote: > > Personally, it's perhaps more of an "aesthetic" thing I suppose but I would > definitely prefer that my internal classes stay internal even if there is a > public subclass... I don't like how that

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

> * What is your evaluation of the proposal? I think it's ultimately a good idea. Being noncommittal about subclassability/overridability—and thus forbidding it in public scope, but not making any promises about what the module does internally—is the alternative that preserves the most

Re: [swift-evolution] [Proposal] Sealed classes by default

> On Jul 2, 2016, at 10:58 AM, L. Mihalkovic > wrote: > > > Regards > LM > (From mobile) > > On Jun 30, 2016, at 9:12 AM, John McCall > wrote: > >>> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic

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

Extremely strong +1 from me on this proposal. It is the best default for many, many reasons (stated in the proposal and in Austin's review). It improves safety, facilitates and encourages reasoning about code, and will result in an ecosystem of overall higher quality. Sent from my iPad > On

[swift-evolution] [Discussion] Parentheses

Please feel free to ignore this naive attempt to engage in this discussion. My understanding of the history of Swift's tuples, argument lists, pattern matching, associated values, etc. in two steps: 1. Initial Idealism *: Simple powerful heavily reused general concept. 2. Iterative pragmatism /

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

* 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 the ways they forsee. By making the default be non-subclassable, if a designer does not put thought into all the ways a class can be

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

> On 6 Jul 2016, at 01:02, Douglas Gregor wrote: > >> On Jul 5, 2016, at 5:00 PM, Ben Rimmington wrote: >> >> >> >> The new protocols could be combined into a

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

On Jul 5, 2016, at 5:41 PM, Saleem Abdulrasool wrote: > On Tuesday, July 5, 2016, Chris Lattner > wrote: > >> On Jul 5, 2016, at 5:28 PM, Saleem Abdulrasool >

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

> On Jul 5, 2016, at 5:28 PM, Saleem Abdulrasool wrote: > > On Tuesday, July 5, 2016, Chris Lattner > wrote: > >> On Jul 5, 2016, at 2:59 PM, Brian Gesiak via swift-evolution >> >

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

+1 with modifications. In my team we write “final class” a lot. We also do have a lot of internal frameworks and an ability to guide external frameworks uses is important for us. We have a lot of candidates in our frameworks that should be inheritable internally, but we do not recommend to

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

> On Jul 5, 2016, at 5:00 PM, Ben Rimmington wrote: > > > > The new protocols could be combined into a single CustomNSError protocol. > This would mirror the NSError class APIs,

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

The new protocols could be combined into a single CustomNSError protocol. This would mirror the NSError class APIs, which are being customized. Instead of using

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

I'll bite. On Tue, Jul 5, 2016 at 4:11 PM, Chris Lattner wrote: > > > * What is your evaluation of the proposal? > Strong +1. I like this proposal because it forces programmers vending a public API to think about their extension points, and it also provides

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

I have a patch that implements this proposal *except* this part. (aka () -> Void means 0 argument therefore { _ in } is a mismatch). If we were to interpret tuple and the outer paren as described in this proposal, it should be consistent everywhere, therefore requires more consideration

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

> > What is your evaluation of the proposal? > +1 Is the problem being addressed significant enough to warrant a change to > Swift? > Yes. Passing value types to Objective-C APIs taking AnyObject requires creating wrapper classes that store the value types. This change would eliminate that

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

> On Jul 5, 2016, at 2:59 PM, Brian Gesiak via swift-evolution > wrote: > > Sorry to resurrect such an old thread! I understand getting this in Swift 3.0 > might not be realistic anymore, but this is still something I’d love to see > added to Swift. Could someone

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

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 Reviews are an

Re: [swift-evolution] Class mutation model and value-constrained protocols

I definitely see Dave’s point here. It seems to me we can only get generic to the point at which the semantics change. So methods that don’t have any mutating consequences can be applied to any value such as Structs and Classes, but when the semantic relates to mutation, we can only apply that

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

Hello Swift community, The review of "SE-0118: Closure Parameter Names and Labels" begins now and runs through July 11. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md Reviews are an important

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

on Tue Jul 05 2016, Andrew Trick wrote: >> On Jul 2, 2016, at 10:10 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> I have a pile of naming quibbles; rather than describe them all in >> prose (which turned into a mess), I've

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

on Sat Jul 02 2016, Brent Royal-Gordon wrote: > One ridiculous thing we could do for `moveAssign(from:count:)` and > perhaps `move()` is to deliberately make `self` invalid by setting it > to address 0. If it were `Optional`, this would nil `self`. If it >

Re: [swift-evolution] Notification.Name

Hi Brent, In general, I agree with your idea that the scope of the name of these things is with the type it’s used for. The type of it is of course Notification.Name. One thing we did in the short term to make this feature even remotely possible was to add an importer rule: global const

Re: [swift-evolution] Class mutation model and value-constrained protocols

> > If we are going to maintain source stability after Swift 3, it seems > that we either need to address this now, or decide that it won't be > addressed, because of the “viral const” problem. > IMHO immutable instances and value vs reference allocation are separate concerns. Just like you

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

> On Jul 5, 2016, at 5:12 PM, Dave Abrahams wrote: > > > on Tue Jul 05 2016, Matthew Johnson wrote: > >>> On Jul 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Tue Jul 05 2016, Jordan Rose >>

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

on Tue Jul 05 2016, Matthew Johnson wrote: >> On Jul 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue Jul 05 2016, Jordan Rose > > wrote: >> > >>> [Proposal: >>>

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

Sorry to resurrect such an old thread! I understand getting this in Swift 3.0 might not be realistic anymore, but this is still something I’d love to see added to Swift. Could someone advise on whether it still makes sense to spend time on this proposal? Or is this part of Swift too solidified to

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

> On Jul 5, 2016, at 3:17 PM, Dave Abrahams wrote: > > > on Tue Jul 05 2016, Jordan Rose > wrote: > >> [Proposal: >> https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md >> >>

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

Trying my hardest to summarize the talking points of the conversation so far. Please let me know if I’ve missed any particular points: - The thread was started (by yours truly) as an offshoot of another on-list conversation involving Dave Abrahams. In it, I voiced a concern that there were not

Re: [swift-evolution] Class mutation model and value-constrained protocols

> On Jul 5, 2016, at 4:15 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jul 05 2016, Chris Lattner wrote: > >>> It's also possible that I've overestimated the seriousness of the issue >>> and we actually can afford to postpone thinking about it until

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

> On Jul 5, 2016, at 4:17 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jul 05 2016, Jordan Rose > wrote: > >> [Proposal: >> https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md >> >>

Re: [swift-evolution] Class mutation model and value-constrained protocols

Comments inline. > On Jul 5, 2016, at 2:11 PM, Dave Abrahams wrote: > > > on Tue Jul 05 2016, Jonathan Hull > wrote: > >> Comments inline >>> A “mutating” keyword on a protocol method is only useful if >>> you can reason about the mutation in

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

on Tue Jul 05 2016, Jordan Rose wrote: > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md > > ] > >> On Jul 3, 2016, at 9:52, David

Re: [swift-evolution] Class mutation model and value-constrained protocols

on Tue Jul 05 2016, Chris Lattner wrote: >> It's also possible that I've overestimated the seriousness of the issue >> and we actually can afford to postpone thinking about it until after >> Swift 4. > > There is no chance that we will have time to re-evaluate this for Swift 3. There are too

Re: [swift-evolution] Class mutation model and value-constrained protocols

on Tue Jul 05 2016, Jonathan Hull wrote: > Comments inline >> A “mutating” keyword on a protocol method is only useful if >> you can reason about the mutation in generic code. >> >> protocol P { >> mutating func changeMe() >> func noChange() -> Int >> } >> >> In other words,

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API "initialize(from:forwardToCount:)"

on Tue Jul 05 2016, Andrew Trick wrote: >> On Jul 5, 2016, at 10:48 AM, Dave Abrahams via swift-evolution >> wrote: >> >>> I want to call this out separately because it’s not specific to my >>> proposal and changes the existing UnsafePointer API. >>> > >>> Brent’s

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

> On Jul 3, 2016, at 5:02, Vladimir.S via swift-evolution > wrote: > > On 02.07.2016 4:20, Daniel Duan via swift-evolution wrote: >>> Vladimir.S via swift-evolution writes: >> >> Following your conclusion, should this be legal as well? >> >>

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md ] > On Jul 3, 2016, at 9:52, David Sweeris via swift-evolution >

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Tue Jul 05 2016, David Waite wrote: >> On Jul 1, 2016, at 9:59 AM, Matthew Johnson via swift-evolution >> wrote: >> >>> >>> On Jun 30, 2016, at 12:26 PM, Dave Abrahams wrote: >>> >>> Q: Why not allow endIndex to have a different type from

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

Sent from my iPad > On Jul 5, 2016, at 3:32 PM, David Waite wrote: > > >>> On Jul 1, 2016, at 9:59 AM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> >>> On Jun 30, 2016, at 12:26 PM, Dave Abrahams

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

> On Jul 4, 2016, at 10:15 PM, Ben Rimmington wrote: > > > > If uses NS_EXTENSIBLE_STRING_ENUM for `domain` names > and `userInfo` keys, would a generic type (cf.

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jul 1, 2016, at 9:59 AM, Matthew Johnson via swift-evolution > wrote: > >> >> On Jun 30, 2016, at 12:26 PM, Dave Abrahams wrote: >> >> Q: Why not allow endIndex to have a different type from startIndex? >> A: It appears to offer

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Gave me a chuckle, but yeah, basically. On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley < w...@delicious-monster.com> wrote: > On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution < > swift-evolution@swift.org> wrote: > > When I see an IUO property, I consider it a sort of

Re: [swift-evolution] Class mutation model and value-constrained protocols

On Jul 5, 2016, at 10:53 AM, Dave Abrahams via swift-evolution wrote: > When T is a class type, it can easily violate *all* of these > expectations. In other words, classes naturally bypass the mutation > model. > > If we are going to maintain source stability after

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution wrote: > When I see an IUO property, I consider it a sort of “contract”–it’s basically > saying something like “I can’t set this to a valid value right now, but by > the time you use it I promise that it’s

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API "initialize(from:forwardToCount:)"

> On Jul 5, 2016, at 10:48 AM, Dave Abrahams via swift-evolution > wrote: > >> I want to call this out separately because it’s not specific to my >> proposal and changes the existing UnsafePointer API. >> >> Brent’s suggestion is to change `initialize(from:count:)`

Re: [swift-evolution] Class mutation model and value-constrained protocols

Personally, I'm fine with current state of things. Firstly, I consider classes like a compatibility feature. They slightly fall out of Swift type system. One can almost entirely avoid them, except when interacting with ObjC. (They somehow code in Haskell, right?) Secondly, when we interact with

Re: [swift-evolution] Class mutation model and value-constrained protocols

>> One idea that Jordan and I have floated is that protocols with mutating >> methods should be constrained to applying to non-class types. That >> would be a step in the right direction, but, that still leaves cases >> like gg able to easily violate expectations when the protocol in >> question

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

> On Jul 5, 2016, at 2:06 PM, Andrew Trick wrote: > >> * I don't think I understand `initialize(toContiguous:atIndex:with:)`. Does >> it return a typed pointer to the whole buffer, or just the one instance it >> initialized? Typed pointers are returned only for the memory

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Sorry, but I’m going to use your use case as an example…hope you don’t take it personally :) Basically, your use of IUOs is exactly what I’m trying to avoid. IUOs may have their uses, but in my mind, they don’t (in my mind) indicate “This argument should not be nil on most occasions, but may be

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

That’s pretty neat - although I’d inevitably forget and end up writing it with spaces between the “arguments" and the “operator”: someCollection[* … idx] But maybe even that could be made to work with some cleverness. l8r Sean > On Jul 5, 2016, at 1:45 PM, Dave Abrahams via swift-evolution

Re: [swift-evolution] Class mutation model and value-constrained protocols

Comments inline > A “mutating” keyword on a protocol method is only useful if > you can reason about the mutation in generic code. > > protocol P { > mutating func changeMe() > func noChange() -> Int > } > > In other words, given x of some type conforming to P, it should be >

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

on Sun Jul 03 2016, Nevin Brackett-Rozinsky wrote: > The incomplete range concept is quite intriguing. > > Have we considered spelling the operators with an asterisk at the > incomplete end? > prefix *..< > prefix *... > postfix ...* > postfix ..<* > > That way the

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

> On Jul 2, 2016, at 10:10 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I have a pile of naming quibbles; rather than describe them all in prose > (which turned into a mess), I've annotated parts of the "Full > UnsafeRawPointer API" section in a gist: >

[swift-evolution] Class mutation model and value-constrained protocols

A “mutating” keyword on a protocol method is only useful if you can reason about the mutation in generic code. protocol P { mutating func changeMe() func noChange() -> Int } In other words, given x of some type conforming to P, it should be meaningful that this is an error:

Re: [swift-evolution] Multiple protocols variable - automatic class-type inference

The case with testVar4 and testVar5 is not exactly a bug—the default implementation of a mutating protocol requirement can reassign 'self' even if the dynamic type turns out to be a class. (I'm not sure that's a good feature, but it is the current behavior of Swift 3.) I agree that we should

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

Sorry, my example should have been the other way around: var data: NSData! for 1...5 { data = self.loadSomeData() if data != nil { break // *this* can't be done with .forEach } /// Try again in next iteration } if data == nil {

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

> On Jul 5, 2016, at 6:37 PM, Joe Groff wrote: > >> >> On Jul 5, 2016, at 9:06 AM, Charlie Monroe via swift-evolution >> wrote: >> >> +1, but I'm not a big fan of the proposed Optional -> NSNull bridging which >> can cause various hard-to-debug

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API "initialize(from:forwardToCount:)"

on Tue Jul 05 2016, Andrew Trick wrote: >> On Jul 2, 2016, at 10:10 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> I have a pile of naming quibbles; rather than describe them all in >> prose (which turned into a mess), I've

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

> On Jul 5, 2016, at 9:06 AM, Charlie Monroe via swift-evolution > wrote: > > +1, but I'm not a big fan of the proposed Optional -> NSNull bridging which > can cause various hard-to-debug issues with errors "NSNull doesn't respond to > a selector -foo". I'm not

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API "initialize(from:forwardToCount:)"

> On Jul 5, 2016, at 11:27 AM, Xiaodi Wu wrote: > > I'm not sure about that. "Initialize backward from x, count y" is unambiguous > as to how initialization starts and iterates (the first argument), and it is > clear that `count` is an end condition dissociated from

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API "initialize(from:forwardToCount:)"

I'm not sure about that. "Initialize backward from x, count y" is unambiguous as to how initialization starts and iterates (the first argument), and it is clear that `count` is an end condition dissociated from anything to do with how initialization starts and iterates. By contrast, "Initialize

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

+1, but I'm not a big fan of the proposed Optional -> NSNull bridging which can cause various hard-to-debug issues with errors "NSNull doesn't respond to a selector -foo". Most APIs that take "id" as an argument usually specify several types that the API accepts (e.g. arrays and dictionaries),

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

`continue` can be rewritten `return` inside `forEach`. On Tue, Jul 5, 2016 at 02:30 Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote: > Example: > > for 1...5 { > guard let data = self.loadSomeData() else { > /// Will try it several times and then report failure to the user.

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API "initialize(from:forwardToCount:)"

> On Jul 5, 2016, at 11:05 AM, Xiaodi Wu wrote: > > I don't mind `initialize(from:forwardToCount:)`, but I do have trouble with > Brent's suggestion of `initialize(from:backwardFromCount:)`. It adds > ambiguity as to whether the pointer in the first argument points to the

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API "initialize(from:forwardToCount:)"

I don't mind `initialize(from:forwardToCount:)`, but I do have trouble with Brent's suggestion of `initialize(from:backwardFromCount:)`. It adds ambiguity as to whether the pointer in the first argument points to the 0th element or the (count - 1)th element from which initializing is proceeding

Re: [swift-evolution] Fix or remove Swift.min and Swift.max?

on Sun Jul 03 2016, Haravikk wrote: > There was a proposal a little while ago to change Comparable to have > an operator producing an enum (with ordered before, same and ordered > after cases) which provides strict ordering requirements (unlike the > current

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

Hello Swift community, The review of "SE-0116: Import Objective-C id as Swift Any type" begins now and runs through July 11. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md Reviews are an important part of the Swift

Re: [swift-evolution] Multiple protocols variable - automatic class-type inference

These feel like bugs in the compiler. I'd suggest filing a bug report at http://bugs.swift.org if others don't think there is more to it... > On Jul 4, 2016, at 12:47 AM, Jakub Skotnicki via swift-evolution > wrote: > > Hi, > > I would

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API "initialize(from:forwardToCount:)"

> On Jul 2, 2016, at 10:10 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I have a pile of naming quibbles; rather than describe them all in prose > (which turned into a mess), I've annotated parts of the "Full > UnsafeRawPointer API" section in a gist: >

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

on Mon Jul 04 2016, 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

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

> 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 I have not had time for a full review, but I have a question about the

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (initialize:with:)

“as” is for types :) Let’s say initialize(to:) is good and once we’ve bikeshedded all the other names we’ll see if there’s any potential for confusion… Andy > On Jul 5, 2016, at 9:20 AM, Dave Abrahams wrote: > > The use "as"? > > Sent from my moss-covered three-handled

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

Oops remove the duplicate "@" in my example. On Tue, Jul 5, 2016 at 7:27 AM Shawn Erickson wrote: > I would suggest something like the following (yeah I would URLComponents > for this but this is just an example)... basically a short hand of some > type for (a != nil ? a : b)

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

I would suggest something like the following (yeah I would URLComponents for this but this is just an example)... basically a short hand of some type for (a != nil ? a : b) to deal with optional in string construction. "http://\(self.username + "@" : "default")@

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (initialize:with:)

The use "as"? Sent from my moss-covered three-handled family gradunza > On Jul 5, 2016, at 6:48 AM, Andrew Trick wrote: > > >>> On Jul 4, 2016, at 6:19 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> So Swift 3 users have already

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

> On 5 Jul 2016, at 12:47, Charlie Monroe via swift-evolution > wrote: > > This is mentioned in Gabriel's proposal: > >> Implement a native .cases static var for all enumerations without associated >> values > > > But as has been mentioned in the discussion, this

Re: [swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

On 05.07.2016 8:39, Greg Lutz via swift-evolution wrote: Vladimir.S via swift-evolution writes: Proposal: === 1. Separate function types with parameter list and a tuple parameter. They should be two separate types. 2. Require this syntax to assign tuple

Re: [swift-evolution] Public classes with private superclass

Thanks for the link — imho it's really hard to keep an overview of this list… So, I'll follow the leader ;-) and delay further posts on this topic >> Not everything can be solved with protocols (stored properties, anyone?) > > Sure, it's not completely painless, but you can declare > >

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

Maybe a way we could opt in is by only doing this for enums with out turples? i.e enum ABTestingBrah { case A case B } I'm not sure if enums that take turples would need this functionality. *___* *James⎥Head of Trolls* *ja...@supmenow.com

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

Example: enum MediaKind { case HomeVideo, Movie, MusicVideo, TVShow var localizedName: String { ... } } let popUpButton: NSPopUpButton = ... for kind in MediaKind.allKinds { popUpButton.addItemWithTitle(kind.localizedName) } And many, many more. > On Jul 5, 2016, at

Re: [swift-evolution] [Proposal] Allow enumerating cases in enumerations

Would love a real life scenario of why you would need this. *___* *James⎥Head of Trolls* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 4 July 2016 at 02:36,

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (initialize:with:)

func initialize(_: T.Type, to: T, count: Int = 1) -> UnsafeMutablePointer I wonder why the first parameter is needed. If one is passing literals, it's always more Swift'y to use 'as'. 2016-07-05 6:00 GMT+03:00 L. Mihalkovic via swift-evolution < swift-evolution@swift.org>: > > > Regards >

Re: [swift-evolution] Public classes with private superclass

> On Jul 5, 2016, at 12:03 PM, Tino Heth <2...@gmx.de> wrote: > > >> How would this look in the exported API? Would it simply show itself as not >> inheriting from anything? If your base class inherited from something (e.g. >> NSObject), would the public subclasses show themselves as direct

  1   2   >