I don’t have opinions on Swift formatting specifically, but I suggest that this is an opportunity to have all Swift code follow a standard format by running it through `swift format` (with some agreed-upon formatting rules) before commit. You can use whatever style you like while editing, but at commit time formatting would be standardized.
Simon > On Nov 7, 2026, at 9:00 PM, Ryosuke Niwa via webkit-dev > <[email protected]> wrote: > > >> 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]
_______________________________________________ webkit-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
