There are some cases where having a way to check if a proc is functional can be useful (e.g. A timeline editor which calls a function with animated inputs when you scrub the timeline).
Basically it would need to have the odin calling convention, be contextless, and no pointers allowed in the inputs or outputs (checked recursively).
This won’t handle the case where the procedure body reads a global, but that is hard to do on accident so it’s not as important.
A proper func() type which only allows calling other func types would be ideal, but imperative purists would get mad at me so I will refrain.
On the topic of functions with limited side-effects, limitting the import statements does limit the effects that file can do. So that might be one track to explore if you want to constrain your procedures to more pure functions.
Not sure if it is a good idea though. ^^"
I am guessing by “functional” you mean “side effect free”. And the answer is there is not one nor are we going to support such a thing. Odin is not a FP language but an unabashedly imperative procedural programming language.
I don’t really think the imperative vs functional dynamic makes sense in 2026 when every language has some combination of every feature from every paradigm. You could call tagged unions as sum types, and one could imagine arguing against including them in the language because it’s not imperative enough. Lamdas are another example, or first class functions in general. I’m not saying you have to include it in the language but I hope it being ‘functional’ is not the reason.
I don’t really think the imperative vs functional dynamic makes sense in 2026 when every language has some combination of every feature from every paradigm.
I get where you’re coming from, but Odin isn’t like most contemporary languages on this front as it’s fundamentally imperative by design and nature. “Functional” usually implies a declarative aspect, and for a lot of people it also implies things like “everything is an expression”, “no side effects”, or “immutability by default”, and Odin doesn’t have any of those aspects.
Odin’s tagged unions aren’t sum types in the algebraic sense. A sum type is a sum over the possible states of labelled (possibly non-unique) variants. Odin’s union is a set of unioned distinct types where the thing that discriminates them is the type itself, not a label. For many FP folks that distinction really matters, because the algebraic semantics end up being different. Add in the fact that Odin doesn’t have pattern matching, and it’s not likely to win over many FP fans, especially anyone coming from ML-style languages.
Odin’s procedure literals are another case that looks functional but isn’t really. They aren’t true higher-order functions: they don’t capture the parent scope. They’re essentially global-scoped procedures (so they can have side effects) that just happen to be nestable inside another procedure’s body. For a language to support such a construct with a unified procedure signature type, automatic memory management is required, and something Odin is never going to support.
So I don’t think there’d be any real benefit to adding the intrinsic you’re asking for as it just doesn’t fit how the language works.
More broadly, I’m not a fan of this push to merge the two paradigms. It tends to overlook the genuine benefits of an imperative, procedural approach and treats the functional approach as better by default for everything, which is objectively false.
For what it’s worth, I only throw out random ideas like these is because I know there is someone up top willing to say no. If this were a more democratic process, I would be more conservative. I hope it isn’t too annoying to deal with for you. That is a lot of text you had to write to explain your point.