Is opCast need, we have to!

[Jesse Phillips]

foobar Wrote:

> Jesse Phillips Wrote:
> 
> > to!(int)(base!(2)("1010101"));
> 
> semantically this is what i wanted but i still feel that a plain function would be easier on the eyes. 
> for instance: 
> int r = parseInt("101010", 2); 
> // second parameter is optional and defaults to decimal base

But then the logic for base conversion is spread out in:

parseInt, parseDouble, toString, and what ever else a base conversion might be converted to/from. Though a helper function would be used by all.

And how do you handle generic code?

static if(is(T == int) parseInt...
else static if(is(T == double)) parseDouble...

> you're right, point taken. to fix my previous example:
> int a = integer(floor(3.14)); // still simpler than the unified template syntax
> 
> > 
> > Do you really want that?

Yes, yes you do. Well you are in luck:

int a = floor(3.14); // does not compile in D

I think returning integer would be correct, but doesn't bother me to much? (Anyone else reading with an opinion?... numeric coders?)

> IMO, there is a need to distinguish the two because I may want to provide a conversion of my class type to a different class.
> contrived example:
> class Person {};
> class Kid : Person {};
> class Adult : Person {}; 
> I want to be able to convert a Kid instance into an Adult instance when said kid turns 18. 

Currently you can provide the conversion in the manner you desire

Adult grownup = kid.canSmokeNow();

And by _not_ providing an opCast function, casting from Kid to adult will fail! to compile. Now of the cast types I do not know where this one falls, but dynamic cast is not it (I would think static cast).

> > The type you are assigning too might be an issue, but this not a bug introduced by the conversion. For example you can assign a real to a float implicitly. This could result in a loss of precision. The bug did not come from an implicit conversion to float, it came because the precision of real was needed but float was used.
> > 
> > My initial thought was it was a bad idea, but I came up with that reasoning to make myself feel good about D :D
> > 
> 
> My opinion -  this is a misfeature inherited from C. Assignment of incorrect type (e.g. a double value to an int) should be a compile-time error.

Could we please get one thing straight, D does not implicitly convert double/float/real to int. Or int to byte. You can select from these examples:

int -> uint
real -> double -> float
int -> double...
byte -> int
and other similar combinations

But stop using a completely invalid conversion example.

> > The compiler _is_ checking the code. There is nothing inherently wrong with converting an int to a double, except larger numbers can be held in an int (but making the conversion explicit will not resolve this, and won't result in people considering it). The example of:
> 
> because of differences in representation this is also unsafe. Not all integral values can be represented accurately in a floating point type and this has nothing to do with size of int. I myself had such a bug where I expected a value of 2.0 as a result of some calculation but got 1.99998.. instead.

I have never heard this. Not all values are representable in floating point, but I do not know of any issue representing integers.

http://ideone.com/e8x5L

If you received a value of 1.99998 from a calculation, it is an inherit issue with using double and not a conversion error from converting an int to a double.

> > double d = 5 / 2;
> > 
> > Is one place I agree could use an explicit conversion to double. I think this is the only major logic bug solved by forcing type conversions. But I also believe when the compiler complains the solution to fix it will be:
> > 
> > double d = cast(double) 5 / 2;
> > 
> > Even though it needs to wrap the five/two. That is because a complaining compiler does not make a thinking programmer, and the more it complains the less thinking. If you want say that the programmer sucks if they don't think about the changes they are making then, they also suck when they don't think 5 / 2 returns an int.
> 
> i disagree with this logic. Take a look at ML family of languages to see that more checks do not make worse programmers.

I said nothing about making the programmer worse due to checks, but do to excessive complaining. I do not think a programmer sucks for either mistake; I do think both are very easy mistakes to make. As Don pointed out there is a plan to fix this issue (not sure if it applies to when variables are used too).

[OT] Why nagging people makes them numb.

I believe you understand the premise of this. If something continually asks or tells you to do something, the answer becomes involuntary. Like dialogs that say do you wish to continue? Well I might not, but by the time I realize that I've already clicked yes (actually I might realize it 5 mins later and has nothing to do with being asked the question).

But what I think you want is for the required action to be a safer action. For example, write now the solution is to insert a cast() which handles many different things and could perform one you weren't expecting. With many cast/conversion methods then you insert the appropriate method and it will complain that it can't do that.

And now that I am seeing your view a little better I don't see this at play because:

double d = double(5/2);

would induce thinking, but so would:

double d = cast(double)(5/2);

(want an ! in there :P)

I do not wish to argue against making things explicit, but I do want to figure out if there really is an issue in the way D does implicit conversions. So far I am seeing an opinion based on experience with C, but not D and an unwillingness to see that implicit conversion isn't harmful when done right.