[swift-corelibs-dev] incomplete implementation warning functions

Tony Parker anthony.parker at apple.com
Thu Jan 21 17:38:33 CST 2016


Hi Will,

> On Jan 21, 2016, at 2:27 PM, Will Stanton <willstanton1 at yahoo.com> wrote:
> 
> Hello Tony,
> 
> In my view, crashing immediately isn’t best when ‘most’ of the implementation is present. A function could work most of the time but still need some work – no need to always crash.
> Is it possible to conditionally call NSUnimplemented, in the cases where something doesn’t work? Maybe, but it might not be worth the time to write the potentially numerous checks.
> 

I think this is probably the right approach.

> Also, I would rather see messages in the console about something which might not work over nothing (i.e. a partial implementation).
> I like the current rate of review and merges, but ex. NSDateFormatter doesn’t fully implement its time/date style properties, and this appears to have led to confusion: The submitter of SR-208 https://bugs.swift.org/browse/SR-208 spent time writing up cases and investigating the Swift toolchain, when there’s a telling line in NSDateFormatter.swift saying // TODO: Set up attributes here
> A function like NSWarnIncompleteImplementation(“Date formatter attributes not set”) could have saved some time (presuming the console message was understood)!
> 
> Regards,
> Will Stanton

We’re in a somewhat tricky situation here where we want to enable incremental progress (and testability, so that prevents crashing), and yet I think it’s really important for users to understand when they’ve run across some code we haven’t implemented yet. I think in this case we should prioritize fixing the TODO and in future merges we should make sure it’s functional enough to work when merged, or crashes if you’re doing something that we haven’t yet implemented yet.

I find log messages tough to swallow in the end - I feel like there are so many that they become easy to ignore and therefore not as useful as we wanted in the first place…

- Tony

> 
>> On Jan 21, 2016, at 1:04 PM, Tony Parker via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
>> 
>> Hi Will,
>> 
>> The reason we chose fatalError() was that we felt that the safest course of action when reaching unimplemented code was to immediately crash. If we continue instead, aren’t we putting the app into an unknown state?
>> 
>> - Tony
>> 
>>> On Jan 21, 2016, at 2:55 AM, Will Stanton via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
>>> 
>>> Hello,
>>> 
>>> I would like to propose functions that warn about incomplete implementations without calling NSUnimplemented/fatalError. They could provide a standard interface for reminding/warning about incomplete implementations while things are being built.
>>> 
>>> I was thinking of two utility functions:
>>> 1) NSWarnIncompleteImplementation: Prints a warning message once. Can make potential issues clear (without flooding the console), particularly for classes where most of the implementation is there, but something could fail for certain parameters/configurations.
>>> 2) NSWarnUnimplemented: prints a warning on each call, ex. in a setter that doesn’t do anything
>>> 
>>> Something like:
>>> https://github.com/e78l/swift-corelibs-foundation/commit/f69f174ef0cfcdd32fb43912c2c88179fce07ce3
>>> 
>>> Are there are any recommendations/thoughts about incorporating these functions?
>>> 
>>> Regards,
>>> Will Stanton
> 



More information about the swift-corelibs-dev mailing list