-preview=in might break code
Iain Buclaw
ibuclaw at gdcproject.org
Sun Oct 4 20:06:49 UTC 2020
On Sunday, 4 October 2020 at 19:26:56 UTC, Iain Buclaw wrote:
> On Sunday, 4 October 2020 at 16:10:42 UTC, Ola Fosheim Grøstad
> wrote:
>> On Sunday, 4 October 2020 at 14:58:13 UTC, Iain Buclaw wrote:
>>> As it is an optimization, I think that's best left to the
>>> interpretation of the compiler/compiler author, however
>>> optimizations should never break the semantic guarantee.
>>
>> What is the intended semantic guarantee in simple words that
>> makes sense to an end user?
>>
>> From what you say I assume it is something along the lines of:
>>
>> «Has const scope semantics. Values may be passed as
>> references. Parameter passing will not trigger sideeffects on
>> the actual or formal parameters.»
>>
>> However, do you also have this constraint:
>>
>> «The caller is responsible for ensuring that the actual
>> parameter does not alias with other parameters or globals
>> available to the called function.»
>>
>> And if not, what do you have?
>>
>
> The spec only explicitly states that non-POD types must *always
> be passed by reference*. So the only semantic guarantee is
> that copy constructors are elided.
>
Of course, I'm forgetting the other side of `in` due to everyone
only focusing on the `ref` part. :-)
The answer is yes on your mention of const scope semantics. If
I'd be pressed to bullet point it, I'd put down the following.
When an parameter is annotation with `in`:
- The parameter is not modifiable.
- All memory reachable from the parameter can not be clobbered
(overwritten).
- The parameter does not escape.
- Copy constructors are elided by passing by-ref.
- Other forms of copy elision may occur if doing so does not
change program behaviour.
Is that simple enough for an end-user?
More information about the Digitalmars-d
mailing list