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]
