deprecate `any` (redundant with `auto`)

[timotheecour]

https://nim-lang.github.io/Nim/manual.html claims:

any | distinct auto (see below)

but then doesn't show examples with any.
And in fact this seems incorrect:

when true:
  proc main1(a, b: any)=discard
  proc main2(a, b: auto)=discard
  main1(1,"x") # works
  main2(1,"x") # works

so any seems redundant with auto, unless I'm missing something.
(docs also mention this: https://nim-lang.github.io/Nim/manual.html#templates-symbol-binding-in-templates

For parameters it currently creates implicitly generic routines:
proc foo(a, b: auto) = discard
Is the same as:
proc foo[T1, T2](a: T1, b: T2) = discard

it's also not used (much/at all) IIRC and is underdocumented.

note

docs also says:

However, later versions of the language might change this to mean "infer the parameters' types from the body". Then the above foo would be rejected as the parameters' types can not be inferred from an empty discard statement.

but IMO a pragma should be used for that instead of changing meaning of auto

note 2

docs should add right here:
typedesc is a "bind many" type class:

that auto is also "bind many"

[cooldome]

any is shorter and more accurate name for a type, should we decom auto instead

[Vindaar]

To me any is a pretty scary thing. I wasn't even aware of its existence (talk about under documented) until a master's student of mine started using it in her code.
To me it's too close to making it seem like Nim is a dynamic language, i.e. people using it not realizing that it's "just" an implicit generic and then getting confused about resulting errors etc.

It's kinda neat that Nim allows to write code that looks so little like typed code, but... Who would honestly use any instead of a completely unrestricted generic?

[timotheecour]

any is shorter and more accurate name for a type, should we decom auto instead

auto is widespread, and common in other languages; it's here to stay.

...talk about under documented...

yes

Who would honestly use any instead of a completely unrestricted generic?

same holds for auto though. But it's useful, you just need to read the docs about what auto means as a param. That can be made easy if theindex.html starts indexing keywords like auto.

proc fn[T1,T2](a1: T1, a2: T2) = discard
proc fn(a1, a2: auto) = discard # shorter, and makes sense if you're not using T1, T2

[treeform]

I support removal of any in favor of just having auto.

Also any type conflicts with function std lib any ( https://nim-lang.org/docs/sequtils.html#any%2CopenArray%5BT%5D%2Cproc%28T%29 ).

Which leads to some strange errors and crashes: nim-lang/Nim#14255

[juancarlospaco]

Deprecation of any should start ASAP then.

[timotheecour]

@juancarlospaco can you please make a PR?

[juancarlospaco]

nim-lang/Nim#16920

[ringabout]

Which leads to some strange errors and crashes: nim-lang/Nim#14255

auto causes the same issues too

block:
  var a = newSeq[bool](1000)
  if false:
    echo "ok?"
  elif auto(a):
    echo "false"

Error: internal error: getTypeDescAux(tyFromExpr)
No stack traceback available

[timotheecour]

any was also confusing (in the human sense, not compiler sense) with typeinfo.Any refs https://nim-lang.github.io/Nim/typeinfo.html#Any