CTFrameGetLineOrigins useless in Swift 3?

Question

benspratling4 OP

Created Sep ’16

Replies 2

Boosts 0

Participants 2

Implicitly-unwrapped optionals are such an anti-pattern that they are implicitly converted to other types in Swift 3.

UnsafePointers are a throw back to an old language.

Yet CTFrameGetLineOrigins requires a UnsafeMutablePointer<CGPoint>! .

Leaving a big question, how do I even create an implicitly unwrapped unsafe pointer ?

Obviously, the need to have an unsafe pointer in the first place is an anti-pattern as well. So either I'd want a

var lineOrigins:[CGFloat] //computed property

or

func lineOrigins(inRange:CFRange = default)->[CGFloat]

But, as is, is this basically useless, or am I missing something? I spent an hour trying to figure out how to create the argument, haven't figured it out. Frankly I don't think I should have to.

Answered by QuinceyMorris in 176053022

You should submit a bug report about this. It sort of looks like the underlying CoreText API isn't annotated properly. I think the default for C/Obj-C parameters that don't have a nullability annotation is to be imported with the "!". In effect, in Swift 3 it means that the pointer is optional (although it really can't be, except perhaps in the case when the range is empty).

As to how to write the call, the following compiles for me:

class X
     var cf: CTFrame!
     func c () {
          var o = [CGPoint] (repeating: .zero, count: 1)
          CTFrameGetLineOrigins (cf, CFRange (location: 0,length: 1), &o)
     }
}

I wasn't in a position to see if it crashed at runtime, but it seems to work in many scenarios to use the "&" to get an implicit conversion and avoid the messy syntax details of an explicit conversion.

Boost

Answer 1

QuinceyMorris OP

Sep ’16

Accepted Answer

You should submit a bug report about this. It sort of looks like the underlying CoreText API isn't annotated properly. I think the default for C/Obj-C parameters that don't have a nullability annotation is to be imported with the "!". In effect, in Swift 3 it means that the pointer is optional (although it really can't be, except perhaps in the case when the range is empty).

As to how to write the call, the following compiles for me:

class X
     var cf: CTFrame!
     func c () {
          var o = [CGPoint] (repeating: .zero, count: 1)
          CTFrameGetLineOrigins (cf, CFRange (location: 0,length: 1), &o)
     }
}

I wasn't in a position to see if it crashed at runtime, but it seems to work in many scenarios to use the "&" to get an implicit conversion and avoid the messy syntax details of an explicit conversion.

0

Answer 2

benspratling4 OP

Sep ’16

Thanks, my gut reaction when I see a unsafe mutable is to use "&". I wasn't able in this case because I had declared an array of CGFloat instead of CGPoint (face palm) but when I had investigated "what type is it suppossed to be?" and found the implicit unwrapped and assumed that was the problem. Using the & actually creates the unsafe mutable just fine as you illustrated. Thanks. I'm building up a set of wrappers so I can use many of apples libraries in Swift 3 without this kind of headache. I guess I shouldn't have stayed up so late trying that.

0