I understand what you are saying now. Based on your last reply, I modified the macro to take a "default initialization expression" parameter: [https://play.nim-lang.org/#ix=23Zl](https://play.nim-lang.org/#ix=23Zl)
The syntax could be made "more beautiful" but I think it closely approximates the feature you are looking for. The other relevant documentation is here: [https://nim-lang.org/docs/manual.html#statements-and-expressions-return-statement](https://nim-lang.org/docs/manual.html#statements-and-expressions-return-statement) Specifically: > The result variable is always the return value of the procedure. It is > automatically declared by the compiler. As all variables, result is > initialized to (binary) zero Nim memsets the memory to binary 0 by default when a variable is initialized (It does not take into account the type at that stage) This is an important thing for memory security etc..., But, as you observe, does not necessarily result in a semantically correct default value for a type. (This is called out in the manual. It's known behavior.) I agree with you that being able to set a semantically correct default value for a type is a useful feature, but consider that it is not fundamental. A related issue has been discussed previously here: [https://github.com/nim-lang/RFCs/issues/126](https://github.com/nim-lang/RFCs/issues/126) and here: [https://github.com/nim-lang/RFCs/issues/48](https://github.com/nim-lang/RFCs/issues/48) Notably, other popular languages such as Go work the exact same way. There is precedent for the current behavior and there are real costs associated with adding this behavior to the language. The thing that I am unsure about is how the current behavior should interact with the "Proveinit" algorithm. Proveinit is counter intuitive but technically correct in this case. It is reminding you that Nim has not set a semantically valid default value and you must do so yourself. > Thanks. It's more a workaround than a satisfaying solution but I'll see if I > can use it in my code. Using the no warning pragma is shorter though ;-) It is a work around, but IMO, it is more correct that setting the "no warning" pragma. That silences the warning, which you explicitly stated that you did not want: > My goal is not to disable that compiler warning with compiler flags or > pragma, but to write the correct code for the nim compiler. Unlike disabling or ignoring the warning, my macro solution produces "correct" code :-P. IMHO, the beauty of Nim is that macros allow you to "fix" small holes in the spec like this in an elegant way. Believe or not, it is actually idiomatic Nim to do something like this. Pick your poison :-P
