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. > > consequence of the goal of being callable from C code without > > needing to worry about druntime. > > All of those features that betterC can't use can be avoided in > > normal D code if you don't want them for whatever reason. > > nothrow is actually one of the few cases where you have to > > explicitly do something in order to avoid that list of features > > that you have there. In the other cases, you just don't use the > > feature, and the only cost you're paying is the startup and > > shutdown time for druntime and the few resources that it uses. > > 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. 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). > But I know the answer to that. It's not possible because it was > never considered because why would anyone want to do that and > have the program just crash. > > Let's say I don't want to deal with OutOfMemoryError. That means > essentially I'm losing the GC. Which sucks big time as it is > _the_ selling point for me to use D over C. > > Let's say I didn't agree with RangeError for assoc. Arrays. I > imagine it allocates dynamically and hence has a dependency on > the GC so I have to consider the OutOfMemoryError headache even > if I would agree to RangeError. Solution again don't use it and > implement my own. > > Really, I don't see the difference between not using a feature > and not having a feature available; result's the same - I need a > solution/replacement. If having the program crash due to an error condition being considered fatal is unacceptable to you, then D will be 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 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