[swift-evolution] RFC: didset and willset

[Angelo Villegas]

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 at swift.org>, wrote:
> I like them camelCase.
>  
> > On May 18, 2016, at 4:58 PM, Erica Sadun via swift-evolution<swift-evolution at swift.org>wrote:
> >  
> >  
> > > On May 18, 2016, at 2:56 PM, Krystof Vasa<kvasa at 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 at 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 at 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 at 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 at 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 at swift.org
> > > > > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > > >  
> > > > > > _______________________________________________
> > > > > > swift-evolution mailing list
> > > > > > swift-evolution at swift.org
> > > > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > >  
> > > > _______________________________________________
> > > > swift-evolution mailing list
> > > > swift-evolution at swift.org
> > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >  
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160519/8465e46f/attachment.html>