Re: Why don't all initialising assignments use 'build-in-place' ?

[Rod Kay <rodakay5@gmail.com>]

On 25/3/23 19:39, Randy Brukardt wrote:
> "Rod Kay" <rodakay5@gmail.com> wrote in message
> news:tvc6j9$3gfe$1@dont-email.me...
>> Hello again,
>>
>>     I'm sure there must be a good reason. All I can think of is that it may
>> somehow break backwards compatibility wrt controlled types (a vague stab
>> in the dark).
>>
>>     Any thoughts ?
> 
> (1) Didn't want to make work for implementers.
> (2) You shouldn't be able to tell (since it is required for all cases
> involved finalization). Finalization is the only way to inject user-defined
> code into the initialization process.
> (3) True build-in-place can be expensive and complex (especially for array
> types).
> (4) Build-in-place requires functions compiled to support it (must pass in
> the place to initialize into). That might not be the case (especially if a
> foreign convention is involved). Also see (3) - an implementation might have
> a cheaper way to return some types that doesn't support build-in-place.
> 
> There's probably more, those are off the top of my head. If it is cheap, it
> would be silly for an implementation to do anything else. (Don't ask what
> Janus/Ada does. ;-) Otherwise, most people want the fastest possible code.
> 
>                         Randy.
> 
> 
> 

    Thanks, Randy. I somehow imagined that build-in-place would be 
faster :/.

    So using 'extended return' *everywhere* would decrease performance, 
I guess.


Cheers.