> On Nov 7, 2026, at 6:35 PM, Ryosuke Niwa via webkit-dev > <[email protected]> wrote: > >> On Nov 7, 2026, at 18:20, Mike Wyrzykowski <[email protected]> wrote: >> >> 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. > > Right, these things need to be discussed on webkit-dev. It seems really > premature to impose style checks on Swift when most of us haven't even > written a single line of Swift. > > If the future of WebKit codebase is to be written in Swift, then the coding > style of Swift needs to be something every WebKit contributor agrees to.
I asked Claude which rules in https://webkit.org/code-style-guidelines/ would conflict with idiomatic Swift. Here’s what Claude came up with: Setters start with set, getters are bare words, members use m_. Swift uses stored and computed properties (view.frame = …), not setFrame()/frame() pairs, and doesn't prefix members. Prefer enums over bools for parameters. Swift's argument labels (reload(animated: true)) already make call sites readable. Enums still help sometimes, but the reason for the rule mostly goes away. Out arguments passed by reference, getters with out arguments prefixed get. Idiomatic Swift returns tuples or optionals instead. inout exists but is rarely used for this. A space between if/for and the parentheses. Swift usually drops the parentheses entirely (if x {). One-line control clauses without braces, and if (!ptr) null tests. These can't be written in Swift: braces are required, and optionals aren't implicitly boolean, so you write if let, guard let or != nil. These changes for Swift seem reasonable although we should probably have a separate discussion for each. For those who are opposing to adopt the existing style guidelines, what are rules that are in conflict with writing idiomatic Swift in your view? - R. Niwa
_______________________________________________ webkit-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
