Revise GCD API to conform to API Design Guidelines

Evolution Discussion
1

Hello everyone!

I would like to submit the following rough sketch of a proposal to revise the GCD API syntax to adhere to the API Design Guidelines, in order to gauge interest and collect feedback and suggestions.

Here is a preliminary proposal outline:

Author: Scott Gardner

Introduction

I propose that the Grand Central Dispatch (GCD) API be revised. GCD function signatures use snake-casing and are devoid of parameter names. This syntax does not conform to the Swift API Design Guidelines (“API guidelines”).

Motivation

The GCD API provides a rich set of capabilities for writing concurrent code. Yet GCD’s syntax can be a barrier to entry for developers, because it does not conform to the API guidelines.

Proposed solution

I propose revising the GCD API to follow the API guidelines. For example, instead of writing the following code to execute an operation asynchronously and then return to the main queue, such as to update the UI...

let concurrentQueue = dispatch_queue_create("com.scotteg.concurrent", DISPATCH_QUEUE_CONCURRENT)

dispatch_async(concurrentQueue) {
  // ...
  
  dispatch_async(dispatch_get_main_queue()) {
    // ...
  }
}

…this should be able to written in a more Swifty manner, e.g.,...

let concurrentQueue = GCDQueue(.Concurrent, withIdentifier: "com.scotteg.concurrent")

GCD.enqueueOn(concurrentQueue) {
  // ...
  
  GCD.enqueueOn(.Main) {
    // ...
  }
}

Detailed design

TBD

Impact on existing code

This would be a wholesale replacement of syntax for the GCD API. A utility should also be created to convert pre-existing GCD code to the new syntax.

Alternatives considered

TBD

I would really appreciate your comments and suggestions, and I'd certainly be willing and committed to completing this proposal based on community feedback.

Thanks!
Scott

···

--
Scott Gardner
http://scotteg.com <http://scotteg.com/&gt;

2

Certainly looks much nicer, but considering a major theme Swift 4 is likely to be concurrency, and in the meantime, this is easily solved with a 3rd party library — is it worth it?

SE-0006 admittedly changes Objective-C APIs *a lot*, but in a predictable way, without redesigning it from scratch. So, aside from minor enhancements to CGRect and the like, this would be a precedent AFAICT.

— Radek

···

On 13 Feb 2016, at 16:48, Scott Gardner via swift-evolution <swift-evolution@swift.org> wrote:

Hello everyone!

I would like to submit the following rough sketch of a proposal to revise the GCD API syntax to adhere to the API Design Guidelines, in order to gauge interest and collect feedback and suggestions.

Here is a preliminary proposal outline:

Author: Scott Gardner

Introduction

I propose that the Grand Central Dispatch (GCD) API be revised. GCD function signatures use snake-casing and are devoid of parameter names. This syntax does not conform to the Swift API Design Guidelines (“API guidelines”).

Motivation

The GCD API provides a rich set of capabilities for writing concurrent code. Yet GCD’s syntax can be a barrier to entry for developers, because it does not conform to the API guidelines.

Proposed solution

I propose revising the GCD API to follow the API guidelines. For example, instead of writing the following code to execute an operation asynchronously and then return to the main queue, such as to update the UI...

let concurrentQueue = dispatch_queue_create("com.scotteg.concurrent", DISPATCH_QUEUE_CONCURRENT)

dispatch_async(concurrentQueue) {
  // ...
  
  dispatch_async(dispatch_get_main_queue()) {
    // ...
  }
}

…this should be able to written in a more Swifty manner, e.g.,...

let concurrentQueue = GCDQueue(.Concurrent, withIdentifier: "com.scotteg.concurrent")

GCD.enqueueOn(concurrentQueue) {
  // ...
  
  GCD.enqueueOn(.Main) {
    // ...
  }
}

Detailed design

TBD

Impact on existing code

This would be a wholesale replacement of syntax for the GCD API. A utility should also be created to convert pre-existing GCD code to the new syntax.

Alternatives considered

TBD

I would really appreciate your comments and suggestions, and I'd certainly be willing and committed to completing this proposal based on community feedback.

Thanks!
Scott

--
Scott Gardner
http://scotteg.com <Scott Gardner - Apple | LinkedIn;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

Is there guidance from the Swift team in making C code conform with the Swift design guidelines? I know that there is an effort to apply it to imported Obj-C API, but I wasn’t aware of any guidance on C API. There are a lot of C libraries floating around out there that Swift so far is not trying to change, and so far I’m ok with that.

I’d favor leaving it alone. It’s an existing cross platform open source library. I’d like it to continue to be consistent with where it’s used elsewhere. I’m not huge on the idea of making everything a class level function, and it looks like this proposal is trying to make a set of C functions look like a Swift class.

