Does D have too many features?

[H. S. Teoh]

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".


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.