6 ms·
Is it just me that doesnt like automatically returning the last statement in functions? It makes it hard to see where a function returns, and I dont see how you
by voidUpdate 4mo ago
Is it just me that doesnt like automatically returning the last statement in functions? It makes it hard to see where a function returns, and I dont see how you would do a guard clause at the start of a function without having the entire rest of the function in an else block
- rtpg 4mo agoI remember really bumping up against this learning OCaml in college after having experienced oodles of imperative programming. I understand the sort of philosophy and ergonomics of not having an early return, but it really does hurt certain kinds of code that otherwise would be more readable
- orthoxerox 4mo ago> ergonomics of not having an early return I wonder who came up with this idea first. I find obvious early returns incredibly ergonomic.
- voidUpdate 4mo agoWikipedia says that "guard clause" was a term invented by Kent Beck, but that the actual practice was used since at least the early 60s
- orthoxerox 4mo agoNo, I meant the idea that guard clauses are antipatterns and your subroutine should have a single implicit return.
- voidUpdate 4mo agoSorry, I misread. Need more coffee
- bjoli 4mo agoI think it is much more obvious than being able to return from anywhere in a function. If the last expression is a match, I know every match body must return the same type. if the last is a (cond ...) I know ever cond branch must return a value. I vastly prefer that.
- zdragnar 4mo agoI suspect the idea would be to use `match` instead of an imperative `if`. There's an example here: https://github.com/kablorp/blorp/blob/main/benchmarks/blorp/sleep_fanout.brp#L8 https://github.com/kablorp/blorp/blob/main/benchmarks/blorp/... Then again, there's really not too many examples of early return guards, but I did manage to find one where the body is stuffed in an `else`: https://github.com/kablorp/blorp/blob/main/benchmarks/blorp/binary_trees.brp#L16 https://github.com/kablorp/blorp/blob/main/benchmarks/blorp/... It does make me think that the usual types of guards might typically happen higher up (handled by the caller) or hidden with safe / monadic type operators that simply pass through rather than bailing out, so to speak.
- troupo 4mo agoIf it's inconsistently applied, yes. In most functional languages however you can view the end of any statement/expression as a return/assign which makes it very easy and trivial to assign anything to variables, or split anything into function calls.