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.
