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
