Constructing a class in-place

[Johan Engelen]

On Thursday, 26 July 2018 at 21:22:45 UTC, Petar Kirov 
[ZombineDev] wrote:
>
> Please excuse if my question is too naive, but how does this 
> change anything?

The main insight is to reason about things in terms of language 
semantics, not in terms of actual memory addresses and 
instructions as processed by the CPU. Then reread my post. I am 
not talking about disallowing storing different objects in the 
same physical hardware memory location: the language spec says 
nothing about that, and it shouldn't.

> Nothing stops the same bytes from being reused for another 
> object of a different type.

Here you are talking about physical memory bits, which is none of 
the language's business. So in practice, of course memory will be 
reused. But (most of) that should be transparent to D's language 
semantics.

> D on the other hand is (or at least I'm hopeful that it is) 
> moving away giving magical powers to its runtime or standard 
> library and is its embracing the spirit of bare bones systems 
> programming where the programmer is allowed or even encouraged 
> to implement everything from scratch (cref -betterC) for when 
> that is the most sensible option.

This is a matter of opinion I guess. But why wouldn't you just 
program in assembly? For example, things like 
`__traits(isReturnOnStack)` don't make sense in a high level 
language like D. Some machines don't have a stack. In other 
cases, the decision whether to return something on the stack can 
be delayed until optimization for better performance. I see you 
mention LTO; forget about _any_ optimization and high-level 
language features, if you care about controlling what the machine 
is doing.

> While C and C++ approach portability by abstracting the 
> machine, the approaches portability by laying all the cards on 
> the table and defining things, rather than letting them be 
> unspecified or at least documenting the implementation 
> definition.

The kind of low-level control that you want is not what D should 
give (and doesn't). With "laying cards on the table" you mean 
specifying language semantics in hardware behavior? Because the 
strength of most languages is in _not_ doing that. (some of the 
strengths that'd be lost: cross platform, cross architecture, 
performance)

Note that this is not only about optimization. It's about being 
able to reason sensibly about code. You are advocating this?
```
class A { virtual void foo(); }
class B : A { ... }
class C : A { ... }

void bar(A a) {
    a.foo(); // type of a is B, but turns it into C
    a.foo(); // type is now C, call different foo
}
```

- Johan