RFC: didset and willset

Evolution Discussion
21

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

-Chris

···

On May 18, 2016, at 1:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> 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.

22

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

I'd personally keep it camelCase.

Those are sourced external to Swift.

···

On May 18, 2016, at 2:56 PM, Krystof Vasa <kvasa@icloud.com> wrote:

On May 18, 2016, at 10:53 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> 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 <sean@fifthace.com> 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 <swift-evolution@swift.org> 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<CGPoint> = {
    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<CGPoint> =
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 <swift-evolution@swift.org>:

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

23

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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org> 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 <sean@fifthace.com> 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 <swift-evolution@swift.org> 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<CGPoint> = {
    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<CGPoint> =
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 <swift-evolution@swift.org>:

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

24

I like them camelCase.

···

On May 18, 2016, at 4:58 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On May 18, 2016, at 2:56 PM, Krystof Vasa <kvasa@icloud.com> 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 <swift-evolution@swift.org> 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 <sean@fifthace.com> 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 <swift-evolution@swift.org> 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<CGPoint> = {
   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<CGPoint> =
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 <swift-evolution@swift.org>:

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

25

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.

···

Am 18.05.2016 um 22:58 schrieb Josh Parmenter via swift-evolution <swift-evolution@swift.org>:

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

26

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 <swift-evolution@swift.org> 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

27

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<swift-evolution@swift.org>, wrote:

I like them camelCase.

> On May 18, 2016, at 4:58 PM, Erica Sadun via swift-evolution<swift-evolution@swift.org>wrote:
>
>
> > On May 18, 2016, at 2:56 PM, Krystof Vasa<kvasa@icloud.com>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<swift-evolution@swift.org>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<sean@fifthace.com>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<swift-evolution@swift.org>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<CGPoint>= {
> > > > > 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<CGPoint>=
> > > > > 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<swift-evolution@swift.org>:
> > > > > >
> > > > > > 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
https://lists.swift.org/mailman/listinfo/swift-evolution

28

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

···

On May 18, 2016, at 2:01 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 18, 2016, at 3:53 PM, Brent Royal-Gordon 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?

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.

29

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

30

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.

···

Sent from my iPad

On May 20, 2016, at 1:11 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 18, 2016, at 1:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

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

31

I think my problem stems from the fact that some of these keywords aren't in the normal place we'd find a keyword. Some are acting like properties and others are acting like methods:

someClass.dynamicType looks like a normal property on an object.
someClass.dynamictype just looks unnatural as a result.

didSet/willSet also look like methods and not really keywords. They also contain descriptive names that are an action of doing something or something about to be down, like a normal method name would usually convey.

I'm not sure there is a perfect way to reconcile these two things: being a keyword and following those rules yet not really seeming like one read or seen.

Would it be easier not to make these keywords somehow? I.E. dynamicType on a protocol all classes conform to which would end that debate once and for all.

Just some thoughts,
Brandon

···

Sent from my iPad

On May 20, 2016, at 2:11 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 18, 2016, at 1:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> 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).

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

32

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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org>, wrote:

I like them camelCase.

On May 18, 2016, at 4:58 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On May 18, 2016, at 2:56 PM, Krystof Vasa <kvasa@icloud.com> 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 <swift-evolution@swift.org> 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 <sean@fifthace.com> 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 <swift-evolution@swift.org> 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<CGPoint> = {
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<CGPoint> =
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 <swift-evolution@swift.org>:

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

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

33

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 <swift-evolution@swift.org> wrote:

On May 18, 2016, at 2:01 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On May 18, 2016, at 3:53 PM, Brent Royal-Gordon 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?

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

34

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.

···

Sent from my iPad
On May 20, 2016, at 1:34 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

--
Brent Royal-Gordon
Architechies

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

35

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

···

On May 20, 2016, at 7:24 AM, Matthew Johnson <matthew@anandabits.com> wrote:

On May 20, 2016, at 1:11 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 18, 2016, at 1:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> 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.

36

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

···

On May 19, 2016, at 11:34 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

37

I think camelCase is richer and easier to read.

···

On May 20, 2016, at 10:26 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

Sent from my iPad

On May 20, 2016, at 1:34 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> 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

38

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

···

On May 20, 2016, at 7:26 AM, Matthew Johnson <matthew@anandabits.com> wrote:

(For instance, a perhaps controversial opinion: I think `dynamicType` is properly capitalized for the syntactic slot it's in. That's not to say I think we should *keep* `dynamicType`, but simply that `foo.dynamicType` is more appropriate than `foo.dynamictype` would be.)

+1. 'foo.dynamictype' seems strange to me.

39

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

···

On May 20, 2016, at 11:39 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 20, 2016, at 7:24 AM, Matthew Johnson <matthew@anandabits.com> wrote:

On May 20, 2016, at 1:11 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 18, 2016, at 1:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> 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.

40

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