> 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. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
