Bug 239481

Summary: Use more r-value references for Text / CharacterData classes
Product: WebKit Reporter: Chris Dumez <cdumez>
Component: DOMAssignee: Chris Dumez <cdumez>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, benjamin, calvaris, changseok, cmarcelo, darin, dino, eric.carlson, esprehn+autocc, ews-watchlist, fmalita, ggaren, gyuyoung.kim, kangil.han, mifenton, pdr, philipj, sabouhallawa, sam, schenney, sergio, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
ews-feeder: commit-queue-
Patch
none
Patch
none
Patch
none
Patch none

Chris Dumez
Reported 2022-04-18 21:34:36 PDT
Use more r-value references for Text / CharacterData classes.
Attachments
Patch (86.11 KB, patch)
2022-04-18 21:41 PDT, Chris Dumez
no flags
Patch (87.49 KB, patch)
2022-04-19 08:33 PDT, Chris Dumez
ews-feeder: commit-queue-
Patch (90.02 KB, patch)
2022-04-19 09:10 PDT, Chris Dumez
no flags
Patch (90.66 KB, patch)
2022-04-19 10:30 PDT, Chris Dumez
no flags
Patch (102.24 KB, patch)
2022-04-19 14:03 PDT, Chris Dumez
no flags
Patch (102.23 KB, patch)
2022-04-19 19:26 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2022-04-18 21:41:27 PDT
Chris Dumez
Comment 2 2022-04-19 08:33:58 PDT
Chris Dumez
Comment 3 2022-04-19 09:10:31 PDT
Chris Dumez
Comment 4 2022-04-19 10:30:58 PDT
Chris Dumez
Comment 5 2022-04-19 14:03:16 PDT
Sam Weinig
Comment 6 2022-04-19 18:25:57 PDT
Comment on attachment 457935 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=457935&action=review > Source/WebCore/dom/CDATASection.h:32 > + static Ref<CDATASection> create(Document&, String&&); I have come to the concluding that just using "String", no "&&" is better in cases like this, and has the same behavior, because it will work for both l-values and r-values equally well. If this were a template function, the && would make it a universal reference, which would be even more general, but not useful for things like this. The downside of not using "String&&" is that it is harder to find people who might be doing the wrong thing, which might be a big enough reason to keep && in these cases.
Chris Dumez
Comment 7 2022-04-19 18:29:42 PDT
(In reply to Sam Weinig from comment #6) > Comment on attachment 457935 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=457935&action=review > > > Source/WebCore/dom/CDATASection.h:32 > > + static Ref<CDATASection> create(Document&, String&&); > > I have come to the concluding that just using "String", no "&&" is better in > cases like this, and has the same behavior, because it will work for both > l-values and r-values equally well. > > If this were a template function, the && would make it a universal > reference, which would be even more general, but not useful for things like > this. > > The downside of not using "String&&" is that it is harder to find people who > might be doing the wrong thing, which might be a big enough reason to keep > && in these cases. I feel pretty strongly against using just "String" personally :/ I think it looks confusing and it makes it likely callers will fail/forget to "move" and we'll end up calling the copy constructor. Yes, people can write efficient code with just "String" but in my opinion, they are unlikely too. "String&&" forces people to do the right thing.
Chris Dumez
Comment 8 2022-04-19 18:30:07 PDT
(In reply to Chris Dumez from comment #7) > (In reply to Sam Weinig from comment #6) > > Comment on attachment 457935 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=457935&action=review > > > > > Source/WebCore/dom/CDATASection.h:32 > > > + static Ref<CDATASection> create(Document&, String&&); > > > > I have come to the concluding that just using "String", no "&&" is better in > > cases like this, and has the same behavior, because it will work for both > > l-values and r-values equally well. > > > > If this were a template function, the && would make it a universal > > reference, which would be even more general, but not useful for things like > > this. > > > > The downside of not using "String&&" is that it is harder to find people who > > might be doing the wrong thing, which might be a big enough reason to keep > > && in these cases. > > I feel pretty strongly against using just "String" personally :/ > I think it looks confusing and it makes it likely callers will fail/forget > to "move" and we'll end up calling the copy constructor. > > Yes, people can write efficient code with just "String" but in my opinion, > they are unlikely too. "String&&" forces people to do the right thing. *unlikely to
Chris Dumez
Comment 9 2022-04-19 19:26:18 PDT
Chris Dumez
Comment 10 2022-04-19 20:06:00 PDT
Comment on attachment 457950 [details] Patch Clearing flags on attachment: 457950 Committed r293059 (249790@trunk): <https://commits.webkit.org/249790@trunk>
Chris Dumez
Comment 11 2022-04-19 20:06:04 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 12 2022-04-19 20:07:17 PDT
Note You need to log in before you can comment on or make changes to this bug.