bigfloat

[Benji Smith]

Daniel Keep wrote:
> 
> Andrei Alexandrescu wrote:
>> dsimcha wrote:
>>> 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.
>> Great! For now, I'd be happy if at least the user could hack their
>> import path to include their own object.d before the stock object.d.
>> Then people can use straight D to implement the AssocArray they prefer.
>> Further improvements of the scheme will then become within reach!
>>
>> Andrei
> 
> dmd -object=myobject.d stuff.d
> 
> That would require the user to duplicate everything in object, which is
> a little messy.  Maybe it would be a good idea to break object itself
> into a bunch of public imports to core.internal.* modules, then allow this:
> 
> dmd -sub=core.internal.aa=myaa stuff.d
> 
> Of course, it's probably simpler still to have this:
> 
> dmd -aatype=myaa.AAType stuff.d
> 
>   -- Daniel

Instead, what if the literal syntax was amended to take an optional type 
name, like this:

    // Defaults to using built-in associative array type
    auto assocArray = [
       "hello" : "world
    ];

    // Uses my own custom type.
    auto hashtable = MyHashTableType!(string, string) [
       "hello" : "world
    ];

You could accomplish that pretty easily, as long as the custom type had 
a no-arg constructor and a function with the signature:

    void add(K key, V val)

--benji