Inherent code performance advantages of D over C?

[Timon Gehr]

On 12/15/2013 11:53 PM, Uplink_Coder wrote:
> On Sunday, 15 December 2013 at 11:52:17 UTC, Timon Gehr wrote:
>> On 12/15/2013 02:20 AM, Walter Bright wrote:
>>> On 12/14/2013 4:36 PM, Timon Gehr wrote:
>>>> I cannot cast data from my own storage allocator to immutable
>>>> because the
>>>> behaviour will be undefined.
>>>>
>>>> http://dlang.org/const3.html
>>>>
>>>> Is this a documentation bug? What should be the actual rules?
>>>
>>> It means it's up to you to ensure it is correct.
>>
>> Undefined behaviour is a term with a precise meaning. That site says
>> that casting a reference to immutable while there are still live
>> mutable references to memory reachable by that reference leads to
>> undefined behaviour. It is not possible to 'ensure it is correct'.
>
> being picky with words is not the right way to argue :D
>

Of course it is. http://en.wikipedia.org/wiki/Mathematical_logic
Logic is the right way to reason whenever it is applicable. An example 
of when it is not applicable is during a debate on whether the last 
statement was valid. However, reasonable people will agree.

Here the goal is to describe programming language semantics in a precise 
way, so logic is clearly applicable. Knowing what one is actually saying 
(relative to some logic) is necessary in order to do this in any 
meaningful fashion.

>
> anyhow.
> since we are programmers we can change meaning perfectly well
> <code>
> alias good bad;
> </code> there :D

I see neither your point nor how your example illustrates it.

> Undefined behaviour may have a precise meaning to a academic, but for me
> as a programmer it means. AVOID THIS SITUATION !!!

This is close enough to the "precise academic meaning" to leave 
everything I have stated meaningful.

> unless you know what you do!
> Undefined behaviour for a compiler is a point where certin garuntees MAY
> be broken. casting something says : "Compiler my friend: Trust Me, I
> know what I do"  and since neither the compiler nor the compiler-writer
> can know wether you are REALLY trustworthy it can't and doesn't define
> behaviour for that case.
>

This part is nonsense. (Also, we are not arguing about what some 
specific compiler is doing. A specific compiler version will usually 
define the semantics of a portion of code for each back-end architecture 
in a more fine-grained way than mandated by the language standard, 
specified in its documentation and/or unspecified.)

The language defines behaviour conditional on "trustworthiness of the 
programmer". E.g. dereferencing a pointer in C has defined behaviour as 
long as the pointer is valid, according to a precise definition of 
valid. It is not the case that dereferencing a pointer in C never has 
defined behaviour just because one cannot verify validity automatically 
in general. This does not have to be possible in order to have a 
meaningful language specification.

>
> In this case you have to picture langauge as obeying the open-closed
> principle.
> The advice Walter gave was adding to the avilable Information not
> subsituting it.

Hence I was asking whether the spec is in need of an update.