The JSON definition of the Swift style is hard to compare to the prose explanation of the C++ style. A lot of it is setting somewhat mysterious flags to “true”.
- Maciej > On Nov 6, 2026, at 12:41 PM, Richard (WebKit) Robinson via webkit-dev > <[email protected]> wrote: > > Most of the C++ style <https://webkit.org/code-style-guidelines/> and Swift > style <https://github.com/WebKit/WebKit/blob/main/.swift-format> are specific > to their language and don't share too much in common. The types of style > rules they do both have are things like line length, indentation count, > maximum blank lines between functions, spacing between symbols, etc. Most of > those are all already consistent, except for line length. I set line length > for Swift to 140 because that seemed reasonable to me since super long lines > are unreadable in my opinion, but I agree there is indeed no reason that > should be Swift specific, and can be changed to be consistent. > >> On Nov 5, 2026, at 4:04 PM, Geoff Garen via webkit-dev >> <[email protected]> wrote: >> >> I think this debate would be easier to resolve if it moved from abstractions >> like “C++ style” and “Swift style” to specific style rules. >> >> Would someone who prefers “Swift style” be willing to list some specific >> deviations from WebKit’s C++ style guidelines, why they prefer those >> deviations, and why that preference should outweigh concerns about >> consistency? >> >> One deviation I heard was “no un-required semicolons”. First, I agree with >> that proposal. Second, as stated it may not technically be a deviation from >> WebKit’s C++ style guidelines — C++ just happens to require semicolons in >> more places. >> >>> We already use the `swift-format` tool for all WebKit Swift code using a >>> style I came up with several years ago >> >> I don’t think “I got here first” should settle this debate. We want to >> welcome in others who get here later. >> >> Thanks, >> Geoff >> >>> On Nov 5, 2026, at 12:42 PM, Ryosuke Niwa via webkit-dev >>> <[email protected]> wrote: >>> >>> For Python, we seem to just use PEP. I would have objected to adopting that >>> if I still worked a lot on Python. I'm fine with Objective-C having its own >>> style because it's a language I rarely ever have to touch myself. >>> >>> Generally speaking, Python and Objective-C coding styles only affects a >>> subset of engineers some of the times. With Swift, we're talking about >>> rewriting the entire engine in it. The level of scrutiny it requires is at >>> a completely different level. >>> >>> - R. Niwa >>> >>>> On Nov 5, 2026, at 19:14, Aditya Keerthi <[email protected]> wrote: >>>> >>>> >>>> I strongly disagree with the idea that we should simply adopt the existing >>>> C++ style guide with the one modification Ryosuke stated. I agree with >>>> Abrar’s sentiment that there could be project-specific tweaks to the >>>> conventional Swift style. >>>> >>>> In Swift, semicolons are optional and conventionally omitted. I do not >>>> think we should start adding semicolons to our Swift code just to match >>>> C++ style. >>>> >>>> However, for things such as line length limit, I would be more inclined to >>>> keep the same rules as our C++ source files. >>>> >>>> I believe that we should work towards defining a Swift-specific style >>>> guide, and document it in https://webkit.org/code-style-guidelines/ along >>>> with our existing C++ and Python style guides. >>>> >>>> I’d also like to note that we already have language-specific styles. The >>>> largest difference is between our Python and C++ style guides. >>>> Furthermore, we have Objective-C-specific style rules. For example, in >>>> Objective-C, instance variables are prefixed with “_”; in C++, we use >>>> “m_”. It is not at all unprecedented to need to change styles when working >>>> with different languages across the WebKit project. >>>> >>>> - Aditya >>>> >>>>> On Nov 5, 2026, at 9:07 AM, Mike Wyrzykowski via webkit-dev >>>>> <[email protected]> wrote: >>>>> >>>>> I strongly agree with Ryosuke, it is best to maintain a consistent style >>>>> throughout the codebase. >>>>> >>>>> Swift is a relatively new language still undergoing rapid development, it >>>>> is hard to argue there is a canonical Swift style that will not change in >>>>> the future. 20 years ago many ‘modern’ C++ coding guidelines were pushing >>>>> styles that ultimately fell out of use for one reason or the other. >>>>> >>>>> Changing style as Swift continues to develop / introduce new guidelines >>>>> will lead to style fragmentation across the codebase in addition to >>>>> fragmentation from the rest of the codebase. >>>>> >>>>> It is better to follow WebKit’s existing coding style. Style is language >>>>> agnostic: one can make C++ look like Haskell, JavaScript can be written >>>>> both C-like and functional-like, etc. Remembering to use a certain style >>>>> for Swift and another style for C++ seems to make less sense than >>>>> consistently following a single style. >>>>> >>>>>> On Nov 4, 2026, at 1:41 PM, Eric Carlson via webkit-dev >>>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Nov 4, 2026, at 10:29 AM, Ryosuke Niwa via webkit-dev >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> On Nov 4, 2026, at 6:04 PM, Abrar Protyasha <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> I want WebKit to adopt suggested/conventional Swift style, maybe with >>>>>>>> some well-reasoned (and agreed on) project-specific tweaks. I don’t >>>>>>>> know if there is added value in having source files of two different >>>>>>>> languages follow one style? Swift is vaguely C-lang styled, but >>>>>>>> otherwise it’s a very different programming language and we don’t >>>>>>>> necessarily need it to look the same as C++. >>>>>>> >>>>>>> Consistency is important. Otherwise we’d have to constantly change the >>>>>>> style between when we’re writing C++ vs. Swift. >>>>>>> >>>>>>>> There may be specific issues with the existing Swift style format >>>>>>>> enforced in the project that we may want to debate, but for the most >>>>>>>> part it seems best to just use as much of the defaults opined by >>>>>>>> swift-format. >>>>>>> >>>>>>> I strongly disagree. >>>>>>> >>>>>>> >>>>>> >>>>>> +1 >>>>>> >>>>>> -eric >>>>>> >>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> webkit-dev mailing list -- [email protected] >>>>>>> To unsubscribe send an email to [email protected] >>>>>> _______________________________________________ >>>>>> webkit-dev mailing list -- [email protected] >>>>>> To unsubscribe send an email to [email protected] >>>>> >>>>> _______________________________________________ >>>>> webkit-dev mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>> >>> _______________________________________________ >>> webkit-dev mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> webkit-dev mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > webkit-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ webkit-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
