Timothee Cour

@mratsim > proc zeros[T: SomeReal](n: int, _: typedesc[T]): Vector[T] = ... why not simply `proc zeros[T: SomeReal](n: int): Vector[T] = ...` ?

@andreaferretti everything you mentioned in https://github.com/nim-lang/Nim/issues/7517#issuecomment-379183154 can be done with generics just as well (with simpler declarations even) ```nim proc zero[T: int]() = 0 proc zero[T: float]() = 0.0 proc...

@siliconvoodoo > TLDR but I searched the word "deduced" and it doesn't appear in this thread. The biggest importance of generics is that they are automatically deduced at the call...

@zah > If we want to have consistent libraries, we must deprecate one of the mechanisms. Otherwise, people will always choose the mechanism they like more and this thread have...

side question: just filed https://github.com/nim-lang/Nim/issues/7596 ; is that a bug that can be easily fixed? if not, that makes generics more useful in that regard

how is that a 1-char saver? ```nim if not condition: raise newException(msg, SomeException) vs # in simplest form: still produces informative msg: `(pathto/file(2,3): "a == 1" failed [CatchableError]` enforce a...

> I like it except for the idea that the error message is produced automatically from the source code it's no different from `doAssert`, `assert`, or `unittest.check`, `unittest.require` etc: you'll...

> These are all not supposed to be error messages for end-users! you could argue uncaught exceptions also shouldn't reach end-users. The reality is that we routinely have to read...

* `assert/doAssert` is for validating internal logic and is not supposed to be recoverable in normal circumstances. * `enforce` is for validating external input and is supposed to be recoverable;...

we should have a `std/cmath.nim` that is a pure low-level wrapper around importc procs. Then std/math can import it but also work cross-backend with high-level portable wrappers that work in...