On 09/17/13 00:53, H. S. Teoh wrote: > On Mon, Sep 16, 2013 at 10:59:10PM +0200, Artur Skawina wrote: >> On 09/16/13 22:38, Namespace wrote: >>>> [1] Obviously, not a practical short term option for the existing >>>> D2 language. That's probably clear from the context, and the >>>> question was meant to be rhetorical -- but it could actually be >>>> done and would make sense; it's just not a change that would >>>> make enough of a difference on its own; the cost would be to >>>> high. >>> >>> Why to high? Too much compiler magic or dmd internal dependences? >> >> Too much (language) change for too little gain; there are many, many >> much more important things that need to be fixed. Being able to have >> several user-defined kinds of arrays is a nice-to-have feature, but >> not one that determines whether the language is usable or not. > [...] > > Hmm. I find D arrays just fine the way they are, actually. (In fact, I > rather *liked* the way D arrays worked as compared with, say, C/C++.) > What's wrong with them?
Not that much, at least not enough to worry about it right now, considering all the other language issues. (eg some conversions, like to-bool, static-array-to-slice; syntax ambiguity [1]; some properties) But removing magic from the compiler and making the language more expressive, so that the magic could be done by the user, would be an improvement. Not a regression, which the original question implied. For example: 1) // in semi-pseudocode alias utf8string = utf8octet[]; utf8string s = "abc"; foreach (c; s) // iterate by codepoints, not bytes Yep, this is like what can be done today with built-in strings -- except that it could be done by overloading array-ops in 'utf8octect'. No type-specific compiler magic, and then you can use it for many other kinds of variable-element-length array types. 2) SIMD optimizations; again, w/o explicit compiler support. It could just map array ops to an optional 'static @inline T.opArrayOp(string op, size_t minAlignent, B)(T[] a, B b)' method, etc. In general, much of the built-in compiler 'magic' gets in the way of emitting optimal code, for example the hardwired (d)runtime calls prevent many optimizations. (eg removing (hacking around for just one built-in type is easy enough) the 'typeid()' calls from your stand-alone AAs makes a huge difference. Or at least it did ~ a year ago when i looked at how much inherent overhead the std AAs have). artur [1] ---------------------------------------------------------------------- auto f(T[2] a) { /* 'a' is what it looks like - a static array, right? Oops... */ } template Tuple(A...) { alias Tuple = A; } alias T = Tuple!(int, double, long); ----------------------------------------------------------------------