I think it would also be helpful to frame it the other way. Apparently most of our Swift code is already in some sort of Swift style (even that was for got-here-first reasons), so it’s the “like C++ style” that would call for a change to existing code.
- Maciej > 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]
