To give a concrete example, I encountered hundreds of style warnings with every
Swift PR last year with each PR. For example:
Writing:
private var rootJointIndicesCache: [String:[UInt32]] = [:]
results in the very non-descriptive style warning:
Source/WebKit/GPUProcess/graphics/Model/USDModel.swift:2327: error:
[Spacing] add 1 space
as a new-to-Swift engineer, I had no idea where to add the space. Furthermore,
writing the code like:
private var rootJointIndicesCache: [String:[UInt32]]=[:]
results in three style warnings:
Source/WebKit/GPUProcess/graphics/Model/USDModel.swift:2327: error:
[Spacing] add 1 space
Source/WebKit/GPUProcess/graphics/Model/USDModel.swift:2327: error:
[Spacing] add 1 space
Source/WebKit/GPUProcess/graphics/Model/USDModel.swift:2327: error:
[Spacing] add 1 space
It is trivial to fix via:
swift format --in-place
"Source/WebKit/GPUProcess/graphics/Model/USDModel.swift"
but writing style-correct code initially was basically impractical even after
several months.
If we removed some of the more pedantic rules it would probably go a long way.
Or alternatively, made the style warnings descriptive which they are not today.
There are some other examples which the style checker does not flag but were
frequently flagged during PR review, example:
guard !missingPrimNames.contains(name) else {
whereas a WebKit engineer might write it like:
if missingPrimNames.contains(name) {
and I would argue the latter is more readable despite not being canonical Swift
style.
Another example is flagging every single force unwrap which is effectively
impractical with C++ / Swift mixed code.
Searching for `swift-format-ignore:` yields nearly 400 results in my WebKit
sources.
If we need to ignore so many style warnings today, it is an indication they are
too pedantic.
-Mike
> On Nov 7, 2026, at 1:45 PM, Ryosuke Niwa via webkit-dev
> <[email protected]> wrote:
>
>>
>> On Nov 7, 2026, at 20:25, Maciej Stachowiak <[email protected]> wrote:
>>
>>> On Nov 7, 2026, at 4:36 AM, Ryosuke Niwa via webkit-dev
>>> <[email protected]> wrote:
>>>
>>>
>>>> On Nov 6, 2026, at 00:05, 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.
>>>
>>> Right, but nothing in our coding style guideline says about semicolon so
>>> that's consistent with the proposal to use the same coding style guideline.
>>
>> To the best of my understanding of the JSON style rules that Richard linked,
>> quite a few of the rules there are not covered at all in the C++ guidelines
>> and logically would not be because they pertain to Swift constructs that
>> aren’t in C++.
>>
>> Since it;s hard to compare prose rules with rules implemented in code, maybe
>> we could look at some real Swift code linted (and/or hand written) to follow
>> the de facto Swift style rules.
>
> Right, it's probably useful to talk about concrete style differences.
>
>> What if any deviations do you see from WebKit’s coding style for C++? The
>> only difference that standards out to be is the opening curly brace for
>> functions being on the same line as the declaration instead of its own line.
>> But that seems to genuinely pervasive Swift convention, and everything else
>> about the function declaration syntax is different too, so it doesn’t seem
>> like a huge win to go separate brace.
>
> I don't think we should be changing the style just because other Swift code
> places { on the same line as the declaration. Plenty of C/C++ codebase does
> that too but we have our own style.
>
>> https://github.com/WebKit/WebKit/blob/main/Source/WebKit/UIProcess/WebBackForwardList.swift
>>
>> Here’s some code that may have been written without the guidelines as
>> closely in mind. It looks basically the same except that function
>> declarations with multiple parameters are written with a line per parameter.
>
> I don't think we should put each argument on its own line. I find this style
> extremely verbose. Blink code often does that and makes the code much harder
> to follow.
>
> I'm really not interested in re-litigating all these syntactical approaches.
> These things have been discussed in webkit-dev over the years. If we're
> changing our coding guideline, then it should be applied to both C++ and
> Swift where applicable and should be a discussion of its own.
>
> If we're serious about adopting Swift in more parts of WebKit, then its
> coding guideline should be something we all agree upon, not something a
> person who wrote Swift code before others dictate.
>
> - R. Niwa
> _______________________________________________
> webkit-dev mailing list -- [email protected]
> <mailto:[email protected]>
> To unsubscribe send an email to [email protected]
> <mailto:[email protected]>
_______________________________________________
webkit-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
