What are (were) the most difficult parts of D?

[Ali Çehreli]

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