-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[stdlib][Discussion] Implement operator
module
#2924
Comments
Idea: If we were to introduce traits to each operator, could we name them I'm not suggesting that we change what we have, which are perfectly good (like |
In python, some functions are only available in the |
idea: And somehow make this even shorter? trait CanCollect(CanCopy, CanMove, CanDelete):
... feels more natural fn some_func[T: CanMove | CanCopy](somthing: T):
@parameter
if T.can[CanCopy]():
...
else:
... |
+1
Also +1, I like the expression "syntactic traits" for this. I think we would use these to build common compositions that some types would actually conform to explicitly (t.g. |
Regarding testing, what if we have things like this: struct MockLessThan(HasLessThan):
fn __lt__(self, other: Self) -> Bool:
return True
def test_less_than():
var m = MockLessThan()
var r = m.__lt__(m)
assert_true(_type_is_eq[__type_of(r), Bool]())
assert_true(r) I'm looking for minimal ways to "glue" these traits and their methods in the module, so that we don't accidentally move/remove them. |
I sitll think I like the idea of having these base traits a lot because once we are able to do |
It might make sense to just use the dunder method name as the trait name. So there could be an |
Hmmm... although it's not explicitly stated in the style guide, to my understanding, the convention is camel case for types and traits. Also, say for example that |
I'm not sure why you're talking about renaming
That's what a single leading underscore means. I'm not set on any particular naming scheme. I'm just sharing some ideas. |
As part of a larger effort to clean up and open source the
math
module, we have removed a number of functions that would mirror arithmetic operators. In most cases, the value of these functions is limited, since the operators can (and in fact should) be used directly, e.g.However, for code that passes around these as function pointers or parameters, it might be convenient to import these from a central module rather than having to define wrappers for each of these. Python's
operator
exists for slightly different reasons, but IMO it sets a pretty clear precedent and has a clear scope. The main difference I envision compared to Python is that in Mojo we probably want a trait for each of these methods. Consequently, this could be a natural place forAbsable
(and others) to live in, instead of being a builtin and implicitly imported everywhere. This is another reason why I'm considering work on this module: declaring these traits in a single place would make it easier to compose them, and build more complex abstraction on top of them.Are there any concerns with this? I am also looking for ideas on how to test these: the tests should not rely on particular implementations of these methods (e.g. those of
Int
's).To be clear, this is not very high priority for the stdlib team, but since it's a self-contained, relatively simple, and fairly well defined module, it would be something that the community could work on, if we decide to move forward with it. In particular, seems like this might include many "good first issue" type tasks.
The text was updated successfully, but these errors were encountered: