Replacing new? (was re: -nogc)

Joel C. Salomon joelcsalomon at gmail.com
Thu Apr 23 07:58:02 PDT 2009


Andrei Alexandrescu wrote:
> Jason House wrote:
>> Andrei Alexandrescu Wrote:
>>> So I'm thinking there should be a flag -nogc that enables a different
>>> model of memory allocation. Here's the steps we need to take:
>>>
>>> 1. Put array definitions in object.d. Have the compiler rewrite "T[]" ->
>>> ".Array!(T)" and "[ a, b, c ]" -> ".Array!(typeof(a))(a, b, c)". I think
>>> superdan suggested that when he wasn't busy cursing :o).
>>> 
>>> 2. Do the similar thing for associative arrays. 
>>
<<snip>>
> 
> We will need to accommodate multiple implicit conversions somehow anyway
> (e.g. multiple alias this entries). This is a great question because it
> illustrates how segregating arrays out of the language challenges the
> magic that made them "special" and democratizes good features such that
> other types can benefit of them too.
<snip>
>>> 5. Define a Ref!(T) struct in object_nogc.d that does intrusive
>>> reference counting against T using ctors and dtor.
>>>
>>> 6. At this point we already have a usable, credible no-gc offering: just
>>> use object_nogc.d instead of object.d and instead of "new Widget(args)"
>>> use "Ref!(Widget)(args)".
>>
>> Ick... Please make this hijack the default new behavior.
> 
> Agreed.

Just as (1) & (2) point to a way to remove the “magic” of built-in
arrays & hash-tables, so too might (5) & (6) point to a way of replacing
the “new T(args)” syntax with something cleaner?  Not that
“new!(T)(args)” looks nicer than the current syntax, but is it perhaps a
better fit with the rest of the language?

I’ve been lurking on these list for a while and have noticed a pattern:
• Walter includes a useful feature (e.g., complex numbers) into the
language itself for efficiency reasons.
• Walter makes the language more powerful in some subtle but
far-reaching way.
• Someone re-implements the special feature as a library function, based
on the language improvement.

I’m just wondering what addition will––accidentally, of course––make the
creation of new infix operators possible. ;-)

—Joel Salomon



More information about the Digitalmars-d mailing list