Bounty for -minimal compiler flag

[1100110]

On 2/14/14, 7:09, Daniel Murphy wrote:
> "1100110"  wrote in message news:ldl2pf$20b0$1 at 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.