bigfloat

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> 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

Well, now that I understand your proposal a little better, it makes sense.  I had
wondered why the current AA implementation uses RTTI instead of templates.  Even
better would be if only the default implementation were in Object, and a user
could somehow override which implementation of AA is given the blessing of pretty
syntax by some pragma or export alias or something, as long as the implementation
conforms to some specified compile-time interface.