RFC on range design for D2

[bearophile]

I don't have enough experience to have a clear view on the whole subject, so I write only some general comments:

1) In time I have seen that everyone that likes/loves language X wants D to become like X. This is true for Andrei too, you clearly like C++ a lot. The worse fault of C++ is excessive complexity, that's the single fault that's killing it, that has pushed people to invent Java, and so on. Walter has clearly tried hard to make D a less complex language. This means that D is sometimes less powerful that C++, and every smart programmer can see that it's less powerful, but having 15% less power is a good deal if you have 1/3 of the complexity. As you may guess I don't like C++ (even if I like its efficiency I'm not going to use it for real coding), so I don't like D to become just a resyntaxed C++. Note that originally D was more like a statically compiled Java, and while that's not perfect, that's probably better than a resyntaxed C++. So I suggest less power, if this decreases a lot what the programmer has to keep in the mind while programming. If you don't believe me take a look at what the blurb of D says:

>D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.<

As you see it's a matter of balance.

2) Keep in mind that not all D programmers are lovers of C++ and they don't all come from C++, some of them are actually lovers of other languages, like Java, C#, Python, Ruby, Lisp, etc. And as you may expect, they may want to push D to look more lisp, Python, C#, etc.

3) opApply has some problems, but it isn't infamous.

4) Syntax matters, and function/ method /attribute names too. So they have to be chosen with care. I suggest to use single words when possible, and to consider "alllowercase" names too (I know this contrasts with D style guide).

4b) Coping function/method/attribute names from C++ isn't bad if people think such names are good. Inventing different names just to be different is not good.

5) The source code of the current algorithm module of D2 is already very complex to follow, it smells of over-generalization here and there. Sometimes it's better to reduce the generality of things, even if that reduces their power a little, to reduce complexity, etc. Tango code too isn't perfect, but it often looks more human. While you have created the algorithm module I too have created something similar, but based on different grounds.

6) Built-in data types are important, they aren't meant to replace a good standard library, where you can find more specialized and more efficient data structures. The built-in data types are meant to:
- offer a very handy syntax, easy to use and remember, short to type too.
- They have to be efficient in a very wide variety of situations, so they must avoid having really bad peformance in a large number of situations, while it's okay for them to be not much fast in any situation.
- They are useful for example when you have little data, in 90% of the code where max performance isn't so important. In the other situations you are supposed able to import things like an IntrusiveRedBlackHashMap from the std lib.

7) Take a look at the lazy "views" of keys/values/items of Python3, how they fit into your view of such ranges. Java too has something similar. (I can give a summary if you want. But in few words if you have an associative array (dict) d.keys() doesn't return an array, but a "view", a lazy iterable that's an object that can be sliced lazily, iterated, etc. This is way more efficient than the .keys/.values of the currenct D implementation).

8) Lot of functions/thinghies in my mostly-functional library are designed to be lazy, that is they generate items on the fly. At the moment D lacks a *lot* such view of the world. Again, take a good look at how Python 3 has shifted from eager to lazy in lot of its style. How do such things fit in your range view? I think they can fit well, but the D language has to shift its phylosophy a little to support such lazy generators/iterators more often and commonly in the built-ins too.

9) I have a long discussion in the main D newsgroup, a partial conclusion was that a struct of 2 items may not be enough for the current implementation of dynamic arrays, because withot a capacity field, the append is dead-slow. I presume this is ortogonal to your range propostal, but I have mentioned it here because you keep talking about dynamic arrays as 2-pointer structs, and that may be changed in the future.

Bye,
bearophile