View mode: basic / threaded / horizontal-split · Log in · Help
June 24, 2007
Re: D2.0: an example of use-case for casting invariant away
James Dennett wrote:
> Jason House wrote:
>> Don Clugston wrote:
>>> int* d = cast(break const) b;
>>>
>>> IMHO, we want something that looks really nasty.
>> Based on all the discussion in this thread, I like this alternative
>> best.  I'd only insist that if someone did int *d = cast(int*) b; that
>> the compiler would issue an error saying to use cast(break const) instead
> 
> Interesting: my experience suggests that it shouldn't do so.
> Those who know enough to use cast(break const) appropriately
> will find out how to do so.  Others would just read the error
> message and blindly do what it said, pausing only briefly to
> wonder why the compiler issued an error message if it knew
> exactly how to "fix" the code.  Far too many programmers'
> first reaction to type warnings/errors is to add casts and
> mask the problem rather than addressing root cause.
> 
> -- James

... And what about those programmers who know what they're doing but 
don't know the ins and outs of the language perfectly?  Should they 
start scouring the documentation and news groups to find the proper fix?

IMHO, error messages should be as helpful as possible.  Besides giving a 
new syntax with "break const" embedded within it.  I don't think there's 
really anything else we can do to stop crazy programmers who'll do 
anything to get their code to function.  D has many cool features that 
attracted me to use it, but I'm already near my limit of frustration 
using such a volatile language.

PS: How do you fix a large program that gives just this one compilation 
error (with gdc after compiling and running perfectly with dmd):
/include/d/4.1.1/std/traits.d:134: Error: void initializer has no value

