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.
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.