Sent from my iPhone
> On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi <pana...@gmail.com> wrote:
>
>
>
> Sent from my iPhone
>
>> On 5 Sep 2016, at 20:01, Douglas Gregor <dgre...@apple.com> wrote:
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi <pana...@gmail.com> wrote:
>>>
>>>
>>> Sent from my iPhone
>>>
>>>> On 5 Sep 2016, at 18:59, Douglas Gregor <dgre...@apple.com> wrote:
>>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi <pana...@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.
> 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. 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.
- Doug
>>
>> - Doug
>>
>>>
>>>> - Doug
>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On 5 Sep 2016, at 05:05, Brandon Knope via swift-evolution
>>>>>> <swift-evolution@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 <dgre...@apple.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>> On Sep 3, 2016, at 11:32 AM, Ben Rimmington via swift-evolution
>>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 3 Sep 2016, at 19:13, Brandon Knope <bkn...@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@swift.org
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution@swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
