On Monday, 18 June 2018 at 20:23:48 UTC, Jonathan M Davis wrote:
On Monday, June 18, 2018 15:22:48 wjoe via Digitalmars-d-learn
wrote:
On Saturday, 16 June 2018 at 21:25:01 UTC, Jonathan M Davis
wrote:
> every feature that you can't use in betterC is considered a
> loss, and efforts are being made to make more of them work.
> There's always going to be a limit to that, and some D
> features just plain require druntime (just like some of
> C++'s features require a runtime), but it was never the
> point of betterC to strip out a bunch of D features. That's
> just the natural
It is what it is and if what it is is the best tool to fix a
problem I would not hesitate to use it to that end.
But you make it sound like betterC _should only_ work if
actual D code is called otherwise stick with good old C. From
the POV of a C programmer most of what betterC offers is a net
gain and nothing is a loss because what are they losing by
upgrading from C? And in general not paying for something you
don't use or need is considered a gain, no?
I'm saying that -betterC is a subset of D that does not include
D's runtime, and it includes as many of D's features as it
currently can without using the runtime. You can choose to use
it and never use normal D code, but the reason that it was
created in the first place was so that it would be easier to
port C code to D. Without -betterC, you tend to be forced to
port the entire program at once, whereas with it, you can port
it in pieces and then only switch to normal D once everything
has been ported over. But there are some folks who elect to
just write code targetting -betterC and who never intend for it
to work as normal D code.
That's not how it came across.
It came across like the _entire_ purpose of it is to call D stuff
without the need to deal with the druntime and nothing else.
Please tell me. How would I disable just the Error mechanism,
for
example ?
As far as I can tell it's not sufficient that I don't use
nothrow
in my code because if it was used in phobos or druntime or some
other D code I'd have to deal with it.
As with pretty much every other feature, if you don't want any
Errors, you just don't use anything that uses it. The same goes
with the GC and other features that you might choose to avoid.
In some cases, that can be quite limiting, but it is possible
to avoid it. It's simply that just like with any feature,
avoiding it means losing out on features.
So basically everything safe for what is betterC.
The primary difference with nothrow over most other features is
that the compiler inserts code by default for Exceptions if
nothrow isn't there. So, using nothrow is required to turn that
off, whereas for most other features, they only get used if you
choose to use them (or use something that uses them). But it
has nothing to do with Errors either way. The only way to avoid
those is to never use a feature that could throw them (which
can be done but would be so limiting that it's probably a waste
of time).
If having the program crash due to an error condition being
considered fatal is unacceptable to you, then D will be
I never made that claim. Unacceptable to me is the implemented
mechanism.
unacceptable to you - including with -betterC, since in that
case, the Errors get turned into failed C assertions that
aren't compiled out. So, you won't get the stack unwinding, but
your program will be purposefully killed either way, because it
encountered an error condition that is considered fatal. You're
yes, it will be terminated via sigabrt. Which is the way it's
supposed to be.
Not to continue running to a function that prints possibly
invalid stuff, iff a console like device is attached, and abort
in a central, completely unrelated, part of the druntime.
If no console is attached, you'll end up with nothing.
Seriously, the entire mechanism is contradicting itself. How can
it declare program state invalid and unfit to continue at the
point the Error was detected and thrown but do it regardless ?
free to disagree with that approach, and you're free to
disagree with which error conditions are considered fatal, but
it's part of using D. So, you'll either have to learn to live
with that or use a different language.
- Jonathan M Davis
One could also argue that Exceptions are an integral part of
using D and there is really never a situation where you need to
turn it off just like there is never a situation where you would
catch an Error. Deal with it.
If a programming language doesn't so much as to help the
developer to be more productive, e.g. by making it easier to
squash bugs but, by definition i.e. invalid program state, make
it impossible to troubleshoot them, then this language is at
least a bad decision from an economic point of view. Which makes
it a toy language.
I know that much of what can be done actually works in practice
but that's not the point. As soon as program is in invalid state
it must not continue but immediately abort - and if it continues
regardless nothing at all can be relied upon, including what the
druntime spits out before aborting because the druntime is, at
least by definition, in invalid state, too.
And all of this is completely unrelated to my personal opinion.