[Swift-devel] Any type

Tim Armstrong tim.g.armstrong at gmail.com
Fri Feb 13 15:42:15 CST 2015


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.

tl;dr version is: I think it's fine when used sparingly (serialization is a
good example).

My more detailed thoughts were:

   - It's straightforward to implement the typechecking in STC so that
   isn't a concern.
   - You can already do that with type variables in Swift/T, e.g. the
   repr() function that returns a string representation has type signature: <T>
   (string o) repr(T x).  We also have repr_array: <T> (string o[])
   repr_array(T A[]).   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).
   - It may cause some confusion if programmers see the type and assume
   they will be able to instantiate *any x*; and have a dynamically typed
   variable.  This may just be a documentation issue.
   - We should try to only use it for functions where it can actually
   accept any type.  .  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: switch
   (type) {... default: printf("I don't like this type"); exit(1); }.
   Sometimes it's not possible to express something more nuanced in the
   type system, so it's difficult to always avoid.
   - If the function body is just going to be a switch (type) {...}, 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.
   - 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).

- Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150213/07d0383b/attachment.html>


More information about the Swift-devel mailing list