Re: [swift-evolution] RFC: didset and willset

[Matthew Johnson via swift-evolution]

> On May 20, 2016, at 6:18 PM, Ricardo Parada  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. :-)

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.

> 
> Sent from my iPhone
> 
>> On May 20, 2016, at 4:59 PM, Matthew Johnson via swift-evolution 
>>  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

Re: [swift-evolution] RFC: didset and willset

[Ricardo Parada via swift-evolution]

If accessors are defined by the developer who designs a property behavior then 
I do not see them as keywords. Or am I wrong?

That is why I would prefer them lowerCamelCase. 


On May 20, 2016, at 1:50 PM, Chris Lattner via swift-evolution 
 wrote:

>> Thus, `willSet` and `didSet` should be capitalized like other, user-defined, 
>> accessors.
> 
> I agree with your believe that we should treat these just like user-defined 
> accessors.  So lets assume we had an “observed” behavior that had 
> didset/willset aspects that can be specified.  To the implementor of the 
> behavior, these are terms that they define, but to users of the behavior, 
> they are indistinguishable from keywords.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Ricardo Parada via swift-evolution]

Correction. I meant lowerCamelCase not CamelCase. 

Sent from my iPhone

> On May 20, 2016, at 7:18 PM, Ricardo Parada via swift-evolution 
>  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 
>>  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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Ricardo Parada via 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 
>  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

Re: [swift-evolution] RFC: didset and willset

[Matthew Johnson via swift-evolution]

> On May 20, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> 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` 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.

> 
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Brent Royal-Gordon via swift-evolution]

> 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-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Brent Royal-Gordon via swift-evolution]

> 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` 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.


-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Erica Sadun via swift-evolution]

> On May 20, 2016, at 11:41 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> On May 20, 2016, at 7:26 AM, Matthew Johnson  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.
> 
> -Chris

Gist: https://gist.github.com/erica/b0155e2f6d96c3d530fdafa9b3bd6272 


Moving dynamicType to the standard library

Proposal: TBD
Author: Erica Sadun 
Status: TBD
Review manager: TBD
 
Introduction

This proposal establishes dynamicType as a named operator rather than a 
property and moves it to the standard library.

 
Motivation

In Swift, dynamicType is a property. Because of that, it shows up in code 
completion as an "appropriate" completion for all values, regardless of whether 
it makes sense to do so or not. For example, Swift offers 4.dynamicType, 
myFunction().dynamicType, etc. Rather than express a logical attribute of a 
specific type, it can be applied to any expression. Since dynamicType behaves 
more like a operator (like sizeof), its implementation should follow suit.

Moving it to the standard library, allows Swift to remove a keyword and better 
aligns the functionality with its intended use.

 
Detailed
 Design

Upon adoption of this proposal, Swift removes the dynamicType keyword and 
introduces a dynamicType function:

dynamicType(value) // returns the dynamicType of value
 
Impact
 on Existing Code

Adopting this proposal will break code and require migration support, moving 
the postfix property syntax into a prefix function call.

 
Alternatives
 Considered

Not adopting this proposal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Erica Sadun via swift-evolution]

> On May 20, 2016, at 11:52 AM, Chris Lattner <clatt...@apple.com> wrote:
> On May 20, 2016, at 10:48 AM, Erica Sadun <er...@ericasadun.com> wrote:
>> On May 20, 2016, at 11:43 AM, Chris Lattner <clatt...@apple.com> wrote:
>>> On May 20, 2016, at 10:41 AM, Erica Sadun <er...@ericasadun.com> wrote:
>>>> Right, but the catfight had a clear outcome:
>>>>>>> 1) keywords are conjoined
>>>>>>> 2) attributes are lower camel cased.
>>>>>>> 3) attributes should use “non” not “no”.  noescape should be 
>>>>>>> nonescaping (and thus no camel bump).
>>>>>> Would you be in favor of a proposal that cleans all of this up at once 
>>>>>> and establishes this standard for all new features?  I don't mind the 
>>>>>> change and think consistency is a good idea, I just think it doesn't 
>>>>>> make sense to keep doing these as one-off changes.
>>>>> I’d prefer one proposal to cover didset/willset and one to cover 
>>>>> nonescaping (and any other nofoo attributes left).They will raise 
>>>>> different sorts of discussion, even though they both seem obvious to me.
>>>> Before putting together a proposal, are there any other de-facto rules 
>>>> besides the three already listed that touch on naming keywords and 
>>>> attributes? (I suppose no snake case is a given)
>>> I think that these are the relevant rules.  As I mentioned upthread, 
>>> .dynamicType is broken for a different reason, and thus leads to a 
>>> different solution (it should be a global function in the stdlib, not a 
>>> propery).
>>> 
>>> -Chris
>> Separate action items:
>> 
>> * Move dynamicType to standard library as a global function
>> * Rename didSet and willSet to lowercase to conform to Swift standard of 
>> conjoined lowercase keywords.
>> * Rename noescape to nonescaping to conform to Swift standard of 
>> "non"-modified attributes
> 
> Sounds great.

Part 2: https://gist.github.com/erica/f31d580d7dcca3c416181a2973a185d5 
<https://gist.github.com/erica/f31d580d7dcca3c416181a2973a185d5>

Gist pasted below

Normalizing naming for "negative" attributes

Proposal: TBD
Author: Erica Sadun <https://github.com/erica>
Status: TBD
Review manager: TBD
 
<https://gist.github.com/erica/f31d580d7dcca3c416181a2973a185d5#introduction>Introduction

This proposal normalizes naming for "negative" attributes by adopting a rule 
that replaces camel-cased property names starting with no with adjectives 
starting with non. 

Swift-evolution thread: RFC: didset and willset 
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534>
 
<https://gist.github.com/erica/f31d580d7dcca3c416181a2973a185d5#motivation>Motivation

Some Swift-sourced attributes including available and testable are both 
adjectives. Converting no-prefixed attributes to non changes them into a single 
word that describes how they modify the syntax they decorate.

 
<https://gist.github.com/erica/f31d580d7dcca3c416181a2973a185d5#swift-casing-rules-roadmap>Swift
 Casing Rules Roadmap

This proposal addresses the third 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 
<https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md>)
Terms of art may be exempted from casing rules.
Phrases sourced from outside Swift may be exempted from Swift casing rules, 
e.g. @UIApplicationMain.
Keywords that appear in the same syntactic locations as user-defined names 
should follow the convention of those user-defined names.
 
<https://gist.github.com/erica/f31d580d7dcca3c416181a2973a185d5#swift-language-cleanup-roadmap>Swift
 Language Cleanup Roadmap

This proposal is part of a series that will:

Normalize casing to lower conjoined names.
Normalize naming for "negative" attributes (from "noFeature" to "nonfeaturing").
Move dynamicType to the standard library as a global function.
 
<https://gist.github.com/erica/f31d580d7dcca3c416181a2973a185d5#detailed-design>Detailed
 Design

Upon adoption, Swift will rename:

noreturn to nonreturning
noescape to nonescaping
 
<https://gist.github.com/erica/f31d580d7dcca3c416181a2973a185d5#impact-on-existing-code>Impact
 on Existing Code

This proposal requires migration support to rename keywords that use the old 
convention to adopt the new convention. This is a simple substitution that 
should limit effect on code.

 
<https://gist.github.com/erica/f31d580d7dcca3c416181a2973a185d5#alternatives-considered>Alternatives
 Considered

The core team may consider exceptions for terms of art. For example, "no 
return" indicates "there is no return from this function", as in the "point of 
no return".

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Brent Royal-Gordon via swift-evolution]

> Upon adoption, Swift will rename didSet and willSet to willset and didset. 
> Future expansions to the language will follow this adopted rule, for example 
> didchange.

Might want to switch the order of the two keywords in one of those pairs, 
unless you're proposing we prank our user base. :^)

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Erica Sadun via swift-evolution]

> On May 20, 2016, at 11:52 AM, Chris Lattner <clatt...@apple.com> wrote:
>> On May 20, 2016, at 10:48 AM, Erica Sadun <er...@ericasadun.com> wrote:
>>> On May 20, 2016, at 11:43 AM, Chris Lattner <clatt...@apple.com> wrote:
>>>> On May 20, 2016, at 10:41 AM, Erica Sadun <er...@ericasadun.com> wrote:
>>>>>>> Right, but the catfight had a clear outcome:
>>>>>>> 
>>>>>>> 1) keywords are conjoined
>>>>>>> 2) attributes are lower camel cased.
>>>>>>> 3) attributes should use “non” not “no”.  noescape should be 
>>>>>>> nonescaping (and thus no camel bump).
>>>>>> 
>>>>>> Would you be in favor of a proposal that cleans all of this up at once 
>>>>>> and establishes this standard for all new features?  I don't mind the 
>>>>>> change and think consistency is a good idea, I just think it doesn't 
>>>>>> make sense to keep doing these as one-off changes.
>>>>> 
>>>>> I’d prefer one proposal to cover didset/willset and one to cover 
>>>>> nonescaping (and any other nofoo attributes left).They will raise 
>>>>> different sorts of discussion, even though they both seem obvious to me.
>>>> 
>>>> Before putting together a proposal, are there any other de-facto rules 
>>>> besides the three already listed that touch on naming keywords and 
>>>> attributes? (I suppose no snake case is a given)
>>> 
>>> I think that these are the relevant rules.  As I mentioned upthread, 
>>> .dynamicType is broken for a different reason, and thus leads to a 
>>> different solution (it should be a global function in the stdlib, not a 
>>> propery).
>>> 
>>> -Chris
>> 
>> Separate action items:
>> 
>> * Move dynamicType to standard library as a global function
>> * Rename didSet and willSet to lowercase to conform to Swift standard of 
>> conjoined lowercase keywords.
> 
> Sounds great.
> 
>> * Rename noescape to nonescaping to conform to Swift standard of 
>> "non"-modified attributes
> 
> I just looked and the one other wrong one we have is “noreturn”.  It would be 
> great to tackle nonescaping and whatever noreturn should be in the same 
> proposal.
> 
> Thanks Erica!
> 
> -Chris

