> On Dec 27, 2015, at 4:23 AM, Tino Heth <2...@gmx.de> wrote:
>
>>
>> Of course, if you’re worried about the performance costs associated with
>> that extra method call, you might want to include a keyword, such as
>> “observable”, and only generate the method call(s) if that keyword is on the
> Of course, if you’re worried about the performance costs associated with that
> extra method call, you might want to include a keyword, such as “observable”,
> and only generate the method call(s) if that keyword is on the property.
I strongly agree that Swift should have/keep a possibility to
> On Dec 13, 2015, at 6:49 PM, Marc Knaup via swift-evolution
> wrote:
>
> Also it's unlikely that all mutable properties will support observation
> automatically. That would require the optimizer to keep using dynamic
> dispatch for all of them which will hurt performance.
Not really. All th
FYI, I just sent a proposal draft titled “Generalized Naming for Any Function”
that pulls these ideas together more formally. I went with a different syntax
that I’d been kicking around for a while internally, and I’d love to hear
everyone’s thoughts on this.
- Doug
> On Dec 14, 2015,
Another option for handling this occurred to me - an "export list" in the
lexical block that usually declares getters, setters, and will/didSet:
class Thing {
var property: String {
[get, set]
}
}
It's somewhat like a "capture list" syntax but in the context of the
accessor declarations.
