Pitch: Implicit Pointer Conversion for C Interoperability

This discussion is obviously important and productive. But I'm perplexed by why this, of all proposals, is being used as a battleground for a the architecture of the type system and debate over a potential major new language feature.

This fixes a serious bug that's been known to block Swift adoption for years. I've been advocating this solution all along with no serious objection until now.

There's no valid alternative for programmers. This isn't about syntactic sugar to make regular Swift programmers happier. It's about language adoption for new Swift projects.

The implementation is obviously straightforward and self-contained. It does not introduce any measurable cost (a single check on the AST node). It does not complicate unrelated code or create any maintenance burden.

This does not introduce any new language rules. It merely exposes C language rules to the Swift compiler when invoking C.

This does not introduce any new implicit conversions in Swift. This fixes the existing UnsafePointer argument conversion to correctly apply Swift rules to Swift functions and C rules to C functions.

Unlike the proposal where this battle started, this does not propose generalizing existing implicit conversions to operators: Automatic Mutable Pointer Conversion - #32 by johnno1962

Arguments about social engineering are relevant to many things that have happened during Swift development, but they don't hold any water when comparing a real, visceral problem for Swift adopters to a hypothetical, theoretical gain for language maintainers.

17 Likes