Tail pad optimization, cache friendlyness and C++ interrop

[via Digitalmars-d]

On Wednesday, 18 June 2014 at 06:50:14 UTC, deadalnix wrote:
> That isn't splitting hair. You are loosing track of the big 
> picture here. To come back to the original problem :
>
> memset(&foo, 0, typeof(foo).sizeof);
>
> Walter mention that this is not corrupting memory and therefore 
> @safe.

memset is by definition an unsafe feature, but a hypothetical 
cleartype(foo,…) is a safe feature. Imagine having a hypothetical 
IR that makes the unsafe/safe distinction, then you can have both 
memset and cleartype in that IR and transform them into memset at 
the lower level backend without causing problems for memory 
safety verification.

> In the situation of tail pad optimization, it is obviously not 
> valid anymore and will cause memory corruption.

But if you have cleartype() when you do tail pad optimization and 
turn it into memset a codegen then you are ok?

> The discussion then derailed to what is @safe, as the code is 
> certainly @safe, but it is difficult to prove it is 
> automatically) and the fact that @safe is defined backward (ie 
> by listing what is not allowed and adding to the list when new 
> holes are discovered rather than listing what is allowed and 
> adding to the list when some construct are proven to be @safe).

I don't disagree, I think the simplest thing to do is to have a 
hypothetical implied IR between the AST and the backend and 
accept safe features on that level.

I think people who care about @safe also will accept that some 
safe programs are rejected if it is easy to modify the code into 
something the compiler accepts. The compiler could even provide 
suggestions: ("consider using cleartype() over memset()" etc).