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

[Michael Ilseman]

> On Mar 15, 2016, at 5:12 PM, Michel Fortin via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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.
> 

There’s two things present in this proposal, manual annotation and automatic inference. Projects such as sqlite3 can use manual annotation, so that they can control their APIs and have a chance to import e.g. sqlite3_stmt_readonly as a member on a type (perhaps also named/defined otherwise, e.g. through existing attributes or other proposed elsewhere).

Automatic inference, at least in the near term, will not be turned on by default for all C APIs, but will start out as opt-in. In the near term, heuristics and techniques are tuned for CF-style naming conventions. Future work could be broadening this, and I think having something to also reason through snake_case is definitely possible. Future work could expand the inference system to have many more (configurable) heuristics, but that’s out of scope for this proposal. But, unless the project opts-in, the inference system will not try to infer how to import as a member.

> 
>> 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?
> 
> N/A
> 
> 
>> 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.
> 

I am very interested in improving non-Apple C APIs as well. I’m not sure how much will be in scope for Swift 3, though.

> 
> -- 
> Michel Fortin
> https://michelf.ca
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution