On Friday, 14 February 2014 at 12:39:11 UTC, 1100110 wrote:
> Can you name anything I'm missing?
>

* no module info
* no runtime type info
* treat TLS as __gshared for single threaded programs

Mike

On 2/14/14, 7:09, Daniel Murphy wrote:
> "1100110"  wrote in message news:ldl2pf$20b0$1@digitalmars.com...
>
>> 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.
>>
>
> Good, this is what I had in mind.
>
>> 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.
>
> Cool.
>
>> Can you name anything I'm missing?
>
> TLS, dynamic cast, profiling, static this/static ~this, assert, -cov,
> -profile, class == and synchronized all rely on druntime code.

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.  I feel that this is more of a language feature.
similarly, I'd expect scope(exit) to still work.


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

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.

All of those are optional features really.  It would be nice to have them, but I feel that those pretty much require a runtime, and the whole point is to *not* require the runtime.

>
> Also, D classes will fail to link without Object.

I'm unsure how useful classes will be without a GC or the runtime...
Thoughts?
I'd be fine with then being disabled.

>
> Should `array.length = x` be an error or just unsafely set the length?

Unsafely set the length.
Justification:  There is no way to know whether or not you have manually adjusted the array or not.

I see it as similar to pointer arithmetic in current D.  Whether it works or not is dependent on the programmer.

>
> Should it be ABI-compatible with normal D?
Yes.   It should be as compatible as possible.  If that is not possible, then C, as D is compatible with C.

>
> If you don't have strong feelings about any of these they should still
> probably be listed.

"1100110"  wrote in message news:ldl6v6$255r$1@digitalmars.com...

> I dont know enough about TLS to comment really. Thoughts?

It's probably platform dependent, I guess it should work everywhere that C supports 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.

> All of those are optional features really.  It would be nice to have them, but I feel that those pretty much require a runtime, and the whole point is to *not* require the runtime.
>

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.

ie small enough to copy+paste into your main.d

> > Also, D classes will fail to link without Object.
>
> I'm unsure how useful classes will be without a GC or the runtime...
> Thoughts?
> I'd be fine with then being disabled.

I'll take it you've never seen how virtual functions are implemented in C? Classes are awesome.

> >
> > Should `array.length = x` be an error or just unsafely set the length?
>
> Unsafely set the length.
> Justification:  There is no way to know whether or not you have manually adjusted the array or not.
>
> I see it as similar to pointer arithmetic in current D.  Whether it works or not is dependent on the programmer.

This puts us in the nasty situation of having code behave differently with and without the switch.  Like dynamic cast, I'd rather it was a compile-time error and you had to use arr.ptr[0..newlen] instead.

On 2/14/14, 8:07, Daniel Murphy wrote:
> "1100110"  wrote in message news:ldl6v6$255r$1@digitalmars.com...
>
>> I dont know enough about TLS to comment really. Thoughts?
>
> It's probably platform dependent, I guess it should work everywhere that
> C supports 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.
>
>> All of those are optional features really.  It would be nice to have
>> them, but I feel that those pretty much require a runtime, and the
>> whole point is to *not* require the runtime.
>>
>
> 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.

But then where do we stop?
This is why I think it's an excellent idea to have multiple flags, or options, one for each thing disabled.

So you can only disable what you do not want.

>
> ie small enough to copy+paste into your main.d
>
>> > Also, D classes will fail to link without Object.
>>
>> I'm unsure how useful classes will be without a GC or the runtime...
>> Thoughts?
>> I'd be fine with then being disabled.
>
> I'll take it you've never seen how virtual functions are implemented in
> C? Classes are awesome.
>
>> >
>> > Should `array.length = x` be an error or just unsafely set the length?
>>
>> Unsafely set the length.
>> Justification:  There is no way to know whether or not you have
>> manually adjusted the array or not.
>>
>> I see it as similar to pointer arithmetic in current D.  Whether it
>> works or not is dependent on the programmer.
>
> This puts us in the nasty situation of having code behave differently
> with and without the switch.  Like dynamic cast, I'd rather it was a
> compile-time error and you had to use arr.ptr[0..newlen] instead.
>