Please look through and comment:

https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407 
<https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407>

Gist contents pasted below.

-- Erica


Adopting consistent keyword casing in Swift

Proposal: TBD
Author: Erica Sadun <https://github.com/erica>
Status: TBD
Review manager: TBD
 
<https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#introduction>Introduction

This proposal adopts consistent conjoined keyword lowercasing.

Swift-evolution thread: RFC: didset and willset 
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/17534>
 
<https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#motivation>Motivation

Swift is an opinionated language. One opinion it adheres to is that keywords 
should use conjoined lowercasing. Conjoined lowercase terms already in the 
language include typealias, associatedtype, and fallthrough. Using this casing 
style enables programmers to treat keywords as atomic concepts. This proposal 
formalizes this rule and fixes current inconsistencies. 

 
<https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#swift-casing-rules-roadmap>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 
<https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md>)
Terms of art may be exempted from casing rules.
Phrases sourced from outside Swift may be exempted from Swift casing rules, 
e.g. @UIApplicationMain.
 
<https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#swift-language-cleanup-roadmap>Swift
 Language Cleanup Roadmap

This proposal is part of a series that will:

Normalize casing to lower conjoined names.
Normalize naming for "negative" attributes (from "noFeature" to "nonfeaturing").
Move dynamicType to the standard library as a global function.
 
<https://gist.github.com/erica/7fa61c3b74b2a2635dbea02120ac5407#detailed-design>Detailed
 Design

Upon adoption

Re: [swift-evolution] RFC: didset and willset

[Brent Royal-Gordon via swift-evolution]

>>> When we introduce property behaviors, the surface level syntax for this 
>>> sort of thing is likely to remain the same, and it therefore stands to 
>>> reason that the behavior “accessors” would follow the same convention as 
>>> keywords.
>> 
>> Yes, but what will the conventions be? Is the accessor for the "did change" 
>> behavior going to be `didchange` or `didChange`?
> 
> I’m arguing for “didchange”.  
> 
> To be clear, this is just my personal opinion, but even in the context of a 
> general user-defined behavior, these things seem extremely "keyword like” 
> from the users perspective.  To a user of a behavior, these aspects are not 
> arbitrary user defined names, they are specific things that you can pick 
> from.  The existing accessors clearly work the same way.

Okay. That was not the answer I expected :^), but if that is your answer, and 
if you're pretty confident in that answer, then I support changing willSet and 
didSet.

>> *That*—not some general rule about keywords which is primarily designed to 
>> address things like `fallthrough` and `associatedtype`—is what I think 
>> `willSet` and `didSet` ought to match. Users do not care whether something 
>> comes out of the standard library or the language grammar; they care whether 
>> it has the feel of other things which fit that syntactic slot.
> 
> I don’t understand what you’re trying to say here.

I'm trying to articulate a general rule, that when there is a built-in thing 
that goes alongside user-defined things, the built-in thing should be 
capitalized like the user-defined things even if it's implemented as a 
"keyword".

That is, nobody cares whether dynamicType is a keyword or an extension on Any, 
and nobody cares whether willSet is a keyword or an accessor for a built-in 
property. Since they behave like something else in the grammar, they should be 
spelled like that thing, too.

>> (For instance, a perhaps controversial opinion: I think `dynamicType` is 
>> properly capitalized for the syntactic 
>> slot it's in.
> 
> As I mentioned down-thread, the problem with .dynamicType is that it is in 
> the wrong slot :-)

I don't necessarily disagree. What I'm saying is, fake properties should be 
capitalized like real properties, and fake accessors should be capitalized like 
real accessors.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Chris Lattner via swift-evolution]

> On May 20, 2016, at 11:03 AM, Erica Sadun  wrote:
> 
>> On May 20, 2016, at 11:58 AM, Krystof Vasa  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

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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Xiaodi Wu via 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 
wrote:

> On May 20, 2016, at 1:30 PM, Xiaodi Wu  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  wrote:
>> >
>> > On May 20, 2016, at 7:26 AM, Matthew Johnson 
>> 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
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Matthew Johnson via swift-evolution]

> On May 20, 2016, at 1:30 PM, Xiaodi Wu  wrote:
> 
> On Fri, May 20, 2016 at 1:16 PM, Matthew Johnson via swift-evolution 
> > wrote:
> 
> > On May 20, 2016, at 12:41 PM, Chris Lattner  > > wrote:
> >
> > On May 20, 2016, at 7:26 AM, Matthew Johnson  > > 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 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Xiaodi Wu via swift-evolution]

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  wrote:
> >
> > On May 20, 2016, at 7:26 AM, Matthew Johnson 
> 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/


>
> >
> > -Chris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Chris Lattner via swift-evolution]

On May 19, 2016, at 11:34 PM, Brent Royal-Gordon  wrote:
>> When we introduce property behaviors, the surface level syntax for this sort 
>> of thing is likely to remain the same, and it therefore stands to reason 
>> that the behavior “accessors” would follow the same convention as keywords.
> 
> Yes, but what will the conventions be? Is the accessor for the "did change" 
> behavior going to be `didchange` or `didChange`?

I’m arguing for “didchange”.  

To be clear, this is just my personal opinion, but even in the context of a 
general user-defined behavior, these things seem extremely "keyword like” from 
the users perspective.  To a user of a behavior, these aspects are not 
arbitrary user defined names, they are specific things that you can pick from.  
The existing accessors clearly work the same way.

> If I write a JSON behavior, is my accessor going to be `toJSON` or `tojson`?

If you’re writing a JSON behavior, including “JSON” in the accessor would be a 
needless word.  The names for the accessors should describe “aspects” of the 
behavior they are implementing, not the behavior itself.

That said, you’re right that this could come up.  When and if we have a 
specific example to discuss, I'm sure we can figure out a reasonable policy.


> *That*—not some general rule about keywords which is primarily designed to 
> address things like `fallthrough` and `associatedtype`—is what I think 
> `willSet` and `didSet` ought to match. Users do not care whether something 
> comes out of the standard library or the language grammar; they care whether 
> it has the feel of other things which fit that syntactic slot.

I don’t understand what you’re trying to say here.

> (For instance, a perhaps controversial opinion: I think `dynamicType` is 
> properly capitalized for the syntactic 
> slot it's in.

As I mentioned down-thread, the problem with .dynamicType is that it is in the 
wrong slot :-)

> Thus, `willSet` and `didSet` should be capitalized like other, user-defined, 
> accessors.

I agree with your believe that we should treat these just like user-defined 
accessors.  So lets assume we had an “observed” behavior that had 
didset/willset aspects that can be specified.  To the implementor of the 
behavior, these are terms that they define, but to users of the behavior, they 
are indistinguishable from keywords.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Erica Sadun via swift-evolution]

> On May 20, 2016, at 11:52 AM, Chris Lattner  wrote:
> 
>> 
>> On May 20, 2016, at 10:48 AM, Erica Sadun  wrote:
>> 
>> 
>>> On May 20, 2016, at 11:43 AM, Chris Lattner  wrote:
>>> 
>>> 
 On May 20, 2016, at 10:41 AM, Erica Sadun  wrote:
 
>>> 
>>> Right, but the catfight had a clear outcome:
>>> 
>>> 1) keywords are conjoined
>>> 2) attributes are lower camel cased.
>>> 3) attributes should use “non” not “no”.  noescape should be 
>>> nonescaping (and thus no camel bump).
>> 
>> Would you be in favor of a proposal that cleans all of this up at once 
>> and establishes this standard for all new features?  I don't mind the 
>> change and think consistency is a good idea, I just think it doesn't 
>> make sense to keep doing these as one-off changes.
> 
> I’d prefer one proposal to cover didset/willset and one to cover 
> nonescaping (and any other nofoo attributes left).They will raise 
> different sorts of discussion, even though they both seem obvious to me.
 
 Before putting together a proposal, are there any other de-facto rules 
 besides the three already listed that touch on naming keywords and 
 attributes? (I suppose no snake case is a given)
>>> 
>>> I think that these are the relevant rules.  As I mentioned upthread, 
>>> .dynamicType is broken for a different reason, and thus leads to a 
>>> different solution (it should be a global function in the stdlib, not a 
>>> propery).
>>> 
>>> -Chris
>> 
>> 
>> Separate action items:
>> 
>> * Move dynamicType to standard library as a global function
>> * Rename didSet and willSet to lowercase to conform to Swift standard of 
>> conjoined lowercase keywords.
> 
> Sounds great.
> 
>> * Rename noescape to nonescaping to conform to Swift standard of 
>> "non"-modified attributes
> 
> I just looked and the one other wrong one we have is “noreturn”.  It would be 
> great to tackle nonescaping and whatever noreturn should be in the same 
> proposal.
> 
> Thanks Erica!
> 
> -Chris

To be clear before I put anything together, `nonreturning`, yes?

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Chris Lattner via swift-evolution]

