On Monday, 17 March 2014 at 07:56:20 UTC, Mason McGill wrote:
I just wrote a DIP aimed at improving slicing and range
construction syntax while maintaining backwards compatibility,
and I'd like to hear your opinions!
http://wiki.dlang.org/DIP58
It can be thought of as an elaboration on the approach
discussed here:
http://forum.dlang.org/thread/[email protected]
And an alternative to the approach discussed here:
http://forum.dlang.org/thread/[email protected]#post-ncwqaixkgbgycybvpkgj:40forum.dlang.org
I think the issue of appealing to numerical programmers is
worth some attention because there's a distinct niche that D is
frustratingly close to filling. In my field, researchers will
often write scripts in a dynamic language, publish, iterate,
and eventually re-write their software in C++ and release it as
a library. The re-writing step is a large time investment, but
it's important because
- Dynamic languages are either slow (MATLAB/Python/R) or
immature (Julia).
- Other researchers may prefer another dynamic language, but
every relevant dynamic language can interface with native
libraries.
D already has the speed and modeling power of C++, GC for clean
API design, and reflection for automatic bindings, but it's
missing a few key features required to make something like
NumPy or the Julia standard library possible in D. I believe
DIP58 provides those features, and accepting DIP58 will make D
a competitive alternative to the prototype/test/rewrite/release
cycle.
On another note, I'm pretty new to D and the community, so let
me know if there's any protocol I should follow with respect to
DIPs and I'll get on it!
Cheers,
Mason
It's a nice proposal, but what happens if you want a range of
floats, e.g., 1.0..2.0? I don't know if this causes any ambiguity
or not. Also, as others said, the step syntax is a bit weird, and
could probably be delegated to a library function quite easily,
such as in one of your examples:
const evenEntries = vector[(1..11).by(2)];
