fix #16736 assign closure proc to const should be CT error

[bung87]

fix #16736
fix #16737

[bung87]

CI fails cause by #14340 related test case , if this PR accepted , should remove that test case.

proc opl3EnvelopeCalcSin0() = discard
type EnvelopeSinfunc = proc()
# const EnvelopeCalcSin0 = opl3EnvelopeCalcSin0 # ok
const EnvelopeCalcSin0: EnvelopeSinfunc = opl3EnvelopeCalcSin0 # was bug
const envelopeSin = [EnvelopeCalcSin0]
var a = 0
envelopeSin[a]()

[top-master]

@bung87 You basically cause the error:

tvmmisc.nim(358, 11) Error: const 'EnvelopeCalcSin0' cannot be assigned to proc of calling convention 'closure'

And why do you think setting to a const should be forbidden?

Like:

• const just means that the internal state is not modifiable by outsiders,
• and that such attempts should cause compile-error,
• but as it is a closure, I doubt anything "outside" has even access, hence closure is truly const even without const-keyword use.

Update; Above I am confusing const with let (to be expected, for someone with C/C++ experience).

The only difference with let is that, Nim's const expressions are evaluated at compile-time, just like constexpr in C++.

Nim-lang Example:

var x = 123
let y = x+4 # Works.
const z = x+4 # Throws error.

[beef331]

Bung pinged me in realtime chat I assume to respond

const is not a let as such it has different semantics. The way I see it is a const closure does not make much sense as refs are presently not capable of being used for const, This is a problem for a closure as it has a heap allocated environment.

Not only that but presently the following errors:

const a = proc() {.closure.} = echo "Hello"
a()

Error: VM problem: dest register is not set

Since it's attempting to evaluate a at CT and not runtime.

but as it is a closure, I doubt anything "outside" has even access, hence closrure is truly const even without const-keyword use.

This Exists.

Another example to explain how odd it is of a concept to me:

proc makeMyClosure(r: ref int): proc() =
    result = proc() =
      inc r[]
      echo r[]

var myRef {.compileTime.} = new int # This makes a reference in VM since it needs to be accessible at CT, but we can make a closure to capture it.

const a = makeMyClosure(myRef)
let b = a

b()

[bung87]

Thanks beef's response, am not a native english speaker and not capble to explain this, so I pinged beef, as we discussed yesterday about this. now am pretty sure this should be CT error.

[Araq]

Patch the existing typeAllowed code for this.

[arnetheduck]

Why shouldn't const be allowed to be a proc? It makes proc's less of first-class citizens in the language, which prevents some code and generic constructs, as well as renamed function pointers and other use cases

[bung87]

Why shouldn't const be allowed to be a proc? It makes proc's less of first-class citizens in the language, which prevents some code and generic constructs, as well as renamed function pointers and other use cases

today's news is it is planed to support, but for now it may causes users mis-use, which we dont like to see.

[arnetheduck]

Example use case: status-im/nim-chronos#319

[bung87]

since chronos used as a real use case, that can't be patched in a easy way, I decide partially support it or wait real const closure implementation.

[metagn]

Since it's attempting to evaluate a at CT and not runtime.

Can't we find a way to only allow calling non-closures converted to a closure type at runtime? i.e. if the closure environment is nil, or whatever that would correspond to for the compile time VM (I'm guessing all procvars at compile time are stored as symbols, so we would check if the symbol type is a closure).