[swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

Michel Fortin michel.fortin at michelf.ca
Tue Mar 15 19:12:44 CDT 2016

> What is your evaluation of the proposal?

Looks like a very good idea. Less wrapper code means less possibility of an error, a less cluttered call stack when debugging, and faster compile times (because of less code).

It looks like it'll work well for importing Apple headers. I'm a bit worried however about what it'll do for APIs that have a different design or syntax conventions. What happens with this function for instance?

	int sqlite3_stmt_readonly(sqlite3_stmt *pStmt);

Reading the proposal, it isn't all that clear where it stops. Does automatic inference work with snake-case? Should it? Does it import functions with unmanaged pointers in the first position as mutating methods? Hopefully not. Is this going to make some APIs seemingly inconsistent as to what becomes a member and what stays global? Probably. I can't tell really from reading the proposal.

> Is the problem being addressed significant enough to warrant a change to Swift?

It makes code more readable, less alien in a Swift program, and by having less wrapper code it just makes everything simpler. I think that is an important improvement.

> Does this proposal fit well with the feel and direction of Swift?

It fits very well with the path taken for renaming Objective-C methods to have more Swifty names. Swift 3 seems to be the right release for this change.

> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?


> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading, then looked at some non-Apple C APIs trying to figure out what the automatic inference heuristics would do to them.

Michel Fortin

More information about the swift-evolution mailing list