[Swift-devel] numeric type(s) in swift.

[Mike Wilde]

OK, I just reread the thread from the top, and have some thoughts on what our 
alternatives are.

Some of the road forward depends on:

1) whether we care about breaking current code
2) how well the current code can handle (or be taught) type coercions

If I had to pick a simple system, I'd pick either:

a) just strings
b) just string and ints
c) just strings and floats where floats act like ints when they have integral 
values (many systems are like this)
d) strings, ints and floats with fully manual coercions
e) strings, ints and floats with reasonable auto coercions ala C

My pref would be (e) if thats easy to implement.

Forget what I said abut XML-Schema types earlier.

Do the choices above cover the range of reasonable choices?

What are the major open issues, give, say (e)?

- Mike




Ben Clifford wrote, On 7/20/2007 12:11 PM:
> 
> On Fri, 20 Jul 2007, Mike Wilde wrote:
> 
>> Is there any app-based request in bugzilla right now that demands a more
>> immediate resolution of this issue?
> 
> its more that it comes from me trying to do the bug 30 rewrite of the 
> intermediate format - every bug that depends on that has a workaround 
> being used by apps as they encounter them, however its a serious usability 
> problem in terms of people writing code they think will work and finding 
> it doesn't (and worse, finding it fails in mysterious ways).
> 
>> Seems like we can always do (b) in another language, so we can always 
>> "get by" by having all args be strings for the moment.  Not pretty, but 
>> it lowers the urgency of an immediate decision.
> 
> A 'numeric' type that makes no more constraint on its content looks very 
> much like a string; but is still typed enough to know that you can use + 
> or - or / or * on it. There's no shame in that.
> 
> You say:
> 
>> it lowers the urgency of an immediate decision.                               
> 
> but deciding (if we do or not) on this approach *is* the kind of decision 
> that I'm looking for!
> 
>> I think also that at some point we'll need to reconcile whether we 
>> support all (or more) of the primitive data types of XML Schema, which 
>> has more numeric and date types.
> 
> 'int' isn't even an XML Schema primitive type - its defined as a 
> restriction of a more general type... Our present type model looks almost 
> entirely unlike XML Schema.
> 

-- 
Mike Wilde
Computation Institute, University of Chicago
Math & Computer Science Division
Argonne National Laboratory
Argonne, IL   60439    USA
tel 630-252-7497 fax 630-252-1997