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 don't understand this argument either. Today, the compiler already has to cross-check the use of an API against a list of whether or not it's been blacklisted using "unavailable". If it's "unavailable" the compiler stops with an error and does not need to further check whether a function body has been defined. As for the grammar, there are already productions defined for member declarations without implementations, used for constructing protocols. Austin On Fri, Jun 10, 2016 at 2:32 PM, Leonardo Pessoa <m...@lmpessoa.com> 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 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 body of the function is interesting > but I keep thinking of the overhead of the compiler to check for every > function if it can drop the requirement for a body. Perhaps keeping > the body is well suited here. > > On 10 June 2016 at 18:26, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote: > > On Jun 10, 2016, at 3:22 PM, Austin Zheng via swift-evolution > > <swift-evolution@swift.org> wrote: > > > > So, instead of: > > > > @available(*, unavailable, renamed:"someNewAPI()") > > public func someOldAPI() -> Int { fatalError() } > > > > You can just have: > > > > @available(*, unavailable, renamed:"someNewAPI()") > > public func someOldAPI() -> Int > > > > The intent is, in my opinion, clearer for the latter and it feels less > > kludgy. > > > > > > You ask, we answer. I'd much prefer spelling out { > fatalError("unavailable > > API") }. > > It makes the code clearer to read, to maintain, it produces debug and > > runtime errors. etc. I think > > this is an example where concision is overrated. > > > > -- E > > > > > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution