bigfloat

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> dsimcha wrote:
>>> == Quote from Frits van Bommel (fvbommel at REMwOVExCAPSs.nl)'s article
>>>> Steven Schveighoffer wrote:
>>>> Yet another reason to get rid of built-in .sort; a templated function would have
>>>> no problem with this :).
>>> Yes, and with my proposal (not exclusively mine, it's been suggested by plenty of
>>> other people) of importing some very basic, universally used functionality
>>> automatically in Object so it can "feel" builtin, getting rid of builtin sort
>>> wouldn't even make code *look* any different.
>> Great point. My hope is that one day I'll manage to convince Walter and
>> Sean to simply replace V[K] types with AssocArray!(K, V) and then make
>> AssocArray a regular template inside object.d. The current
>> implementation of associative arrays looks... brutal.
>> Andrei
> 
> Yes, but then we lose niceties like AA literals and good declaration syntax.

Sorry, I meant to include literals too. What I'm saying is that built-in 
AAs should essentially be a very thin wrapper over a genuine D type. 
That means only the syntax of the type and the syntax of literals should 
be built-in - everything else should use the exact same amenities as any 
user-defined type.

> What
> would be gained by moving stuff into Object compared to improving the
> implementation within the existing paradigm?  On the other hand, the current
> implementation *could* use some improvement.  (In a few minutes when it's written,
> see post on AA implementation.  I've been meaning to post this for a while.)

Current AAs look awful. They're all casts and bear claws and cave 
paintings. I tried two times to get into them, and abandoned them for 
lack of time. (I wanted to add an iterator for keys. It's virtually 
impossible.) Also, they don't use the normal operator syntax etc. The 
compiler elaborately transforms expressions into calls to AA functions.

Also, AAs use dynamic type info which makes them inherently slower. Oh, 
and iteration uses opApplyImSlowLikeMolassesUphillOnAColdDay.

To me it is painfully obvious that there should be as little magic as 
possible for elaborate types. Literals and simple type syntax are 
useful. Keep those, but stop there and let actual code take off from 
there. It's just the right way, again, to me that's so obvious I don't 
know how to explain.


Andrei