On Friday, 24 July 2015 at 21:12:57 UTC, Jonathan M Davis wrote:
Yeah. That needs to be fixed. As I understand it, it's feasible
without any language improvements, but it's horrific. Jonathan
Crapuchettes talked at one point about doing it at EMSI (and
how hard it was). The last time I tried
to the community at
large that you _cannot_ be casting away const and mutating
simply because you know that the data is mutable underneath
rather than immutable.
Pull request for that:
https://github.com/D-Programming-Language/dlang.org/pull/1047
On 07/24/2015 10:08 PM, Steven Schveighoffer wrote:
We can start with casting away const and mutating, even if you know the
underlying data is mutable, is UB, except for these situations:...
And relax from there.
But what is the point?
within the same function to allow
the possibility that some mutable data changed.
We can start with casting away const and mutating, even if you
know the underlying data is mutable, is UB, except for these
situations:...
The only except that makes any sense to me is when you're casting
away const
of them should be casting away const and
mutating internally.
You seem to be arguing that as long as you know that a const reference
refers to mutable data, it is defined behavior to cast away const and
mutate it.
No. If you *create* a const reference to mutable data, you can cast away
that const
On 7/24/15 4:20 PM, Timon Gehr wrote:
On 07/24/2015 10:08 PM, Steven Schveighoffer wrote:
We can start with casting away const and mutating, even if you know the
underlying data is mutable, is UB, except for these situations:...
And relax from there.
But what is the point?
The original PR
is clearer. It needs to be clear to the community at
large that you _cannot_ be casting away const and mutating simply
because you know that the data is mutable underneath rather than
immutable.
- Jonathan M Davis
as the compiler can actually rely on const not being
mutated.
And my interpretation of the spec doesn't change this. You can still
elide those calls as none of them should be casting away const and
mutating internally.
But part of the problem with start doing more than it does now
On 7/24/15 3:02 PM, Timon Gehr wrote:
On 07/23/2015 10:20 PM, Steven Schveighoffer wrote:
On 7/23/15 2:43 PM, anonymous wrote:
Steven disagrees and thinks that there are cases where it's ok. Namely,
this simple case would be ok:
int x;
const int *y = x;
*(cast(int *)y) = 5;
Yes,
On 07/24/2015 09:43 PM, Steven Schveighoffer wrote:
On 7/24/15 3:02 PM, Timon Gehr wrote:
On 07/23/2015 10:20 PM, Steven Schveighoffer wrote:
On 7/23/15 2:43 PM, anonymous wrote:
Steven disagrees and thinks that there are cases where it's ok. Namely,
this simple case would be ok:
int x;
On 07/23/2015 10:20 PM, Steven Schveighoffer wrote:
On 7/23/15 2:43 PM, anonymous wrote:
Steven disagrees and thinks that there are cases where it's ok. Namely,
this simple case would be ok:
int x;
const int *y = x;
*(cast(int *)y) = 5;
Yes, IMO, this should simply work and be
something like that would never be implemented in the
compiler, but it
could be as long as the compiler can actually rely on const
not being
mutated.
And my interpretation of the spec doesn't change this. You can
still elide those calls as none of them should be casting away
const and mutating
, if you're _really_
careful, you can get away with casting away const and mutating a
variable, but you are depending on undefined behavior.
Steven disagrees and thinks that there are cases where it's ok.
Namely, this simple case would be ok:
int x;
const int *y = x;
*(cast(int *)y) = 5
on that. So, if you're casting away const and
mutating, relying on no one coming up with new optimizations,
then you could be in trouble later when they do. And maybe they
won't, but we don't know.
Specifically, I would say you can cast away const on a
reference that you have created within
working correctly. So, if
you're _really_ careful, you can get away with casting away const and
mutating a variable, but you are depending on undefined behavior.
An example of what the compiler can start doing more than it does now
would be helpful. I can't see how it can do anything based
On 7/23/15 2:43 PM, anonymous wrote:
Steven disagrees and thinks that there are cases where it's ok. Namely,
this simple case would be ok:
int x;
const int *y = x;
*(cast(int *)y) = 5;
Yes, IMO, this should simply work and be consistent. The compiler could
use willful ignorance to
On a GitHub pull request, Steven Schveighoffer (schveiguy),
Jonathan M Davis (jmdavis), and I (aG0aep6G) have been discussing
if or when it's ok to cast away const and then mutate the data:
https://github.com/D-Programming-Language/phobos/pull/3501#issuecomment-124169544
I've been under the
17 matches
Mail list logo
