An important point is that implicit casting where it's not guaranteed to be safe is DANGEROUS.

And especially in large systems of code and in later maintenance changes.

THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN TIME.

It should be reconsidered whether or not it breaks Phobos or other projects developed or in-work.  Explicit casting need not have such limitations - it can be searched for and any problems can be dealt with.  The correction of the limited amount of long-term current code can be fixed by explicit casting when the compiler starts rejecting it.

-larry

In article <c1g43k$11he$1@digitaldaemon.com>, J Anderson says...
>
>Sark7 wrote:
>
>> I think that implicit casting from greater space to lesser space should be not allowed, because imho it isn't logically correct.
>>
>> for example:
>>
>> unit -> int  // ok
>
>But uint's can be greater then int's.  I don't think either should be allowed without a cast.
>
>> int  -> uin  // error
>>
>> float -> double // ok
>> double -> float // error
>>
>> int   -> float // ok
>> float -> int   // error
>
>I think float/double to int should also have a forced cast.  Most of the time you are using floating point for calculations that need the fraction part and accidental conversion to int can be a real problem.
>
>However, I think these things are to late to change now, it's kinda engrained in D now and would cause to many changes in stuff that is already written.
>
>-- 
>-Anderson: http://badmama.com.au/~anderson/

Just playing devils advocate:

larry cowan wrote:

>An important point is that implicit casting where it's not guaranteed to be safe
>is DANGEROUS.
>
>And especially in large systems of code and in later maintenance changes.
>
>THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS
>BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
>SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN
>TIME.
>  
>
I think this *feature* could be argued both ways, so IMHO I think it is best to stick with what we have at the moment.

>It should be reconsidered whether or not it breaks Phobos or other projects
>developed or in-work.  Explicit casting need not have such limitations - it can
>be searched for and any problems can be dealt with.  The correction of the
>limited amount of long-term current code can be fixed by explicit casting when
>the compiler starts rejecting it.
>  
>
It's difficult to grep and therefore in most cases would have to be done by hand.  However its merits should be considered of course.

>-larry
>  
>
-- 
-Anderson: http://badmama.com.au/~anderson/

I completely agree, fixing the pre-existing code should not be too dificult , even if its all by hand.

C

On Tue, 24 Feb 2004 19:09:42 +0000 (UTC), larry cowan <larry_member@pathlink.com> wrote:

> An important point is that implicit casting where it's not guaranteed to be safe
> is DANGEROUS.
>
> And especially in large systems of code and in later maintenance changes.
>
> THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS
> BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
> SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN
> TIME.
>
> It should be reconsidered whether or not it breaks Phobos or other projects
> developed or in-work.  Explicit casting need not have such limitations - it can
> be searched for and any problems can be dealt with.  The correction of the
> limited amount of long-term current code can be fixed by explicit casting when
> the compiler starts rejecting it.
>
> -larry
>
> In article <c1g43k$11he$1@digitaldaemon.com>, J Anderson says...
>>
>> Sark7 wrote:
>>
>>> I think that implicit casting from greater space to lesser space
>>> should be not allowed, because imho it isn't logically correct.
>>>
>>> for example:
>>>
>>> unit -> int  // ok
>>
>> But uint's can be greater then int's.  I don't think either should be
>> allowed without a cast.
>>
>>> int  -> uin  // error
>>>
>>> float -> double // ok
>>> double -> float // error
>>>
>>> int   -> float // ok
>>> float -> int   // error
>>
>> I think float/double to int should also have a forced cast.  Most of the
>> time you are using floating point for calculations that need the
>> fraction part and accidental conversion to int can be a real problem.
>>
>> However, I think these things are to late to change now, it's kinda
>> engrained in D now and would cause to many changes in stuff that is
>> already written.
>>
>> --
>> -Anderson: http://badmama.com.au/~anderson/
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

