> On Sep 5, 2016, at 6:44 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi via swift-evolution >> <[email protected]> wrote: >> >> I hope you will not find it too impolite, but this feels like a more >> dogmatic decision than I would like. I agree that macro's do not feel pure, >> but they allow you to adapt to some of the ugliness of real world use cases >> (the fact that Swift forces people to write a lot of boilerplate or to give >> up on this pushes people that support iOS9 and want to go full Swift to drop >> the idea of using os_log... do we rather have that than compromise slightly >> on purity perhaps?). Sorry for the long aside, but maybe shedding all the C >> part of Objective-C did hurt a bit the ease of adaptation. > > I think you may be misinterpreting the reason macros are being deferred. As I > understand it, it's not because of dislike for macros, but because of a > desire to do them deeply and comprehensively—something more like Lisp's > treatment of macros than C's. It's the same reason we haven't yet done > regular expressions, or concurrency, or any of a hundred other features that > are easy to do poorly and difficult to do well. > > A secondary reason is that we want time to develop easier-to-use features for > common boilerplate cases before we design a boilerplate feature that can do > anything, but is difficult to use. For instance, the use cases for the > proposed property behavior feature could probably be handled with macros, but > it would be much more difficult to define a macro than it would be to define > a property behavior.
Right on both points! -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
