Does D have too many features?

[Dmitry Olshansky]

On 30.04.2012 9:33, H. S. Teoh wrote:
> On Mon, Apr 30, 2012 at 07:07:53AM +0200, David Nadlinger wrote:
>> On Monday, 30 April 2012 at 03:16:09 UTC, H. S. Teoh wrote:
>>> On Sun, Apr 29, 2012 at 02:26:12PM +0200, David Nadlinger wrote:
>>>> […]
>>>> - Built-in arrays and AAs: They are convenient to use, but as
>>>> far as I can see the single biggest GC dependency in the language.
>>>> Why not lower array and AA literals to expression tuples (or
>>>> whatever) to make the convenient syntax usable with custom (possibly
>>>> non-GC safe) containers as well? A GC'd default implementation could
>>>> then be provided in druntime, just like today's arrays and AAs.
>>> [...]
>>>
>>> AA's are moving into druntime. Yours truly is supposed to make that
>>> happen eventually, but lately time hasn't been on my side. :-/
>>
>> This moves the _implementation_ to druntime, but there is still
>> realistically no way to use AA literals with my own non-GC'd version
>> of hash maps without shipping a custom druntime (and thus modifying
>> the semantics of an existing language construct). What I'm talking
>> about would let you do things like
>>
>> MyVector!int stuff = [1, 2, 3, 4, 5];
>>
>> without needing a (temporary) GC'd allocation, and thus please the
>> GC-hater crowd because they can still have all the syntax candy with
>> their own containers, even if they can't resp. don't want to use the
>> default GC'd constructs.
> [...]
>
> I think you're talking about two orthogonal issues here. One is
> language-level support for arrays and AA's, which IMO are necessary and
> are even a plus (built-in AA's are one of the big reasons I chose D).
> The other is language-level support for literal syntax in user-defined
> types.
>
> I think the latter area has lots of room for improvement. From a
> theoretical standpoint, syntax like [1,2,3,4,5] really should not be
> prematurely tied to a specific type: at the most fundamental level, it's
> just specifying a list of things. How the abstract concept of a list of
> things should be implemented need not be constrained to concrete
> built-in types; I'd argue that the language should permit the
> realization of the concept in a user-defined type as well (i.e., the
> literal interpreted by a user type).
>
> Just off the top of my head, this might be achievable by introducing a
> fromList method in user-defined types that takes a compile-time
> parameter containing some representation of the list, say as a builtin
> array. This method then does whatever is needed to create an instance of
> the type accordingly. (Since the parameter is compile-time, this
> essentially just generates code to create the custom container
> directly.)
>
> The same thing can be done for custom floating-point literals, say. A
> fromFloat() method takes a compile-time string containing the literal,
> and creates an instance of the custom type. (A string is used here so
> that you can implement types that far exceed the maximum precision of
> any builtin type.)
>
> Ditto for AA literals: a fromAA() method takes a compile-time list of
> key/value pairs and does whatever it needs to do to create the
> appropriate runtime AA. In fact, such a construct would alleviate much
> of the need for compiler hacks to support AA's (both old and the
> prospective new replacement). There will be no unnecessary overhead of
> allocating runtime arrays, copying, etc.; the fromAA() method at
> compile-time generates whatever code is necessary to create the literal
> into the target object directly.
>
> This is a language enhancement issue, though, not really an issue about
> builtin AA's or arrays being "unnecessary features".
>
>

*cough* initializer lists *cough*

Seriously let AA liters be an sorted initializer list (conceptual 
compile-time array) of pairs, and normal array literal just plain 
initializer list of common type.

This also nails nicely strange use case of AA literal to build array 
(just the same sorted table of pairs!).
The AA then is just initialized with sorted array at run-time. (as it 
does anyway)

-- 
Dmitry Olshansky