From 815c7c12e73748a2c00c72b64cbe166ddd057258 Mon Sep 17 00:00:00 2001 From: flaviut Date: Sun, 26 Oct 2014 05:32:37 -0700 Subject: [PATCH] Updated Common Criticisms (markdown) --- Common-Criticisms.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/Common-Criticisms.md b/Common-Criticisms.md index 5cc7afa..8efa755 100644 --- a/Common-Criticisms.md +++ b/Common-Criticisms.md @@ -1,16 +1,15 @@ ## Nim doesn't require call-site annotation for `var` parameters This is referring to systems like C#'s: `void foo(ref int myInput){...}; foo(ref a);`. Note the ref on the `foo` call. If this was Nim, it'd be impossible to tell from the call-site that `foo` has the potential to modify `a`. -***NOTE*** : The following is wrong, I'll fix it soon - -Possibly. The problem here is that of perception. In many languages, heap allocation through pointers is the only method of having objects, and passing them to a function gives the freedom to modify them. In Nim, things can be allocated on the stack, and those things need to be treated in the same way as things on the heap. +Possibly. The problem here is that of what mental metaphor is being used. In many languages, heap allocation through pointers is the only method of having objects, and passing them to a function gives the freedom to modify them without any callsite annotations. In Nim, things can be allocated on the stack, and those things need to be treated in the same way as things on the heap. ``` nimrod proc foo(input: var T) = ... +proc foo(input: ref T) = ... let a: ref T = ... foo(a) # valid, this is Java-style var b: T = ... -foo(b) # also valid and equivalent +foo(b) # also valid ``` Note that the difference between what happens in Java and what Nim does is simply a matter of efficiency: Nim does not require our `T` to be allocated on the heap, and it certainly allows `b` to be declared with `let`, which will force an compile-time error to be thrown. \ No newline at end of file