> On May 20, 2016, at 10:48 AM, Erica Sadun  wrote:
> 
> 
>> On May 20, 2016, at 11:43 AM, Chris Lattner  wrote:
>> 
>> 
>>> On May 20, 2016, at 10:41 AM, Erica Sadun  wrote:
>>> 
>> 
>> Right, but the catfight had a clear outcome:
>> 
>> 1) keywords are conjoined
>> 2) attributes are lower camel cased.
>> 3) attributes should use “non” not “no”.  noescape should be nonescaping 
>> (and thus no camel bump).
> 
> Would you be in favor of a proposal that cleans all of this up at once 
> and establishes this standard for all new features?  I don't mind the 
> change and think consistency is a good idea, I just think it doesn't make 
> sense to keep doing these as one-off changes.
 
 I’d prefer one proposal to cover didset/willset and one to cover 
 nonescaping (and any other nofoo attributes left).They will raise 
 different sorts of discussion, even though they both seem obvious to me.
>>> 
>>> Before putting together a proposal, are there any other de-facto rules 
>>> besides the three already listed that touch on naming keywords and 
>>> attributes? (I suppose no snake case is a given)
>> 
>> I think that these are the relevant rules.  As I mentioned upthread, 
>> .dynamicType is broken for a different reason, and thus leads to a different 
>> solution (it should be a global function in the stdlib, not a propery).
>> 
>> -Chris
> 
> 
> Separate action items:
> 
> * Move dynamicType to standard library as a global function
> * Rename didSet and willSet to lowercase to conform to Swift standard of 
> conjoined lowercase keywords.

Sounds great.

> * Rename noescape to nonescaping to conform to Swift standard of 
> "non"-modified attributes

I just looked and the one other wrong one we have is “noreturn”.  It would be 
great to tackle nonescaping and whatever noreturn should be in the same 
proposal.

Thanks Erica!

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Erica Sadun via swift-evolution]

> On May 20, 2016, at 11:43 AM, Chris Lattner  wrote:
> 
> 
>> On May 20, 2016, at 10:41 AM, Erica Sadun  wrote:
>> 
> 
> Right, but the catfight had a clear outcome:
> 
> 1) keywords are conjoined
> 2) attributes are lower camel cased.
> 3) attributes should use “non” not “no”.  noescape should be nonescaping 
> (and thus no camel bump).
 
 Would you be in favor of a proposal that cleans all of this up at once and 
 establishes this standard for all new features?  I don't mind the change 
 and think consistency is a good idea, I just think it doesn't make sense 
 to keep doing these as one-off changes.
>>> 
>>> I’d prefer one proposal to cover didset/willset and one to cover 
>>> nonescaping (and any other nofoo attributes left).They will raise 
>>> different sorts of discussion, even though they both seem obvious to me.
>> 
>> Before putting together a proposal, are there any other de-facto rules 
>> besides the three already listed that touch on naming keywords and 
>> attributes? (I suppose no snake case is a given)
> 
> I think that these are the relevant rules.  As I mentioned upthread, 
> .dynamicType is broken for a different reason, and thus leads to a different 
> solution (it should be a global function in the stdlib, not a propery).
> 
> -Chris


Separate action items:

* Move dynamicType to standard library as a global function
* Rename didSet and willSet to lowercase to conform to Swift standard of 
conjoined lowercase keywords.
* Rename noescape to nonescaping to conform to Swift standard of "non"-modified 
attributes

Roger that?

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Chris Lattner via swift-evolution]

> On May 20, 2016, at 10:41 AM, Erica Sadun  wrote:
> 
 
 Right, but the catfight had a clear outcome:
 
 1) keywords are conjoined
 2) attributes are lower camel cased.
 3) attributes should use “non” not “no”.  noescape should be nonescaping 
 (and thus no camel bump).
>>> 
>>> Would you be in favor of a proposal that cleans all of this up at once and 
>>> establishes this standard for all new features?  I don't mind the change 
>>> and think consistency is a good idea, I just think it doesn't make sense to 
>>> keep doing these as one-off changes.
>> 
>> I’d prefer one proposal to cover didset/willset and one to cover nonescaping 
>> (and any other nofoo attributes left).They will raise different sorts of 
>> discussion, even though they both seem obvious to me.
> 
> Before putting together a proposal, are there any other de-facto rules 
> besides the three already listed that touch on naming keywords and 
> attributes? (I suppose no snake case is a given)

I think that these are the relevant rules.  As I mentioned upthread, 
.dynamicType is broken for a different reason, and thus leads to a different 
solution (it should be a global function in the stdlib, not a propery).

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Chris Lattner via swift-evolution]

On May 20, 2016, at 7:26 AM, Matthew Johnson  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.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Erica Sadun via swift-evolution]

> On May 20, 2016, at 11:39 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On May 20, 2016, at 7:24 AM, Matthew Johnson  wrote:
>> 
>>> On May 20, 2016, at 1:11 AM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> 
> On May 18, 2016, at 1:55 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> I may be wrong but I don't remember any other case of a keyword in
> Swift composed of two or more words, so I believe these should be
> exceptions.
 
 `typealias` and `associatedtype` are the main examples; there were huge 
 catfights on swift-evolution about whether the latter should be 
 `associatedtype`, `associatedType`, or `associated_type`. There are also a 
 number of attributes like `@noescape` and `@discardableResult`, which 
 aren't 100% consistent.
>>> 
>>> Right, but the catfight had a clear outcome:
>>> 
>>> 1) keywords are conjoined
>>> 2) attributes are lower camel cased.
>>> 3) attributes should use “non” not “no”.  noescape should be nonescaping 
>>> (and thus no camel bump).
>> 
>> Would you be in favor of a proposal that cleans all of this up at once and 
>> establishes this standard for all new features?  I don't mind the change and 
>> think consistency is a good idea, I just think it doesn't make sense to keep 
>> doing these as one-off changes.
> 
> I’d prefer one proposal to cover didset/willset and one to cover nonescaping 
> (and any other nofoo attributes left).They will raise different sorts of 
> discussion, even though they both seem obvious to me.

Before putting together a proposal, are there any other de-facto rules besides 
the three already listed that touch on naming keywords and attributes? (I 
suppose no snake case is a given)

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Chris Lattner via swift-evolution]

> On May 20, 2016, at 7:24 AM, Matthew Johnson  wrote:
> 
>> On May 20, 2016, at 1:11 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
 On May 18, 2016, at 1:55 PM, Brent Royal-Gordon via swift-evolution 
  wrote:
 
 I may be wrong but I don't remember any other case of a keyword in
 Swift composed of two or more words, so I believe these should be
 exceptions.
>>> 
>>> `typealias` and `associatedtype` are the main examples; there were huge 
>>> catfights on swift-evolution about whether the latter should be 
>>> `associatedtype`, `associatedType`, or `associated_type`. There are also a 
>>> number of attributes like `@noescape` and `@discardableResult`, which 
>>> aren't 100% consistent.
>> 
>> Right, but the catfight had a clear outcome:
>> 
>> 1) keywords are conjoined
>> 2) attributes are lower camel cased.
>> 3) attributes should use “non” not “no”.  noescape should be nonescaping 
>> (and thus no camel bump).
> 
> Would you be in favor of a proposal that cleans all of this up at once and 
> establishes this standard for all new features?  I don't mind the change and 
> think consistency is a good idea, I just think it doesn't make sense to keep 
> doing these as one-off changes.

I’d prefer one proposal to cover didset/willset and one to cover nonescaping 
(and any other nofoo attributes left).They will raise different sorts of 
discussion, even though they both seem obvious to me.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Ricardo Parada via swift-evolution]

I think camelCase is richer and easier to read. 

> On May 20, 2016, at 10:26 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On May 20, 2016, at 1:34 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>> When we introduce property behaviors, the surface level syntax for this 
>>> sort of thing is likely to remain the same, and it therefore stands to 
>>> reason that the behavior “accessors” would follow the same convention as 
>>> keywords.
>> 
>> Yes, but what will the conventions be? Is the accessor for the "did change" 
>> behavior going to be `didchange` or `didChange`? If I write a JSON behavior, 
>> is my accessor going to be `toJSON` or `tojson`?
>> 
>> *That*—not some general rule about keywords which is primarily designed to 
>> address things like `fallthrough` and `associatedtype`—is what I think 
>> `willSet` and `didSet` ought to match. Users do not care whether something 
>> comes out of the standard library or the language grammar; they care whether 
>> it has the feel of other things which fit that syntactic slot.
> 
> +1.  Standard library behaviors should use a convention that is appropriate 
> to recommend for user behaviors as well.
> 
>> 
>> (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. 
> 
>> 
>> Thus, `willSet` and `didSet` should be capitalized like other, user-defined, 
>> accessors. If user-defined accessors are not going to go into that syntactic 
>> slot, or if they are going to have all-lowercase accessor names, then by all 
>> means, lowercase `willSet` and `didSet`. But if user-defined accessors are 
>> going to be mixed-case, then `willSet` and `didSet` should be too. And if we 
>> aren't sure whether user-defined accessors will be all-lowercase or mixed 
>> case, then let's not jump the gun and make a change that we're likely to 
>> reverse later.
> 
> +1.
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Matthew Johnson via swift-evolution]

Sent from my iPad

