On 2/14/14, 5:45, Daniel Murphy wrote:
"1100110"  wrote in message news:ldkuku$1sgt$1...@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
> 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

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.

Reply via email to