Revert "Explicitly implement copy ctor/assignment operator for IndexedDBKey"

Revert "Explicitly implement copy ctor/assignment operator for IndexedDBKey"

This reverts commit 662e95081cfe6aa20be3a367d7e12b71f9d790b3.

Original commit: https://codereview.chromium.org/136853003

BUG=333205
Committed: https://crrev.com/a7703f15c24dfbd4418cb051c4c7547102312d3f
Cr-Commit-Position: refs/heads/master@{#292645}

[Andrew Hayden (chromium.org), 2014-08-26 14:04:39]

andrewhayden@chromium.org changed reviewers:
+ jsbell@chromium.org

[Andrew Hayden (chromium.org), 2014-08-27 10:58:44]

jsbell@: Please take a look.

[jsbell, 2014-08-27 17:15:05]

change l*g*t*m, but what's the motivation?

These were put in when we believed that, overall, there'd be a decrease in
binary size if we prevented the auto-generated versions. We've since backed off
on that, but per the original commit, I did measure and see a slight improvement
in binary size. 

Having the ctor/operator explicitly implemented also appears to be required by
the style guide if the types will e.g. be stored in STL containers (which these
are, IIRC).

So... why the revert?

[jsbell, 2014-08-27 17:16:53]

On 2014/08/27 17:15:05, jsbell wrote:
> change l*g*t*m, but what's the motivation?

Okay, actually looked at the linked bug. Seems like there's thinking that
explicit operators may make the binary size worse with clang. Has that been
measured here? If we're now promoting relying on autogenerated ctor/operator
here, should we update the style guide?

[Andrew Hayden (chromium.org), 2014-08-29 12:16:15]

On 2014/08/27 17:16:53, jsbell wrote:
> On 2014/08/27 17:15:05, jsbell wrote:
> > change l*g*t*m, but what's the motivation?
> 
> Okay, actually looked at the linked bug. Seems like there's thinking that
> explicit operators may make the binary size worse with clang. Has that been
> measured here? If we're now promoting relying on autogenerated ctor/operator
> here, should we update the style guide?

I think the general idea here is that we shouldn't introduce just one small
piece of what was supposed to have been a broader refactoring; doing so
encourages copying and pasting the code, which means more code to maintain and
more chances for bugs with questionable benefits that appear to vary for
different observers depending upon the combination of [platform, build type,
compiler] (and maybe more). I think we should save further discussion for the
bug, which is a better place to record decisionmaking IMO.

I'll go ahead and land this for now; we can always re-revert, but at least this
puts us back at the state we were in before we started tinkering.

[Andrew Hayden (chromium.org), 2014-08-29 12:16:49]

(jsbell: can you give a real ell-gee-tee-emm?)

[jsbell, 2014-08-29 14:05:38]

lgtm

[Andrew Hayden (chromium.org), 2014-08-29 14:18:43]

On 2014/08/29 14:05:38, jsbell wrote:
> lgtm

PS, for posterity, in no way am I passing judgment here - I think it's great
that you researched this and as someone who has been looking into binary size
for the past 10 months or so I want to say explicitly: thank you. Binary size is
a pain to tackle for exactly the reasons we've run into here, namely that after
the compilers and linkers get done mangling the code beyond recognition it can
be VERY HARD to definitively answer what is a seemingly simple question: "is
this an improvement?"

So, thank you for the investigation and please don't hesitate to try more stuff
in the future.

[Andrew Hayden (chromium.org), 2014-08-29 14:18:50]

The CQ bit was checked by andrewhayden@chromium.org

[commit-bot: I haz the power, 2014-08-29 14:19:38]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/andrewhayden@chromium.org/473003003/1

[commit-bot: I haz the power, 2014-08-29 15:23:38]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_chromium_x64_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[jsbell, 2014-08-29 16:09:04]

Thanks for the PS! I just wanted to make sure it wasn't a reflexive "Revert ALL
the things!"

[commit-bot: I haz the power, 2014-08-29 16:18:24]

Committed patchset #1 (id:1) as 0a7aef01b1460ef286cd108cbf52306dd644aee5

[Daniel Bratell, 2014-09-01 07:32:40]

On 2014/08/29 16:18:24, I haz the power (commit-bot) wrote:
> Committed patchset #1 (id:1) as 0a7aef01b1460ef286cd108cbf52306dd644aee5

Found this because cq posted in the bug.

I'm missing the answer to why this is a good change. Does it make chromium
faster or smaller?

andrewhayden said "I think the general idea ... is ..." which makes it sound
like you don't know why you're doing it yourself.

[Andrew Hayden (chromium.org), 2014-09-01 14:28:05]

On 2014/09/01 07:32:40, Daniel Bratell wrote:
> On 2014/08/29 16:18:24, I haz the power (commit-bot) wrote:
> > Committed patchset #1 (id:1) as 0a7aef01b1460ef286cd108cbf52306dd644aee5
> 
> Found this because cq posted in the bug.
> 
> I'm missing the answer to why this is a good change. Does it make chromium
> faster or smaller?
> 
> andrewhayden said "I think the general idea ... is ..." which makes it sound
> like you don't know why you're doing it yourself.

Daniel,

Please add this discussion to the linked bug instead.

[commit-bot: I haz the power, 2014-09-10 03:09:02]

Patchset 1 (id:??) landed as
https://crrev.com/a7703f15c24dfbd4418cb051c4c7547102312d3f
Cr-Commit-Position: refs/heads/master@{#292645}