Very Very good point there.  I didn't think about that.  Code should not behave any differently with different switches.  Period.  I seriously doubt it would make it into the repo either.

"1100110"  wrote in message news:ldl9fj$28g6$1@digitalmars.com...
> > 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.
>
> But then where do we stop?
> This is why I think it's an excellent idea to have multiple flags, or options, one for each thing disabled.
>
> So you can only disable what you do not want.

'assert' is pretty fundamental (compared to something like exceptions) and is especially important in low-level code.  It can also be disabled using -release.

I guess worst case the compiler could inline it as `e || _whatever_the_clib_calls_on_assert_failure`

> >
> > This puts us in the nasty situation of having code behave differently
> > with and without the switch.  Like dynamic cast, I'd rather it was a
> > compile-time error and you had to use arr.ptr[0..newlen] instead.
> >
>
> Very Very good point there.  I didn't think about that.  Code should not behave any differently with different switches.  Period.  I seriously doubt it would make it into the repo either.

Hmm, I forgot about new and delete.  They would be nice to have as wrappers around malloc, but that would change the meaning of code... 

On Fri, 14 Feb 2014 08:09:21 -0500, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> TLS, dynamic cast, profiling, static this/static ~this, assert, -cov, -profile, class == and synchronized all rely on druntime code.
>
> Also, D classes will fail to link without Object.

I think classes heavily depend on druntime, I believe Walter was indicating they would not be allowed (which trivially excludes class ==)

> Should `array.length = x` be an error or just unsafely set the length?

It should be an error, you can do this unsafely:

array = array.ptr[0..x];

-Steve

On Fri, 14 Feb 2014 09:07:35 -0500, Daniel Murphy <yebbliesnospam@gmail.com> wrote:

> "1100110"  wrote in message news:ldl6v6$255r$1@digitalmars.com...
>
>> I dont know enough about TLS to comment really. Thoughts?
>
> It's probably platform dependent, I guess it should work everywhere that C supports TLS.

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

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

>> unittests are out as well.
>
> Most likely.

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

>> I'm unsure how useful classes will be without a GC or the runtime...
>> Thoughts?
>> I'd be fine with then being disabled.
>
> 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.

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'

-Steve

On Friday, 14 February 2014 at 13:04:32 UTC, 1100110 wrote:
> Got any thoughts?
3. Disabling runtime type information and module information...

On Friday, 14 February 2014 at 15:34:16 UTC, Steven Schveighoffer wrote:
> I think classes heavily depend on druntime, I believe Walter was indicating they would not be allowed (which trivially excludes class ==)

My problem with excluding them is that it isn't hard to bring in the druntime parts they depend on when you need it. It's not like writing a class is a hidden feature - you don't need the compiler to help you find places you used them, and the linker error about the missing functions are fine.

Then we can just provide class support in one module that you just start compiling in to opt-in to the feature.

On Fri, 14 Feb 2014 10:46:19 -0500, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Friday, 14 February 2014 at 15:34:16 UTC, Steven Schveighoffer wrote:
>> I think classes heavily depend on druntime, I believe Walter was indicating they would not be allowed (which trivially excludes class ==)
>
> My problem with excluding them is that it isn't hard to bring in the druntime parts they depend on when you need it. It's not like writing a class is a hidden feature - you don't need the compiler to help you find places you used them, and the linker error about the missing functions are fine.
>
> Then we can just provide class support in one module that you just start compiling in to opt-in to the feature.

Classes are typically written with an expectation that the GC will clean them up. I don't think you can just get rid of that expectation. A class written without the assumption of the runtime is a very different object, and I would be hesitant to name it 'class' in D.

I recommend not supporting classes, at least for now.

-Steve