About foreach loops

[Timon Gehr]

Jesse Phillips wrote:
> Timon Gehr Wrote:
>
> > 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!
>
> Not possible, the executable can not contain an address because nothing is in
memory to have an address.

Uh... You don't actually know the internals of executables, do you? Because if you
do, please clarify your statement.

>
> > JK, I guess you did not realize there was a "...and mutating the memory" part in
> > my statement? =)
>
> I did see that but you must first understand that casting away const is defined.
Once this is done though the compiler can no longer identify when something that
was once
> const is now being modified.

I understand that.

>
> The behavior of modifying an int* is also defined, and when you cast away const
to get an int* you maybe modifying what use to be a const variables, but the
compiler does not > know that.

Nope. As soon as you invoke undefined behavior, even the behavior of modifying an
int* is not defined anymore. Encountering undefined behavior makes your whole
program nonsensical. It does not matter if the compiler knows that. It could know
if its developer wanted it to.

>
> > > at compile time. The compiler doesn't know where in memory the values are stored
> > 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.
>
> No it can not provide that guarantee at no cost. It is allowed to do
optimizations on const variables, I can not tell what optimizations the compiler
could preform as I don't > think there are any at this time, but why restrict
future geniuses?

You cannot perform optimizations on const variables, because they don't give more
guarantees than mutable variables. They only impose restrictions. It is as simple
as that. If you want guarantees and optimizations, use immutable variables.

>
> Sorry shouldn't have brought up extra code, if you can come up with some code or
design that can identify when a const value has changed, within the current
guidelines of the > spec the more power to you.

You can perform a runtime-check. But you don't need to to give the guarantee that
casting away const from a reference to mutable memory will give you a valid
reference through which that memory can be modified.

>
> > 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.
>
> This is an implementation detail of foreach that can be made to work with DMD.

I think it is not worth the special casing, but sure.

>
> Though this does bring up a point you aren't trying to make. There are places
where the compiler can statically identify you are modifying const and put in any
code it wants, > but it still can't define what happens when you modify const.

Sure, because the const could reference immutable memory.

>
> >
> > >
> > > 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.
>
> Yes even if it is undefined.

defined behavior <=> it must always behave that way on every implementation.
undefined behavior <=> the behavior could be anything, but it might also be what
you expected.

There is nothing more to it.

>
> > 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 are correct, that it could theoretically do all those things and still be
valid to the spec. But it can't be done, not without breaking some other aspect of
the spec.

So it is theoretically possible, yet impossible? This fails to sound like a fair
point. Which aspect would be broken?

>
> > 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.
>
> Yes I've read his posts. And many of them the compiler knows what is happening
or the hardware is even able to detect the behavior. But in the case of modifying
const, you
> can't identify it to make it defined.

You don't need to identify it to make the behavior defined just if it is actually
pointing to mutable memory. The compiler does not know what is going on, it is
simply ignoring it to generate faster code within the spec.

>
> I haven't been touching on the main reason it isn't defined, could be an
immutable value. You are just asking for defining when it does point to a mutable
value. It is like
> trying to define gravity as the force that keeps you on the earth. It does do a
good job of that but only because of the properties of gravity.

Your analogy has nothing to do with the issue. A better one.

You have two classes of items.

1. Tea Cups. Dropping them to the floor will break them.
2. The magical flubber slime ball from outer space (TMFSBFOS). Dropping it to the
floor will have undefined behavior.

Now you have a set of equal boxes, each containing either a Tea Cup or the magical
flubber slime ball from outer space. You have no way to know what it is.

Now, a quick wrap-up of our points:
Timon: Now what happens if you drop one of these boxes?
Jesse: The behavior is undefined, because it could contain the magical flubber
slime ball from outer space!
Timon: And if there is a tea cup in there?
Jesse: The behavior is undefined, because it could contain the magical flubber
slime ball from outer space!
Timon: Well, no it is a tea cup. What happens if you drop a tea cup?
Jesse: It breaks.
Timon: Yes, and if it is in a box?
Jesse: The behavior is still undefined!
Timon: No. The tea cup breaks.
Jesse: Yes that is what happens, always happened and will always happen in all
circumstances, yet the behavior is undefined. Also, white is black.


Cheers,
-Timon