DIP 1014

[a11e99z]

On Wednesday, 3 July 2019 at 11:18:20 UTC, aliak wrote:
> On Wednesday, 3 July 2019 at 09:31:38 UTC, RazvanN wrote:
>> On Wednesday, 3 July 2019 at 08:27:49 UTC, RazvanN wrote:
>>
>> Also there is the problem of typechecking the move operator as 
>> a function.Let's take a look at a slightly modified version of 
>> the example that Shachar provided:
>>
> Is there any situation where a move-related hook will do 
> anything other than "fix" indirections in the destination of 
> the move?

copy constructor or copy+postblit can be very expensive 
operations in some cases, and I am in doubt that compiler 
generate code only with copy without some move/memmoves.
auto x = fun(); // a move may occur
so at code generation levels in any case we have move/memmove 
operations, why not pull out it to user level where user can 
control it in some cases more predictably and easily?

for some interop projects (like DPP 
https://dlang.org/blog/2019/04/08/project-highlight-dpp/ ) it can 
be helpful too: std::string uses Small String Optimization 
technique https://stackoverflow.com/a/28003328 with video about 
GCC string and fbstring https://youtu.be/kPR8h4-qZdk?t=654 
(CppCon 2016: Nicholas Ormrod “The strange details of std::string 
at Facebook") - I just pointed to fbstring internals that most 
probably used as Clang strings (from SO answer), but M$ and GCC 
uses some kind of GCC ver>=5 string internals (find it in video 
too)

probably it can be tied with DIP 1021 (Borrowing and Ownership) - 
when code doesn't contains another refs to object compiler can 
just move the one without expensive copy/constructor/destructor.

nobody can assure (wrong word meaning? idk English) that "move" 
don't needed at all.
so lets add it with user friendly details control.