Head Const

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 16 February 2016 at 06:04:42 UTC, Jonathan M Davis 
wrote:
> On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright 
> wrote:
>> rears its head again :-)
>>
>> Head Const is what C++ has for const, i.e. it is not 
>> transitive, applies to one level only. D has transitive const.
>>
> In this particular case, doesn't this really just come down to 
> mangling? It's undefined behavior in D to mutate a const object 
> (even if it was constructed as mutable), so we can't just slap 
> D const on C++ types and have that work, since the C++ code 
> could legally mutate the object. But since C++ considers it 
> defined behavior to mutate a const object by casting away const 
> (or at least it does in all but some very specific cases), can 
> we just get away with the D code treating D const as mutable? 
> If so, then it's purely a matter of mangling. And for that, we 
> could do something like add @cppconst or cppconst that the 
> compiler recognizes and which is only valid in extern(C++) 
> declarations. It would unfortunately have to be more than a 
> simple attribute, because it would have to apply to parts of a 
> parameter's type like C++'s const does (instead of the whole 
> type at once), but if it were implemented such that it was just 
> something that went on the extern(C++) function parameter types 
> (or return types) for mangling purposes, and the D code just 
> treated it as mutable, then it would at least restrict the muck 
> to extern(C++).

Actually, one could argue that the fact that we support const at 
all with other languages - even with C - is broken in that C/C++ 
code can cast away our const and mutate the variable we passed 
in, breaking our type system. We rely on the programmer to know 
that the C/C++ code isn't going to do that, and most of the time, 
you really have no clue. You just assume that it won't - and it 
probably won't, but you don't know for sure.

So, most of the time, it will work just fine, but const with 
extern(C) and extern(C++) really does not provide the guarantees 
that const is supposed to provide.

Of course, there's also the issue that with extern(C) and 
extern(C++), everything is really __gshared, and yet we typically 
treat  it like it's thread-local just like the D code is. 
Arguably, all parameters and return types with extern(C) and 
extern(C++) should be automatically treated as shared, and not 
doing so is risking a world of pain if the C/C++ code misbehaves, 
but having them be treated as shared would be really annoying to 
deal with, and most C/C++ code that's being called probably isn't 
doing anything with threads that could violate D's guarantees 
about thread-local variables (just like most C/C++ code 
presumably isn't casting away const and mutating when we pass it 
something from D) - but there's no guarantee that it isn't.

So, as far as compiler guarantees and the type system go, 
extern(C) and extern(C++) are a bit of a disaster, much as they 
generally work in practice. But I don't know what we can really 
do about that other than trying to educate people about the risks 
and possibly have the compiler avoid certain types of 
optimizations around extern(C) and extern(C++) code (which it may 
already do).

- Jonathan M Davis