As others have mentioned, this seems like something someone could wrap, but I don’t feel GCD as it stands is that scary. :)

···

On Feb 13, 2016, at 7:48 AM, Scott Gardner via swift-evolution <swift-evolution@swift.org> wrote:

Hello everyone!

I would like to submit the following rough sketch of a proposal to revise the GCD API syntax to adhere to the API Design Guidelines, in order to gauge interest and collect feedback and suggestions.

Here is a preliminary proposal outline:

Author: Scott Gardner

Introduction

I propose that the Grand Central Dispatch (GCD) API be revised. GCD function signatures use snake-casing and are devoid of parameter names. This syntax does not conform to the Swift API Design Guidelines (“API guidelines”).

Motivation

The GCD API provides a rich set of capabilities for writing concurrent code. Yet GCD’s syntax can be a barrier to entry for developers, because it does not conform to the API guidelines.

Proposed solution

I propose revising the GCD API to follow the API guidelines. For example, instead of writing the following code to execute an operation asynchronously and then return to the main queue, such as to update the UI...

let concurrentQueue = dispatch_queue_create("com.scotteg.concurrent", DISPATCH_QUEUE_CONCURRENT)

dispatch_async(concurrentQueue) {
  // ...
  
  dispatch_async(dispatch_get_main_queue()) {
    // ...
  }
}

…this should be able to written in a more Swifty manner, e.g.,...

let concurrentQueue = GCDQueue(.Concurrent, withIdentifier: "com.scotteg.concurrent")

GCD.enqueueOn(concurrentQueue) {
  // ...
  
  GCD.enqueueOn(.Main) {
    // ...
  }
}

Detailed design

TBD

Impact on existing code

This would be a wholesale replacement of syntax for the GCD API. A utility should also be created to convert pre-existing GCD code to the new syntax.

Alternatives considered

TBD

I would really appreciate your comments and suggestions, and I'd certainly be willing and committed to completing this proposal based on community feedback.

Thanks!
Scott

--
Scott Gardner
http://scotteg.com <Scott Gardner - Apple | LinkedIn;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

Thanks, and I totally agree that there are decent 3rd party libraries, such as Async that wraps GCD (https://github.com/duemunk/Async\). I submitted this because I feel it should not be solely the responsibility of 3rd party libraries to facilitate conformance of Apple API. Also, it puts the onus on newcomers to Swift, iOS, et al, to go find those 3rd party libraries. :]

Scott

···

On Feb 13, 2016, at 9:51 AM, Radosław Pietruszewski <radexpl@gmail.com> wrote:

Certainly looks much nicer, but considering a major theme Swift 4 is likely to be concurrency, and in the meantime, this is easily solved with a 3rd party library — is it worth it?

SE-0006 admittedly changes Objective-C APIs *a lot*, but in a predictable way, without redesigning it from scratch. So, aside from minor enhancements to CGRect and the like, this would be a precedent AFAICT.

— Radek

On 13 Feb 2016, at 16:48, Scott Gardner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello everyone!

I would like to submit the following rough sketch of a proposal to revise the GCD API syntax to adhere to the API Design Guidelines, in order to gauge interest and collect feedback and suggestions.

Here is a preliminary proposal outline:

Author: Scott Gardner

Introduction

I propose that the Grand Central Dispatch (GCD) API be revised. GCD function signatures use snake-casing and are devoid of parameter names. This syntax does not conform to the Swift API Design Guidelines (“API guidelines”).

Motivation

The GCD API provides a rich set of capabilities for writing concurrent code. Yet GCD’s syntax can be a barrier to entry for developers, because it does not conform to the API guidelines.

Proposed solution

I propose revising the GCD API to follow the API guidelines. For example, instead of writing the following code to execute an operation asynchronously and then return to the main queue, such as to update the UI...

let concurrentQueue = dispatch_queue_create("com.scotteg.concurrent", DISPATCH_QUEUE_CONCURRENT)

dispatch_async(concurrentQueue) {
  // ...
  
  dispatch_async(dispatch_get_main_queue()) {
    // ...
  }
}

…this should be able to written in a more Swifty manner, e.g.,...

let concurrentQueue = GCDQueue(.Concurrent, withIdentifier: "com.scotteg.concurrent")

GCD.enqueueOn(concurrentQueue) {
  // ...
  
  GCD.enqueueOn(.Main) {
    // ...
  }
}

Detailed design

TBD

Impact on existing code

This would be a wholesale replacement of syntax for the GCD API. A utility should also be created to convert pre-existing GCD code to the new syntax.

Alternatives considered

TBD

I would really appreciate your comments and suggestions, and I'd certainly be willing and committed to completing this proposal based on community feedback.

Thanks!
Scott

--
Scott Gardner
http://scotteg.com <Scott Gardner - Apple | LinkedIn;

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution