Automatic type casting

[ghost]

It seems Adept doesn't do automatic type casting. For example, both a and b are ulong. I want to print the result of a/b as floating point number so I used:

printf('%.20f\n', (a as double)/b))

Doesn't work. It will error with:

error: Incompatible types 'double' and 'ulong'

I have to cast b to double, too:

printf('%.20f\n', (a as double)/(b as double))

Btw, this will work fine in C: printf('%.20f\n',(double)a/b))

[IsaacShelton]

Yes, in Adept ulongs are not automatically converted into doubles (the conversion is explicit because it loses precision).

This also avoid the ambiguity between

printf('%.20f\n', a as double / b as double)

and

printf('%.20f\n', (a / b) as double)

[ghost]

I don't think so. If I have already casted a to double then b should be automatically casted to double too. Btw, there is no ambiguity in the examples you provided. Every programmer, or at least anyone who studied math in high school, should know that anything in the brackets has a higher priority than the rest. a is ulong and b is ulong then a/b will also be ulong.

[ghost]

This is an example of over-engineering.

[IsaacShelton]

The difference is that the top one performs DOUBLE division, but the bottom one performs ULONG division. They will usually result in different answers.

I disagree, which is why

a, b ulong
printf('%.20f\n', a / b as double)

is not legal. You are forced to state which one you mean.

See this code which demonstrates the difference:

import basics

func main {
    a ulong = 25
    b ulong = 10

    printf('%3.1f\n', (a / b) as double)
    printf('%3.1f\n', a as double / b as double)
}

produces:

2.0
2.5

---

In the provided example, it's not too difficult to guess that you mean double division, but once you start having function calls, struct field accesses, and global variables in there it becomes less obvious and an easy source for bugs even when you're being careful. Having automatic conversion between ulongs and doubles like this would mean that you could change a return type somewhere in your program and now your equation produces a different result!

Which is why this isn't allowed.

[ghost]

You are over-thinking. And you are pretty much repeat what I have said. Everyone knows that the result of a/b is ulong. So (a/b) as double is pointless.

[IsaacShelton]

(a / b) as double is not pointless. In video games for example, there are many times where you specifically want to do ulong division but have a double result.

In your simplistic example, it's understandable. But I don't think you completely realize the implications of what you're suggesting.

Take for example this code:

value1.adept

func getValue1() double {
    return 13.0
}

value2.adept

func getValue2() int {
    return 10
}

main.adept

import basics
import "value1.adept"
import "value2.adept"

func main {
    print(getValue1() / getValue2())
}

Following your suggestion would mean that changing the return type of getValue1 changes the result of the computation! It's impossible to know what will actually happen without knowing the return types, which in any non-trivial program, can be easy to change to introduce a bug in some completely unrelated code!

I'm not sure if you're understanding the bigger picture.

It might seem like a good idea at face value, but once you understand its implications you realize all of the problems that come with it.