On May 20, 2016, at 1:34 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> When we introduce property behaviors, the surface level syntax for this sort 
>> of thing is likely to remain the same, and it therefore stands to reason 
>> that the behavior “accessors” would follow the same convention as keywords.
> 
> Yes, but what will the conventions be? Is the accessor for the "did change" 
> behavior going to be `didchange` or `didChange`? If I write a JSON behavior, 
> is my accessor going to be `toJSON` or `tojson`?
> 
> *That*—not some general rule about keywords which is primarily designed to 
> address things like `fallthrough` and `associatedtype`—is what I think 
> `willSet` and `didSet` ought to match. Users do not care whether something 
> comes out of the standard library or the language grammar; they care whether 
> it has the feel of other things which fit that syntactic slot.

+1.  Standard library behaviors should use a convention that is appropriate to 
recommend for user behaviors as well.

> 
> (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. 

> 
> Thus, `willSet` and `didSet` should be capitalized like other, user-defined, 
> accessors. If user-defined accessors are not going to go into that syntactic 
> slot, or if they are going to have all-lowercase accessor names, then by all 
> means, lowercase `willSet` and `didSet`. But if user-defined accessors are 
> going to be mixed-case, then `willSet` and `didSet` should be too. And if we 
> aren't sure whether user-defined accessors will be all-lowercase or mixed 
> case, then let's not jump the gun and make a change that we're likely to 
> reverse later.

+1.

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 20, 2016, at 1:11 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>>> On May 18, 2016, at 1:55 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> I may be wrong but I don't remember any other case of a keyword in
>>> Swift composed of two or more words, so I believe these should be
>>> exceptions.
>> 
>> `typealias` and `associatedtype` are the main examples; there were huge 
>> catfights on swift-evolution about whether the latter should be 
>> `associatedtype`, `associatedType`, or `associated_type`. There are also a 
>> number of attributes like `@noescape` and `@discardableResult`, which aren't 
>> 100% consistent.
> 
> Right, but the catfight had a clear outcome:
> 
> 1) keywords are conjoined
> 2) attributes are lower camel cased.
> 3) attributes should use “non” not “no”.  noescape should be nonescaping (and 
> thus no camel bump).

Would you be in favor of a proposal that cleans all of this up at once and 
establishes this standard for all new features?  I don't mind the change and 
think consistency is a good idea, I just think it doesn't make sense to keep 
doing these as one-off changes.

> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Brent Royal-Gordon via swift-evolution]

> When we introduce property behaviors, the surface level syntax for this sort 
> of thing is likely to remain the same, and it therefore stands to reason that 
> the behavior “accessors” would follow the same convention as keywords.

Yes, but what will the conventions be? Is the accessor for the "did change" 
behavior going to be `didchange` or `didChange`? If I write a JSON behavior, is 
my accessor going to be `toJSON` or `tojson`?

*That*—not some general rule about keywords which is primarily designed to 
address things like `fallthrough` and `associatedtype`—is what I think 
`willSet` and `didSet` ought to match. Users do not care whether something 
comes out of the standard library or the language grammar; they care whether it 
has the feel of other things which fit that syntactic slot.

(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.)

Thus, `willSet` and `didSet` should be capitalized like other, user-defined, 
accessors. If user-defined accessors are not going to go into that syntactic 
slot, or if they are going to have all-lowercase accessor names, then by all 
means, lowercase `willSet` and `didSet`. But if user-defined accessors are 
going to be mixed-case, then `willSet` and `didSet` should be too. And if we 
aren't sure whether user-defined accessors will be all-lowercase or mixed case, 
then let's not jump the gun and make a change that we're likely to reverse 
later.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Austin Zheng via swift-evolution]

My personal opinion (as with the @lazy proposal) is that changing the names of 
to-be-property-behaviors should be deferred until the property behaviors 
proposal is finalized and accepted. I understand why fixing them pre-emptively 
might be a good idea, though.

Austin

> On May 19, 2016, at 11:12 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On May 18, 2016, at 2:01 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>>> On May 18, 2016, at 3:53 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
 didSet and willSet remain outliers in the general rule of conjoined 
 lowercase keywords. Is there any support for bringing these outliers into 
 the fold?
>>> 
>>> I don't think we shouldn't touch these until we know what accessors on 
>>> property behaviors are going to look like. We could very well change these 
>>> now and then change them back in the next version; that kind of bouncing 
>>> back and forth is maddening for users. Better leave them alone for now and 
>>> change them later if we decide to, than change them in Swift 3 and then 
>>> have a high probability of changing them back in Swift 4.
>> 
>> I generally agree, but is that an option?  Changing `didSet` to `didset` is 
>> a breaking change.
> 
> In practice, we can accept both spellings for a long time at no harm to 
> anyone.  The first question to answer is “what is the right thing”.  We can 
> talk about how to phase it in separately.
> 
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Chris Lattner via swift-evolution]

> On May 18, 2016, at 2:01 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On May 18, 2016, at 3:53 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>>> didSet and willSet remain outliers in the general rule of conjoined 
>>> lowercase keywords. Is there any support for bringing these outliers into 
>>> the fold?
>> 
>> I don't think we shouldn't touch these until we know what accessors on 
>> property behaviors are going to look like. We could very well change these 
>> now and then change them back in the next version; that kind of bouncing 
>> back and forth is maddening for users. Better leave them alone for now and 
>> change them later if we decide to, than change them in Swift 3 and then have 
>> a high probability of changing them back in Swift 4.
> 
> I generally agree, but is that an option?  Changing `didSet` to `didset` is a 
> breaking change.

In practice, we can accept both spellings for a long time at no harm to anyone. 
 The first question to answer is “what is the right thing”.  We can talk about 
how to phase it in separately.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Jeremy Pereira via swift-evolution]

> On 18 May 2016, at 21:53, Erica Sadun via swift-evolution 
>  wrote:
> 
> Just some context:
> 
> "We have a few conjoined keywords already (typealias, associatedtype, 
> fallthrough).  In the discussion about these terms, we decided that these 
> read best when all lowercase, because they are treated as atomic concepts by 
> programmers”

Hmm, that’s kind of spurious isn’t it? Camel case has nothing to do with 
whether the concept referred to is atomic but whether the label for it is 
composed of multiple words.

If you came across the following 

let databaseTransaction = database.beginTransaction()

you wouldn’t change the T's to lower case on the grounds that database 
transactions are atomic.

> 
> and
> 



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Krystof Vasa via swift-evolution]

I don't see a cleaner solution for observing value change for a property on 
superclass:

class MyView: UIView {

override var bounds: CGRect {
didSet { 
self._clearCachedValues() 
}
}

}

Without didSet, you need to do this:

class MyView: UIView {

override var bounds: CGRect {
get { 
return super.bounds 
}
set { 
super.bounds = newValue
self._clearCachedValues() 
}
}

}

Which is just so painful to type out.

Krystof


> On May 19, 2016, at 8:37 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> Because some posts explicitly stated the willSet/didSet-functionality should 
> be kept (and I mentioned the option of discarding them):
> My statement had the same background as Brent's — I expect there will be a 
> "cleaner" and more versatile replacement in the future, so "don't fix it if 
> it isn't broken, and will be replaced soon anyways" ;-)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Tino Heth via swift-evolution]

Because some posts explicitly stated the willSet/didSet-functionality should be 
kept (and I mentioned the option of discarding them):
My statement had the same background as Brent's — I expect there will be a 
"cleaner" and more versatile replacement in the future, so "don't fix it if it 
isn't broken, and will be replaced soon anyways" ;-)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Austin Zheng via swift-evolution]

I really don't want didSet and willSet to be changed.

Will changing them make them easier to tell apart from each other? I don't 
think so. I think it'll only make it slightly harder, now that there isn't a 
easily-identifiable visual cue that groups "didSet" and "willSet" on one hand, 
and "set" and "get" on the other.

Are "didSet" and "willSet" used in the Swift grammar in a way where they might 
be confused with a type, identifier, or other language construct? I don't think 
so either. They can only be used to open a curly-brace delimited clause within 
a property definition. That's the only place they show up, and the way in which 
they are used is highly formulaic.

What is the primary reason to change them? If it's consistency, why then is 
this (rather synthetic form of) consistency an end, rather than a means to an 
end? Code is, after all, meant to be read by human beings, and human beings 
still care about aesthetics and things being easy and pleasant to look at, 
where 'easy to look at' and 'consistent' aren't the same.

By the way, fun fact - if you try to use "didSet" in a subscript the error 
message reads "DidSet is not allowed in subscripts." That should probably be 
fixed. (Xcode 7.3.1.)

Austin


> On May 18, 2016, at 7:42 PM, Angelo Villegas via swift-evolution 
>  wrote:
> 
> I prefer camelCase but if it's inconsistent to the current Swift then I guess 
> a review is needed. I would like to add though that a small change of letter 
> case that will break Swift just because it feels inconsistent is a bit over 
> the top. It needs to be reviewed properly.
> 
> I'm also against removing it completely. didSet/willSet can be helpful the 
> same as viewWillAppear/viewDidAppear.
> 
> 
> On 19 May 2016, 9:44 AM +0800, Ricardo Parada via swift-evolution 
> , wrote:
>> I like them camelCase.
>> 
>>> On May 18, 2016, at 4:58 PM, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On May 18, 2016, at 2:56 PM, Krystof Vasa  wrote:
 
 Not to mention @NSApplicationMain, @NSManaged, ...
 
 I'd personally keep it camelCase.
