What features of Odin do you dislike?

General
142

I very much agree with this one.

Another approach for naming functions of modules could be similar to how SDL names its functions, where instead of:

module_do_something()

you would write the module in all caps as:

MODULE_do_something()

Not the prettiest either but it’s much better for readability than an ambiguous name that does not immediately and clearly separates the action from the object.

For me personally, I usually like organizing my code by modules where each module that is large enough to warrant its own folder-subfolder structure (say for example a renderer module that handles Vulkan on multiple platforms or an ECS module) has its own folder-subfolder structure.
In such cases simply prefixing the function names with MODULE_ doesn’t fully address this, as Odin expects you to put all source files flat in the same folder / package.

I could make it into a package of course, but unless I go out of my way to make it entirely project agnostic to warrant being considered a standalone library (as cyclical dependencies are forbidden), it’s not worth the risk of finding out there are more dependencies than I’ve initially thought and having to refactor a bunch of code.

Maybe that’s just a sign of me being a bad developer though, who knows. :^)

I wonder if a mix of collections for file organization and something like the OBJECT_action(); naming convention are a potential answer to this, though I could be very off-base :sweat_smile:

I am still very much new with Odin though so take my opinion with a grain of salt*

143

I would like it if I didn’t need to manually type the type of a parametric argument when calling a parametric proc.

For example in my codebase I have the proc:

window_eval :: proc(win: ^Window, function: Eval_Function($T), args: T, callback: Eval_Callback) { ... }

When calling it must specify the type of args, even though it can be safely inferred from the call:

// must:
webapp.window_eval(win, func, Resolve_Args{id, value}, cb)
Resolve_Args{id, value}, cb)

// want:
webapp.window_eval(win, func, {id, value}, cb)
144

This a technical problem with how parametric polymorphism works, and it’s probably never going to be “fixed”. Part of the reason for never “fixing” this is to keep the type inference system sane and fast. If I was wanting to solve this in the general case, I can see edge cases which would become O(N!) to find the best fit, and I do not want to make the same mistakes as Swift.

2 Likes
145

Not really a dislike, more an improvement suggestion.

I wish Odin implemented multi cases matches switch like in Swift.

IMHO it’s a good way to lower the cognitive load in the code. It really helps clean the code and understand the logic instead of stacking if / switch statements everywhere.

146

Odin is never getting “pattern matching”, which that is effectively one step from.