Sent from my iPhone > On 6 Sep 2016, at 02:50, Douglas Gregor <[email protected]> wrote: > > > > Sent from my iPhone > >> On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi <[email protected]> wrote: >> >> >> >> 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. > > A macro system isn't a "slight" compromise. It's a major feature whose > existence would forever change the way libraries are written in Swift. It's > not a feature to be taken lightly. The C preprocessor is the single worst > part of the C language from a tooling perspective, and even very > well-designed macro systems (e.g., Scala's macro system is fairly > interesting) have taken numerous iterations. >
Fair enough, I was speaking by someone lucky enough to see mostly good effects on the user side and not the tool implementation side. Sorry if it felt a bit ignorantly irritating as a statement. If the effects of a macro system are seen as so far reaching the concern of getting it even in the medium term is not a completely incorrect one to have though, right? >> 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. > > Objective-C "sorta" lets you use the feature sooner; you can log differently > on iOS 9 with your own implementation of os_los, but the OS provides far > better logging support with a real os_log implementation. The point is that Objective-C kind of allows me to have my cake and eat it too because it makes it a lot easier to have something that still allows me to work on iOS 6-9 and then for iOS 10+ (which means I can use it plenty and get useful development and debugging information internally) I can use the real os_log. > That's the real point here, though: os_log is not a Swift feature. It's an OS > feature available in Swift, and it is very very rare to have an OS-level > feature that works on previous OS's. Compatibility libraries to transform the calls into fancily formatted NSLog statements? Would that be an option? > - Doug > >>> >>> - 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
