[swift-evolution] RFC: didset and willset

[Erica Sadun]

> On May 20, 2016, at 11:52 AM, Chris Lattner <clattner at apple.com> wrote:
> On May 20, 2016, at 10:48 AM, Erica Sadun <erica at ericasadun.com> wrote:
>> On May 20, 2016, at 11:43 AM, Chris Lattner <clattner at apple.com> wrote:
>>> On May 20, 2016, at 10:41 AM, Erica Sadun <erica at 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".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/8ae3372c/attachment.html>