> You, as the guy who wrote the code, will (or should) know that there are no other live references, hence you are telling the compiler "trust me, I know there aren't any".

So, is the intended meaning the following: If there exist any immutable references to the data, mutating it results in undefined behavior? If so, I think the documentation on creating immutable data should explicitly say so.

On 12/15/2013 4:22 PM, jerro wrote:
>> You, as the guy who wrote the code, will (or should) know that there are no
>> other live references, hence you are telling the compiler "trust me, I know
>> there aren't any".
>
> So, is the intended meaning the following: If there exist any immutable
> references to the data, mutating it results in undefined behavior? If so, I
> think the documentation on creating immutable data should explicitly say so.


Good idea. I suggest writing a pull request against the documentation for this.

On Sunday, 15 December 2013 at 22:53:19 UTC, 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
>
> anyhow.
> since we are programmers we can change meaning perfectly well
> <code>
> alias good bad;
> </code> there :D
>
> Undefined behaviour may have a precise meaning to a academic, but for me as a programmer it means. AVOID THIS SITUATION !!! 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.
>
>
> 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.

Strict, well-defined definitions are important for communication on technical subjects.

Undefined behaviour means "goodbye logic". Excepting the extreme case of hacking something for a specific compiler version, you should never use it. By definition, you cannot know what you're doing.

Having mutable references to immutable data is not undefined behaviour. The normal logic of the program is guaranteed to not be broken by them.
The line lies at modifying the data, not at the existence of the reference.

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.

On 12/16/2013 01:53 AM, Walter Bright wrote:
> On 12/15/2013 4:22 PM, jerro wrote:
>>> You, as the guy who wrote the code, will (or should) know that there
>>> are no
>>> other live references, hence you are telling the compiler "trust me,
>>> I know
>>> there aren't any".
>>
>> So, is the intended meaning the following: If there exist any immutable
>> references to the data, mutating it results in undefined behavior? If
>> so, I
>> think the documentation on creating immutable data should explicitly
>> say so.
>
>
> Good idea. I suggest writing a pull request against the documentation
> for this.

We need to be careful to do this right.

Consider what happens when we want to dispose memory using our custom allocator. The caller clearly needs to own an immutable reference in order to cast it to mutable and pass it to the storage allocator, where it will be freed in some way that will sometimes involve updating some metadata accessible through it. The immutable reference will not be gone during this process. [1]

Furthermore, existence of references may be indeterministic due to the garbage collector, and the language does not make any guarantees that anything is ever collected at all.

Informally speaking, the final specification should probably allow in some way immutable references to mutated data to _exist_, but not define _access_ to them.



[1] The language does not allow ownership to be tracked.

Am Sun, 15 Dec 2013 16:53:21 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 12/15/2013 4:22 PM, jerro wrote:
> >> You, as the guy who wrote the code, will (or should) know that there are no other live references, hence you are telling the compiler "trust me, I know there aren't any".
> >
> > So, is the intended meaning the following: If there exist any immutable references to the data, mutating it results in undefined behavior? If so, I think the documentation on creating immutable data should explicitly say so.
> 
> 
> Good idea. I suggest writing a pull request against the documentation for this.

+1. I kept telling people that casting immutable to mutable and vice-versa is undefined behavior, based on that page.

-- 
Marco

On Wednesday, 11 December 2013 at 00:19:50 UTC, H. S. Teoh wrote:
> hardware. So arguably, no matter what code fragment you may  present in
> C++ or D, there's always a corresponding C code fragment that performs
> equally fast or faster.

Yes, but the unix/C-way is to have many simple programs that work together to make complex systems. C is meant to be used with makefiles and source-generating tools such as Lex, Ragel and even the C-preprocessor. C++ and D claim to be self-sufficient. C was never meant to be, it was meant to be part of the unix eco-system. What you do with templates and and compile-time-expressions in C++/D is what you do with the ecosystem of tools in C. Therefore a comparison between C and C++/D should include that C-ecosystem. If people don't like sourcecode-generating tools, fine, but that is the unix/C way of programming and it should be included when assessing the power of C versus C++/D (and their template libraries).

> But that obscures the fact that said C  code
> fragment may be written in an unmanageably convoluted style that no one in their right mind would actually use in practice.

Well, C-programmers do, if they have tools that generate that convoluted style from a readable input file (like lex).

> but that proves nothing since the whole issue is writing  *idiomatic* C
> vs. *idiomatic* D, not writing things in an unnatural way just so you can lay claim to the title of best performance.)

Exactly, and idiomatic C is to use source-generating tools. Just about all medium to large size C projects use such tools that go beyond the C-preprocessor (which conceptually is a separate tool that is optional in theory).

