undefined | Better HN

0 pointsdnautics4y ago0 comments

It's still bonkers to make you cast an non-duration input to time.Duration. this causes cognitive confusion, because you are effectively labelling the multiplicand as something that it isn't. All pls with types have semantic meaning for the types if nothing else, so if you can't see why this is a real problem, I can only say: Stockholm syndrome.

"numerical operations generally require their operands to be of the same type"

The correct decision would have been to make the * operator be allowed to operate on a time.Duration and an integer, just as you are uncontroversially allowed to operate * on a float and an integer -- to refute your statement and go even stronger I don't know of ANY pls that require * operands be the same type.

However, that is not what go chose. And we are talking about the choices go made. This is very much NOT well thought out and very ill-considered, especially since "the right thing" is so easy.

0 comments

5 comments · 3 top-level

bidirectional4y ago· 1 in thread

> I don't know of ANY pls that require * operands be the same type.

Haskell is an example, where the type of * is:

    (*) :: Num a => a -> a -> a

Which says that the arguments must be numeric, and of the same type. I think this is the sensible choice from a strongly-typed perspective, and some operation which allows one to multiply a time value should be a separate thing.

twic4y ago

But you can define your own * operator, separate to the one from Num, with any types you like, can't you? You might have to hide the one from the prelude to use it.

wwalexander4y ago· 1 in thread

> this causes cognitive confusion, because you are effectively labelling the multiplicand as something that it isn't

You make a fair point, but at that point the debate is about other choices made in the Go language disallowing implicit type conversions.

> The correct decision would have been to make the * operator be allowed to operate on a time.Duration and an integer, just as you are uncontroversially allowed to operate * on a float and an integer

What should the resulting type of the multiplication operator be when applied to a float and an integer? Should the type be different if the operands are swapped? Is it acceptable for the multiplication operator to not be commutative, given that we seem to be demanding a great deal of rigor from our type system? Should we only allow this implicit conversion if type inference is not being used?

> To refute your statement and go even stronger I don't know of ANY pls that require * operands be the same type

Rust, for one, but will test out some more when I’m not on a bus: https://play.rust-lang.org/?version=stable&mode=debug&editio...

> cannot multiply `i32` by `f32`

mcronce4y ago

> Rust, for one, but will test out some more when I’m not on a bus

You can impl Mul for your own types. The operands' types don't need to match.

59nadir4y ago

> to refute your statement and go even stronger I don't know of ANY pls that require * operands be the same type.

This really comes down to a lack of experience on your part. Haskell requires both arguments to be of the same type and only in the case where it can reasonably infer from a literal that it could be coerced will it do so. OCaml, as another example, requires an entirely different multiplication operator for floats.

Requiring the same type for both arguments is not as rare a position as you've made it out to be, and not a showstopper in any case either.

j / k navigate · click thread line to collapse