Update on strict funcs

So effectively this change will cause the following changes to the experimental strict funcs: func a(x: var int) = discard func b() = var x = 1 var p = addr x a(x) # OK a(p[]) # FAIL, was OK before Run

Update on strict funcs

Only admins can remove posts. ;-)

Update on strict funcs

The perfect forum which isn't missing any important features strikes again.

Update on strict funcs

You can think of func f(x: var X): Y var x: X let y = f(x) Run as sugar for func f(x: X): tuple[X, Y] var x: X let (newx, y) = f(x) x = newx Run

Update on strict funcs

Please ignore. The forum won't let me delete my post.

Update on strict funcs

Another example, I can just move heap allocation to a template and it seems to bypass any checks: {.experimental: "strictFuncs".} template t() = result = newSeq[int](10) func f():seq[int] = t() for i in 0..9: result[i] = i echo f()

Update on strict funcs

> If so that’s a bit unintuitive to me since it allows side effects, and the > hallmark of a “pure” function in the math/FP sense is that it has no side > effects, which makes its behavior a lot easier to reason about. Efficiency in FP languages is not that easy to reason about. Nor is emulating

Update on strict funcs

> Should this be considered a bug? No. An allocation is not an effect. Never has been, never will be.

Update on strict funcs

Should this be considered a bug? {.experimental: "strictFuncs".} func f(p:proc() {.noSideEffect.}) = p() f(proc() {.noSideEffect.} = discard newSeq[int](10)) Run

Update on strict funcs

> stores to locations that involve a ptr/ref indirection are forbidden Does this mean that stores through a `var` parameter _are_ allowed? If so that’s a bit unintuitive to me since it allows side effects, and the hallmark of a “pure” function in the math/FP sense is that it has no side effects,

Update on strict funcs

Also, a variation of this rule allows the compiler to prevent the creating of cycles at compile-time. I think. :-)

Update on strict funcs

> Does that mean, you no longer have to make ref parameters var for funcs to > compile? That was never the goal of strict functions so I'm not sure what to say. > But it's about every ref/ptr location now, including locals? Yeah, but it doesn't matter much because you can adapt the coding style

Update on strict funcs

Does that mean, you no longer have to make ref parameters var for funcs to compile? I consider that a good thing, since a lot of code would need to be changed, and a sub-dialect was created. But it's about every ref/ptr location now, including locals?

Update on strict funcs

changed the definition (and implementation) of what a "strict function" is once again. The definition was changed to "stores to locations that involve a ptr/ref indirection are forbidden". As you can see in this pull request this makes the language le