spec: definition for iota doesn't make sense for nested ConstDecls

[mdempsky]

This program should print 1, but cmd/compile rejects it with an "undefined: iota" error.

package main

import (
        "fmt"
        "unsafe"
)

const (
        _ = unsafe.Sizeof(func() int {
                const (
                        _ = 1
                        _
                        _
                )
                return 0
        }())

        y = iota
)

func main() {
        fmt.Println(y)
}

[mdempsky]

Two side thoughts:

1. Arguably the Go spec says it should print 3 (not 1, like I say above), because the value of iota is said to reset whenever the const keyword appears in the source, not in the block. I suspect that's just because the Go spec's wording wasn't written with nested const declarations in mind.

2. Should

   const _ = unsafe.Sizeof(func() int {
       var _ int
       return iota
   })
   

   be valid? Arguably iota here is appearing inside a ConstSpec so it should be allowed by the spec, yet cmd/compile, gotype, and gccgo all reject it. (cmd/compile accepts it if you remove the var declaration.)

/cc @griesemer @ianlancetaylor

[griesemer]

Yes, I would agree that there's (among other things) a spec issue here - each scope should have its own iota. I think we can safely make that adjustment in the spec w/o affecting real-life code.

Regarding the comments:

1. Per the strict spec interpretation, it should print 4 rather than 3, no?
2. I think if we fix the spec, the example in 2) should not be permitted.

[mdempsky]

@griesemer Ah, agreed that strict interpretation supports printing 4, not 3. (And so gccgo is actually technically conforming.)

[mdempsky]

Per discussion on #15551, I'm reclassifying this as an issue against the spec. Based on how we resolve this issue, we can then (re)open issues against the compilers / typecheckers to fix their behavior as appropriate.

[gopherbot]

CL https://golang.org/cl/36122 mentions this issue.

[gopherbot]

Change https://golang.org/cl/71750 mentions this issue: spec: clarify that each block has its own version of iota

[mdempsky]

Oops, I just noticed there are still two mentions of iota being "incremented":

(iota is not used but still incremented)

Within an ExpressionList, the value of each iota is the same because it is only incremented after each ConstSpec:

Since we got rid of the definition that iota "increments" after each ConstSpec, should these be reworded too?

I think there's also still the question of whether this is valid:

const _ = unsafe.Sizeof(func() int { return iota })

Currently, I think the spec's wording permits it, but none of the compilers do. I'm leaning towards the compilers are wrong here. Partly because I think disallowing this in the spec is too clumsy, and partly because it seems natural that function literals should be allowed to still access any declared objects in scope just as if they weren't in a function literal.

[griesemer]

@mdempsky All good points. I'm fixing the "increments" parts ( I think we just don't need those comments anymore, including the references to "reset" ). Still thinking about the use of iota inside a function with const decl.

[griesemer]

@mdempsky We should probably allow iotas anywhere in an expression. There's no real harm here, and as you say, it would be pretty awkward to exclude selected special cases. For instance, this actually works:

const n = len([iota]int{})

( https://play.golang.org/p/iEFCsj_L_0 )

[gopherbot]

Change https://golang.org/cl/71912 mentions this issue: spec: remove vestiges referring to iotas being incremented