ply icon indicating copy to clipboard operation
ply copied to clipboard

Local types

Open lukechampine opened this issue 8 years ago • 1 comments

2ac2a8daee999a5d12def5e66918fd60f668ea5b was a step in the right direction wrt named types, but it introduced a new problem. Consider the following code:

func main() {
    type ints []int
    xs := ints{1, 2, 3}.reverse()
}

We would expect xs to have type ints, and indeed the aforementioned commit will generate code to do that. The problem is that the generated method lives at the top level, but returns a locally-defined type, causing compilation to fail (because a top-level function can't see ints).

So what's the correct behavior here? I see basically two options: either cast the return value at the call site, or ban methods on local types. The latter approach feels rather harsh, especially considering that it's unnecessary for methods like fold that aren't affected by named types. But the former looks like it may be difficult to implement. I started writing out why, but then I had an idea for how to do it, so maybe it's not as bad as I fear.

lukechampine avatar Jan 29 '17 06:01 lukechampine

This bug has reared its head again:

func main() {
    type myint int
    xs := []myint{1, 2, 3}.reverse()
}

Or worse:

func main() {
    type foo int
    type bar struct { f foo }
    xs := []bar{{f: 1}, {f: 2}, {f: 3}}.reverse()
}

This seems like a much tougher nut to crack. For now I think local types will just have to be banned.

lukechampine avatar May 04 '17 21:05 lukechampine