"Steven Schveighoffer"  wrote in message news:op.xa929juueav7ka@stevens-macbook-pro.local...

> >> static this/~this is tougher.  If it is possible for it to work, then it should.  I feel that this is more of a language feature.
> >
> > These might work with init sections, but maybe not.
>
> No, static ctor/dtor is not a trivial mechanism. There is a runtime graph analysis to make sure there are no cycles, and then run them in the proper order.
>
> I think this feature has to be disabled.

I meant that we could get something mostly working using init sections, but it's probably not a good idea.

> >> unittests are out as well.
> >
> > Most likely.
>
> Yes, this also depends on moduleinfo, like static ctor/dtor.

Same with this, not worth the hack.

> >
> > I'll take it you've never seen how virtual functions are implemented in C? Classes are awesome.
>
> This requires vtables and typeinfo. I've seen virtual functions implemented in C (back when I wrote Xt widgets). I also think that with D's compile-time power, one could probably recreate it using templates.

I don't want to recreate it, I want to avoid it.

> The issue I have with allowing classes is the implications of classes. D classes are infinite-lifetime, meaning requiring GC. What we would end up with is classes written for the minimal no-gc version of D, and classes that were written to be allocated on the GC heap in full-D. And both would be named 'class'

This is a very good point.  extern(C++) classes do not depend on druntime, and currently do not have their destructors run by the GC! 

I don't think, everything should be done by the compiler. Most trouble with gc is that its usage can't be traced similar to tls, so the feature will be diagnostics similar to -vtls option, say, -vminimal. The compiler can write the trace of runtime usage in machine-readable format to stdout (format: `vminimal:feature:file:line`) and a separate frontend (stylesop) can analyze the trace and apply arbitrary feature usage policy. Don't change semantics of language constructs. The first step would be to implement tracing of gc usage.

On 2014-02-14 14:50, 1100110 wrote:

> This does come with a cost.
>
> I dont know enough about TLS to comment really. Thoughts?
>
> Dynamic cast can be disabled.
>
> static this/~this is tougher.  If it is possible for it to work, then it
> should.

This requires ModuleInfo, if I recall correctly.

> profiling and code coverage are fine left out, since other tools can
> fill the same task.

Doesn't that require another flag anyway?

> It would be nice if assert didn't depend on the runtime, but it's easy
> enough to implement.  conditional, message and  exit();
>
> unittests are out as well.

Theoretically it should be possible to just disabled the ModuleInfo part and then use __traits(getUnitTests) instead.

-- 
/Jacob Carlborg

On 2014-02-14 15:07, Daniel Murphy wrote:

> It's probably platform dependent, I guess it should work everywhere that
> C supports TLS.

Well, on OS X it's natively supported on since 10.7 but DMD still uses emulated TLS:

>> Dynamic cast can be disabled.
>
> Sure, but should it be an error or be replaced with a static cast?
>
>> static this/~this is tougher.  If it is possible for it to work, then
>> it should.  I feel that this is more of a language feature.
>
> These might work with init sections, but maybe not.
>
>> similarly, I'd expect scope(exit) to still work.
>
> With no exceptions, scope(xxx) will work just fine.
>
> Similarly, try-catch will be valid, just not throwing.
>
>> profiling and code coverage are fine left out, since other tools can
>> fill the same task.
>
> Yah.
>
>> It would be nice if assert didn't depend on the runtime, but it's easy
>> enough to implement.  conditional, message and  exit();
>
> mmm...
>
>> unittests are out as well.
>
> Most likely.

Theoretically it should be possible to just disabled the ModuleInfo part and then use __traits(getUnitTests) instead.

> I don't think it's worth throwing out assert over.  A runtime that
> supported assert + Object would be about 8 lines and would IMO be
> worthwhile.

Perhaps leave the assert handler, which could be overridden, which could default to a halt like assert(0) does in release mode?

-- 
/Jacob Carlborg

On 2014-02-14 16:42, Steven Schveighoffer wrote:

> I'm 90% sure that MacOS does not natively support TLS, and uses the
> core.Thread class to store it.

OS X support TLS natively since 10.7, but DMD still uses emulated TLS on OS X.

> Yes, this also depends on moduleinfo, like static ctor/dtor.

As I've replied to other posts, there's __traits(getUnitTests) as well.

-- 
/Jacob Carlborg

On Fri, 14 Feb 2014 15:39:24 -0500, Jacob Carlborg <doob@me.com> wrote:

> On 2014-02-14 16:42, Steven Schveighoffer wrote:
>
>> I'm 90% sure that MacOS does not natively support TLS, and uses the
>> core.Thread class to store it.
>
> OS X support TLS natively since 10.7, but DMD still uses emulated TLS on OS X.

That's... old. Why doesn't DMD start using it? 10.7 came out in 2011.

>
>> Yes, this also depends on moduleinfo, like static ctor/dtor.
>
> As I've replied to other posts, there's __traits(getUnitTests) as well.
>

I wasn't aware of that. One has to consider how it will be expected to work. Most of the time, D compiles and runs unit tests if -unittest is passed. What happens in -nodruntime -unittest? Does it just compile the unit tests into the objects but not store the pointers since there is no moduleinfo?

Here is a possible compromise: -unittest and -nodruntime are mutually exclusive. If you want to run unit tests, run with -unittest. If you want to run without druntime, use -nodruntime. Any code that builds under -nodruntime should also build without that switch.

-Steve

On 2014-02-14 22:02, Steven Schveighoffer wrote:

> That's... old. Why doesn't DMD start using it? 10.7 came out in 2011.

It wasn't that old until recently, when 10.9 was released. It's the same as with everything else. Someone just have to commit time and implement it. I guess this is a bit different though, since we might need to drop support for 10.6.

> I wasn't aware of that. One has to consider how it will be expected to
> work. Most of the time, D compiles and runs unit tests if -unittest is
> passed. What happens in -nodruntime -unittest?

-unittest need to be passed for __traits(getUnitTests) to return anything.

> Does it just compile the
> unit tests into the objects but not store the pointers since there is no
> moduleinfo?

I would say so, yes.

-- 
/Jacob Carlborg

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?

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

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

"Denis Koroskin"  wrote in message news:wjdvvungwvpemwmxlbst@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. 

On 2/14/14, 20:40, Daniel Murphy wrote:
> "Denis Koroskin"  wrote in message
> news:wjdvvungwvpemwmxlbst@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.