Bounty for -minimal compiler flag

[inout]

On Sunday, 16 February 2014 at 16:18:13 UTC, Elie Morisse wrote:
> On Thursday, 13 February 2014 at 23:14:20 UTC, 1100110 wrote:
>> I think it's about time I gave back to this wonderful 
>> community.
>>
>> I'm offering a $50 bounty on this.
>> (Preferably Bitcoins, but I'll use bountysource if desired.)
>>
>> rules:
>> Has to be called -minimal
>> 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).
>>
>>
>> This seems to be a good idea and has lots of support from the 
>> community, would anyone like to chip in a few more bucks?
>>
>> I haven't set the bounty yet, depends on if multiple people 
>> chip in.  I'll probably set it sometime tonight.
>>
>> Let me know what y'all think, am I leaving anything out?
>> Thanks
>>
>>
>> On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
>> wrote:
>>> I've toyed with this idea for a while, and wondered what the 
>>> interest there is in something like this.
>>>
>>> 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. To that end, there'd be a 
>>> compiler switch (-betterC) which would enforce the subset.
>>>
>>> (First off, I hate the name "better C", any suggestions?)
>>>
>>> The subset would disallow use of any features that rely on:
>>>
>>> 1. moduleinfo
>>> 2. exception handling
>>> 3. gc
>>> 4. Object
>>>
>>> I've used such a subset before when bringing D up on a new 
>>> platform, as the new platform didn't have a working phobos.
>>>
>>> What do you think?
>
> Isn't this a bit premature?
>
> The idea is controversial, if you read the thread Andrei and 
> Walter wanted to postpone it:
>
>>I convinced Walter of my view on this, so he won't work on it. 
>>I trust
> that at least between the two of us we can focus on working on 
> what
> matters most first.
>>
>>Andrei
>
> so why the hurry?
>
>
> std.allocator should solve the biggest issue which is not 
> making the GC mandatory, and then I don't see the point of 
> stripping D of many of its essential features (classes, array 
> operations, TLS, dynamic casts, static ctors and dtors, ...) 
> when GDC and LDC are already able to enable them (i.e add parts 
> of druntime and Phobos to the binary) on a per-needed basis 
> when statically linking.
>
> IMHO an approach that would not involve making a binary choice 
> between "full D" and "minimal D" is to add an option to make 
> the linker strip druntime and Phobos' shared libraries (or any 
> shared library, and it's not specific to D btw) to the "lowest 
> common denominator" required by a bunch of libraries and 
> applications. Wouldn't that fulfill one of the two goals 
> -nodruntime is trying to achieve as far as I understand (saving 
> memory)?
>
> And regarding the other goal, to help porting D to other 
> platforms a stub druntime would be cleaner than a hackish 
> compiler flag that requires many changes to DMD.

This is wrong in many levels:
a) Walter/Andrei effort vs community effort. It is very important
to have community goals/tasks, and this is a good one
b) Allocator design has nothing to do with e.g. avoiding
TypeInfo/ModuleInfo. Writing code that depends on nothing but C
runtime would allow writing code that is designed to run in C
environment (e.g. Python extensions).
c) "minimal D" may help simplify bootstrapping, ease porting D to
new platforms, open new opportunities for embedded development
with its lower footprint etc.