Fix Issue 18493 - [betterC] Can't use aggregated type with postblit (+More)

[JinShil]

Overview

Issue 18493 revealed an oversight in the implementation of betterC: -betterC does not support throwing exceptions, but does not require a nothrow environment. #8184 provided a fix to the auto-generated try-catches implicitly added to an aggregate's field postblits, but the fundamental issue remains. This PR attempts to fix that fundamental issue.

I discussed this with @andralex and @WalterBright privately in an e-mail exchange:

• Me: Is it your intention to make -betterC work with reference counted exceptions in the future, or will -betterC always imply a nothrow environment?
• WB: For the foreseeable future, betterC means nothrow.
• AA: If we want betterC to only work with nothrow, we should restrict it as such, i.e. reject any code that is not marked with "nothrow". Code semantics should not depend on the compilation switch used.
• WB: It's reasonable for betterC to assume nothrow. It diagnoses an error when any attempts are made to throw, and it already assumes nothrow.
• AA: How does that interact with linking -betterC code with non-betterC code?
• WB: There's no purpose to doing that. The point of betterC is to not require druntime - linking it with non-betterC code will require druntime. If you do it anyway, it will be like linking in C code to your D code. It'll be totally unaware of thrown exceptions - it won't catch them, and won't execute finally blocks or destructors as the stack is unwound.
• Me: What about DIP1008? Are there any plans to make that usable in -betterC?
• WB: No, because the exception unwinding code in druntime is still required, and is not there in the standard C libraries.

I've chosen to side with @andralex for this PR as I agree with the principle that:

Code semantics should not depend on the compilation switch used.

That is, when compiling in -betterC, or with a minimal runtime that does not support Throwable, the compiler will require all functions to be attributed with nothrow (which users should already be doing anyway).

Breaking Changes

This will break existing -betterC code for sure, but I think that's OK:

• -betterC is a relatively new feature of D and we're still sorting out issues with it.
• according to the 2018 State of D Survey -betterC is only being used by 4% of respondents, so the impact should be very minimal.
• the fix is extremely simple in most cases: Add a nothrow: attribution to the top of the module. Users should already be doing this anyway when compiling without support for exceptions.

DRuntime Changes

To make this work druntime's object.d also needed to be modified (See dlang/druntime#2184). This is because, despite the fact the -betterC does not link with druntime or phobos, it still imports object.d. There is a large amount of code in object.d that not utilized when compiling with -betterC, but it is not versioned out like it should be, and that causes compiler errors with the changes in this PR. The druntime PR will also enable other planned features for -betterC including using classes with static memebers, so it is also forward-looking.

Adding the "Vision" label as this is congruent with item 4 of Vision 2018H1

4. Improve interoperability with other languages: Finishing -betterC should improve incremental migration of C and C++.

[dlang-bot]

Thanks for your pull request, @JinShil!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	18493	blocker	[betterC] Can't use aggregated type with postblit

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

To target stable perform these two steps:

1. Rebase your branch to upstream/stable:

git rebase --onto upstream/stable upstream/master

2. Change the base branch of your PR to stable

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#8253"

[WalterBright]

Requiring nothrow on all -betterC code is a significant nuisance and adds little to no value.

[JinShil]

Requiring nothrow on all -betterC code is a significant nuisance and adds little to no value.

Adding a nothrow: at the top of a module is not a significant nuisance, and furthermore, users should be doing it anyway. It adds great value, in my opinion, because through the compiler-emitted errors, it educates users about the proper usage of the language helping them write correct and portable code. It also maintains principled interpretation of the language and prevents -betterC from fracturing the language into a new dialect.

@andralex and @WalterBright, it would be very helpful if you two could come to some agreement on this.

[JinShil]

In order for this to work we need to agree that the feature set of D available to -betterC builds at compile-time is identical to the feature set of D available to -betterC at runtime.

Users of -betterC can currently employ features of D at compile-time that are not available in the -betterC subset of the language at runtime. An obvious example is pragma(msg, typeid(size_t)). That code, as ridiculous as it is, is currently possible in -betterC despite the fact that it requires TypeInfo which is a feature not available in -betterC at runtime. In order to move forward with this PR, we need to disallow such features in -betterC at compile-time if they are not permitted in -betterC at runtime.

If we can agree that -betterC at compile time and -betterC at runtime must have feature parity, then we can move forward with this PR. Until then, this is blocked.

[patrickkh7788]

current betterC not allow compile time call function with GC, this is reduce the power of betterC. (some template will only use to generate static const will not work, like web view template compile)

[jacob-carlborg]

Yeah, basically the only way to allocate in a CTFE function is to use the GC. If that's not allowed in betterC then we're going to severely limit CTFE for betterC. I don't see why you wouldn't want be able to take full advantage of Phobos during CTFE. There was a talk about someone that was parsing a PDF file with CTFE to extract op codes or similar for some kind of architecture. This generated some code which would always be up to date with the specification. Good luck doing that without Phobos.

[patrickkh7788]

CTFE BetterC with GC make betterC useless.

[9il]

Why useless? Do you mean betterC is useless without GC in CTFE?

[skoppe]

At compile time I want to be able to do what I normally can, but when I compile with betterC I can't.

There really should not be any reason for that behaviour.

[PetarKirov]

If -betterC starts implying a D_BetterC environment in CTFE code it means you won't even be able to use string concatenation and by extension mixins become close to useless. So I think we can all agree that this would be a pointless limitation. -betterC should only affect the runtime environment - compile-time code should not be limited in any way.

[skoppe]

-betterC should only affect the runtime environment - compile-time code should not be limited in any way.

It's so bad you can't even use things like tuple. This makes ctfe completely useless in betterC mode.

[anon17]

On windows exception mechanism is provided by the system, and invalid memory access is reported as an exception. If it's C, it doesn't mean there are no exceptions.

[thewilsonator]

not being able to use string concat at compile time would be completely useless.