I wrote a new blog post:
https://nim-lang.org/araq/writetracking_2.html
Please enjoy and feel free to ask questions here.
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
Can the error message be expanded to show you the alias chain that lead to the mutation? The thing about aliases in particular is that even if the compiler finds the bug through the graph analysis, the programmer is not always so smart. It may not be obvious to my silly monkey brain when just looking at the line that triggered the error :-P
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 compression").
+1 For gently promoting immutability by default with args and let.
And for this change allowing better immutability guarantees.
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 funcs equivalent to proc ... {.noSideEffects, immutableRefs.}
Personally I'm a fan of the more fine grained control of the second option, and it allows us to pass a ref to a side effect proc while assuring that it doesn't modify the ref. It also allows anything that uses noSideEffects but does mutate refs to coexist with the new funcs for when this becomes default behavior.
Ultimately I'm not a fan of changing existing features when exactly the same can be achieved by adding new features.
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 replacing procs by funcs in the Nim repo (though i wonder if the compiler can be ran with some options to analyse all procs and find all that can be made 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 effects like "now you have to change all 'funcs' to 'procs'" typically cost real time and effort and tend to not reveal any real bugs.
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 ?
Any links ?
It was in a pull request of mine that never got merged, see https://github.com/nim-lang/Nim/pull/14728/files
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
proc updateFlagStatus(someObject: SomeObject) =
someObject.someFlag = false # I want this to be a compiler error
globalFlagStatus = globalFlagStatus xor someObject.someFlag
If I'd want to modify the object I then could just use var
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.