On 2014-03-29 21:45, Damian Conway wrote:
Moritz wrote:
To spin the tale further, we need to think about what happens if
somebody writes
multi foo(1|2e0) { ... }
so now we have Int|Num. We could explore the most-derived common
ancestor (Cool), or look into role space (Real, Numeric come to mind),
or simply error out.
Or maybe we need to reconsider the whole idea that it's appropriate to
infer type from a smartmatched constraint?
[...]
In other words specifying a constraint value is a way of applying a
smartmatched acceptance test to a parameter, but the type of the
acceptance test is typically totally unrelated to the type of the
parameter.
Which is why it now seems very odd to me that we are currently inferring
parameter types from constraint values.
I couldn't agree more. This looks like a piece of odd-sized baggage left
behind by Moose, where declaring type constraints on attributes is too
easily mistaken as actual type declarations.
Other languages may provide simple restriction rules for parameter value
domains in the shape of types, but in a dynamically typed language, it
doesn't make much sense, since there may be conversion paths between the
types involved.
I'd much more prefer a pure matching language where no assumptions about
types are done automatically, forcing me to write explicit type
constraints myself, if I believe they are necessary (they should rarely
be needed, since having to deal too much with types in a dynamically
typed language is counterproductive :-) ).
In general - Perl (5) is a great tool because it doesn't force people to
deal too much with typing (both implicit and explicit). Lets keep it
that way.
--
Michael Zedeler
70 25 19 99
mich...@zedeler.dk
dk.linkedin.com/in/mzedeler |
twitter.com/mzedeler |
github.com/mzedeler
