Note: the {public} modifier above does not work in swift but does in Objective-C. I have filed a radar for this.
A few things:
• This looks like how the Dispatch APIs use to look: very C-like which was made to be much better in The Great Renaming
• Cannot use Swift’s string interpolation, resulting in the arguments being passed in at the end
For reference, this is what it looks like in Objective-C, showing that SOME renaming has occurred:
os_log_debug(ui_log, "Sender: %{public}@", sender);
This might look more Swift-like:
uiLog.log("Sender: %{public}\(sender)”, type: .debug)
* Makes “log” a method on an OSLog object
• Uses string interpolation
I hope this isn’t too late AND maybe we will see something more complete when the GM is released, but this seems important to correct and get right BEFORE it is released.
The OS framework is also suppose to have new activity tracing API but it is not yet exposed in Swift. This is worrisome as the GM is allegedly dropping next week.
If this is pushed aside: what happens when it is released as it is? Are we stuck with this API? Can it be corrected in Swift 4 (breaking changes etc…)?
The os_log_with_type macro in <os/log.h> uses __builtin_os_log_format to encode its arguments into a byte array. The overlay for Swift instead uses its _os_log_encode C++ function, which only recognizes the {private} modifier.
A few things:
• This looks like how the Dispatch APIs use to look: very C-like which was made to be much better in The Great Renaming
• Cannot use Swift’s string interpolation, resulting in the arguments being passed in at the end
For reference, this is what it looks like in Objective-C, showing that SOME renaming has occurred:
os_log_debug(ui_log, "Sender: %{public}@", sender);
This might look more Swift-like:
uiLog.log("Sender: %{public}\(sender)”, type: .debug)
* Makes “log” a method on an OSLog object
• Uses string interpolation
The format string of os_log APIs is required to be constant. The overlay uses a StaticString, which isn't ExpressibleByStringInterpolation. SE-0137 also deprecated the protocol, so that it can be redesigned.
The os_log_with_type macro in <os/log.h> uses __builtin_os_log_format to encode its arguments into a byte array. The overlay for Swift instead uses its _os_log_encode C++ function, which only recognizes the {private} modifier.
A few things:
• This looks like how the Dispatch APIs use to look: very C-like which was made to be much better in The Great Renaming
• Cannot use Swift’s string interpolation, resulting in the arguments being passed in at the end
For reference, this is what it looks like in Objective-C, showing that SOME renaming has occurred:
os_log_debug(ui_log, "Sender: %{public}@", sender);
This might look more Swift-like:
uiLog.log("Sender: %{public}\(sender)”, type: .debug)
* Makes “log” a method on an OSLog object
• Uses string interpolation
The format string of os_log APIs is required to be constant. The overlay uses a StaticString, which isn't ExpressibleByStringInterpolation. SE-0137 also deprecated the protocol, so that it can be redesigned.
I think the framework API mapping itself is not part of the language and is handle by Apple directly (at least for Apple specifics frameworks). I don’t know if such changes are subject to the same policy.
···
Le 3 sept. 2016 à 06:43, Georgios Moschovitis via swift-evolution <swift-evolution@swift.org> a écrit :
Can it be corrected in Swift 4 (breaking changes etc…)?
Good question.
Maybe the core team should accept additional source-breaking changes in 3.x releases?
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.
-- Ben
···
On 3 Sep 2016, at 19:13, Brandon Knope <bknope@me.com> wrote:
Thank you! I was looking for this last night and failed.
I am still not clear how os_log is supposed to be used with Swift if you are not one of the elected ones that can ride his white horse straight into iOS 10+ only land of apps ;). In Objective-C I can use a macro, as wrapper functions are banned, but in Swift? Are availability checks every time I log the answer?
···
Sent from my iPhone
On 3 Sep 2016, at 17:28, Jean-Daniel Dupas via swift-evolution <swift-evolution@swift.org> wrote:
Le 3 sept. 2016 à 06:43, Georgios Moschovitis via swift-evolution <swift-evolution@swift.org> a écrit :
Can it be corrected in Swift 4 (breaking changes etc…)?
Good question.
Maybe the core team should accept additional source-breaking changes in 3.x releases?
I think the framework API mapping itself is not part of the language and is handle by Apple directly (at least for Apple specifics frameworks). I don’t know if such changes are subject to the same policy.
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
···
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 <bknope@me.com> 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@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 <bknope@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.
How do I use it in Swift code without a wrapper, which is understandably a bit pointless, if I still support iOS 9?
···
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 <dgregor@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 <bknope@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.
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
Overlays are a grey area. Please file a radar and send me the radar number offline.
- Doug
···
Sent from my iPhone
On Sep 4, 2016, at 9:05 PM, Brandon Knope <bknope@me.com> wrote:
Brandon
Sent from my iPad
On Sep 4, 2016, at 11:48 PM, Douglas Gregor <dgregor@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 <bknope@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.
On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi <panajev@gmail.com> wrote:
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 <dgregor@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 <bknope@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.
This is confusing to me as the WWDC talk they specifically said not to use wrappers as it would pick up the wrong context and using the if directive at every call site would make for a lot of repeated code... hard to use.
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.
···
Sent from my iPhone
On 5 Sep 2016, at 18:59, Douglas Gregor <dgregor@apple.com> wrote:
On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi <panajev@gmail.com> wrote:
- 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 <dgregor@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 <bknope@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.
For a wrapper, are there any public hooks into dyld that allow us to do
anything meaningful with #dsoHandle on prior OS? Without that, and
without using #dsoHandle, wrapping os_log is essentially useless.
Cheers!
Zachary Waldowski
zach@waldowski.me
···
On Mon, Sep 5, 2016, at 10:59 AM, Douglas Gregor via swift-evolution wrote:
Sent from my iPhone
On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi > <panajev@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?
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 <dgregor@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 <bknope@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.
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.
- Doug
···
Sent from my iPhone
On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi <panajev@gmail.com> wrote:
On 5 Sep 2016, at 18:59, Douglas Gregor <dgregor@apple.com> wrote:
On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi <panajev@gmail.com> wrote:
- 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 <dgregor@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 <bknope@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.
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.
···
Sent from my iPhone
On 5 Sep 2016, at 20:01, Douglas Gregor <dgregor@apple.com> wrote:
On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi <panajev@gmail.com> wrote:
On 5 Sep 2016, at 18:59, Douglas Gregor <dgregor@apple.com> wrote:
On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi <panajev@gmail.com> wrote:
- 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 <dgregor@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 <bknope@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.
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.
···
On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi via swift-evolution <swift-evolution@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.
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
···
Sent from my iPhone
On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi <panajev@gmail.com> wrote:
On 5 Sep 2016, at 20:01, Douglas Gregor <dgregor@apple.com> wrote:
On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi <panajev@gmail.com> wrote:
On 5 Sep 2016, at 18:59, Douglas Gregor <dgregor@apple.com> wrote:
On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi <panajev@gmail.com> wrote:
- 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 <dgregor@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 <bknope@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.
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?
···
Sent from my iPhone
On 6 Sep 2016, at 02:50, Douglas Gregor <dgregor@apple.com> wrote:
On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi <panajev@gmail.com> wrote:
On 5 Sep 2016, at 20:01, Douglas Gregor <dgregor@apple.com> wrote:
On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi <panajev@gmail.com> wrote:
On 5 Sep 2016, at 18:59, Douglas Gregor <dgregor@apple.com> wrote:
On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi <panajev@gmail.com> wrote:
- 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 <dgregor@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 <bknope@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.
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.
Fair enough, I can understand and appreciate the desire to do those features well, but there is also the desire to use such features now that keeps me still writing more and more Objective-C at work. iOS 6 and iOS 7 still matter too much to where I work for iOS 6 to be dropped and without Objective-C's ability to swizzle methods we would have been in trouble with several vendors pushing of libraries which would crash if their code ran on an iOS 6 device, but that is an aside.
···
Sent from my iPhone
On 6 Sep 2016, at 02:44, Brent Royal-Gordon <brent@architechies.com> wrote:
On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote: