Convert index operator to be by value #23601
Conversation
|
(Hmm, something seems to have broken in the rebase. It WAS passing |
nikomatsakis
force-pushed
the
by-value-index
branch
from
5ca7257
to
bae844d
Compare
|
OK, fixed the problem I was seeing locally -- rerunning make check now. |
|
oh and cc @sfackler |
|
I'm not sure where we landed in discussion before. Longterm what's the strategy for recovering the old behaviour? |
|
ok, make check passes. |
|
@gankro if we want to recover the
I would prefer option 1 since I think we want to have optional auto-ref for (All that said, my experience has been that I find the autoref on (*) This may seem inconsistent with our conversation on IRC, since I think maybe (in retrospect) you were asking me about the prospects for "autoref" and I was saying "that's hard". There are indeed sometimes challenges about this sort of thing from inference; we'd have to see how well it works. But I think it'll work out ok in most cases, I guess. |
|
@bors: r+ bae844d |
|
☔ The latest upstream changes (presumably #23361) made this pull request unmergeable. Please resolve the merge conflicts. |
nikomatsakis
force-pushed
the
by-value-index
branch
from
bae844d
to
b760c56
Compare
|
@bors r=japaric b760c56 |
|
@bors p=1 important language change |
|
⌛ Testing commit b760c56 with merge 2aa6858... |
This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the `[]` operator, it is now necessary to borrow explicitly, so change `map[key]` to `map[&key]` (consistent with the `get` routine). However, indexing of string-valued maps with constant strings can now be written `map["abc"]`. r? @japaric cc @aturon @gankro
|
💔 Test failed - auto-mac-64-nopt-t |
|
@bors: retry this test failure makes no sense! |
|
☔ The latest upstream changes (presumably #23593) made this pull request unmergeable. Please resolve the merge conflicts. |
references. For collections whose keys are integers, we take both references and by-value.
`[]` on maps to `get` in rustc, since stage0 and stage1+ disagree about how to use `[]`.
nikomatsakis
force-pushed
the
by-value-index
branch
from
b760c56
to
57cf2de
Compare
This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the `[]` operator, it is now necessary to borrow explicitly, so change `map[key]` to `map[&key]` (consistent with the `get` routine). However, indexing of string-valued maps with constant strings can now be written `map["abc"]`. r? @japaric cc @aturon @gankro
|
⌛ Testing commit 57cf2de with merge beb33d4... |
|
⛄ The build was interrupted to prioritize another pull request. |
|
⌛ Testing commit 57cf2de with merge ffd5f00... |
|
⛄ The build was interrupted to prioritize another pull request. |
This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the `[]` operator, it is now necessary to borrow explicitly, so change `map[key]` to `map[&key]` (consistent with the `get` routine). However, indexing of string-valued maps with constant strings can now be written `map["abc"]`. r? @japaric cc @aturon @gankro
|
💔 Test failed - auto-linux-64-opt |
|
@bors: retry |
remove ?Sized bounds from Index I've noticed that we have an `Idx: ?Sized` bound on the **index** in the `Index`, which seems strange given that we accept index by value. My guess is that it was meant to be removed in #23601, but was overlooked. If I remove this bound, `./x.py src/libstd/ src/libcore/` passes, which means at least that this is not covered by test. I think there's three things we can do here: * run crater with the bound removed to check if there are any regressions, and merge this, to be consistent with other operator traits * run crater, get regressions, write a test for this with a note that "hey, we tried to fix it, its unfixable" * decide, in the light of by-value DSTs, that this is a feature rather than a bug, and add a test cc @rust-lang/libs EDIT: the forth alternative is that there exist a genuine reason why this is the case, but I failed to see it :D
Add test checking that Index<T: ?Sized> works I've noticed that we have an `Idx: ?Sized` bound on the **index** in the `Index`, which seems strange given that we accept index by value. My guess is that it was meant to be removed in #23601, but was overlooked. If I remove this bound, `./x.py src/libstd/ src/libcore/` passes, which means at least that this is not covered by test. I think there's three things we can do here: * run crater with the bound removed to check if there are any regressions, and merge this, to be consistent with other operator traits * run crater, get regressions, write a test for this with a note that "hey, we tried to fix it, its unfixable" * decide, in the light of by-value DSTs, that this is a feature rather than a bug, and add a test cc @rust-lang/libs EDIT: the forth alternative is that there exist a genuine reason why this is the case, but I failed to see it :D
This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the
[]operator, it is now necessary to borrow explicitly, so changemap[key]tomap[&key](consistent with thegetroutine). However, indexing of string-valued maps with constant strings can now be writtenmap["abc"].r? @japaric
cc @aturon @gankro