> On Jun 10, 2016, at 2:32 PM, Leonardo Pessoa via swift-evolution
> <swift-evolution@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@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
