Skip to content
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

support overloaded operators in lvalues #2193

Closed
nikomatsakis opened this issue Apr 12, 2012 · 5 comments
Closed

support overloaded operators in lvalues #2193

nikomatsakis opened this issue Apr 12, 2012 · 5 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@nikomatsakis
Copy link
Contributor

You should be able to write:

foo[x] = y

which should translate to foo.[]=(x, y) or something like that. This would be great as an alias for the insert() function on maps. I can't think of any other overloadable operators that are valid in lvalues... do we allow unary * to be overloaded?

@boggle
Copy link
Contributor

boggle commented Apr 14, 2012

I kind of like ruby's append operator << (which in rust is reserved for lshift), maybe there is a nice alternative?

@graydon
Copy link
Contributor

graydon commented Apr 14, 2012

Not unary star, I think. Likewise not unary ampersand. Too close to the memory model. Same thinking as keeping assign, move, copy as non overloadable.

@nikomatsakis
Copy link
Contributor Author

An alternative we might consider is to make the call operator () overridable. There is a good argument for having maps (and possibly even vectors) be callable things. We would want to make them coercable to fn&() though. We could still allow foo(x) = y, although it looks odd.

@gwillen
Copy link
Contributor

gwillen commented Jun 27, 2012

I urge you to consider allowing the overload of []= as a special case, even if nobody can think of any other operators that need lhs overloading. This may be one of those cases where there's just one specific crucial bit of syntax. (I have been arguing with sully about the need for [] on hashtables, and I'm about to file a bug asking him to implement fn[] on hash tables, readonly for now.)

@bstrie
Copy link
Contributor

bstrie commented Jun 5, 2013

Closing in favor of #6515, since graydon has ruled against lvalue overloads other than indexing.

@bstrie bstrie closed this as completed Jun 5, 2013
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
do not use int2ptr casts in strict provenance tests
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
In some cases, like `-Zunpretty=expanded`, Rustc will print information to the stdout that is not in json format. For those cases, we should print the message as is.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

5 participants