3 ms·

Interesting. I have always felt the opposite. It's always been stable for me, that's why I rewrote V in V so early. We also have thousands of tests. Do you ha

• kgeist 4y ago
  Right now on the very first issues page 5 issues out of 21 (if we skip feature requests) are about broken codegen (i.e. C errors). I'd expect a stable implementation to have very few codegen problems, not like this; I'd expect something like subtle correctness issues or various bugs in the standard library to be much more common (larger surface area). Another interesting example is this: https://github.com/vlang/v/issues/14804 https://github.com/vlang/v/issues/14804 Passing a variable to a function works, but passing a string literal doesn't. I wonder why stuff like that even happens, it leaves an impression that the compiler has hardcoded special cases internally and breaks on input which wasn't foreseen by the implementation authors. Your solution is to get rid of the method entirely instead of fixing it, which is also somewhat strange to me. Can you explain? >Interesting. I have always felt the opposite. It's always been stable for me It could be that the patterns you use when writing V code are well-tested but when someone strays from the path and does something you wouldn't do when writing V code it easily breaks the compiler.
  • amedvednikov 4y ago
    strconv.v_sprintf is an internal function only used by the compiler in string interpolation. It should simply be made private.