Timon Gehr

It's a conservative fix and it's also ad-hoc. It does not follow from `return scope`/`scope` semantics on the pointer level. It's both more powerful because you are tracking which variables...

> This would be less powerful than keeping track of individual local variables, but it's consistent with how all struct members are assumed to have equal lifetime. To be very...

I understand the benefit of easy compatibility with C, but C bitfields are still a bad way to do bitfields because they are not portable. This adds a footgun with...

Also note that the main benefit of this interoperability is for incremental porting of existing C code to D. No sane C library would have C bitfields in the public...

> @schveiguy I do understand Adam's objections. I see bitfields used a lot in C code. Anything reasonable we can do to make it easy for people to ease into...

> > interoperability > > Using bitfields in the D part of the compiler will effortlessly interoperate with bit fields in the gdc and ldc backends. Yes right (except for...

In general, any form of undefined behavior following from invalidated type invariants can lead to memory corruption. Memory corruption, undefined behavior, violations of type safety, wrong optimizer assumptions etc. are...

Buildkite is _obviously_ not going to fail by you removing a way that code could fail to type check. This does not show what you say it shows. In any...