You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Why should this rule be added? Share links to existing discussion about what
the community thinks about this.
It's common to add unimplemented methods just to fill protocol/init requirements. For example, if you don't use Interface Builder and create an UIView subclass overriding init, you'll be asked to implement init?(coder:). Xcode suggests a fix-it that adds an implementation with a fatalError .
In addition to the fatalError, one can also mark the method with @available(*, unavailable) to avoid someone from calling directly. It's just an extra safety net.
I'm not sure if we should trigger a warning for every method that only contains a fatalError inside or only the ones with the default template. Also not sure about protocols/overrides.
Provide several examples of what would and wouldn't trigger violations.
// would trigger
publicrequiredinit?(coder aDecoder:NSCoder){fatalError("init(coder:) has not been implemented")}
// wouldn't trigger
@available(*, unavailable)publicrequiredinit?(coder aDecoder:NSCoder){fatalError("init(coder:) has not been implemented")}
Should the rule be configurable, if so what parameters should be configurable?
No.
Should the rule be opt-in or enabled by default? Why?
See README.md for guidelines on when to mark a
rule as opt-in.
Probably opt-in.
The text was updated successfully, but these errors were encountered:
marcelofabri
changed the title
Rule request: add unavailable to implemented function
Rule request: add unavailable to unimplemented function
Apr 6, 2018
New Issue Checklist
Rule Request
the community thinks about this.
It's common to add unimplemented methods just to fill protocol/init requirements. For example, if you don't use Interface Builder and create an
UIView
subclass overriding init, you'll be asked to implementinit?(coder:)
. Xcode suggests a fix-it that adds an implementation with afatalError
.In addition to the
fatalError
, one can also mark the method with@available(*, unavailable)
to avoid someone from calling directly. It's just an extra safety net.I'm not sure if we should trigger a warning for every method that only contains a
fatalError
inside or only the ones with the default template. Also not sure about protocols/overrides.No.
See README.md for guidelines on when to mark a
rule as opt-in.
Probably opt-in.
The text was updated successfully, but these errors were encountered: