SE-189 Impact: Implementing Default Struct Initializers?

I have a simple type:

public struct Location: Decodable {
    public let coordinate: CLLocationCoordinate2D
    public let speed: CLLocationSpeed
    public let heading: CLLocationDirection
}

It has no public initializer, as it’s only ever created from network responses and my app has no need to create them directly. However, I do want to be able to test with preset values, so I have an extension in my test target:

extension Location {
    init(coordinate: CLLocationCoordinate2D = .mine, speed: CLLocationSpeed = 30, heading: CLLocationDirection = 0) {
        self.coordinate = coordinate
        self.speed = speed
        self.heading = heading
    }
}

Under Swift 4.1, with 0189 in effect, I get the warning Initializer for struct 'Location' must use "self.init(...)" or "self = ..." because it is not in module 'Networking'. Without thinking I refactored to call the suggested self.init(...), self.init(coordinate: coordinate, speed: speed, heading: heading). Unfortunately, this is circular, leading to a crash. Even if I did have a public memberwise initializer, there would still be ambiguity.

What’s the solution here? Do I really need to maintain public initializers within my Networking framework that will only ever be used for testing? Could a change be made to prevent the warning when there are no public initializers? If nothing else, shouldn’t the warning message be different if the type has no public initializers at all?

Looking at the proposal again, it looks like this was an anticipated concern, with internal initializers with @testable imports being recommended. So I guess this is really just a diagnostic issue.

It is rather annoying to not be able to make initializing these types impossible inside my framework, but I guess it’s manageable for now.

And of course attempting to make my defaulted initializers internal conflicts with the automatically generated initializer. So I can either make them make functions or declare them in the primary type declaration, which is awkward since they’re internal to other types.

That testing behavior mentioned in the proposal? I think we’re going to want it.