>>> 
>>> Those are sourced external to Swift.
>>> 
> On May 18, 2016, at 10:53 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Just some context:
> 
> "We have a few conjoined keywords already (typealias, associatedtype, 
> fallthrough). In the discussion about these terms, we decided that these 
> read best when all lowercase, because they are treated as atomic concepts 
> by programmers"
> 
> and
> 
> "On it being a conjoined word, we agreed that the language is currently 
> inconsistent (we have typealias, fallthrough, but also didSet/willSet and 
> @warn_unused_result) and that we should clean it up. Conjoined feels like 
> the right direction to go for this case. We didn’t discuss it but IMO, 
> didSet should get lowercased as well."
> 
> -- E
> 
> 
>> On May 18, 2016, at 2:50 PM, Sean Heber  wrote:
>> 
>> +1 on not getting rid of willSet and didSet for sure!
>> 
>> As for naming, it doesn’t bother me much either way, but I think 
>> lowercase makes sense with the direction everything else is going.
>> 
>> l8r
>> Sean
>> 
>> 
>>> On May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution 
>>>  wrote:
>>> 
>>> Hi Erica,
>>> 
>>> "didset" and "willset" are outliers in the general rule that when 
>>> combining multiple words into an identifier, that you should use 
>>> camelCase. which rule is more important? I'd like to introduce a third 
>>> rule: don't fix it if it isn't broken, or more mildly: if in doubt, 
>>> keep it the way it is. or another one: embrace precedent.. "@IBOutlet" 
>>> is also not all-lowercase, should it be changed too? I'd say no, 
>>> because in objc it is called "IBOutlet" as well. Also, for my Apple 
>>> Mail client, "didset" and "willset" are marked as typos, but "didSet" 
>>> and "willSet" is okay :)
>>> 
>>> => I vote for "didSet" and "willSet".
>>> 
>>> I think we should be more careful when trying to argue with 
>>> "consistency". It sounds objective, when in reality it's often very 
>>> subjective, because Immanuel Kant's imperative is ambiguous ;) there 
>>> are multiple ways to be consistent. If you are saying that something is 
>>> inconsistent, you either assert a specific rule of consistency (like 
>>> "keywords are always lowercase"), or you must argue that there is no 
>>> general/sane rule under which the individual parts of the system are 
>>> consistent.
>>> 
>>> And for all the others who want to abolish didSet and willSet 
>>> completely:
>>> NO WAY! they are both useful and I even used them 

Re: [swift-evolution] RFC: didset and willset

[Angelo Villegas via swift-evolution]

I prefer camelCase but if it's inconsistent to the current Swift then I guess a 
review is needed. I would like to add though that a small change of letter case 
that will break Swift just because it feels inconsistent is a bit over the top. 
It needs to be reviewed properly.

I'm also against removing it completely. didSet/willSet can be helpful the same 
as viewWillAppear/viewDidAppear.


On 19 May 2016, 9:44 AM +0800, Ricardo Parada via 
swift-evolution, wrote:
> I like them camelCase.
>  
> > On May 18, 2016, at 4:58 PM, Erica Sadun via 
> > swift-evolutionwrote:
> >  
> >  
> > > On May 18, 2016, at 2:56 PM, Krystof Vasawrote:
> > >  
> > > Not to mention @NSApplicationMain, @NSManaged, ...
> > >  
> > > I'd personally keep it camelCase.
> >  
> > Those are sourced external to Swift.
> >  
> > > > On May 18, 2016, at 10:53 PM, Erica Sadun via 
> > > > swift-evolutionwrote:
> > > >  
> > > > Just some context:
> > > >  
> > > > "We have a few conjoined keywords already (typealias, associatedtype, 
> > > > fallthrough). In the discussion about these terms, we decided that 
> > > > these read best when all lowercase, because they are treated as atomic 
> > > > concepts by programmers"
> > > >  
> > > > and
> > > >  
> > > > "On it being a conjoined word, we agreed that the language is currently 
> > > > inconsistent (we have typealias, fallthrough, but also didSet/willSet 
> > > > and @warn_unused_result) and that we should clean it up. Conjoined 
> > > > feels like the right direction to go for this case. We didn’t discuss 
> > > > it but IMO, didSet should get lowercased as well."
> > > >  
> > > > -- E
> > > >  
> > > >  
> > > > > On May 18, 2016, at 2:50 PM, Sean Heberwrote:
> > > > >  
> > > > > +1 on not getting rid of willSet and didSet for sure!
> > > > >  
> > > > > As for naming, it doesn’t bother me much either way, but I think 
> > > > > lowercase makes sense with the direction everything else is going.
> > > > >  
> > > > > l8r
> > > > > Sean
> > > > >  
> > > > >  
> > > > > > On May 18, 2016, at 3:38 PM, Michael Peternell via 
> > > > > > swift-evolutionwrote:
> > > > > >  
> > > > > > Hi Erica,
> > > > > >  
> > > > > > "didset" and "willset" are outliers in the general rule that when 
> > > > > > combining multiple words into an identifier, that you should use 
> > > > > > camelCase. which rule is more important? I'd like to introduce a 
> > > > > > third rule: don't fix it if it isn't broken, or more mildly: if in 
> > > > > > doubt, keep it the way it is. or another one: embrace precedent.. 
> > > > > > "@IBOutlet" is also not all-lowercase, should it be changed too? 
> > > > > > I'd say no, because in objc it is called "IBOutlet" as well. Also, 
> > > > > > for my Apple Mail client, "didset" and "willset" are marked as 
> > > > > > typos, but "didSet" and "willSet" is okay :)
> > > > > >  
> > > > > > =>I vote for "didSet" and "willSet".
> > > > > >  
> > > > > > I think we should be more careful when trying to argue with 
> > > > > > "consistency". It sounds objective, when in reality it's often very 
> > > > > > subjective, because Immanuel Kant's imperative is ambiguous ;) 
> > > > > > there are multiple ways to be consistent. If you are saying that 
> > > > > > something is inconsistent, you either assert a specific rule of 
> > > > > > consistency (like "keywords are always lowercase"), or you must 
> > > > > > argue that there is no general/sane rule under which the individual 
> > > > > > parts of the system are consistent.
> > > > > >  
> > > > > > And for all the others who want to abolish didSet and willSet 
> > > > > > completely:
> > > > > > NO WAY! they are both useful and I even used them for real code. 
> > > > > > For example, from code in my bachelors thesis (it's about polygons):
> > > > > >  
> > > > > > public var points: Array= [] {
> > > > > > didSet {
> > > > > > _area = nil
> > > > > > _centroid = nil
> > > > > > }
> > > > > > }
> > > > > >  
> > > > > > I want to cache the _area and _centroid of a polygon, because I'm 
> > > > > > going to use it many many times more often than I change points. I 
> > > > > > would have to rewrite that code to something like
> > > > > >  
> > > > > > private var _points: Array= []
> > > > > > public var points {
> > > > > > get {
> > > > > > return _points
> > > > > > }
> > > > > > set {
> > > > > > _area = nil
> > > > > > _centroid = nil
> > > > > > _points = newValue
> > > > > > }
> > > > > > }
> > > > > >  
> > > > > > That's not better, and it probably breaks the COW-optimization of 
> > > > > > the underlying array. (And don't tell me that my design is bad 
> > > > > > because I use "didSet", I really don't think so.)
> > > > > >  
> > > > > > -Michael
> > > > > >  
> > > > > > > Am 18.05.2016 um 17:09 schrieb Erica Sadun via 
> > > > > > > 

Re: [swift-evolution] RFC: didset and willset

[Ricardo Parada via swift-evolution]

I like them camelCase. 

> On May 18, 2016, at 4:58 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On May 18, 2016, at 2:56 PM, Krystof Vasa  wrote:
>> 
>> Not to mention @NSApplicationMain, @NSManaged, ...
>> 
>> I'd personally keep it camelCase.
> 
> Those are sourced external to Swift.
> 
>>> On May 18, 2016, at 10:53 PM, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> Just some context:
>>> 
>>> "We have a few conjoined keywords already (typealias, associatedtype, 
>>> fallthrough).  In the discussion about these terms, we decided that these 
>>> read best when all lowercase, because they are treated as atomic concepts 
>>> by programmers"
>>> 
>>> and
>>> 
>>> "On it being a conjoined word, we agreed that the language is currently 
>>> inconsistent (we have typealias, fallthrough, but also didSet/willSet and 
>>> @warn_unused_result) and that we should clean it up.  Conjoined feels like 
>>> the right direction to go for this case.  We didn’t discuss it but IMO, 
>>> didSet should get lowercased as well."
>>> 
>>> -- E
>>> 
>>> 
 On May 18, 2016, at 2:50 PM, Sean Heber  wrote:
 
 +1 on not getting rid of willSet and didSet for sure!
 
 As for naming, it doesn’t bother me much either way, but I think lowercase 
 makes sense with the direction everything else is going.
 
 l8r
 Sean
 
 
> On May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Hi Erica,
> 
> "didset" and "willset" are outliers in the general rule that when 
> combining multiple words into an identifier, that you should use 
> camelCase. which rule is more important? I'd like to introduce a third 
> rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep 
> it the way it is. or another one: embrace precedent.. "@IBOutlet" is also 
> not all-lowercase, should it be changed too? I'd say no, because in objc 
> it is called "IBOutlet" as well. Also, for my Apple Mail client, "didset" 
> and "willset" are marked as typos, but "didSet" and "willSet" is okay :)
> 
> => I vote for "didSet" and "willSet".
> 
> I think we should be more careful when trying to argue with 
> "consistency". It sounds objective, when in reality it's often very 
> subjective, because Immanuel Kant's imperative is ambiguous ;) there are 
> multiple ways to be consistent. If you are saying that something is 
> inconsistent, you either assert a specific rule of consistency (like 
> "keywords are always lowercase"), or you must argue that there is no 
> general/sane rule under which the individual parts of the system are 
> consistent.
> 
> And for all the others who want to abolish didSet and willSet completely:
> NO WAY! they are both useful and I even used them for real code. For 
> example, from code in my bachelors thesis (it's about polygons):
> 
> public var points: Array = [] {
>didSet {
>_area = nil
>_centroid = nil
>}
> }
> 
> I want to cache the _area and _centroid of a polygon, because I'm going 
> to use it many many times more often than I change points. I would have 
> to rewrite that code to something like
> 
> private var _points: Array = []
> public var points {
>get {
>return _points
>}
>set {
>_area = nil
>_centroid = nil
>_points = newValue
>}
> }
> 
> That's not better, and it probably breaks the COW-optimization of the 
> underlying array. (And don't tell me that my design is bad because I use 
> "didSet", I really don't think so.)
> 
> -Michael
> 
>> Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution 
>> :
>> 
>> didSet and willSet remain outliers in the general rule of conjoined 
>> lowercase keywords. Is there any support for bringing these outliers 
>> into the fold?
>> 
>> -- E, going through her "ttd notes" this morning
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Rod Brown via swift-evolution]

Agreed. Personally I prefer willSet and didSet, but consistency of rules is 
higher priority. +1.


> On 19 May 2016, at 1:09 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> didSet and willSet remain outliers in the general rule of conjoined lowercase 
> keywords. Is there any support for bringing these outliers into the fold?
> 
> -- E, going through her "ttd notes" this morning
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Michael Peternell via swift-evolution]

