With the release of swift 3, The interface to libDispatch has evolved quite a lot, to a much cleaner, object oriented interface.
There seems to be one feature that is no longer available :
In swift 2, it was possible to get the current queue label using "dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL)".
In the new interface, the DispatchQueue has a label property, but there seems to be no way to get the current queue.
Is that a design decision ?
If not, a "current" class property should probably be added to "DispatchQueue".
If yes, maybe we could add a "currentQueueLabel" class property to "DispatchQueue", but this doesn't look right to me : why should only this property of the current queue be available, and not other ones like "qos" ?
This comes a bit late, I'm sorry for not spotting that when SE-0088 was being reviewed !
With the release of swift 3, The interface to libDispatch has evolved quite a lot, to a much cleaner, object oriented interface.
There seems to be one feature that is no longer available :
In swift 2, it was possible to get the current queue label using "dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL)".
In the new interface, the DispatchQueue has a label property, but there seems to be no way to get the current queue.
Is that a design decision ?
[Cc: Matt Wright]
If not, a "current" class property should probably be added to "DispatchQueue".
`DispatchQueue.current` is unlikely to be accepted, because `dispatch_get_current_queue()` is deprecated (since iOS 6.0, macOS 10.9).
If yes, maybe we could add a "currentQueueLabel" class property to "DispatchQueue", but this doesn't look right to me : why should only this property of the current queue be available, and not other ones like "qos" ?
`DispatchQueue.currentQueueLabel` might be useful for debugging and logging. Or maybe this would be better as an LLDB command or breakpoint action?
The new SE-0088 types don't seem to have CustomStringConvertible or CustomDebugStringConvertible conformance.
-- Ben
···
On 19 Jun 2016, at 23:52, Jérôme Duquennoy via swift-evolution <swift-evolution@swift.org> wrote:
dispatch_queue_get_label() isn’t marked as a for-debugging-only API as far as I can see, and I can see uses in non-debugging contexts (logging is the obvious one) for knowing the current queue’s label (without also allowing the error-prone usage of dispatch_get_current_queue() itself). As such, I wouldn’t mind seeing this interface available on DispatchQueue, though I might name it simply "label", as in:
extension DispatchQueue {
public class var label: String { get }
}
This would be in keeping with the way getSpecific() is named; IMO "DispatchQueue.label" is not ambiguous enough to require the extra "currentQueue" prefix. Or maybe "currentLabel", since if nothing else "queue" seems like noise to me, due to the repetition.
-- Gwynne Raskind
···
On Jun 20, 2016, at 04:02, Ben Rimmington via swift-evolution <swift-evolution@swift.org> wrote:
On 19 Jun 2016, at 23:52, Jérôme Duquennoy via swift-evolution <swift-evolution@swift.org> wrote:
With the release of swift 3, The interface to libDispatch has evolved quite a lot, to a much cleaner, object oriented interface.
There seems to be one feature that is no longer available :
In swift 2, it was possible to get the current queue label using "dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL)".
In the new interface, the DispatchQueue has a label property, but there seems to be no way to get the current queue.
Is that a design decision ?
[Cc: Matt Wright]
If not, a "current" class property should probably be added to "DispatchQueue".
`DispatchQueue.current` is unlikely to be accepted, because `dispatch_get_current_queue()` is deprecated (since iOS 6.0, macOS 10.9).
If yes, maybe we could add a "currentQueueLabel" class property to "DispatchQueue", but this doesn't look right to me : why should only this property of the current queue be available, and not other ones like "qos" ?
`DispatchQueue.currentQueueLabel` might be useful for debugging and logging. Or maybe this would be better as an LLDB command or breakpoint action?
The new SE-0088 types don't seem to have CustomStringConvertible or CustomDebugStringConvertible conformance.
Chris Lattner: "Swift supports instance and type members with the same names, but this is controversial, leads to confusion, and may go away in the future."
On 20 Jun 2016, at 10:14, Gwynne Raskind <gwynne@darkrainfall.org> wrote:
dispatch_queue_get_label() isn’t marked as a for-debugging-only API as far as I can see, and I can see uses in non-debugging contexts (logging is the obvious one) for knowing the current queue’s label (without also allowing the error-prone usage of dispatch_get_current_queue() itself). As such, I wouldn’t mind seeing this interface available on DispatchQueue, though I might name it simply "label", as in:
extension DispatchQueue {
public class var label: String { get }
}
I stand corrected! "currentLabel" would be my prevailing suggestion, then.
-- Gwynne Raskind
···
On Jun 20, 2016, at 04:51, Ben Rimmington <me@benrimmington.com> wrote:
On 20 Jun 2016, at 10:14, Gwynne Raskind <gwynne@darkrainfall.org> wrote:
dispatch_queue_get_label() isn’t marked as a for-debugging-only API as far as I can see, and I can see uses in non-debugging contexts (logging is the obvious one) for knowing the current queue’s label (without also allowing the error-prone usage of dispatch_get_current_queue() itself). As such, I wouldn’t mind seeing this interface available on DispatchQueue, though I might name it simply "label", as in:
extension DispatchQueue {
public class var label: String { get }
}
Chris Lattner: "Swift supports instance and type members with the same names, but this is controversial, leads to confusion, and may go away in the future."