python vs d

[bearophile via Digitalmars-d]

John Colvin:

> Any reason why this needs language support? I haven't tried it, 
> but I can't see why it can't be trivially done in a library.

I don't yet know the answer. I have to think more about the 
topic, and to try to implement something in library code. And 
then I can judge (a bit) if the result is good enough.

In D there are things that can be implemented well enough in 
library code (tensors). And we don't yet know if other things can 
be implemented well enough in D library code (like Typedef, or 
Algebric: 
http://forum.dlang.org/thread/olpznzscwiqdysfqvydb@forum.dlang.org 
  Currently Algebraic is not acceptable). And then there are 
things that now we know cannot be implemented acceptably well in 
D library code (like Phobos tuples, that lack essential features 
like unpacking in some different contexts. See Rust for an 
example of simple and reasonably designed built-in tuples: 
http://rustbyexample.github.io/examples/tuples/README.html ).

For D programmers to invest in the usage of (optionally) strongly 
typed array indexing in their medium-integrity D programs (you 
can avoid using that indexing style in script-like D programs), 
such feature has to return them some valuable advantages. This 
means this feature should increase compile-time safety and offer 
a rich enough semantics. Otherwise it's a waste of time for the 
people that implement it, because D programmers (rightfully) will 
not use it.

If you look at Ada, where this feature is more developed, you see 
some semantics that could be not so trivial to reproduce in D 
library code.

Time ago I have suggested to add to D "enum preconditions" that 
in theory can be used in library code to better implement some of 
the static semantics of similar data structures.

Bye,
bearophile