> Am 18.05.2016 um 22:58 schrieb Josh Parmenter via swift-evolution 
> :
> 
> I have a general preference for camelCase as well, but I would prefer 
> consistency in the language over my own personal preference.

In fact, I wouldn't care much about the naming. But I don't like much change. 
Change is okay if there is a real improvement. But changes for "consistency" 
have to be very convincing for me to be even considered. After all, "didSet" 
and "willSet" is what I have learned. And I don't think that is entirely bad. 
I'm still open for improvements, but I want to have a feeling that the 
improvement is bigger than my pain about having to learn something new* . I 
hope that is not too much to ask for. "Being easy to learn for Swift 2 wizards" 
should be a medium-priority design goal for Swift 3. That's just my personal 
opinion though. Maybe it's because I have no problem with remembering big 
amounts of keywords with mixed case and underscore rules. (And Xcode 7.3 turns 
all these case-issues into non-issues IMHO.)

-Michael

* Learning about Generics is fun. Learning about the new case-changes in Swift 
3 is not.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Leonardo Pessoa via swift-evolution]

Matthew's right. The first thing here is to define a consistent rule
which takes no exceptions and then apply this rule to every existing
or new keyword and attribute.

On 18 May 2016 at 18:02, Matthew Johnson  wrote:
>
>> On May 18, 2016, at 3:55 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>>
>>> I may be wrong but I don't remember any other case of a keyword in
>>> Swift composed of two or more words, so I believe these should be
>>> exceptions.
>>
>> `typealias` and `associatedtype` are the main examples; there were huge 
>> catfights on swift-evolution about whether the latter should be 
>> `associatedtype`, `associatedType`, or `associated_type`. There are also a 
>> number of attributes like `@noescape` and `@discardableResult`, which aren't 
>> 100% consistent.
>
> Yeah, some of these changes which may feel like low hanging fruit to some 
> turn out to take a lot of energy.
>
> If we’re going to pursue more of these kinds of changes, I would prefer a 
> comprehensive proposal that evaluates everything, establishes well defined 
> conventions, and then applies the changes holistically.
>
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Matthew Johnson via swift-evolution]

> On May 18, 2016, at 3:55 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> I may be wrong but I don't remember any other case of a keyword in
>> Swift composed of two or more words, so I believe these should be
>> exceptions.
> 
> `typealias` and `associatedtype` are the main examples; there were huge 
> catfights on swift-evolution about whether the latter should be 
> `associatedtype`, `associatedType`, or `associated_type`. There are also a 
> number of attributes like `@noescape` and `@discardableResult`, which aren't 
> 100% consistent.

Yeah, some of these changes which may feel like low hanging fruit to some turn 
out to take a lot of energy.  

If we’re going to pursue more of these kinds of changes, I would prefer a 
comprehensive proposal that evaluates everything, establishes well defined 
conventions, and then applies the changes holistically.  

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Matthew Johnson via swift-evolution]

> On May 18, 2016, at 3:53 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> didSet and willSet remain outliers in the general rule of conjoined 
>> lowercase keywords. Is there any support for bringing these outliers into 
>> the fold?
> 
> I don't think we shouldn't touch these until we know what accessors on 
> property behaviors are going to look like. We could very well change these 
> now and then change them back in the next version; that kind of bouncing back 
> and forth is maddening for users. Better leave them alone for now and change 
> them later if we decide to, than change them in Swift 3 and then have a high 
> probability of changing them back in Swift 4.

I generally agree, but is that an option?  Changing `didSet` to `didset` is a 
breaking change.  Or are you arguing that this is a special case as it is 
already going to change when property behaviors are introduced?

I wish we had a clearer sense of how breaking changes will be evaluated in 
future versions of Swift.

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Erica Sadun via swift-evolution]

> On May 18, 2016, at 2:56 PM, Krystof Vasa  wrote:
> 
> Not to mention @NSApplicationMain, @NSManaged, ...
> 
> I'd personally keep it camelCase.
> 

Those are sourced external to Swift.

