[swift-evolution] [Discussion] Naming directives

[Dany St-Amant]

> Le 25 févr. 2016 à 14:06, Антон Жилин via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> Currently, Swift follows all-lower convention for #-directives. We haven't discussed it much, but just derived it from a few existing directives we have.
> Now people invent new directives: #setline, #fileliteral. Now it becomes obvious that lowercase just breaks down for anything long enough. CamelCase is much more clear (read distinguishable) than thatlowercasemess. Compare:
> 
> #colorliteral   vs   #colorLiteral
> #imageliteral   vs   #imageLiteral
> #setline   vs   #setLine
> 
> Directives read like functions:
> 
> #fileLiteral(resourceName: "name")
> #setLine(1)
> #available(iOS 8.0, *)
> 
> One may say that their arguments aren't really Swift values and objects, but that's why they are directives, after all.
> 
> #if stands out a bit, but the change will not affect it.


For the #-directive, like for the @-attribute, I see them a language keyWords which I believe to be better in all lowerCase; maybe I’m just lazy and hate typing upperCases letters on my keyBoard. But mainly, I think these upperCase letter in the middle of what I see as a single "common" word get distracting (its worst for the shorter one like setline). I know that Swift aims for one golden case rule to rule them all, but I do think that API/library words versus compiler words could differ a bit on that regards.

Neither of these colorliteral, imageliteral, setline are any harder to read that some of the few german composed words I remember from way back when I try to learn it: Krakenschwester, Tageslichtprojektor. 

In the end, it is just about how you read it and visualize it. I see #colorliteral and #imageliteral as two distincts entities (a colour thingie and image thingie), not two variant of single #literal concept which can contains either a colour or an image.

Dany