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

Tue Sep 6 01:50:28 CDT 2016

Sent from my iPhone

> On 6 Sep 2016, at 02:50, Douglas Gregor <dgregor at apple.com> wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi <panajev at gmail.com> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 5 Sep 2016, at 20:01, Douglas Gregor <dgregor at apple.com> wrote:
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi <panajev at gmail.com> wrote:
>>>> 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On 5 Sep 2016, at 18:59, Douglas Gregor <dgregor at apple.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi <panajev at gmail.com> 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 <swift-evolution at swift.org> 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 <dgregor at apple.com> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Sent from my iPhone
>>>>>>>> 
>>>>>>>>> On Sep 3, 2016, at 11:32 AM, Ben Rimmington via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 3 Sep 2016, at 19:13, Brandon Knope <bknope at me.com> 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
>>>>>>>>> swift-evolution at swift.org
>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution at swift.org
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160906/4c761daa/attachment.html>