>> On May 18, 2016, at 10:53 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Just some context:
>> 
>> "We have a few conjoined keywords already (typealias, associatedtype, 
>> fallthrough).  In the discussion about these terms, we decided that these 
>> read best when all lowercase, because they are treated as atomic concepts by 
>> programmers"
>> 
>> and
>> 
>> "On it being a conjoined word, we agreed that the language is currently 
>> inconsistent (we have typealias, fallthrough, but also didSet/willSet and 
>> @warn_unused_result) and that we should clean it up.  Conjoined feels like 
>> the right direction to go for this case.  We didn’t discuss it but IMO, 
>> didSet should get lowercased as well."
>> 
>> -- E
>> 
>> 
>>> On May 18, 2016, at 2:50 PM, Sean Heber  wrote:
>>> 
>>> +1 on not getting rid of willSet and didSet for sure!
>>> 
>>> As for naming, it doesn’t bother me much either way, but I think lowercase 
>>> makes sense with the direction everything else is going.
>>> 
>>> l8r
>>> Sean
>>> 
>>> 
 On May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution 
  wrote:
 
 Hi Erica,
 
 "didset" and "willset" are outliers in the general rule that when 
 combining multiple words into an identifier, that you should use 
 camelCase. which rule is more important? I'd like to introduce a third 
 rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep 
 it the way it is. or another one: embrace precedent.. "@IBOutlet" is also 
 not all-lowercase, should it be changed too? I'd say no, because in objc 
 it is called "IBOutlet" as well. Also, for my Apple Mail client, "didset" 
 and "willset" are marked as typos, but "didSet" and "willSet" is okay :)
 
 => I vote for "didSet" and "willSet".
 
 I think we should be more careful when trying to argue with "consistency". 
 It sounds objective, when in reality it's often very subjective, because 
 Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be 
 consistent. If you are saying that something is inconsistent, you either 
 assert a specific rule of consistency (like "keywords are always 
 lowercase"), or you must argue that there is no general/sane rule under 
 which the individual parts of the system are consistent.
 
 And for all the others who want to abolish didSet and willSet completely:
 NO WAY! they are both useful and I even used them for real code. For 
 example, from code in my bachelors thesis (it's about polygons):
 
 public var points: Array = [] {
 didSet {
 _area = nil
 _centroid = nil
 }
 }
 
 I want to cache the _area and _centroid of a polygon, because I'm going to 
 use it many many times more often than I change points. I would have to 
 rewrite that code to something like
 
 private var _points: Array = []
 public var points {
 get {
 return _points
 }
 set {
 _area = nil
 _centroid = nil
 _points = newValue
 }
 }
 
 That's not better, and it probably breaks the COW-optimization of the 
 underlying array. (And don't tell me that my design is bad because I use 
 "didSet", I really don't think so.)
 
 -Michael
 
> Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution 
> :
> 
> didSet and willSet remain outliers in the general rule of conjoined 
> lowercase keywords. Is there any support for bringing these outliers into 
> the fold?
> 
> -- E, going through her "ttd notes" this morning
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Josh Parmenter via swift-evolution]

I have a general preference for camelCase as well, but I would prefer 
consistency in the language over my own personal preference.

Best,
Josh

> On May 18, 2016, at 1:56 PM, Krystof Vasa via swift-evolution 
>  wrote:
> 
> Not to mention @NSApplicationMain, @NSManaged, ...
> 
> I'd personally keep it camelCase.
> 
>> On May 18, 2016, at 10:53 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> Just some context:
>> 
>> "We have a few conjoined keywords already (typealias, associatedtype, 
>> fallthrough).  In the discussion about these terms, we decided that these 
>> read best when all lowercase, because they are treated as atomic concepts by 
>> programmers"
>> 
>> and
>> 
>> "On it being a conjoined word, we agreed that the language is currently 
>> inconsistent (we have typealias, fallthrough, but also didSet/willSet and 
>> @warn_unused_result) and that we should clean it up.  Conjoined feels like 
>> the right direction to go for this case.  We didn’t discuss it but IMO, 
>> didSet should get lowercased as well."
>> 
>> -- E
>> 
>> 
>>> On May 18, 2016, at 2:50 PM, Sean Heber  wrote:
>>> 
>>> +1 on not getting rid of willSet and didSet for sure!
>>> 
>>> As for naming, it doesn’t bother me much either way, but I think lowercase 
>>> makes sense with the direction everything else is going.
>>> 
>>> l8r
>>> Sean
>>> 
>>> 
 On May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution 
  wrote:
 
 Hi Erica,
 
 "didset" and "willset" are outliers in the general rule that when 
 combining multiple words into an identifier, that you should use 
 camelCase. which rule is more important? I'd like to introduce a third 
 rule: don't fix it if it isn't broken, or more mildly: if in doubt, keep 
 it the way it is. or another one: embrace precedent.. "@IBOutlet" is also 
 not all-lowercase, should it be changed too? I'd say no, because in objc 
 it is called "IBOutlet" as well. Also, for my Apple Mail client, "didset" 
 and "willset" are marked as typos, but "didSet" and "willSet" is okay :)
 
 => I vote for "didSet" and "willSet".
 
 I think we should be more careful when trying to argue with "consistency". 
 It sounds objective, when in reality it's often very subjective, because 
 Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be 
 consistent. If you are saying that something is inconsistent, you either 
 assert a specific rule of consistency (like "keywords are always 
 lowercase"), or you must argue that there is no general/sane rule under 
 which the individual parts of the system are consistent.
 
 And for all the others who want to abolish didSet and willSet completely:
 NO WAY! they are both useful and I even used them for real code. For 
 example, from code in my bachelors thesis (it's about polygons):
 
 public var points: Array = [] {
 didSet {
 _area = nil
 _centroid = nil
 }
 }
 
 I want to cache the _area and _centroid of a polygon, because I'm going to 
 use it many many times more often than I change points. I would have to 
 rewrite that code to something like
 
 private var _points: Array = []
 public var points {
 get {
 return _points
 }
 set {
 _area = nil
 _centroid = nil
 _points = newValue
 }
 }
 
 That's not better, and it probably breaks the COW-optimization of the 
 underlying array. (And don't tell me that my design is bad because I use 
 "didSet", I really don't think so.)
 
 -Michael
 
> Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution 
> :
> 
> didSet and willSet remain outliers in the general rule of conjoined 
> lowercase keywords. Is there any support for bringing these outliers into 
> the fold?
> 
> -- E, going through her "ttd notes" this morning
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] RFC: didset and willset

[Patrick Smith via swift-evolution]

Yeah I agree completely with this. They may be camel case with property 
behaviours, so best to keep them as is for now.

> On 19 May 2016, at 6:53 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> didSet and willSet remain outliers in the general rule of conjoined 
>> lowercase keywords. Is there any support for bringing these outliers into 
>> the fold?
> 
> I don't think we shouldn't touch these until we know what accessors on 
> property behaviors are going to look like. We could very well change these 
> now and then change them back in the next version; that kind of bouncing back 
> and forth is maddening for users. Better leave them alone for now and change 
> them later if we decide to, than change them in Swift 3 and then have a high 
> probability of changing them back in Swift 4.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Krystof Vasa via swift-evolution]

Not to mention @NSApplicationMain, @NSManaged, ...

I'd personally keep it camelCase.

> On May 18, 2016, at 10:53 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Just some context:
> 
> "We have a few conjoined keywords already (typealias, associatedtype, 
> fallthrough).  In the discussion about these terms, we decided that these 
> read best when all lowercase, because they are treated as atomic concepts by 
> programmers"
> 
> and
> 
> "On it being a conjoined word, we agreed that the language is currently 
> inconsistent (we have typealias, fallthrough, but also didSet/willSet and 
> @warn_unused_result) and that we should clean it up.  Conjoined feels like 
> the right direction to go for this case.  We didn’t discuss it but IMO, 
> didSet should get lowercased as well."
> 
> -- E
> 
> 
>> On May 18, 2016, at 2:50 PM, Sean Heber  wrote:
>> 
>> +1 on not getting rid of willSet and didSet for sure!
>> 
>> As for naming, it doesn’t bother me much either way, but I think lowercase 
>> makes sense with the direction everything else is going.
>> 
>> l8r
>> Sean
>> 
>> 
>>> On May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution 
>>>  wrote:
>>> 
>>> Hi Erica,
>>> 
>>> "didset" and "willset" are outliers in the general rule that when combining 
>>> multiple words into an identifier, that you should use camelCase. which 
>>> rule is more important? I'd like to introduce a third rule: don't fix it if 
>>> it isn't broken, or more mildly: if in doubt, keep it the way it is. or 
>>> another one: embrace precedent.. "@IBOutlet" is also not all-lowercase, 
>>> should it be changed too? I'd say no, because in objc it is called 
>>> "IBOutlet" as well. Also, for my Apple Mail client, "didset" and "willset" 
>>> are marked as typos, but "didSet" and "willSet" is okay :)
>>> 
>>> => I vote for "didSet" and "willSet".
>>> 
>>> I think we should be more careful when trying to argue with "consistency". 
>>> It sounds objective, when in reality it's often very subjective, because 
>>> Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be 
>>> consistent. If you are saying that something is inconsistent, you either 
>>> assert a specific rule of consistency (like "keywords are always 
>>> lowercase"), or you must argue that there is no general/sane rule under 
>>> which the individual parts of the system are consistent.
>>> 
>>> And for all the others who want to abolish didSet and willSet completely:
>>> NO WAY! they are both useful and I even used them for real code. For 
>>> example, from code in my bachelors thesis (it's about polygons):
>>> 
>>>  public var points: Array = [] {
>>>  didSet {
>>>  _area = nil
>>>  _centroid = nil
>>>  }
>>>  }
>>> 
>>> I want to cache the _area and _centroid of a polygon, because I'm going to 
>>> use it many many times more often than I change points. I would have to 
>>> rewrite that code to something like
>>> 
>>>  private var _points: Array = []
>>>  public var points {
>>>  get {
>>>  return _points
>>>  }
>>>  set {
>>>  _area = nil
>>>  _centroid = nil
>>>  _points = newValue
>>>  }
>>>  }
>>> 
>>> That's not better, and it probably breaks the COW-optimization of the 
>>> underlying array. (And don't tell me that my design is bad because I use 
>>> "didSet", I really don't think so.)
>>> 
>>> -Michael
>>> 
 Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution 
 :
 
 didSet and willSet remain outliers in the general rule of conjoined 
 lowercase keywords. Is there any support for bringing these outliers into 
 the fold?
 
 -- E, going through her "ttd notes" this morning
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Brent Royal-Gordon via swift-evolution]

> I may be wrong but I don't remember any other case of a keyword in
> Swift composed of two or more words, so I believe these should be
> exceptions.

`typealias` and `associatedtype` are the main examples; there were huge 
catfights on swift-evolution about whether the latter should be 
`associatedtype`, `associatedType`, or `associated_type`. There are also a 
number of attributes like `@noescape` and `@discardableResult`, which aren't 
100% consistent.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Erica Sadun via swift-evolution]

Just some context:

"We have a few conjoined keywords already (typealias, associatedtype, 
fallthrough).  In the discussion about these terms, we decided that these read 
best when all lowercase, because they are treated as atomic concepts by 
programmers"

and

"On it being a conjoined word, we agreed that the language is currently 
inconsistent (we have typealias, fallthrough, but also didSet/willSet and 
@warn_unused_result) and that we should clean it up.  Conjoined feels like the 
right direction to go for this case.  We didn’t discuss it but IMO, didSet 
should get lowercased as well."

-- E


