On 2/14/14, 20:40, Daniel Murphy wrote:
"Denis Koroskin"  wrote in message
news:wjdvvungwvpemwmxl...@forum.dlang.org...

I'll throw in $300 extra (maybe more), but can you please first
formalize the requirements (list of flags, and what each flag
should mean, required unittests to pass etc).

Required unittests are very helpful, specifying switch names less so.

I also think it's best to split into a few tasks (e.g. a task per
feature or compiler flag). This way it is:
- easier to verify correctness/completeness
- many people can work without interfering with each other
- easier to implement and grab a bounty

Yes.


Ok, In discussing all of this I just realize I looped all the way back around to pretty much Walter's original post.

I'm thinking about setting Bounties on these to start off with.
But I'll be digging through the source code tomorrow to make sure.

(the suggested switch names are just for clarity)

1. Disable Garbage Collector   (suggestion: -nogc)
Currently it's pretty difficult to know what allocates and what does not. There should be a way to completely disable it, and error on attempted GC allocations. I would also like a method to warn on GC allocations (-vgc maybe?), but that is optional.

2. Disable Exceptions          (suggestion: -noexceptions)
There should be a way to completely disable Exceptions, and ensure that none are thrown.

3. Disable ModuleInfo          (suggestion: -nomoduleinfo)
There should be a way to disable any features that rely on ModuleInfo.

4. Disable Object              (suggestion: -noobject)
And anything that depends on it.

5. Disable linking of druntime (suggestion: -nodruntime)

Really I need to learn more about all of this to make sure what I'm proposing will accomplish the end goal of being able to completely disable druntime. Is RTTI necessary, or should it be added to the list of things to disable?

You convinced me that keeping assert would be for the best, so that should be added under suggestions. Classes would be nice, but there's always C++ classes.

I think it's very important to not change the semantics of D in any way. The end goal is to have a solid, core subset of the language, therefore it's important that any code that compiles with these flags would also compile without them.

Jeez, the more I look into this, the more I realize how little I know about it all.

Reply via email to