Anyway, one cannot discuss performance without discussing the target. Much of the stuff in C makes sense on memory-constrained hardware, even C-strings are great when you want to conserve memory and have hardware-support for 0-guarded strings (string-instructions that will stop on 0).  And, JITed regexps won't work on mobile platforms or platforms that require signed code.

We are now getting a new range of memory constrained hardware, transputer-like processsors with many simple cores with fast local memory and a saturated link to main memory. So the memory-efficent way of getting performance is still highly relevant.

Performance is always contextual. E.g. I think OpenCL is just an intermediate step to getting performance, compilers will soon have to emit co-processor friendly code automagically and languages will have to provide constructs that makes that happen in the most efficient way. So if C is out-dated then so are all other languages in current use… ;-)

O.

On Monday, 16 December 2013 at 00:53:21 UTC, Walter Bright wrote:
> On 12/15/2013 4:22 PM, jerro wrote:
>>> You, as the guy who wrote the code, will (or should) know that there are no
>>> other live references, hence you are telling the compiler "trust me, I know
>>> there aren't any".
>>
>> So, is the intended meaning the following: If there exist any immutable
>> references to the data, mutating it results in undefined behavior? If so, I
>> think the documentation on creating immutable data should explicitly say so.
>
>
> Good idea. I suggest writing a pull request against the documentation for this.

That is a bad idea as it preclude any GC optimization based on immutability.

On Monday, 16 December 2013 at 17:32:11 UTC, deadalnix wrote:
> On Monday, 16 December 2013 at 00:53:21 UTC, Walter Bright
>> Good idea. I suggest writing a pull request against the documentation for this.
>
> That is a bad idea as it preclude any GC optimization based on immutability.

What do you mean by this? How can a change in the documentation preclude GC optimization? Does our GC read docs to understand what can be collected? Now I get it: it's a stop the world, then RTFM, then collect GC implementation :)

On 12/16/13 5:35 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Wednesday, 11 December 2013 at 00:19:50 UTC, H. S. Teoh wrote:
>> hardware. So arguably, no matter what code fragment you may present in
>> C++ or D, there's always a corresponding C code fragment that performs
>> equally fast or faster.
>
> Yes, but the unix/C-way is to have many simple programs that work
> together to make complex systems. C is meant to be used with makefiles
> and source-generating tools such as Lex, Ragel and even the
> C-preprocessor. C++ and D claim to be self-sufficient. C was never meant
> to be, it was meant to be part of the unix eco-system. What you do with
> templates and and compile-time-expressions in C++/D is what you do with
> the ecosystem of tools in C. Therefore a comparison between C and C++/D
> should include that C-ecosystem. If people don't like
> sourcecode-generating tools, fine, but that is the unix/C way of
> programming and it should be included when assessing the power of C
> versus C++/D (and their template libraries).
>
>> But that obscures the fact that said C  code
>> fragment may be written in an unmanageably convoluted style that no
>> one in their right mind would actually use in practice.
>
> Well, C-programmers do, if they have tools that generate that convoluted
> style from a readable input file (like lex).
>
>> but that proves nothing since the whole issue is writing *idiomatic* C
>> vs. *idiomatic* D, not writing things in an unnatural way just so you
>> can lay claim to the title of best performance.)
>
> Exactly, and idiomatic C is to use source-generating tools. Just about
> all medium to large size C projects use such tools that go beyond the
> C-preprocessor (which conceptually is a separate tool that is optional
> in theory).

Nonsense. Using extralinguistic tools including code generators is not the exclusive appurtenance of C. Any large project uses some for various purposes. Needless to say, extralinguistic generators often compare poorly with language-integrated solutions. Look where the preprocessor has taken C - it's compromised the entire notion of preprocessing. And m4, more powerful and supposedly better, has only spawned more madness.

> Anyway, one cannot discuss performance without discussing the target.
> Much of the stuff in C makes sense on memory-constrained hardware, even
> C-strings are great when you want to conserve memory and have
> hardware-support for 0-guarded strings (string-instructions that will
> stop on 0).  And, JITed regexps won't work on mobile platforms or
> platforms that require signed code.
>
> We are now getting a new range of memory constrained hardware,
> transputer-like processsors with many simple cores with fast local
> memory and a saturated link to main memory. So the memory-efficent way
> of getting performance is still highly relevant.
>
> Performance is always contextual. E.g. I think OpenCL is just an
> intermediate step to getting performance, compilers will soon have to
> emit co-processor friendly code automagically and languages will have to
> provide constructs that makes that happen in the most efficient way. So
> if C is out-dated then so are all other languages in current use… ;-)

Current applications also demand good modeling power. The days when one thousand lines was a nontrivial program are behind us. The right solution is a language that combines performance control with the modeling required by large applications.


Andrei