Hello! I'm relatively new to Nim but I didn't find easy answers to these
questions in the docs so I'm looking for some clarification.
As I understand it, the auto type is basically an alias for creating generic
procs, and
proc foo(a:auto,b:auto)
is equivalent to
proc foo(a,b:auto)
(aka every auto parameter gets its own T and there's no way to specify that a
and b are the same T without writing out a generic proc).
Would it be syntactically ambiguous to allow "implicit" autos? E.g.,
proc foo(a,b:)
would be syntactic sugar for
proc foo(a,b:auto)
and
proc foo(a:,b:int)
would be sugar for
proc foo(a:auto,b:int)
(I'd have the same question about return types, in that case.)
It also wasn't clear to me whether generic/auto parameters can reference
properties that aren't present for every T, or whether they could be passed as
parameters to procs expecting a more specific type than T. The docs say that
auto parameters do not yet "infer the parameters' types from the body", so do
all generic/auto parameters need to be handled in a completely generic manner?
Or does the compiler not do any type validation until the generic proc is
called (and thereby instantiated)?
Nim's concept type, as I understand it, is essentially a form of
statically-checked duck-typing (which I've never seen before and am really
impressed with, by the way), which means the compiler is capable of verifying
whether a type meets some arbitrary assertions. So then would it also be
capable of, for lack of a better term, "implicit concept types for generics?"
I.e., if I wrote
proc foo(a:auto) = a.x += 1
would the compiler accept this and essentially treat a as a member of
type T = concept a
a.x + int
? If so we must be very close to achieving syntactic parity with Python in a
statically-typed language and that is very cool.
