[PATCH] D84005: Introduce ns_error_domain attribute.

[Doug Gregor via Phabricator via cfe-commits]

doug.gregor added a comment.

In D84005#2171982 <https://reviews.llvm.org/D84005#2171982>, @MForster wrote:

> @milseman, @doug.gregor, could you please help with the open questions on this review?
>
> Specifically:
>
> - Is `ns_error_domain` ever needed for something other than an enum?


No, it only makes sense on enums.

> - Why is this designed in the way it is (requiring an identifier for the domain, not allowing literals and then only using the name of the identifier from Swift)?

It's codifying the design of NSError, which has been this way since... longer than Clang has existed, and is independent of Swift. NSErrors have a domain (identified by an NSString constant symbol, not a literal, for pointer uniqueness and code size)  and a code (an integer, conventionally defined by an enum). The two need to be used together, e.g., you create an NSError with a domain and a code from that domain. This attribute finally ties those things together at the source level.

This is leads to the answer to Aaron's question:

> Are there plans to use this attribute in Clang itself?

It would absolutely make sense to add some warnings if you've mismatched your domain and code when constructing an NSError (e.g., uses of https://developer.apple.com/documentation/foundation/nserror/1522782-errorwithdomain?language=objc) or even if when testing an error in an "if" statement (if checking both domain and code, make sure the code enumerator is from the same domain). I bet you'd catch some fiddly error-handling bugs this way.

> - Is it ok to make this attribute inheritable?

Sure.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84005/new/

https://reviews.llvm.org/D84005