3 ms·

I haven't looked into Nim in as much detail as Rust (though I did make some contributions to the compiler/language a number of years ago), but one aspect that h

I haven't looked into Nim in as much detail as Rust (though I did make some contributions to the compiler/language a number of years ago), but one aspect that has always seemed notable to me is that it seems to defer type checking of generic code until it is instantiated (this is what happens in C++), so these functions will all typecheck until you actually try to use them: proc foo[T](): float32 = result = "foo" + 4 proc bar[T](n: T, m: T): T = result = n(m)(n) In Rust, such functions would require some sort of explicit constraints on `T`, so it's more-or-less guaranteed to be instantiable (ignoring the issue of polymorphic recursion) and you don't get some error pointing to code internal to the function when the user applies types that don't work.

Arnavion 7y ago
>it seems to defer type checking of generic code until it is instantiated (this is what happens in C++) ... and you don't get some error pointing to code internal to the function when the user applies types that don't work. Worth noting that C++ is going the opposite way with concepts. The compiler still won't enforce that `template<typename T> void foo(T t) { t++; }` needs a `requires Incrementable T` (like Rust would require with trait bounds). But if `foo` does use the concept `template<Incrementable T>`, then a call like `foo(S{})` will raise an error at the callsite, not at the `t++` line.
- maxdamantus 7y ago
  Interesting. From what I remember of Go's generics proposal, they seemed to be trying to do something similar, which seemed a bit hacky to me (as you say, it addresses the error reporting issue but it's difficult to see how the constraints would be used to actually check the generic code, so functions can presumably still lie about being "for all types"). EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them. Looking into it now, Nim apparently has experimental support for the same feature: https://nim-lang.org/docs/manual_experimental.html#concepts https://nim-lang.org/docs/manual_experimental.html#concepts
  - maxdamantus 7y ago
    > EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them. Just wanted to add that my initial memory was apparently of the earlier proposal for generics in Go, as reflected here: https://dev.to/deanveloper/go-2-draft-generics-3333 https://dev.to/deanveloper/go-2-draft-generics-3333 (in this earlier proposal, contracts simply specify code that is expected to compile, in such a way that it would be difficult/impossible to derive types for symbols introduced by the contract). I guess the golang people figured out why that was not an optimal system and changed it ... wonder if the same will be true of Nim.

Arnavion 7y ago

>it seems to defer type checking of generic code until it is instantiated (this is what happens in C++) ... and you don't get some error pointing to code internal to the function when the user applies types that don't work. Worth noting that C++ is going the opposite way with concepts. The compiler still won't enforce that `template<typename T> void foo(T t) { t++; }` needs a `requires Incrementable T` (like Rust would require with trait bounds). But if `foo` does use the concept `template<Incrementable T>`, then a call like `foo(S{})` will raise an error at the callsite, not at the `t++` line.

maxdamantus 7y ago
Interesting. From what I remember of Go's generics proposal, they seemed to be trying to do something similar, which seemed a bit hacky to me (as you say, it addresses the error reporting issue but it's difficult to see how the constraints would be used to actually check the generic code, so functions can presumably still lie about being "for all types"). EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them. Looking into it now, Nim apparently has experimental support for the same feature: https://nim-lang.org/docs/manual_experimental.html#concepts https://nim-lang.org/docs/manual_experimental.html#concepts
- maxdamantus 7y ago
  > EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them. Just wanted to add that my initial memory was apparently of the earlier proposal for generics in Go, as reflected here: https://dev.to/deanveloper/go-2-draft-generics-3333 https://dev.to/deanveloper/go-2-draft-generics-3333 (in this earlier proposal, contracts simply specify code that is expected to compile, in such a way that it would be difficult/impossible to derive types for symbols introduced by the contract). I guess the golang people figured out why that was not an optimal system and changed it ... wonder if the same will be true of Nim.