Tom Christiansen wrote:
>
> >Several people have suggested strong typing as a feature, and have been shot
> >down one by one. However, I think it can be done without forcing it on
> >everyone.
>
> Can it? Are you prepared to make everyone declare the full, formal, and
> fancy types for the return values of all their functions?
I think it can, but don't have proof. See my recently posted RFC for my
opinion of the right direction to go.
> Consider how nasty "strong typing" will really become if you really
> get it all the way, or how slipshod it will be if you only partway.
I agree that the first won't work, but am unconvinced that a partway
solution is so bad. If it catches a large set of errors, then as long as
you don't rely on it for doing your thinking for you, what's the harm?
> You now have to enforce typing of expressions. (Gasp!)
Define what you mean by "enforce". I think it should warn when it's
certain of a problem, or when you've asked it to divulge its misgivings.
> For example, consider a function that is expected to return a list
> of two values, the first a reference to a hash of arrays of integers
> and the second a floating point number.
I find that to be one of the easier ones, since it's a fixed-length
tuple. The hard ones are lists of an unknown number of values. But you
can always punt and fall back to a "list of any" type.
You can get partway, though -- I once worked on a project where we had a
list type "if there is at least one element, the first one is of type
T1. If there are at least two, the first is type T1 and the second is
type T2. If there are three or more, then as before but the third and
all subsequent are of type T3." The notation was something like LIST(T1,
T2, T3...). It worked out well, but may be more effort than it's worth
here. Although multiple known return values _would_ be nice to catch,
rather than just falling back to LIST(least common ancestor(T1,T2,T3)).
