-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