On 5/11/22 18:06, Christopher Katko wrote:
> Cool useful library functions like sumElement that magically don't work
> on static arrays.
Yeah, that sometimes gets me as well. Although it is trivial to deal
with, the programmer may be surprised by the strange error messages:
int[3] arr = [ 1, 2, 3 ];
assert(sum(arr) == 6);
Error: template `std.algorithm.iteration.sum` cannot deduce function
from argument types `!()(int[3])`
/usr/include/dlang/dmd/std/algorithm/iteration.d(7234):
Candidates are: `sum(R)(R r)`
with `R = int[3]`
must satisfy the following constraint:
` isInputRange!R`
WHAT? :) But the clue is on the last line above.
For completeness and for people who may not know the reason, D's static
arrays and dynamic arrays are different in a number of ways but what
matters here is that static arrays are not ranges because they cannot
shrink. (Arguably, static arrays could be RandomAccessRanges but D's
range hierarchy does not allow RandomAccessRanges that are not also
InputRanges and ForwardRanges.)
So, the commented-out assert below cannot be compiled but the two
following lines do compile by simply adding the two characters [] to get
a range to all elements:
import std.algorithm;
void main() {
int[3] arr = [ 1, 2, 3 ];
// assert(sum(arr) == 6);
assert(sum(arr[]) == 6);
assert(arr[].sum == 6);
}
> 'private' is per module, not per class, making it pretty much useless
> for preventing incorrect access and using .
My view on private has changed over the years. I need to be convinced
that there is usage that needs to be protected. :) I don't see people
using types freely especially the ones that are in the same module. The
only argument for private is to allow changing the implementation of
published libraries in the future.
Still, private could have been a convention like naming variables with
an underscore (which Go chose) and it could have been as effective.
People who went around the convention and accessed the private members
would either be happy or deserved what they got. I really don't see any
problem on this matter for a programming language to go out of their way
to protect people from themselves.
I started wondering as I wrote those: Perhaps IDEs make this a bigger
issue? If they do respect private/public, perhaps they include member
names in menus to pick from and the programmer does not want to see the
private members there?
> I just realized foreach copies by value by default. Maybe. Sometimes.
> When?
It is always by-value when passing parameters and in foreach (which can
be defined by opApply) and everywhere else. As Steve said, the confusion
is when the copied thing is a reference itself. You end up getting
another reference to data.
Ali
