[Swift-devel] expression typing

[Tim Armstrong]

Yes, it's been like this for a long time (it's the same in Swift/K).

Generally I think it's best to not diverge from convention unnecessarily,
but the traditional C behaviour is so error prone - you have two related
but distinct mathematical operations being denoted with the same symbol.
I've seen the mistake of doing integer division instead of floating point
division all the time from beginner programmers and even with some
frequency in code from experienced programmers who understand the behaviour
but had a mental lapse (myself included).

Neither implementation does much in the way of automatic type coercion.  In
general I have avoided it since there's a high probability of unintended
consequences, except when a) there's no chance of information loss and b)
they're of the same general category of types, e.g. numeric.

The only differences I could find were:
1. Swift/T always casts integer literals to floats provided they're exactly
representable, Swift/K only seems to when they're arguments to operators.
2. Swift/K integers are 32-bits, which means that in context where they
might be casted, they can always be cast to (double-precision) floats
without information loss.  In Swift/T, they're 64-bit, so you can lose
precision casting to double - Swift/T won't coerce integers to floats
unless it's a literal where it knows the value.
3. Swift/K will coerce numeric types to strings in very limited situations
(when applying the + operator to a string and a numeric type).  Swift/T
doesn't do this.

I've created a ticket for the last feature in Swift/T:
https://code.google.com/p/exm-issues/issues/detail?id=733

- Tim


On Fri, Aug 15, 2014 at 9:39 AM, Justin M Wozniak <wozniak at mcs.anl.gov>
wrote:

>
> Both Swifts use / for floating point division and %/ for integer
> division, both are in the docs.
>
> On 08/15/2014 09:33 AM, Michael Wilde wrote:
> > A  participant in yesterday's ATPESC tutorial was surprised to see that
> > division of two integers yields a float type.
> >
> > We should discuss this, as well as unification of the type coercion
> > rules of both Swift/K and Swift/T, and document what the situation is
> > (as well as whether we plan to change it).
> >
> > - Mike
> >
>
>
> --
> Justin M Wozniak
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20140815/a5f8c738/attachment.html>