# Trait operators / macro traits

**URL:** <https://internals.rust-lang.org/t/trait-operators-macro-traits/17369>\
**Category:** language design\
**Created:** [September 11, 2022, 11:38am UTC](https://internals.rust-lang.org/t/trait-operators-macro-traits/17369 "2022-09-11T11:38:33Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![mathstuf](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@mathstuf](https://internals.rust-lang.org/u/mathstuf)\
**Post date:** [September 11, 2022, 9:13pm UTC](https://internals.rust-lang.org/t/trait-operators-macro-traits/17369/7 "2022-09-11T21:13:45Z")

</div>

My observations aren't about your specific examples. I did use your examples in questions that arise (namely with the precedence, associativity, and ambiguity), but this is something inherent to the idea. To be a custom operator there has to be some syntax a the usage site. There's the possibility of the Haskell ``opname``syntax that I think no one would like in practice, though ``opname` does show up in one of the threads linked below..

> [@Miiao](#):
>
> I want rustaceans to take a look at this and discuss.

And are we not discussing it? There is little provided on the "pro" side right now, sure, but who do you think should provide such information?

> [@Miiao](#):
>
> Please, I beg you, see beyond your nose and read my messages

I did read it. Have you researched prior discussions about custom operators on here? It happens fairly regularly and the problems are almost never about how to declare such things, but how it'd actually work in Rust regardless of how you end up spelling any declarations in the code.

Some samples (some of which are about _specific_ operators still causing problems, nevermind arbitrary ones):

> [@What is wrong with auto .into?](https://internals.rust-lang.org/t/what-is-wrong-with-auto-into/17319/33):
>
> Just curious, when turn a str to String, why not do a lazy allocation. I believe a lazy allocation can avoid 80% of the allocation. Since most of the time, the string will not be changed anyway.

> [@Add operator @ for matrix multiplication](https://internals.rust-lang.org/t/add-operator-for-matrix-multiplication/16026):
>
> Python chooses @ for matrix multiplication. How about also giving it to rustaceans?

> [@How about a new operator?](https://internals.rust-lang.org/t/how-about-a-new-operator/17322):
>
> Borrowed from c#. Which means: unwrap\_or\_else Personally I really miss it. C.unwrap\_or\_else(||5) Vs c ?? 5

> [@Method-cascading and pipe-forward operators proposal](https://internals.rust-lang.org/t/method-cascading-and-pipe-forward-operators-proposal/7384):
>
> In this topic I want to draw attention, show purpose and share initial idea about syntax for them. Before reading, note: I’m just an enthusiast - don’t take that too seriously and don’t be too critical if something wrong; prepare to bad English. [Jump to second version](https://internals.rust-lang.org/t/method-cascading-and-pipe-forward-operators-proposal/7384/51) - text below is not actual It consists of two parts because in my proposal both are related and second can be combined with first to cover additional use case. Also, both have different syntax from one that may be found in ot…

> [@When will Rust adopt the syntax of pipline operator "|\>" in ocaml](https://internals.rust-lang.org/t/when-will-rust-adopt-the-syntax-of-pipline-operator-in-ocaml/17191):
>
> When will Rust adopt the syntax of pipline operator "|\>" in ocaml

> [@(Mathematical) modulo operator](https://internals.rust-lang.org/t/mathematical-modulo-operator/5952):
>
> Rust currently has a remainder operator in the form of %, which behaves as the operator of the same symbol does in languages like C or Java. It is also similar to the modulo operator found in languages such as Python or Haskell, except for its behaviour for negative arguments – remainder is based on truncating division, whereas modulo is based on flooring division. In the vast majority of cases whilst programming (see [http://dl.acm.org/citation.cfm?doid=128861.128862](http://dl.acm.org/citation.cfm?doid=128861.128862)), the behaviour of the modu…

> [@Yoric](#):
>
> I don't remember seeing the feature used in non-trivial Haskell code either, but my experience of Haskell is more limited.

I've mainly seen it in code like `container `contains` item ` where the "operator" reads well in English with its argument order.

---

_[View the full topic](https://internals.rust-lang.org/t/trait-operators-macro-traits/17369)._
