Rust-based provocation :)

Adam D. Ruppe destructionator at gmail.com
Wed May 29 05:41:23 PDT 2013


On Wednesday, 29 May 2013 at 09:58:02 UTC, Dicebot wrote:
> My main interest here is to get something running to experiment 
> with what changes can be made to compiler to allow to remove 
> unused stubs and still get the useful stuff running. Like "no 
> exceptions" and "no rtti" switches in g++.

That might be possible through -version switches on object.d, 
which would give either a stub (my original d_throw function 
before copy/pasting from druntime just said { write("exception 
thrown"); exit(1); } or something like that) or left out 
entirely, leading to linker errors.

The same thing might be possible for more features.


BTW I just tried new int[](10), and that needs even more code. 
But I think using that in a non-gc environment is actually a 
mistake anyway. It could be done like classes, where the new 
function mallocs and you are responsible for freeing, but the 
problem is new int[](10) and arr[0 .. 10] look the same in user 
code.

You would be responsible for freeing the former, but not the 
slice. So I think keeping them a different type is a feature, not 
a bug, in this situation.

My thought is array slices are always "borrowed" references. You 
don't free them, and you should avoid keeping a copy of it unless 
that is well documented. (Actually I think this would be nice 
addition to D proper, a special type qualifier that promises 
you'll never store a reference to this except in local variables. 
So you can still slice it and so on, but never stuff it in a 
member variable because the owner might free it without informing 
you.)

Anyway the arrays themselves are a different library type

StackArray!int blah;
HeapArray!int blah;

and so on, and you've gotta be responsible for freeing them 
appropriately. The StackArray of course dies when it goes out of 
scope, and maybe the HeapArray could be reference counted. Again, 
built in slices won't count toward the count, so can only use 
them temporarily, but the rest could be.


And when this is written it might be a good idea to put in phobos 
too!


More information about the Digitalmars-d mailing list