> On May 18, 2016, at 2:50 PM, Sean Heber  wrote:
> 
> +1 on not getting rid of willSet and didSet for sure!
> 
> As for naming, it doesn’t bother me much either way, but I think lowercase 
> makes sense with the direction everything else is going.
> 
> l8r
> Sean
> 
> 
>> On May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution 
>>  wrote:
>> 
>> Hi Erica,
>> 
>> "didset" and "willset" are outliers in the general rule that when combining 
>> multiple words into an identifier, that you should use camelCase. which rule 
>> is more important? I'd like to introduce a third rule: don't fix it if it 
>> isn't broken, or more mildly: if in doubt, keep it the way it is. or another 
>> one: embrace precedent.. "@IBOutlet" is also not all-lowercase, should it be 
>> changed too? I'd say no, because in objc it is called "IBOutlet" as well. 
>> Also, for my Apple Mail client, "didset" and "willset" are marked as typos, 
>> but "didSet" and "willSet" is okay :)
>> 
>> => I vote for "didSet" and "willSet".
>> 
>> I think we should be more careful when trying to argue with "consistency". 
>> It sounds objective, when in reality it's often very subjective, because 
>> Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be 
>> consistent. If you are saying that something is inconsistent, you either 
>> assert a specific rule of consistency (like "keywords are always 
>> lowercase"), or you must argue that there is no general/sane rule under 
>> which the individual parts of the system are consistent.
>> 
>> And for all the others who want to abolish didSet and willSet completely:
>> NO WAY! they are both useful and I even used them for real code. For 
>> example, from code in my bachelors thesis (it's about polygons):
>> 
>>   public var points: Array = [] {
>>   didSet {
>>   _area = nil
>>   _centroid = nil
>>   }
>>   }
>> 
>> I want to cache the _area and _centroid of a polygon, because I'm going to 
>> use it many many times more often than I change points. I would have to 
>> rewrite that code to something like
>> 
>>   private var _points: Array = []
>>   public var points {
>>   get {
>>   return _points
>>   }
>>   set {
>>   _area = nil
>>   _centroid = nil
>>   _points = newValue
>>   }
>>   }
>> 
>> That's not better, and it probably breaks the COW-optimization of the 
>> underlying array. (And don't tell me that my design is bad because I use 
>> "didSet", I really don't think so.)
>> 
>> -Michael
>> 
>>> Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution 
>>> :
>>> 
>>> didSet and willSet remain outliers in the general rule of conjoined 
>>> lowercase keywords. Is there any support for bringing these outliers into 
>>> the fold?
>>> 
>>> -- E, going through her "ttd notes" this morning
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Brent Royal-Gordon via swift-evolution]

> didSet and willSet remain outliers in the general rule of conjoined lowercase 
> keywords. Is there any support for bringing these outliers into the fold?

I don't think we shouldn't touch these until we know what accessors on property 
behaviors are going to look like. We could very well change these now and then 
change them back in the next version; that kind of bouncing back and forth is 
maddening for users. Better leave them alone for now and change them later if 
we decide to, than change them in Swift 3 and then have a high probability of 
changing them back in Swift 4.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Leonardo Pessoa via swift-evolution]

I may be wrong but I don't remember any other case of a keyword in
Swift composed of two or more words, so I believe these should be
exceptions. I would agree best to change these keywords for others
consisting of only one word but I myself have no suggestion what those
could be. Otherwise I'd rather keep them as-is.

On 18 May 2016 at 17:38, Michael Peternell via swift-evolution
 wrote:
> Hi Erica,
>
> "didset" and "willset" are outliers in the general rule that when combining 
> multiple words into an identifier, that you should use camelCase. which rule 
> is more important? I'd like to introduce a third rule: don't fix it if it 
> isn't broken, or more mildly: if in doubt, keep it the way it is. or another 
> one: embrace precedent.. "@IBOutlet" is also not all-lowercase, should it be 
> changed too? I'd say no, because in objc it is called "IBOutlet" as well. 
> Also, for my Apple Mail client, "didset" and "willset" are marked as typos, 
> but "didSet" and "willSet" is okay :)
>
> => I vote for "didSet" and "willSet".
>
> I think we should be more careful when trying to argue with "consistency". It 
> sounds objective, when in reality it's often very subjective, because 
> Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be 
> consistent. If you are saying that something is inconsistent, you either 
> assert a specific rule of consistency (like "keywords are always lowercase"), 
> or you must argue that there is no general/sane rule under which the 
> individual parts of the system are consistent.
>
> And for all the others who want to abolish didSet and willSet completely:
> NO WAY! they are both useful and I even used them for real code. For example, 
> from code in my bachelors thesis (it's about polygons):
>
> public var points: Array = [] {
> didSet {
> _area = nil
> _centroid = nil
> }
> }
>
> I want to cache the _area and _centroid of a polygon, because I'm going to 
> use it many many times more often than I change points. I would have to 
> rewrite that code to something like
>
> private var _points: Array = []
> public var points {
> get {
> return _points
> }
> set {
> _area = nil
> _centroid = nil
> _points = newValue
> }
> }
>
> That's not better, and it probably breaks the COW-optimization of the 
> underlying array. (And don't tell me that my design is bad because I use 
> "didSet", I really don't think so.)
>
> -Michael
>
>> Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution 
>> :
>>
>> didSet and willSet remain outliers in the general rule of conjoined 
>> lowercase keywords. Is there any support for bringing these outliers into 
>> the fold?
>>
>> -- E, going through her "ttd notes" this morning
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Sean Heber via swift-evolution]

+1 on not getting rid of willSet and didSet for sure!

As for naming, it doesn’t bother me much either way, but I think lowercase 
makes sense with the direction everything else is going.

l8r
Sean


> On May 18, 2016, at 3:38 PM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Hi Erica,
> 
> "didset" and "willset" are outliers in the general rule that when combining 
> multiple words into an identifier, that you should use camelCase. which rule 
> is more important? I'd like to introduce a third rule: don't fix it if it 
> isn't broken, or more mildly: if in doubt, keep it the way it is. or another 
> one: embrace precedent.. "@IBOutlet" is also not all-lowercase, should it be 
> changed too? I'd say no, because in objc it is called "IBOutlet" as well. 
> Also, for my Apple Mail client, "didset" and "willset" are marked as typos, 
> but "didSet" and "willSet" is okay :)
> 
> => I vote for "didSet" and "willSet".
> 
> I think we should be more careful when trying to argue with "consistency". It 
> sounds objective, when in reality it's often very subjective, because 
> Immanuel Kant's imperative is ambiguous ;) there are multiple ways to be 
> consistent. If you are saying that something is inconsistent, you either 
> assert a specific rule of consistency (like "keywords are always lowercase"), 
> or you must argue that there is no general/sane rule under which the 
> individual parts of the system are consistent.
> 
> And for all the others who want to abolish didSet and willSet completely:
> NO WAY! they are both useful and I even used them for real code. For example, 
> from code in my bachelors thesis (it's about polygons):
> 
>public var points: Array = [] {
>didSet {
>_area = nil
>_centroid = nil
>}
>}
> 
> I want to cache the _area and _centroid of a polygon, because I'm going to 
> use it many many times more often than I change points. I would have to 
> rewrite that code to something like
> 
>private var _points: Array = []
>public var points {
>get {
>return _points
>}
>set {
>_area = nil
>_centroid = nil
>_points = newValue
>}
>}
> 
> That's not better, and it probably breaks the COW-optimization of the 
> underlying array. (And don't tell me that my design is bad because I use 
> "didSet", I really don't think so.)
> 
> -Michael
> 
>> Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution 
>> :
>> 
>> didSet and willSet remain outliers in the general rule of conjoined 
>> lowercase keywords. Is there any support for bringing these outliers into 
>> the fold?
>> 
>> -- E, going through her "ttd notes" this morning
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Michael Peternell via swift-evolution]

Hi Erica,

"didset" and "willset" are outliers in the general rule that when combining 
multiple words into an identifier, that you should use camelCase. which rule is 
more important? I'd like to introduce a third rule: don't fix it if it isn't 
broken, or more mildly: if in doubt, keep it the way it is. or another one: 
embrace precedent.. "@IBOutlet" is also not all-lowercase, should it be changed 
too? I'd say no, because in objc it is called "IBOutlet" as well. Also, for my 
Apple Mail client, "didset" and "willset" are marked as typos, but "didSet" and 
"willSet" is okay :)

=> I vote for "didSet" and "willSet".

I think we should be more careful when trying to argue with "consistency". It 
sounds objective, when in reality it's often very subjective, because Immanuel 
Kant's imperative is ambiguous ;) there are multiple ways to be consistent. If 
you are saying that something is inconsistent, you either assert a specific 
rule of consistency (like "keywords are always lowercase"), or you must argue 
that there is no general/sane rule under which the individual parts of the 
system are consistent.

And for all the others who want to abolish didSet and willSet completely:
NO WAY! they are both useful and I even used them for real code. For example, 
from code in my bachelors thesis (it's about polygons):

public var points: Array = [] {
didSet {
_area = nil
_centroid = nil
}
}

I want to cache the _area and _centroid of a polygon, because I'm going to use 
it many many times more often than I change points. I would have to rewrite 
that code to something like

private var _points: Array = []
public var points {
get {
return _points
}
set {
_area = nil
_centroid = nil
_points = newValue
}
}

That's not better, and it probably breaks the COW-optimization of the 
underlying array. (And don't tell me that my design is bad because I use 
"didSet", I really don't think so.)

-Michael

> Am 18.05.2016 um 17:09 schrieb Erica Sadun via swift-evolution 
> :
> 
> didSet and willSet remain outliers in the general rule of conjoined lowercase 
> keywords. Is there any support for bringing these outliers into the fold?
> 
> -- E, going through her "ttd notes" this morning
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Tino Heth via swift-evolution]

> didSet and willSet remain outliers in the general rule of conjoined lowercase 
> keywords. Is there any support for bringing these outliers into the fold?
I would rather like to see them disappear completely — although those 
"decorators" [is there any established term to describe them?] can be quite 
handy, they add a lot of special syntax to the language...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Patrick Smith via swift-evolution]

Not really sure, Like the way the camel case ones look. I’m not sure I 
understand why keywords are lowercase? To reduce clashes with variables?


> On 19 May 2016, at 1:09 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> didSet and willSet remain outliers in the general rule of conjoined lowercase 
> keywords. Is there any support for bringing these outliers into the fold?
> 
> -- E, going through her "ttd notes" this morning
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] RFC: didset and willset

[Xiaodi Wu via swift-evolution]

+1 to consistency!
On Wed, May 18, 2016 at 10:10 Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> didSet and willSet remain outliers in the general rule of conjoined
> lowercase keywords. Is there any support for bringing these outliers into
> the fold?
>
> -- E, going through her "ttd notes" this morning
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] RFC: didset and willset

[Erica Sadun via swift-evolution]

didSet and willSet remain outliers in the general rule of conjoined lowercase 
keywords. Is there any support for bringing these outliers into the fold?

-- E, going through her "ttd notes" this morning

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution