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

[Mark Lacey]

> On Jun 10, 2016, at 2:32 PM, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> 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).

You might be thinking of Builtin.unreachable(). I recently replaced the bodies of all the stdlib functions that are completely unavailable with calls to Builtin.unreachable(), which generates a trap instruction (as opposed to having bodies with calls to fatalError that take static strings, which generate more code/data).

> 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.

Personally I think it would be nice if you could omit the body of any function (through some special syntax) with the intent that you’d get a warning for these when compiling and that they would trap if ever called. It can be handy to be able to do that while prototyping, e.g. as you’re trying to figure out the design of the types you want to implement, etc. I don’t consider this critical though, as it’s usually not too hard to write a placeholder body that constructs and returns some kind of dummy return value.

Mark

> 
> On 10 June 2016 at 18:26, Erica Sadun via swift-evolution
> <swift-evolution at swift.org> wrote:
>> On Jun 10, 2016, at 3:22 PM, Austin Zheng via swift-evolution
>> <swift-evolution at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution