proc doSomething(msg="", opt=-1)

Or just work around the ambiguity: proc doSomething(msg="", opt=(-1)) = echo msg, opt doSomething() Run

proc doSomething(msg="", opt=-1)

Not in this case, no, as the syntax is `param [: typ] = value` and not `param [: typ] `.

proc doSomething(msg="", opt=-1)

Is it possible to write a macro operator that would automatically substitute `=-` with `= -` at the AST level? That would fix it for me at least.

proc doSomething(msg="", opt=-1)

> For example, disallowing (unquoted) binary operators ending with a “-“ and > maybe a “.” might work in most cases and still would be pretty simple to > understand. Yeah, until somebody introduces a unary `~` operator and then `=~` doesn't work but `=-` does and the usual "inconsistent!" compl

proc doSomething(msg="", opt=-1)

If you always took the shortest operator, then operators with more than one character couldn't exist. That just doesn't make sense.

proc doSomething(msg="", opt=-1)

You made I good point. It’s clear that the extreme “take the shortest” rule is worse than the current “take the longest” rule. However that does not mean that there aren’t any rules that are still simple yet solve this problem (or make it much more unlikely). For example, disallowing (unquoted)

proc doSomething(msg="", opt=-1)

Well [maximal munch](https://en.wikipedia.org/wiki/Maximal_munch) is so common that it got a special name and the problems it causes are wide spread, in C you cannot write `a/*b` (a divided by pointer deref of b) as the `/*` already starts a comment. Almost nobody complains...

proc doSomething(msg="", opt=-1)

I get and agree with the idea of reasoning from first principles, but the consequences of this particular rule are very unfortunate and affect even simpler expressions such as '2*-1' which _[must](https://forum.nim-lang.org/postActivity.xml#must) be written as '2 * -1'. This makes nim a little

proc doSomething(msg="", opt=-1)

To make it clear, I'm in favor of improving the error message.

proc doSomething(msg="", opt=-1)

That would add unnecessary complexity to the spec.

proc doSomething(msg="", opt=-1)

Well, I see your point in not making exceptions for the generic rules that govern the language. Perhaps a re-parse rule to chop the operator symbol sequence starting from the back, if the initial lookup fails?

proc doSomething(msg="", opt=-1)

The error messages that are the worst (and the hardest to improve, given the paucity of information at that stage) are, like this one, in the parser/lexer. If `x=-1` is outside of a formalParams, as in `var x:int; x=-1` you get the clear, if frustrating: Error: undeclared identifi

proc doSomething(msg="", opt=-1)

Well you still do reasoning by analogy and Nim often does reasoning from first principles, an operator is a non-empty sequence of the set of symbols `{'=', '+', '-', ...}` thus `=-` is an operator like `++?` would be. There is no special casing for `=-`, there is no idea of allowing a 3rd party

proc doSomething(msg="", opt=-1)

Regarding the 'not recommended style', I understand the argument. It does shift the reasonable expectation hierarchy though by making an incredibly rare feature interfere with something I'd imagine many people would stumble into, especially those coming from Python. In Python it's the default st

proc doSomething(msg="", opt=-1)

Well, it's not valid syntax, as this post demonstrates. But Nim's error messages need improvement in general.

Fix for Warning: implicit conversion to 'cstring' from a non-const location

Thank you, glad I asked, and that's even easier to type in!

proc doSomething(msg="", opt=-1)

I think it is very confusing that =- fails to compile. I don't find the fact that it is not the recommended style a very convincing argument because it is still an allowed syntax). Is there a compelling use case for supporting '=-' as an operator (as opposed to the usual '-=' ?) That being sai

proc doSomething(msg="", opt=-1)

The comparison with C++ makes some sense but we encourage you to use spaces around `=` regardless so "patching" it would only allow for a style that we don't recommend. And worse, more special rules make Nim harder to understand once you understand it completely and you use your understanding in

proc doSomething(msg="", opt=-1)

It won't break the existing code when the operator is actually defined. I don't know about other people's sensibilities about it though, but I wouldn't override `=-` for anything that accepts an integer after it, as it would be a sure way to shoot yourself in the foot. As for fixing, I guess, i

proc doSomething(msg="", opt=-1)

No, because that would require the lexer to know beforehand about procedures and other context. Also no because that would break older code that might have depended on this, and no, scanning public repositories for use of such does not act as proof, nor does “it makes no sense”

proc doSomething(msg="", opt=-1)

Hello, I'm pretty sure this one popped up already before: Nim recognises `=-` as an operator and thus fails to compile default parameters that are assigned to negative numbers, unless a space is added after the `=`. proc doSomething(msg="", opt=-1) = echo msg, opt

MNIST perceptron

from guarana import pills

Iterating over anonymous enums?

Ironically, playground is 502, so here's RainbowAsteroids' paste directly from [ix.io](http://ix.io/3ExT): import std/enumutils # std/enumutils implements the items iterator for holey enums. # I believe system defines items for ordinal types, which includes sinner enums