-preview=in might break code

Daniel N no at public.email
Sat Oct 3 08:51:26 UTC 2020


On Friday, 2 October 2020 at 23:03:49 UTC, Ola Fosheim Grøstad 
wrote:
> On Friday, 2 October 2020 at 22:46:11 UTC, tsbockman wrote:
>> On Friday, 2 October 2020 at 22:27:33 UTC, Ola Fosheim Grøstad 
>> wrote:
>> As I said earlier in this thread, if people are very worried 
>> about the undefined behavior, then perhaps the cases which are 
>> not proven by the compiler to have the same effect should be 
>> @system. There are essential features in D already that cannot 
>> be verified by the compiler; that's what @system is for.
>
> I have no issues with undefined behaviour as long as it is easy 
> to understand and explain, like requiring 'in' params to be 
> nonaliased in the function body. It has to be easy to grok and 
> remember.
>
> However the D community tends to want D to distinguish itself 
> from c++ in this regard.

How about this?

You can freely mix any number of 'in' and 'out' parameters and 
keep the optimized behavior.

As soon as you add any 'ref' parameter 'in' will pass by value.



More information about the Digitalmars-d mailing list