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