larry cowan wrote:
> An important point is that implicit casting where it's not guaranteed to be safe
> is DANGEROUS.
> 
> And especially in large systems of code and in later maintenance changes.
> 
> THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS
> BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A
> SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN
> TIME.
> 
> It should be reconsidered whether or not it breaks Phobos or other projects
> developed or in-work.  Explicit casting need not have such limitations - it can
> be searched for and any problems can be dealt with.  The correction of the
> limited amount of long-term current code can be fixed by explicit casting when
> the compiler starts rejecting it.

I do agree, and while I've not written large amounts of D code yet, but I would think that when writing code for a language/compiler that is unfinished and incomplete, language changes breaking code really ought not be that big a concern. Especially since D is a language that *does* break backwards compatability to its 'ancestors' C/C++ *precisely* because it wants to deal with problems. Do we really wish to deal with problems in D simply because by 0.79 it was 'too late' to fix them?

Besides, and not to step on anybody's toes, but I wouldn't say enormous amounts of code has been written for D at this point, relatively speaking. It would certainly be better to fix the problem that implicit casting can be now than for D 2.0.

Cheers,
Sigbjørn Lund Olsen

In article <c1g8fi$1978$1@digitaldaemon.com>, J Anderson says...
>
>Just playing devils advocate:
>
>larry cowan wrote:
>
>>An important point is that implicit casting where it's not guaranteed to be safe is DANGEROUS.
>>
>>And especially in large systems of code and in later maintenance changes.
>>
>>THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO THINGS BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER IN TIME.
>> 
>>
>I think this *feature* could be argued both ways, so IMHO I think it is best to stick with what we have at the moment.
>

I understand, but like I mentioned, it's easy to include in the spec now, valuable, and need not be included in the 1.0 compiler which will have errors if only in things we haven't found yet.  It should be considered on its merits.

>>It should be reconsidered whether or not it breaks Phobos or other projects developed or in-work.  Explicit casting need not have such limitations - it can be searched for and any problems can be dealt with.  The correction of the limited amount of long-term current code can be fixed by explicit casting when the compiler starts rejecting it.
>> 
>>
>It's difficult to grep and therefore in most cases would have to be done by hand.  However its merits should be considered of course.
>

As far as grepping for explicit casts, it needs only anything with reasonable re-like acceptance, and could be either for 'cast' or 'cast\s*\(float\s*\**\)' or some such.  If grep wouldn't find what you wanted, a simple perl program could scan the code.

>>-larry
>> 
>>
>-- 
>-Anderson: http://badmama.com.au/~anderson/

Coulnd't agree more.

But, ouch!, that shouting hurt my eyes. ;/

"larry cowan" <larry_member@pathlink.com> wrote in message news:c1g7hm$17is$1@digitaldaemon.com...
> An important point is that implicit casting where it's not guaranteed to
be safe
> is DANGEROUS.
>
> And especially in large systems of code and in later maintenance changes.
>
> THIS SHOULD BE A CONCERN OF A LANGUAGE WHICH ASPIRES TO MAKE THOSE TWO
THINGS
> BETTER AND EASIER!  IT SHOULOD BE RECONSIDERED BEFORE 1.0 COMES OUT - AS A SPECIFICATION ITEM WHETHER OR NOT IT CAN BE FIXED IN THE CURRENT COMPILER
IN
> TIME.
>
> It should be reconsidered whether or not it breaks Phobos or other
projects
> developed or in-work.  Explicit casting need not have such limitations -
it can
> be searched for and any problems can be dealt with.  The correction of the limited amount of long-term current code can be fixed by explicit casting
when
> the compiler starts rejecting it.
>
> -larry
>
> In article <c1g43k$11he$1@digitaldaemon.com>, J Anderson says...
> >
> >Sark7 wrote:
> >
> >> I think that implicit casting from greater space to lesser space should be not allowed, because imho it isn't logically correct.
> >>
> >> for example:
> >>
> >> unit -> int  // ok
> >
> >But uint's can be greater then int's.  I don't think either should be allowed without a cast.
> >
> >> int  -> uin  // error
> >>
> >> float -> double // ok
> >> double -> float // error
> >>
> >> int   -> float // ok
> >> float -> int   // error
> >
> >I think float/double to int should also have a forced cast.  Most of the time you are using floating point for calculations that need the fraction part and accidental conversion to int can be a real problem.
> >
> >However, I think these things are to late to change now, it's kinda engrained in D now and would cause to many changes in stuff that is already written.
> >
> >-- 
> >-Anderson: http://badmama.com.au/~anderson/
>
>

