Blog post about strict funcs

> If I'd want to modify the object I then could just use var That's really not a good solution. Over-specifying the mutability via `var ref T` is much more problematic than it looks as there is no subtype relation between `var ref T` and `var ref S` even if `S <: T`.

Blog post about strict funcs

Hi, I was wondering whether there is a reason why this strict mode only applies to `func` and not to `proc`. For example, here it could be useful to also have this strict mode apply to `proc`: type SomeObject = ref object someFlag: bool var globalFlagStatus = true

Blog post about strict funcs

> Any links ? It was in a pull request of mine that never got merged, see

Blog post about strict funcs

I made a library based on Clojures vectors a while back, and I was planning on implementing the same thing for hash tables but never got around to it.

Blog post about strict funcs

> We had such a tool but it didn't make it in any release. But yeah, more > explicit annotations make sense for the stdlib. Any links ?

Blog post about strict funcs

I was thinking the same thing. In the style guide you have "Constants do no harm, variables do!" Along the same line of reasoning, making everything a `func` with exceptions for `proc`s seems like a better design choice. Same with `let`. Maybe even a compiler warning when `var` or `procs` don't

Blog post about strict funcs

> (though i wonder if the compiler can be ran with some options to analyse all > procs and find all that can be made funcs) ? We had such a tool but it didn't make it in any release. But yeah, more explicit annotations make sense for the stdlib. Beware of application level code though, ripple e

Blog post about strict funcs

> This can be important for evolving code bases so that you don't > accidentically break the func-ness guarantees. So shouldn't the usage of func be encouraged over proc (use func by default and only if you need a proc use it), like in code snippets in the docs and the manual and gradually repl

Blog post about strict funcs

> does it help the compiler to make optimizations in a way it can't without > `{.noSideEffects.}` ?

Blog post about strict funcs

It is inferred yes, but `func` (or an explicit `.noSideEffect`) guarantees it. This can be important for evolving code bases so that you don't accidentically break the func-ness guarantees.

Blog post about strict funcs

I apologize for my "noobiness" and for bumping this thread, why does one need to explicitly declare a routine with `func`, doesn't the compiler perform side effects analysis regardless ? does it help the compiler to make optimizations in a way it can't without `{.noSideEffects.}` ?

Blog post about strict funcs

Thanks. That makes sense.

Blog post about strict funcs

> I just want to understand the behavior. Well `add(s: var seq[T]; x: T)` is builtin and so its body isn't checked. `add(s: var seq[T]; x: openArray[T])` is not builtin and its body is checked. That explains the difference that you have seen.

Blog post about strict funcs

> Btw you can override the compiler's thinking with a {.noSideEffect.}: ... > block. I think that pragmas with opposite meanings depending on where they appear is confusing. I think something like {.ignoreSideEffects.} would be better.

Blog post about strict funcs

This is the pragma {.noSideEffect.} for `add` which causes the error. Adding a block {.noSideEffect.} in `p` doesn’t change anything. But in fact, for now, I don’t want to make the program compile. I just want to understand the behavior. I simplified again my examples (no need for an object) an

Blog post about strict funcs

Btw you can override the compiler's thinking with a `{.noSideEffect.}: ...` block.

Blog post about strict funcs

As I wrote, `add` for seq must be `.noSideEffect` no matter the `T`. The analysis might be "sound" as it it is, but it's too conservative. :-)

Blog post about strict funcs

OK, but that doesn’t explain why my second examples compiles. We are in the same situation where an alias is created when copying a reference.

Blog post about strict funcs

> The compiler analysis is sound, add() is copying choices, which contains > references reachable from choices into an another storage location where they > can be mutated. But Araq just said that "Mutability via var parameter has higher priority than immutability of other parameters", and resu

Blog post about strict funcs

> According to the type of T a proc may be side-effect free or not. How could that not be true? Different code will be executed depending on the type. I don't think {.noSideEffect.} is checkable at the definition point by either humans or the compiler; it can only be checked at the invocation.

Blog post about strict funcs

This is a rather subtile explanation. I will have to read Araq’s paper again to see where is described this behavior. But, then, there is a problem as the following program compiles without error: type Item = ref object choices: seq[Item] proc p(it

Blog post about strict funcs

The compiler analysis is sound, `add()` is copying `choices`, which contains references reachable from `seq[Item]` into an another storage location where they can be mutated. I guess what this meant is that `add()` is not truly `{.noSideEffects.}` :P

Blog post about strict funcs

I have been able to reproduce the error in a very simple example: type Item = ref object choices: seq[Item] proc p(item: Item): seq[Item] = result.add(item.choices) Run

Blog post about strict funcs

Thank you for great new feature and nice blog post! `n` parameter in `test` func in following code can be mutated via var parameter `x`. Mutability via var parameter has higher priority than immutability of other parameters? {.experimental: "strictFuncs".} type Node

Blog post about strict funcs

> Mutability via var parameter has higher priority than immutability of other > parameters? Correct.

Blog post about strict funcs

OK, thanks. I will try to reproduce the problem in a simple example.

Blog post about strict funcs

> Before investigating further, I would like to know if I missed something. You didn't, this code must compile.

Blog post about strict funcs

I installed last development version and did some tests. This is quite impressive! But I encountered a strange error in one case. It occurred in system.add with the message: /home/xxx/.choosenim/toolchains/nim-#devel/lib/system.nim(1216, 6) Error: 'add' can have side effects an

Blog post about strict funcs

Currently strictFuncs does the first - it changes the meaning of noSideEffect

Blog post about strict funcs

So I'm not completely sure what `{.experimental: "strictFuncs".}` does, it could do one of 2 things Changes the `noSideEffects` tag so that prevents mutating via references. Or, Adds a new tag to funcs that prevent mutating via references maybe call it `immutableRefs` and strictFuncs makes func

Blog post about strict funcs

+1 For gently promoting immutability by default with args and let. And for this change allowing better immutability guarantees.

Blog post about strict funcs

TIL there is a `nim fusion`. Seems like a good idea. Is the eventual plan to migrate functionality to it from the standard library?

Blog post about strict funcs

> Can the error message be expanded to show you the alias chain that lead to > the mutation? Currently it does show a single step of the alias chain. You're probably right and it should show all steps. It's not as easy though as the algorithm doesn't even track this (it's called "path compressi

Blog post about strict funcs

This is brilliant! excellent work @Araq and @Clyyber! I have a question about the error message. Does it currently just look like the below sample? Error: 'p' can have side effects an object reachable from 'n' is potentially mutated Run Can the error message be e

Blog post about strict funcs

Ok, but if we want to link previously compiled (with old behavior) library - will be an exception thrown or not?

Blog post about strict funcs

These should be provided as external libraries (and iirc we have some Nimble packages offering these) or added to "nim fusion". Our focus is on language development, not on libraries.

Blog post about strict funcs

This is great! Now that mutation is being enforced more strictly will there be immutable versions of data structures with node sharing and purely functional updates?

Blog post about strict funcs

Finally func is going to be doing what I though it should be doing!

Blog post about strict funcs

I wrote a new blog post: Please enjoy and feel free to ask questions here.