3 ms·

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 ad

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.