[jrmg]

I think there may be a difference in thinking that underlies the difference in opinion here.

In my experience, having a header file nudges you to think about interface being a _different thing_ to implementation - something that (because you need to) you think about as more fundamentally separate from the implementation.

Folks who think this way bristle at the idea that interface be generated using tooling. The interface is not an artifact of the implementation - it’s a separate, deliberate, and for some even more important thing. It makes no sense to them that it be generated from the implementation source - that’s an obvious inversion of priority.

Of course, the reverse is also true - for folks used to auto-generated docs, they bristle at the idea that the interface is not generated from the one true source of truth - the implementation source. To them it’s just a reflection of the implementation and it makes no sense to do ‘duplicate’ work to maintain it.

Working in languages with or without separate interface files nudges people into either camp over time, and they forget what it’s like to think in the other way.

[estebank]

This thread feels weird to me because when I write code I do think about my public API, have even sketched it out separately looking at the desired usage pattern, but never felt the need to save that sketch as anything other than as part of the documentation. Which lives next to the code that implements that API.

I think it is telling that the handful of languages that still have something akin to .h files use them purely to define cross-language APIs.

[juped]

I would generate implementations from interfaces were it possible, but I never want to generate interfaces from implementations.

[kode-tar-gz]

Why not?