On 6/11/18 9:11 AM, Steven Schveighoffer wrote:
> For a while, phobos was partly compiled with dip1000 and it was a disaster.

I should say, this was only for unittests. Normal release was done without dip1000.

-Steve

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.