Bounty for -minimal compiler flag

[1100110]

On 2/14/14, 5:45, Daniel Murphy wrote:
> "1100110"  wrote in message news:ldkuku$1sgt$1 at digitalmars.com...
>
>> I don't think we'll ever please everyone here.  All I'm really trying
>> to do by specifying the name is prevent some cutesy annoying name.
>
> It's pretty hard to get a pull request in with a silly switch name, so I
> wouldn't worry too much about that.
>
>> I'd be fine with the switch being name -nodruntime, and honestly I
>> like that better.
>
> Me too!
>
>> >> Has to fulfill Walter's original post. (listed below)
>> >> Has to split the separate parts into different flags as well as
>> >> -minimal(-nogc, -nomoduleinfo, etc. Naming is left to the
>> implementer).
>> >
>> > Make a enhancement report on bugzilla with the details.
>>
>> I will as soon as I iron a few wrinkles.  I need to figure out if
>> typeinfo should be a part of this as well.
>
> I strongly recommend putting only goals in the enhancement request, and
> avoiding implementation details (and especially syntax) whenever possible.
>
> Eg Struct equality requires typeinfo, but and implementation that
> changed it to use templates instead would probably be fine.  The
> typeinfo part is irrelevant here, you just want to avoid having to link
> druntime in.
>
> Specifying individual flags is also not recommended, because a better
> interface might emerge and then the issue of whether the ER is completed
> gets messy.  Instead saying "I want a way to disable just the GC" avoids
> this.

Alright,
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.

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.


Can you name anything I'm missing?

>
> Finally, putting many things in one request discourages partial fixes,
> makes discussion harder to follow, and could get complicated with a
> bounty involved. (what if two people implement different parts etc)  It
> would be better (IMO) to split each atomic feature into its own ER and
> cross-link them, even if this means splitting the bounty across them.

Good point, I'll do that.