Say you need a Vector2D type: struct Vector2D int x int y Except, hold on, I hav...

nadams · on March 7, 2015

Maybe my brain hasn't starting firing on all cylinders yet this morning...but are you saying that:

If I have some function in Go (pseudocode - I don't know Go but it should get my point across)

f(float x) { }

and call

f(vec.x)

Go can't cast it to a float?

I'm not being sarcastic or anything - I'm genuinely curious on Go and your example.

gnuvince · on March 7, 2015

No, what he means is the you would need to write these two functions:

        func DotProductInt(v1, v2 Vector2D) int {
             return v1.x*v2.x + v1.y*v2.y
        }

        func DotProductFloat(v1, v2 Vector2DFloat) float64 {
             return v1.x*v2.x + v1.y*v2.y
        }

If Go allowed for parametric polymorphism, the type of the elements could be abstracted away like this (not real syntax obviously)

        type Vector2D<t> struct {
             x, y t
        }

        func DotProduct(v1, v2 Vector2D<t>) t {
             return v1.x*v2.x + v1.y*v2.y
        }

one-more-minute · on March 7, 2015

To answer your question, no, but it's not really the key issue. The problem is storage; I can't store a value of 1.5 in my original Vector2D, so I had to reimplement it.

If that sounds silly (why not just change the original Vector2D to floats?) imagine you're implementing a game, for example, and you want to store game objects in sets. You can't just write one type-safe Set structure – you have to implement Monster1Set, Monster2Set, PlayerSet, Coin1Set...

Basically, any time you want to go outside of Go's built-in array and dictionary types, you run into problems.