[swift-evolution] The great renaming and the state of new Unified Logging in Swift

[Goffredo Marocchi]

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 <clattner at apple.com> wrote:

>
> > On Sep 5, 2016, at 6:44 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >> On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi via swift-evolution <
> swift-evolution at swift.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160906/60be08de/attachment.html>