What's happening with the `in` storage class

[Vijay Nayar]

On Saturday, 9 June 2018 at 02:38:14 UTC, SonicFreak94 wrote:
> On Saturday, 9 June 2018 at 02:17:18 UTC, Adam D. Ruppe wrote:
>> On Saturday, 9 June 2018 at 02:13:00 UTC, Walter Bright wrote:
>>> But it was never enforced, meaning that suddenly enforcing it 
>>> is just going to break code left and right.
>>
>>
>> It isn't going to break anything. It is going to *correctly 
>> diagnose already broken code*.
>>
>> That's a significant difference. Real world D users don't like 
>> broken code, but they DO like the compiler catching new bugs 
>> that slipped by before.
>
> I agree. I would rather my potentially broken code be pointed 
> out to me rather than removing the much more concise `in` from 
> my code. In any case, I feel as though the concept of both `in` 
> and `out` should be fairly intuitive. `in` would be a read-only 
> reference (C# has received this recently), and `out` is a 
> reference with the intention to write.

100% agreed.

I always found "in" to be consistent with what I view as one of 
D's core philosophies, that the simple thing should be the right 
thing.  For example, when you have a class parameter, it is 
automatically passed by reference without any other special 
considerations by the programmer.

To me, "in" has been a shorthand to communicate my desire to make 
sure that the parameter is treated strictly as an input, and not 
modified in any way or having ways to pass its reference to 
others who may then modify it.

Where I may be doing something wrong, a helpful message from the 
compiler is welcome.