@gpopides to Programmer [email protected] • 1 year agoBrought to you by the ocaml gangimagemessage-square13arrow-up1205arrow-down116
arrow-up1189arrow-down1imageBrought to you by the ocaml gang@gpopides to Programmer [email protected] • 1 year agomessage-square13
minus-square@FishFacelink13•1 year agoYeah but it doesn’t cross function boundaries so it’s more limited.
minus-square@[email protected]linkfedilink23•1 year agoIn other words, in OCaml, you don’t have to write type annotations into the function parameter list. It will infer even those. It’s useful for small ad-hoc functions, but personally, I’m glad that Rust is more explicit here.
minus-squarevoxellinkfedilink6•edit-21 year agoyeah structs, consts ets should always be explicit, prevents a lot oh headache also, for adhoc stuff rust has closures which can be fully inferred (but you need to convert them to explicit function pointers for storage in structs/consts)
minus-square@[email protected]linkfedilink4•edit-21 year agoIt’s not like it’s more limited, it’s just so that it can yell at you when you return not what you said you’re going to, IMO
minus-square@FishFacelink2•1 year agoOCaml allows you to specify return types, but doesn’t force you to.
Yeah but it doesn’t cross function boundaries so it’s more limited.
In other words, in OCaml, you don’t have to write type annotations into the function parameter list. It will infer even those.
It’s useful for small ad-hoc functions, but personally, I’m glad that Rust is more explicit here.
yeah structs, consts ets should always be explicit, prevents a lot oh headache
also, for adhoc stuff rust has closures which can be fully inferred (but you need to convert them to explicit function pointers for storage in structs/consts)
It’s not like it’s more limited, it’s just so that it can yell at you when you return not what you said you’re going to, IMO
OCaml allows you to specify return types, but doesn’t force you to.