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