On 2/14/14, 7:09, Daniel Murphy wrote:
"1100110"  wrote in message news:ldl2pf$20b0$1...@digitalmars.com...

I want a way to disable the GC, and have the compiler verify that no
GC allocations may occur.

I want a way to disable Exceptions, and have the compiler verify that
no Exceptions may occur.


Good, this is what I had in mind.

I want a way to disable linking either the standard library and the
runtime, and be able to run a minimal D program without needing to
stub anything out manually.

The idea can be boiled down to:
> The idea is to be able to use a subset of D that does not require
any of
druntime or phobos - it can be linked merely with the C standard library.

Cool.

Can you name anything I'm missing?

TLS, dynamic cast, profiling, static this/static ~this, assert, -cov,
-profile, class == and synchronized all rely on druntime code.

This does come with a cost.

I dont know enough about TLS to comment really. Thoughts?

Dynamic cast can be disabled.

static this/~this is tougher. If it is possible for it to work, then it should. I feel that this is more of a language feature.
similarly, I'd expect scope(exit) to still work.


profiling and code coverage are fine left out, since other tools can fill the same task.

It would be nice if assert didn't depend on the runtime, but it's easy enough to implement. conditional, message and exit();

unittests are out as well.

All of those are optional features really. It would be nice to have them, but I feel that those pretty much require a runtime, and the whole point is to *not* require the runtime.


Also, D classes will fail to link without Object.

I'm unsure how useful classes will be without a GC or the runtime...
Thoughts?
I'd be fine with then being disabled.


Should `array.length = x` be an error or just unsafely set the length?

Unsafely set the length.
Justification: There is no way to know whether or not you have manually adjusted the array or not.

I see it as similar to pointer arithmetic in current D. Whether it works or not is dependent on the programmer.


Should it be ABI-compatible with normal D?
Yes. It should be as compatible as possible. If that is not possible, then C, as D is compatible with C.


If you don't have strong feelings about any of these they should still
probably be listed.

Reply via email to