Core Location compatibility shim on Linux uses CL class prefix

[1ec5]

This library publicly exposes a compatibility shim for common Core Location types on Linux. The shim works by aliasing primitive types and defining structs from scratch:

turf-swift/Sources/Turf/CoreLocation.swift

Lines 2 to 12 in 19d1841

	#if os(Linux)
	public struct CLLocationCoordinate2D {
	let latitude: Double
	let longitude: Double
	}
	public typealias CLLocationDirection = Double
	public typealias CLLocationDistance = Double
	public typealias CLLocationDegrees = Double
	#else
	import CoreLocation
	#endif

Unfortunately, if an application imports both Turf and another library that implements a similar shim, there could be conflicts that would at least result in client code having to namespace types or import the library more selectively. For example, mapbox/mapbox-directions-swift#488 adds Linux support to a library that imports both Turf and Polyline. Since Turf’s compatibility shim defines types under the original Core Location names, the Linux version of the codebase has to import Turf, even for files that don’t otherwise contain anything related to geometry operations.

In raphaelmor/Polyline#55, I settled on a slightly different approach: standardize the library on a parallel set of slightly differently named types. Primitives continue to be aliased to Core Location types. On Apple platforms, structs are also aliased to the Core Location types, but on Linux, they’re are defined from scratch. This is similar to the Turf approach, but since it doesn’t claim the CL class prefix, the developer can explicitly opt into the compatibility shim and choose which library they want to get it from in a given file.

Migrating to the Polyline approach would be a backwards-incompatible change.

/cc @frederoni @Udumft

[1ec5]

Making matters worse, CLLocationCoordinate2D.latitude and longitude are internal and there’s no public initializer, so clients have to get this CLLocationCoordinate2D compatibility shim but can’t use it for much at all.