Replies: 1 comment 1 reply
-
I'm not sure where you're getting this idea, because Odin not only supports them, but they're even required in some cases (e.g. after a vararg) I guess you mean that Odin doesn't like polymorphic parameters with defaults? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
I've recently discovered Odin and wanted to try out how good the genericity was, but I noticed a few things.
First, optional parameters for procedures aren't a thing, and I don't know if they ever will be since golang seems to have been a significant source of inspiration and it does not allow these, please correct me if you have information about that but despite looking through the documentation and searching for an answer I have not found anything suggesting any particular stance of the creator(s) towards any response to that question
Second, the documentation, unless I'm mistaken, does not mention unions of procedures, but the checker during my tests hasn't prevented me from declaring some so I figured I might as well try to do something with them, particularly circumvent the aforementioned lack of optional parameters
So I went and tried to do a basic generic forEach procedure taking a generic slice as a first argument, and a generic second argument that specializes into a union of a procedure that either takes two arguments, one for value one for index, or just one for value, as so to allow to iterate on a slice and run callbacks, with prototypes varying depending on the needs, on each values.
However, the checker didn't like it, here is the code :
And the error is on the callback passed to the forEach in the main and is "Cannot determine polymorphic type from parameter: 'proc(string)' to '$U/union {proc(string), proc(string, int)}'(checker)".
I then started to wonder if this was unallowed by design or if could be a missing "feature" in the current state of the language, so I also rewrote the same function using explicit overloading to figure out the answer :
And it turns out that it works, the program outputting "1\n2\n3\n" just as intended.
So to conclude I suppose that this kind of pattern that allows to have polymorphic callback parameters is not "forbidden" by design, and I am therefore wondering if I am completely mistaken about the syntax of my first implementation, or if I may have found some kind of bug
I have already done extensive research and couldn't find anything regarding this kind of issue, and would be very grateful if anyone could provide an answer
Thank you for your time
Beta Was this translation helpful? Give feedback.
All reactions