For my subjective opinion and personal project of supporting clang-format, the spacing could be this:
id<Foo> @interface WebSpeechRecognizerTaskImpl : NSObject<SFSpeechRecognitionTaskDelegate, SFSpeechRecognizerDelegate> On the grounds of: 1) No space for type declaration on the grounds that formatting the code would not need objective-c semantic analysis to work and it’s similar to other spacing rules related to angle brackets. 2) No space for the interface definition on the grounds that there’s no space for type declaration, so the rule “no space” is easier to remember. So the categories of arguments would be roughly practicality, consistency and simplicity, evaluated very subjectively. > Or would the spacing help you understand that Baz is a protocol but Bar is > supplied as a generic type? For me subjectively semantic spacing in form id <Foo> signifying “Foo is definitively protocol” would not improve readability. E.g. even if semantic spacing was reliable, I doubt I’d get much readability for knowing Baz is a protocol. Discussing semantic spacing merits vs semantic spacing is reliability: If I understand correctly, being able to rely on spacing you would read the latter part unambiguously: Foo<Bar <Baz> *> * — Foo is a C++ template or Obj-C generic, Bar is a Obj-C class that conforms to Baz Where as not having semantic spacing notation you would this declaration and this interpretation: Foo<Bar<Baz>*>* — Foo is a C++ template or Obj-C generic, Bar is a Obj-C class that conforms to Baz or a C++ template E.g. semantic spacing is more unambiguous at the surface level, where as simpler spacing rule (“generally don’t put spaces near angle brackets or * or &") is more ambiguous. However, unless the spacing is enforced programmatically, you cannot rely on semantic spacing. It tends to go wrong, as it has in WebKit currently. Currently and for the foreseeable future, we don’t have programmatic formatting that has exact semantic awareness of the languages being formatted. This means regardless of the style rules, you anyway have to resolve the ambiguity by knowing what Foo,Bar,Baz are, as you cannot trust that the code in question conforms to style. To me this would say that semantic spacing is not a strong readability argument. Assuming semantic spacing is not reliable and thus not a readability argument: Contrasting cases: Vector<id<Protocol>> Vector<List<MyType>> I’m not sure there is readability argument that would support "space for protocols" and “no space for c++ templates” simultaneously. > Would the inconsistent spacing annoying you? Only if there is style guide saying rules about it and review comments are enforcing it inconsistently. This is related to other aspect of Obj-C spacing rules, which I opened a discussion end of last year and hope to get back closing it.. (Reminder to somebody objecting to obj-c parts to comment on that) Br, Kimmo > On 21. Feb 2022, at 23.19, Myles Maxfield via webkit-dev > <webkit-dev@lists.webkit.org> wrote: > > Hello! > > I was working on a patch recently where I wanted to give an Objective-C > variable a type of “id that conforms to protocol Foo.” > > Should this be spelled like this: > > id <Foo> myVariable > > Or like this: > > id<Foo> myVariable > > I don’t see anything about this in the WebKit style guide > <https://webkit.org/code-style-guidelines/>. > > The former appears in WebCore, WebKit, and WebKitLegacy 1035 times, whereas > the latter appears only 281 times. On the other hand, Apple’s documentation > <https://developer.apple.com/documentation/metal/1433401-mtlcreatesystemdefaultdevice?language=objc> > seems to prefer the latter. > > Another consideration - This question is only about Objective-C protocols, > not Objective-C generics. We already have a longstanding practice of spelling > generics without the space, e.g. NSArray<NSString *> *. So, we could either > intentionally choose for protocols to look visually similar to generics, or > alternatively we could intentionally choose for protocols to look visually > distinct to generics. Consider seeing something like Foo<Bar <Baz> *> *. > Would the inconsistent spacing annoying you? Or would the spacing help you > understand that Baz is a protocol but Bar is supplied as a generic type? > Maybe the * characters already make that clear? > > What should the style guide say here? > > Thanks, > Myles > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
