5 ms·
Maybe I am missing some subtleity here, but isn't the whole point of the described proposed feature that you would be able to replicate the Python code pretty m
by krig 12y ago
Maybe I am missing some subtleity here, but isn't the whole point of the described proposed feature that you would be able to replicate the Python code pretty much exactly?
fn read_database() -> Result<Document, DatabaseError> {
let db = pgsql.connect(localhost)?
let stmt = db.prepare("INSERT INTO log VALUES(?,?)")?
stmt.execute(("debug", "Note to self: debug logs are noncritical"))?
}
So to have the handling code there as well, wrap it in an outer function (I have no idea if this is anywhere close to actual Rust):
fn read_database() {
fn reader() -> Result<Document, DatabaseError>
let db = pgsql.connect(localhost)?
let stmt = db.prepare("INSERT INTO log VALUES(?,?)")?
stmt.execute(("debug", "Note to self: debug logs are noncritical"))?
}
match reader() {
Document(d) => d,
DatabaseError(err) => println!("Could not write log to database {}", err)
}
}
- sergiosgc 12y agoNote my mention of the too-many-small-functions-with-one-caller(tm) smell. It refers to this solution.
- krig 12y agoI see, yes. Implementation-wise, I don't think this is a problem, the inner function can easily be inlined by the compiler. But language-wise I agree that it is somewhat ugly. Some kind of sugar over this kind of construction would be nice.
- sergiosgc 12y agoI was not thinking in terms of compilation result. My problem with this solution is readability. Functions get extracted in the name of reusability. When they are called just once, they do not serve that purpose, and just use space in the programmers mental map of the program. However, I imagine your type of solution could be used in a macro, like jeremyjh suggested in a parallel comment, producing simple code and the expected functionality.
- kybernetikos 12y ago> My problem with this solution is readability. Functions get extracted in the name of reusability In my opinion one of the biggest benefits of functions is the ability to name pieces of code. I've worked with a number of teams where a single line function with a single caller and a descriptive name is preferred to a line that needs a comment to say what it does.
- adrusi 12y agoIt would be inlined by the compiler, and the standard library could introduce a macro to eliminate the awkward code. try!({ let db = pgsql.connect(localhost)? let stmt = db.prepare("INSERT INTO log VALUES(?,?)")? stmt.execute(("debug", "Note to self: debug logs are noncritical"))? } catch err: DatabaseError { println!("Could not write log to database {}", err); }) ===> match (|| { let db = pgsql.connect(localhost)? let stmt = db.prepare("INSERT INTO log VALUES(?,?)")? stmt.execute(("debug", "Note to self: debug logs are noncritical"))? }) { Document(d) => d, DatabaseError(err) => println!("Could not write log to database {}", err) }
- ben0x539 12y agoClosures aren't "free", you need to structure your code around being unable to return/break/continue across the closure boundary, and there's probably some silly borrow checker errors involved too.