User defined attributes use

[Artur Skawina]

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);
----------------------------------------------------------------------