$ head -n 134 /include/d/4.1.1/std/traits.d | tail -n 3
template isStaticArray_impl(T)
{
    const T inst = void;
June 24, 2007
Re: D2.0: an example of use-case for casting invariant away
James Dennett escribió:
> Jason House wrote:
>> Don Clugston wrote:
>>> int* d = cast(break const) b;
>>>
>>> IMHO, we want something that looks really nasty.
>> Based on all the discussion in this thread, I like this alternative
>> best.  I'd only insist that if someone did int *d = cast(int*) b; that
>> the compiler would issue an error saying to use cast(break const) instead
> 
> Interesting: my experience suggests that it shouldn't do so.
> Those who know enough to use cast(break const) appropriately
> will find out how to do so.  Others would just read the error
> message and blindly do what it said, pausing only briefly to
> wonder why the compiler issued an error message if it knew
> exactly how to "fix" the code.  Far too many programmers'
> first reaction to type warnings/errors is to add casts and
> mask the problem rather than addressing root cause.
> 
> -- James

But they're going to find it anyway. They'll read an error message, come here 
and ask what that means, someone will tell them to use cast(break const), and 
they'll be left wondering why the compiler couldn't tell that in the first 
place. Not only that, but after a while it'll become FAQ material.

I agree with your point, but not much will be gained in the end.

-- 
Carlos Santander Bernal
June 25, 2007
Re: D2.0: an example of use-case for casting invariant away
Carlos Santander wrote:
> James Dennett escribió:
>> Jason House wrote:
>>> Don Clugston wrote:
>>>> int* d = cast(break const) b;
>>>>
>>>> IMHO, we want something that looks really nasty.
>>> Based on all the discussion in this thread, I like this alternative
>>> best.  I'd only insist that if someone did int *d = cast(int*) b; that
>>> the compiler would issue an error saying to use cast(break const) instead
>> 
>> Interesting: my experience suggests that it shouldn't do so.
>> Those who know enough to use cast(break const) appropriately
>> will find out how to do so.  Others would just read the error
>> message and blindly do what it said, pausing only briefly to
>> wonder why the compiler issued an error message if it knew
>> exactly how to "fix" the code.  Far too many programmers'
>> first reaction to type warnings/errors is to add casts and
>> mask the problem rather than addressing root cause.
>> 
>> -- James
> 
> But they're going to find it anyway. They'll read an error message, come here 
> and ask what that means, someone will tell them to use cast(break const), and 
> they'll be left wondering why the compiler couldn't tell that in the first 
> place. Not only that, but after a while it'll become FAQ material.
> 
> I agree with your point, but not much will be gained in the end.
> 

What if the error message is something like 'can't assign const int* b 
to non-const int* d'?  If they really want a const cast, they'll then go 
look at the docs for cast expressions to see why it didn't work. 
Otherwise, they'll try making d a const.
June 25, 2007
Re: D2.0: an example of use-case for casting invariant away
Jason House wrote:
> James Dennett wrote:
>> Jason House wrote:
>>> Don Clugston wrote:
>>>> int* d = cast(break const) b;
>>>>
>>>> IMHO, we want something that looks really nasty.
>>> Based on all the discussion in this thread, I like this alternative
>>> best.  I'd only insist that if someone did int *d = cast(int*) b; that
>>> the compiler would issue an error saying to use cast(break const)
>>> instead
>>
>> Interesting: my experience suggests that it shouldn't do so.
>> Those who know enough to use cast(break const) appropriately
>> will find out how to do so.  Others would just read the error
>> message and blindly do what it said, pausing only briefly to
>> wonder why the compiler issued an error message if it knew
>> exactly how to "fix" the code.  Far too many programmers'
>> first reaction to type warnings/errors is to add casts and
>> mask the problem rather than addressing root cause.
>>
>> -- James
> 
> ... And what about those programmers who know what they're doing but
> don't know the ins and outs of the language perfectly? 

They'll know what to do.  This isn't obscure; knowing how to
handle issues such as constness is basic to any language which
supports such a notion.  Programmers who "Know what they're
doing" know what they're doing.  They're just in the minority.

> Should they
> start scouring the documentation and news groups to find the proper fix?

Even if they didn't know, it shouldn't take much to find the
answer.  Typing the error message into Google would likely do
the job.

> IMHO, error messages should be as helpful as possible.  Besides giving a
> new syntax with "break const" embedded within it.  I don't think there's
> really anything else we can do to stop crazy programmers who'll do
> anything to get their code to function. 

You can't stop people writing bad code, but you can avoid
making the bad code easier to write than the good code in
many cases.

-- James
June 25, 2007
Re: D2.0: an example of use-case for casting invariant away
Jason House wrote:
> James Dennett wrote:
>> Jason House wrote:
>>> Don Clugston wrote:
>>>> int* d = cast(break const) b;
>>>>
>>>> IMHO, we want something that looks really nasty.
>>> Based on all the discussion in this thread, I like this alternative
>>> best.  I'd only insist that if someone did int *d = cast(int*) b; that
>>> the compiler would issue an error saying to use cast(break const) 
>>> instead
>>
>> Interesting: my experience suggests that it shouldn't do so.
>> Those who know enough to use cast(break const) appropriately
>> will find out how to do so.  Others would just read the error
>> message and blindly do what it said, pausing only briefly to
>> wonder why the compiler issued an error message if it knew
>> exactly how to "fix" the code.  Far too many programmers'
>> first reaction to type warnings/errors is to add casts and
>> mask the problem rather than addressing root cause.
>>
>> -- James
> 
> ... And what about those programmers who know what they're doing but 
> don't know the ins and outs of the language perfectly?  Should they 
> start scouring the documentation and news groups to find the proper fix?

In general, I agree with you, but remember that in this case, cast(break const) 
is an ugly hack which leads you into undefined behaviour. It's not like C++'s 
const_cast<> which is well-defined.

I don't think we want Microsoft's paperclip:
"You like you're trying to hang yourself, would you some help?". <g>
Hopefully breaking const is very, very rare. If a novice program actually needs 
to break const in ordinary situations, there's a big language problem.
June 25, 2007
Re: D2.0: an example of use-case for casting invariant away
Daniel Keep wrote:
> "Damnit; I don't understand what's going wrong here."
> 
> "It looks like you're modifying const data.  Did you cast const away
> anywhere?"
> 
> "I use unConst, and I already checked all the lines that use that, and
> they're fine!"
> 
> "But what if you *forgot* to use unConst?"
> 
> "... Uh-oh."
> 
> The problem with your suggestions is that unless either A) it's
> compiler-enforced or B) humans suddenly become infallible, it's really
> not solving the problem at all.  If someone forgets to use unConst, or
> worse, casts away const *without realising it*, they're screwed.
> 
> And I *really* doubt B is going to happen.
> 
> 	-- Daniel


If you're not meant to write any cast, how the hell does one 
accidentally write a cast?
(http://www.flicklife.com/edecadcc9a8691762b4f/The_Daily_Show_Server_Crossfire.html 
:P )


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
June 25, 2007
Re: D2.0: an example of use-case for casting invariant away
Reply to Bruno,

> If you're not meant to write any cast, how the hell does one
> accidentally write a cast?

somthing like this maybe?

int[] foo;  // an array of ints

const int[]* pfoo;  // a pointer to an array of ints

auto pdfoo = cast(dchar[]*)pfoo;  // a pointer to the same data but as dchars 


(*pdfoo)[5] = 'h'; //oops
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home