About foreach loops

[Timon Gehr]

Jesse Phillips wrote:
> Timon Gehr Wrote:
>
> > Jesse Phillips wrote:
> > > On Wed, 15 Jun 2011 16:40:24 -0400, bearophile wrote:
> > >
> > >> Isn't it undefined in D to modify a const?
> > >
> > > Yes, but unlike what every redditer is say, that doesn't mean the
> > > compiler can do whatever it wants. It means you can't define its
> > > behavior. Go ahead try.
> > > [snip.]
> >
> > How do "cannot do what it wants" and "the behavior cannot be defined" not
> > contradict each other?
>
> Because the compiler can't identify when it happens. Try making the compiler
format your hard drive when you modify const. It can't do what it wants because it
can't define what it will do!

Uh, you could modify DMD to do just that... Left as an exercise. The point is, the
resulting compiler would be compliant with the D spec. Ergo a D compiler can do
just what it wants in case it has compile code with undefined behavior. And how
"can't [the compiler] define what it will do"? It is generating the resulting
executable after all. The compiler is *omnipotent*!

>
> > It may work as you would expect in some cases but not in others. "The compiler can
> > do what it wants". The behavior will depend on what the compiler wants. The way
> > out would be to just define the behavior of casting away const
>
> Casting away const is defined. But once you do, the compiler can no longer
identify when you are modifying its value.
>
> void main(){
>     const a = 53;
>     auto pa = &a;
>     auto pb = cast(int*) pa;
>     assert(*pb == *pa); // Always true, all implementations
>
Yes, I'm perfectly fine with that. See below to learn why it is irrelevant.

>
> > and mutating the
> > memory to do the expected thing in case it is not typed as immutable somewhere in
> > the program.
>
> This is not possible. You don't know where the variable resides

I will now do the same thing you did: Yes I know where it resides, I can
disassemble the resulting executable and there is the address, plain as day!

JK, I guess you did not realize there was a "...and mutating the memory" part in
my statement? =)

> at compile time. The compiler doesn't know where in memory the values are stored
and it isn't allowed to add
> code which checks where the variable is stored. This means if the variable is in
modifiable memory then when you modify it, it will do exactly as you expect, even
if it comes > from an immutable declaration.

I think you did not understand the point. The compiler does not have to check
anything (and why do you think it is not allowed to?), to provide that guarantee.
It just has to act as (following you example below) DMD does at the moment. But
the spec has to reflect this, otherwise, a complying compiler can do anything.

>
> Your examples are flawed, declaring a variable with const is equivalent to
declaring it immutable, the compiler is allowed to place it in read only memory
(or at least that
> is what most people expect, I don't really know if the spec says anything on it).

My examples are not flawed, that is what the discussion was about in the
beginning: rewriting the foreach range loop into the second example. Then
bearophile protested.

>
> void main(){
>     int a = 53;
>     const int* pa = &a;
>     auto pb = cast(int*) pa;
>     assert(*pb == *pa);
>     *pb = 3;
>     assert(*pb == *pa);
> }
>
> This will always be true on every implementation.

No. Not as long as the behavior is undefined.

All existing implementations, true. But all existing implementations use the same
front-end so that is no argument at all. It is certainly not true for the general
case of 'all [possible] implementations'. As long as the spec does not define what
happens if you modify const, _the compiler can do anything!_. Does not mean that
it will do anything specific, such as that what you'd like it to do, just that
theoretically, it *could* format your hard drive, call your grandma, or steal your
identity without breaking language imposed rules.

You may want to have a look at the excellent series about the topic located at
http://blog.regehr.org/archives/213

When I am talking about undefined behavior, I mean this.

Cheers,
- Timon