> On Mar 15, 2016, at 5:12 PM, Michel Fortin via swift-evolution > <swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
