I'd like a core team call one way or the other.
`nonreturning`: follows rule
`noreturn`: term of art exception
-- E
On May 20, 2016, at 11:58 AM, Krystof Vasa <kvasa@icloud.com> wrote:
IMHO noreturn is fine. You are indicating "there is no return from this function", as in point of no return.
Also, this is kind of an idiom amongst many programming languages...
The core team hasn’t discussed this specifically, and doesn’t have a lot of time for extra bikeshedding meetings at the moment :-). I’d suggest putting several different options in the proposal so the community can work through it.
-Chris
On May 20, 2016, at 11:03 AM, Erica Sadun <erica@ericasadun.com> wrote:
On May 20, 2016, at 11:58 AM, Krystof Vasa <kvasa@icloud.com> wrote:
IMHO noreturn is fine. You are indicating "there is no return from this function", as in point of no return.
Also, this is kind of an idiom amongst many programming languages...
I'd like a core team call one way or the other.
`nonreturning`: follows rule
`noreturn`: term of art exception
1. Appear anywhere in the grammar appropriate for their purpose.
Actually, I'll modify this one:
1. Appear anywhere in the grammar appropriate for their purpose, but most commonly in one of the following positions:
* At the beginning of a statement.
* Between parts of a keyword-introduced statement.
* Just before the name in a declaration.
* In infix operator position.
--
Brent Royal-Gordon
Architechies
Swift Casing Rules Roadmap
This proposal addresses the first of the following Swift casing rules:
• Keywords use lower case conjoined naming.
• Attributes use lower camel cased naming.
• Attributes use “non” prefixes in preference to "no" prefixes.
• Compiler-expanded literals use lower camel casing and are prefixed with octothorpes (#)
• Swift eschews snake casing. (See also: SE-0028)
• Terms of art may be exempted from casing rules.
• Phrases sourced from outside Swift may be exempted from Swift casing rules, e.g. @UIApplicationMain.I started working on expanding this and ended up creating a general set of guidelines for naming language entities in Swift. Oops. You might want to just use the relevant subset.
* * *
Keywords:
1. Appear anywhere in the grammar appropriate for their purpose.
2. Have no prefix.
3. Use lowercaseonly naming (conjoined without underscores) and have no prefix.
4. May be any part of speech appropriate for the use, but are usually nouns, verbs, conjunctions, or prepositions, rarely adjectives or adverbs.Declaration modifiers:
1. Appear in declarations before the declaration's keyword (e.g. `let`, `func`), or before the type if there is no keyword (e.g. function parameters). Can be intermixed with attributes.
2. Have no prefix.
3. Use lowercaseonly naming (conjoined without underscores) and have no prefix.
4. Are usually adjectives.Attributes:
1. Appear in declarations before the declaration's keyword (e.g. `let`, `func`), or before the type if there is no keyword (e.g. function parameters). Can be intermixed with declaration modifiers.
2. Are prefixed with `@` symbols.
3. Use lowerCamelCase, unless prefixed to match a closely related module, in which case they use PFXUpperCamelCase.
* Prefixes like "auto" and "non" do not introduce new words.
4. Are usually adjectives or involve an adjective.
* When constructing an attribute name from a verb, use the "-ing" form (e.g. "escaping", not "escape") to turn it into an adjective.
* When negating a term, use the "non" prefix.Build configuration statements:
1. Appear where statements or declarations are valid.
2. Are prefixed with `#` symbols.
3. Use lowercaseonly naming (conjoined without underscores) and have no prefix.
* If block-scoped, they run until a matching `#end<foo>` statement.
4. May be any part of speech appropriate for the use, but are usually verbs, conjunctions, or prepositions.Compiler-expanded expressions:
1. Are prefixed with `#` symbols.
2. Use lowerCamelCase, unless prefixed to match a closely related module, in which case they use PFXUpperCamelCase.
3. Are usually nouns, but may be adjectives if they have parameters and are testing for that trait.[1]
4. Appear in expressions.As always in Swift naming, you may deviate from these rules to preserve a widely-used term of art if it is a very close match for the meaning of the entity.
[1] The adjective rule here is for #available. Should that be #isAvailable, though? That would more closely match our usual rules about Boolean expressions.
You haven’t discussed behavior accessors here, presumably because you’re not counting them (and therefore didSet and willSet) language entities. Is that correct?
It is probably worth discussing them here as well since this thread is about changing the names of what are going to be behavior accessors in the future.
On May 20, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
--
Brent Royal-Gordon
Architechies_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I may yet whip up the results of that conversation into a formal proposal,
but at the moment I'm unsure whether I myself would prefer the result over
the current sizeof().
On Fri, May 20, 2016 at 13:50 Matthew Johnson <matthew@anandabits.com> wrote:
On May 20, 2016, at 1:30 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Fri, May 20, 2016 at 1:16 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote:
> On May 20, 2016, at 12:41 PM, Chris Lattner <clattner@apple.com> wrote:
>
> On May 20, 2016, at 7:26 AM, Matthew Johnson <matthew@anandabits.com> >> wrote:
>>> (For instance, a perhaps controversial opinion: I think `dynamicType`
is properly capitalized for the syntactic slot it's in. That's not to say I
think we should *keep* `dynamicType`, but simply that `foo.dynamicType` is
more appropriate than `foo.dynamictype` would be.)
>>
>> +1. 'foo.dynamictype' seems strange to me.
>
> foo.dynamicType is broken for other reasons. I see x.dynamicType as
being a named operator (like sizeof) and not a property. For example, we
don’t want .dynamicType to show up in code completion on every value in the
universe ("4.dynamicType”, really?).
>
> That argues that it should be spelled as dynamicType(x), and ideally
being a standard library feature instead of a keyword.That makes sense. It never crossed my mind until now, but given that
`sizeof` is a standard library feature why isn’t it camel case `sizeOf`?
Is this a case of “term of the art”?See: http://thread.gmane.org/gmane.comp.lang.swift.evolution/15830/
Thanks. That’s what I figured. :)
>
> -Chris_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
If I remember correctly the property behaviors proposal it seemed that accessors such as willSet, didSet, willRead, etc. were being called. I look at them at the same level as instance methods, properties, etc. and should follow camelCase. Not to mention that I think they look so much better camelCase.
When we start having accessors made up of three or more lowercase conjoined words we are going to realize what a bad choice it was to switch these to lowercase.
I think they should stay camelCase. Please. :-)
Sent from my iPhone
On May 20, 2016, at 4:59 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
I do support Brent’s argument that keywords which syntactically appear in the same syntactic location as user-defined names should follow the same convention as those user-defined names. This means, for example, that dynamicType already has the correct case even though it is a keyword. I would like to see this exemption added to the proposal.
Also, with this in mind I would like to see more discussion about the naming convention the community prefers for user-defined behavior accessors (under the assumption that they will make it eventually). If we agree on lowercase for user-defined accessors (which is Chris’s stated preference) I support the change to willset and didset.
If I remember correctly the property behaviors proposal it seemed that accessors such as willSet, didSet, willRead, etc. were being called. I look at them at the same level as instance methods, properties, etc. and should follow camelCase. Not to mention that I think they look so much better camelCase.
When we start having accessors made up of three or more lowercase conjoined words we are going to realize what a bad choice it was to switch these to lowercase.
I think they should stay camelCase. Please. :-)
I generally agree with you. Especially because I believe sooner or later we will regret all lowercase because we find that sometimes the best accessor names are a bit too long to be comfortable with all lowercase (even 3 or 4 short words would be uncomfortable in all lowercase IMO). I would at least like to see this get more discussion before it is settled.
On May 20, 2016, at 6:18 PM, Ricardo Parada <rparada@mac.com> wrote:
Sent from my iPhone
On May 20, 2016, at 4:59 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
I do support Brent’s argument that keywords which syntactically appear in the same syntactic location as user-defined names should follow the same convention as those user-defined names. This means, for example, that dynamicType already has the correct case even though it is a keyword. I would like to see this exemption added to the proposal.
Also, with this in mind I would like to see more discussion about the naming convention the community prefers for user-defined behavior accessors (under the assumption that they will make it eventually). If we agree on lowercase for user-defined accessors (which is Chris’s stated preference) I support the change to willset and didset.
Correction. I meant lowerCamelCase not CamelCase.
Sent from my iPhone
On May 20, 2016, at 7:18 PM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:
If I remember correctly the property behaviors proposal it seemed that accessors such as willSet, didSet, willRead, etc. were being called. I look at them at the same level as instance methods, properties, etc. and should follow camelCase. Not to mention that I think they look so much better camelCase.
When we start having accessors made up of three or more lowercase conjoined words we are going to realize what a bad choice it was to switch these to lowercase.
I think they should stay camelCase. Please. :-)
Sent from my iPhone
On May 20, 2016, at 4:59 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
I do support Brent’s argument that keywords which syntactically appear in the same syntactic location as user-defined names should follow the same convention as those user-defined names. This means, for example, that dynamicType already has the correct case even though it is a keyword. I would like to see this exemption added to the proposal.
Also, with this in mind I would like to see more discussion about the naming convention the community prefers for user-defined behavior accessors (under the assumption that they will make it eventually). If we agree on lowercase for user-defined accessors (which is Chris’s stated preference) I support the change to willset and didset.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
FWIW, the entire purpose of having a review period is so that lots of people from the community can weigh in on the topic. When this comes up for review (tomorrow), please chime in on the review thread.
I have no idea how the core team as a whole feels about this.
-Chris
On May 20, 2016, at 4:18 PM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:
If I remember correctly the property behaviors proposal it seemed that accessors such as willSet, didSet, willRead, etc. were being called. I look at them at the same level as instance methods, properties, etc. and should follow camelCase. Not to mention that I think they look so much better camelCase.
When we start having accessors made up of three or more lowercase conjoined words we are going to realize what a bad choice it was to switch these to lowercase.
I think they should stay camelCase. Please. :-)