Open Radar

 
Summary:
Hi!

So I'm looking at the Core Graphics grand renaming.  In CoreGraphics.apinotes there's:

- Name: CGPDFContextBeginPage
  SwiftName: CGContext.beginPDFPage(self:_:)

- Name: CGBitmapContextGetWidth
  SwiftName: getter:CGContext.width(self:)

Notice that BitmapContext and PDFContext, essentially 'subclasses' of CGContext, have their calls placed up at CGContext.  The function calls themselves just take CGContextRefs because OOP in C.

With the C API, it's part of the name, and therefore in your face, that asking the context for a width requires a BitmapContext.

But with Swift 3 and the great renaming, these are now CGContext properties.  If you have a plain old context and bring up the completion window, it happily offers 'width' and 'beginPDFPage' on _any_ CGContext, and there's no hint that these only apply to context 'subclasses' until runtime, when you get errors like this:

<Error>: CGBitmapContextGetWidth: invalid context 0x100e6c3c0.
If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental varia\
ble.

Someone who isn't extremely familiar with the API, doing Programming-by-completion (which is the vast majority of iOS / Mac developers) won't realize that they're completing the wrong thing until its too late.

This has effectively taken bug that can be found at coding time (the name has BitmapContext in it. Do I actually have a BitmapContext) to a runtime error.  Kind of the opposite of Swift's stated goals :-)

Attached are two screenshots from a playground showing the completion suggestions for CGContext.

Steps to Reproduce:


Expected Results:


Actual Results:


Version:
Version 8.0 beta 3 (8S174q)
10.11.5 (15F34)


Notes:
Outside of this one wart, I _love_ _love_ _love_ the new CG API.  Wish I could have it in Objective-C land.

Configuration:


Attachments:
'Screen Shot 2016-07-30 at 1.27.39 PM.png' and 'Screen Shot 2016-07-30 at 1.27.47 PM.png' were successfully uploaded.