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
