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 <mailto:mich...@zedeler.dk>

dk.linkedin.com/in/mzedeler <http://dk.linkedin.com/in/mzedeler/> | twitter.com/mzedeler <https://twitter.com/mzedeler> | github.com/mzedeler <https://github.com/mzedeler/>

Reply via email to