Stylistic differences btw Motion and Location interfaces

[humblehacker]

@stephencelis @mbrandonw Both of your CoreMotion and CoreLocation libraries define "interfaces" in your concrete data type style - but there's a difference between the two libraries. The location library makes all of the method properties public, and has few actual func declarations.

public var accuracyAuthorization: () -> AccuracyAuthorization?

However, the motion library has non-public method properties and public func wrappers for those properties that take arguments.

var accelerometerData: (AnyHashable) -> AccelerometerData?
public func accelerometerData(id: AnyHashable) -> AccelerometerData? {
  self.accelerometerData(id)
}

This is nicer as it improves the call site by being able to use argument labels. But since the vars are not public, library users can't easily change the implementation.

Also, since you can't have a property with a no-arg lambda and a func with the same signature,

var f: () -> Void
func f() -> Void // <-- Invalid redeclaration of f()

it's easy to miss the need to make those public. For example, MotionManager's availableAttitudeReferenceFrames should probably be public.

In most respects I like the implementation in MotionManager better as it's a "cleaner" interface to use, but at the expense of the complete flexibility afforded by the LocationManager implementation and a lot more boilerplate.

Do you prefer one style over the other? Was it an intentional decision to keep the properties in MotionManager internal? Would you recommend this approach?