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
I agree that camel-case is more readable than all-lowercase, although the only all-lowercase names currently are '#dsohandle' (very rarely used) and '#elseif' / '#endif'. I also have a knee-jerk reaction against '#endIf'; somehow '#EndIf' doesn't seem quite as bad to me.
I can see the argument for naming the expression-like directives like values. I'm not sure whether it's necessary that the non-expression-like directives follow the same naming convention. Something to explore.
Jordan
···
On Feb 25, 2016, at 11:06, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:
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
Exceptions from guidelines probably can happen, given an argumentation. In
attributes, @NS- and @IB- things for compatibility with Objective-C. Here, #elseif for analogy with "else if" in usual Swift. #elseIf also feels odd
to me.
Can #end be a better name for #endif?
Anyway, I think I won't create a proposal draft until the proposals
containing mentioned directives get accepted.
Camel-case, mild preference for lower since keywords are lower
···
On Friday, 26 February 2016, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote:
I agree that camel-case is more readable than all-lowercase, although the
only all-lowercase names currently are '#dsohandle' (very rarely used) and
'#elseif' / '#endif'. I also have a knee-jerk reaction against '#endIf';
somehow '#EndIf' doesn't seem quite as bad to me.
I can see the argument for naming the expression-like directives like
values. I'm not sure whether it's necessary that the non-expression-like
directives follow the same naming convention. Something to explore.
Jordan
> On Feb 25, 2016, at 11:06, Антон Жилин via swift-evolution < > swift-evolution@swift.org <javascript:;>> wrote:
>
> 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.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
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
···
Le 25 févr. 2016 à 14:06, Антон Жилин via swift-evolution <swift-evolution@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
Well... I think that there is nothing wrong with the current directives
*and* attribute names being lowercase (with some exceptions for attributes
when relating to Objective-C/Cocoa support).
One of the things I dislike in Java is the @Override. First the `override`
should no be an attribute, but since it is, `@override` would be much more
pleasant.
The same goes for directives that is what is being discussed here. I vote
for lowercase.
-Van
···
On Thu, Feb 25, 2016 at 5:31 PM, Антон Жилин <swift-evolution@swift.org> wrote:
Exceptions from guidelines probably can happen, given an argumentation. In
attributes, @NS- and @IB- things for compatibility with Objective-C. Here, #elseif for analogy with "else if" in usual Swift. #elseIf also feels odd
to me.
Can #end be a better name for #endif?
Anyway, I think I won't create a proposal draft until the proposals
containing mentioned directives get accepted.