> 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
