Sent from my iPhone
> On 5 Sep 2016, at 20:01, Douglas Gregor <[email protected]> wrote: > > > > Sent from my iPhone > >> On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi <[email protected]> wrote: >> >> >> Sent from my iPhone >> >>> On 5 Sep 2016, at 18:59, Douglas Gregor <[email protected]> wrote: >>> >>> >>> >>> Sent from my iPhone >>> >>>> On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi <[email protected]> wrote: >>>> >>>> Hey Doug, >>>> >>>> How do I use it in Swift code without a wrapper, which is understandably a >>>> bit pointless, if I still support iOS 9? >>> >>> #if or a wrapper are your best options. >>> >> >> This is confusing to me as the WWDC talk they specifically said not to use >> wrappers as it would pick up the wrong context > > Ah, right. I forgot about that. > >> and using the #if directive at every call site would make for a lot of >> repeated code... hard to use. > > Yes, using #if can be boilerplate-y here. > Oh well, if it cannot be helped there is an area I will have to butt heads in code reviews... >> It would be good if macro support for Swift landed in the not too distant >> future as cases like this make its lack of sorely missed. > > Macro support is not likely to be a priority for quite a while. 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. Very few people can go iOS 10+ only and I do find a lot of great value in the new logging system and Objective-C allows me to use it a lot sooner thanks to macro support. > > - Doug > >> >>> - Doug >>> >>>> >>>> Sent from my iPhone >>>> >>>>> On 5 Sep 2016, at 05:05, Brandon Knope via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> Where should the lack of {public} be reported then? >>>>> >>>>> This seems like it falls under jira and not radar because it's in swift >>>>> open source but I'm not 100 percent >>>>> >>>>> Brandon >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On Sep 4, 2016, at 11:48 PM, Douglas Gregor <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Sep 3, 2016, at 11:32 AM, Ben Rimmington via swift-evolution >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> On 3 Sep 2016, at 19:13, Brandon Knope <[email protected]> wrote: >>>>>>>> >>>>>>>> Thank you! I was looking for this last night and failed. >>>>>>>> >>>>>>>> Why do you think {public} isn't included? >>>>>>> >>>>>>> I don't know, but trying to reimplement __builtin_os_log_format in the >>>>>>> overlay seems wrong. It would be better to have a variant of >>>>>>> __builtin_os_log_format which takes a va_list. >>>>>> >>>>>> >>>>>> __builtin_os_log_format is implemented by Clang, not a library, and is >>>>>> quite involved. Implementing os_log in an overlay to provide near >>>>>> feature-compatibility with the C API is the right approach for Swift 3, >>>>>> where a more comprehensive solution (say, a general logging API based on >>>>>> string interpolation or similar) is way out of scope. >>>>>> >>>>>> - Doug >>>>>> >>>>>> >>>>>>> >>>>>>> -- Ben >>>>>>> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> [email protected] >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
