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 im
r a new one that is not
immutable, and no references to that object escaped the function,
then casting the return type to mutable should work, and I'm not
against that being well-defined, but as I understand it, it
technically isn't, because it involves casting away const and
then mut
On 7/23/15 11:58 PM, Jonathan M Davis wrote:
On Friday, 24 July 2015 at 03:02:30 UTC, Steven Schveighoffer wrote:
Basically, if we say this is undefined behavior, then inout is
undefined behavior.
inout is done by the compiler. It knows that it's safe to cast the
return type to mutable (or imm
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 cons
On Friday, 24 July 2015 at 14:07:46 UTC, Steven Schveighoffer
wrote:
On 7/23/15 11:58 PM, Jonathan M Davis wrote:
On Friday, 24 July 2015 at 03:02:30 UTC, Steven Schveighoffer
wrote:
Basically, if we say this is undefined behavior, then inout is
undefined behavior.
inout is done by the compil
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, I
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 7/24/15 3:35 PM, Jonathan M Davis wrote:
On Friday, 24 July 2015 at 14:07:46 UTC, Steven Schveighoffer wrote:
On 7/23/15 11:58 PM, Jonathan M Davis wrote:
On Friday, 24 July 2015 at 03:02:30 UTC, Steven Schveighoffer wrote:
Basically, if we say this is undefined behavior, then inout is
unde
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?
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 P
On Friday, 24 July 2015 at 20:08:11 UTC, Steven Schveighoffer
wrote:
On 7/24/15 3:35 PM, Jonathan M Davis wrote:
Your case works, because the const reference is gone after the
cast, and
there are no others that were created from the point that it
temporarily
became const. So, it's a very specia
On Friday, 24 July 2015 at 20:44:44 UTC, Steven Schveighoffer
wrote:
The advantage of simply clarifying the spec is that the current
compiler behavior (which should work) doesn't need to change,
we just change the spec.
Ideally, we should just fix the situation with tail-const and
we could ha
On Friday, 24 July 2015 at 21:12:57 UTC, Jonathan M Davis wrote:
Well, regardless of whether mimicking inout like we're talking
about with RedBlackTree should be considered defined behavior
or not, I think that the spec should be updated so that the
situation is clearer. It needs to be clear to
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 it
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 Thursday, 23 July 2015 at 18:43:03 UTC, anonymous wrote:
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/p
On 7/23/15 7:57 PM, Jonathan M Davis wrote:
On Thursday, 23 July 2015 at 18:43:03 UTC, anonymous wrote:
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:
h
17 matches
Mail list logo