J Anderson wrote:
> Just playing devils advocate:
> 
> larry cowan wrote:
> 
>> An important point is that implicit casting where it's not guaranteed to be safe
>> is DANGEROUS.
>>
>> And especially in large systems of code and in later maintenance changes.
>>
[...]
> It's difficult to grep and therefore in most cases would have to be done by hand.  However its merits should be considered of course.

I think it'd be impossible to grep, but at least the compiler error messages should point to the code that needs correcting. I'm not sure if it needs changing, but if something this fundamental is going to be changed, now is our opportunity to make the change. Pretty soon, the door will close on that chance.

D 1.0 hasn't arrived yet, and I don't think we'd be able to make a change here once it does arrive.


-- 
Justin
http://jcc_7.tripod.com/d/

J C Calvarese wrote:

> J Anderson wrote:
>
> I think it'd be impossible to grep, but at least the compiler error messages should point to the code that needs correcting. I'm not sure if it needs changing, but if something this fundamental is going to be changed, now is our opportunity to make the change. Pretty soon, the door will close on that chance.
>
> D 1.0 hasn't arrived yet, and I don't think we'd be able to make a change here once it does arrive.


With my other hat:

It is something I like from C++ with all warnings (maximum level) as errors set.  Actually I think that just about all c++ warnings (maximum level) should become errors in D.

-- 
-Anderson: http://badmama.com.au/~anderson/

On Wed, 25 Feb 2004 09:13:09 +0800 (02/25/04 12:13:09)
, J Anderson <REMOVEanderson@badmama.com.au> wrote:

> J C Calvarese wrote:
>
>> J Anderson wrote:
>>
>> I think it'd be impossible to grep, but at least the compiler error messages should point to the code that needs correcting. I'm not sure if it needs changing, but if something this fundamental is going to be changed, now is our opportunity to make the change. Pretty soon, the door will close on that chance.
>>
>> D 1.0 hasn't arrived yet, and I don't think we'd be able to make a change here once it does arrive.
>
>
> With my other hat:
>
> It is something I like from C++ with all warnings (maximum level) as errors set.  Actually I think that just about all c++ warnings (maximum level) should become errors in D.
>

Doesn't an error imply that D cannot continue compiling, whereas a warning means that D can continue but the results may not be what the coder expects.

A *potential* loss of data due to implicit cast conversions would therefore only warrant a warning at best, as D can continue compiling.

-- 
Derek


-- 
Derek

J Anderson wrote:
> J C Calvarese wrote:
> 
>> J Anderson wrote:
>>
>> I think it'd be impossible to grep, but at least the compiler error messages should point to the code that needs correcting. I'm not sure if it needs changing, but if something this fundamental is going to be changed, now is our opportunity to make the change. Pretty soon, the door will close on that chance.
>>
>> D 1.0 hasn't arrived yet, and I don't think we'd be able to make a change here once it does arrive.
> 
> With my other hat:
> 
> It is something I like from C++ with all warnings (maximum level) as errors set.  Actually I think that just about all c++ warnings (maximum level) should become errors in D.

If Walter doesn't see these implicit casts as a problem, it's possible that a clever D programmer can create a program to check that the variables aren't being implicitly cast in the ways that the OP was concerned about. It sounds like a very ambitious task to me, but I suppose it's possible.

Another check that could be helpful: ensuring that every swtich has a default case (no one likes pesky runtime errors) BEFORE compilation. If the cases are susposed to be specified, it could be "default: assert(0);". If unspecified cases are permitted, it could be default: break;". Walter seems to be unwavering on this controversial issue, but I think this would be an easier thing to check for.

Just thinking outloud...

-- 
Justin
http://jcc_7.tripod.com/d/