Hello Chris, What would you suggest for people that want to use Swift, but cannot set a target of iOS 10+? Could the compiler/backward compatibility library intercept those calls in older OS's and replace them with simple NSLog's with some data added to the logged string?
On Tue, Sep 6, 2016 at 10:56 PM, Chris Lattner <[email protected]> wrote: > > > 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
