On: 5 Weeks of Go

[taliesinb]

It doesn't seem odd to me. In fact I think it might be a Good Thing.

Having the compiler take care of the safe cases for one makes one less likely to always blindly cast things and leave oneself open to the unsafe cases. For certain values of 'one', of course :)

As for your point about Fahrenheit, the real solution is

  type DegreesF float64;
  type DegreesC float64;

so that the units cannot be accidentally mixed.

Note to self: It might not be a bad idea to have alias-style types deliberately not participate in automatic numeric conversions, although I think it is a mistake they don't currently always auto-convert to their own aliased type.

[ori_b → taliesinb]

Or just write your code so you don't need to convert types. I think that's entirely doable, with the possible exception of API boundaries, and removes the need to have complicated and confusing rules about allowed conversions.

And yes, as far as different unit types, you just pointed out exactly what I was getting at. It's relatively rare that you want implicit type conversions.

[taliesinb → ori_b]

Maybe so, maybe so. I do agree that numeric implicit conversion is not as simple as it first seemed to me, and would have knock-on effects elsewhere.

Edit: For the record, here are the rules we've discovered so far:

1. Numeric casts: A -> B happens automatically if every value of A can be represented exactly in B. Both must be base types.

2. Aliased casts: A -> B happens automatically if A is an alias of B.

3. Automatic casts only happen if a single automatic cast is required, not more. In other words, x + y should not cause x and y to both be cast to a common type.

Is that it? That doesn't seem to bad actually.