Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 10, 2016, at 5:47 PM, John McCall via swift-evolution > wrote: > >> On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution >> wrote: >> >> Hello swift-evolutioneers, >> >> Here's an idea. It's technically additive, but

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 12, 2016, at 9:08 PM, Charlie Monroe wrote: >> On Jun 11, 2016, at 3:51 AM, Andrew Bennett via swift-evolution >> > wrote: >> >> Unavailable doesn't mean un-callable. >> If you're marking an

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

As Andrew says - I have several cases where I mark a method on a subclass as unavailable to ensure subclasses do not call it directly, but it is required by the root class to be implemented (which it is and gets called). Example: class Root { func doSomething() {

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

All I want, and all @available(*, unavailable, renamed:) gives me, is the ability to give my users a more pleasant upgrade experience than simply working through whatever errors Xcode spits out and trying to figure out what old APIs correspond with what new APIs. If resilience is an issue...a

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

Unavailable doesn't mean un-callable. - If you're marking an override or required initialiser as unavailable, it's still possible it's called dynamically, or by super. - If you're marking it unavailable for some OS versions, it could still be called by the other OS versions. - If

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolutioneers, > > Here's an idea. It's technically additive, but it's small and I think it fits > in well with Swift 3's goals, one of which is to establish API conventions. >

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> However, you can (and still need to) provide an implementation (e.g. function > body). You can just stick a fatalError() inside and be done with it, but my > question is, is an impl even necessary? Personally, I always figured the best thing to do was to call through to the new API. We don't

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 10, 2016, at 2:32 PM, Leonardo Pessoa via swift-evolution > wrote: > > I've seen around the Swift source code some uses of a function named > something like NSUnimplemented(). I'm not sure this is available only > inside the Swift source or if we could call

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

NSUnimplemented() has nothing to do with the Swift compiler proper, and you won't find it in the Swift repo. It's a marker used for the Swift Foundation project to denote methods and APIs that haven't yet been implemented. It has nothing to do with availability/renamed. As for the overhead, I

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

I've seen around the Swift source code some uses of a function named something like NSUnimplemented(). I'm not sure this is available only inside the Swift source or if we could call it as well (I'm not in front of a Swift compiler right now so I cannot test). The idea of being able to drop the

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

Sorry, but I'm going to have to disagree with you on this one. On Fri, Jun 10, 2016 at 2:26 PM, Erica Sadun wrote: > On Jun 10, 2016, at 3:22 PM, Austin Zheng via swift-evolution < > swift-evolution@swift.org> wrote: > > So, instead of: > > @available(*, unavailable,

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 10, 2016, at 3:22 PM, Austin Zheng via swift-evolution > wrote: > > So, instead of: > > @available(*, unavailable, renamed:"someNewAPI()") > public func someOldAPI() -> Int { fatalError() } > > You can just have: > > @available(*, unavailable,

[swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

Hello swift-evolutioneers, Here's an idea. It's technically additive, but it's small and I think it fits in well with Swift 3's goals, one of which is to establish API conventions. Right now, you can declare a function, type member, etc and mark it using "@available(*, unavailable,