CLLocationCoordinate2D C array parameters feels unnatural in swift

[js]

Some of the methods taking an C array of CLLocationCoordinate2D feels unnatural in swift, for instance - (void)setVisibleCoordinates:(const CLLocationCoordinate2D *)coordinates count:(NSUInteger)count edgePadding:(UIEdgeInsets)insets animated:(BOOL)animated will get translated to swift as: setVisibleCoordinates(UnsafePointer<CLLocationCoordinate2D>, count: UInt, edgePadding: UIEdgeInsets, animated: Bool)

Any plans to provide some swift shims to improve the ergonomics here? Maybe something like:

extension MGLMapView {
  func setVisibleCoordinates(_ coordinates: [CLLocationCoordinate2D], edgePadding insets: UIEdgeInsets, animated: Bool) {
    var coords = coordinates
    setVisibleCoordinates(&coords, count: UInt(coords.count), edgePadding: insets, animated: animated)
  }
}

slightly related as it lists affected methods: #7214

[1ec5]

Any plans to provide some swift shims to improve the ergonomics here?

We aren’t planning to incorporate Swift code directly into the map SDK proper until we can take advantage of Swift 5’s ABI stability, which will eventually require dropping support for iOS versions older than 12.2.

A separate library (or plugin, if you will) that implements these shims might be a worthwhile improvement in the meantime. We’d be happy to see someone like yourself run with that idea.

In this particular case, it might be possible for the map SDK proper to vend a -setVisibleCoordinateValues:edgePadding:animated: method that takes an NSArray of NSValues. However, that would shift type checking to runtime, which may not be prudent.

/ref mapbox/mapbox-events-ios#3

[js]

Thank you for the response.

Personally I'd rather keep it as it is than introduce a NSValue-based API, for the exact non-prudent reason you mention.