View mode: basic / threaded / horizontal-split · Log in · Help
September 11, 2007
Re: cast(!const) proposal
While I think of it, casting from const pointer to int should also be
illegal without that same special syntax.

For example

const int n = 42;
auto p = &n;
auto k = cast(int)p; /* should be a compile error */

Do we have intptr_t in D?

Anyway, losing the constness by casting to int is cheating, so that
too should require the special syntax.
September 11, 2007
Re: cast(!const) proposal
"Janice Caron" wrote
> While I think of it, casting from const pointer to int should also be
> illegal without that same special syntax.
>
> For example
>
> const int n = 42;
> auto p = &n;
> auto k = cast(int)p; /* should be a compile error */
>
> Do we have intptr_t in D?
>
> Anyway, losing the constness by casting to int is cheating, so that
> too should require the special syntax.

I don't agree.  You are getting into Java-style hide-all-pointers 
terminology here.  If we are to have pointers, then I think we are going to 
have to agree that there will be ways to do *bad* things with them.  I can 
think of other ways to circumvent your const rule about casting to int that 
will allow code to change const data without having to use the cast(!const). 
I don't think it will be possible to get around all these possibilities with 
compiler errors.

My opinion is that any time you are casting away const, you should need the 
special cast(!const).  If you are doing funky things to get around that 
rule, then you are on your own.

patient: "doctor, it hurts when I do this!"
doctor: "then don't do that."

-Steve
September 11, 2007
Re: cast(!const) proposal
On 9/11/07, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> I don't agree.

Seems to me that you and I are actually in complete agreement. (Well,
one of my replies starts with "But" - see below).

> If we are to have pointers, then I think we are going to
> have to agree that there will be ways to do *bad* things with them.

Of course.

>  I can
> think of other ways to circumvent your const rule about casting to int that
> will allow code to change const data without having to use the cast(!const).

So can I. I even gave an example on another thread, with a working demo.


> I don't think it will be possible to get around all these possibilities with
> compiler errors.

But it *will* be possible to outlaw cast(T)x, wherever T has different
const characteristics from typeof(x). As soon as the compiler sees
that, it can insist on cast(!const)x or cast(!const T)x.


> My opinion is that any time you are casting away const, you should need the
> special cast(!const).

That's what I said.

> If you are doing funky things to get around that
> rule, then you are on your own.

I said that too.

So fear not - I think we're on the same page here.
:-)
September 11, 2007
Re: cast(!const) proposal
"Janice Caron" wrote
> On 9/11/07, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> I don't agree.
>
> Seems to me that you and I are actually in complete agreement. (Well,
> one of my replies starts with "But" - see below).

Hm... in that case, I misunderstood this extra "pointer to int" 
specification, and I also don't understand why this even needs to be 
specified :)  It seems redundant.

I interpreted your post as you were trying to say if you have a mutable 
pointer to immutable data, you cannot cast the mutable pointer type into a 
mutable integer without doing a !const cast.  That was where my disagreement 
was.  Since the pointer is mutable, it should be perfectly legal to cast it 
into another compatible mutable type without a !const cast.

yes/no?

-Steve
September 11, 2007
Re: cast(!const) proposal
On 9/11/07, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> I interpreted your post as you were trying to say if you have a mutable
> pointer to immutable data, you cannot cast the mutable pointer type into a
> mutable integer without doing a !const cast.

I was.


> That was where my disagreement was.

Oh. Right. Well then, I guess that /was/ a disagreement. But I've
changed my mind now and I think you're right.


> Since the pointer is mutable, it should be perfectly legal to cast it
> into another compatible mutable type without a !const cast.

You can argue either way. My take was that, without a cast(!const),
the only thing you should be allowed to convert a pointer-to-const
into is another pointer-to-const.

(You should be allowed to add constness, of course, but not to remove it).

This isn't about catching tricksters, it's about preventing
/accidents/. So if I type:

auto n = cast(intptr_t) p;

I thought it might be kinda nice if the compiler could "remind" me if
p was a pointer-to-const, so that I didn't do it by accident.

But on second thoughts, there's really no justification for insisting
on a cast(!const) here, because const-correctness isn't necessarily
being abused.

Points to you on this one then. :-)
Cheers
September 12, 2007
Re: cast(!const) proposal
"Janice Caron" wrote
> The syntax that I suggest for this is:
>
> auto q = cast(!const)p;

A crazy thought just occurred to me.  If we are successful in lobbying for 
the mutable keyword, I think this could become:

cast(mutable)p;

looks a lot more straightforward than !const, especially when ! is used in 
templates.

-Steve
September 12, 2007
Re: cast(!const) proposal
On Wed, 12 Sep 2007 14:17:44 -0400, Steven Schveighoffer wrote:

> "Janice Caron" wrote
>> The syntax that I suggest for this is:
>>
>> auto q = cast(!const)p;
> 
> A crazy thought just occurred to me.  If we are successful in lobbying for 
> the mutable keyword, I think this could become:
> 
> cast(mutable)p;
> 
> looks a lot more straightforward than !const, especially when ! is used in 
> templates.

Yes! That is just right, and thus will never see the light of day :-)

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home