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<kv...@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<s...@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
