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
