[swift-evolution] SE-0025: Scoped Access Level, next steps

[Brent Royal-Gordon]

> Why is it important to highlight word boundaries in so many other conventions in Swift but not in this one? What would be lost with this alternative?
> 
> public
> module_private
> file_private
> private
> 
> Is it just the extra (chorded, on US keyboards) keystroke? I think the readability benefits of clear word boundaries far outweigh the keystroke cost (especially with good editor auto-complete).

Swift style, deriving from Objective-C style, seems to disfavor underscores in general, except as a "formally public but informally private" marker at the beginning of an identifier. We're in the process of removing the last underscored language constructs, `@warn_unused_result` and its `mutable_variant` parameter, and replacing them with alternatives without underscores.

So if we wanted to mark a word boundary, we'd probably use camelCase. And to me, camelCase just feels wrong for keywords, particularly ones as common as access modifiers. I think it's because identifiers are camelCase too; you really want keywords to disappear into the background, but in something like this:

	modulePrivate func spinWicket() {

That `modulePrivate` looks like an identifier—maybe a return type or something—rather than a keyword.

Honestly, though, I'm not sure why people are working so hard to cram `private` in there. Does `moduleprivate` or `private(module)` really convey more information than `module`? Particularly once you've looked it up and know that it's an access modifier?

-- 
Brent Royal-Gordon
Architechies