<div dir="ltr"><div>Just following up on this.  My understanding was that this would be a special type that is limited to builtin Java/Tcl function arguments.  I.e. typing within Swift remains static and you can't instantiate a variable with type any.<br><br></div><div>tl;dr version is: I think it's fine when used sparingly (serialization is a good example).<br></div><div><br></div>My more detailed thoughts were:<br><ul><li>It's straightforward to implement the typechecking in STC so that isn't a concern.<br></li><li>You can already do that with type variables in Swift/T, e.g. the repr() function that returns a string representation has type signature: <span style="font-family:monospace,monospace"><T> (string o) repr(T x)</span>.  We also have repr_array: <span style="font-family:monospace,monospace"><T> (string o[]) repr_array(T A[])</span>.   I'm not sure whether it would be better to stick with this approach in Swift/T (for the purposes of the standard library, there's no functional difference).<br></li><li>It may cause some confusion if programmers see the type and assume they will be able to instantiate  <span style="font-family:monospace,monospace"><b>any x</b></span>; and have a dynamically typed variable.  This may just be a documentation issue.</li><li>We should try to only use it for functions where it can actually accept any type.  <span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif"></font></span>.  E.g. printf() in Swift/T isn't a good candidate, since, say, structs aren't a sensible argument to printf.  I.e. I think it's not ideal if the function implementation is something like: <span style="font-family:monospace,monospace">switch (type) {... default: printf("I don't like this type"); exit(1); }<font face="arial,helvetica,sans-serif">.  </font></span><br><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">Sometimes it's not possible to express something more nuanced in the type system, so it's difficult to always avoid.<br></font></span></li><li>If the function body is just going to be a <span style="font-family:monospace,monospace">switch (type) {...}</span>, maybe it's best to do that in the compiler with overloading.  I think there are some cases where overloading isn't powerful enough: if you're recursively doing something like serialisation on a more complex data structure, or if you have multiple polymorphic arguments, then you can't enumerate all the cases with overloading.<br></li><li>We don't have runtime type information in Swift/T so it's a pain to implement functions that require it (there's a workaround with the compiler emitting type information for the function to parse, but it's ugly).</li></ul><p>- Tim<br></p></div>